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

Re: [Pharo-project] [ANN] New Reef page and Tutorial available

by StÃ©phane Ducasse

Cool we want more :) Yes :) May be after we could turn that into a chapter for the book. Stef > Hi, > As I promised at ESUG 2010, I created a page to keep Reef information and documentation... > You can see it here: http://www.smallworks.com.ar/en/community/Reef > > Also, I began to write a tutorial for Reef, the first part is here: http://www.smallworks.com.ar/en/community/Reef/reefSimpleTutorialPart1 > And the slides for the presentation is here: http://www.slideshare.net/EstebanLM/reef-esug-2010 > > > Cheers, > Esteban > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 8, 2010

[Pharo-project] [ANN] New Reef page and Tutorial available

by Esteban Lorenzano

Hi, As I promised at ESUG 2010, I created a page to keep Reef information and documentation... You can see it here: http://www.smallworks.com.ar/en/community/Reef Also, I began to write a tutorial for Reef, the first part is here: http://www.smallworks.com.ar/en/community/Reef/reefSimpleTutorialPart1 And the slides for the presentation is here: http://www.slideshare.net/EstebanLM/reef-esug-2010 Cheers, Esteban

Oct. 8, 2010

[Pharo-project] Error: subscript is out of bounds: 2

by HernÃ¡n Morales Durand

Hi all, When I evaluate Compiler compile: '|' in an old version like PharoCore1.1ALPHA #11106 brings a Syntax Error window with the message " |Argument name expected -> " Now in Pharo1.2a #12186 or Pharo1.1rc2 #11400 I get a Debugger with the message "Error: subscript is out of bounds: 2". This happens in latest Squeak too. Apparently the parser is catching the exception but the #notify:at: method is not reading the source contents in a proper way when creating the SyntaxErrorNotification. Is this a known bug? -- HernÃ¡n Morales Information Technology Manager, Institute of Veterinary Genetics. National Scientific and Technical Research Council (CONICET). La Plata (1900), Buenos Aires, Argentina. Telephone: +54 (0221) 421-1799. Internal: 422 Fax: 425-7980 or 421-1799.

Oct. 8, 2010

Re: [Pharo-project] XTream was Re: Re: Ocean (was Re: Less plugins, more Smalltalk code!)

by Nicolas Cellier

2010/10/8 Igor Stasenko <siguctua(a)gmail.com>: > I recalled one detail: > > VW Xtreams are composable from the beginning, its a core stream feature. > Not like ours, which require wrappers, which i added (and thus a lot > of clutter on proxying message sends). > > :) > > I still fail to see the difference. Squeak_XTream are composable from the beginning, ReadXtream all have a source, WriteXtream all have a destination, and most of the subclasses fill those ivars with another XTream. VW_XTream.ReadStream>> on: aSource source := aSource Squeak_Xtream.ReadXtream>>source: anObject "Set the source of this stream" source := anObject Or is it just a question of naming ? I adopted #source:, simply because #on: is harder to trace (too many implementors). Maybe the difference is just a convenient wrapping message or two missing in Squeak_XTream. The wrapper class you added are indeed unecessary in both Squeak_XTream and VW_Xtream. I should have given more feedback to you. If you want to look at differences between the two implementation, rather look at VW_Xtream.Buffer and subclasses. Also look at use of Exception handling in VW_Xtream (users of Incomplete). Don't look number of classes & methods, I obviously don't scale ;) Having only nights and week-ends left for programming, I just don't want to compete ;) Nicolas > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 8, 2010

Re: [Pharo-project] XTream was Re: Ocean (was Re: Less plugins, more Smalltalk code!)

by mkobetic＠gmail.com

I saw this thread on the pharo list and figured that a bit of feedback from Michael and myself might be helpful. Please, forgive the cross-posting, this concerns both dialects and I'd like to make this discussion visible on the VW side as well. First of all, let me thank everyone for the "xtreamly" positive feedback. It sure feels good to get a thumbs up once in a while. So, thanks! Since there was a question earlier about availability of my ESUG slides, I'll also add that a rather crude and plain but usable pdf export of those is available on the ESUG slideshare. I'd be happy to forward the pdf to anyone interested as well. It's full of examples and it certainly should be easier to copy those from there than from the video or memory :-). As far as the future plans for Xtreams go (at least on VW side), we'd primarily like to validate the design with actual use, and fix any outstanding issues of course. We are certainly open towards collaboration with others on further development or porting efforts. I'd be happy to help sort out any porting issues (at least from the VW side). Regarding the general direction of the project, we are skeptical about the possibility of maintaining backward compatibility with the classic streams and yet being able to make the kind of changes that we're experimenting with in Xtreams. At this point we believe that the only practical approach is to let them live side by side and let people chose whichever fits better their needs. If Xtreams ever do gain significant acceptance there certainly is a very real possibility that we'll end up having to live with both frameworks, maybe forever. But we don't think there's practical way to somehow evolve the classic streams into something like Xtreams without wreaking havoc. That's also partly why we took the liberty of changing even the basic APIs. They don't behave quite the same way (intentionally) in a number of cases and given that the two will likely have to coexist in the same context, it might be actually beneficial to make them distinctly different, so that it's clear which one is used where. Anyway, what I'm getting at is that some of the choices we've already made with Xtreams might be hard for us to compromise on, but we can certainly discuss the options. On the other hand, implementation changes that aid portability and don't compromise the basic goals are certainly a fair game. Ideally we'll be able to agree on an arrangement that would allow the project to co-evolve on multiple-dialects without the need to effectively fork the code-base. That would certainly be worth-while and we're definitely interested in trying to achieve that. I'll be at the Smalltalks 2010 conference in november and would be happy to discuss any details if there are people interested in this. Obviously, given the license, people are free to fork the code or start from scratch or whatever and take it in whatever direction they see fit. I just want to make it clear that we are open to collaboration as long as we can agree on general direction. So, no hard feelings Nicolas :-), although we may want to sort out the naming eventually just for the sake of avoiding confusion in the Squeak and Pharo world (if Xtreams ever get traction there). Anyway, I'm now subscribed to the pharo list so I'm reachable both there and on vwnc. Martin "Nicolas Cellier"<nicolas.cellier.aka.nice(a)gmail.com> wrote: > Yes that's a correct description of the past and present. > > The futur is opened, and the main options for Squeak Xtream are: > 1) change goals to get closer to VW - with a compatible API and lot of > mud underneath to glue the implementation on squeak > 2) stay at a proof of concept experimental level > 3) continue developping independantly as a replacement for Stream > > There is a lot of buzz recently, and a renewed interest in VW Xtream. > So there is a chance to gather enough force to attempt a squeak port, > whether based on Squeak Xtream experiments or not. > But it's not to me alone to answer this challenge. > > Nicolas > > > Sven > > > > > > _______________________________________________ > > 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

Oct. 8, 2010

Re: [Pharo-project] DejaVu vs Bitmap DejaVu / missing fonts folder

by StÃ©phane Ducasse

alain may be we should that as comments in one of the class of the package. On Oct 8, 2010, at 6:41 PM, Alain Plantec wrote: > Le 08/10/2010 14:37, Veronica Isabel Uquillas Gomez a Ã©crit : >> Hi, >> >> I would like to know if i am the only one having the indentation problem when using bitmap fonts. >> >> The Torch dashboard makes use of small and big DejaVu Sans fonts. For configuring it the fonts folder is needed (that now is gone in the last version pharo 1.1.1 dev, why?). >> Got the suggestion of using the new DejaVu package and I tried... However, they are Bitmap DejaVu fonts and I have the problem of text indentation. >> I show the changed source code in popup views. With DejaVu sans fonts the text appears as it is written (first image), but with Bitmap fonts not -- all is aligned to the left, and it is impossible to read a method like that (second image). >> >> Do I need to set something else for those fonts to work? > Hi Veronica, > > After the loading, to install them: > DejaVuHolder installFull. > or > DejaVuHolder installSizes: #(5 7 8 9 10 11 24) > if you only want a subset > >> Any idea why do I have this problem? >> > I've tried with the 1.1.1 version on Linux and the indentation seems ok also with small fonts (5, 6, 7). > See the screenshot. > > Cheers > Alain > >> Can the fonts folder be include again in the distribution? >> >> Best regards, >> Veronica Uquillas >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > <allAvailablesSizes.png>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 8, 2010

[Pharo-project] R: Problem with inspector

by morod

Hi Mariano I tried it with multiple images and the behavior is the same with all the images. Sent the sample is made with: Pharo-1.1-11411 Latest update: #11411 The first one is my image and the second is taken from the book ÂPharo by ExampleÂ Thanks again Morod Da: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] Per conto di Mariano Martinez Peck Inviato: venerdÃ¬ 8 ottobre 2010 21:43 A: Pharo-project(a)lists.gforge.inria.fr Oggetto: Re: [Pharo-project] Problem with inspector Hi morod, and welcome to Pharo! Which Pharo image are you exactly using? (the name of the zip, the image file or go to System -> About) The first one is your image, right ? and the second one? where is it from ? The difference is that the first image is using the "old" traditional inspector, while the second picture is using another inspector, which is called "NewInspector", which provides more information. Cheers Mariano 2010/10/8 morod <morod(a)tiscali.it> Hi iÂm new to smalltalk and Pharo and my inspector show instead of Why? Thanks _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 8, 2010

Re: [Pharo-project] Problem with inspector

by Mariano Martinez Peck

Hi morod, and welcome to Pharo! Which Pharo image are you exactly using? (the name of the zip, the image file or go to System -> About) The first one is your image, right ? and the second one? where is it from ? The difference is that the first image is using the "old" traditional inspector, while the second picture is using another inspector, which is called "NewInspector", which provides more information. Cheers Mariano 2010/10/8 morod <morod(a)tiscali.it> > Hi > > iâm new to smalltalk and Pharo and my inspector show > > > > > > instead of > > > > Why? Thanks > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 8, 2010

[Pharo-project] Problem with inspector

by morod

Hi i'm new to smalltalk and Pharo and my inspector show instead of Why? Thanks

Oct. 8, 2010

Re: [Pharo-project] XTream was Re: Ocean (was Re: Less plugins, more Smalltalk code!)

by Nicolas Cellier

2010/10/8 Sven Van Caekenberghe <sven(a)beta9.be>: > > On 07 Oct 2010, at 21:41, Nicolas Cellier wrote: > >> Yes, every time I must warn and apologize because I'm guilty of hijacking the name. > > [....] > > Thank you Nicolas, for the elaborate explanation (I should have checked the wiki on SS first myself). > > With your latest updates, everything loads and all tests are green in Pharo 1.1.1 > > Is this a correct summary then ? > > You started Squeak XTreams based on both ideas in VW Xtreams and your own, at a time when VW Xtreams was not MIT licensed (and maybe incomplete). Your goal was/is not API level compatibility with VW Xtreams. Squeak XTreams values backwards compatibilty/integration a bit more, speed is important as well. > > I haven't looked deep enough into Squeak Xtreams yet. Reading the high level descriptions (slides and website docs) of VW Xtreams I get this warm feeling of 'Yes, this is it, this all makes perfect sense, feels good'. But apart from some historical influences, the relation with Squeak Xtreams seems rather limited. > Yes that's a correct description of the past and present. The futur is opened, and the main options for Squeak Xtream are: 1) change goals to get closer to VW - with a compatible API and lot of mud underneath to glue the implementation on squeak 2) stay at a proof of concept experimental level 3) continue developping independantly as a replacement for Stream There is a lot of buzz recently, and a renewed interest in VW Xtream. So there is a chance to gather enough force to attempt a squeak port, whether based on Squeak Xtream experiments or not. But it's not to me alone to answer this challenge. Nicolas > Sven > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 8, 2010