- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Pharo VMs should be more Pharo-like

by StÃ©phane Ducasse

On Nov 29, 2011, at 1:46 PM, Esteban Lorenzano wrote: > Hi, > > Currently, we are linking official VMs for pharo taking directly from Jenkins a version and packaging for download (or for Pharo One-Click). > I think this is a temporal solution, we need something better: > > 1) Pharo VMs should have Pharo Icons. +1 > 2) Pharo VMs should be named "pharo" or "pharovm" (better the fist), not "CogVM", which is an internal name. + 1 > 3) We should include a PLUGINS.txt file with information about present plugins (internal and external) +1 > 4) We should include a LICENCE.txt file with all licence information. + 1 > > ... I think that's all :) > > I know... this is very dumb and clearly not mandatory, but it says a lot about the maturity of our Pharo :) > > All agree? Should I create a ticket? YES! > > Cheers, > Esteban > > pd: I'm the only one who does not likes One-Click versions? I would prefer a different package for each platform (Is ugly to have a directory named Pharo.app in linux or windows. Also, no need to have all those duplicated-but-for-different-platform files) Yes :)

Nov. 29, 2011

Re: [Pharo-project] Problem with NonInteractiveUIManager

by StÃ©phane Ducasse

I'm confused by your sentence > if you run headless and don't want to use this manager, > you can disable it, just by setting a morphic ui manager: > > UIManager default: MorphicUIManager new. we disable it by setting a morphic ui manager?

Nov. 29, 2011

[Pharo-project] Call for your input on questions you ask yourselves during merge

by StÃ©phane Ducasse

Hi guys We are writing some articles on the work of veronica to support merging activities. We need your input great smalltalk community :) What are the questions that you ask yourselves when you are/want to merge some code in your project? We would like to do a compilation of questions and also evaluate how the solution of veronica solves them or part of them. Here are some typical questions we asked ourselves. - What other changes did this change require? - Can I integrate this change right now? - How large it is? - Who made it? - Is it still valid (when I'm working on an old change)? - Is this change impacted by a change that happened in another branch of my software? Stef D., Andy K. and Veronica U.

Nov. 29, 2011

Re: [Pharo-project] Athens work in progress: couple screenshots

by Fernando Olivero

I get the point now, something like the brushes in seaside. Thanks for the explanation. Regarding the protocol, did you consider reusing the same idea, but one step before, as in the following: pathTransform := canvas transformDescribedBy: 'path'. pathTransform scaleBy: 0.5. imageTransform := canvas transformDescribedBy: 'image'. imageTransform scaleBy: 0.5. Maybe add the following for documentation: AthensCairo>>availableTransforms ^ #('path'. 'image'. ) AthensOpenGL>>availableTransforms ^ #('modelView'. 'projection'. ) This would unify the canvas protocol, for all the available rendering engines. Fernando On Mon, Nov 28, 2011 at 6:43 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 28 November 2011 16:04, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: >> Don't know, but in case we cant modify Athens, we can always rename >> the project and start fresh, given that Igor rewrote most of it >> right?. >> >> Fernando >> >> On Fri, Nov 25, 2011 at 12:58 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> >>> On Nov 25, 2011, at 10:35 AM, Fernando Olivero wrote: >>> >>>> Ok, i will try to do so from now on! >>>> >>>> Igor, thanks for detailed response, i see now there's no real need for >>>> caching the glyphs, even though i didn't consider rotation as an >>>> available affine transformation. >>>> >>>> Just a question on the protocol of the canvas, i found it better to >>>> use the following convenience methods, instead of exposing the >>>> transformation (or canvas state) directly to the sender: >>>> >>>> drawOn: aCanvas >>>> Â aCanvas pathTransform â¦ >>>> >>>> drawOn: aCanvas >>>> Â Â aCanvas scaleBy: 0.5 @0.5 ; translateBy: 10@10 . >>>> Â Â â¦.. > > the canvas #pathTransform actually should answer a delegate, > which should allow you to manipulate coordinate system transformation. > There's no intent to expose the state directly. You can modify > transformation matrix > only via corresponding protocol, but don't manipulate its state directly. > > now about > canvas scaleBy: ... versus canvas pathTransform scaleBy:... > why i did it like that? because there are multiple transformation > matrices responsible > for different parts of computations. > for instance, in OpenVG model there are four: > Â - path > Â - image > Â - stroke > Â - (forgot) :) > > or take an openGL for example there are 3 (or 4) matrices again: > Â - model > Â - projection > Â - texture > Â - color space > > if you expose all of them via canvas, then you have to bloat canvas > protocol with duplicate messages like: > > canvas pathScale: > canvas pathRotate: > canvas imageScale: > canvas imageRotate: > ... etc > > that's why there are separate delegates, which represent concrete > matrix, and common protocol which > you can use for all of them: > > canvas pathTransform scaleBy: > canvas imageTransform scaleBy: > etc > > > -- > Best regards, > Igor Stasenko.

Nov. 29, 2011

Re: [Pharo-project] Pharo VMs should be more Pharo-like

by Marcus Denker

On Nov 29, 2011, at 1:46 PM, Esteban Lorenzano wrote: > Hi, > > Currently, we are linking official VMs for pharo taking directly from Jenkins a version and packaging for download (or for Pharo One-Click). > I think this is a temporal solution, we need something better: > > 1) Pharo VMs should have Pharo Icons. > 2) Pharo VMs should be named "pharo" or "pharovm" (better the fist), not "CogVM", which is an internal name. > 3) We should include a PLUGINS.txt file with information about present plugins (internal and external) > 4) We should include a LICENCE.txt file with all licence information. > > ... I think that's all :) > > I know... this is very dumb and clearly not mandatory, but it says a lot about the maturity of our Pharo :) > > All agree? Should I create a ticket? > yes. > > pd: I'm the only one who does not likes One-Click versions? I would prefer a different package for each platform (Is ugly to have a directory named Pharo.app in linux or windows. Also, no need to have all those duplicated-but-for-different-platform files) Yes, I was thinking about that, too... its nice for the very first step, but then it's more a problem. Maybe having 3 packages for the three architectures would be better? -- Marcus Denker -- http://marcusdenker.de

Nov. 29, 2011

Re: [Pharo-project] Pharo VMs should be more Pharo-like

by Diaz Trepat, Ramiro

I'm not sure having a VM with a different name is so confusing. Cog is a VM for more than one project, it's got its own identity and that is a good thing to me. Very much like V8 is not called javascriptvm or chromevm to the best of my knowledge. I'd say Pharo uses Cog, not that Cog is Pharo, and there's nothing wrong with that. Cheers. r. -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Esteban Lorenzano Sent: 29 November 2011 12:46 To: Pharo Development Subject: [Pharo-project] Pharo VMs should be more Pharo-like Hi, Currently, we are linking official VMs for pharo taking directly from Jenkins a version and packaging for download (or for Pharo One-Click). I think this is a temporal solution, we need something better: 1) Pharo VMs should have Pharo Icons. 2) Pharo VMs should be named "pharo" or "pharovm" (better the fist), not "CogVM", which is an internal name. 3) We should include a PLUGINS.txt file with information about present plugins (internal and external) 4) We should include a LICENCE.txt file with all licence information. ... I think that's all :) I know... this is very dumb and clearly not mandatory, but it says a lot about the maturity of our Pharo :) All agree? Should I create a ticket? Cheers, Esteban pd: I'm the only one who does not likes One-Click versions? I would prefer a different package for each platform (Is ugly to have a directory named Pharo.app in linux or windows. Also, no need to have all those duplicated-but-for-different-platform files) This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.

Nov. 29, 2011

Re: [Pharo-project] Pharo VMs should be more Pharo-like

by Sean P. DeNigris

EstebanLM wrote > > All agree? Should I create a ticket? > +1. All the little things make a difference, especially to newbies that may have misconceptions/doubts about Smalltalk. EstebanLM wrote > > pd: I'm the only one who does not likes One-Click versions? I would prefer > a different package for each platform (Is ugly to have a directory named > Pharo.app in linux or windows. Also, no need to have all those > duplicated-but-for-different-platform files) > I think they are both valuable. For me, the one-click is great to showcase Smalltalk's ability to run on any mainstream OS. I think the idea that in one operation I can drag my Smalltalk world onto a USB stick, plug it into any computer I may find, and have everything work is pretty cool. OTOH, for a dedicated use, like a web app on a unix server, the cleaner platform-specific approach seems better. -- View this message in context: http://forum.world.st/Pharo-VMs-should-be-more-Pharo-like-tp4119042p4119166… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 29, 2011

Re: [Pharo-project] Pharo VMs should be more Pharo-like

by Larry White

On Tue, Nov 29, 2011 at 8:07 AM, Luc Fabresse <luc.fabresse(a)gmail.com> > > >> pd: I'm the only one who does not likes One-Click versions? I would >> prefer a different package for each platform (Is ugly to have a directory >> named Pharo.app in linux or windows. Also, no need to have all those >> duplicated-but-for-different-platform files) >> > > I understand but on the other hand it is great to have the same package > which contains everything and runs everywhere. > > I have a bizarre, but maybe related use-case. I work in OS X and tried to setup my dev environment such that my one-click app was in a DropBox folder so I would never have to worry about backups and, theoretically, would be able to switch at any time to work from my other macs. (I put my local montecello repository in the same folder.) Unfortunately, it didn't work. Clicking the app resulted in a 'can't find image' error. I didn't look into it further but assumed that either there was a non-relative path setting, or that the image was actually not in the package contents hidden by the app. If the app packaging could be tweaked so this use-case worked it would be a nice, flexible (and free) model for working across different machines and having constant , effortless backup of the working environment. - Larry > Luc > > >

Nov. 29, 2011

[Pharo-project] VM page in pharo book is outdated

by Esteban Lorenzano

Hi, Checking the pharo colaboractive book, I found that the VM building is old and it is not compatible anymore with our current process. Maybe "someone" (cough, cough, Mariano, cough, cough) could update it with better information? Cheers, Esteban pd: also... I'm a little worried about nobody noticing this before. That means people does not use pharo book? I think is a great way to share information, but maybe there is not much people aware of it... I know, there is a link in "external links" in main page and is top in "documentation"... I don't know if we can do it more visible or clear? ppd: I'd rearrange "pharo tools" section by adding subsections like: "Persistence", "Web", etc., today looks a little bit confusing, IMHO. pppd: yeah... today is my "stupid questions" day... :P

Nov. 29, 2011

Re: [Pharo-project] Pharo VMs should be more Pharo-like

by Luc Fabresse

Hi Esteban, 2011/11/29 Esteban Lorenzano <estebanlm(a)gmail.com> > Hi, > > Currently, we are linking official VMs for pharo taking directly from > Jenkins a version and packaging for download (or for Pharo One-Click). > I think this is a temporal solution, we need something better: > > 1) Pharo VMs should have Pharo Icons. > 2) Pharo VMs should be named "pharo" or "pharovm" (better the fist), not > "CogVM", which is an internal name. > 3) We should include a PLUGINS.txt file with information about present > plugins (internal and external) > 4) We should include a LICENCE.txt file with all licence information. > > ... I think that's all :) > > I know... this is very dumb and clearly not mandatory, but it says a lot > about the maturity of our Pharo :) > > All agree? Should I create a ticket? > I completly agree. > > Cheers, > Esteban > > pd: I'm the only one who does not likes One-Click versions? I would prefer > a different package for each platform (Is ugly to have a directory named > Pharo.app in linux or windows. Also, no need to have all those > duplicated-but-for-different-platform files) > I understand but on the other hand it is great to have the same package which contains everything and runs everywhere. Luc

Nov. 29, 2011