- Pharo-dev - lists.pharo.org

[Pharo-project] Smalltalk Image writer?

by James Ladd

>>we are interested in a Smalltalk based image writer too :) While I work through reading and writing the Smalltalk image myself (in Java) I'll be writing down what I find. I'd be happy to try and write a Smalltalk based image writer. Please tell me your requirements and I'll try and include them. Rgs, James.

Sept. 2, 2010

Re: [Pharo-project] Serial ports on Linux

by Schwab,Wilhelm K

I *think* I have been able to successfully open '/dev/ttyS0' by name. I started on my laptop, which does not have a serial port, so I tried the USB-serial box knowing there could be problems. Then I worked for a while at home, "knowing" that this machine has a serial port (apparently not!). Having realized the latter trap, I fired up a PC/104 machine that is currently in my care; it has two serial ports, and I can open and read nothing from them. I still think the Linux vm is too stingy with diagnostic information, but the named ports hopefully indeed work. It will take a little doing to get a computer with serial ports in the same place as the device with which I need to communicate, and/or to write some code for the PC/104 machine to talk to itself using the two ports and a cable. The latter is not entirely trivial, mostly because I want to do it using streams. The state of the USB-serial box is unclear. The problems might simply be in the way I created the nodes for its ports - more on that after some technical support. 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: Wednesday, September 01, 2010 3:36 PM To: vm-dev(a)lists.squeakfoundation.org; squeak-dev(a)lists.squeakfoundation.org; Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Serial ports on Linux Markus, If you have some experience with serial I/O on Linux, I would appreciate your giving it a quick shakedown; if it is just plain broken or is still known to work, it would be nice to confirm either way. I would like to use the binary distribution, but it does not report enough of what it is trying to do (so no clues when things fail) and I end up hacking to add tracing with possible installation troubles as a result. That said, this time around, I find myself in serialPortOpenByName() and puzzled by the failure being allegedly detected by: /* save the old state */ if (tcgetattr(sp->spDescriptor, &sp->spTermios)) My question: is there old state to save on the first pass? errno is not helpful; it is set to 5 aka I/O error :( I find myself wondering whether this should be conditional on the internal state of the descriptor, and the failure to open simply being that it gives up too easily? Then again, it could be detecting a true error condition and preventing certain disaster in the lines that would follow. Any ideas? I can't get /dev/ttyS0 to open by name or number. 'COM1' worked nicely on Windows. Bill Markus Lampert markuslampert at yahoo.com Wed Sep 1 15:28:38 UTC 2010 Hi Bill, haven't used the serial interface with the new VMs (yet), but previously under Linux I had to use the vm option '-notimer'. I did not find any negative side effects with that option. Hope this helps, Markus _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 2, 2010

Re: [Pharo-project] [squeak-dev] Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b4.

by John M McIntosh

On 2010-08-29, at 11:10 AM, stephane ducasse wrote: > John > > What I want to understand is what does it means to use open/GL. > This means that you use open/GL to implement the primitive? > Now I thought that opengl was more vector graphics than bitblt so how does it fit together. > Is it because the mac UI is opengl based too? > > Stef Ok let me give you some background, then talk about open/GL The Squeak drawing logic invokes: http://isqueak.org/displayioShowDisplay Which is to say copy this rectangle of data from the Squeak Display Oops data pointer to something that visually shows the user what is going on, since drawing can require a few Smalltalk based calculations resulting in draw events to compose a final image then we also have, http://isqueak.org/ioForceDisplayUpdate To help the process a bit by allowing the drawing subsystem to compose the bits until we are done, then perform the expensive step of visualization. In general the displayioShowDisplay is really fast but the ioForceDisplayUpdate is slow, displayioShowDisplay may not show the bits, but displayioShowDisplay may now (or later... ) Depending on which VM source code (version and platform dependent) you may find that ioForceDisplayUpdate does nothing, or a operating system flush is done to the hardware on every displayioShowDisplay. Where you can see this issue is if you try. Transcript cr;show: [| b | b _ Pen new. Display fillWhite. b place:(Display boundingBox bottomLeft). b hilbert: 9 side: 2 ] timeToRun. Display restore. If this crawls, like taking 30 seconds, then the implementation is flushing every bit draw to the operating system. Well or if you don't see the bits then maybe neither displayioShowDisplay or ioForceDisplayUpdate does any flushing, and all you see is the Display restore results. Now just to make life harder for the VM implementor the Smaltalk code might not call ioForceDisplayUpdate. Then the VM has to do the ioForceDisplayUpdate internally in order not to leave bit's dangling. How this is done again is different from VM to VM. Usually this shows up as a double menu selection highlight. For the 4.2.x series of Macintosh VM we would trigger a operating system flush if more than 20 ms (a settable value) had elapsed, and I did nothing for ioForceDisplayUpdate. But I change this in 5.x and for the iPhone to make ioForceDisplayUpdate the trigger, with a timer that pops if a ioForceDisplayUpdate is not done within 20ms of the last executed displayioShowDisplay. Now about Open/GL, in the past for os-x carbon VM 4.2.X and earlier we used System 7.5.x technology to draw bits, which was quickdraw and quickdraw quartz. When I moved the logic to the iPhone that is not supported technology, because of the interesting drawing logic on the iPhone it took 6 attempts and a long chat with a graphics engineer at Apple. That resulted in using Core Animation to divide the screen into 16 tiles so when a draw happens we note which Tile(s) are dirty based on the rectangle intersections, then on the ioForceDisplayUpdate we generate images for each of the dirty tiles from the Display Oops and tell Core Animation redraw the new tiles. Bert said this seemed slow on OS-X. At this point the next step in our OS-X/iOS drawing path is drop one step lower down and consider Open/GL. I must admit I've not done any open/GL work before so it was a learning opportunity. Although you think of Open/GL as a vector based graphic language it does support what is know as Textures. So instead of providing vectors, you supply bits. So a chunk of data, stating it's RGB, at this depth and pixel layout and size, etc make a chunk of screen glow that is showing the open/GL viewport. Now there are lots of restrictions but the GPUs and drivers have become more friendly so you can supply arbitrary sized rectangles, this was at one time slow, but GPUs have become extremely fast, so slow is fast... In fact on the mac you can supply a arbitrary sized rectangle taken from a much larger rectangle of data, which fits perfectly into the displayioShowDisplay logic. The only hassle is that you need to figure out how the flush should work. So after 3 days of intense effort I can say the algorithm is... displayioShowDisplay collects the union of the rectangles that are being drawn. Nothing more happens... It's pointless to do the glTexImage2D here because 'b hilbert: 9 side: 2' will kill you. Mind we do still watch for a missing ioForceDisplayUpdate. ioForceDisplayUpdate Then takes the union of the rectangles, set a GL viewpoint, and does the glTexImage2D based on figuring out the start point of the top/left pixel of the rectangle to draw, then setups up the coordinate system and finally flush the data. glViewport( subRect.origin.x,subRect.origin.y, subRect.size.width,subRect.size.height ); char *subimg = ((char*)lastBitsIndex) + (unsigned int)(subRect.origin.x + (r.size.height-subRect.origin.y-subRect.size.height)*r.size.width)*4; glTexImage2D( GL_TEXTURE_RECTANGLE_ARB, 0, GL_RGBA, subRect.size.width, subRect.size.height, 0, GL_BGRA, GL_UNSIGNED_INT_8_8_8_8_REV, subimg ); glBegin(GL_QUADS); // The -1 is so we flip the coordinate system as os-x and squeak have different views of where (0,0) is... glTexCoord2f(0.0f, 0.0f); glVertex2f(-1.0f, 1.0f); glTexCoord2f(0.0f, subRect.origin.x.size.height); glVertex2f(-1.0f, -1.0f); glTexCoord2f(subRect.origin.x.size.width, subRect.origin.x.size.height); glVertex2f(1.0f, -1.0f); glTexCoord2f(subRect.origin.x.size.width, 0.0f); glVertex2f(1.0f, 1.0f); glEnd(); glFlush() // Ask the hardware to draw this stuff, don't use the more aggressive glFinish() reset the union of draw rectangles. Hint (a) Oddly some people feel they should re-configure the open/GL graphic context on *every* draw cycle, why? (b) People don't read the Apple guidebooks for best practices for doing glTexImage2D, this I know based on Google searches using certain Apple open/GL extension keywords. Notes: This assumes the Squeak display is 32 bits, other resolutions are an exercise for the reader. Actually if the row width is a multiple of 32 bytes then on the Mac things are *much* faster and no copy is made. This is enforced in 5.7b5 by ensuring window size is divisible by 8. When the graphic context is setup when the window is built there is a bunch of cmds to execute, one important one is glPixelStorei( GL_UNPACK_ROW_LENGTH, self.frame.size.width ); and when the window is resized there are a few things to do to indicate how the context has changed. Some platforms like the iPhone might need to do this instead because it doesn't support the GL extension GL_TEXTURE_RECTANGLE_ARB glTexImage2D( GL_TEXTURE_2D, 0, GL_RGBA, subRect.size.width, subRect.size.height, 0, GL_RGBA, GL_UNSIGNED_INT_8_8_8_8_REV, NULL ); for( int y = 0; y < subRect.size.height; y++ ) { char *row = ((char*)lastBitsIndex) + ((y + subRect.origin.y)*subRect.size.width + subRect.origin.x) * 4; glTexSubImage2D( GL_TEXTURE_2D, 0, 0, y, subRect.size.width, 1, GL_RGBA, GL_UNSIGNED_BYTE, row ); } -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Sept. 1, 2010

Re: [Pharo-project] Please help!! Error: There is no free space in this set!'

by Guillermo Polito

I couldn't reproduce your original error :S. I tested the code in the comments of the issue in an updated 1.2 Core image on windows... I did a 'do it' and a 'debug it' and nothing special happened... Check the comment 3 in this issue http://code.google.com/p/pharo/issues/detail?id=1628 , looking at the code and the comments below that one, I think that's the fix implemented :). 2010/9/1 Mariano Martinez Peck <marianopeck(a)gmail.com> > > > 2010/9/1 Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> > > The error no free space in set should be fixed in 1.1. >> Except abysmal performance, what problem do you have exactly? >> > > I am not talking about performance. I am talking that it just raise that > error. > > What I do particulary in SqueakDBX (it is optional thus) is that when a > Connection is created, it is added to WeakRegistry default so that I can > implement #finalize and this method releases the database connection if it > was not already done. > > This is for possible bugs or developers where they don't cal correctly > yhe#disconnect method. Of course, if you use the pool you won't have this > problem (depending how many connections you define in the pool as max). > Anyway, while running tests, I create a lot of connections, thus, I get the > error "There is no free space in this set!'" when the code tries to add > the connection to the WeakRegistry. > > Thanks Henry. > > mariano > > >> >> Cheers, >> Henry >> >> >> On 01.09.2010 16:41, Mariano Martinez Peck wrote: >> >> So....any helpers? >> >> http://code.google.com/p/pharo/issues/detail?id=2551 >> http://code.google.com/p/pharo/issues/detail?id=1628 >> >> I would like to help, but I am 100% newbie in this. Please consider me as >> tester. >> >> Cheers >> >> mariano >> >> 2010/8/5 Miguel Enrique CobÃ¡ MartÃnez <miguel.coba(a)gmail.com> >> >>> El jue, 05-08-2010 a las 21:35 +0200, Mariano Martinez Peck escribiÃ³: >>> > I know this is a alraedy known issue: >>> > http://code.google.com/p/pharo/issues/detail?id=1628 >>> > I am trying to make SqueakDBX work in 1.1 and it doesn't work because >>> > of this. Each DBXConnection is registered in the WeakRegistry just to >>> > close the database connection in case they don't do it explicitly. >>> > >>> > This this, I have a: >>> > >>> > addObjectToGarbageCollect: anObject >>> > >>> > WeakRegistry default add: anObject. >>> > >>> > >>> > And in DBXConnetion >> connect, I call that method. >>> > >>> > Do you know how to solve the problem? I read the issue but I am >>> > uncertain what should I do nor if it is fixed. I think this bug is >>> > really important. >>> >>> Not a solution sorry, but a suggestion (or maybe this is already >>> implemented, I haven't used SqueakDBX). :) >>> >>> Maybe it would be useful to add a pool for the connections so they >>> aren't so many at the same time. Also, the database admin will be >>> grateful. >>> >>> Cheers >>> >>> >>> > >>> > Thanks >>> > >>> > Mariano >>> > _______________________________________________ >>> > Pharo-project mailing list >>> > Pharo-project(a)lists.gforge.inria.fr >>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> -- >>> 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 >> >> >> >> _______________________________________________ >> Pharo-project mailing listPharo-project@lists.gforge.inria.frhttp://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 >

Sept. 1, 2010

Re: [Pharo-project] MethodName

by Alexandre Bergel

>> Is there a configuration I can use instead of the gofer invocation? > > Why? Does it depend on strange things? Using configurations allow me to scripts loading. For example: -=-=-=-=-=-=-=-=-= #('NewInspector' 'Shout' 'OCompletion' 'O2' 'Moose' 'CAnalyzer' 'Spy' 'Adore' 'DependencyView') do: [:t | | name | name := 'ConfigurationOf', t. Gofer new squeaksource: 'MetacelloRepository'; package: name; load. ((Smalltalk at: name asSymbol) project perform: #lastVersion) load ]. -=-=-=-=-=-=-=-=-= Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 1, 2010

Re: [Pharo-project] Fwd: [squeak-dev] The Trunk: System-eem.366.mcz

by Eliot Miranda

On Wed, Sep 1, 2010 at 1:48 PM, Henrik Sperre Johansen < henrik.s.johansen(a)veloxit.no> wrote: > Just remember to add corresponding deregistration in shutdown if > SystemChangeNotifier is reimplemented using Announcements :) > > (hint: Announcers do not care if objects register multiple times to the > same Announcement) > but surely we'd fix that in the new implementation of notify:ofAllSystemChangesUsing:? Or arguably in Announcements? > > Cheers, > Henry > > On 01.09.2010 22:41, StÃ©phane Ducasse wrote: > >> muchas gratias. >> >> >> Stef >> >> On Sep 1, 2010, at 9:08 PM, Adrian Lienhard wrote: >> >> I created a changeset and attached it to the appropriate ticket: >>> http://code.google.com/p/pharo/issues/detail?id=2896 >>> >>> Adrian >>> >>> On Sep 1, 2010, at 09:52 , StÃ©phane Ducasse wrote: >>> >>> seems like we should do something :) >>>> >>>> Begin forwarded message: >>>> >>>> From: John M McIntosh<johnmci(a)smalltalkconsulting.com> >>>>> Date: September 1, 2010 1:12:28 AM GMT+02:00 >>>>> To: StÃ©phane Ducasse<stephane.ducasse(a)inria.fr> >>>>> Subject: Fwd: [squeak-dev] The Trunk: System-eem.366.mcz >>>>> Reply-To: johnmci(a)smalltalkconsulting.com >>>>> >>>>> In case this gets overlooked being hidden in a update for The Trunk: >>>>> System-eem. >>>>> >>>>> The EndianCache does need to be cleared at shutdown versus in startup. >>>>> I can't speak for the SystemChangeNotifier since I'm not sure what the >>>>> bug is.. >>>>> >>>>> Of course I'm not quite sure if anyone in the Pharo group looks and the >>>>> trunk updates and moves things across? >>>>> >>>>> >>>>> Begin forwarded message: >>>>> >>>>> From: commits(a)source.squeak.org >>>>>> Date: August 31, 2010 5:47:35 PM PDT >>>>>> To: squeak-dev(a)lists.squeakfoundation.org, >>>>>> packages(a)lists.squeakfoundation.org >>>>>> Subject: [squeak-dev] The Trunk: System-eem.366.mcz >>>>>> Reply-To: squeak-dev(a)lists.squeakfoundation.org >>>>>> >>>>>> Eliot Miranda uploaded a new version of System to project The Trunk: >>>>>> http://source.squeak.org/trunk/System-eem.366.mcz >>>>>> >>>>>> ==================== Summary ==================== >>>>>> >>>>>> Name: System-eem.366 >>>>>> Author: eem >>>>>> Time: 31 August 2010, 10:47:17.97 am >>>>>> UUID: 2126e5d9-4d47-4cc1-921f-daefd935aedd >>>>>> Ancestors: System-nice.365 >>>>>> >>>>>> Make sure system notifications for Smalltalk are up-to-date >>>>>> on start-up. >>>>>> Fix voiding of Smalltalk's endian cache which needs to be done >>>>>> in a timely manner. >>>>>> >>>>>> =============== Diff against System-nice.365 =============== >>>>>> >>>>>> Item was changed: >>>>>> ----- Method: SmalltalkImage class>>startUp (in category 'class >>>>>> initialization') ----- >>>>>> startUp >>>>>> + SystemChangeNotifier uniqueInstance notify: Smalltalk >>>>>> ofAllSystemChangesUsing: #event:! >>>>>> - "XXXX: This is broken. SmalltalkImage startUp happens quite >>>>>> late in the startup sequence; earlier startups may very well need the >>>>>> information about the endianness of the platform." >>>>>> - EndianCache := nil. >>>>>> - ! >>>>>> >>>>>> Item was changed: >>>>>> ----- Method: SmalltalkImage>>processShutDownList: (in category >>>>>> 'snapshot and quit') ----- >>>>>> processShutDownList: quitting >>>>>> + "Send #shutDown to each class that needs to wrap up before a >>>>>> snapshot. >>>>>> + Also void the endianness chace; this can't safely be done on >>>>>> start-up because >>>>>> + Smalltalk is too late in the start-up sequence." >>>>>> - "Send #shutDown to each class that needs to wrap up before a >>>>>> snapshot." >>>>>> >>>>>> + EndianCache := nil. >>>>>> + self send: #shutDown: toClassesNamedIn: ShutDownList with: >>>>>> quitting! >>>>>> - self send: #shutDown: toClassesNamedIn: ShutDownList with: >>>>>> quitting. >>>>>> - ! >>>>>> >>>>>> >>>>>> -- >>>>> >>>>> =========================================================================== >>>>> 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 >>> >> >> _______________________________________________ >> 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 >

Sept. 1, 2010

Re: [Pharo-project] Fwd: [squeak-dev] The Trunk: System-eem.366.mcz

by Henrik Sperre Johansen

Just remember to add corresponding deregistration in shutdown if SystemChangeNotifier is reimplemented using Announcements :) (hint: Announcers do not care if objects register multiple times to the same Announcement) Cheers, Henry On 01.09.2010 22:41, StÃ©phane Ducasse wrote: > muchas gratias. > > > Stef > > On Sep 1, 2010, at 9:08 PM, Adrian Lienhard wrote: > >> I created a changeset and attached it to the appropriate ticket: http://code.google.com/p/pharo/issues/detail?id=2896 >> >> Adrian >> >> On Sep 1, 2010, at 09:52 , StÃ©phane Ducasse wrote: >> >>> seems like we should do something :) >>> >>> Begin forwarded message: >>> >>>> From: John M McIntosh<johnmci(a)smalltalkconsulting.com> >>>> Date: September 1, 2010 1:12:28 AM GMT+02:00 >>>> To: StÃ©phane Ducasse<stephane.ducasse(a)inria.fr> >>>> Subject: Fwd: [squeak-dev] The Trunk: System-eem.366.mcz >>>> Reply-To: johnmci(a)smalltalkconsulting.com >>>> >>>> In case this gets overlooked being hidden in a update for The Trunk: System-eem. >>>> >>>> The EndianCache does need to be cleared at shutdown versus in startup. >>>> I can't speak for the SystemChangeNotifier since I'm not sure what the bug is.. >>>> >>>> Of course I'm not quite sure if anyone in the Pharo group looks and the trunk updates and moves things across? >>>> >>>> >>>> Begin forwarded message: >>>> >>>>> From: commits(a)source.squeak.org >>>>> Date: August 31, 2010 5:47:35 PM PDT >>>>> To: squeak-dev(a)lists.squeakfoundation.org, packages(a)lists.squeakfoundation.org >>>>> Subject: [squeak-dev] The Trunk: System-eem.366.mcz >>>>> Reply-To: squeak-dev(a)lists.squeakfoundation.org >>>>> >>>>> Eliot Miranda uploaded a new version of System to project The Trunk: >>>>> http://source.squeak.org/trunk/System-eem.366.mcz >>>>> >>>>> ==================== Summary ==================== >>>>> >>>>> Name: System-eem.366 >>>>> Author: eem >>>>> Time: 31 August 2010, 10:47:17.97 am >>>>> UUID: 2126e5d9-4d47-4cc1-921f-daefd935aedd >>>>> Ancestors: System-nice.365 >>>>> >>>>> Make sure system notifications for Smalltalk are up-to-date >>>>> on start-up. >>>>> Fix voiding of Smalltalk's endian cache which needs to be done >>>>> in a timely manner. >>>>> >>>>> =============== Diff against System-nice.365 =============== >>>>> >>>>> Item was changed: >>>>> ----- Method: SmalltalkImage class>>startUp (in category 'class initialization') ----- >>>>> startUp >>>>> + SystemChangeNotifier uniqueInstance notify: Smalltalk ofAllSystemChangesUsing: #event:! >>>>> - "XXXX: This is broken. SmalltalkImage startUp happens quite late in the startup sequence; earlier startups may very well need the information about the endianness of the platform." >>>>> - EndianCache := nil. >>>>> - ! >>>>> >>>>> Item was changed: >>>>> ----- Method: SmalltalkImage>>processShutDownList: (in category 'snapshot and quit') ----- >>>>> processShutDownList: quitting >>>>> + "Send #shutDown to each class that needs to wrap up before a snapshot. >>>>> + Also void the endianness chace; this can't safely be done on start-up because >>>>> + Smalltalk is too late in the start-up sequence." >>>>> - "Send #shutDown to each class that needs to wrap up before a snapshot." >>>>> >>>>> + EndianCache := nil. >>>>> + self send: #shutDown: toClassesNamedIn: ShutDownList with: quitting! >>>>> - self send: #shutDown: toClassesNamedIn: ShutDownList with: quitting. >>>>> - ! >>>>> >>>>> >>>> -- >>>> =========================================================================== >>>> 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 1, 2010

Re: [Pharo-project] Fwd: [squeak-dev] The Trunk: System-eem.366.mcz

by StÃ©phane Ducasse

muchas gratias. Stef On Sep 1, 2010, at 9:08 PM, Adrian Lienhard wrote: > I created a changeset and attached it to the appropriate ticket: http://code.google.com/p/pharo/issues/detail?id=2896 > > Adrian > > On Sep 1, 2010, at 09:52 , StÃ©phane Ducasse wrote: > >> seems like we should do something :) >> >> Begin forwarded message: >> >>> From: John M McIntosh <johnmci(a)smalltalkconsulting.com> >>> Date: September 1, 2010 1:12:28 AM GMT+02:00 >>> To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>> Subject: Fwd: [squeak-dev] The Trunk: System-eem.366.mcz >>> Reply-To: johnmci(a)smalltalkconsulting.com >>> >>> In case this gets overlooked being hidden in a update for The Trunk: System-eem. >>> >>> The EndianCache does need to be cleared at shutdown versus in startup. >>> I can't speak for the SystemChangeNotifier since I'm not sure what the bug is.. >>> >>> Of course I'm not quite sure if anyone in the Pharo group looks and the trunk updates and moves things across? >>> >>> >>> Begin forwarded message: >>> >>>> From: commits(a)source.squeak.org >>>> Date: August 31, 2010 5:47:35 PM PDT >>>> To: squeak-dev(a)lists.squeakfoundation.org, packages(a)lists.squeakfoundation.org >>>> Subject: [squeak-dev] The Trunk: System-eem.366.mcz >>>> Reply-To: squeak-dev(a)lists.squeakfoundation.org >>>> >>>> Eliot Miranda uploaded a new version of System to project The Trunk: >>>> http://source.squeak.org/trunk/System-eem.366.mcz >>>> >>>> ==================== Summary ==================== >>>> >>>> Name: System-eem.366 >>>> Author: eem >>>> Time: 31 August 2010, 10:47:17.97 am >>>> UUID: 2126e5d9-4d47-4cc1-921f-daefd935aedd >>>> Ancestors: System-nice.365 >>>> >>>> Make sure system notifications for Smalltalk are up-to-date >>>> on start-up. >>>> Fix voiding of Smalltalk's endian cache which needs to be done >>>> in a timely manner. >>>> >>>> =============== Diff against System-nice.365 =============== >>>> >>>> Item was changed: >>>> ----- Method: SmalltalkImage class>>startUp (in category 'class initialization') ----- >>>> startUp >>>> + SystemChangeNotifier uniqueInstance notify: Smalltalk ofAllSystemChangesUsing: #event:! >>>> - "XXXX: This is broken. SmalltalkImage startUp happens quite late in the startup sequence; earlier startups may very well need the information about the endianness of the platform." >>>> - EndianCache := nil. >>>> - ! >>>> >>>> Item was changed: >>>> ----- Method: SmalltalkImage>>processShutDownList: (in category 'snapshot and quit') ----- >>>> processShutDownList: quitting >>>> + "Send #shutDown to each class that needs to wrap up before a snapshot. >>>> + Also void the endianness chace; this can't safely be done on start-up because >>>> + Smalltalk is too late in the start-up sequence." >>>> - "Send #shutDown to each class that needs to wrap up before a snapshot." >>>> >>>> + EndianCache := nil. >>>> + self send: #shutDown: toClassesNamedIn: ShutDownList with: quitting! >>>> - self send: #shutDown: toClassesNamedIn: ShutDownList with: quitting. >>>> - ! >>>> >>>> >>> >>> -- >>> =========================================================================== >>> 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

Sept. 1, 2010

Re: [Pharo-project] MethodName

by StÃ©phane Ducasse

alain will certainly have a look at the code too. Stef > I have a 12121, it works very well! > I will use it. > > Is there a configuration I can use instead of the gofer invocation? > > Cheers, > Alexandre > > > On 1 Sep 2010, at 08:22, Mariano Martinez Peck wrote: > >> >> >> 2010/8/30 Alexandre Bergel <alexandre(a)bergel.eu> >> I attached PharoDebug.log >> >> did you try it in Pharo1.2 - 12109 ? ? >> >> >> >> Alexandre >> >> >> >> On 30 Aug 2010, at 09:12, StÃ©phane Ducasse wrote: >> >>> excellent we spent the week-end (or the part allocated to code) chasing it. >>> Which image? version.... >>> >>> We do not understand why fileIn has a problem when MethodReference get a real timestamp. >>> Stef >>> >>> >>>> Hi! >>>> >>>> I can't load it. I've got an error: Instances of Timestamp are not indexable >>>> >>>> Alexandre >>>> >>>> >>>> On 29 Aug 2010, at 22:07, Benjamin Van Ryseghem wrote: >>>> >>>>> Hello everyone >>>>> >>>>> As you may already known, I'm working on a new tool named MethodName which is the merge of MethodFinder and MessagesName with some cool improvement :) >>>>> >>>>> It works on Pharo1.2 - 12109 because it needs NullTextStyler ( >>>>> Gofer new >>>>> squeaksource: 'PharoTaskForces'; >>>>> package: 'NullTextStyler'; >>>>> load.) >>>>> >>>>> You can download the sources by evaluating this : >>>>> >>>>> Gofer new >>>>> squeaksource: 'PharoTaskForces'; >>>>> package: 'MethodName'; >>>>> load. >>>>> >>>>> For opening a new MethodName window there's two ways : >>>>> - evaluate : MethodName new openInWorld. >>>>> - click World >> Tools >> Method Name >>>>> >>>>> >>>>> How it works : >>>>> - You choose thank to the radio button where you want to search (Selectors / Class names/ Source) >>>>> - You type the text you want to search : >>>>> + Source : >>>>> 1) *string or string or string* or *string* -> it answers all the methods which source contains string >>>>> 2) begin*end -> it answers all the methods which source contains begin(whatever)end. >>>>> + Class names : >>>>> 1) name -> it answers the class which the name is name >>>>> 2) name* / *name / *name* / begin*end ... -> * replaces any string. >>>>> + Selectors: >>>>> 1) the same behaviour that for class names >>>>> 2) the behaviour of MethodFinder >>>>> >>>>> Moreover you can reduce the field of search by clicking on "Change environment" which open a PackageChooser window. >>>>> A PackageChooser let you choose the set of classes which will be browsed during the search. >>>>> >>>>> The left list shows all the available packages and the right list shows the already selected packages. >>>>> To add packages, just select them then click ">" to add them or click ">>" to select all the packages. It's the same to remove packages. >>>>> >>>>> Instead of browsing tons of packages in the goal of finding the one you want, you can use the text field to enter the name of the package or a part of the name using some *. >>>>> >>>>> When all the packages are selected, just click "Ok" :) >>>>> >>>>> I hope it's a bit clear and a bit useful ^^ >>>>> >>>>> Benjamin >>>>> _______________________________________________ >>>>> 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 >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> 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 > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 1, 2010

Re: [Pharo-project] Deleted or renamed behaviors

by StÃ©phane Ducasse

sure. Let me know what you have. I just wanted to explain what we will start doing and what we have in mind. The future looks quite cool to me but I'm an optimist and this is life Stef On Sep 1, 2010, at 8:13 PM, HernÃ¡n Morales Durand wrote: > Hi Stef, > > I don't aspire an advanced tool or even build a model for this, just a > tool for the short-term to track removed methods names or modified > selectors so I can see what is the new selector or equivalent method > to use instead, if such exists in the current image. > > HernÃ¡n > > 2010/9/1 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> what is the idea? >> >> What we want to do with veronica is >> - get a declarative code model (MC2/Ginsu) --> >> - put all the version of squeak and pharo in a Gemstone DB >> - make sure that we can do historized queries >> sender in version 1.0 >> - diff between versions >> >> Stef >> >> On Aug 31, 2010, at 9:17 PM, HernÃ¡n Morales Durand wrote: >> >>> Ok, thanks for the reply. I've created a repository in SqS for a tool >>> supporting better tracking of change history >>> >>> http://www.squeaksource.com/ChangeTracker.html >>> >>> please do not hesitate to contact me to join this project. I'm >>> planning to use the OB framework but any suggestions are welcomed. >>> Cheers, >>> >>> HernÃ¡n >>> >>> 2010/8/31 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> not directly but indeed we should be much more imaginative with our tools. >>>> Now I'm spending my time on not really funny or exciting actions so I do not have time >>>> to invent new stuff and this is bad. >>>> I'm trying to make sure that this situation will change but so far still crawling. >>>> This is why we will add RB in Unstable because we should use powertools in Unstable. >>>> >>>> Stef >>>> >>>> On Aug 31, 2010, at 6:46 PM, HernÃ¡n Morales Durand wrote: >>>> >>>>> Hi all, >>>>> >>>>> Is there a tool to observe the replacements of renamed or removed >>>>> methods in Pharo? >>>>> Because it happened to me several times, when loading a package in >>>>> Pharo two or three months after I've released something, there are >>>>> methods removed and I have to search the change comments everywhere >>>>> (change log, mailing list, issues list, etc) and figure out the >>>>> replacements, and sometimes it isn't so direct. >>>>> Cheers, >>>>> >>>>> HernÃ¡n >>>>> >>>>> _______________________________________________ >>>>> 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 >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 1, 2010