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

Re: [Pharo-project] [squeak-dev] Morphic on HTML+CSS

by Janko MivÅ¡ek

S, info(a)tomsik.cz piÅ¡e: > I am no squeak/pharo/cuis master, > > but in my opinion the best approach is still "objects as servers" > - no matter what html6 will be able to do, it won't be enough. > > however html5+js means we can leverage ajax - and provide illusion > of objects as servers - and that's cool. > > so: > > 1. yes > 2. not sure, I'd rather spend energy on something different. Remember that we the web guys are spending energy close to that goal for quite a while already. The Iliad/Aida (bit less Seaside) component model is close to what Morphic is, as far I know Morphic. And with Jtalk we can cover JavaScript from Smalltalk code too. Add the open-source and portable WebKit [1] based foundation like many web browsers have and we are there! So, if we point ourselves to this direction, for sure someone will come with a courage to experiment in approximately this way: - WebKit based foundation - Iliad/Aida component model adopted to Morphic on top - Jtalk for running JavaScript from Smalltalk - Squeak/Pharo image with more or less unchanged tools So, we switch one level higher in running Squeak/Pharo GUI: from bare operating system's graphic/windowing support to WebKit based HTML5/CSS/JavaScript one. With HTML5 Canvas and WebGL for HW optimized graphics,... Janko [1] http://www.webkit.org/ > On Tue, 14 Jun 2011 13:41:45 +0200, Janko MivÅ¡ek > <janko.mivsek(a)eranova.si> wrote: > >> Hi all, >> >> In light of recent Microsoft surprising U-turn announcement [1] that in >> Windows 8 it swithes to HTML5 (HTML5+CSS+JavaScript) instead of .NET+WPF >> and Silverlight for desktop app development it is IMO a right time to >> think about: >> >> 1. is this a clear signal that HTML5 for ALL apps, both desktop and the >> web is inevitable? >> 2. is this a clear signal that we need to rebuild Morphic on top of >> HTML+CSS, to leverage all Morphic advantages and come back >> to bleeding edge again? >> >> I think yes. What Squeak/Pharo/Cuis GUI masters say? >> >> Best regards >> Janko >> >> [1] >> http://arstechnica.com/microsoft/news/2011/06/html5-centric-windows-8-leave… >> -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

June 14, 2011

[Pharo-project] Morphic on HTML+CSS

by Torsten Bergmann

Not only .NET ... also JavaFX 2.0 is using CSS for skinning: http://download.oracle.com/javafx/2.0/css_tutorial/jfxpub-css_tutorial.htm Bye T. -- NEU: FreePhone - kostenlos mobil telefonieren! Jetzt informieren: http://www.gmx.net/de/go/freephone

June 14, 2011

[Pharo-project] Morphic on HTML+CSS

by Janko MivÅ¡ek

Hi all, In light of recent Microsoft surprising U-turn announcement [1] that in Windows 8 it swithes to HTML5 (HTML5+CSS+JavaScript) instead of .NET+WPF and Silverlight for desktop app development it is IMO a right time to think about: 1. is this a clear signal that HTML5 for ALL apps, both desktop and the web is inevitable? 2. is this a clear signal that we need to rebuild Morphic on top of HTML+CSS, to leverage all Morphic advantages and come back to bleeding edge again? I think yes. What Squeak/Pharo/Cuis GUI masters say? Best regards Janko [1] http://arstechnica.com/microsoft/news/2011/06/html5-centric-windows-8-leave… -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

June 14, 2011

Re: [Pharo-project] [update 1.3] #13263

by Pavel Krivanek

...and http://code.google.com/p/pharo/issues/detail?id=4403 On Tue, Jun 14, 2011 at 11:49 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Thank you for the fast integration. > > Please try to integrate this three small issues too. Then I will be > able to remove one script from the PharoKernel generation. > > http://code.google.com/p/pharo/issues/detail?id=4402 > > http://code.google.com/p/pharo/issues/detail?id=4400 > > http://code.google.com/p/pharo/issues/detail?id=3107 > > Cheers, > -- Pavel > > On Tue, Jun 14, 2011 at 10:28 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> 13263 >> ----- >> >> Issue 4398: Â Â saveImageInNewContext >> Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=4398 >> >> Issue 4395: Â Â ChangeSet class>>#fileIntoNewChangeSet: dependent on Compression >> Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=4395 >> >> Issue 4397: Â Â FileStream class>>#fileIn: dependent on Compression >> Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=4397 >> >> Issue 4396: Â Â DeepCopier warnIverNotCopiedIn:sel: and tools >> Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=4396 >> >> >> >> -- >> Marcus Denker Â -- http://www.marcusdenker.de >> INRIA Lille -- Nord Europe. Team RMoD. >> >> >> >

June 14, 2011

Re: [Pharo-project] WindowOrganiser (was: Tab widget improvements)

by Henrik Sperre Johansen

On 10.06.2011 08:56, StÃ©phane Ducasse wrote: > excellent!!! > We need to use the same in Nautilus and Glamour > > Stef > On Jun 10, 2011, at 8:52 AM, laurent laffont wrote: Just a minor nitpick, but if it is to be included in core it should probably change name to WindowOrganizer, to keep in spirit with the absence of EN_UK spelling in other class names :) Cheers, Henry

June 14, 2011

Re: [Pharo-project] [update 1.3] #13263

by Pavel Krivanek

Thank you for the fast integration. Please try to integrate this three small issues too. Then I will be able to remove one script from the PharoKernel generation. http://code.google.com/p/pharo/issues/detail?id=4402 http://code.google.com/p/pharo/issues/detail?id=4400 http://code.google.com/p/pharo/issues/detail?id=3107 Cheers, -- Pavel On Tue, Jun 14, 2011 at 10:28 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > 13263 > ----- > > Issue 4398: Â Â saveImageInNewContext > Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=4398 > > Issue 4395: Â Â ChangeSet class>>#fileIntoNewChangeSet: dependent on Compression > Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=4395 > > Issue 4397: Â Â FileStream class>>#fileIn: dependent on Compression > Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=4397 > > Issue 4396: Â Â DeepCopier warnIverNotCopiedIn:sel: and tools > Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=4396 > > > > -- > Marcus Denker Â -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > >

June 14, 2011

Re: [Pharo-project] Fuel - a fast object deployment tool

by Henrik Sperre Johansen

On 13.06.2011 19:16, Mariano Martinez Peck wrote: > > > On Thu, Jun 9, 2011 at 3:35 AM, Eliot Miranda <eliot.miranda(a)gmail.com > <mailto:eliot.miranda@gmail.com>> wrote: > > Hi Martin and Mariano, > > a couple of questions. What's the right way to exclude > certain objects from the serialization? Is there a way of > excluding certain inst vars from certain objects? > > > > Eliot and the rest....Martin implemented this feature in > Fuel-MartinDias.258. For the moment, we decided to put > #fuelIgnoredInstanceVariableNames at class side. > > Behavior >> fuelIgnoredInstanceVariableNames > "Indicates which variables have to be ignored during serialization." > > ^#() > > > MyClass class >> fuelIgnoredInstanceVariableNames > ^ #('instVar1') > > > The impact in speed is nothing, so this is good. Now....we were > thinking if it is common to need that 2 different instances of the > same class need different instVars to ignore. Is this common ? do you > usually need this ? We checked in SIXX and it is at instance side. > Java uses the prefix 'transient' so it is at class side... > > thanks > > > -- > Mariano > http://marianopeck.wordpress.com > You can have variables on both instances and classes. I believe in SIXX you send #sixxIgnorableInstVarNames to the object you want to serialize. IE. on class side you define ignorable class instance variables, while on instance side you define ignorable instance variables. Cheers, Henry

June 14, 2011

Re: [Pharo-project] Fuel serialization - feature/bug

by Mariano Martinez Peck

So..using (Fuel-MartinDias.259) I added FSMemoryStore class >> fuelIgnoredInstanceVariableNames ^#(root) PRFuelPersistency class >> fuelIgnoredInstanceVariableNames ^#(directory) The tests are all green. Cheers On Tue, Jun 14, 2011 at 10:15 AM, Martin Dias <tinchodias(a)gmail.com> wrote: > Hi Yanni > > On Tue, Jun 14, 2011 at 3:12 AM, Yanni Chiu <yanni(a)rogers.com> wrote: > >> On 13/06/11 6:56 PM, Yanni Chiu wrote: >> >>> On 13/06/11 5:49 PM, Mariano Martinez Peck wrote: >>> >>>> >>>> mmmmmm so you are using a stream to serialize and such stream is also >>>> being refenced from the object to serialize? >>>> >>> >>> Yes, that's it - except that the stream is an FSWriteStream on a >>> FSMemoryStore "file", which I think is an issue here. The PRKernel is >>> holding an instance of PRFuelPersistency, which holds an FSReference. >>> That FSReference happens to refer to a memory-based "file". >>> >> >> The code is at http://ss3.gemstone.com/ss/pierfuel.html >> >> You'll first need a Pier image, with the following loaded: >> >> (ConfigurationOfFilesystem project version: '2.0.1-baseline') load >> >> (ConfigurationOfFuel project version: '1.4') load >> OR >> (ConfigurationOfFuel project version: '1.5-baseline') load >> >> If you run PRFuelPersistencyTest, then you'll see the stack trace. I saw >> the same problem with 1.4 and with 1.5-baseline. >> >> In the 1.5-baseline, I added #fuelIgnoredInstanceVariableNames to >> PRFuelPersistency and FSMemoryStore (to ignore 'directory' and 'root', >> respectively) but the same problem remained. So I think it's a bug. >> > > I didn't try in the Pier image, but I hope your problem is fixed with the > last version (Fuel-MartinDias.259). > > serialize the stream where you are serializing is a test case I had never > thought! > > BTW, is it fine to get nil on these variables? I mean, is the FSMemoryStore > materialized useful? > > >> >> Despite the test failing, the PRFuelPersistency works as expected to >> save/restore a Pier kernel to/from a file. The file is 30 times smaller than >> the corresponding (uncompressed) SIXX file. >> > > good! so it can be useful for scenarios where you don't need to be > cross-dialect or to have XML format. > > -- Mariano http://marianopeck.wordpress.com

June 14, 2011

[Pharo-project] [update 1.3] #13263

by Marcus Denker

13263 ----- Issue 4398: saveImageInNewContext http://code.google.com/p/pharo/issues/detail?id=4398 Issue 4395: ChangeSet class>>#fileIntoNewChangeSet: dependent on Compression http://code.google.com/p/pharo/issues/detail?id=4395 Issue 4397: FileStream class>>#fileIn: dependent on Compression http://code.google.com/p/pharo/issues/detail?id=4397 Issue 4396: DeepCopier warnIverNotCopiedIn:sel: and tools http://code.google.com/p/pharo/issues/detail?id=4396 -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

June 14, 2011

Re: [Pharo-project] Fuel serialization - feature/bug

by Martin Dias

Hi Yanni On Tue, Jun 14, 2011 at 3:12 AM, Yanni Chiu <yanni(a)rogers.com> wrote: > On 13/06/11 6:56 PM, Yanni Chiu wrote: > >> On 13/06/11 5:49 PM, Mariano Martinez Peck wrote: >> >>> >>> mmmmmm so you are using a stream to serialize and such stream is also >>> being refenced from the object to serialize? >>> >> >> Yes, that's it - except that the stream is an FSWriteStream on a >> FSMemoryStore "file", which I think is an issue here. The PRKernel is >> holding an instance of PRFuelPersistency, which holds an FSReference. >> That FSReference happens to refer to a memory-based "file". >> > > The code is at http://ss3.gemstone.com/ss/pierfuel.html > > You'll first need a Pier image, with the following loaded: > > (ConfigurationOfFilesystem project version: '2.0.1-baseline') load > > (ConfigurationOfFuel project version: '1.4') load > OR > (ConfigurationOfFuel project version: '1.5-baseline') load > > If you run PRFuelPersistencyTest, then you'll see the stack trace. I saw > the same problem with 1.4 and with 1.5-baseline. > > In the 1.5-baseline, I added #fuelIgnoredInstanceVariableNames to > PRFuelPersistency and FSMemoryStore (to ignore 'directory' and 'root', > respectively) but the same problem remained. So I think it's a bug. > I didn't try in the Pier image, but I hope your problem is fixed with the last version (Fuel-MartinDias.259). serialize the stream where you are serializing is a test case I had never thought! BTW, is it fine to get nil on these variables? I mean, is the FSMemoryStore materialized useful? > > Despite the test failing, the PRFuelPersistency works as expected to > save/restore a Pier kernel to/from a file. The file is 30 times smaller than > the corresponding (uncompressed) SIXX file. > good! so it can be useful for scenarios where you don't need to be cross-dialect or to have XML format.

June 14, 2011