January 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] Does someone know why Nile is in Dev images?

by Mariano Martinez Peck

Does another package of the dev image depends on Nile? If not, I don't understand why it is part of the dev image. I see it as any other external package but not a "dev tool" that should be included. Thanks Mariano

Jan. 3, 2010

Re: [Pharo-project] Can't debug in 1.1

by Levente Uzonyi

On Sat, 2 Jan 2010, Schwab,Wilhelm K wrote: > Eliot, > > Squeak's weak collections are, weak, in more ways than one. They are not thread safe, and not clean up after finalization, which is of course how they get away without thread safety. See "Thread-safe collections" starting on 23 Oct from this list. I will post, as a separate message with attachment, something that I **threw together** to try to address some of the missing features. I have not had time to test it separately from the rest of my image, so please start slowly and let me know if you have any problems. All collections are intentionally not thread-safe (except SharedQueue and WeakRegistry). All weak collections clean up themselves in a lazy fashion. I think there's no way to ensure that garbage collected objects are immediately removed from weak collections without vm changes. Levente > > Bill > > > > ________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Eliot Miranda > Sent: Saturday, January 02, 2010 6:08 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Can't debug in 1.1 > > > > On Thu, Dec 31, 2009 at 2:33 AM, Marcus Denker <marcus.denker(a)inria.fr<mailto:marcus.denker@inria.fr>> wrote: > > On Dec 31, 2009, at 9:50 AM, StÃ©phane Ducasse wrote: > >> Probably the changes of Martin von Lowis. > > Yes. The changeset had code to migrate all instances... it might be that the debugger's use > of WeakKeyDictionary was added by Eliot? This would explain why it was not migrated. > > Yes, DebuggerMethodMap is mine. A DebuggerMethodMap maps between the vector of temp names in the lower right-hand debugger window and temp locations in method activations. This is much more complex using closures tan blue-book blocks since in-scope temps are spread from a closure through its nested closures out to the home method. The cache holds the maps for the most recent N methods inspected with the debugger (N=16). The cache is weak so as not to hold onto methods that get deleted or redefined. > > As far as registering the cache for finalization or not, I would defer to someone familiar with Squeak weak collections. I think I'm right in thinking that in VW a weak dictionary will be automatically finalized and will keep its tally correct. One only needs to register for finalization if something needs to happen besides simply removing elements. So when I implemented this in Squeak I could easily have got things wrong. > > > I suggest to just do the reset in a postscript in one of the next updates, and it's fixed. > > >> I imagine that when marcus is bad from holidays he can tell us more. >> > > I'm back... kind of. Decided not to travel to south germany this morning after moving boxes > for 3 days... better to have an IKEA-unboxing-relaxing-reading-emails-hacking-weekend. > > Marcus > > > >> Now I try to reproduce it in 11128. >> >> I put a self halt in a method and execute the method. >> And I got no problem. >> After I tried to select 'self halt' + doit in the debugger itself and it worked too. >> >> Did you have a way reproduce it systematically ? >> >> Stef >> On Dec 31, 2009, at 4:17 AM, Martin McClure wrote: >> >>> This one's pretty nasty. >>> >>> Symptom: >>> >>> The debugger in recent and current 1.1 images is completely broken. >>> >>> To reproduce (save your image first!): >>> >>> "self halt" doit. It goes into an infinite loop, and if there's a way to >>> get out of that without killing the VM I'd like to know about it. Alt-. >>> works, but just tries to open another debugger, which goes into another >>> infinite loop, etc. >>> >>> >>> >>> Cause: >>> >>> DebuggerMethodMap>MapCache is a WeakIdentityKeyDictionary, but it is >>> corrupt. It has an array of 22 nils, expired is 0, so it contains >>> nothing, but tally=16. >>> >>> This causes MapCache to lie about its size. >>> >>> This drives DebuggerMethodMap class>>cacheDebugMap:forMethod: into an >>> infinite loop, the whileTrue: condition is always true, it keeps trying >>> to remove non-existent elements to get the size to be less than 16 but >>> the size is always 16. >>> >>> I don't see any obvious code paths to get into this state. I suspect it >>> may have been left in this state when weak collections were updated with >>> the new code not too long ago. >>> >>> >>> Cure: >>> >>> In an inspector, set tally=0. Debuggers then work again. >>> >>> Not sure how to package this as a slice, so I'll leave the update to >>> someone else, and get back to hashing, which was hard when every >>> walkback froze my system :-) >>> >>> >>> Regards, >>> >>> -Martin >>> >>> _______________________________________________ >>> 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<mailto:Pharo-project@lists.gforge.inria.fr> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >

Jan. 3, 2010

Re: [Pharo-project] Pharo testers.... WE NEED YOU!!!

by Schwab,Wilhelm K

Mariano, I noted your(??) comment about how some people will have significant work to build a new image. I somewhat fall into that category, and *really* fell into it as soon as I ported a few of my big packages to Pharo. Three things that I found missing were: (1) a way to identify work that I had failed to package; (2) a clean way to save large numbers of packages in one step; (3) a clean way to load a lot of code into a new image. By no means complete or perfect, I ended up with a "port" of a Dolphin goodie of mine I call Migrate. The intent is that users would sub-class it it to describe their packages. The recent move toward Gofer will probably have some impact on it, and a larger problem is that I need to clean up comments that contain things I do not want to make public. I mentioned this a while back and the response was underwhelming, but it is probably worth another mention, especially since there does not appear to be a magic solution to the problem. If there were, you would advising testers about how easy it will be for them to make a new image, right? :) The basic idea of Migrate is to iteratively extend your own #homeGrownPackageNames list until the suspect methods report is clean, or least understandable and ignorable. At that point, it is (in my experience) easy to save packages and make them available for a new image. Load Migrate and your subclass into the new image, and ask it to load packages. I would be happy to clean it up and make it available if there is any interest. A relevant class comment appears below. Bill CONFIGURE ========= Configure it using #homeGrownPackageNames and #me to tell it which packages are intended to hold your work, and how to identify you from the (misnomer!!!) #timeStamp aspects of the compiled methods you produce. SAVE YOUR WORK ============== Use #suspectMethodsReport to produce a listing of class>>selector names that might be in danger of being orphaned in your current image. Use #homeGrownPackgesSaveWithMessage: to save all of the identified home grown packages in the next version and with the common text message. BUILD A NEW IMAGE ================= Load Migrate into a new image. It wants underscore_madness.cs, and loads SIXX and other packages of interest to me; you can edit as needed to remove what you do not want to load. Put your packages in the cache directory for the new image. Yes, it is fussy about these things, but the idea is to find errors early rather than being stopped after a long wait. Likewise, if you do not like what #setPreferences does, edit it. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck [marianopeck(a)gmail.com] Sent: Saturday, January 02, 2010 8:39 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Pharo testers.... WE NEED YOU!!! Cool....we are already 13 beta testers :) More than enought :) I updated http://code.google.com/p/pharo/w/list And we almost cover all the conbinations of OS, Browser and type of image :) Cheers Mariano On Sat, Jan 2, 2010 at 2:30 PM, Mariano Martinez Peck <marianopeck(a)gmail.com<mailto:marianopeck@gmail.com>> wrote: On Sat, Jan 2, 2010 at 1:50 AM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com<mailto:hernan.morales@gmail.com>> wrote: Hi Mariano, I don't use dev or web images. I've found the PharoCore more stable, for example now I'm fixing a dependency browser bug in the dev image #10502 (trying a dev after a long time), and clicking with the right button gives me : MessageNotUnderstood: OBTextSelection>>isMethodNode Yes, this is issue: http://code.google.com/p/pharo/issues/detail?id=1182 but isn't just that bug, I've never worked 30 minutes with the dev/web images without interaction bugs. I wonder what happens with Smalltalk and Pharo newcomers when these bugs appears, but there's no survey system for Pharo users so no one can't figure out anyway. Well, fortunately there are no too many public word of mouth recommendation systems yet :) HernÃ¡n: I agreee 100%. All of what you describe is what I said in the email with subject "We need to do something, seriously, ..." And that's exactly what I proposed to do this stuff about the beta testers. Cheers Mariano Cheers, HernÃ¡n 2010/1/1 Mariano Martinez Peck <marianopeck(a)gmail.com<mailto:marianopeck@gmail.com>>: > Sorry, I realize something. Maybe it would be cool also if you tell us if > you use web or dev. I happens also several times that the seaside > installation, or pier or whatever are not working very well. So...it would > be cool to have both testers :) > > If you have access to the wiki, just add your self on it. If you don't have > access ask to Adrian and he will give you. Finally you can put it here and > then I put it in the wiki. > > Cheers! > > Mariano > > On Fri, Jan 1, 2010 at 10:56 PM, Mariano Martinez Peck > <marianopeck(a)gmail.com<mailto:marianopeck@gmail.com>> wrote: >> >> Ok.....I collect all the information here: >> >> http://code.google.com/p/pharo/wiki/ListOfBetaTesters >> >> Feel free to add something else. >> >> The only thing we need now is Damien's answer...maybe he is in holidays, I >> don't know. >> >> The last thing I would like to propose is that when we have a new image to >> test, not only we send the email to the mailing list but also cc to each of >> us. There is a lot of traffic (fortunately!!) in Pharo mailing list and not >> all the people here keeps truck for it every day. So, I think having them in >> cc is a good idea. >> >> Cheers, >> >> M >> >> On Fri, Jan 1, 2010 at 12:41 AM, Miguel CobÃ¡ <miguel.coba(a)gmail.com<mailto:miguel.coba@gmail.com>> >> wrote: >>> >>> > So...here is the list, if you offer yourself, it would be cool to know: >>> > OS, >>> > VM version, Dev or Web, browser you usually work, 32 o 64 bits, >>> > I will then collect this and I will put it in the wiki. >>> > >>> > - Mariano Martinez Peck. Mac OS, Squeak 4.2.2beta1U.app, Dev, OB, 32 >>> > bits >>> > - Stan Shepherd >>> > >>> > >>> > WHO ELSE IS IN THE LIST ?? >>> >>> Me too. >>> >>> - Miguel CobÃ¡, Debian GNU/Linux Squeeze (testing), Pharo0.1 of 16 May >>> 2008 [latest update: #10074], Web, OB, 32 bits >>> >>> >>> > >>> > cheers and happy new year!! >>> > >>> >>> Feliz aÃ±o tambiÃ©n Mariano. >>> >>> Miguel CobÃ¡ >>> http://miguel.leugim.com.mx >>> >>> _______________________________________________ >>> 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<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 3, 2010

Re: [Pharo-project] Can't debug in 1.1

by Schwab,Wilhelm K

Eliot, The promised code. Again, this is not groomed for release, but you are welcome to use/improve as you see fit. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu] Sent: Saturday, January 02, 2010 6:57 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Can't debug in 1.1 Eliot, Squeak's weak collections are, weak, in more ways than one. They are not thread safe, and not clean up after finalization, which is of course how they get away without thread safety. See "Thread-safe collections" starting on 23 Oct from this list. I will post, as a separate message with attachment, something that I **threw together** to try to address some of the missing features. I have not had time to test it separately from the rest of my image, so please start slowly and let me know if you have any problems. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Eliot Miranda Sent: Saturday, January 02, 2010 6:08 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Can't debug in 1.1 On Thu, Dec 31, 2009 at 2:33 AM, Marcus Denker <marcus.denker(a)inria.fr<mailto:marcus.denker@inria.fr>> wrote: On Dec 31, 2009, at 9:50 AM, StÃ©phane Ducasse wrote: > Probably the changes of Martin von Lowis. Yes. The changeset had code to migrate all instances... it might be that the debugger's use of WeakKeyDictionary was added by Eliot? This would explain why it was not migrated. Yes, DebuggerMethodMap is mine. A DebuggerMethodMap maps between the vector of temp names in the lower right-hand debugger window and temp locations in method activations. This is much more complex using closures tan blue-book blocks since in-scope temps are spread from a closure through its nested closures out to the home method. The cache holds the maps for the most recent N methods inspected with the debugger (N=16). The cache is weak so as not to hold onto methods that get deleted or redefined. As far as registering the cache for finalization or not, I would defer to someone familiar with Squeak weak collections. I think I'm right in thinking that in VW a weak dictionary will be automatically finalized and will keep its tally correct. One only needs to register for finalization if something needs to happen besides simply removing elements. So when I implemented this in Squeak I could easily have got things wrong. I suggest to just do the reset in a postscript in one of the next updates, and it's fixed. > I imagine that when marcus is bad from holidays he can tell us more. > I'm back... kind of. Decided not to travel to south germany this morning after moving boxes for 3 days... better to have an IKEA-unboxing-relaxing-reading-emails-hacking-weekend. Marcus > Now I try to reproduce it in 11128. > > I put a self halt in a method and execute the method. > And I got no problem. > After I tried to select 'self halt' + doit in the debugger itself and it worked too. > > Did you have a way reproduce it systematically ? > > Stef > On Dec 31, 2009, at 4:17 AM, Martin McClure wrote: > >> This one's pretty nasty. >> >> Symptom: >> >> The debugger in recent and current 1.1 images is completely broken. >> >> To reproduce (save your image first!): >> >> "self halt" doit. It goes into an infinite loop, and if there's a way to >> get out of that without killing the VM I'd like to know about it. Alt-. >> works, but just tries to open another debugger, which goes into another >> infinite loop, etc. >> >> >> >> Cause: >> >> DebuggerMethodMap>MapCache is a WeakIdentityKeyDictionary, but it is >> corrupt. It has an array of 22 nils, expired is 0, so it contains >> nothing, but tally=16. >> >> This causes MapCache to lie about its size. >> >> This drives DebuggerMethodMap class>>cacheDebugMap:forMethod: into an >> infinite loop, the whileTrue: condition is always true, it keeps trying >> to remove non-existent elements to get the size to be less than 16 but >> the size is always 16. >> >> I don't see any obvious code paths to get into this state. I suspect it >> may have been left in this state when weak collections were updated with >> the new code not too long ago. >> >> >> Cure: >> >> In an inspector, set tally=0. Debuggers then work again. >> >> Not sure how to package this as a slice, so I'll leave the update to >> someone else, and get back to hashing, which was hard when every >> walkback froze my system :-) >> >> >> Regards, >> >> -Martin >> >> _______________________________________________ >> 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<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 2, 2010

Re: [Pharo-project] Can't debug in 1.1

by Schwab,Wilhelm K

Eliot, Squeak's weak collections are, weak, in more ways than one. They are not thread safe, and not clean up after finalization, which is of course how they get away without thread safety. See "Thread-safe collections" starting on 23 Oct from this list. I will post, as a separate message with attachment, something that I **threw together** to try to address some of the missing features. I have not had time to test it separately from the rest of my image, so please start slowly and let me know if you have any problems. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Eliot Miranda Sent: Saturday, January 02, 2010 6:08 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Can't debug in 1.1 On Thu, Dec 31, 2009 at 2:33 AM, Marcus Denker <marcus.denker(a)inria.fr<mailto:marcus.denker@inria.fr>> wrote: On Dec 31, 2009, at 9:50 AM, StÃ©phane Ducasse wrote: > Probably the changes of Martin von Lowis. Yes. The changeset had code to migrate all instances... it might be that the debugger's use of WeakKeyDictionary was added by Eliot? This would explain why it was not migrated. Yes, DebuggerMethodMap is mine. A DebuggerMethodMap maps between the vector of temp names in the lower right-hand debugger window and temp locations in method activations. This is much more complex using closures tan blue-book blocks since in-scope temps are spread from a closure through its nested closures out to the home method. The cache holds the maps for the most recent N methods inspected with the debugger (N=16). The cache is weak so as not to hold onto methods that get deleted or redefined. As far as registering the cache for finalization or not, I would defer to someone familiar with Squeak weak collections. I think I'm right in thinking that in VW a weak dictionary will be automatically finalized and will keep its tally correct. One only needs to register for finalization if something needs to happen besides simply removing elements. So when I implemented this in Squeak I could easily have got things wrong. I suggest to just do the reset in a postscript in one of the next updates, and it's fixed. > I imagine that when marcus is bad from holidays he can tell us more. > I'm back... kind of. Decided not to travel to south germany this morning after moving boxes for 3 days... better to have an IKEA-unboxing-relaxing-reading-emails-hacking-weekend. Marcus > Now I try to reproduce it in 11128. > > I put a self halt in a method and execute the method. > And I got no problem. > After I tried to select 'self halt' + doit in the debugger itself and it worked too. > > Did you have a way reproduce it systematically ? > > Stef > On Dec 31, 2009, at 4:17 AM, Martin McClure wrote: > >> This one's pretty nasty. >> >> Symptom: >> >> The debugger in recent and current 1.1 images is completely broken. >> >> To reproduce (save your image first!): >> >> "self halt" doit. It goes into an infinite loop, and if there's a way to >> get out of that without killing the VM I'd like to know about it. Alt-. >> works, but just tries to open another debugger, which goes into another >> infinite loop, etc. >> >> >> >> Cause: >> >> DebuggerMethodMap>MapCache is a WeakIdentityKeyDictionary, but it is >> corrupt. It has an array of 22 nils, expired is 0, so it contains >> nothing, but tally=16. >> >> This causes MapCache to lie about its size. >> >> This drives DebuggerMethodMap class>>cacheDebugMap:forMethod: into an >> infinite loop, the whileTrue: condition is always true, it keeps trying >> to remove non-existent elements to get the size to be less than 16 but >> the size is always 16. >> >> I don't see any obvious code paths to get into this state. I suspect it >> may have been left in this state when weak collections were updated with >> the new code not too long ago. >> >> >> Cure: >> >> In an inspector, set tally=0. Debuggers then work again. >> >> Not sure how to package this as a slice, so I'll leave the update to >> someone else, and get back to hashing, which was hard when every >> walkback froze my system :-) >> >> >> Regards, >> >> -Martin >> >> _______________________________________________ >> 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<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 2, 2010

[Pharo-project] Code Critics pragmas for classes - do they need to be on instance *and* class side?

by Stan Shepherd

Hi, this one's for Lukas. Where you set Code critics to pragmas- http://n4.nabble.com/Slime-in-one-click-image-tt100493.html#a100498 http://n4.nabble.com/Slime-in-one-click-image-tt100493.html#a100498 It seems only to work when the pragma is on both instance and class side. Is this the intention? Cheers, ...Stan -- View this message in context: http://n2.nabble.com/Code-Critics-pragmas-for-classes-do-they-need-to-be-on… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 2, 2010

Re: [Pharo-project] Can't debug in 1.1

by Eliot Miranda

On Thu, Dec 31, 2009 at 2:33 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On Dec 31, 2009, at 9:50 AM, StÃ©phane Ducasse wrote: > > > Probably the changes of Martin von Lowis. > > Yes. The changeset had code to migrate all instances... it might be that > the debugger's use > of WeakKeyDictionary was added by Eliot? This would explain why it was not > migrated. > Yes, DebuggerMethodMap is mine. A DebuggerMethodMap maps between the vector of temp names in the lower right-hand debugger window and temp locations in method activations. This is much more complex using closures tan blue-book blocks since in-scope temps are spread from a closure through its nested closures out to the home method. The cache holds the maps for the most recent N methods inspected with the debugger (N=16). The cache is weak so as not to hold onto methods that get deleted or redefined. As far as registering the cache for finalization or not, I would defer to someone familiar with Squeak weak collections. I think I'm right in thinking that in VW a weak dictionary will be automatically finalized and will keep its tally correct. One only needs to register for finalization if something needs to happen besides simply removing elements. So when I implemented this in Squeak I could easily have got things wrong. > > I suggest to just do the reset in a postscript in one of the next updates, > and it's fixed. > > > > I imagine that when marcus is bad from holidays he can tell us more. > > > > I'm back... kind of. Decided not to travel to south germany this morning > after moving boxes > for 3 days... better to have an > IKEA-unboxing-relaxing-reading-emails-hacking-weekend. > > Marcus > > > > > Now I try to reproduce it in 11128. > > > > I put a self halt in a method and execute the method. > > And I got no problem. > > After I tried to select 'self halt' + doit in the debugger itself and it > worked too. > > > > Did you have a way reproduce it systematically ? > > > > Stef > > On Dec 31, 2009, at 4:17 AM, Martin McClure wrote: > > > >> This one's pretty nasty. > >> > >> Symptom: > >> > >> The debugger in recent and current 1.1 images is completely broken. > >> > >> To reproduce (save your image first!): > >> > >> "self halt" doit. It goes into an infinite loop, and if there's a way to > >> get out of that without killing the VM I'd like to know about it. Alt-. > >> works, but just tries to open another debugger, which goes into another > >> infinite loop, etc. > >> > >> > >> > >> Cause: > >> > >> DebuggerMethodMap>MapCache is a WeakIdentityKeyDictionary, but it is > >> corrupt. It has an array of 22 nils, expired is 0, so it contains > >> nothing, but tally=16. > >> > >> This causes MapCache to lie about its size. > >> > >> This drives DebuggerMethodMap class>>cacheDebugMap:forMethod: into an > >> infinite loop, the whileTrue: condition is always true, it keeps trying > >> to remove non-existent elements to get the size to be less than 16 but > >> the size is always 16. > >> > >> I don't see any obvious code paths to get into this state. I suspect it > >> may have been left in this state when weak collections were updated with > >> the new code not too long ago. > >> > >> > >> Cure: > >> > >> In an inspector, set tally=0. Debuggers then work again. > >> > >> Not sure how to package this as a slice, so I'll leave the update to > >> someone else, and get back to hashing, which was hard when every > >> walkback froze my system :-) > >> > >> > >> Regards, > >> > >> -Martin > >> > >> _______________________________________________ > >> 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 >

Jan. 2, 2010

Re: [Pharo-project] Error when passing file (without full path) at startup

by John M McIntosh

Hey so what does a V5 VM do? why don't you try with a './' > /Applications/Squeak/Squeak\ 4.2.2beta1U.app/Contents/MacOS/Squeak\ VM\ Opt PharoCore-1.0-10503rc1.1.image ./test.st At 3.8.19b1 I did sqMacMain.c drop cwd to VM directory at startup time to help script writers use ../ or ./ which commented out this /* LETS NOT DO THIS, SEE what happens for people wanting to do ./Squeak.app foobar.image zingger.st { // Change working directory, this works under os-x, previous logic worked pre os-x 10.4 char target[4097],temp[4097]; getVMPathWithEncoding(target,gCurrentVMEncoding); sqFilenameFromStringOpen(temp,(sqInt) target, strlen(target)); chdir(temp); } */ On 2010-01-02, at 2:22 PM, StÃ©phane Ducasse wrote: > Hi > > Can somebody confirm that he gets the same error than me with the following code expression > > /Applications/Squeak/Squeak\ 4.2.2beta1U.app/Contents/MacOS/Squeak\ VM\ Opt PharoCore-1.0-10503rc1.1.image test.st > > where test.st is deadline > > Beeper beep > > > <test.st> > > I get Error: No content to install > > I also get the same error with PharoCore1.1ALPHA Latest update: #11131 > > Now if I use > > /Applications/Squeak/Squeak\ 4.2.2beta1U.app/Contents/MacOS/Squeak\ VM\ Opt PharoCore-1.0-10503rc1.1.image /Users/ducasse/Workspace/FirstCircle/ActiveResearch/Pharo/Pharo/Coral/test.st > > it is working I thought that the passed argument was resolved using the current directory. > John I remember that you change that is it true? > > > Stef_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Jan. 2, 2010

[Pharo-project] Error when passing file (without full path) at startup

by StÃ©phane Ducasse

Hi Can somebody confirm that he gets the same error than me with the following code expression /Applications/Squeak/Squeak\ 4.2.2beta1U.app/Contents/MacOS/Squeak\ VM\ Opt PharoCore-1.0-10503rc1.1.image test.st where test.st is deadline Beeper beep I get Error: No content to install I also get the same error with PharoCore1.1ALPHA Latest update: #11131 Now if I use /Applications/Squeak/Squeak\ 4.2.2beta1U.app/Contents/MacOS/Squeak\ VM\ Opt PharoCore-1.0-10503rc1.1.image /Users/ducasse/Workspace/FirstCircle/ActiveResearch/Pharo/Pharo/Coral/test.st it is working I thought that the passed argument was resolved using the current directory. John I remember that you change that is it true? Stef

Jan. 2, 2010

Re: [Pharo-project] Pharo based "Web Velocity"

by Geert Claes

dmason wrote: > > > I have a new graduate student who will be working on this, but the actual > work won't start for a few months. XUL and Moose/Glamour both sound like > interesting base points. > > ../Dave > > A start in a few months is probably not bad at all, I reckon by then Pharo may have an improved metacello project/component/package and version control system which will be instrumental when designing a smalltalk web app IDE :) Anyhow, I am looking forward to see what your grad student comes up with! -- View this message in context: http://n2.nabble.com/Pharo-based-Web-Velocity-tp4240702p4243582.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 2, 2010