May 2009 - Pharo-dev - lists.pharo.org

[Pharo-project] Sensor fix again does not work

by StÃ©phane Ducasse

if you want to try load the following cs Stef

May 1, 2009

Re: [Pharo-project] run all tests from superClass

by StÃ©phane Ducasse

I agree more or less :) Now with traits we just compose kind of first class protocols and the result is quite natural. stef On May 1, 2009, at 12:37 AM, Hernan Wilkinson wrote: > My mind keep thinking about this and I realized that the problem > with reusing sunit test cases is more a tool related problem. I > mean, nothing stop us from doing something like this: > ------- > TestCase subclass: #EnumerationTest > instanceVariableNames: 'collection' > etc. > > EnumerationTest>>testDo > > collection do: [ :x | self assert: what ever has to be > tested.... ]. > > EnumerationTest>>testSelect > > collection select: [ what ever has to be tested ... ] > > EnumerationTest>>collection: aCollection > > collection := aCollection. > ----- > Then if you want to run it with an array, we can do something like > this: > > EnumerationTest buildSuite > tests do: [ :aTest | aTest collection: #(1 2 3) ]; > run. > > or with a OrderedCollection > > EnumerationTest buildSuite > tests do: [ :aTest | aTest collection: (OrderedCollection with: > 1 ....) ]; > run. > > etc. > The problem with this is that the test runner assumes that test > cases are made up from subclasses of TestCase, a really bad > coupling... so, if we want to keep running test from the test > runner, we can: > 1) Create a test case per collection type and create a test method > per test method in EnumerationTest... > TestCase subclass: #ArrayTest > ArrayTest>> testDo > (EnumerationTest selector: #testDo) collection: #(1 2 3); run. > etc. a really ugly thing > 2) Redefine testSelectors in ArrayTest, OrderedCollectionTest to do > something like this: > testSelectors > ^EnumerationTest testSelectors > buildSuiteFromLocalSelectors > ^(super buildSuiteFromLocalSelectors) > tests do: [ :aTest | aTest collection: ... ] > 3) Or just open the test runner with a suite... something like: > > TestRunner open runSuite; ( EnumerationTest buildSuite > tests do: [ :aTest | aTest collection: #(1 2 3) ]; yourself) > > > Anyway, I think the problem of reusing tests with SUnit is more > related with the tools we use to run the tests and not with the > TestCase hierarchy, although it is not straightforward to reuse > tests with it. > > Bye, > Hernan > > On Thu, Apr 30, 2009 at 9:56 AM, Hernan Wilkinson <hernan.wilkinson(a)gmail.com > > wrote: > > What I read here indicates you prefer maintaining many duplicates of > the test. > And when you realize that one of the test was buggy (not the method > that is tested, but the test itself), you certainly prefer to track > all the copies and probably leave a buggy one here and there... > > nop nop... that was not my intention. If there is "duplicate code", > then it should be reified. > Traits is an option and we did that with Acciaressi and Butarelli > thesis (same problem). > Another option is just normal delegation. > > Bye, > Hernan > > > > Rethorical debates are fine, but it would be more enlightning to > discuss around some chosen examples. > > Nicolas > > 2009/4/30 Miguel Enrique CobÃ¡ MartÃnez <miguel.coba(a)gmail.com>: > > Hernan Wilkinson wrote: > >> I don't think it is a good idea to have hierarchies with test > cases... > >> depending on how you are doing it, it could couple the test > hierarchy > >> with the model hierarchy and I don't think that is a good idea... > >> It also introduces some complexity, for example the number of > tests are > >> not only the test methods but for each concrete test class, the > test > >> methods on it plus the test methods of the abstract > superclasses... hmmm > >> I don't know, it is not natural at least for me too user > inheritance > >> with tests... > > > > +1 > > Besides, one of the goals of the testing is to test "external > behavior" > > of the classes. > > This means, to me, that the test cases must test the classes without > > knowing if B inherits from A o if both B and C are subclasses of A. > > This way, when you for some reason must refactor or reorganize your > > classes, the test will not break as long as the external behavior of > > them remains unchanged. > > > > Summary, the inheritance of the classes tested is just an > implementation > > detail, not something the test cases must care of. > > > > Cheers, > > Miguel CobÃ¡ > >> > >> On Wed, Apr 29, 2009 at 4:46 PM, StÃ©phane Ducasse > >> <stephane.ducasse(a)inria.fr <mailto:stephane.ducasse@inria.fr>> > wrote: > >> > >> HI guys > >> > >> I was coding this afternoon with Cyrille who is working a lot > to > >> improve the test coverage of collections. > >> And we found a bit strange that when a testcase inherits from > another > >> one the tests of the superclass are not run. > >> I checked a bit SUnit code and superclass testmethods are > only run is > >> the superclass is abstract or if there are not testmethods. > >> Imagine > >> BagTest > >> IdentityBagTest > >> > >> > >> We could redefine buildSuite on BagTest to invoke allSelectors > >> but this means in essence that we could do it on a lot of > potential > >> testcase classes that may be subclasses. > >> > >> Or we could redefine buildSuite on IdentyBagTest but this > means that > >> the subclasses should specify it. > >> May be this solution is the best but I wanted to get your > thoughts. > >> > >> Of course this idea of inheriting test case make sense when > superclass > >> setup can be reused in subclasses one. > >> So the default behavior of buildSuite always invoking all > testmethods > >> may not be so good but then > >> via subclassing from BagTest if this is not to reuse it. > >> > >> Stef > >> > >> > >> On Apr 29, 2009, at 6:04 PM, Cyrille Delaunay wrote: > >> > >> > A change have been saved in 'PharoInBox' for class > TestCase in > >> > package SUnit > >> > so that suite are now built from allSelectors. > >> > This makes sense when you have testcase classes which > inherits from > >> > each other and have parametrized (hook-based) setup. > >> > > >> > > >> > _______________________________________________ > >> > Pharo-project mailing list > >> > Pharo-project(a)lists.gforge.inria.fr > >> <mailto:Pharo-project@lists.gforge.inria.fr> > >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > > >> > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> <mailto:Pharo-project@lists.gforge.inria.fr> > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> > >> > >> > ------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 1, 2009

[Pharo-project] Closure update from eliot

by StÃ©phane Ducasse

Begin forwarded message: > From: Eliot Miranda <eliot.miranda(a)gmail.com> > Date: May 1, 2009 1:34:25 AM CEDT > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Cc: nicolas cellier <ncellier(a)ifrance.com>, Lukas Renggli <renggli(a)iam.unibe.ch > > > Subject: Re: latest Pharo image? > > Hi Stef, Hi All, > > got it; thanks. First thing I want to suggest is the following: > > Smalltalk compactClassesArray > {CompiledMethod . MethodProperties . Array . PseudoContext . > LargePositiveInteger . Float . MethodDictionary . Association . > Point . Rectangle . ByteString . AnObsoleteTranslatedMethod . > BlockContext . MethodContext . nil . Bitmap . nil . nil . nil . > nil . nil . nil . nil . nil . nil . nil . nil . nil . nil . nil . nil} > > The StackVM and CogVM have updated this for speed. So make it look > like > #(CompiledMethod MethodProperties Array LargeNegativeInteger > LargePositiveInteger Float MethodDictionary Association Point > Rectangle ByteString BlockClosure BlockContext MethodContext nil > Bitmap nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil) > > i.e. replace PseudoContext with LargeNegativeInteger, > AnObsoleteTranslatedMethod with BlockClosure. This will poise Pharo > for use of the StackVM when it is released. > > On Thu, Apr 30, 2009 at 12:42 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > > wrote: > You can find it at > > http://gforge.inria.fr/frs/?group_id=1299 > then you should take the pharo and not pharo-dev > then you should do update (in system -> software update) > > Stef > > > On Apr 30, 2009, at 12:21 AM, Eliot Miranda wrote: > > This reminds me to ask you for a location from which to download the > latest Pharo image ith closures so I can check the compiler changes > I've made against the image and send you them. This will be easier > and less error-prone than my e.g. extracting the packages we use > here and you having to work out the changes. > > > mmm latest pharo image > > [1 == 0] forkAt: 999. > > oops.. > > >

May 1, 2009

[Pharo-project] Closure update from eliot

by StÃ©phane Ducasse

Begin forwarded message: > From: Eliot Miranda <eliot.miranda(a)gmail.com> > Date: May 1, 2009 3:23:48 AM CEDT > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Cc: nicolas cellier <ncellier(a)ifrance.com>, Lukas Renggli <renggli(a)iam.unibe.ch > > > Subject: Re: latest Pharo image? > > One thing I recommend you do is to rip out the old closure compiler > stuff. e.g. CompiledMethod>>embeddedBlockMethods. > What I'm doing now is a merge that pulls in the important bug fixes. > > Things I'll try and do (or work with you) later are > > - ripping out MethodProperties and using the penultimate literal to > hold either the selector or an AdditionalMethodState, which is a > pragma-friendly replacement for MethodProperties. Doing this saves > a lot of space. > > - adding a primitive error code so you can write > fooPrimitive > <primitive: 'myprim' module: 'mymodule' error: errorCode> > errorCode == #'bad receiver' ifTrue: ... > > - remove all the old closure compiler stuff. > > > On Thu, Apr 30, 2009 at 12:42 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > > wrote: > You can find it at > > http://gforge.inria.fr/frs/?group_id=1299 > then you should take the pharo and not pharo-dev > then you should do update (in system -> software update) > > Stef > > > On Apr 30, 2009, at 12:21 AM, Eliot Miranda wrote: > > This reminds me to ask you for a location from which to download the > latest Pharo image ith closures so I can check the compiler changes > I've made against the image and send you them. This will be easier > and less error-prone than my e.g. extracting the packages we use > here and you having to work out the changes. > > > mmm latest pharo image > > [1 == 0] forkAt: 999. > > oops.. > > >

May 1, 2009

[Pharo-project] Fwd: latest Pharo image?

by StÃ©phane Ducasse

Begin forwarded message: > From: Eliot Miranda <eliot.miranda(a)gmail.com> > Date: May 1, 2009 1:50:55 AM CEDT > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Cc: nicolas cellier <ncellier(a)ifrance.com>, Lukas Renggli <renggli(a)iam.unibe.ch > > > Subject: Re: latest Pharo image? > > the attached sorts class variables and shared pools in Monticello > class defs and results in fewer conflicts being reported. > > On Thu, Apr 30, 2009 at 12:42 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > > wrote: > You can find it at > > http://gforge.inria.fr/frs/?group_id=1299 > then you should take the pharo and not pharo-dev > then you should do update (in system -> software update) > > Stef > > > On Apr 30, 2009, at 12:21 AM, Eliot Miranda wrote: > > This reminds me to ask you for a location from which to download the > latest Pharo image ith closures so I can check the compiler changes > I've made against the image and send you them. This will be easier > and less error-prone than my e.g. extracting the packages we use > here and you having to work out the changes. > > > mmm latest pharo image > > [1 == 0] forkAt: 999. > > oops.. > > >

May 1, 2009

[Pharo-project] Fwd: latest Pharo image?

by StÃ©phane Ducasse

Begin forwarded message: > From: Eliot Miranda <eliot.miranda(a)gmail.com> > Date: May 1, 2009 1:34:25 AM CEDT > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Cc: nicolas cellier <ncellier(a)ifrance.com>, Lukas Renggli <renggli(a)iam.unibe.ch > > > Subject: Re: latest Pharo image? > > Hi Stef, Hi All, > > got it; thanks. First thing I want to suggest is the following: > > Smalltalk compactClassesArray > {CompiledMethod . MethodProperties . Array . PseudoContext . > LargePositiveInteger . Float . MethodDictionary . Association . > Point . Rectangle . ByteString . AnObsoleteTranslatedMethod . > BlockContext . MethodContext . nil . Bitmap . nil . nil . nil . > nil . nil . nil . nil . nil . nil . nil . nil . nil . nil . nil . nil} > > The StackVM and CogVM have updated this for speed. So make it look > like > #(CompiledMethod MethodProperties Array LargeNegativeInteger > LargePositiveInteger Float MethodDictionary Association Point > Rectangle ByteString BlockClosure BlockContext MethodContext nil > Bitmap nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil) > > i.e. replace PseudoContext with LargeNegativeInteger, > AnObsoleteTranslatedMethod with BlockClosure. This will poise Pharo > for use of the StackVM when it is released. > > On Thu, Apr 30, 2009 at 12:42 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > > wrote: > You can find it at > > http://gforge.inria.fr/frs/?group_id=1299 > then you should take the pharo and not pharo-dev > then you should do update (in system -> software update) > > Stef > > > On Apr 30, 2009, at 12:21 AM, Eliot Miranda wrote: > > This reminds me to ask you for a location from which to download the > latest Pharo image ith closures so I can check the compiler changes > I've made against the image and send you them. This will be easier > and less error-prone than my e.g. extracting the packages we use > here and you having to work out the changes. > > > mmm latest pharo image > > [1 == 0] forkAt: 999. > > oops.. > > >

May 1, 2009

Re: [Pharo-project] Monticello/ftp stopped working for me

by Nicolas Cellier

Hmm... I suspect my linux /proc has been foolished for some reason and it was in fact some sockets... I tried again, during loading, the socket opened and close and were recognized as such in /proc, but after a certain point, listing /proc/$pid/fd was reporting change log open and close... though the loading did continue normally. I will try the whole procedure again, but all this is really slow (I had some other traffic going on my limited bandwith). Nicolas 2009/5/1 John M McIntosh <johnmci(a)smalltalkconsulting.com>: > Well yes, and the magic check would be > > FileStream allSubInstances size inspect > > same place as the socket. > > Nothing of course finalization is involved in getting rid of zombie > file handles too. > > And Dave is right you should only have one file handle open (read/ > write) for *.changes > > > On 30-Apr-09, at 4:30 PM, David T. Lewis wrote: > >> Well that's a bug for sure. Somebody is opening new file streams on >> the changes file, probably by accident. And not closing the one they >> opened last time. >> >> The bug in changes file handling could easily appear to be a socket >> problem, because the per-process limit on open descriptors would be >> shared between files and sockets (and pipes and ...). So find out >> why the changes file is being accidentally reopened, and the "socket >> problem" will probably go away. >> >> Dave > > -- > = > = > = > ======================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > = > = > = > ======================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 1, 2009

Re: [Pharo-project] Monticello/ftp stopped working for me

by John M McIntosh

The Unix ipv6 logic translates the lookup error number into a string and prints to the console. If the name is "" an empty string, then yes it's EAI_NONAME see man 3 gai_strerror GAI_STRERROR(3) BSD Library Functions Manual GAI_STRERROR(3) NAME gai_strerror -- get error message string from EAI_xxx error code SYNOPSIS #include <sys/types.h> #include <sys/socket.h> #include <netdb.h> const char * gai_strerror(int ecode); DESCRIPTION The gai_strerror() function returns an error message string corresponding to the error code returned by getaddrinfo(3) or getnameinfo(3). The following error codes and their meaning are defined in <netdb.h>: EAI_AGAIN temporary failure in name resolution EAI_BADFLAGS invalid value for ai_flags EAI_BADHINTS invalid value for hints EAI_FAIL non-recoverable failure in name resolution EAI_FAMILY ai_family not supported EAI_MEMORY memory allocation failure EAI_NONAME hostname or servname not provided, or not known EAI_PROTOCOL resolved protocol is unknown EAI_SERVICE servname not supported for ai_socktype EAI_SOCKTYPE ai_socktype not supported EAI_SYSTEM system error returned in errno On 30-Apr-09, at 10:27 PM, Alexandre Bergel wrote: > On a 293/OSX, I get a primitive failed. > When (HTTPSocket>>httpGetDocument: url args: args accept: mimeType > request: requestString) > calls > (NetNameResolver addressForName: connectToHost timeout: 20.) > > connectToHost = '', which makes the primitive fail. > > Alexandre > > > On 1 May 2009, at 00:11, Nicolas Cellier wrote: > >> With a simpler command, I reproduced the MC failure, but not the >> bunch >> of opened change log: >> >> 1) ScriptLoader new installingInstaller >> 2) Installer lukas install: 'OB-Regex'. >> >> I get this interesting message on the XTerm console: >> >> getaddrinfo: Name or service not known -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

May 1, 2009

Re: [Pharo-project] Monticello/ftp stopped working for me

by Alexandre Bergel

On a 293/OSX, I get a primitive failed. When (HTTPSocket>>httpGetDocument: url args: args accept: mimeType request: requestString) calls (NetNameResolver addressForName: connectToHost timeout: 20.) connectToHost = '', which makes the primitive fail. Alexandre On 1 May 2009, at 00:11, Nicolas Cellier wrote: > With a simpler command, I reproduced the MC failure, but not the bunch > of opened change log: > > 1) ScriptLoader new installingInstaller > 2) Installer lukas install: 'OB-Regex'. > > I get this interesting message on the XTerm console: > > getaddrinfo: Name or service not known > > > 2009/4/30 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> Very strange... >> After a while on linux, I have an error in >> MCHttpRepository>>#allFileNames >> >> 'Could not resolve the server named: source.lukas-renggli.ch' >> >> while executing: >> >> instClass lukas >> install: 'OB-Regex'; >> >> the 6 opened fd turned into many ... all pointing to the change file >> Pharo0.1Core-10281cl.changes >> >> ls -l /proc/7932/fd | wc -l >> 577 >> >> ls -l /proc/7932/fd | sort -n -k 8 | head -20 | grep -v '^total' >> lrwx------ 1 nicolas parents 64 2009-04-30 23:03 0 -> /dev/pts/3 >> lrwx------ 1 nicolas parents 64 2009-04-30 23:03 1 -> /dev/pts/3 >> lrwx------ 1 nicolas parents 64 2009-04-30 23:03 2 -> /dev/pts/3 >> lrwx------ 1 nicolas parents 64 2009-04-30 23:03 3 -> socket:[19987] >> lr-x------ 1 nicolas parents 64 2009-04-30 23:03 4 -> >> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/package-cache/ >> lr-x------ 1 nicolas parents 64 2009-04-30 23:03 5 -> >> /windata/Smalltalk/Squeak/SqueakV39.sources* >> lrwx------ 1 nicolas parents 64 2009-04-30 23:03 6 -> >> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/ >> Pharo0.1Core-10281cl.changes* >> lr-x------ 1 nicolas parents 64 2009-04-30 23:03 7 -> >> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/ >> Pharo0.1Core-10281cl.changes* >> lr-x------ 1 nicolas parents 64 2009-04-30 23:03 8 -> >> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/ >> Pharo0.1Core-10281cl.changes* >> lr-x------ 1 nicolas parents 64 2009-04-30 23:03 9 -> >> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/ >> Pharo0.1Core-10281cl.changes* >> lr-x------ 1 nicolas parents 64 2009-04-30 23:03 10 -> >> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/ >> Pharo0.1Core-10281cl.changes* >> lr-x------ 1 nicolas parents 64 2009-04-30 23:03 11 -> >> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/ >> Pharo0.1Core-10281cl.changes* >> lr-x------ 1 nicolas parents 64 2009-04-30 23:03 12 -> >> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/ >> Pharo0.1Core-10281cl.changes* >> lr-x------ 1 nicolas parents 64 2009-04-30 23:03 13 -> >> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/ >> Pharo0.1Core-10281cl.changes* >> lr-x------ 1 nicolas parents 64 2009-04-30 23:03 14 -> >> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/ >> Pharo0.1Core-10281cl.changes* >> lr-x------ 1 nicolas parents 64 2009-04-30 23:03 15 -> >> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/ >> Pharo0.1Core-10281cl.changes* >> lr-x------ 1 nicolas parents 64 2009-04-30 23:03 16 -> >> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/ >> Pharo0.1Core-10281cl.changes* >> lr-x------ 1 nicolas parents 64 2009-04-30 23:03 17 -> >> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/ >> Pharo0.1Core-10281cl.changes* >> lr-x------ 1 nicolas parents 64 2009-04-30 23:03 18 -> >> /windata/Smalltalk/Squeak/pharo0.1-10268dev09.04.1/ >> Pharo0.1Core-10281cl.changes* >> etc... >> >> Trying to restart, i have >> serverAdress 84.75.162.243(84-75-162-243.dclient.hispeed.ch),0(0) >> which I cannot ping outside squeak... >> So maybe squeak has correct diagnostic, but why all these opened >> change logs ? >> >> Nicolas >> >> 2009/4/30 John M McIntosh <johnmci(a)smalltalkconsulting.com>: >>> So is that in the exception block before you get the walkback on the >>> socket allocation failure? >>> >>> On 30-Apr-09, at 8:45 AM, Cameron Sanders wrote: >>> >>>> Well, "Socket allInstances size inspect" is giving me numbers >>>> like 8, >>>> 6, or 2 from the "ScriptLoader loadOBAlpha" do-it. When I look at >>>> the >>>> process on the Mac (with the activity monitor), it says I have >>>> "Ports: >>>> 91". A look at "open files and ports" shows a lengthy list of >>>> filenames/devices that are open, but only about 35 show up. There >>>> are >>>> a few surprises (to me) in the open files list: >>>> >>> >>> -- >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> ==================================================================== >>> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: >>> squeaker68882 >>> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> ==================================================================== >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 1, 2009

Re: [Pharo-project] [Vm-dev] Loading VMMaker into latest Pharo

by David T. Lewis

On Thu, Apr 30, 2009 at 06:43:00PM +0300, Igor Stasenko wrote: > > There are multiple issues, when loading VMMaker into closure-aware > image (10292). > > two #needsToRegenerateInterpreterFile methods > storing into block args. Fix is easy and quick. The easy and quick fix is in VMMaker-dtl.121 on SqS. Dave

May 1, 2009