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

Re: [Pharo-project] Finalization quirk

by Schwab,Wilhelm K

Gary, At this point, I'd settle for evidence that it is at least random. So far, it appears to do nothing until some type of "big" system event happens, almost to the point of acting like a pre-shutdown cleanup. I _thought_ I saw more predictable activity in another situation where I use finalization, but that might have been more that I was squeezing bugs out of my finalization code and was just happy to see the end of the walkbacks :) It could also be that the code in question is a little memory hungry and was (just a guess) kicking off more and more substantial GC activity and prodded finalization that way?? For laughs I tried switching the mutual exclusion semaphore to a mutex, and tried signaling the finalization semaphore myself. Neither seemed to improve the situation. In my current situation, finalization is really a coward's way out anyway. I have gnuplot giving me png images via pipes, and now want to begin to do that more than once per external process, and also to allow it to work if the goal is indeed to write files, etc. So far, I have been reading the image off the pipe and closing gnuplot more or less in one operation, which needs to change. With good coding, I should be able to retain ensured cleanup and still allow multiple interactions per OS process, and with fewer gnuplot instances created, some delay in finalizing them (if I do fail to ensure cleanup) should not be a big disaster. That said, I still think there is something wrong with the current finalization implementation. At best, it is nowhere near as predicatable as Dolphin's finlizer. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Gary Chambers Sent: Wednesday, January 06, 2010 1:20 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Finalization quirk Finalisation seems a bit random in Squeak/Pharo. Sometimes needs a globalGarbageCollect to kick it. Part of the reason we try to avoid excessive use (Sockets still remain etc.). Regards, Gary ----- Original Message ----- From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Wednesday, January 06, 2010 6:12 PM Subject: [Pharo-project] Finalization quirk >I am trying to add finalization to something and appear to be at a point >that finalization does not happen until I open the process browser. Any >ideas? > > Bill > > > _______________________________________________ > 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. 6, 2010

Re: [Pharo-project] inspector and auto-update

by Marcus Denker

On Jan 6, 2010, at 9:32 PM, John M McIntosh wrote: > Hi I noticed that in the past (likely some current squeak image) > When you brought up an inspector on an object it would auto-update the instance variables shown. > > However this behaviour is lacking in a > PharoCore1.0rc1 > Latest update: #10502 > > So is that what is expected? > auto-update is supposed to work with the inspector... if not, it's a bug. Marcus

Jan. 6, 2010

Re: [Pharo-project] Polymorph

by Gary Chambers

Thank you Steph... it will be a challenge to produce a framework to support all our needs but I believe we have, between us all, the expertise and motivation to make it so! ----- Original message ----- Gary I feel honored by your trust (which is a ***really*** important value for me - mainly my own value). Now slices are only good when dealing with crosscutting changes. They help us finding the packages in the kind of random order of the inbox :) > Given the integration of Polymorph with Pharo and the distinct direction that Squeak is going I am going to have to mark an end to Polymorph as an ongoing project, as such. >Â > Further changes/additions/refactorings will now be limited to Pharo and must be therefore done using the Slice system (will take a while to get to grips with as time allows). What I would like is to have a deeper merge (not turning around morphic idiosyncrasies). For fun I wanted to check CUIS Morph since juan removed a lot of unnecessary code. >Â A final release of Polymorph will be made on SqueakSource, as time allows soon. This will be the last (allegedly compatible) version with Squeak, though I expect in its current state it is effectively not loadable into recent Squeak images. >Â > I'll try to get the time to make any changes via Pharo slices though I still like the modularity of packaging systems. Can't have both it seems. Polymorph is mature enough that, moving forward, most else can be done as additions rather that overrides. Cool. > Perhaps an "extras" package? > Thanks to all who have been involved with Pharo and helping us to move forward. Here's to the new baseline! >Â > Shame the StrikeFonts don't do all that they should... always a compromise of speed vs. functionality (c.f. translucent text). >Â > On a personal note, it would be nice to start to leverage the possiblility of an open approach to visuals, host windows etc. Valuable lessons have been learned and I think Pharo can provide a baseline for moving forward to a more flexible and performant ui substrate. Happy to work with you all to achieve that goal! Excellent! We really want to learn from your experience. I have rome also in my scanner. > Regards, Gary > _______________________________________________ > 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. 6, 2010

Re: [Pharo-project] [Seaside] Mac VM 5.2b3 & iPhone VM 2.1.0 ships

by John M McIntosh

Bruce Prior and I are looking at a problem with the touch interaction and menu display He notes for 2.10 that: "but the windows are easily moved around now " On a slow device like the iPhone any improvements in window management, drawing, usage are quite noticeable. On 2010-01-06, at 8:35 AM, Esteban Lorenzano wrote: > Well, I'm currently testing those vms with the iphone. So far, no > problems (but I'm maybe being optimistic, I didn't tried a full stress > of the vm, just a few tests) > > Cheers, > Esteban > > On 2010-01-06 04:15:53 -0300, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> said: > >> Since Pharo 1.1 is already faster and 1.0 and will continue to improve >> on that level. I'm curious to see >> if how it helps for iphone >> >> Stef >> -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Jan. 6, 2010

Re: [Pharo-project] getting crazy with ImageSegment code

by StÃ©phane Ducasse

Before I add an issue to add classifiedBy: is it different from groupedBy: aBlock "Answer a dictionary whose keys are the result of evaluating aBlock for all my elements, and the value for each key is the selection of my elements that evaluated to that key. Uses species." | groups | groups := PluggableDictionary integerDictionary. self do: [ :each | (groups at: (aBlock value: each) ifAbsentPut: [ OrderedCollection new ]) add: each ]. self species ~~ OrderedCollection ifTrue: [ groups associationsDo: [ :association | association value: (self species withAll: association value) ]]. ^ groups which is now in Pharo 1.1 ;-") On Jan 6, 2010, at 4:28 PM, Gary Chambers wrote: > Perhaps a helper method might be useful. Here's one I alsways end up > implementing on Collection for whatever Smalltalk system... > > classifiedBy: aBlock > "Answer a dictionary where the keys are the result > of evaluating the block and the values are ordered > collections of the elements of the receiver that caused > the block to return that key." > > |d| > d := Dictionary new. > self do: [:e | > (d at: (aBlock value: e) > ifAbsentPut: [OrderedCollection new]) > add: e]. > ^d > > Regards, Gary > > > ----- Original Message ----- > From: "Adrian Lienhard" <adi(a)netstyle.ch> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Wednesday, January 06, 2010 2:57 PM > Subject: Re: [Pharo-project] getting crazy with ImageSegment code > > >> I extracted some old code and adapted it slightly (see below). I've >> not executed this but just typed it in Mail. And I have not completely >> read/understood your code but maybe it does what you need :) >> >> Cheers, >> Adrian >> >> >> symbols := Symbol allSymbols. >> groups := Dictionary new. >> SystemOrganization categories do: [ :cat | >> groups >> at: cat >> put: ((SystemOrganization superclassOrder: cat) select: [:c | >> aCollection includes: c]) asArray ]. >> groups keys do: [ :cat | >> roots := groups at: cat. >> roots := roots reject: [ :each | unused includes: each ]. >> roots := roots , (roots collect: #class). >> (ImageSegment new >> copyFromRoots: roots >> sizeHint: 0 >> areUnique: true) >> extract; >> writeToFile: cat ] >> >> On Jan 6, 2010, at 15:44 , Mariano Martinez Peck wrote: >> >>> Hi folks. I will pay a beer in next ESUG to the person that helps me >>> to >>> refactor this piece of code of ImageSegments: >>> >>> The idea is that I have a list of classes that were inactive and I >>> want to >>> group them by category (actually, seeing the code I think it is >>> package) and >>> to to create an ImageSegment per category (or package). >>> >>> This is the code (ONLYYYYY a piece...I cut all the rest) >>> >>> unused := self inactiveClassesDuringDiscovery. "These are the >>> classes that >>> were not used" >>> groups := Dictionary new. >>> SystemOrganization categories do: >>> [:cat | >>> i := (cat findLast: [:c | c = $-]) - 1. >>> i <= 0 ifTrue: [i := cat size]. >>> groups at: (cat copyFrom: 1 to: i) >>> put: (groups at: (cat copyFrom: 1 to: i) ifAbsent: [Array >>> new]) >>> , >>> ((SystemOrganization superclassOrder: cat) select: [:c | >>> unused includes: c]) asArray]. >>> groups keys do: >>> [:cat | roots := groups at: cat. >>> Transcript cr; cr; show: cat; cr; print: roots; endEntry. >>> roots := roots , (roots collect: [:c | c class]). >>> "There seems to be a problem with these packages, thus they are >>> excluded." >>> ((cat beginsWith: 'Sys') or: [cat beginsWith: 'Multilingual'] >>> or: >>> [cat beginsWith: 'Kerne'] ) ifFalse: >>> [(ImageSegment new copyFromRoots: roots sizeHint: 0) >>> extract; >>> writeToFile: cat]. >>> Transcript cr; print: Smalltalk garbageCollect; endEntry] >>> >>> >>> Can someone help me tu rewrite this? I think I could use >>> PackageOrganizer or >>> PackageInfo but I have no idea. >>> >>> Thanks! >>> >>> Mariano >>> _______________________________________________ >>> 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. 6, 2010

Re: [Pharo-project] Dev images with or without tests?

by Mariano Martinez Peck

2010/1/6 Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com> > El miÃ©, 06-01-2010 a las 16:56 -0200, csrabak(a)bol.com.br escribiÃ³: > > Alexandre, > > > > Once upon a time I thought like you, but I changed my mind when I > realized that more and more the tests are being engineered in such a fashion > that using them for the sake of an example is becoming convoluted. > > > > As we create all the machinery (setup and tear down) to do Unit Tests the > test itself conveys less information unless you start to navigate the SUnit > land, and I feel it will become even more inexpugnable for newcomers as soon > PhExample enters the scene (you might have chained tests). > > > > Notwithstanding the accepted notion that tests are a form of > documentation, I would say more and more they're falling into the same slot > of the argument "you have access to the code": true but not practical for > the day to day chores. > > > > +1 > > I agree with you 100% but I vote for maintaining the tests in the dev > image and giving the users a quick/easy/transcript ready way to unload > them if they want. > Yes. Would be cool if some one can see what I said about ScriptLoader cleanUpForProduction. > > Also, for deploy scenarios, the intended way is to use a PharoCore image > and use a personalized script (with gofer/metacello) to load only the > packages needed. > > BUt even the core have tests. So, even if you load your packages by hand, you may want to unload the tests of the core. Maybe you don't. It is up to you :) > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 6, 2010

Re: [Pharo-project] Finalization quirk

by Gary Chambers

Indeed, not all per pass... I find that, in Squeak, compared to VisualAge, for instance, that finalisation rarely happens regularly... This does tend to lead to quite prolonged processing when most critical... ----- Original message ----- Bill, I always tell people (a) finalization will occur later, not when you think it should (b) finalization will occur slower/faster than you think. (c) both (a) & (b) will vary You're violating (a) There is mention of doing a full GC will force the finalization, but I can't recall if that finalizes (all) objects in old oops space in one pass with squeak. Various Smalltalk flavours and versions do things differently, some at different times & versions perhaps would only finalize one oops per pass (visualage). On 2010-01-06, at 10:12 AM, Schwab,Wilhelm K wrote: > I am trying to add finalization to something and appear to be at a point that finalization does not happen until I open the process browser.Â Any ideas? > > Bill > > > _______________________________________________ > 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 =========================================================================== _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 6, 2010

[Pharo-project] DNU in dev image freezes my image

by Danie Roux

All, I downloaded pharo1.1-11112-alphadev09.12.2.zip, opened a Workspace and caused a DNU. This froze my image. Bug report: http://code.google.com/p/pharo/issues/detail?id=1750 -- Danie Roux *shuffle* Adore Unix - http://danieroux.com

Jan. 6, 2010

Re: [Pharo-project] Dev images with or without tests?

by Miguel Enrique CobÃ¡ Martinez

El miÃ©, 06-01-2010 a las 16:56 -0200, csrabak(a)bol.com.br escribiÃ³: > Alexandre, > > Once upon a time I thought like you, but I changed my mind when I realized that more and more the tests are being engineered in such a fashion that using them for the sake of an example is becoming convoluted. > > As we create all the machinery (setup and tear down) to do Unit Tests the test itself conveys less information unless you start to navigate the SUnit land, and I feel it will become even more inexpugnable for newcomers as soon PhExample enters the scene (you might have chained tests). > > Notwithstanding the accepted notion that tests are a form of documentation, I would say more and more they're falling into the same slot of the argument "you have access to the code": true but not practical for the day to day chores. > +1 I agree with you 100% but I vote for maintaining the tests in the dev image and giving the users a quick/easy/transcript ready way to unload them if they want. Also, for deploy scenarios, the intended way is to use a PharoCore image and use a personalized script (with gofer/metacello) to load only the packages needed. -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Jan. 6, 2010

[Pharo-project] inspector and auto-update

by John M McIntosh

Hi I noticed that in the past (likely some current squeak image) When you brought up an inspector on an object it would auto-update the instance variables shown. However this behaviour is lacking in a PharoCore1.0rc1 Latest update: #10502 So is that what is expected? -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Jan. 6, 2010