November 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] [COTDC] 86 - TextURL

by Sean P. DeNigris

Continuing in Collections... Today: TextURL Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest -- View this message in context: http://forum.world.st/COTDC-86-TextURL-tp4119838p4119838.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 29, 2011

Re: [Pharo-project] Problem with NonInteractiveUIManager

by Sean P. DeNigris

This is what I have for a class comment, between what was already there and what Igor said in this thread: I am a UI manager which doesn't provide any kind of interactivity with users. I guarantee that your task(s) will run in fully-automated mode. This is useful for things like: - an image runing as a persistent application on a server - an image running headless from the command-line with some batch scripts/commands I automatically take ownership: - when you run an image with the -headless parameter - during image startup (StartupUIManager) To install me: UIManager default: NonInteractiveUIManager new. To replace me: UIManager default: MorphicUIManager new. To handle requests when a UI is not available, catch ErrorNonInteractive. For example: response := [ UIManager default request: 'what is your name?' ] on: ErrorNonInteractive do: [:ex | ex return: 'Mr. John Smith' ]. My default error handling: for any unhandled error, print a stack trace to a log file and exit to the OS. -- View this message in context: http://forum.world.st/Problem-with-NonInteractiveUIManager-tp4115412p411980… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 29, 2011

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

by Igor Stasenko

On 29 November 2011 16:12, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: > 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. > This sounds more complicated. We can map different matrices in different engines to Athens. So, it is not necessary for client code to know which of them are there, because then code will be filled with tons of #ifTrue: branches ... . -- Best regards, Igor Stasenko.

Nov. 29, 2011

Re: [Pharo-project] Problem with NonInteractiveUIManager

by Igor Stasenko

On 29 November 2011 16:42, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > 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? > perhaps we should introduce another message like: UIManager ensureInteractive. so, then you don't have to mention the concrete class name. -- Best regards, Igor Stasenko.

Nov. 29, 2011

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

by Igor Stasenko

Yes, we need branded VM. For that i made a branch on gitorious , named pharo-vm http://gitorious.org/+pharo-developers/cogvm/pharo-vm it should be branding version of original cog vm (with pharo icons , names etc). we made a 1-click for 1.3 with Marcus manually, but we should automate it to build on jenkins. On 29 November 2011 16:43, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > 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 :) > > > -- Best regards, Igor Stasenko.

Nov. 29, 2011

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