Vm-dev December 2011

vm-dev@lists.squeakfoundation.org

23 participants
33 discussions

"fixed" AbstractLauncher missing for loading Cog
by Mariano Martinez Peck 22 Dec '11

22 Dec '11

Hi guys. I have just "fixed" the problem that we cannot load clean Cog in Pharo 1.4/1.3 because AbstractLauncher was removed. I have created a package CogVMMakerPharoCompatibility in the repo PharoVM of SqueakSource and I have commited a nuked version of AbstractLauncher. It is nuked because the method #activate is sent by Cog's CommandLineLauncher class >> initialize. So...it seems CommandLineLauncher is only used for scripting, so if you DO want to use that class, it won't work in Pharo. But at least Cog will load without problems and you will be able to build a VM. Of course a better solution would be to put 'Cog-Scripting' in a separate package and from ConfigurationOfCog do not loas such separated package if we are in Pharo but do load it if we are in Squeak. If someone (Eliot) publishes such a change, I don't have a problem to rollback this one. But I was tired of this error so I proceeded with this workarround. So...this was done in ConfigurationOfCog new baseline 2.0 and new version 3.7. Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfCog'; load. ((Smalltalk at: # ConfigurationOfCog) project version: '3.7') load Cheers -- Mariano http://marianopeck.wordpress.com

2 1

Re: [Pharo-project] Crashes: Pharo 1.3 + Cog VM 13307
by Esteban Lorenzano 22 Dec '11

22 Dec '11

Thanks for the explanation, Chris. I was thinking on using some of the eliot versions with my own builds, like this: 2222.01, and maybe unix/windows guys could do the same, so we need a prefix, something like 2222.M01 for mac, U01 for unix, W01 for windows... ... or something like that. Anyway... this discussion borns in pharo list, but concerns more to vm-dev list. I'm copying email there :) cheers, Esteban El 21/12/2011, a las 9:28p.m., Chris Cunningham escribió: > On Wed, Dec 21, 2011 at 2:44 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> Hi, >> >> and yes, I know what you feel about version numbers... we (guys working with vm) should find an unique versioning number. But is hard, right now we have this different numbering: >> >> 1) Eliot has his own version number (I think based on svn commit version) >> 2) Each platform (Linux, Windows and Mac) has his own versioning too. >> 3) There are also 4.x versions alive (for mac, at least) >> >> I also don't know what does each version means (3.8 for unix, etc.). I named cocoa versions 6.x because older versions based on carbon where 5.x, so I thought: changing from carbon to cocoa is important enough to have a new major version... but I dunno. >> > > The old numbering system came from pre-Pharo days, when the VM was > just for Squeak. In those days, the VM number was meant to sync with > the current Squeak image release - so vm 3.8 for Unix was the VM that > accompanied the Squeak 3.8 release, compiled for the Unix platform. > Each platform (and, indeed, each variant - such as Cocoa/Carbon) would > use the same main version number, but with some other distinction > built on (and these did change by platform). > > Eliot's VM now supports a wide range of roughly compatible Smalltalks > (or near smalltalks), such as Pharo, Squeak, Croquet, Cuis, Newspeak, > and probably others. In that environment, with each near-smalltalk > having their own numbering schemes, the old numbering convention just > doesn't make sense. So, his using the apparent SVN commit number > makes as much sense as anything - probably a lot more than some. > > As for what you should call the Pharo branded and tweaked versions, > that is obviously up to you. I would suggest finding something that > makes it easy for us users to figure out which version of the PharoVM > works with which Pharo image, if possible. > > -Chris >

1 0

quit message on windows builds
by Esteban Lorenzano 19 Dec '11

19 Dec '11

Hi, Although my direct responsibility with the community is building mac vm's, for my day work necessities I'm also building windows vm's (one of my clients want a multi-platform desktop app). When doing this... I found one difference in vm behavior between mac, linux and windows: when you press "close button" in main window, both linux and mac fires a callback to image, who can decide if quit, quit saving or denial of quit for some reason. Windows, in the other hand, pops up a dialog "Quit Croquet without save" and then quits or not. We can't handle this from image. Changing this is as easy as removing the dialog part... without it, windows behaves just as the other two... So, my question: Why??????? Why is that code there? Is there a reason? or just remnants of older vm's? best, Esteban

2 2

New primitive??? [WAS] Re: [Pharo-project] IdentitySet but using #hash rather than #identityHash ?
by Mariano Martinez Peck 16 Dec '11

16 Dec '11

> "Preallocate objects, so we won't count gc time." > n := 1000000. > objects := Array new: n streamContents: [ :stream | > n timesRepeat: [ stream nextPut: Object new ] ]. > > > set := IdentitySet new: n. > Smalltalk garbageCollect. > [1 to: n do: [ :i | set add: (objects at: i) ] ] timeToRun. "4949" > > set := LargeIdentitySet new. > Smalltalk garbageCollect. > [1 to: n do: [ :i | set add: (objects at: i) ] ] timeToRun. "331" > > set := (PluggableSet new: n) > hashBlock: [ :object | object identityHash * 4096 + object class > identityHash * 64 ]; "Change this to #basicIdentityHash in Pharo" > equalBlock: [ :a :b | a == b ]; > yourself. > Smalltalk garbageCollect. > [1 to: n do: [ :i | set add: (objects at: i) ] ] timeToRun. "5511" > > > I also have a LargeIdentityDictionary, which is relatively fast, but not > as fast as LargeIdentitySet, because (for some unknown reason) we don't > have a primitive that could support it. If we had a primitive like > primitive 132 which would return the index of the element if found or 0 if > not, then we could have a really fast LargeIdentityDictionary. > > Eliot do you think we could provide such a primitive? Thanks > > Levente > > >> Cheers, >> Henry >> >> >> > -- Mariano http://marianopeck.wordpress.com

2 1

Out of the box primitives for bit in ObjectHeader?
by Mariano Martinez Peck 15 Dec '11

15 Dec '11

Hi guys. As you may notice, I always try to push in the direction of a VM where we can have both things: a) a really cooler super fast VM for production super critical applications and b) the most-flexible-possible VM for doing reasearh and experiment. Now I was thinking the following: we have one free bit in the ObjectHeader. Let's say you are experimenting with something and you would like to tag objects, such as, "traversed", "processes", "isProxy", etc. To do that small experiment you need to modify the VM, adapt the bit, code the primitives, build the VM, put the smalltalk side part etc etc. So I was thinking why not providing such small functionality out of the box? the idea would be not to give semantics to the bit since each user will do that. So we just provide the VM with 2 primtives, one to get the value (#getBitValue) and one to set it (#setBitTo:). Choose the names you want. Then we do not integrate nothing in our images that use such bit, there won't be colisions. Then each guy who wants to experiments with that, can use the primitives and do what he wants. Some people is doing something with its bit: Jean Batiptse is doing XXX, I am doing YYY, etc. Either in his work or mine, there are much more changes that just that bit, so in anyway, I will end up needing my own VM. Finally, I could help in providing the code if it is needed. So, what do you think? -- Mariano http://marianopeck.wordpress.com

4 3

Cross compile Window from Unix/Mac os
by Jean Baptiste Arnaud 14 Dec '11

14 Dec '11

Since the last Igor ( thank ) update it 's possible to cross compile windows VM(last version) from MacOs and Unix. Using Mingw and cmake. Now, i do for Cog, and for ARM9 processor. My process imply to fix some window file cause some include are wrong, then it the cross compiler don't find some include beginning by Uppercase(cause the file isn't beginning by uppercase). In /Platform/win32/vm/sqWin32Intel.c #include <float.h> instead #include <Float.h> in /Platform/win32/plugin/SocketPlugin/sqWin32NewNet.c #include <ws2tcpip.h> instead #include <Ws2tcpip.h> Regard Jean Baptiste Arnaud jbaptiste.arnaud(a)gmail.com

4 8

Weird Cog VM Crash [WAS] Fwd: [Moose-dev] Re: Pharo + Moose on Windows 7
by Mariano Martinez Peck 12 Dec '11

12 Dec '11

Hi Eliot. Look at what a weird crash ;) (attached dmp) Trying to load Moose with Metacello... how can a bitmap be related there? And I think it is even reproducible in Windows with a Pharo 1.3 image and executing Gofer new squeaksource: 'Moose'; package: 'ConfigurationOfMoose'; load. (Smalltalk at: #ConfigurationOfMoose) perform: #loadDefault. Smalltalk stack dump: 0x19cd48 I Bitmap(ProtoObject)>become: 105252488: a(n) Bitmap 0x19cd74 M Bitmap>? 105252488: a(n) Bitmap 0x19cd8c M Bitmap>? 105252488: a(n) Bitmap 0x19cda8 M Bitmap>? 105252488: a(n) Bitmap 0x19cdcc M ConfigurationOfGrease class(Behavior)>basicAddSelector:withMethod: 96391684: a(n) ConfigurationOfGrease class 0x19cdec M ConfigurationOfGrease class(Behavior)>methodDictAddSelectorSilently:withMethod: 96391684: a(n) ConfigurationOfGrease class 0x19ce0c M ConfigurationOfGrease class(Behavior)>addSelectorSilently:withMethod: 96391684: a(n) ConfigurationOfGrease class 0x19ce2c M ConfigurationOfGrease class(ClassDescription)>addSelectorSilently:withMethod: 96391684: a(n) ConfigurationOfGrease class 0x19ce4c M MethodAddition>installMethod 98574536: a(n) MethodAddition 0x19ce64 M [] in MCPackageLoader>basicLoad 96367996: a(n) MCPackageLoader 0x19ce84 M OrderedCollection>do: 96368076: a(n) OrderedCollection 0x19cea0 M [] in MCPackageLoader>basicLoad 96367996: a(n) MCPackageLoader 0x19cebc M BlockClosure>on:do: 96391128: a(n) BlockClosure 0x19cee4 I [] in MCPackageLoader>basicLoad 96367996: a(n) MCPackageLoader 0x19cf04 M BlockClosure>ensure: 96391004: a(n) BlockClosure 0x19cf28 I MCPackageLoader>basicLoad 96367996: a(n) MCPackageLoader 0x19cf48 I [] in MCPackageLoader>loadWithNameLike: 96367996: a(n) MCPackageLoader 0x19cf6c I [] in MCPackageLoader>useChangeSetNamed:during: 96367996: a(n) MCPackageLoader 0x19cf8c M BlockClosure>ensure: 96390808: a(n) BlockClosure 0x19cfb8 I MCPackageLoader>useChangeSetNamed:during: 96367996: a(n) MCPackageLoader 0x19cfe0 I MCPackageLoader>useNewChangeSetNamedLike:during: 96367996: a(n) MCPackageLoader 0x19d008 I MCPackageLoader>loadWithNameLike: 96367996: a(n) MCPackageLoader 0x19d030 I MCVersionLoader>loadWithNameLike: 96367856: a(n) MCVersionLoader 0x19d054 I MCVersionLoader>load 96367856: a(n) MCVersionLoader ---------- Forwarded message ---------- From: Hani Abdeen <hani.abdeen(a)gmail.com> Date: Mon, Dec 5, 2011 at 2:28 PM Subject: [Moose-dev] Re: Pharo + Moose on Windows 7 To: Moose-related development <moose-dev(a)iam.unibe.ch> Ok, this is quit strange. I just loaded Moose default configuration using Croquet VM. No problem with that!! On the other hand, the Pharo VM 1.3 crashes each time I try to load the default configuration of Moose. The crash.dmp file is enclosed herewith. Cheers, Hani On 5 December 2011 13:10, Stéphane Ducasse <stephane.ducasse(a)inria.fr>wrote: > let us (pharo) know the problems because this is really strange. > > Stef > > On Dec 5, 2011, at 12:35 PM, Tudor Girba wrote: > > > Alex, > > > > Hani performed two experiments. One with the default VM shipped with > > the Pharo OneClick, and one with the latest VM from Eliot. > > > > When using the VM from Eliot, he only got an error that seemed to be > > related to not finding something in squeaksource. That is why we > > concluded that it might have been related to squeaksource. > > > > Doru > > > > On Mon, Dec 5, 2011 at 12:28 PM, Alexandre Bergel > > <alexandre.bergel(a)me.com> wrote: > >> Yesterday I was able to install it on OSX but not on WindowsXP, and at > the same time. > >> > >> Alexandre > >> > >> > >> On 5 Dec 2011, at 06:57, Tudor Girba wrote: > >> > >>> Thanks, Mariano. > >>> > >>> Indeed, most likely the issue with the last email was a squeaksource > problem. > >>> > >>> Hani, could you retry? > >>> > >>> Cheers, > >>> Doru > >>> > >>> On Mon, Dec 5, 2011 at 10:32 AM, Mariano Martinez Peck > >>> <marianopeck(a)gmail.com> wrote: > >>>> Weird. I have just tried in my machine and it works. Maybe > squeaksource was > >>>> down? > >>>> Cheers > >>>> > >>>> > >>>> On Mon, Dec 5, 2011 at 12:16 AM, Hani Abdeen <hani.abdeen(a)gmail.com> > wrote: > >>>>> > >>>>> Hi Doru, > >>>>> > >>>>> Thanks for the information. > >>>>> Ok, the Croquet VM > >>>>> (http://www.mirandabanda.org/files/Cog/VM/VM.r2519/cogwin.zip) does > not > >>>>> crash while loading Moose on Pharo image but I still get errors when > trying > >>>>> to load moose configuration. See the attached logs for more > information. > >>>>> > >>>>> The premade Moose images on Moose website work well :) > >>>>> > >>>>> Cheers, > >>>>> Hani > >>>>> > >>>>> > >>>>> On 4 December 2011 22:51, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> On 4 Dec 2011, at 22:31, Hani Abdeen wrote: > >>>>>> > >>>>>>> Thanks Alex > >>>>>>> > >>>>>>> On 4 December 2011 22:07, Alexandre Bergel < > alexandre.bergel(a)me.com> > >>>>>>> wrote: > >>>>>>> Interesting. > >>>>>>> I am able to reproduce the problem, even with XP. The VM indeed > >>>>>>> crashes. > >>>>>>> At the same time, I run it on Mac, and it works well. > >>>>>>> > >>>>>>> Hani, just download the last OneClick Image. Many students of mine > are > >>>>>>> using it on a windows without any problem. > >>>>>>> > >>>>>>> I thought that Pharo-1.3-13315-OneClick.zip is the last stable > OneClick > >>>>>>> release. > >>>>>>> There is also Pharo-1.4.zip but it's annotated as unstable on > >>>>>>> Pharo-Project website. I'll try it. > >>>>>> > >>>>>> Alex meant that you could use the premade Moose OneClick image: > >>>>>> > >>>>>> > http://ci.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/arti… > >>>>>> > >>>>>> Another thing you can try is to use another VM instead of the one > from > >>>>>> the pharo oneclick. For example, try: > >>>>>> http://www.mirandabanda.org/files/Cog/VM/VM.r2519/cogwin.zip > >>>>>> > >>>>>> So, try redoing the experiment and run the Pharo image with the > newly > >>>>>> downloaded VM and let us know if it is better. > >>>>>> > >>>>>> Cheers, > >>>>>> Doru > >>>>>> > >>>>>> > >>>>>>> Cheers, > >>>>>>> Alexandre > >>>>>>> > >>>>>>> NB: I use VirtualBox to run Windows on my Mac, this is really > cool. The > >>>>>>> installation is a bit tricky however. > >>>>>>> > >>>>>>> Yes I agree, it's great to have a strong mac and run Windows on > Mac. > >>>>>>> > >>>>>>> Cheers, > >>>>>>> Hani > >>>>>>> > >>>>>>> > >>>>>>> On 4 Dec 2011, at 17:43, Hani Abdeen wrote: > >>>>>>> > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> Yes it's Strange, since me too did that several days ago and moose > >>>>>>>> was loaded, but when I was playing with Moose the VM crashed. I > thought that > >>>>>>>> was a simple accident. > >>>>>>>> So what I did many many times is the following: > >>>>>>>> - unzip the Pharo-1.3-13315-OneClick.zip > >>>>>>>> - execute pharo.exe > >>>>>>>> - do "DEVImageWorkspaces openExternalProjectWorkspace." > >>>>>>>> - then do: > >>>>>>>> Gofer new > >>>>>>>> squeaksource: 'Moose'; > >>>>>>>> package: 'ConfigurationOfMoose'; > >>>>>>>> load. > >>>>>>>> > >>>>>>>> (Smalltalk at: #ConfigurationOfMoose) perform: #loadDefault. > >>>>>>>> > >>>>>>>> When I found that there is nothing to do and I have always this > crash > >>>>>>>> or an error I thought that I should ask about it. > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> Hani > >>>>>>>> > >>>>>>>> On 4 December 2011 21:27, Tudor Girba <tudor(a)tudorgirba.com> > wrote: > >>>>>>>> Hi Hani, > >>>>>>>> > >>>>>>>> Something is strange. The continuous integration server is using > this > >>>>>>>> script every day without problems. It's true that it is on Linux, > but that > >>>>>>>> should not make much of a difference. > >>>>>>>> > >>>>>>>> Could you provide us with the exact things you are doing (exact > >>>>>>>> links, code and step orders)? > >>>>>>>> > >>>>>>>> Cheers, > >>>>>>>> Doru > >>>>>>>> > >>>>>>>> > >>>>>>>> On 4 Dec 2011, at 21:23, Hani Abdeen wrote: > >>>>>>>> > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> Oops, I past a wrong code above. I try to load the default > >>>>>>>>> configuration of Moose not Magma: > >>>>>>>>> > >>>>>>>>> --- > >>>>>>>>> Gofer new > >>>>>>>>> squeaksource: 'Moose'; > >>>>>>>>> package: 'ConfigurationOfMoose'; > >>>>>>>>> load. > >>>>>>>>> > >>>>>>>>> (Smalltalk at: #ConfigurationOfMoose) perform: #loadDefault. > >>>>>>>>> ---- > >>>>>>>>> > >>>>>>>>> Attached the log and crash dmp files. > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> Hani > >>>>>>>>> > >>>>>>>>> On 4 December 2011 21:16, Tudor Girba <tudor(a)tudorgirba.com> > wrote: > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> I do not understand. Are you loading Moose or Magma? Or trying to > >>>>>>>>> load Magma in a Moose image? > >>>>>>>>> > >>>>>>>>> Doru > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On 4 Dec 2011, at 21:05, Stéphane Ducasse wrote: > >>>>>>>>> > >>>>>>>>>> Alex this is strange because the log mention mondrian > >>>>>>>>>> configuration file. > >>>>>>>>>> > >>>>>>>>>> Begin forwarded message: > >>>>>>>>>> > >>>>>>>>>>> From: Hani Abdeen <hani.abdeen(a)gmail.com> > >>>>>>>>>>> Subject: Pharo + Moose on Windows 7 > >>>>>>>>>>> Date: December 4, 2011 8:52:57 PM GMT+01:00 > >>>>>>>>>>> To: Stéphane Ducasse <stephane.ducasse(a)inria.fr> > >>>>>>>>>>> > >>>>>>>>>>> Hi Stef, > >>>>>>>>>>> > >>>>>>>>>>> I started reading "Pharo by Example" and "Moose book" and > >>>>>>>>>>> familiarizing myself with the new implementation of Moose. > >>>>>>>>>>> I use Pharo 1.3 release on Windows 7. > >>>>>>>>>>> Now, each time I open a clean image of Pharo and try to load > the > >>>>>>>>>>> default configuration of Moose, using the code below, I get an > error or the > >>>>>>>>>>> VM crashes! > >>>>>>>>>>> > >>>>>>>>>>> ------ > >>>>>>>>>>> Gofer new > >>>>>>>>>>> squeaksource: 'MetacelloRepository'; > >>>>>>>>>>> package: 'ConfigurationOfMagma'; > >>>>>>>>>>> load. > >>>>>>>>>>> > >>>>>>>>>>> ((Smalltalk at: #ConfigurationOfMagma) project > >>>>>>>>>>> latestVersion) load > >>>>>>>>>>> ------ > >>>>>>>>>>> > >>>>>>>>>>> The error Stack and the crash dmp file are herewith attached > for > >>>>>>>>>>> more information. > >>>>>>>>>>> > >>>>>>>>>>> I thought that before all I should ask you if I have to use > >>>>>>>>>>> another release of Pharo or if I have to load Moose > differently... > >>>>>>>>>>> > >>>>>>>>>>> Thanks in advance, > >>>>>>>>>>> Hani > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> -- > >>>>>>>>>>> > >>>>>>>>>>> Dr. Hani Abdeen > >>>>>>>>>>> Phd. in Software Engineering - RMod, INRIA Lille-Nord Europe > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> <ErrorDuringLoadingMooseConfigurationDefault-Pharo1.3.txt> > >>>>>>>>>> <crash.dmp> > >>>>>>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> Moose-dev mailing list > >>>>>>>>>> Moose-dev(a)iam.unibe.ch > >>>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >>>>>>>>> > >>>>>>>>> -- > >>>>>>>>> www.tudorgirba.com > >>>>>>>>> > >>>>>>>>> "What we can governs what we wish." > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> Moose-dev mailing list > >>>>>>>>> Moose-dev(a)iam.unibe.ch > >>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> -- > >>>>>>>>> > >>>>>>>>> Dr. Hani Abdeen > >>>>>>>>> Phd. in Software Engineering - RMod, INRIA Lille-Nord Europe > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > <ErrorDuringLoadingMooseConfigurationDefault-Pharo1.3.txt><crash.dmp>_______________________________________________ > >>>>>>>>> Moose-dev mailing list > >>>>>>>>> Moose-dev(a)iam.unibe.ch > >>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >>>>>>>> > >>>>>>>> -- > >>>>>>>> www.tudorgirba.com > >>>>>>>> > >>>>>>>> "We can create beautiful models in a vacuum. > >>>>>>>> But, to get them effective we have to deal with the inconvenience > of > >>>>>>>> reality." > >>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> Moose-dev mailing list > >>>>>>>> Moose-dev(a)iam.unibe.ch > >>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> -- > >>>>>>>> > >>>>>>>> Dr. Hani Abdeen > >>>>>>>> Phd. in Software Engineering - RMod, INRIA Lille-Nord Europe > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> Moose-dev mailing list > >>>>>>>> Moose-dev(a)iam.unibe.ch > >>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >>>>>>> > >>>>>>> -- > >>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >>>>>>> Alexandre Bergel http://www.bergel.eu > >>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Moose-dev mailing list > >>>>>>> Moose-dev(a)iam.unibe.ch > >>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> > >>>>>>> Dr. Hani Abdeen > >>>>>>> Phd. in Software Engineering - RMod, INRIA Lille-Nord Europe > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Moose-dev mailing list > >>>>>>> Moose-dev(a)iam.unibe.ch > >>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >>>>>> > >>>>>> -- > >>>>>> www.tudorgirba.com > >>>>>> > >>>>>> "Every thing should have the right to be different." > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Moose-dev mailing list > >>>>>> Moose-dev(a)iam.unibe.ch > >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> > >>>>> Dr. Hani Abdeen > >>>>> Phd. in Software Engineering - RMod, INRIA Lille-Nord Europe > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Moose-dev mailing list > >>>>> Moose-dev(a)iam.unibe.ch > >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Mariano > >>>> http://marianopeck.wordpress.com > >>>> > >>>> > >>>> _______________________________________________ > >>>> Moose-dev mailing list > >>>> Moose-dev(a)iam.unibe.ch > >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >>>> > >>> > >>> > >>> > >>> -- > >>> www.tudorgirba.com > >>> > >>> "Every thing has its own flow" > >>> > >>> _______________________________________________ > >>> Moose-dev mailing list > >>> Moose-dev(a)iam.unibe.ch > >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >> > >> -- > >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >> Alexandre Bergel http://www.bergel.eu > >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> Moose-dev mailing list > >> Moose-dev(a)iam.unibe.ch > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > > > > > -- > > www.tudorgirba.com > > > > "Every thing has its own flow" > > > > _______________________________________________ > > Moose-dev mailing list > > Moose-dev(a)iam.unibe.ch > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > -- Dr. Hani Abdeen Phd. in Software Engineering - RMod, INRIA Lille-Nord Europe _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Mariano http://marianopeck.wordpress.com

2 1

primitivePerform (prim 83)
by Stefan Marr 12 Dec '11

12 Dec '11

Hi: From the current implementation, which I find in the interpreter, and from testing on Cog I assume that primitive 83, that is 'perform:', does easily handle an arbitrary number of parameters. Is that correct, or does for instance Cog do something else? (it does not seem so) I am just asking, because the number of parameters of the Object>>#perform:with: variants goes only up to three. And, the comment does not mention it. (at least in a recent Pharo image) Furthermore, I guess, there is an upper limit on the number of arguments with regard to frame size? Thanks Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

3 7

new VMs available at...
by Eliot Miranda 12 Dec '11

12 Dec '11

http://www.mirandabanda.org/files/Cog/VM/VM.r2519 Change the VM argument access back to be consistent with linux: CogVM binaries as per VMMaker.oscog-eem.139/r2519. 0 => executable name -1 .. -n => VM arguments *including* image (if explicitly supplied). Provide standard i/o console access on Windows. -- best, Eliot

3 3

Git help for Ben?
by Mariano Martinez Peck 11 Dec '11

11 Dec '11

Hi guys. Ben asked something in a comment in my blog but I have no idea :( http://marianopeck.wordpress.com/2011/04/10/building-the-vm-from-scratch-us… If someone does, please help. Thanks -- Mariano http://marianopeck.wordpress.com

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev December 2011