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

Re: [Pharo-project] CrLfFileStream class>>new?!

by Henrik Sperre Johansen

On 09.03.2010 21:48, StÃ©phane Ducasse wrote: > It would be good to add that to the method and class comment. > Henrik? > > Stef Slice-CrLfFileStreamDeprecation in Inbox. Adds an explanation to class comment and in new method, reroutes the default-lineEnd methods, and deprecates basicNew just in case. Cheers, Henry

March 10, 2010

Re: [Pharo-project] [update 1.1] #11255

by Miguel Enrique CobÃ¡ Martinez

El mar, 09-03-2010 a las 22:40 +0100, StÃ©phane Ducasse escribiÃ³: > 11255 > ----- > > - added tests for the compiler to test shadowing of self, super, thisContext, true, false and nil. Thanks guys - we know you :) > > - Issue 2086: Introduce a cleanUp/cleanUp: protocol from squeak / keith idea! > MyClass class>>cleanUp: aggressive > This (class-side) method is called with an argument that indicates whether to do aggressive, i.e., potentially destructive cleanup. Doing aggressive cleanup will delete projects, change sets, uni-classes and more. Gentle cleanup is expected to only flush transient caches. If your class only has gentle cleanup you can simply implement > > MyClass class>>cleanUp > > By default #cleanUp: delegates to this method (similar to startUp/startUp: and shutDown/shutDown:). You can > run cleanup by executing: > > Smalltalk cleanUp. > Smalltalk cleanUp: true. > > Thanks luc for your analysis. After lunch in hot room is never that good for my brain :) > Cool, very good. Good to see this implemented at least. Can we then close: http://code.google.com/p/pharo/issues/detail?id=1778 as it appears to me that this solves it. Cheers -- Miguel CobÃ¡ http://miguel.leugim.com.mx

March 9, 2010

Re: [Pharo-project] [smalltalk-research] Re: [Esug-list] Google Summer Of Code 2010 news!!!

by Eliot Miranda

On Sun, Mar 7, 2010 at 3:24 PM, Gilad Bracha <gbracha(a)gmail.com> wrote: > I'm all for it, and hope that John or Eliot can mentor. I would like to mentor something in this area, but I think the basic goal of a cross-platform system is not achievable in GSoC this summer. A specification of a non-blocking architecture and a reference implementation may be possible. Cross-platform is too big for a summer project and will require input from dialects and vendors. What affects my thinking is the following: 1. I designed and implemented the VisualWorks THAPI system, a threaded extension to the VisualWorks FFI. 2. I have a functional prototype of a multi-threaded FFI for the Cog VM based on David Simmons' VMs. 1's architecture is poor, being complex, slow and not very general (allows only FFI calls to be threaded). 2's architecture is rather simple, rather fast and very general (allows threading to be much more widely used, e.g. calls within plugins can be made threaded by surrounding them with two calls, disownVM and ownVM). 3. I have looked at marshalling semantics in the context of the VW FFI, Andreas' Squeak FFI & Alien, and am still of the opinion, one shared by David, - that the generation of marshalling stubs has to be lifted up into Smalltalk based on simple ABI compilers that somehow (e.g. through RTL) communicate down to a JIT that generates and caches marshalling code (i.e. that VM attempts to interpret simplified call specs, as happens in the VM and Squeak FFIs are in general doomed to poor performance and bugs) - that type coercion code also has to be lifted (e.g. character conversions on strings, null termination, type coercion) - that one be able to depend on a pinning garbage collector to deal with the issues of passing objects through the FFI (although there are workaround hacks that can serve temporarily) I don't see the point of spending a GSoC trying to implement an obsolete (unthreaded, lowest-common-denominator) cross-platform FFI; it won't get used. I do see benefit in an open-source reference implementation that provides some of the above (at least threading/non-blocking). If people agree that an open-source reference implementation is worth pursuing, then I will happily mentor. What the starting point is will depend on to what extent Cog has been open sourced (Teleplace may choose to open source single-threaded Cog initially, keeping back the threaded FFI for a while, it may not open source Cog at all; we'll see :) ). There are other starting points (current Squeak VMs, GST, Newspeak). But the outline above is a move towards better cross-platform commonality, not less, because it's an architecture in which the image does more (type coercion, compiling call signatures to RTL sequences) and the VM (except for the threading ;) ) does less. And so this direction does lead towards better cross-platform facilities. best Eliot

March 9, 2010

Re: [Pharo-project] [update 1.1] #11255

by Igor Stasenko

On 10 March 2010 00:58, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2010/3/9 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> >> >> On Tue, Mar 9, 2010 at 10:40 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> >>> 11255 >>> ----- >>> >>> - added tests for the compiler to test shadowing of self, super, >>> thisContext, true, false and nil. Thanks guys - we know you :) >>> >>> - Issue 2086: Â Introduce a cleanUp/cleanUp: protocol from squeak / keith >>> idea! >>> Â Â Â Â MyClass class>>cleanUp: aggressive >>> Â Â Â Â This (class-side) method is called with an argument that indicates >>> whether to do aggressive, i.e., potentially destructive cleanup. Doing >>> aggressive cleanup will delete projects, change sets, uni-classes and more. >>> Gentle cleanup is expected to only flush transient caches. If your class >>> only has gentle cleanup you can simply implement >>> >>> Â Â Â MyClass class>>cleanUp >>> >>> By default #cleanUp: delegates to this method (similar to startUp/startUp: >>> and shutDown/shutDown:). You can >>> run cleanup by executing: >>> >>> Â Â Â Smalltalk cleanUp. >>> Â Â Â Smalltalk cleanUp: true. >>> >> >> It seems there is a problem as cleanUp or cleanUp:Â are implemented in >> SmalltalkImageÂ but not in SystemDictionary...so evaluating >> >> Â Â Â Smalltalk cleanUp. >> Â Â Â Smalltalk cleanUp: true. >> >> gives a DNU. >> > > Yep, in trunk Smalltalk class = SmalltalkImage, so it just works > Maybe pharo want this change too ? > I think this would be great. > Nicolas > >> Another question....wouldn't be a good idea to add at least aÂ "Smalltalk >> cleanUp. "Â in ScriptLoader >> cleanUpForReleaseÂ Â ???Â or similar.... >> >> Cheers >> >> Mraiano >> >> >> >>> >>> Thanks luc for your analysis. After lunch in hot room is never that good >>> for my brain :) >>> >>> >>> Stef >>> _______________________________________________ >>> 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 > -- Best regards, Igor Stasenko AKA sig.

March 9, 2010

Re: [Pharo-project] Fwd: Pharo by Example vol 2: new chapter available

by Mariano Martinez Peck

2010/3/9 Hernan Wilkinson <hernan.wilkinson(a)gmail.com> > I haven't read the chapter yet, but there is something that bothers me a > little about the Exception hierarchy... what I've seen lately is that > Exceptions are not used only as exceptions but as a why to get context > information (for example Seaside with WACurrentRequestContext), notify about > an event (for example the Notification class and subclasses), etc. > Despite if it is a good idea to solve this issues with exceptions, calling > Exception to the root of the hierarchy makes a lot of noise (at least to > me... I mean, a Notification is not an Exception, something you were not > expecting... getting the current context has nothing to do with an > exception...)... So, have you think about changing the name to that class > and making the protocol simpler (at least for the root of the hierarchy) so > all these types of uses fit better than they do today? (for example, > retrying a notification looks like no sense, the same for > wacurrentrequestcontext) > I think that the idea of "crawling" on the execution stack or the execution > flow have more sense as metaphor to look for another name... > Anyway, just a thought. > +1. > Bye, > Hernan. > > 2010/3/3 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > Thanks laurent >> >> Stef >> >> >> Begin forwarded message: >> >> *From: *laurent laffont <laurent.laffont(a)gmail.com> >> *Date: *March 3, 2010 10:09:32 PM GMT+01:00 >> *To: *StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> *Subject: **Re: [Pharo-project] Pharo by Example vol 2: new chapter >> available* >> >> Some notes: >> >> Page 1: The basic idea behing exception .... I would expect a schema to >> show the workflow. >> >> Page 8: When an exception is signaled, the exception handling mechanism >> ....I've read it 3 times (for something finally quite simple), maybe it >> needs a sequence diagram or reformulation. >> >> Section 1.15: How exceptions are implemented. I had to read several times >> to understand, lot of informations to handle at once. >> >> Page 27 (bottom): For example, in method 1.1 ... specify "on page 19" or >> put the snippet again so we can easily compare with method 1.2. >> >> I like the "real code" examples. The "How..." sections too. >> >> When not to use Exceptions: not to "hide errors". I have too many times >> seen try ... catch ... to hide errors to the users. >> >> Maybe add a "When to use Exceptions" section, reminding the "Crash early" >> principle. >> >> Laurent Laffont >> >> >> On Tue, Mar 2, 2010 at 2:26 PM, StÃ©phane Ducasse < >> stephane.ducasse(a)inria.fr> wrote: >> >>> Hi guys >>> >>> We just released a new chapter for Pharo by Example Vol.2 on Exceptions >>> http://pharobyexample.org/ >>> >>> Let us know what you think. >>> >>> Stef >>> >>> _______________________________________________ >>> 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 >

March 9, 2010

Re: [Pharo-project] [update 1.1] #11255

by Nicolas Cellier

2010/3/9 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > On Tue, Mar 9, 2010 at 10:40 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> 11255 >> ----- >> >> - added tests for the compiler to test shadowing of self, super, >> thisContext, true, false and nil. Thanks guys - we know you :) >> >> - Issue 2086: Â Introduce a cleanUp/cleanUp: protocol from squeak / keith >> idea! >> Â Â Â Â MyClass class>>cleanUp: aggressive >> Â Â Â Â This (class-side) method is called with an argument that indicates >> whether to do aggressive, i.e., potentially destructive cleanup. Doing >> aggressive cleanup will delete projects, change sets, uni-classes and more. >> Gentle cleanup is expected to only flush transient caches. If your class >> only has gentle cleanup you can simply implement >> >> Â Â Â MyClass class>>cleanUp >> >> By default #cleanUp: delegates to this method (similar to startUp/startUp: >> and shutDown/shutDown:). You can >> run cleanup by executing: >> >> Â Â Â Smalltalk cleanUp. >> Â Â Â Smalltalk cleanUp: true. >> > > It seems there is a problem as cleanUp or cleanUp:Â are implemented in > SmalltalkImageÂ but not in SystemDictionary...so evaluating > > Â Â Â Smalltalk cleanUp. > Â Â Â Smalltalk cleanUp: true. > > gives a DNU. > Yep, in trunk Smalltalk class = SmalltalkImage, so it just works Maybe pharo want this change too ? Nicolas > Another question....wouldn't be a good idea to add at least aÂ "Smalltalk > cleanUp. "Â in ScriptLoader >> cleanUpForReleaseÂ Â ???Â or similar.... > > Cheers > > Mraiano > > > >> >> Thanks luc for your analysis. After lunch in hot room is never that good >> for my brain :) >> >> >> Stef >> _______________________________________________ >> 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 >

March 9, 2010

Re: [Pharo-project] [update 1.1] #11255

by Mariano Martinez Peck

On Tue, Mar 9, 2010 at 10:40 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > 11255 > ----- > > - added tests for the compiler to test shadowing of self, super, > thisContext, true, false and nil. Thanks guys - we know you :) > > - Issue 2086: Introduce a cleanUp/cleanUp: protocol from squeak / keith > idea! > MyClass class>>cleanUp: aggressive > This (class-side) method is called with an argument that indicates > whether to do aggressive, i.e., potentially destructive cleanup. Doing > aggressive cleanup will delete projects, change sets, uni-classes and more. > Gentle cleanup is expected to only flush transient caches. If your class > only has gentle cleanup you can simply implement > > MyClass class>>cleanUp > > By default #cleanUp: delegates to this method (similar to startUp/startUp: > and shutDown/shutDown:). You can > run cleanup by executing: > > Smalltalk cleanUp. > Smalltalk cleanUp: true. > > It seems there is a problem as cleanUp or cleanUp: are implemented in SmalltalkImage but not in SystemDictionary...so evaluating Smalltalk cleanUp. Smalltalk cleanUp: true. gives a DNU. Another question....wouldn't be a good idea to add at least a "Smalltalk cleanUp. " in ScriptLoader >> cleanUpForRelease ??? or similar.... Cheers Mraiano > Thanks luc for your analysis. After lunch in hot room is never that good > for my brain :) > > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 9, 2010

Re: [Pharo-project] about the hudson server

by Yanni Chiu

stephane ducasse wrote: > http://hudson.jooshr.org/job/Pharo1.1/81/ > is it because the tests cannot run? It builds and runs the tests now (with some failure reports). In build#82, I saw in the stack trace some EOCD message, which usually means some kind of package missing, corruption, or download problem. I cleared the package-cache and got the same problem. It was updating from PharoCore-1.1-11239-UNSTABLE, so I changed to the latest: PharoCore-1.1-11254-UNSTABLE.1, and now the build/test works. There probably were no updates to be applied to 11254, so of course the build worked.

March 9, 2010

Re: [Pharo-project] ESUG gentle actions reminder

by Igor Stasenko

On 9 March 2010 23:49, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Dear Smalltalkers of all dialects! > > In a time where Â Â Â Â we are bombarded with information and may be misinformed :), > some of you may not notice that ESUG is doing a great job pushing Smalltalk, we thought that it is good > Â to get a gentle reminder on the main actions ESUG performed in the past. http://www.esug.org > Yes we have been busy promoting the language we all love. :) > > The board. > I hardly believe that there is anyone who thinks that ESUG is evil :) -- Best regards, Igor Stasenko AKA sig.

March 9, 2010

Re: [Pharo-project] VM crash on Windows

by Schwab,Wilhelm K

David, The rebuttal: if it has time/ability to write information all over part of the screen, it can open a file and make sure it leaves a trace of what happened. Right? The current vms (Windows and Linux) appear to be totally disinterested in logging crashes, and that needs to change. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of David T. Lewis Sent: Monday, March 08, 2010 8:09 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] VM crash on Windows On Mon, Mar 08, 2010 at 07:47:16PM -0500, Schwab,Wilhelm K wrote: > Hello all, > > Good news/bad news: I got it running again :) I have no idea what was > wrong, nor what is right now :( > > A corrupt image file is not out of the question. I was having huge problems with Ubuntu (perhaps Linux in general??[*]) and cifs writing to windows shares. That problem suddenly went away some weeks ago, but maybe it is simply less frequent now?? Nearly the same image was running just fine on a sibling box, and copying the image from there to the offending machine got me going again. > > What bothers me here is not so much that Pharo crashed but that it did it so abruptly and without logging anything that I could find. Suggestions would be most welcome. Bill, Whatever is wrong, it is probably not the fault of the Pharo image. When the VM crashes abruptly with no log file generated, it is most likely because it encountered an access violation (segfault) error in some plugin or in an FFI call. If you get a hard failure like that, the image is not able to write the debug log file (because it is already dead - d'oh!). I think that various people have reported problems with virus scanners and that sort of thing on windows. And it is possible that running on network file systems (cifs etc) will expose bugs that do not show up when running on local file systems. I think you're going to be stuck doing some good old process of elimination work here :( Dave _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 9, 2010