February 2009 - Pharo-dev - lists.pharo.org

[Pharo-project] Font for Pharo

by JÃ©rÃ´me

Hi, I found the Font "Andika Basic"[2] which is an Open Source and Free- Software[1] Unicode-ready font made by the same people who brought us Gentium, the typeface for the nations. I suggest using Andika as the Pharo CI Font since it can be distributed along with Pharo and looks a little bit like Lucida Grande, the Mac-UI-font, but at the same time is more friendly and better readable[3]. According to the Andika Website, Andika is Swahili, which is spoken widely in southeastern regions of the African continent, and means "Write!". Have a look: [2] http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=Andika [3] http://minusfreun.de/blog/uploads/Pharo.png JÃ©rÃ´me [1] http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=OFL

Feb. 23, 2009

[Pharo-project] suggestion for the category chooser

by StÃ©phane Ducasse

Hi I think that the category chooser could be improved to avoid to have to type twice the category. Right now if I want to create a category I have to know up front whether it exist or not then I have to select new if it does not else if naively I type the new cat the ui tells me well that it is not defined but in such a case I have to retype it. The solution could be remove the fact that for new category we have to press new... when the user enter the category whether it matches or not return the string that the user entered modulo with its matched string in the list. This way as a user I do not have to choose upfront. I want to create a cat I either select on the list or I type and there is one which I can select or I type and there is none in the list so we get a new one the I typed. Stef

Feb. 23, 2009

Re: [Pharo-project] Question about Morphic

by Alexandre Bergel

Thanks Gary, Cheers, Alexandre On 23 Feb 2009, at 12:36, Gary Chambers wrote: > The scroller itself provides the transform morph that deals with > offsetting > within the scrollpane. > Canvases are used in the drawing cycle of morphs so a morph of some > kind > (that implements drawOn: and draws the graphics) should be added to > the > scroller of the scrollpane. The transform morph sets the clipping > rectangle > for drawing its submorphs. > > |window pane m| > window := SystemWindow labelled: 'Mondrian Canvas'. > window model: self. > window extent: 640 @ 480. > pane := ScrollPane new. > m := PolygonMorph new > position: 250@200; > extent: 400@300. > pane scroller addMorph: m. > window > addMorph: pane > frame: (0 @ 0 corner: 1 @ 1). > window openInWorld. > > > Regards, Gary > > ----- Original Message ----- > From: "Igor Stasenko" <siguctua(a)gmail.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Sunday, February 22, 2009 12:11 PM > Subject: Re: [Pharo-project] Question about Morphic > > >> 2009/2/22 Alexandre Bergel <alexandre(a)bergel.eu>: >>>> Canvas has the clipping capabilities. >>>> So, you can send a command to render a rectangle (-1000 @ -1000) >>>> corner: (10000 @10000) >>>> but depends on canvas clipping area, it will render only part of >>>> it. >>>> >>>> Also, for displaying morphs withing area with scrolling - use a >>>> TransformMorph to apply clipping & sroll in view. >>>> There are another morphs , ready for use , like ScrollPane >>> >>> I exactly use a ScrollBar. Here is a code excerpt: >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>> | window pane | >>> window := SystemWindow labelled: 'Mondrian Canvas'. >>> window model: self. >>> window extent: 640 @ 480. >>> pane := ScrollPane new. >>> >>> canvas := MOCanvas on: self root. >>> pane scroller addMorph: canvas. >>> window >>> addMorph: pane >>> frame: (0 @ 0 corner: 1 @ 1). >>> window openInWorld. >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>> >>> MOCanvas is a subclass of Morph that is resized on some point. >>> >>> Apparently, this incantation does not activate this clipping. >>> >> Well, i'm not sure how to use ScrollPane properly.. >> look for examples of it in other morphs. >> >>> Alexandre >>> >>>> >>>> >>>>> Cheers, >>>>> Alexandre >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> Alexandre Bergel http://www.bergel.eu >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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. >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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. >> >> _______________________________________________ >> 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 23, 2009

Re: [Pharo-project] Question about Morphic

by Gary Chambers

The scroller itself provides the transform morph that deals with offsetting within the scrollpane. Canvases are used in the drawing cycle of morphs so a morph of some kind (that implements drawOn: and draws the graphics) should be added to the scroller of the scrollpane. The transform morph sets the clipping rectangle for drawing its submorphs. |window pane m| window := SystemWindow labelled: 'Mondrian Canvas'. window model: self. window extent: 640 @ 480. pane := ScrollPane new. m := PolygonMorph new position: 250@200; extent: 400@300. pane scroller addMorph: m. window addMorph: pane frame: (0 @ 0 corner: 1 @ 1). window openInWorld. Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Sunday, February 22, 2009 12:11 PM Subject: Re: [Pharo-project] Question about Morphic > 2009/2/22 Alexandre Bergel <alexandre(a)bergel.eu>: >>> Canvas has the clipping capabilities. >>> So, you can send a command to render a rectangle (-1000 @ -1000) >>> corner: (10000 @10000) >>> but depends on canvas clipping area, it will render only part of it. >>> >>> Also, for displaying morphs withing area with scrolling - use a >>> TransformMorph to apply clipping & sroll in view. >>> There are another morphs , ready for use , like ScrollPane >> >> I exactly use a ScrollBar. Here is a code excerpt: >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> | window pane | >> window := SystemWindow labelled: 'Mondrian Canvas'. >> window model: self. >> window extent: 640 @ 480. >> pane := ScrollPane new. >> >> canvas := MOCanvas on: self root. >> pane scroller addMorph: canvas. >> window >> addMorph: pane >> frame: (0 @ 0 corner: 1 @ 1). >> window openInWorld. >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> >> MOCanvas is a subclass of Morph that is resized on some point. >> >> Apparently, this incantation does not activate this clipping. >> > Well, i'm not sure how to use ScrollPane properly.. > look for examples of it in other morphs. > >> Alexandre >> >>> >>> >>>> Cheers, >>>> Alexandre >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> 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. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 23, 2009

Re: [Pharo-project] New Pharo-dev based on 10236

by Damien Cassou

On Mon, Feb 23, 2009 at 10:20 AM, Simon Denier <Simon.Denier(a)inria.fr> wrote: > I got an Error: primitive failed in MultiByteFileStream when launching > a fresh 10236dev image. Am I the only one to experience that? No, everyone is concerned. This is a problem with MIME support. -- Damien Cassou http://damiencassou.seasidehosting.st

Feb. 23, 2009

Re: [Pharo-project] New Pharo-dev based on 10236

by Simon Denier

I got an Error: primitive failed in MultiByteFileStream when launching a fresh 10236dev image. Am I the only one to experience that? On 19 fÃ©vr. 09, at 10:06, Damien Cassou wrote: > http://code.google.com/p/pharo/wiki/Downloads?tm=2 > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Simon

Feb. 23, 2009

Re: [Pharo-project] What about #ifNotNil and #ifNotNilDo:

by Marcus Denker

On 22.02.2009, at 22:42, Keith Hodges wrote: > > The traditional approach that Pharo is using produces a new image, > developed by a new team as a complete break from the past, and > everyone > is forced to code to a moving target. This is the process that squeak > has been using since before the flood, and it is this process that I > have identified as the problem. (I accept that I may be wrong) > So nobody is actually *using* 3.11? (would 4.1 the name of it now?) The problem I see here is that this 3.11 will not have been tested at all. Is that correct? > I myself haven't adopted Pharo, not because you aren't making good > changes, or making things better, but because your development process > guarantees that there will be problems down the line. Not only do you > make it difficult for me to port my current deployments to Pharo with > anything other than a step change, since that is your avowed intent. > But > also Pharo 2 will inevitably be incompatible with Pharo1 and so on, > due > to the process. > Yes. Beeing incompatible with the past is the only way to make progress. > I thank the pharo team for performing lots of useful research on > behalf > of the squeak community, I expect that we will be able to adopt most > of > your innovations, but this will take time, and will be carefully > considered, with the backward compatabiity issue in mind. Pharo is not Research. Research you can find here (for example): http://www.iam.unibe.ch/~denker/mdpubs.cgi?byCategory Enabeling Software Evolution one of the themes of that Research, interestingly. The direction this is going might get clearer from a quote from http://www.iam.unibe.ch/~scg/cgi-bin/scgbib.cgi/abstract=yes?Nier08a : Backward compatibility is the enemy of forward-evolvability. Nevertheless, we cannot live in a world were the old is ignored. A snapshot of an old Windows machine can run on a virtual machine forever, whereas keeping an operating system compatible forever will be bound to fail. Programming languages for eternal systems should provide backwards compatibility in the same way: we need a first class description of the history of all code of the system, freeing the present from being compatible with the past while at the same time providing the possibility to go back in time easily. The system should provide complete, runnable snapshots of the system at any point in the past. Eternal systems need languages that support continuous development and evolution. But there is another aspect to the language: to think that we can envision the perfect language to realize all future systems is to treat language design like a finite game. Thus a language suited for implement- ing ever-evolving, eternal software systems needs to be itself an eternal program. An eternal language must evolve to incorporate new ideas and practices while it is used. It needs to be extensible and growable from within. Marcus -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

Feb. 23, 2009

Re: [Pharo-project] Just downloaded pharo

by Igor Stasenko

2009/2/23 Michael Rueger <m.rueger(a)acm.org>: > Igor Stasenko wrote: > >> Indeed. It is difficult, but possible :) >> I want to refactor VM code to make all windowing stuff be exclusively >> driven from language side. >> So, when you run: >> squeak -headless myimage.image >> >> and -headless flag is handled not by VM itself, but by language side. >> So, you can ignore such flag, or can honor it - all is in your hands. > > Well, while you are at it ;-) everything related to display, input and > clipboard should be moved out of the core VM into plugins so one could > build a truely headless VM e.g. for running scripts. > exactly, that's my point. In a longer perspective, i'd also would like to be able to build VM as a library, so one can embed it into own project. > Michael > > _______________________________________________ > 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.

Feb. 23, 2009

Re: [Pharo-project] Just downloaded pharo

by Michael Rueger

Igor Stasenko wrote: > Indeed. It is difficult, but possible :) > I want to refactor VM code to make all windowing stuff be exclusively > driven from language side. > So, when you run: > squeak -headless myimage.image > > and -headless flag is handled not by VM itself, but by language side. > So, you can ignore such flag, or can honor it - all is in your hands. Well, while you are at it ;-) everything related to display, input and clipboard should be moved out of the core VM into plugins so one could build a truely headless VM e.g. for running scripts. Michael

Feb. 23, 2009

Re: [Pharo-project] Just downloaded pharo

by Igor Stasenko

2009/2/22 Michael Rueger <m.rueger(a)acm.org>: > Todd Blanchard wrote: >> And WOW the new UI skins are beautiful! >> >> So pretty, I almost hate to ask about integrating the mythical >> ffenesteri native window support that I've never been able to make >> work (which would obsolete all that work, but would help squeak fit >> into the real world better). > > The event support is part of the new VMs and native windows per se > wouldn't obsolete the current UI work. It is rather difficult though to > make Morphic work with multiple windows AFAIK. > Indeed. It is difficult, but possible :) I want to refactor VM code to make all windowing stuff be exclusively driven from language side. So, when you run: squeak -headless myimage.image and -headless flag is handled not by VM itself, but by language side. So, you can ignore such flag, or can honor it - all is in your hands. > Michael > > _______________________________________________ > 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.

Feb. 23, 2009