- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Headless PetitParser

by StÃ©phane Ducasse

Hi Alberto can you give an example so that people can learn too? Stef On Nov 10, 2011, at 6:16 PM, Alberto Bacchelli wrote: > Thank you everybody for your super-useful help! > I managed to create my first smalltalk script for headless Pharo (it's > pretty fun ;) ! > > Cheers, > Alberto > > -- > View this message in context: http://forum.world.st/Headless-PetitParser-tp3994446p4024397.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Nov. 12, 2011

Re: [Pharo-project] Instantiating from a Symbol

by StÃ©phane Ducasse

>> > > StÃ©ph, > > Nick is right. I guess the question is: how should normal client or user code that used to do something like > > Smalltalk at: #Point > > be written ? > > Should we just do > > Smalltalk globals > > or > > self environment. environment should be used in a method while Smalltalk globals more for scripts. Stef

Nov. 12, 2011

Re: [Pharo-project] NewTextMorph

by StÃ©phane Ducasse

Thanks! Stef On Nov 10, 2011, at 4:46 PM, Fernando Olivero wrote: > Done. > > Issue 4986: Removing NewTextMorph and related > > Fernando > On Thu, Nov 10, 2011 at 3:23 PM, Hilaire Fernandes > <hilaire.fernandes(a)gmail.com> wrote: >> Fernando, can you do it? I think you know better the related elements. >> >> Hilaire >> >> Le 10/11/2011 09:30, StÃ©phane Ducasse a Ã©crit : >>> Can you create a bug entry to remove these classes? >>> If they are not maintained we should remove them. >>> >>> Stef >>> >>> >>>> Hi Fernando, >>>> >>>> Thanks for the feedback. I also saw these classes were not used, so I >>>> sticked to TextMorph. >>>> >>>> >>>> Hilaire >>>> >>>> >>>> Le 09/11/2011 10:17, Fernando Olivero a Ã©crit : >>>>> Hi Hillary, the classes you mention were created by me when Pharo >>>>> wasnt using the CUIS editors, they allowed me to plug them into Pharo, >>>>> coming up with a text morph form scratch. >>>>> >>>>> Nobody used them since them, except me in Gaucho. So i've discontinued >>>>> maintaing them in Pharo. I would suggest you to use the other text >>>>> morphs classes (TextMorph, PluggableTextMorph, etcâ¦), which are >>>>> maintained and used currently in the system. >>>>> >>>>> I will create an issue to remove them from the system, because now is >>>>> confusing, to have more than one option. >>>>> >>>>> Fernando >>>>> >>>>> On Sat, Nov 5, 2011 at 4:20 PM, Hilaire Fernandes >>>>> <hilaire.fernandes(a)edu.ge.ch> wrote: >>>>>> I want to plug a multiple line text morph a DrGeo canvas. The morph >>>>>> should display the text (yes) and be editable on place when the user ask >>>>>> for. >>>>>> >>>>>> Which class should I use ? >>>>>> EditableTextMorph, EntryFieldMorph or NewTextMorph >>>>>> >>>>>> >>>>>> The comments of the class EntryFieldMorph wrote about example1 and >>>>>> example2 methods bit I dont see it (I am using Pharo 1.3) >>>>>> >>>>>> Hilaire >>>>>> >>>>>> >>>>>> -- >>>>>> Education 0.2 -- http://blog.ofset.org/hilaire >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Education 0.2 -- http://blog.ofset.org/hilaire >>>> >>>> >>> >>> >>> >> >> >> >

Nov. 12, 2011

Re: [Pharo-project] Latest Polymorph improvements

by StÃ©phane Ducasse

thanks http://code.google.com/p/pharo/issues/detail?id=4996 stef On Nov 10, 2011, at 5:32 PM, Gary Chambers wrote: > Time for another accumulated bunch of things ;-) > > Attached change set > > Summary: > > AlphaImageMorph > can now answer effective image bounds for a rectangle in display bounds > allows use of on-screen crop tools etc. to specify area in image terms with respect to layout/scaling etc. > CheckboxButtonMorph > always honour explicit click/move handlers > CheckboxMorph > extra property to facilitate taking keyboard focus on click (can be used in conjunction with text editors to accept on (keyboard) focus change) > shrink horizontally by default > update enablement on label change > DropListMorph > support wrapSelector on underlying list > FileDialogWindow > update file list when directories added/removed > ListModel > extra change/update aspect for list order (allows using a list model to reorder a list via drag/drop) > MorphicUIManager > openModel uses detected modal morph rather than blocking World by default > PSMCPatchOperationWrapper > use summary of definition (avoid MNU on #selector for reorganisation operations) > PluggableButtonMorph > extra property to facilitate taking keyboard focus on click > PluggableSliderMorph > avoid possible ZeroDivide on bad parameters > PluggableTextFieldMorph > minor performance, reuse already calculated string > ToggleMenuItemMorph > centre text when vertical extent more than minimum > UITheme > Use a PanelMorph for label groups (allows disablement of group... ideally would want a major rework for parent enablement dependency though) > > Regards, Gary > <PolymorphChanges.7.cs>

Nov. 12, 2011

Re: [Pharo-project] [Moose-dev] mooseentitystate

by StÃ©phane Ducasse

good idea. if you have a piece of code send it. Stef On Nov 9, 2011, at 9:32 AM, jannik.laval wrote: > Hi Stef, > > It is not so simple :) > Take this example from Moose: > > === > LANNode methodDictionary collect:[:e | e timeStamp ifNotEmpty: [:s | s subStrings first ]] > === > > LANNode has no author, so if you take the first substring you will have the date of creation. > I have not a good solution, but for my scripts, I test the first character of the substring: if it is a letter, this is an author, else, there is no author. > === > ((myString subStrings) first at:1) isLetter > === > > Cheers, > > On Nov 6, 2011, at 21:48 , StÃ©phane Ducasse wrote: > >> http://code.google.com/p/pharo/issues/detail?id=4971 >> >>> >>>> In moose ? because in pharo this is like that and the changes I added where just to make sure that all the clients do not have to deal with timestamp stupid parsing. >>>> >>> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > --- > Jannik Laval > >

Nov. 12, 2011

[Pharo-project] FFI wish list: double arrays and friends

by Schwab,Wilhelm K

Sig, Stef is hinting that you are going to have some good news about OpenGL and FFI in general. One area in which I have been fumbling along is arrays of doubles, float, signed and unsigned single and double words. Some of it is redundant and arguably more about making code written for Dolphin happy in Pharo, but the doubles really are missing. Alignment is a concern; I have been lucky. It would be nice to get it right. I (ab)use byte arrays to hold the data, have some accessors that I seldom use (most of the access is, thankfully for speed, through functions in external libraries). Ideally, Pharo would provide a full range of double, float, signed and unsigned single and double and probably quad words with FFI awareness of all of them. Where is all of this going? My GSL interface is scarred by the past lack of support for underscores, and really needs to be rebuilt now that this is no longer a problem. It's even worse with PLplot because their function names are mystifyingly cryptic; Camel Case them and they are *completely* unrecognizable :( Another wrinkle with GSL is that I was unable to load it (as-is) on Linux. At least at the time, there were two libraries (GSL itself and BLAS) that were inter-dependent. A library that uses both would load, but the individual libraries would not open via FFI. I put a bunch of my own code, and some proprietary code, into the library that allows the offenders to load. With license constraints and the joys of GPL, I need to separate these things before a public release. It would be nice to clean all of this stuff at one shot and get first releases of PLplot and GSL bindings for Pharo. Callbacks would provide clean use of the minimizers and solvers in GSL, allowing me to remove a lot of confusing junk that I added to work around the missing features. It should be worth the wait. Bill

Nov. 12, 2011

Re: [Pharo-project] FS and binary files

by Johannes Rasche

ok Lukas, that works :) Am 12.11.11 13:43, schrieb Lukas Renggli: > Use #fileStreamDo: or #fileStreamWritable:do: > > Lukas > > On 12 November 2011 13:19, Johannes Rasche<johannesrasche(a)mac.com> wrote: >> Hi Sean, >> >> thanks for your effort and advice, >> >> but it didn't resolve my problem: >> try to open an image file with "PNGReadWriter on: xxx.png" >> >> Lukas wrote: >> "In Colin's code you had to use the third supported stream type: not >> #readStream and not #writeStream (that are minimal ANSI compatible streams), >> but a third kind that I forgot the name of (it would return a >> RBBinaryReadWriteStream that works with most existing code). " >> >> Johannes >> >> Am 11.11.11 16:55, schrieb Sean P. DeNigris: >>> Johannes Rasche wrote: >>>> as FS appeared, I had the impression, that this would be the long >>>> awaited replacement of FileDirectory, >>>> >>>> but it doesn't seem so, because it's not part of the official Pharo up >>>> to now (1.3), >>>> >>> I couldn't wait, so I loaded it in my 1.3-rc image and have been happily >>> using it problem free for 1.5 weeks... >>> >>> Gofer new >>> squeaksource: 'fs'; >>> package: 'ConfigurationOfFilesystem'; >>> load. >>> (Smalltalk at: #ConfigurationOfFilesystem) load. >>> >>> Since Pharo's FS fork is being worked on in 1.4, I may have to port my >>> code >>> slightly for 1.4, but I couldn't go on any longer with FileDirectory, it >>> hurt too much ;-) >>> >>> -- >>> View this message in context: >>> http://forum.world.st/FS-and-binary-files-tp4019963p4031734.html >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >> >> > > -- Johannes Rasche /Hagelberger Str. 56 10965 Berlin mail johannesrasche(a)mac.com mobile +49 1577 175 04 75/

Nov. 12, 2011

Re: [Pharo-project] Slides Pharo talk Smalltalks

by Schwab,Wilhelm K

Stef, My guess will be an optimistic one :) It is of course non-binding, but that sounds great. With Sig on the job, probability of success is high. Re FFI and threading, Eliot described some very interesting ideas a while back; if you are undecided on how to proceed, it would be worth reading his posts on the subject. Callbacks would be most welcome. Loosely related to all of this is handling arrays of doubles in FFI, which brings up alignment. I know I am not doing this stuff correctly, but I have been getting away with it, and it is crucial to putting GSL (or other libraries) to work. I'll start another thread on the topic. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of StÃ©phane Ducasse [Stephane.Ducasse(a)inria.fr] Sent: Friday, November 11, 2011 3:50 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Slides Pharo talk Smalltalks > One thing jumped off the page: the intersection of OpenGL, Sig and NativeBoost. It says "done on Windows" which I *hope* means that Linux and Mac are planned??? I will let you guess. > Being able to embed 3D worlds in "normal" desktop software would be huge (virtual reality/visualization, simulation, etc.). > Question: does this suggest that NativeBoost should advance in the FFI roadmap? AFAIK, I do not care whether FFI, Alien or NativeBoost becomes the first complete FFI solution for us. I mostly want to see callbacks and some level of multi-threading. It would be nice if existing FFI method definitions continued to work, but that's negotiable. The idea is that we would like in january to have one ffi fully working (callback, threaded...â¦..) > On threads, the most important objective is to be able to call into a library without blocking the entire image. If callbacks are not possible from such a function, I could learn to live with that - it's more than we have now. If allowed, I would expect that callbacks would be limited to the calling Process in some way. One could/should use queues, semaphores or deferred actions to make things felt in the UI. > > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] > Sent: Tuesday, November 08, 2011 4:54 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Slides Pharo talk Smalltalks > > I should release my annotated version because it explains the vision behind each itemâ¦ > > Should fish it. > > On Nov 8, 2011, at 8:35 PM, Sven Van Caekenberghe wrote: > >> >> On 08 Nov 2011, at 18:25, Marcus Denker wrote: >> >>> Here are the Slides of the Pharo talk at Smalltalks2011: >>> >>> PDF: http://www.marcusdenker.de/talks/11Smalltalks/2011-Smalltalks-Denker-Pharo.… >>> SlideShare: http://www.slideshare.net/MarcusDenker/pharo-one-year-later >>> >>> All talks where filmed, so there will be a video later at http://www.fast.org.ar/smalltalks2011 >> >> Beautiful and cool slides, as always, Marcus. >> >> Yes the Pharo community did a lot of work this passed year, and the future looks really exciting ! >> >> It feels good to be part of this. >> >> Thx for sharing. >> >> Sven >> >> >> >> > > >

Nov. 12, 2011

Re: [Pharo-project] FS and binary files

by Lukas Renggli

Use #fileStreamDo: or #fileStreamWritable:do: Lukas On 12 November 2011 13:19, Johannes Rasche <johannesrasche(a)mac.com> wrote: > Hi Sean, > > thanks for your effort and advice, > > but it didn't resolve my problem: > try to open an image file with "PNGReadWriter on: xxx.png" > > Lukas wrote: > "In Colin's code you had to use the third supported stream type: not > #readStream and not #writeStream (that are minimal ANSI compatible streams), > but a third kind that I forgot the name of (it would return a > RBBinaryReadWriteStream that works with most existing code). " > > Johannes > > Am 11.11.11 16:55, schrieb Sean P. DeNigris: >> >> Johannes Rasche wrote: >>> >>> as FS appeared, I had the impression, that this would be the long >>> awaited replacement of FileDirectory, >>> >>> but it doesn't seem so, because it's not part of the official Pharo up >>> to now (1.3), >>> >> I couldn't wait, so I loaded it in my 1.3-rc image and have been happily >> using it problem free for 1.5 weeks... >> >> Â Â Â Â Gofer new >> Â Â Â Â Â Â Â Â squeaksource: 'fs'; >> Â Â Â Â Â Â Â Â package: 'ConfigurationOfFilesystem'; >> Â Â Â Â Â Â Â Â load. >> Â Â Â Â (Smalltalk at: #ConfigurationOfFilesystem) load. >> >> Since Pharo's FS fork is being worked on in 1.4, I may have to port my >> code >> slightly for 1.4, but I couldn't go on any longer with FileDirectory, it >> hurt too much ;-) >> >> -- >> View this message in context: >> http://forum.world.st/FS-and-binary-files-tp4019963p4031734.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > > > -- Lukas Renggli www.lukas-renggli.ch

Nov. 12, 2011

Re: [Pharo-project] FS and binary files

by Johannes Rasche

Hi Sean, thanks for your effort and advice, but it didn't resolve my problem: try to open an image file with "PNGReadWriter on: xxx.png" Lukas wrote: "In Colin's code you had to use the third supported stream type: not #readStream and not #writeStream (that are minimal ANSI compatible streams), but a third kind that I forgot the name of (it would return a RBBinaryReadWriteStream that works with most existing code). " Johannes Am 11.11.11 16:55, schrieb Sean P. DeNigris: > Johannes Rasche wrote: >> as FS appeared, I had the impression, that this would be the long >> awaited replacement of FileDirectory, >> >> but it doesn't seem so, because it's not part of the official Pharo up >> to now (1.3), >> > I couldn't wait, so I loaded it in my 1.3-rc image and have been happily > using it problem free for 1.5 weeks... > > Gofer new > squeaksource: 'fs'; > package: 'ConfigurationOfFilesystem'; > load. > (Smalltalk at: #ConfigurationOfFilesystem) load. > > Since Pharo's FS fork is being worked on in 1.4, I may have to port my code > slightly for 1.4, but I couldn't go on any longer with FileDirectory, it > hurt too much ;-) > > -- > View this message in context: http://forum.world.st/FS-and-binary-files-tp4019963p4031734.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Nov. 12, 2011