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

[Pharo-project] Polymorph (and a few other) changes/fixes

by Gary Chambers

Finally found the time to package out. Have tested a bit after fixing some conflicts. A few minor ones left for DropListMorph as it seems the wrapSelector stuff has changed (and appears broken in 2.0 too). Attached cs and description of changes Regards, Gary

April 24, 2012

Re: [Pharo-project] [ANN] Styled Text Editor for Cuis 4.0 Smalltalk

by Dale Henrichs

Juan, Exactly! BTW, I've got just a little more work to do before Cuis will be able to read and write Cypress:) Dale ----- Original Message ----- | From: "Juan Vuletich (mail lists)" <juanlists(a)jvuletich.org> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Tuesday, April 24, 2012 4:55:26 AM | Subject: Re: [Pharo-project] [ANN] Styled Text Editor for Cuis 4.0 Smalltalk | | Hi Dale, | | Quoting Dale Henrichs <dhenrich(a)vmware.com>: | | > Bernhard and Juan, | > | > I was curious enough about Cypress and Cuis to start a Cypress port | > to Cuis[1]. Loaded code and started working through tests: | > | > 19 run, 6 passed, 3 failed, 10 errors | > | > We'll see if I get any farther tonight:) | > | > Dale | > | > [1] https://github.com/CampSmalltalk/cuis-cypress | | This is great, thank you! | | I took a look at your format when thinking on how to do Cuis package | format, and I think that for a Cuis specific package format, a single | file per package will be easier to diff / merge by Git. | | But I really welcome and thank you for this format for cross-dialect | packages! | | Cheers, | Juan Vuletich | | > ----- Original Message ----- | > | From: "Dale Henrichs" <dhenrich(a)vmware.com> | > | To: Pharo-project(a)lists.gforge.inria.fr | > | Sent: Monday, April 23, 2012 1:57:57 PM | > | Subject: Re: [Pharo-project] [ANN] Styled Text Editor for Cuis | > | 4.0 | > Smalltalk | > | | > | Bernhard, | > | | > | With regards to sharing code between dialects, I'd like to | > | recommend | > | that you look into porting Cypress to Cuis (I'm willing to help | > | as | > | much as I can). | > | | > | The Cypress project is aimed from the get go to enable sharing of | > | packages between Smalltalk dialects with a recognition that | > | possibly | > | the most important aspect is a shared VCS (git/github). | > | | > | If you look at the current code base in Cypress, you will see a | > | reference implementation written against Pharo. The reference | > | implementation is a work in progress and the initial | > | implementation | > | was done for Amber[2]. | > | | > | Cypress has Monticello-like packages, but other than taking a few | > | ideas from Monticello (definitions, packages and snapshots ... | > | more | > | than a few:)) the code base is independent of Monticello. The | > | fact | > | that Cypress runs on top of Amber (sans file system access) | > | speaks | > | volumes for it's portability. | > | | > | To paraphrase a point from my STIC talk[3] on this subject: | > | | > | Cypress is not intended to be the primary version control | > | system for any dialect, however, if you want to share code | > | between dialects you should allow your developers to import | > | and export code using the Cypress package format. | > | | > | If you are interested, there are bits and pieces of code in a few | > | other projects that I would want to pull into the Cypress project | > | and couple other things that I'd like to move out of the Cypress | > | project before tackling another port ... | > | | > | We can correspond via private email if you'd like to take me up | > | on | > | the offer of help:) | > | | > | Dale | > | | > | [1] https://github.com/CampSmalltalk/Cypress | > | [2] https://github.com/CampSmalltalk/amber-cypress | > | [3] | > | http://portal.sliderocket.com/vmware/STIC-2012-Practical-Git-for-Smalltalk | > | | > | ----- Original Message ----- | > | | From: "Bernhard Pieber" <bernhard(a)pieber.com> | > | | To: Pharo-project(a)lists.gforge.inria.fr | > | | Sent: Monday, April 23, 2012 9:53:35 AM | > | | Subject: Re: [Pharo-project] [ANN] Styled Text Editor for Cuis | > | | 4.0 | > | | Smalltalk | > | | | > | | Hi GÃ¶ran, | > | | | > | | Thanks for your question! I have posted the announcement of the | > | | Styled Text Editor to the Pharo list as well because I still | > | | have | > | | not given up on the idea to port it to Squeak and Pharo. It is | > | | not | > | | straightforward but I consider it possible. | > | | | > | | Currently the Styled Text Editor is an external package which | > | | is | > | | loaded on top of Cuis 4.0. The API it uses is quite specific to | > | | Cuis | > | | so to port it alone is probably too much effort. What I think | > | | can | > | | be | > | | done is the following: | > | | Split Cuis into three parts, | > | | a) the parts which are not needed for Styled Text Editor, like | > | | the | > | | Cuis tools | > | | b) the parts of Cuis Morphic the Styled Text Editor depends on | > | | ? | > | | this | > | | is in my opinion the most valuable part of Cuis because Juan | > | | spent | > | | years cleaning it | > | | c) the Smalltalk kernel below | > | | | > | | The idea is to port only part b) and the Styled Text Editor. | > | | And it | > | | has to be done automatically by a tool which creates packages | > | | for | > | | Squeak and Pharo, always from the latest code base. In addition | > | | you | > | | will probably need small Cuis portability packages done | > | | manually, | > | | one for Squeak and one for Pharo. | > | | | > | | Being able to always load the latest code base of Styled Text | > | | Editor | > | | and Cuis Morphic as an external package in Pharo is a | > | | prerequisite | > | | to look into possibilities of sharing more of the code. | > | | | > | | I plan to write a more detailed proposal and then to approach | > | | ESUG | > | | and ask for support for the funding. Any ideas for other | > | | sources of | > | | funding are highly welcome and could speed things up | > | | considerably, | > | | of course! ;-) | > | | | > | | I for one have not given up on the idea that it might be | > | | possible | > | | to | > | | develop substantial components as you called it ? thank you for | > | | that | > | | as well ? in a more Squeak-dialect-independent way. ;-) | > | | | > | | Finally, I would like to take the opportunity and kindly ask | > | | everyone | > | | who has not done so yet: Please check out Cuis 4.0 and the | > | | Styled | > | | Text Editor and give us feedback, even if it does not (yet) run | > | | on | > | | your favourite Squeak dialect! Thank you! | > | | | > | | Peace, | > | | Bernhard | > | | | > | | P.S. Thanks to GÃ¶ran and Janko for trying to establish | > | | different | > | | threads for the rather off-topic discussions that my | > | | announcement | > | | posting has caused. | > | | | > | | Am 23.04.2012 um 16:04 schrieb GÃ¶ran Krampe: | > | | > Hi! | > | | > | > | | > On 04/23/2012 03:40 PM, StÃ©phane Ducasse wrote: | > | | >>> Just cloning it off into Pharo and forking seems... less | > | | >>> optimal. | > | | >>> Any ideas or thoughts? | > | | >> | > | | >> I do not get what you mean. I just want to work on our | > | | >> roadmap | > | | >> and | > | | >> make it getting real. | > | | >> It is hard enough to get some momentum and to deliver for | > | | >> real. | > | | >> So can you help us to get focused? | > | | >> People can do what they want. I wrote a vision document. We | > | | >> have | > | | >> a | > | | >> roadmap | > | | >> and we will do it. | > | | > | > | | > Ok, let me clarify. I was just wondering how the Pharo | > | | > community | > | | > wants to handle a case where a substantial component (in this | > | | > case, this new editor) is not *primarily* developed in Pharo | > | | > (in | > | | > this case Cuis). | > | | > | > | | > The simple route is to just copy and fork. But IMHO this | > | | > doesn't | > | | > leverage the team already around this editor, right? We | > | | > (Pharo) | > | | > can't just go around and forking everything and maintaining | > | | > everything for ourselves, right? | > | | > | > | | > I just got interested in that problem - now, later replies | > | | > indicated that it would still need a substantial rewrite for | > | | > Pharo, so perhaps the situation I am describing is not really | > | | > applicable in this case. | > | | > | > | | > regards, GÃ¶ran | > | | > | > | | | > | | | > | | | > | | > | > | | | |

April 24, 2012

Re: [Pharo-project] How to disable development tools on Pharo 1.4

by Noury Bouraqadi

thanx. Done. On 20 avr. 2012, at 17:28, Esteban Lorenzano wrote: > Hi Noury, > > I opened the project (I don't know why it was closed)... please upload your changes :) > > best, > Esteban > > > On Apr 20, 2012, at 5:14 PM, Noury Bouraqadi wrote: > >> Hi, >> >> I tried it with WorldSwitch-Preferences from SS3. >> A minor fix was required to have it run on 1.4 (use rehash instead of rehachWithoutBecome not in the system anymore). >> Attached the fixed version since I can't write on the repo. >> >> I get a "closed" image. I don't know how to test it further. >> >> Noury >> >> >> >> >> Afin de contribuer au respect de l'environnement, >> >> >> merci de n'imprimer ce courriel qu'en cas de necessite >> >> >> >> >> >> Please consider the environment before you print >> >> >> >> >> >> <WorldSwitch-Preferences-NouryBouraqadi.2.mcz> >> >> On 2 fÃ©vr. 2012, at 14:32, Esteban Lorenzano wrote: >> >>> Hi Noury, >>> >>> I packaged what I have. And even create a settings configuration for it (under "Deployment" category). >>> Notice that is very hacky and ugly and needs a lot (and I mean A LOT) of polish... but is a start :) >>> >>> see WSSettings class>>#setDeployment: for a start. >>> >>> <WorldSwitch-Preferences-EstebanLorenzano.2.mcz> >>> >>> best, >>> Esteban >>> >>> El 02/02/2012, a las 6:40a.m., Noury Bouraqadi escribiÃ³: >>> >>>> Hi Esteban, >>>> >>>> On 31 janv. 2012, at 14:23, Esteban Lorenzano wrote: >>>> >>>>> Hi, >>>>> >>>>> in fact, what Mariano posted is just a part... disable everything is complicated, because code is everywhere... I'm collection all of this changes in a package, to see in advance if it is possible to abstract that. >>>> >>>> Thanks Esteban! >>>> Do you have a version of this package already? >>>> Otherwise, I'll start packaging what Mariano sent. >>>> >>>> >>>>> Ideally, we should have a preference "Disable Development Mode", or something like that to allow desktop developers to easily switch... >>>>> >>>> Yes. We should have a menu for this. It's part of dev tools. >>>> It's a shame that this critical feature isn't available yet. >>>> >>>> Noury >>>> >>>>> best, >>>>> Esteban >>>>> >>>>> El 31/01/2012, a las 10:16a.m., Ben Coman escribiÃ³: >>>>> >>>>>> Noury Bouraqadi wrote: >>>>>>> I remember having seen some time in the past a menu that allows to shrink the image and disable the world menu. >>>>>>> But, I can't retrieve any thing related. I don't care about the menu per se. I'd be happy with a message to send to some object that does the job. >>>>>>> >>>>>>> >>>>>>> Noury >>>>>>> -- >>>>>>> http://twitter.com/#!/NouryBouraqadi >>>>>>> http://www.kroobe.com/profile/noury >>>>>>> >>>>>>> >>>>>> Squeak 3.9 based, but perhaps something useful... >>>>>> "Prepare For Application Deployment" http://squeak.preeminent.org/tut2007/html/205.html >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> Noury >>>> -- >>>> http://twitter.com/#!/NouryBouraqadi >>>> http://www.kroobe.com/profile/noury >>>> >>>> >>>> Afin de contribuer au respect de l'environnement, >>>> merci de n'imprimer ce courriel qu'en cas de necessite >>>> >>>> Please consider the environment before you print >>>> >>>> >>>> >>>> >>> >> >> Noury >> -- >> http://twitter.com/#!/NouryBouraqadi >> http://www.kroobe.com/profile/noury >> > > Noury -- http://twitter.com/#!/NouryBouraqadi http://www.kroobe.com/profile/noury Afin de contribuer au respect de l'environnement, merci de n'imprimer ce courriel qu'en cas de necessite Please consider the environment before you print

April 24, 2012

Re: [Pharo-project] Pharo and the rest of the ecosystem

by Edgar De Cleene

El 4/24/12 9:09 AM, "Fernando Olivero" <fernando.olivero(a)usi.ch> escribiÃ³: > The community behind Pharo, shouldnt be required to always be aware of > external enhancements. And vice-versa for the remaining forks. > > Fernando Un libro sabio dice: Los hermanos sean unidos.... A wise book says: The brothers are united... Or Pharo is not descendent of ...... Don't put name here for not irritate people Edgar

April 24, 2012

Re: [Pharo-project] new icon set

by Igor Stasenko

On 24 April 2012 14:54, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 24.04.2012 um 14:37 schrieb Igor Stasenko: > > On 24 April 2012 14:13, Norbert Hartl <norbert(a)hartl.name> wrote: > > > Am 24.04.2012 um 14:06 schrieb Esteban Lorenzano: > > > but, Norbert, I don't see the point. In a server you will not have (or > *should* not have) a display... so rendering time, etc. is non an issue, > because it will not be any... or I'm missing something? > > > I think most people using pharo on the server are using VNC to maintain > them. I do that,too, Â in lack of a better tool. So in this case there is a > display and there are icons. Rendering is not an issue as long as you > suspend to UI thread until you need it. > > So, let me just repeat > > > ...new icons.... cool! > > ...svg icons.....cool! > > ...removable icons...cool! > > > That's basically all I wanted to say. > > > > and this is not preventing an operating systems from having even more > rich graphics and still use remote desktop connections? > i don't share your concerns.. because we're talking about different > terms of use. > for desktop applications we need a modern rich graphics and eye candy. > this not a question. > > for servers you can live perfectly with command-line tools only, and > pharoers also working in that direction.. > so it is not an exclusive choice where you should pick between one > over another. > you can have both: minimal memory footprint on server(s) and decent > graphics on desktop. i am talking about modular system, where you can > (un)load modules at your please, and we're moving towards it. > > > Igor, > > I didn't say there should be one approach and that you need to choose. I > tried to make explicit that having options is a good thing. And that > includes the joy of using a commandline for a server or not. You have no > reason to decide for everyone that they should live with commandline tools > on the server. > I was talking about the near future and you reach far more off. Of course I > like to have a tiny pharo image running on a server that lets me connect > from my development image and lets me debug/inspect everything from remote > where everything is either SVG or opengl. But I don't expect that to happen > tomorrow or the day after. There is a need for short term solution. Â Or to > make fun of a quote > > Don't obscure my reality with your future > no, i don't want to put you into a cage. my post was primarily to advertise some of my work :) one of the problems with graphics, is that if you working with bitmap format(s), like icon sets or fonts, you always have to keep multiple resolutions for them.. for different DPI and different themes. With vector graphics this is obviously not an issue. And i making SVG importer mainly to open a rich vector graphics world to pharo. So, you can create graphics using editors like inkscape or other , and then just put it into your image. And i didn't said that you cannot use bitmaps as endpoint format, while using SVG as a source.. so in case if you want to render different resolution bitmaps you can always reproduce them in a couple of minutes.. > Norbert > -- Best regards, Igor Stasenko.

April 24, 2012

Re: [Pharo-project] Native Boost plugin pour Athens

by Igor Stasenko

2012/4/24 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > >> Stephane >> >> Le 24 avril 2012 12:32, stephane ducasse <stephane.ducasse(a)gmail.com> a Ã©crit : >>> il faut la VM qui accepte nativeBoost. >>> https://ci.lille.inria.fr/pharo/view/NativeBoost/ >> merci >> >> sous Windows, je vais plus loin que prÃ©cÃ©demment, mais au lancement >> d'un exemple Athens je reÃ§ois ce message: >> Error: define your own path yes.. define own path. it means that in case of Athens, you should a) download a cairo library for windows (see http://cairographics.org/download/) b) put it somewhere on your hard drive c) modify the method to point to cairo dll sorry, no easy solution right now.. these things are still under development. >> >> sous mac j'ai une erreur au lancement de la machine virtuelle (NB-Cog-Mac-Cocoa) >> mais comme je le disais dans un mail prÃ©cÃ©dent, je suis sous OSX >> 10.5.8 (il va falloir que je finisse par faire la mise Ã jour ;) >> Voici le rapport de crash: >> >> Date/Time: Â Â Â 2012-04-24 13:54:41.233 +0200 >> OS Version: Â Â Â Mac OS X 10.5.8 (9L30) >> Report Version: Â 6 >> Anonymous UUID: Â FC86FDF9-C4F0-456D-ACF2-2771397F846A >> >> Exception Type: Â EXC_BREAKPOINT (SIGTRAP) >> Exception Codes: 0x0000000000000002, 0x0000000000000000 >> Crashed Thread: Â 0 >> >> Dyld Error Message: >> unknown required load command 0x80000022 >> this is VM related. Not particularily NB problem. IIRC , our current VMs we build can run on 10.6 at minimum.. 10.5 are no longer supported. (well, its better to ask Esteban about why it like that ;) >> >> th > > > > > > -- Best regards, Igor Stasenko.

April 24, 2012

Re: [Pharo-project] Tirade!

by GÃ¶ran Krampe

On 04/24/2012 03:23 PM, Igor Stasenko wrote: > Here the the snippet to parse array literals.. based on existing parser.. > i only had to add a #parseNode accessor to Parser to make it work: > > > | parser| > parser := > (Parser new > init: '#(1 2 3 (ab bc de))' readStream notifying: nil failBlock: [] > ). > > parser encoder initScopeAndLiteralTables. > parser primaryExpression. > parser parseNode key Looks neat. Now, this of course still raises the question - shouldn't we try to move further with our literal arrays? As I mentioned, in Tirade I added support for Associations. So I can do: { 'name'->'Igor' } ...without adding full support for expressions. This was to "match" JSON. It will still produce an Array of Associations, but then I can easily change that to a Dictionary on the receiving end. In Amber Nicolas has added this syntax for literal dictionaries: #{ 'name' -> 'Igor'} regards, GÃ¶ran

April 24, 2012

Re: [Pharo-project] Tirade!

by GÃ¶ran Krampe

On 04/24/2012 03:19 PM, StÃ©phane Ducasse wrote: > goran could I extract the parser? and rename it in another package? Yeah, sure, it is a "classic" recursive descent parser with a hereChar ivar etc. Code is MIT, feel free to grab. And feel free to ask any and all questions :) regards, GÃ¶ran

April 24, 2012

Re: [Pharo-project] Tirade!

by Igor Stasenko

Here the the snippet to parse array literals.. based on existing parser.. i only had to add a #parseNode accessor to Parser to make it work: | parser| parser := (Parser new init: '#(1 2 3 (ab bc de))' readStream notifying: nil failBlock: [] ). parser encoder initScopeAndLiteralTables. parser primaryExpression. parser parseNode key On 24 April 2012 15:19, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > goran could I extract the parser? and rename it in another package? > > Stef > > On Apr 24, 2012, at 12:00 PM, GÃ¶ran Krampe wrote: > >> On 04/24/2012 11:52 AM, GÃ¶ran Krampe wrote: >>> On 04/24/2012 11:51 AM, GÃ¶ran Krampe wrote: >>>> On 04/24/2012 11:46 AM, StÃ©phane Ducasse wrote: >>>>> Where is the code? >>>> >>>> On SS. But it seems... down? Project is called "Tirade". >>> >>> http://www.squeaksource.com/Tirade.html >> >> Eh, oops. I just realized that TiradeParser uses dynamic arrays { } and does not have current support for literal Arrays. Duh. Sorry about that, but feel free to use the code anyways, adding #parseLiteralArray should not be hard. >> >> regards, GÃ¶ran >> > > -- Best regards, Igor Stasenko.

April 24, 2012

Re: [Pharo-project] Tirade!

by StÃ©phane Ducasse

goran could I extract the parser? and rename it in another package? Stef On Apr 24, 2012, at 12:00 PM, GÃ¶ran Krampe wrote: > On 04/24/2012 11:52 AM, GÃ¶ran Krampe wrote: >> On 04/24/2012 11:51 AM, GÃ¶ran Krampe wrote: >>> On 04/24/2012 11:46 AM, StÃ©phane Ducasse wrote: >>>> Where is the code? >>> >>> On SS. But it seems... down? Project is called "Tirade". >> >> http://www.squeaksource.com/Tirade.html > > Eh, oops. I just realized that TiradeParser uses dynamic arrays { } and does not have current support for literal Arrays. Duh. Sorry about that, but feel free to use the code anyways, adding #parseLiteralArray should not be hard. > > regards, GÃ¶ran >

April 24, 2012