- Pharo-dev - lists.pharo.org

[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

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

by Mariano Martinez Peck

On Tue, Jun 14, 2011 at 9:37 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Tue, Jun 14, 2011 at 8: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 > > BTW you put them as class side methods, don't you? > (to ignore 'directory' and 'root', respectively) but the same problem >> remained. So I think it's a bug. >> >> > Yes, We think you have spot a bug :) > Martin is working on that. We will let you know. Thanks > > >> 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. >> >> >> > and speed? could you measure serialization / materialization time ? > > Thanks a lot, > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

June 14, 2011