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

Re: [Pharo-project] MVP: quite interesting.

by Benjamin

On Nov 17, 2011, at 10:49 PM, StÃ©phane Ducasse wrote: > http://www.mimuw.edu.pl/~sl/teaching/00_01/Delfin_EC/Overviews/ModelViewPre… > > Stef

Feb. 4, 2012

Re: [Pharo-project] Starting the sprint @ lille :)

by Nicolas Petton

Cool! I'll hope I'll be joining you for the next one :) Cheers, Nico On Sat, 2012-02-04 at 11:44 +0100, StÃ©phane Ducasse wrote: >

Feb. 4, 2012

[Pharo-project] Starting the sprint @ lille :)

by StÃ©phane Ducasse

Feb. 4, 2012

Re: [Pharo-project] Pharo Morphic View Application Framework

by S Krish

The PDF documentation of the framework. Obliged for review/ read and comment and try out the first release.. Ben, I have done a first read of the Spec and I will get my head around how this should be converge.. Will work on that. Though I must note that the spec framework I have laid out is simplistic, flexible and uses the current framework of classes/ morphs without the ValueModel wrapper. Perhaps there is a common ground there, but I would like to emphasize on flexibility of spec and explicit construction to mix and built out has been central to the thought process. On Tue, Jan 31, 2012 at 10:28 AM, S Krish <krishnamachari.sudhakar(a)gmail.com > wrote: > > http://skrishnamachari.wordpress.com/2012/01/31/pharo-application-framework… > > Obliged for feedback ... > > For details and links.. > > Sharing this little framework that should go some way to ease creating > large applications ( currently morphic oriented). > > AbstractMorphicView subclass: #MyNewView â¦ > > #createMorphsSpecs > > ^{ > > âpanel1â² -> #SomeOtherView. > âlabel1â² -> #LabelMorph. > âtext1â² -> #PluggableTextMorph. > âbutton1â² -> #PluggableButtonMorph. > } > > layoutSpecsArray > > ^{ > âwidgetNameInMorphsDictionaryâ -> { > #fractions -> (0 @ 0 corner: 1 @ 0.5). â fractional value 0 to 1 range â > #offsets -> (10 @ 10 corner: 0 @ 0). â offsets relative to the fractional > position â > }. > > ââ¦ add other widgetspecsâ¦â > } > > Thats it.. you should have a prototype UI neatly laid out.. and then > specify: #morphsPrimaryPropertiesSpecs and #morphsSecondaryPropertiesSpecs > for full functionality that composes views inside views and scales well. > > AbstractSimpleMorphicView can make it simpler for TableLayout stuff > without requiring #layoutSpecsArray. > > ..... the main post has other details and links to package... >

Feb. 4, 2012

Re: [Pharo-project] About linkedlist

by Igor Stasenko

btw, i doubt that there's code which relying on destructive behavior of that prim. because in order to use such "destructive behavior" for own benefit it requires a bit of thought effort :) if you need such "erasing" (can't even find a proper term for it) replacement, then it is more natural that developer will write it by hand, instead of using a primitive with elusive (and perhaps unintended) behavior. from other side, making a new prim is better, because then image-side can do a workarounds if it not there. and i think we don't even need to implement that prim twice. what we can do is to fix the implementation of old one and then put it in additional slot of primitiveTable. -- Best regards, Igor Stasenko.

Feb. 3, 2012

Re: [Pharo-project] About linkedlist

by Igor Stasenko

oh, wait.. a test should be like following: rCopy := replacement copy. receiver replaceFrom: a to: b with: replacement startingAt: c. a to: b do: [:i | Â self assert: (receiver at: i) == (rCopy at: c + i - 1) ] -- Best regards, Igor Stasenko.

Feb. 3, 2012

Re: [Pharo-project] About linkedlist

by Igor Stasenko

On 3 February 2012 21:42, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > lukas may be you should send that to the vm mailing-list. > If you need we can ask igor :) (even if he is busy right now). > implementing it wont be a big deal. i just trying to understand, what is "destructive" vs "non-destructive" behavior in replaceFrom:to:with:startingAt: is it right in my understanding that you want to always meet a following criteria: receiver replaceFrom: a to: b with: replacement startingAt: c. a to: b do: [:i | self assert: (receiver at: i) == (replacement at: c + i - 1) ] ? (irrespectible, of course if receiver == replacement or not ) > Stef > > > On Feb 3, 2012, at 5:35 PM, Nicolas Cellier wrote: > >>> >>> Just a note to the VM developers: The primitive >>> Array>>#replaceFrom:to:with:startingAt: is absolutely central to the >>> implementation of efficient collections. While it works well if you >>> copy from one array to the other, it is broken if source and >>> destination array are the same and the areas overlap. Would it be >>> possible to fix this. Even "memmove(void*, void*, size_t)" in C can >>> handle this situation correctly. >>> >> > > -- Best regards, Igor Stasenko.

Feb. 3, 2012

Re: [Pharo-project] Command Line Interface using FFI

by Eliot Miranda

On Fri, Feb 3, 2012 at 1:16 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > > On Tue, Jan 31, 2012 at 8:35 PM, S Krish < > krishnamachari.sudhakar(a)gmail.com> wrote: > >> I cant get the stdin on FileStream to work. Just blocks irrespective of >> what I do in sending characters with enter.. or any other trials .. will >> check a little more > > > I assure you it does work with the right image-level code. Here's an > interaction with a 3.8/Qwaq derived image on Mac OS: > > McStalker.macbuild$ uname -a > Darwin McStalker 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:32:41 > PDT 2011; root:xnu-1504.15.3~1/RELEASE_X86_64 x86_64 i386 > McStalker.macbuild$ oscfvm ~/Cog/startreader.image > squeak> DateAndTime now! > 2012-02-03T13:04:24-08:00 > squeak> Smalltalk quit! > McStalker.macbuild$ > > On linux: > [eliot@mcqfes ~]$ oscogvm/coglinux/squeak Cog/startreader.image > squeak> Smalltalk quit! > [eliot@mcqfes ~]$ uname -a > Linux mcqfes 2.6.18-128.el5 #1 SMP Wed Jan 21 10:44:23 EST 2009 i686 i686 > i386 GNU/Linux > [eliot@mcqfes ~]$ oscogvm/coglinux/squeak Cog/startreader.image > squeak> DateAndTime now! > 2012-02-03T13:05:58-08:00 > squeak> Smalltalk quit! > [eliot@mcqfes ~]$ > > And windows: > U:\Cog>ver > > Microsoft Windows XP [Version 5.1.2600] > > U:\Cog>oscogvm\cygwinbuild\build\vm\CroquetConsole.exe startreader.image > squeak> DateAndTime now! > 2012-02-03T13:07:39-08:00 > squeak> Smalltalk quit! > > U:\Cog> > > It's crude, using chunk format, but demonstrates the functionality and is > very simple. To get this to work requires the attached nextChunkNoTag hack > since restoreState:with: seems unreliable (it implements skip: -1, which is > used in peek). For Windows you need the 2519 or newer Cog VM. > Oops. And to launch it I use this in a workspace: Smalltalk saveAs. [StdioListener new run] newProcess priority: Processor activePriority + 1; resume but Smalltalk saveAs. StdioListener new run should work too, its just that there won't be any UI, because the listener is running in the active UI process. With the threaded VM one can interact with the UI while the listener is blocked. With the non-threaded VM, it is blocked in the read. So to interact with the UI type something like (Delay forSeconds: 1000) wait! > >> >> On Wed, Feb 1, 2012 at 5:06 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: >> >>> >>> >>> On Tue, Jan 31, 2012 at 4:10 AM, Damien Pollet <damien.pollet(a)gmail.com>wrote: >>> >>>> On 29 January 2012 21:11, Guillermo Polito <guillermopolito(a)gmail.com> >>>> wrote: >>>> > I've spent a few hours playing with Alien+FFI and I did want to have a >>>> > Command line interface to play and use as a quick browser. >>>> >>>> This is something I'd like to have as a part of Coral. >>>> >>>> What's your opinion on the FFI-libc approach compared to OSProcess? I >>>> was actually thinking of doing something like that using NativeBoost >>>> :) >>>> >>> >>> There is a third option which just uses the stdio streams in >>> StandardFileStream. this has been working in the Cog VMs for some time now. >>> >>> >>>> > Gofer it >>>> > squeaksource: 'CLInterface'; >>>> > package: 'ConfigurationOfCLInterface'; >>>> > load. >>>> > >>>> > ConfigurationOfCLInterface load. >>>> > >>>> > >>>> > To play with it write a script, for example startCLI.st, with the >>>> following: >>>> > >>>> > CLInterface start >>>> > >>>> > >>>> > >>>> > And then, from the command line >>>> > >>>> > CogVM -vm-display-null <image> startCLI.st >>>> > >>>> > >>>> > What it does support? >>>> > - executes smalltalk expressions >>>> > - handles the errors and shows them into the stdout (so it does not >>>> explode >>>> > :P) >>>> > - stores variables as a workspace >>>> > Since I used standard C functions (fgets and printf only) this should >>>> work >>>> > on every platform from scratch (having a VM with FFI working, of >>>> course)... >>>> > >>>> > The problems I've ran so far: >>>> > - blocking FFI blocks the vm. I've not tried yet to use threads >>>> through FFI >>>> > (and I don't know if it works. Does it?). But It should be great to >>>> start >>>> > a headless seaside server with a command line :/. >>>> > >>>> > Ok, it's a very simple thing, but it allows to execute a expression >>>> from a >>>> > remote server via ssh without doing much :). >>>> > >>>> > Guille >>>> >>>> >>>> >>>> -- >>>> Damien Pollet >>>> type less, do more [ | ] http://people.untyped.org/damien.pollet >>>> >>>> >>> >>> >>> -- >>> best, >>> Eliot >>> >>> >> > > > -- > best, > Eliot > > -- best, Eliot

Feb. 3, 2012

Re: [Pharo-project] Command Line Interface using FFI

by Eliot Miranda

On Tue, Jan 31, 2012 at 8:35 PM, S Krish <krishnamachari.sudhakar(a)gmail.com>wrote: > I cant get the stdin on FileStream to work. Just blocks irrespective of > what I do in sending characters with enter.. or any other trials .. will > check a little more I assure you it does work with the right image-level code. Here's an interaction with a 3.8/Qwaq derived image on Mac OS: McStalker.macbuild$ uname -a Darwin McStalker 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:32:41 PDT 2011; root:xnu-1504.15.3~1/RELEASE_X86_64 x86_64 i386 McStalker.macbuild$ oscfvm ~/Cog/startreader.image squeak> DateAndTime now! 2012-02-03T13:04:24-08:00 squeak> Smalltalk quit! McStalker.macbuild$ On linux: [eliot@mcqfes ~]$ oscogvm/coglinux/squeak Cog/startreader.image squeak> Smalltalk quit! [eliot@mcqfes ~]$ uname -a Linux mcqfes 2.6.18-128.el5 #1 SMP Wed Jan 21 10:44:23 EST 2009 i686 i686 i386 GNU/Linux [eliot@mcqfes ~]$ oscogvm/coglinux/squeak Cog/startreader.image squeak> DateAndTime now! 2012-02-03T13:05:58-08:00 squeak> Smalltalk quit! [eliot@mcqfes ~]$ And windows: U:\Cog>ver Microsoft Windows XP [Version 5.1.2600] U:\Cog>oscogvm\cygwinbuild\build\vm\CroquetConsole.exe startreader.image squeak> DateAndTime now! 2012-02-03T13:07:39-08:00 squeak> Smalltalk quit! U:\Cog> It's crude, using chunk format, but demonstrates the functionality and is very simple. To get this to work requires the attached nextChunkNoTag hack since restoreState:with: seems unreliable (it implements skip: -1, which is used in peek). For Windows you need the 2519 or newer Cog VM. > > On Wed, Feb 1, 2012 at 5:06 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > >> >> >> On Tue, Jan 31, 2012 at 4:10 AM, Damien Pollet <damien.pollet(a)gmail.com>wrote: >> >>> On 29 January 2012 21:11, Guillermo Polito <guillermopolito(a)gmail.com> >>> wrote: >>> > I've spent a few hours playing with Alien+FFI and I did want to have a >>> > Command line interface to play and use as a quick browser. >>> >>> This is something I'd like to have as a part of Coral. >>> >>> What's your opinion on the FFI-libc approach compared to OSProcess? I >>> was actually thinking of doing something like that using NativeBoost >>> :) >>> >> >> There is a third option which just uses the stdio streams in >> StandardFileStream. this has been working in the Cog VMs for some time now. >> >> >>> > Gofer it >>> > squeaksource: 'CLInterface'; >>> > package: 'ConfigurationOfCLInterface'; >>> > load. >>> > >>> > ConfigurationOfCLInterface load. >>> > >>> > >>> > To play with it write a script, for example startCLI.st, with the >>> following: >>> > >>> > CLInterface start >>> > >>> > >>> > >>> > And then, from the command line >>> > >>> > CogVM -vm-display-null <image> startCLI.st >>> > >>> > >>> > What it does support? >>> > - executes smalltalk expressions >>> > - handles the errors and shows them into the stdout (so it does not >>> explode >>> > :P) >>> > - stores variables as a workspace >>> > Since I used standard C functions (fgets and printf only) this should >>> work >>> > on every platform from scratch (having a VM with FFI working, of >>> course)... >>> > >>> > The problems I've ran so far: >>> > - blocking FFI blocks the vm. I've not tried yet to use threads >>> through FFI >>> > (and I don't know if it works. Does it?). But It should be great to >>> start >>> > a headless seaside server with a command line :/. >>> > >>> > Ok, it's a very simple thing, but it allows to execute a expression >>> from a >>> > remote server via ssh without doing much :). >>> > >>> > Guille >>> >>> >>> >>> -- >>> Damien Pollet >>> type less, do more [ | ] http://people.untyped.org/damien.pollet >>> >>> >> >> >> -- >> best, >> Eliot >> >> > -- best, Eliot

Feb. 3, 2012

Re: [Pharo-project] About linkedlist

by StÃ©phane Ducasse

lukas may be you should send that to the vm mailing-list. If you need we can ask igor :) (even if he is busy right now). Stef On Feb 3, 2012, at 5:35 PM, Nicolas Cellier wrote: >> >> Just a note to the VM developers: The primitive >> Array>>#replaceFrom:to:with:startingAt: is absolutely central to the >> implementation of efficient collections. While it works well if you >> copy from one array to the other, it is broken if source and >> destination array are the same and the areas overlap. Would it be >> possible to fix this. Even "memmove(void*, void*, size_t)" in C can >> handle this situation correctly. >> >

Feb. 3, 2012