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

[Pharo-project] Network tests coverage (Re: WebClient-Core port to Pharo 1.1 final)

by Andreas Raab

Hi Sven - Good question. It would definitely be good to cover those areas with tests but I fear that may require actual cooperation :-) If there is enough energy (which is hard to say) one might be able to start a "neutral" repository with tests but I'm not sure how well it would work in practice (it would mean the tests are fairly far away from the source it's covering which is generally not a good thing). If anyone has good ideas, please propose. Cheers, - Andreas On 9/1/2010 12:38 PM, Sven Van Caekenberghe wrote: > Andreas, > > Thanks a lot for taking the time to look into these problems and for the patches. > Shouldn't we try to capture these problems with unit tests running across Squeak and its derivatives ? > What would be the procedure to contribute to these tests ? > > Sven > > On 01 Sep 2010, at 06:16, Andreas Raab wrote: > >> Hi Sven - >> >> I had a quick look at the failing tests on Pharo and they seem mostly the result of bugs in Pharo's Network package. First, MimeDocument>>url needs to return an instance of Url not a string (check the senders; all users of it expect it to be a Url not a string) so if you change that to return a url it'll take care of the pathForFile issue. >> >> The failure of testMultiPartPost2 is a combination of two bugs in HTTPSocket. First, there's a typo in getResponseUpTo: at the end (this needs to be #copyFrom:to: (the "to" is missing the colon). Second, there is httpPostMultiPart: which adds an erroneous CrLf at the end of a persistent HTTP/1.1 connection. That causes an interesting series of things to go wrong (which I'm partly still investigating) but the easy solution is to insert a "Connection: close" header. >> >> Fixes attached. These are of course also broken in Pharo 1.0 and 1.1. >> >> Cheers, >> - Andreas >>

Sept. 2, 2010

Re: [Pharo-project] Smalltalk Image writer?

by James Ladd

Thank John, great suggestion. > Message: 4 > Date: Wed, 1 Sep 2010 19:05:43 -0700 > From: John M McIntosh <johnmci(a)smalltalkconsulting.com> > Subject: Re: [Pharo-project] Smalltalk Image writer? > To: Pharo-project(a)lists.gforge.inria.fr > Message-ID: > <CCE85492-BBB6-4F08-BCC5-84F08A00FA5A(a)smalltalkconsulting.com> > Content-Type: text/plain; charset="us-ascii" > > You should look at the > > http://www.squeaksource.com/SystemTracing > SystemTracer64 writeImage: 'squeak64.image'. > > That is setup to take a 32bit image and create a 64bit image file by writing out all the bits... > >

Sept. 2, 2010

Re: [Pharo-project] Smalltalk Image writer?

by John M McIntosh

You should look at the http://www.squeaksource.com/SystemTracing SystemTracer64 writeImage: 'squeak64.image'. That is setup to take a 32bit image and create a 64bit image file by writing out all the bits... On 2010-09-01, at 6:26 PM, James Ladd wrote: > > >>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. > > > _______________________________________________ > 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 ===========================================================================

Sept. 2, 2010

[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