April 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Meanwhile, at another vm

by Michael Haupt

Hi Dave, On 14 April 2011 16:13, Dave Mason <dmason(a)mason-rose.ca> wrote: > I'n not sure what you mean that hotswap (or rather HotSwap) has been around since 1.4... do you perhaps mean HotSpot - the better jitter? no, that's around since 1.3 IIRC. :-) The HotSwap technology (i.e., the possibility to change method implementations at run-time) was introduced in the Java VM with the release of Java 1.4. What I don't understand is how HotSwap is supposed to be related to #become:. Also, JSR 292 does not change anything about that if I'm not totally mistaken. It introduces INVOKEDYNAMIC. The details at http://www.jcp.org/en/jsr/detail?id=292 do not give away anything related to HotSwap, schema changes or object identity exchange. But we're probably rather off-topic by now. ;-) Best, Michael

April 14, 2011

Re: [Pharo-project] Are you a Pharo contributor ??? [WAS] Re: Pharo Open Source Smalltalk â Contributors

by Mariano Martinez Peck

On Thu, Apr 14, 2011 at 4:26 PM, Serge Stinckwich < serge.stinckwich(a)gmail.com> wrote: > I think it's a great idea to have a picture and short description. > Maybe we could have something more uniform with the same size for each > picture ? > Yes sure, and maybe put a kind of table were each of us is a row, and all data is one column and the picture is another one. So they are aligned. But first the first :) Get the contributors and then we take care about the make up ehehe Laurent may be able to take care about the makeup ? Cheers Mariano > Regards, > > On Thu, Apr 14, 2011 at 8:46 PM, Mariano Martinez Peck > <marianopeck(a)gmail.com> wrote: > > if true...then what are you wainting for? > > > > http://www.pharo-project.org/community/contributors > > > > Send you data and nice picture :) > > > > Seriously, it is important for marketing among other things. Imagine you > > arrive to a new project...it is good to see that there are several > > contributing to it. Probably this page is not the best, but is something > > more. > > > > Mariano > > > > > > > > On Wed, Apr 13, 2011 at 8:18 PM, laurent laffont < > laurent.laffont(a)gmail.com> > > wrote: > >> > >> Added ! > >> Laurent. > >> On Wed, Apr 13, 2011 at 6:45 PM, Juan Vuletich <juan(a)jvuletich.org> > wrote: > >>> > >>> Hi Laurent, > >>> > >>> I'd like to be added to > >>> http://www.pharo-project.org/community/contributors . My picture is > >>> attached. Description text could be "Contributed the default > anti-aliased > >>> fonts and the SimpleMorphic UI framework. Web page at > www.jvuletich.org". > >>> > >>> Thank you. > >>> > >>> Cheers, > >>> Juan Vuletich > >> > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > > > > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/ > -- Mariano http://marianopeck.wordpress.com

April 14, 2011

Re: [Pharo-project] Meanwhile, at another vm

by Stefan Marr

Hi: On 14 Apr 2011, at 16:13, Dave Mason wrote: > On Apr 14, 2011, at 04:13, Michael Haupt wrote: > >> I'm puzzled; where is #become: mentioned as being implemented in that >> talk? It's mostly about INVOKEDYNAMIC, which is an entirely different >> thing. (They mention HotSwap on one slide, but that, as I wrote, has >> been around since 1.4, and is also not really #become:.) > > I'n not sure what you mean that hotswap (or rather HotSwap) has been around since 1.4... do you perhaps mean HotSpot - the better jitter? Hotswap, as in changing methods in a class. That is what the JVM supports, and that is what Michael is referring to. That is part of the JVM debuggers and tooling interface. That is part of the spec, not just an implementation detail of HotSpot. > I haven't dug into the fine details, but here is a post from 2006 by Gilad Bracha, sometimes contributor to this list: > > http://blogs.sun.com/gbracha/entry/jsr292_and_hotswapping > > and the update to it is the slides I cited say there is a patch to support hotswap currently as of Sept 2009. Hotswap for methods was introduced as part of the debugging API, and that was part of Java 1.4 with its JavaTM Platform Debugger Architecture... -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

April 14, 2011

Re: [Pharo-project] Are you a Pharo contributor ??? [WAS] Re: Pharo Open Source Smalltalk â Contributors

by Serge Stinckwich

I think it's a great idea to have a picture and short description. Maybe we could have something more uniform with the same size for each picture ? Regards, On Thu, Apr 14, 2011 at 8:46 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > if true...then what are you wainting for? > > http://www.pharo-project.org/community/contributors > > Send you data and nice picture :) > > Seriously, it is important for marketing among other things. Imagine you > arrive to a new project...it is good to see that there are several > contributing to it. Probably this page is not the best, but is something > more. > > Mariano > > > > On Wed, Apr 13, 2011 at 8:18 PM, laurent laffont <laurent.laffont(a)gmail.com> > wrote: >> >> Added ! >> Laurent. >> On Wed, Apr 13, 2011 at 6:45 PM, Juan Vuletich <juan(a)jvuletich.org> wrote: >>> >>> Hi Laurent, >>> >>> I'd like to be added to >>> http://www.pharo-project.org/community/contributors . My picture is >>> attached. Description text could be "Contributed the default anti-aliased >>> fonts and the SimpleMorphic UI framework. Web page at www.jvuletich.org". >>> >>> Thank you. >>> >>> Cheers, >>> Juan Vuletich >> > > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

April 14, 2011

[Pharo-project] Issue 4022 in pharo: Symbol readFrom:

by pharo＠googlecode.com

Status: FixProposed Owner: Benjamin...(a)gmail.com Labels: Milestone-1.3 New issue 4022 by Benjamin...(a)gmail.com: Symbol readFrom: http://code.google.com/p/pharo/issues/detail?id=4022 Symbol readFromString: '#''plop-plip''' returns #plop where it should return #'plop-plip' Attachments: Symbol class.BenjaminVanRyseghem.1.cs 576 bytes

April 14, 2011

Re: [Pharo-project] Meanwhile, at another vm

by Dave Mason

On Apr 14, 2011, at 04:13, Michael Haupt wrote: > I'm puzzled; where is #become: mentioned as being implemented in that > talk? It's mostly about INVOKEDYNAMIC, which is an entirely different > thing. (They mention HotSwap on one slide, but that, as I wrote, has > been around since 1.4, and is also not really #become:.) I'n not sure what you mean that hotswap (or rather HotSwap) has been around since 1.4... do you perhaps mean HotSpot - the better jitter? I haven't dug into the fine details, but here is a post from 2006 by Gilad Bracha, sometimes contributor to this list: http://blogs.sun.com/gbracha/entry/jsr292_and_hotswapping and the update to it is the slides I cited say there is a patch to support hotswap currently as of Sept 2009. Perhaps Gilad is listening, and can provide some context. ../Dave

April 14, 2011

[Pharo-project] Class Builder for Pharo, was Re: Improving Pharo's Exception Hierarchy

by Toon Verwaest

Be patient, be patient ;) I'm still very busy at the moment, but it'll get there. We'll probably have discuss if you want to generate slot and layout objects in the classbuilder, or if you want to replace the instanceVariables array with real layout objects that you keep around. We basically implemented everything around the layout objects and keep this data in all classes; but you'll have to figure out if you want this in Pharo or not. Decide and let me know, I'd say ;) cheers, Toon On 04/14/2011 04:07 PM, StÃ©phane Ducasse wrote: > I want this class builder :)

April 14, 2011

Re: [Pharo-project] Improving Pharo's Exception Hierarchy

by StÃ©phane Ducasse

I want this class builder :) On Apr 14, 2011, at 10:33 AM, Toon Verwaest wrote: > Somehow I feel like I offended someone :) > > I personally don't have experience with 10'000+ classes in a system. I do understand that's where you are coming from and do appreciate the insight. > > My personal experience has rather been the opposite until now. For example the Pharo/Squeak classbuilder is 1 single class doing everything. This is horrible; not just horrible because the code is completely horrid but it's non-extensible, non-configurable, non-reusable, contains tons of duplication _just because_ it is all put into one big ball of mud. By decomposing the classbuilder into 4 to 10 different classes I ended up having very little methods with very little code, and a very high level of configurability and understandability. I now actually use this classbuilder to build anonymous classes too, avoiding the whole problem with forgetting to copy in the format that everyone seems to have. > > And this experience was showing me that having classes for all _relevant_ concepts actually pays off in the long run. Since you (and others) are saying that it doesn't for exceptions; and since I don't have enough experience there I'll take your advice into account when writing code ;) > > Toon > > On 04/14/2011 01:00 AM, Dale Henrichs wrote: >> On 04/13/2011 02:58 PM, Toon Verwaest wrote: >>> Is it such a problem if you duplicate a certain exception class? At the >>> moment you'll do the same anyway by not completely writing the exact >>> same symbol. >> >> It's a simple matter of namespaces and volume of names ... with a large open ended namespace you are more likely to have a number of redundant names with slight differences in spelling showing up in different spots in the hierarchy...with a logically segmented namespace each segment will have a manageable number of names and the risk of duplication is reduced ... end of discussion ... >> >> 10,000 names vs 30 names ... I can easily recognize duplicates in a list of 30 names ... not so easy in 10,000 ... that is all ... >> >> to attempt to map every possible error condition onto a class will lead you to 10,000 much quicker than using reasonCodes ... that is all ... >> >> I don't hate classes, it is a _practical_ matter ... if _you_ would rather manage 10,000 names then I will say that it isn't practical ... I'm _not_ saying it is _wrong_, just not _practical_. >> >>> >>> And if the problem is not finding classes anymore, maybe we need a >>> better way of organizing the exception classes away from the standard >>> classes so that they are as non-intrusive as symbols, but convey more >>> information? >> >> And now you've hit the nail on the head ... in order to handle the extra complexity you need additional tools ... before creating more tools, ask your self the simple question: "Do I _need_ the additional complexity?" ... if the answer is yes, then create the tool, if the answer is no, then you don't need to create a new tool .. >> >> Again, this is a _practical_ matter... >> >>> >>> self error: #keyNotFound >>> does not really give much information; and isn't much more difficult to >>> write than: >>> KeyNotFoundException new in: self; key: key; signal >> >> From a practical perspective how many exception handlers will be written to handle KeyNotFoundException ... I use at:ifAbsent: when I'm doing a look up that I think might fail ... better than writing an exception handler ... >> >> If there is a real need to write a handler for KeyNotFoundException, then by all means create the class, but until you actually NEED KeyNotFoundException, `self error: #keyNotFound` or `NotFoundException signal: #keyNotFound` will work just fine... >>> >>> although the second one gives you all the contextual information that >>> the first one misses. >> >> _If_ you NEED the additional contextual information. It's just like writing a framework that no uses ... there's nothing wrong with the idea or the implementation, it's just that the framework didn't solve a problem that anyone had... >> >> If you are going to create a class, I think the least it should do is address an real problem, not an imaginary one. >> >> To say that "if one were to handle the KeyNotFoundException, they will need the complete context", I prefer to say "Until one needs the complete context of the KeyNotFoundException, don't bother creating class" >> >>> >>> What I mean mostly: what about trying to figure out why you want to >>> avoid decent exception classes and tackling that problem? >> >> Depends upon what your definition of a decent exception classes is? My argument is simply that it is not _necessary_ to create a unique class for every unique error condition ... I think that folks should answer the question: "Will anyone every write an exception handler for this exception" before creating the class ... if the answer is yes (or better yet, I am writing code right now and need that exception) then by all means create the class. >> >>> Maybe we don't want classes but exception objects that can pool data >>> together? Maybe a very silly idea: what about just exception "classes" >>> that have dictionaries to store enough information? >> >> That would be another way of doing things ... although using exception classes and reasonCodes is pretty close to all that is needed... >> >> I agree with the notion that it isn't that useful to have a single Error class and have all errors mapped to it ... on the other hand I don't think it is particularly useful to have an exception class for every possible error condition ... the compromise is to provide a smallish hierarchy of excpetion classes with fairly general structure, provide a means for uniquely identifying every possible error condition (I think that is important) and then add new classes to the hierarchy when a demand for the class is found ... >> >> > >

April 14, 2011

Re: [Pharo-project] Issue 4015 in pharo: Fix in SmalltalkEditor

by pharo＠googlecode.com

Updates: Status: FixProposed Comment #4 on issue 4015 by marcus.d...(a)gmail.com: Fix in SmalltalkEditor http://code.google.com/p/pharo/issues/detail?id=4015 ups, not yes

April 14, 2011

Re: [Pharo-project] Issue 3387 in pharo: Package name should not contain crptic characters

by pharo＠googlecode.com

Comment #8 on issue 3387 by marcus.d...(a)gmail.com: Package name should not contain crptic characters http://code.google.com/p/pharo/issues/detail?id=3387 Was the license agreement received?

April 14, 2011