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

Re: [Pharo-project] Another RB engine change

by Yanni Chiu

I don't use omnibrowser on Pharo-1.0, but I was still building it. See: http://hudson.jooshr.org/job/Pharo1.0-Seaside3.0/200/testReport/ I checked only a few of the stacktraces on the 404 newly failing tests, and they were all: SystemDictionary(Object)>>doesNotUnderstand: #globals Maybe the simplest thing to do is a maintenance patch to Pharo-1.0 with an implementation for Smalltalk>>globals. Lukas Renggli wrote: > I fixed that and about 30 other occurrences of the same problem. > > Name: Refactoring-Core-lr.147 > Author: lr > Time: 23 July 2010, 8:14:01 am > UUID: 8e608df4-579d-4a3d-a589-0eb90109275e > Ancestors: Refactoring-Core-lr.146 > > - fixed numerous occurrences where the old 'Smalltalk' was used > > Thank you for pointing out. > > Lukas > > On 23 July 2010 00:01, Fernando olivero <oliverof(a)lu.unisi.ch> wrote: >> Hi Lukas, here is another change in the RB engine package. >> >> RBClass>>realName: aSymbol >> self realClass: (Smalltalk at: aSymbol) >> >> => >> self realClass: (Smalltalk globals at: aSymbol) >> >> Fernando >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > >

July 23, 2010

Re: [Pharo-project] What is correct way to save image automatically in background?

by David T. Lewis

Yes, it really is true. That said, I would expect the practical impact to vary depending on how busy the main image is. If you are running a Squeak/Pharo image that is not busy, such as your own personal desktop image or a Seaside image that is not currently receiving requests, then the additional system memory used by the forked background image is extremely small (it's pretty amazing actually, try watching it on a system monitor such as xosview). However, I would expect that if you were to do this with a busy Seaside image, then that image would be doing a lot of updates to memory and possibly garbage collection, so that will force the OS to use more memory. Unfortunately this means that the busier your image is, the less benefit you get from a memory usage point of view. But even at that, you still get the advantage of doing the image save in a background OS process running at lower OS scheduling priority. I do not actually run any Seaside server images, so someone would need to try this on a real system to find out how much benefit it delivers in practice. I would be interested to know the results. Dave On Fri, Jul 23, 2010 at 02:12:14PM +0200, Lukas Renggli wrote: > David, is what is said about memory management really true? I thought > that saving the image triggered a garbage collect what forces to copy > the whole memory anyway. > > Lukas > > On 23 July 2010 14:00, David T. Lewis <lewis(a)mail.msen.com> wrote: > > On Fri, Jul 23, 2010 at 09:49:46AM +0200, Lukas Renggli wrote: > >> > But How I can do that without fork? I track changes in another process and > >> > when I do update I save image in this process. > >> > How I can initiate image saving from ui process? > >> > >> I don't understand what you are saying. > >> > >> The thing is that using #fork to save the image has no effect (other > >> than wrecking the image), because #snapshot:andQuit: is eventually > >> calling a primitive that locks the complete VM anyway. > >> > >> If you want to fork while saving the image you need to use an OS-level > >> fork, not a Smalltalk-level fork. You can do this with OSProcess for > >> example (check the Seaside mailing-list archive). > > > > "UnixProcess saveImageInBackgroundNicely" > > > > Explained in the method comment: > > > > UnixProcess class>>saveImageInBackground: savedImageName nice: niceFlag > > ? ? ? ?"When Squeak is used as a server it is sometimes desirable to periodically > > ? ? ? ?save image snapshots. This method forks a headless Squeak to perform a > > ? ? ? ?snapshot without impacting the server Squeak. Very little additional memory > > ? ? ? ?is required to do this because Unix copy-on-write memory management allows > > ? ? ? ?the two Squeak images to share object memory while the save is performed. > > ? ? ? ?The saved image is given a time stamped name, and the image name of > > ? ? ? ?the main server Squeak remains unchanged. If niceFlag is true, the > > ? ? ? ?background OS process runs at lowered scheduling priority." > > > > Dave > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 23, 2010

Re: [Pharo-project] Literal array with evaluated value of stmts, vars etc..

by StÃ©phane Ducasse

On Jul 23, 2010, at 4:36 PM, Henrik Johansen wrote: > > On Jul 23, 2010, at 3:14 31PM, StÃ©phane Ducasse wrote: > >> ok not this is not what we have with MenuIcons? >> >> Stef > > A close cousin, I would say. Yes this is a distributed version. > Assets > - saves the need for the separate Contents/Icon methods and an Icons dictionary, due to once usage. > - utilizes pragma instead of method names/comments for imported file names, so you can rename your methods and still sync with the correct file. so the pragma are more for doing a rebuild. > - keeps an md5 hash, so you can update only those methods for which the on-disk resource has actually changed. what is the license? Stef > > Cheers, > Henry > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 23, 2010

Re: [Pharo-project] Literal array with evaluated value of stmts, vars etc..

by Henrik Johansen

On Jul 23, 2010, at 3:14 31PM, StÃ©phane Ducasse wrote: > ok not this is not what we have with MenuIcons? > > Stef A close cousin, I would say. Assets - saves the need for the separate Contents/Icon methods and an Icons dictionary, due to once usage. - utilizes pragma instead of method names/comments for imported file names, so you can rename your methods and still sync with the correct file. - keeps an md5 hash, so you can update only those methods for which the on-disk resource has actually changed. Cheers, Henry

July 23, 2010

Re: [Pharo-project] Invalid utf8 input detected: now what?

by Schwab,Wilhelm K

No dialogs, please :) Actually, it would be fine if there were a different stream class or simply a different method/state (encoding =#userInteraction or something??) that is understood to negotiate such details with "the user." In general, exception is the correct way to handle this: the stream "knows" what is wrong; the application will know what to make of it. If the encoding can be detected automatically, that would be great. Firefox tells me that the encoding is ISO-8859-1; I am not leaving off the 5, Firefox and gedit report it differently. In fairness to gedit, I am reporting the encodings listed in its save-as dialog. Unfortunately the offending file contains specifications that are not mine. I have seen pieces of it published elsewhere (quite recently in fact) but will need to do some checking on the licensing. I might be able to excerpt the file and end up with the same behavior. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Henrik Johansen [henrik.s.johansen(a)veloxit.no] Sent: Friday, July 23, 2010 7:39 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Invalid utf8 input detected: now what? On Jul 23, 2010, at 4:09 30AM, Schwab,Wilhelm K wrote: > Hello all, > > I got an error (on Ubuntu 9.10) trying open an old text file that I created on Windows some time ago. The encoding (if gedit's save-as dialog can be trusted??) is Western ISO-8859-15; resaving as utf8 lets me read it. > > So, is Pharo working by design? Did I do the correct/only thing needed to read the file? What should I be asking? Is there anything I can do to turn this into a useful test/debugging example? > > Bill > This is not an error per se, seeing as the encoding is not utf8 :) If the import was done from some tool instead of in your code (in which case you'd set the encoding of the file stream), a nicer *behavior* might be for the UI Manager to catch encoding errors when trying to read a file, and offer up a dialogue with a list of encodings which the file *can* be read as, along with a preview window of what the text would look like with the selected encoding, like some word processors do. Cheers, Henry _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 23, 2010

Re: [Pharo-project] Literal array with evaluated value of stmts, vars etc..

by StÃ©phane Ducasse

ok not this is not what we have with MenuIcons? Stef On Jul 23, 2010, at 2:30 PM, Henrik Johansen wrote: > > On Jul 23, 2010, at 9:24 38AM, StÃ©phane Ducasse wrote: > >>> I really like Assets. The whole framework is small, flexible, useful and easy to understand. >> what is assets? >> >> Stef > > A really small and neat external resource-management framework in VisualWorks. > > Its relation to once is being the original use case. > > I've attached the class comment from VW, which explains how it works pretty well :) > <Assets.rtf> > > There's also this screencast, which shows off the RB integration, and caching speedup due to once use: > http://www.cincomsmalltalk.com/userblogs/travis/files/assetsOne.mov > and this blogpost, explaining once: > http://www.cincomsmalltalk.com/userblogs/travis/blogView?entry=3346567529 > > Cheers, > Henry_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 23, 2010

Re: [Pharo-project] Literal array with evaluated value of stmts, vars etc..

by Henrik Johansen

On Jul 23, 2010, at 9:24 38AM, StÃ©phane Ducasse wrote: >> I really like Assets. The whole framework is small, flexible, useful and easy to understand. > what is assets? > > Stef A really small and neat external resource-management framework in VisualWorks. Its relation to once is being the original use case. I've attached the class comment from VW, which explains how it works pretty well :) There's also this screencast, which shows off the RB integration, and caching speedup due to once use: http://www.cincomsmalltalk.com/userblogs/travis/files/assetsOne.mov and this blogpost, explaining once: http://www.cincomsmalltalk.com/userblogs/travis/blogView?entry=3346567529 Cheers, Henry

July 23, 2010

Re: [Pharo-project] What is correct way to save image automatically in background?

by Lukas Renggli

David, is what is said about memory management really true? I thought that saving the image triggered a garbage collect what forces to copy the whole memory anyway. Lukas On 23 July 2010 14:00, David T. Lewis <lewis(a)mail.msen.com> wrote: > On Fri, Jul 23, 2010 at 09:49:46AM +0200, Lukas Renggli wrote: >> > But How I can do that without fork? I track changes in another process and >> > when I do update I save image in this process. >> > How I can initiate image saving from ui process? >> >> I don't understand what you are saying. >> >> The thing is that using #fork to save the image has no effect (other >> than wrecking the image), because #snapshot:andQuit: is eventually >> calling a primitive that locks the complete VM anyway. >> >> If you want to fork while saving the image you need to use an OS-level >> fork, not a Smalltalk-level fork. You can do this with OSProcess for >> example (check the Seaside mailing-list archive). > > "UnixProcess saveImageInBackgroundNicely" > > Explained in the method comment: > > UnixProcess class>>saveImageInBackground: savedImageName nice: niceFlag > Â Â Â Â "When Squeak is used as a server it is sometimes desirable to periodically > Â Â Â Â save image snapshots. This method forks a headless Squeak to perform a > Â Â Â Â snapshot without impacting the server Squeak. Very little additional memory > Â Â Â Â is required to do this because Unix copy-on-write memory management allows > Â Â Â Â the two Squeak images to share object memory while the save is performed. > Â Â Â Â The saved image is given a time stamped name, and the image name of > Â Â Â Â the main server Squeak remains unchanged. If niceFlag is true, the > Â Â Â Â background OS process runs at lowered scheduling priority." > > Dave > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch

July 23, 2010

Re: [Pharo-project] What is correct way to save image automatically in background?

by David T. Lewis

On Fri, Jul 23, 2010 at 09:49:46AM +0200, Lukas Renggli wrote: > > But How I can do that without fork? I track changes in another process and > > when I do update I save image in this process. > > How I can initiate image saving from ui process? > > I don't understand what you are saying. > > The thing is that using #fork to save the image has no effect (other > than wrecking the image), because #snapshot:andQuit: is eventually > calling a primitive that locks the complete VM anyway. > > If you want to fork while saving the image you need to use an OS-level > fork, not a Smalltalk-level fork. You can do this with OSProcess for > example (check the Seaside mailing-list archive). "UnixProcess saveImageInBackgroundNicely" Explained in the method comment: UnixProcess class>>saveImageInBackground: savedImageName nice: niceFlag "When Squeak is used as a server it is sometimes desirable to periodically save image snapshots. This method forks a headless Squeak to perform a snapshot without impacting the server Squeak. Very little additional memory is required to do this because Unix copy-on-write memory management allows the two Squeak images to share object memory while the save is performed. The saved image is given a time stamped name, and the image name of the main server Squeak remains unchanged. If niceFlag is true, the background OS process runs at lowered scheduling priority." Dave

July 23, 2010

Re: [Pharo-project] Invalid utf8 input detected: now what?

by Henrik Johansen

On Jul 23, 2010, at 4:09 30AM, Schwab,Wilhelm K wrote: > Hello all, > > I got an error (on Ubuntu 9.10) trying open an old text file that I created on Windows some time ago. The encoding (if gedit's save-as dialog can be trusted??) is Western ISO-8859-15; resaving as utf8 lets me read it. > > So, is Pharo working by design? Did I do the correct/only thing needed to read the file? What should I be asking? Is there anything I can do to turn this into a useful test/debugging example? > > Bill > This is not an error per se, seeing as the encoding is not utf8 :) If the import was done from some tool instead of in your code (in which case you'd set the encoding of the file stream), a nicer *behavior* might be for the UI Manager to catch encoding errors when trying to read a file, and offer up a dialogue with a list of encodings which the file *can* be read as, along with a preview window of what the text would look like with the selected encoding, like some word processors do. Cheers, Henry

July 23, 2010