Vm-dev September 2014

vm-dev@lists.squeakfoundation.org

25 participants
90 discussions

Re: [squeak-dev] replaceFrom:to:with:startingAt:
by Eliot Miranda 23 Sep '14

23 Sep '14

On Mon, Sep 22, 2014 at 1:47 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > 2014-09-22 22:34 GMT+02:00 Bert Freudenberg <bert(a)freudenbergs.de>: > >> >> On 22.09.2014, at 22:21, Ron Teitelbaum <ron(a)usmedrec.com> wrote: >> >> > >> >> From: Bert Freudenberg >> >> Sent: Monday, September 22, 2014 4:00 PM >> >> >> >> I just found out why PNG decoding was broken in SqueakJS [*]. Wouldn't >> >> have believed that any code actually relied on the following behavior: >> >> >> >> | a | >> >> a := (1 to: 20) asArray. >> >> a replaceFrom: 11 to: 20 with: a startingAt: 8. >> >> >> >> ==> #(1 2 3 4 5 6 7 8 9 10 8 9 10 8 9 10 8 9 10 8) >> >> >> > That's funky! Hope it wasn't my code! Seems wrong to not copy the >> array >> > before modifying it (Like your buggy VM did). >> >> It's not a copy. It moved the numbers 8-17 to index 11. Which is what I >> erroneously had assumed to be the desired behavior. >> >> - Bert - >> >> > It's a known problem. > The primitive should use memmove rather than memcpy. > So the solution is quite simple, it's just that it's waiting for a good > soul to integrate it. > Um, no. It has ever been so and must therefore remain. This is the method (as in the Smalltalk-80 V2 sources) that the primitive optimizes: replaceFrom: start to: stop with: replacement startingAt: repStart "This destructively replaces elements from start to stop in the receiver starting at index, repStart, in the collection, replacement. Answer the receiver. No range checks are performed - this may be primitively implemented." | index repOff | repOff _ repStart - start. index _ start - 1. [(index _ index + 1) <= stop] whileTrue: [self at: index put: (replacement at: repOff + index)] So the primitive is correct. This is memcpy behaviour. IIRC BitBlt is the same. There were some BitBlt ticks played with image fill that depended on this. | oc | oc := OrderedCollection withAll: (1 to: 20). oc replaceFrom: 11 to: 20 with: oc startingAt: 8. oc => an OrderedCollection(1 2 3 4 5 6 7 8 9 10 8 9 10 8 9 10 8 9 10 8) > Ron >> > >> >> In my (buggy) VM it answered >> >> >> >> ==> #(1 2 3 4 5 6 7 8 9 10 8 9 10 11 12 13 14 15 16 17) >> >> >> >> which apparently did not at all match what The Creators intended ;) >> >> >> >> - Bert - >> >> >> >> [*] specifically, #decompressBlock:with: >> > >> > >> >> >> >> >> >> > > > > -- best, Eliot

1 0

Re: [squeak-dev] Recompile of Mac VM 4.2.5beta
by David T. Lewis 20 Sep '14

20 Sep '14

Javier, Thank you for doing this, it will be a big help for many people. I do not have a Mac to test this myself, but I hope that we can have a few volunteers to download the VM and try it, especially on older Mac computers. This VM is updated to the latest VM sources, so I expect that it will be able to run the latest closure enabled Squeak trunk images, as well as Etoys and other older images. Dave On Sat, Sep 20, 2014 at 02:00:44PM -0500, Javier Diaz-Reinoso wrote: > I tested the VM with the '0 tinyBenchmarks' and the results are similar to the original, so I am sending a link to the zip file with the results, the files contains: > > - Squeak 4.2.5beta2U.zip, the VM recompiled, I copied the external plugins from the original. > > - SqueakVMUNIXPATHS.xcodeproj.zip, an updated xcodeproj for Xcode, this add links to > InternetConfigPlugin.c and MacMenubarPlugin.c, this are not present in the trunk for Mac OS, I copied from the platforms/iOS/vm/src/vm/intplugins, I think the VMMaker of Mac OS needs to be modified, I copied the files to the corresponding directories in Mac OS/plugins/, also there are links to AsynchFilePlugin, SerialPlugin and SocketPlugin in the platforms/unix/. > > - Squeak VM Universal-Info.plist, an updated version, the only modification is the version, I updated to 4.2.5beta2 to distinguish from the original, I think is important if any problem is detected. > > I also try to compile the CameraPlugin and ScratchPlugin, but there are problems: the CameraPlugin access functions called CameraName, OpenCamera, etc.. not present in the Mac, ScratchPlugin have some functions similar to the UnixSerialPlugin, but at the moment neither are ready to be added to the VM. > > Link: > > http://squeakvm.org/~lewis/MacOS-test-Javier/

1 0

Re: [Pharo-dev] Parsing Pharo syntax to C/C++
by Eliot Miranda 20 Sep '14

20 Sep '14

Hi All, On Mon, Sep 15, 2014 at 6:01 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2014-09-15 14:39 GMT+02:00 Clément Bera <bera.clement(a)gmail.com>: > >> Hello, >> >> Note that slang is a subset of smalltalk. The Slang compiler does not >> allow to compile smalltalk to C. It allows to compile a smalltalk with >> restricted message sends and classes to C. >> > > Yes, I am aware of that. I remember that from the very beginnings of > Squeak. > > Wasn't Smalltalk/X the one which had a more complete version of that C > translation? I did an internship in a French company who had a Smalltalk to > C translator done for them a long time ago. > > >> >> 2014-09-15 13:28 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: >> >>> Hi Phil, >>> >>> thanks for the update on Slang to C. Allways significant to have that. >>> >> >>> Two open questions: >>> >>> - would a slang to x86 asm via NativeBoost be doable / a nice target? >>> >> >> Yes it would be interesting. However, by having a Slang to C compiler, >> we're platform-independent, we can compile the C code to x86, x86_64 and >> ARM quite easily (some part of the VM are already processor dependent, but >> not so much). Targeting direct machine code implies evolving the Slang >> compiler for each new assembly code we support. It sounds like a lot of >> engineering work compared to our resources and the gain. >> > > It would allow JIT-type compilation experiments than a Slang-to-C chain > isn't designed for :) With a lot more work doing the various NB ports, of > course. > > >> >>> - would targetting LLVM-IR be of interest? >>> >>> If you compile the C code with Clang instead of gcc, which starts to be >> the case because of the lack of support for gcc in the latest Mac OS X, you >> are already using LLVM IR because Clang uses it. As the VM use the GNU C >> extensions to improve performance, I do not think that targeting directly >> the LLVM IR would greatly improve performance. So it sounds like quite some >> engineering work for no gain. >> > > I would not suggest replacing C by LLVM-IR for VM work, in part because > LLVM-IR is not what I would call a readable source code format... But I do > know that even when doing C to C rewritting for embedded compilation, there > is some low-level code that you can't write in C. > I find this whole discussion depressing. It seems people would rather put their energy in chasing quick fixes or other technologies instead of contributing to the work that is being done in the existing VM. People discuss using LLVM as if the code generation capabilities inside Cog were somehow poor or have no chance of competing. Spur is around twice as fast as the current memory manager, has much better support for the FFI. Clément and I, now with help from Ronie, are making excellent progress towards an adaptive optimizer/speculative inliner that will give us similar performance to V8 (the Google JavaScript VM, lead by Lars Bak, who implemented the HotSpot VM (Smalltalk and Java)) et al. We are trying to get person-power for a high-quality FFI and have a prototype for a non-blocking VM. When we succeed C won't be any better and so it won't be an interesting target. One will be able to program entirely in Smalltalk and get excellent performance. But we need effort. Collaboration. Personally I feel so discouraged when people talk about using LLVM or libffi or whatever instead of having the courage and energy to make our system world-class. I have the confidence in our abilities to compete with the best and am saddened that people in the community don't value the technology we already have and can't show faith in our abilities to improve it further. Show some confidence and express support and above all get involved. Collaborators <http://www.mirandabanda.org/cogblog/collaborators/> Cog Projects <http://www.mirandabanda.org/cogblog/cog-projects/> Spur 1/3 <https://www.youtube.com/watch?v=k0nBNS1aHZ4&index=49&list=PLJ5nSnWzQXi_6yyR…> Spur, a new object representa... <http://www.slideshare.net/esug/spur-a-new-object-representation-for-cog> Sista: Improving Cog's JIT performance 1/2 <https://www.youtube.com/watch?v=X4E_FoLysJg&list=PLJ5nSnWzQXi_6yyRLsMMBqG8Y…> Sista: Improving Cog’s JIT pe <http://www.slideshare.net/esug/sista-talkesug2>.. Lowcode: Redoing NativeBoost ... <http://www.slideshare.net/esug/03-lowcodeslides> However, I think Ronie was interested in doing such work. If he succeeds >> and reports performance improvement, then we can consider using his >> compiler to compile the VM. >> > > Keep us posted! > > Thierry > -- in hope, Eliot

9 12

Re: [Pharo-dev] [squeak-dev] Re: The Dilemma: Building a Futuristic GUI for Ephestos
by Eliot Miranda 19 Sep '14

19 Sep '14

Hi Torsten, wow, what a great summary. Thanks. See below. On Wed, Sep 17, 2014 at 12:09 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Eliot wrote: > >We're getting there with fast. Tiny needs more definition, but the core > Cog/Spur VM on Mac minus plugins and GUI >code is 568k, 506k code, 63k > data; the newspeak VM which has fewer primitives but support for two > bytecode sets is >453k, 386k code, 68k data. That includes the > interpreter, JIT, core primitives and memory manager/GC. Add on >several k > for the FFI, C library et al and a VM in a megabyte is realistic. Is that > in the right ball park? > > Yes, wet's my appetite :) > > Tiny means easy to download and use for scripting, no other dependencies > for the out of the box REPL experience. But still powerfull to built one > on another > and scale up to large programs. > > Initially you provide just a simple VM executable for a "tiny smalltalk" > (ts), for simple > things like: > > c:\myscripts\ts.exe -e 3+4 > 7 > > where ts.exe is the VM in a few kB including a small initial kernel image > (as part of > the PE DATA section). It should be able to run scripts: > > c:\myscripst\ts.exe automate.st > > It should be possible to easily build components (either with or without > the sources): > > ts.exe sunit.st -o sunit.sll > ts.exe sunit.st -noSource -o sunit.sll > > So you can either include other scripts > > ts.exe -i sunit.st mytests.st > > or link the previously built binary components to form something new. > > ts.exe -l junit.sll mytests.st > > But it should be possible to build another vm+image easily: > > ts.exe -i mykillerapp.st -o killerapp.exe > or ts.exe -l mykillerapp.sll -o killerapp.exe > > by writing a new PE file for Windows either including a new kernel image > or a combined > one based on the already built-in initial kernel of the previous one. > So I can deploy a killerapp or reassemble it to form the next language > version. > > SmallScript was very close to that and it was a nice thing to work with. > Especially since usually Smalltalk usually throws things out at the end - > but > one never builds a house by carving it out of a rock. We need bricks to > assemble. > +1000. With the above scheme you could build components, some of them portable, > others > explicitly non-portable as the code includes native calls. The later have > to > be rebuilt on the other platform - so if you have good design abstractions > you > can implement a UI lib on Windows and one on Mac. > > Some of the components are with the source code packaged in for debugging > (but not changeable), for closed source components you leave it out. > > And still it should support pinnable objects (not moved by GC for > callouts), > sandboxing, Classes with UUIDs to allow for side by side loading/migration > and an extensible meta-scheme as this is where Smalltalk is still the hero > of all > und metaprogramming will be our future. > So so far I have pinning. But I'd love to hear more detail on sandboxing. I'm not sure about UUIDs. What about other mechanisms, namespaces, ClassBoxes? UUID sounds too much like an implementation to me. No one is proposing qualifying class names with UUIDs (Array:c5c09212-0c7d-44f3-81b7-18ae5d7f14d9 new: 5 ????). How about reitierating this more abstractly? Also the VM should be available as a shared component - so it can run > in-process > in other programs like a web browser. Always wished to write: > > <script type="text/tinyscript"> > BrowserLog write: 'HelloWorld'. > </script> > > directly in HTML. > > And this is only the beginning of the wish list... > Please, I'd love to have you write a fuller list. We could add it to the list at Cog Projects <http://www.mirandabanda.org/cogblog/cog-projects/> or add it to a "Directions" page or some such. But capturing these ideas is importasnt. >Yep. But personally I think Fuel is better and just as fast. Certainly > that's the parcels experience. > > - but still with the ability to bootstrap up to a full saveable image > > Yes, Fuel would be an option. At least it would be platform independent. > Not sure > about other options (quick loading by mapping component using memory > mapped files etc.) > Well, mapping finished images a la VW's PermSpace is probably easier. The memory mapping in .Nt is extremely complex. But I get the requirement; ultra-fast start-up of small components. > >This we'll leave to the web framework designers, but it seems eminently > doable no? > > For sure. > > Bye > Torsten > thanks again. And give serious thought to carefully enunciating these requirements/this design sketch? -- best, Eliot

2 1

Re: [Pharo-dev] Implementing lazy loading for expandable collections
by Eliot Miranda 19 Sep '14

19 Sep '14

On Fri, Sep 19, 2014 at 2:35 AM, Max Leske <maxleske(a)gmail.com> wrote: > I’ve written an implementation of lazily initialized expandable > collections (for OrderedCollection and subclasses only for now), inspired > by Alexandre’s talk at ESUG ( > http://www.youtube.com/watch?v=x0YJ2dsZdKg&list=UUO-vBhaKVZf0al-ISMMPvRw). > The implementation is pretty much straight forward but there are a couple > of culprits I want to point out in case anybody else wants to do this: > > - my implementation requires an extra instance variable in > OrderedCollection to store the requested size. This extra instance variable > will break Monticello (and possibly other tools) because Monticello uses > OrderedCollections to load code and the particular way it uses them makes > it impossible to change the number of instance variables on > OrderedCollection. Also, all .mcz files written after the change will not > be loadable by images without the new instance variable (same reason). > - the above means that you have to modify the code in the image manually > and save a new “base image" > - read only messages should obviously not initialize the array. The > ‘firstIndex’ and ‘lastIndex’ variables are quite handy for that. I > initialize those variables to 1 and 0 respectively which makes most things > work already (e.g. #size, #isEmpty etc.). > - when trying to implement the same for HashedCollection I couldn’t. The > image didn’t just stop working, there was no output at all on the console, > not even when using a debug VM. The problem seems to be MethodDictionary, > at least that’s the only subclass of Dictionary for which adding an > instance variable doesn’t work. > Yes, alas the shape of MethodDIctionary is baked into the VM's method lookup code. It would be straight-forward to fix it, but it is still work and one would have to wait for people to update their VMs. I’ll share some memory monitoring as soon as I have something significant > (only just rolled it out). > > > Big thanks to Alex for his talk and the cool work he and his students did! > > Cheers, > Max > -- best, Eliot

1 0

[commit][3081] And of course adding the linux pulse audio plugin requires a new configure .
by commits＠squeakvm.org 18 Sep '14

18 Sep '14

Revision: 3081 Author: eliot Date: 2014-09-18 10:12:31 -0700 (Thu, 18 Sep 2014) Log Message: ----------- And of course adding the linux pulse audio plugin requires a new configure. Modified Paths: -------------- branches/Cog/platforms/unix/config/configure Modified: branches/Cog/platforms/unix/config/configure =================================================================== --- branches/Cog/platforms/unix/config/configure 2014-09-16 02:54:54 UTC (rev 3080) +++ branches/Cog/platforms/unix/config/configure 2014-09-18 17:12:31 UTC (rev 3081) @@ -27480,6 +27480,76 @@ done echo ${llibs} > ${plugin}.lib fi +plugin="vm-sound-pulse" +plibs="" +rm -f vm-sound-pulse.sub vm-sound-pulse.lib +# -*- sh -*- + +echo "$as_me:$LINENO: checking for PulseAudio" >&5 +echo $ECHO_N "checking for PulseAudio... $ECHO_C" >&6 +cat >conftest.$ac_ext <<_ACEOF +/* confdefs.h. */ +_ACEOF +cat confdefs.h >>conftest.$ac_ext +cat >>conftest.$ac_ext <<_ACEOF +/* end confdefs.h. */ +#include <pulse/simple.h> +int +main () +{ +(void)pa_simple_new; + ; + return 0; +} +_ACEOF +rm -f conftest.$ac_objext +if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5 + (eval $ac_compile) 2>conftest.er1 + ac_status=$? + grep -v '^ *+' conftest.er1 >conftest.err + rm -f conftest.er1 + cat conftest.err >&5 + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); } && + { ac_try='test -z "$ac_c_werror_flag" + || test ! -s conftest.err' + { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 + (eval $ac_try) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); }; } && + { ac_try='test -s conftest.$ac_objext' + { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 + (eval $ac_try) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); }; }; then + + echo "$as_me:$LINENO: result: yes" >&5 +echo "${ECHO_T}yes" >&6 + +else + echo "$as_me: failed program was:" >&5 +sed 's/^/| /' conftest.$ac_ext >&5 + + + echo "$as_me:$LINENO: result: no" >&5 +echo "${ECHO_T}no" >&6 + + + echo "$as_me:$LINENO: result: ******** disabling ${plugin}" >&5 +echo "${ECHO_T}******** disabling ${plugin}" >&6 + disabled_plugins="${disabled_plugins} ${plugin}" + +fi +rm -f conftest.err conftest.$ac_objext conftest.$ac_ext +if test "${plibs}"; then + llibs="${LIBS}" + for l in ${plibs}; do + llibs="${llibs} -l${l}" + done + echo ${llibs} > ${plugin}.lib +fi plugin="vm-sound-Sun" plibs="" rm -f vm-sound-Sun.sub vm-sound-Sun.lib

1 0

VM Maker: CogCompatibility-eem.2.mcz
by commits＠source.squeak.org 18 Sep '14

18 Sep '14

Eliot Miranda uploaded a new version of CogCompatibility to project VM Maker: http://source.squeak.org/VMMaker/CogCompatibility-eem.2.mcz ==================== Summary ==================== Name: CogCompatibility-eem.2 Author: eem Time: 17 September 2014, 6:53:04.247 pm UUID: 48f8bdd5-a92a-441b-8766-4a81f3075f44 Ancestors: CogCompatibility-eem.1 prmitiveFail => prmitiveFailed in 2 Context methods. =============== Diff against CogCompatibility-eem.1 =============== Item was changed: ----- Method: Context>>basicSize (in category 'accessing') ----- basicSize "Primitive. Answer the number of indexable variables in the receiver. This value is the same as the largest legal subscript. Essential. Do not override in any subclass. See Object documentation whatIsAPrimitive. Override the default primitive to give latitude to the VM in context management." <primitive: 212> "The number of indexable fields of fixed-length objects is 0" + ^self primitiveFailed! - ^self primitiveFail! Item was changed: ----- Method: Context>>size (in category 'accessing') ----- size "Primitive. Answer the number of indexable variables in the receiver. This value is the same as the largest legal subscript. Essential. See Object documentation whatIsAPrimitive. Override the default primitive to give latitude to the VM in context management." <primitive: 212> "The number of indexable fields of fixed-length objects is 0" + ^self primitiveFailed! - ^self primitiveFail!

1 0

VM Maker: BytecodeSets.spur-eem.13.mcz
by commits＠source.squeak.org 18 Sep '14

18 Sep '14

Eliot Miranda uploaded a new version of BytecodeSets to project VM Maker: http://source.squeak.org/VMMaker/BytecodeSets.spur-eem.13.mcz ==================== Summary ==================== Name: BytecodeSets.spur-eem.13 Author: eem Time: 17 September 2014, 6:51:49.342 pm UUID: e0f9eeee-6633-479d-8441-ef24b2e0b085 Ancestors: BytecodeSets.spur-eem.12 Implement isReturnTopFromMethodAt:in: for other bytecode sets (& stackDeltaForPrimitive:in:) for Sista. Lose bogus subclassResponsibility message from InstructionPrinter>>#pushExplicitOuter: =============== Diff against BytecodeSets.spur-eem.12 =============== Item was changed: SystemOrganization addCategory: #'BytecodeSets-NewsqueakV3'! - SystemOrganization addCategory: #'BytecodeSets-SistaV1'! SystemOrganization addCategory: #'BytecodeSets-NewsqueakV4'! SystemOrganization addCategory: #'BytecodeSets-ParseNodes'! + SystemOrganization addCategory: #'BytecodeSets-SistaV1'! Item was added: + ----- Method: EncoderForNewsqueakV4 class>>isReturnTopFromMethodAt:in: (in category 'instruction stream support') ----- + isReturnTopFromMethodAt: pc in: method + "Answer whether the bytecode at pc is a return stack top from method." + + ^(method at: pc) = 217! Item was added: + ----- Method: EncoderForSistaV1 class>>isReturnTopFromMethodAt:in: (in category 'instruction stream support') ----- + isReturnTopFromMethodAt: pc in: method + "Answer whether the bytecode at pc is a return stack top from method." + + ^(method at: pc) = 92! Item was changed: + ----- Method: EncoderForSistaV1 class>>stackDeltaForPrimitive:in: (in category 'bytecode decoding') ----- - ----- Method: EncoderForSistaV1 class>>stackDeltaForPrimitive:in: (in category '*BytecodeSets-bytecode decoding') ----- stackDeltaForPrimitive: primitiveIndex in: method "Answer the stack delta for the callPrimitive: bytecode (see my class comment). There is no delta for non-inlined primitives (its implicitly 0 - method numArgs). Inlined primitives are grouped by the thousand by argument count, 32 args max ;-)." ^primitiveIndex < 32678 ifTrue: [0] ifFalse: [primitiveIndex - 32768 // 1000]! Item was changed: ----- Method: InstructionClient>>pushExplicitOuter: (in category '*BytecodeSets-NewsqueakV3-decoding') ----- + pushExplicitOuter: n "<Integer>" + "Push the enclosing object at level n."! - pushExplicitOuter: n - "Push the Active Context's Receiver for an outer send at level n." - - self subclassResponsibility!

1 0

Re: [squeak-dev] Mac VM build (was: [ANN] FunZqueak 4.6 alpha for try)
by David T. Lewis 18 Sep '14

18 Sep '14

Javier, Brilliant! This is very good news indeed. On Wed, Sep 17, 2014 at 06:38:23PM -0500, Javier Diaz-Reinoso wrote: > > This is a status report, I successfully compile the VM; the only problem was > in src/plugins/ the directories for InternetConfigPlugin/ and MacMenubarPlugin/ > was not present, I copied from platforms/iOS/, I am not sure if that is a > problem with VMMaker. That sounds right, copying from platforms/iOS should be good. I think this was my mistake. I have been generating the sources for trunk/src from a unix platform, and I did not know that I needed to generate InternetConfigPlugin and MacMenubarPlugin. I will try to fix this. > > I tested in the Mac mini PowerPC and a iMac intel and work correctly with a > Squeak 4.1 image, the report from Smalltalk listBuiltinModules gives 35 plugins, > the same as the original. > As an external plugin I copied the TestOSAPlugin.bundle and tested Applescript ok. > That is great. The VM that you built should work with the latest Squeak trunk images, and it should work with images that were saved from a Cog VM. It should also be able to run older Squeak 3.8 images and Etoys images. As soon as you are ready, I would like to make your updated VM available to everyone. We should be able to serve it from squeakvm.org, and I will try to get access for you as soon as possible. If you do not mind joining another mailing list, it would be good to have you on the vm-dev list: http://lists.squeakfoundation.org/mailman/listinfo/vm-dev @Edgar De Cleene: I think that this new VM will help with your FunSqueak image so that it can run on an older Mac. @Ian Piumarta: When you return I would like to arrange for squeakvm.org access for Javier. I would also like to clean up some broken links on squeakvm.org/mac and make Javier's update of the Carbon VM available from that page. Dave

1 0

Re: [squeak-dev] Mac VM build (was: [ANN] FunZqueak 4.6 alpha for try)
by David T. Lewis 16 Sep '14

16 Sep '14

Great! Thank you again. vm-dev: Please disregard my request for an xcodeproj file. Dave > Oh my fault!, the files are in trunk, in platforms/Mac\ OS/vm/Developer, > so I start now. > > On 16/09/2014, at 06:40, David T. Lewis <lewis(a)mail.msen.com> wrote: > >> Looking for xcodeproj for Squeak 4.2.5beta1U Mac VM, see below: >> >> On Mon, Sep 15, 2014 at 02:51:34PM -0500, Javier Diaz-Reinoso wrote: >>> On 14/09/2014, at 16:43, David T. Lewis <lewis(a)mail.msen.com> wrote: >>> >>>> >>>> >>>> On Sun, Sep 14, 2014 at 12:43:51PM -0500, Javier Diaz-Reinoso wrote: >>>>> On 13/09/2014, at 13:34, David T. Lewis <lewis(a)mail.msen.com> wrote: >>>>> >>>>>> ... >>>>>> Of course it does work with the interpreter VM also. But some people >>>>>> (including Edgar) have older Macs, and they are stuck with using a >>>>>> very >>>>>> outdated VM on those machines. If anyone with good working knowledge >>>>>> of >>>>>> Mac development would like to build an updated Mac interpreter VM, >>>>>> it >>>>>> would be much appreciated. It's not something that I know how to do, >>>>>> but >>>>>> I'm sure someone must have the skills and experience to be able to >>>>>> do >>>>>> this. >>>>>> >>>>>> Dave >>>>>> >>>>> >>>>> In this moment I have an old mac mini ppc loaded with Xcode 3.1.4 who >>>>> is the last version that works on PPC, so I can try to generate an 32 >>>>> bit >>>>> fat binary (ppc/x86) if you can point me to the last svn. >>>> >>>> Javier, >>>> >>>> Thank you! I am cc'ing the vm-dev list also. >>>> >>>> The most up to date SVN is here: >>>> >>>> svn co http://squeakvm.org/svn/squeak/trunk/platforms >>>> svn co http://squeakvm.org/svn/squeak/trunk/src >>>> >>>> The trunk/platforms tree will give you the platforms sources for all >>>> platforms. If you want just the Mac OS parts, it would be: >>>> >>>> svn co http://squeakvm.org/svn/squeak/trunk/platforms/Cross >>>> svn co http://squeakvm.org/svn/squeak/trunk/platforms/Mac\ OS >>>> >>>> The trunk/src tree contains sources generated from a VMMaker image >>>> to match the platforms sources in trunk/platforms. You may prefer to >>>> generate these yourself, but the most recent sources in trunk/src >>>> will match the most recent sources in trunk/platforms, and I expect >>>> that they should work for you, even though I have tested them only >>>> on Unix (Linux), not Mac OS with Xcode. >>>> >>>> The directory structure in trunk/src will probably not match the >>>> organization of the Xcode project, so you may need to copy files or >>>> reorganize them for Xcode. >>>> >>>> The Mac OS VM has support for some things (plugins?) that may not >>>> be present in the trunk/src files. If so I will do my best to help >>>> you find them, or perhaps you will be able to use the original code >>>> from the last Mac OS build. >>> The problem is the trunk version don't have the resources directory and >>> the SqueakVMForCarbon.xcodeproj (someone delete this files), the >>> resource directory can be recreated, but recreating the xcodeproj is a >>> ugly work. >>> >>> So what I need to proceed is a copy of the files of Squeak 4.2.5beta1U >>> (or at least from a older version of 4.2) who include the >>> resource/xcodeproj. >> >> Javier, >> >> The 42.5beta1U release is at >> http://squeakvm.org/mac/release/Squeak%204.2.5beta1U.zip >> but this does not include the resource/xcodeproj file. >> >> I am CC'ing the vm-dev list in hopes that someone on the list has a copy >> of the development files. >> >> vm-dev: Does anyone have, or know how to get, a copy of the Mac xcode >> project >> that was used to build the 4.5beta1U Mac VM? Thanks! >> >> Dave >

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev September 2014