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

Re: [Pharo-project] Issue 1042 in pharo: documentation/help menu

by pharo＠googlecode.com

Comment #3 on issue 1042 by tony.fleig: documentation/help menu http://code.google.com/p/pharo/issues/detail?id=1042 There is indeed a Help item in the World menu, but it does not lead to anywhere that shortcut keys are listed. The original issue, i.e. that the list of shortcut keys is nowhere available has not been addressed. I think this issue should be re-opened. I agree wholeheartedly that this list is of immense value to newcomers to the system and should be available and easy to find.

Dec. 12, 2010

Re: [Pharo-project] Loading *some of* a MC snapshot into the image

by Damien Pollet

On Sun, Dec 12, 2010 at 09:42, Lukas Renggli <renggli(a)gmail.com> wrote: > 1. From the merge dialog you individually pick and install the changes > that work. In the old merge dialog this works nicely. Actually I tried to do something like that, but the menu items were all disabled in the merge tool. So I guess I have the new merge dialog, yay :D > Lukas > > On 12 December 2010 04:37, Damien Pollet <damien.pollet(a)gmail.com> wrote: >> I have a snapshot compiled against an old version of PetitParser. >> Unfortunately one of my classes now has a conflicting inst var with >> the most recent PetitParser, so my code does not load, MC explodes >> instead of giving me a chance to fix the problem on the fly. Of >> course, there are quite a few changes I'd like to rescue in that >> snapshot. Please don't tell me I have to copy-paste them allâ¦ >> >> -- >> Damien Pollet >> type less, do more [ | ] http://people.untyped.org/damien.pollet >> >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Dec. 12, 2010

Re: [Pharo-project] Ring - model infrastructure for Pharo

by Igor Stasenko

On 12 December 2010 08:41, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Dec 11, 2010, at 8:35 PM, Igor Stasenko wrote: > >> CompiledMethod>>#methodNode >> is a conversion method >> and as any conversion i would prefer it be prefixed with 'as' , i.e. >> #asMethodNode >> >> #stringVersion is used only in MessageTrace in my image. >> >> Concerning #stringVersion: >> i really don't have an idea what this stuff doing there? >> Why a method reference allows putting an arbitrary data (strings) >> there by various tools? > > :) > > because it was handy and cool to have a holder of anything from the tools point of view. > And this is why we will clean that :) > >> >> Then maybe better call it 'annotation' , and correspondingly #defaultAnnotation, >> so we will know that this field used for annotations by different tools? > > > >> >> About #isMeta and friends: >> they serve nothing , but introducing a lot of ad-hoc logic with code >> branches all over the places. >> We should learn how to use message dispatching better :) > > this is not always that simple. > >> IMO, the 'theClass' ivar should be capable answering this message, >> along with #name, which gives the name of a class. >> Method reference in its 'theClass' ivar instead of symbol, should hold >> either real class object (or metaclass object), > > No because you can be analysing an off-image > code or not yet installed code. So you cannot rely on the fact that the real class is reachable. > i see no problem with offline representation. You still won't need 'isMeta' in method definition, because you have a following model: instance side method ref -> some class proxy class side method ref -> some metaclass proxy sure you can leave #isMeta in method reference which simply redirects the request to its 'theClass' variable: isMeta ^ theClass isMeta voila. A CompiledMethod makes no difference between class/metaclass, its only holds a reference to the behavior it installed in: method := (Object class>>#initialize). method methodClass ---> Object class method methodClass isMeta ---> true (Object class>>#initialize) methodClass name ---> 'Object class' So, since method references representing the CompiledMethod, they should not care as well. >> or a proxy (in same way as method reference is a proxy by itself). >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > -- Best regards, Igor Stasenko AKA sig.

Dec. 12, 2010

Re: [Pharo-project] Redline: Smalltalk in 'small talks' ...

by Luc Fabresse

That's a great initiative. I will read your blog regularly to know the progress of Redline Smalltalk. Thanks, #Luc 2010/12/12 Noury Bouraqadi <bouraqadi(a)gmail.com> > > On 12 dÃ©c. 2010, at 04:08, James Ladd wrote: > > > The series of posts on implementing Redline Smalltalk for the Java > Virtual Machine has begun. > > You can code along and influence the direction of Redline. > > > > > http://blog.redline.st/2010/12/12/redline-smalltalk-in-%E2%80%9Csmall-talks… > > Cool. > > Noury > > >

Dec. 12, 2010

Re: [Pharo-project] Ring - model infrastructure for Pharo

by Noury Bouraqadi

1 ring to rule all meta-models. Cool :-) I struggled with MC and its meta-model while working with on the Clic project. In Clic I changed the class definition message. But, MC does not support such situations. So, I ended up doing some complex workarounds. Hope that Ring will help solving such situations. Noury On 10 dÃ©c. 2010, at 14:32, Veronica Isabel Uquillas Gomez wrote: > Dear all, > > I am currently working on the Ring, an unifying and foundational model infrastructure for Pharo. > The goals are: > - Provide a common API at structural and runtime level > - Allow tools to interact and integrate directly with the host environment (Pharo) > - Support history analysis > > I started comparing the APIs of RB, MethodReference, Pseudo classes, MC, Smalltalk itself and Ginsu, as a basic to build the Ring. > So far I have implemented the main classes including the ones that should replace MethodReference and the Pseudo classes. > > An unified API will imply changes in most of the ones mentioned above (as most of them are non-polymorphic). > As a first step, I would like to have your opinion about the proposal for replacing MethodReference (attached file). > > > Best Regards, > Veronica Uquillas > > <Ring-forMethodReference.pdf> > > > > > >

Dec. 12, 2010

Re: [Pharo-project] good news of the year

by Geert Claes

This is excellent! It is wonderful for INRIA to invest in Pharo! Congrats Igor and enjoy your time in Lille ... you must try a Belgian beer called Duvel, best beer in the world :) I see the TO-DO list is already pretty long, it would be great if there is time for a better SqueakSource/Monticello 2 -- View this message in context: http://forum.world.st/good-news-of-the-year-tp3083142p3084152.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 12, 2010

Re: [Pharo-project] good news of the year

by Sven Van Caekenberghe

On 11 Dec 2010, at 18:40, Igor Stasenko wrote: > Thanks everyone. > > I had very warm and friendly greeting here in Lille. And atmosphere is > very cool (everyone around you using pharo). > I am a full of enthusiasm and energy to put in Pharo, as never before. ;) > > > -- > Best regards, > Igor Stasenko AKA sig. This is indeed great news for Pharo. Congratulations, Igor, you are a lucky guy. I am sure this will make a positive difference. Sven

Dec. 12, 2010

Re: [Pharo-project] good news of the year

by Noury Bouraqadi

Welcome Igor to the North of France :-) Noury On 11 dÃ©c. 2010, at 10:46, StÃ©phane Ducasse wrote: > Hi all > > We have a really good news for pharo. Igor got a job as engineer in our team for two years. > We are really thankful to INRIA for that. Since we want to be transparent here is the way we plan to work. > We asked igor to help fixing bug fixes for about 20% of his time. > And to focus on larger items. Here is a list based on the brainstorming we did and what we told INRIA > igor would do. > Now if you want to help and join effort with us this is even better. > > Now igor started to work on OPAL because we would like to have it for a beta in january, when we will get a new unstable > stream. > > Stef > > -- Set nil > -- Hashed Collection > -- dictionary are slower > -- Generalize stream protocol #readInto:startingAt:count: > > -- WeakStructure > -- Finalizer > -- Chapter on Finalizer > > -- Better integration process > > -- EventSensor > polling > - publish a windows VM that support it > > -- ClassBuilder rewrite > > -- Helping improving the VM > - cleaner code > > -- Cleaning events/annoucement > check CUIS > on:send: > changed:/update > > -- SystemChangeNotification -> announcement > sync with Cyrille > review with Cyrille > > -- Using RPackage in Monticello > sync with cyrille > > -- iSqueak New event hierarchy > Alain imported that > Multitouch? > > -- New compiler > -- debug > -- Decompiler IR -> AST > -- Cleanups > -- API > -- Environment > > -- ROME API > - API stablisation: openVG > - system rewrite to use API > > -- Ephemerons ?? > > -- Announcement with weak structure > > -- Networks > - may be use WeakFinalizer here. > - looking at Andreas fixes in Squeak > > >

Dec. 12, 2010

Re: [Pharo-project] Redline: Smalltalk in 'small talks' ...

by Noury Bouraqadi

On 12 dÃ©c. 2010, at 04:08, James Ladd wrote: > The series of posts on implementing Redline Smalltalk for the Java Virtual Machine has begun. > You can code along and influence the direction of Redline. > > http://blog.redline.st/2010/12/12/redline-smalltalk-in-%E2%80%9Csmall-talks… Cool. Noury

Dec. 12, 2010

Re: [Pharo-project] A suggestion.

by Noury Bouraqadi

I suggest that asDate shouldn't be part of the kernel. Noury On 10 dÃ©c. 2010, at 18:59, csrabak(a)bol.com.br wrote: > I second your first assertion. However, although I find Chronos a fine package, > I feel this is an interim solution, because we've other places we need i18n support, > I propose this as subject for the next IRC meeting! > > -- > Cesar Rabak > > > Em 10/12/2010 11:58, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr > escreveu: > The problem is that we should not change kernel methods. > I suggest that we use chronos or chalten for localized applications. > > Stef > > >> Hi folks. >> >> First make a question, in this list. >> >> String>>asDate message assume(harcode way) english date format.. may be.. >> may be better if the date format to take it to a context variable as with the names of the months? >> >> Best.. > > > >

Dec. 12, 2010