- Pharo-dev - lists.pharo.org

Re: [Pharo-project] usability of Pharo and Squeak

by laurent laffont

For me Emacs is the best development environment, this is the vision that push me to do TWM. Laurent. On Thu, Jun 2, 2011 at 12:23 PM, Andreas Wacknitz <A.Wacknitz(a)gmx.de> wrote: > After following the discussion for some time, I have the impression that > there are some smalltalkers suffering similar usability problems like my > friend and me and some more or less enjoy the actual state. > Dolphin 6 Professional introduced IdeaSpace. With that you can have both - > single windows and tabbed windows. > It's up to the user to either open windows outside IdeaSpace as independent > windows or inside IdeaSpace as tabbed windows. > Having the free choice is a good thing. Especially if you don't want to > alienate newcomers that are used to use tabbed windows. I like this > approach. > > I haven't looked at TWM yet due to lack of time. I am hardly able to read > the mail traffic in the evenings. > But I asked my friend to have a look at it. He promised to do so although > it's not suited to Pharo 1.2.1. > As Pharo 1.3 is not yet stable I fear that he might have new problems in > other areas. > > What strikes me during this discussion is that nobody seem to have the same > problem with window sizes and positions. > I don't like RealEstateAgent and I don't think that a revamped one will > solve the problems. At least as long it doesn't provide the possibility > to set sizes on the fly. No algorithm can guess the requirements of all > users. > I also haven't heard about applications written in Squeak or Pharo and what > about user thereof think about the usability. IMO there is a lack of > an appropriate framework for dealing with such things. Or is everybody > developing web applications nowadays? > > I have a hard time to promote Smalltalk because of its actual state. I > always tell people about my favorite programming > language, but I also tell them that alas there is no good implementation of > it available. This is sad but true, even if Pharo and Squeak made > big progress during the last months. Both, Squeak and Pharo, aren't > products but just tools. And that makes a big difference. > The commercial products have characteristics that make them not very > attractive to people not yet involved. Despite Dolphin they all have > dated user interfaces, too. When I try to convince people to have a look at > Dolphin they typically tell me: very nice but it seems to be dead already. > > Regards, > Andreas >

June 2, 2011

Re: [Pharo-project] creating KOTDC

by GastÃ³n Dall' Oglio

2011/6/2 Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> > +1! > > And as a first project for KOTD we'd like to introduce Scat, the Scratch > port for Pharo we've been working on for a couple of months and that we had > been keeping in secret until Torsten discovered us yesterday ;) > > Here's the blog post: http://smalltalk.cat/blog/Scat+-+Communiqu%E9 > > And here's the project site: code.google.com/p/scat/ > I showed it to my nephew some months back, and he said liked :) > > Cheers! > > Bernat Romagosa. > > > 2011/6/1 Guillermo Polito <guillermopolito(a)gmail.com> > >> >> >> On Wed, Jun 1, 2011 at 12:34 PM, laurent laffont < >> laurent.laffont(a)gmail.com> wrote: >> >>> + 1, and put contents in the Pharo CollaborActive book :) >> >> >> And to HelpSystem! >> > I don't know what this implicate, but I can dedicate some time for this work. If you can help me to learn, I can try :) > >> >>> >>> Laurent. >>> >>> >>> 2011/6/1 GastÃ³n Dall' Oglio <gaston.dalloglio(a)gmail.com> >>> >>>> What do you think about creating this?: >>>> >>>> *Know Of The Day Contest - One Day One Know >>>> Rules >>>> Each day a not known project is elected. Each day the know will be >>>> readed and the project know for more people.* >>>> >>>> >>>> In reality this would not be a contest (which would not be the criterion >>>> for selecting the winner:), but rather a sharing by its ideologues, >>>> developers, users, critics (why not?) and general interest groups, about the >>>> characteristics of a project that is unknown in general. The idea is to >>>> focus on those projects that are not so widely known, in which are already >>>> widely known does not make sense. >>>> >>>> For example about these people who have been named to the list recently: >>>> Gettext package >>>> TestConsoleRunner >>>> http://www.squeaksource.com/Mocketry.html >>>> http://www.squeaksource.com/Keymapping.html >>>> http://www.squeaksource.com/TilingWindowManager >>>> >>>> >>>> >>>> >>>> >>> >> >

June 2, 2011

Re: [Pharo-project] I am serializing correctly with SIXX?

by Mariano Martinez Peck

Yes Igor. You are correct. We should pass the info we have stored in the serialization so that they can initialize correctly :) On Thu, Jun 2, 2011 at 3:42 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 2 June 2011 15:22, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > > > > On Thu, Jun 2, 2011 at 3:00 PM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > >> > >> Btw, what deserializer does, if it discovers that instance of some > >> class, which you want to bring to life from storage > >> now has its format changed? > >> suppose that when saving graph, some class has inst vars 'a b c' > >> but then you changed the class definition and its inst vars now 'a d e' > >> ? > > > > In this, Fuel will materialize the object, set the instVar 'a' and 'd' > and > > 'e' will be with nil. > > After, the user of FUel can do whatever he wants. > > In fact, we will provide soemthing like #initializeFromFuel or something > > like that that is automatically called by Fuel after the materialization. > > We throw error where there is something we cannot do. > > > > Well, then it should be > initializeFromFuel: fuelSpec > > instead of just > initializeFromFuel > > because if you don't know, what were stored in fuel stream, you cannot > properly migrate the instance. > Consider that initially class has inst vars 'a' > and you saved this instance to fuel. > Then you changed ivars to 'a b' > and changed the #initializeFromFuel appropriately. > But then you again changed ivars to 'c b d' > and also changed #initializeFromFuel > Now if you attempt to materialize the instance from first version > (with only 'a'), > you cannot determine what original format of instance were stored in fuel, > and so, you cannot decide what will be a proper migration path: > 'a' -> 'c b d' > or > 'a b' -> 'c b d' > or > 'c b d' -> 'c b d' > > and i think it is better to move this method to class side, then it > can deal with migration before creating an instance. > So you can even replace an instance of original class with something > else (if you refactored your model and no longer want > an instances of old class, so you stub a creation of them in class > side of old class, and create instances of different class instead). > > Or even two-phase materialization: > > SomeClass class>>materializeFromFuel: fuelSpec > ... "some common logic" .. > ^ self basicNew initializeFromFuel: fuelSpec > > so, you will have two polymorphic entry points. > > >> > >> I think it is not a responsibility of serializer to deal with that > >> (there should be a higher level layer which can handle instance > >> migration), > >> while serializer just reports an error that it can't reify an object > >> because its original class are either gone or changed format. > > > > yes, but there are things that we can do (kind of first pass) so that we > can > > give the user the object already mterialized and he can update it. > > > > In fuel, we have these tests: > > > > > > testVariableInsertion > > "Tests that serializer tolarates when there is a new instance > variable > > on materialization" > > > > | stream aPair resultPair | > > > > aPair := (self stubClassWithInstanceVars: 'left right') new. > > aPair instVarAt: 1 put: $A. > > aPair instVarAt: 2 put: $B. > > stream := self serializationOf: aPair. > > > > self stubClassWithInstanceVars: 'left middle right'. > > resultPair := self materializationOn: stream reset. > > self assert: $A equals: (resultPair instVarAt: 1). > > self assert: nil equals: (resultPair instVarAt: 2). > > self assert: $B equals: (resultPair instVarAt: 3). > > > > > > > > testVariableRemoved > > "Tests that serializer tolarates when an instance variable is missing > on > > materialization" > > > > | stream aPair resultPair | > > > > aPair := (self stubClassWithInstanceVars: 'left right') new. > > aPair instVarAt: 1 put: $A. > > aPair instVarAt: 2 put: $B. > > stream := self serializationOf: aPair. > > > > self stubClassWithInstanceVars: 'right'. > > resultPair := self materializationOn: stream reset. > > self assert: $B equals: (resultPair instVarAt: 1). > > > > > > > > testVariableOrderChange > > "Tests that serializer tolarates when the order in the instance > > variables changed between serialization and materialization" > > > > | pairClass stream aPair resultPair | > > > > pairClass := self stubClassWithInstanceVars: 'left right'. > > aPair := pairClass new. > > aPair instVarAt: 1 put: $A. > > aPair instVarAt: 2 put: $B. > > stream := self serializationOf: aPair. > > > > pairClass := self stubClassWithInstanceVars: 'right left'. > > resultPair := self materializationOn: stream reset. > > self assert: $B equals: (resultPair instVarAt: 1). > > self assert: $A equals: (resultPair instVarAt: 2). > > > > > > > > > > > >> > >> On 2 June 2011 14:51, Norbert Hartl <norbert(a)hartl.name> wrote: > >> > > >> > Am 02.06.2011 um 14:31 schrieb Mariano Martinez Peck: > >> > > >> > Thanks Norbert. Now I could successfully run benchmarks for SIXX and > >> > compare > >> > with Fuel. But that's not really fare because we are comparing a text > >> > based > >> > serializer against a binary one. > >> > > >> > It is interesting anyway. I like to know if it is 20 times faster or > >> > even > >> > more. On the other hand it is not fair either. I don't know fuel but I > >> > think > >> > it platform dependent, right? So it is not fair the other way round > >> > because > >> > you compare a cross-platform serializer with a platform-dependent one > ;) > >> > I > >> > think these are the categories that people think about when the are > >> > about to > >> > choose what util to use. > >> > Norbert > >> > > >> > Mariano > >> > > >> > On Thu, Jun 2, 2011 at 12:14 PM, Norbert Hartl <norbert(a)hartl.name> > >> > wrote: > >> >> > >> >> Am 02.06.2011 um 11:42 schrieb Mariano Martinez Peck: > >> >> > >> >> >> serialize: anObject on: aStream > >> >> | sws | > >> >> sws := SixxWriteStream on: aStream. > >> >> sws nextPut: anObject. > >> >> sws close. > >> >> > >> >> serialize: anObject on: aStream > >> >> anObject sixxOn: aStream > >> >> > >> >> >> materializeFrom: aStream > >> >> | srs objects | > >> >> srs := SixxReadStream on: aStream. > >> >> objects := srs contents. > >> >> srs close. > >> >> ^ objects > >> >> > >> >> materializeFrom: aStream > >> >> ^ Object readSixxFrom: aStream > >> >> Norbert > >> >> > >> >> > >> >> > >> >> Is that correct or I am doing it wrong? All I want to do is to > >> >> serialize > >> >> a graph into a stream. > >> >> > >> >> The stream I am using is or this: > >> >> > >> >> (FileDirectory default forceNewFileNamed: 'Bench') > >> >> > >> >> or > >> >> > >> >> (RWBinaryOrTextStream on: '') > >> >> > >> >> > >> >> I am not sure if I should be doing a #nextPut: or a #nextPutAll:. I > >> >> mean, > >> >> sometimes anObject is a collection and sometimes it is not. So, which > >> >> one > >> >> should I use? > >> >> > >> >> Thanks > >> >> > >> >> Mariano > >> >> > >> >> > >> >> -- > >> >> Mariano > >> >> http://marianopeck.wordpress.com > >> >> > >> >> > >> > > >> > > >> > > >> > -- > >> > Mariano > >> > http://marianopeck.wordpress.com > >> > > >> > > >> > > >> > >> > >> > >> -- > >> Best regards, > >> Igor Stasenko AKA sig. > >> > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > > -- Mariano http://marianopeck.wordpress.com

June 2, 2011

Re: [Pharo-project] I am serializing correctly with SIXX?

by Igor Stasenko

On 2 June 2011 15:22, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Thu, Jun 2, 2011 at 3:00 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> Btw, what deserializer does, if it discovers that instance of some >> class, which you want to bring to life from storage >> now has its format changed? >> suppose that when saving graph, some class has inst vars 'a b c' >> but then you changed the class definition and its inst vars now 'a d e' >> ? > > In this, Fuel will materialize the object, set the instVar 'a' and 'd' and > 'e' will be with nil. > After, the user of FUel can do whatever he wants. > In fact, we will provide soemthing like #initializeFromFuelÂ or something > like that that is automatically called by Fuel after the materialization. > We throw error where there is something we cannot do. > Well, then it should be initializeFromFuel: fuelSpec instead of just initializeFromFuel because if you don't know, what were stored in fuel stream, you cannot properly migrate the instance. Consider that initially class has inst vars 'a' and you saved this instance to fuel. Then you changed ivars to 'a b' and changed the #initializeFromFuel appropriately. But then you again changed ivars to 'c b d' and also changed #initializeFromFuel Now if you attempt to materialize the instance from first version (with only 'a'), you cannot determine what original format of instance were stored in fuel, and so, you cannot decide what will be a proper migration path: 'a' -> 'c b d' or 'a b' -> 'c b d' or 'c b d' -> 'c b d' and i think it is better to move this method to class side, then it can deal with migration before creating an instance. So you can even replace an instance of original class with something else (if you refactored your model and no longer want an instances of old class, so you stub a creation of them in class side of old class, and create instances of different class instead). Or even two-phase materialization: SomeClass class>>materializeFromFuel: fuelSpec ... "some common logic" .. ^ self basicNew initializeFromFuel: fuelSpec so, you will have two polymorphic entry points. >> >> I think it is not a responsibility of serializer to deal with that >> (there should be a higher level layer which can handle instance >> migration), >> while serializer just reports an error that it can't reify an object >> because its original class are either gone or changed format. > > yes, but there are things that we can do (kind of first pass) so that we can > give the user the object already mterialized and he can update it. > > In fuel, we have these tests: > > > testVariableInsertion > Â Â Â "Tests that serializer tolarates when there is a new instance variable > on materialization" > > Â Â Â | stream aPair resultPair | > > Â Â Â aPair := (self stubClassWithInstanceVars: 'left right') new. > Â Â Â aPair instVarAt: 1 put: $A. > Â Â Â aPair instVarAt: 2 put: $B. > Â Â Â stream := self serializationOf: aPair. > > Â Â Â self stubClassWithInstanceVars: 'left middle right'. > Â Â Â resultPair := self materializationOn: stream reset. > Â Â Â self assert: $A equals: (resultPair instVarAt: 1). > Â Â Â self assert: nil equals: (resultPair instVarAt: 2). > Â Â Â self assert: $B equals: (resultPair instVarAt: 3). > > > > testVariableRemoved > Â Â Â "Tests that serializer tolarates when an instance variable is missing on > materialization" > > Â Â Â | stream aPair resultPair | > > Â Â Â aPair := (self stubClassWithInstanceVars: 'left right') new. > Â Â Â aPair instVarAt: 1 put: $A. > Â Â Â aPair instVarAt: 2 put: $B. > Â Â Â stream := self serializationOf: aPair. > > Â Â Â self stubClassWithInstanceVars: 'right'. > Â Â Â resultPair := self materializationOn: stream reset. > Â Â Â self assert: $B equals: (resultPair instVarAt: 1). > > > > testVariableOrderChange > Â Â Â "Tests that serializer tolarates when the order in the instance > variables changed between serialization and materialization" > > Â Â Â | pairClass stream aPair resultPair | > > Â Â Â pairClass := self stubClassWithInstanceVars: 'left right'. > Â Â Â aPair := pairClass new. > Â Â Â aPair instVarAt: 1 put: $A. > Â Â Â aPair instVarAt: 2 put: $B. > Â Â Â stream := self serializationOf: aPair. > > Â Â Â pairClass := self stubClassWithInstanceVars: 'right left'. > Â Â Â resultPair := self materializationOn: stream reset. > Â Â Â self assert: $B equals: (resultPair instVarAt: 1). > Â Â Â self assert: $A equals: (resultPair instVarAt: 2). > > > > > >> >> On 2 June 2011 14:51, Norbert Hartl <norbert(a)hartl.name> wrote: >> > >> > Am 02.06.2011 um 14:31 schrieb Mariano Martinez Peck: >> > >> > Thanks Norbert. Now I could successfully run benchmarks for SIXX and >> > compare >> > with Fuel. But that's not really fare because we are comparing a text >> > based >> > serializer against a binary one. >> > >> > It is interesting anyway. I like to know if it is 20 times faster or >> > even >> > more. On the other hand it is not fair either. I don't know fuel but I >> > think >> > it platform dependent, right? So it is not fair the other way round >> > because >> > you compare a cross-platform serializer with a platform-dependent one ;) >> > I >> > think these are the categories that people think about when the are >> > about to >> > choose what util to use. >> > Norbert >> > >> > Mariano >> > >> > On Thu, Jun 2, 2011 at 12:14 PM, Norbert Hartl <norbert(a)hartl.name> >> > wrote: >> >> >> >> Am 02.06.2011 um 11:42 schrieb Mariano Martinez Peck: >> >> >> >> >> serialize: anObject on: aStream >> >> Â Â Â | sws | >> >> Â Â Â sws := SixxWriteStream on: aStream. >> >> Â Â Â sws nextPut: anObject. >> >> Â Â Â sws close. >> >> >> >> serialize: anObject on: aStream >> >> Â Â anObject sixxOn: aStream >> >> >> >> >> materializeFrom: aStream >> >> Â Â Â | srs objects | >> >> Â Â Â srs := SixxReadStream on: aStream. >> >> Â Â Â objects := srs contents. >> >> Â Â Â srs close. >> >> Â Â Â ^ objects >> >> >> >> materializeFrom: aStream >> >> ^ Object readSixxFrom: aStream >> >> Norbert >> >> >> >> >> >> >> >> Is that correct or I am doing it wrong?Â All I want to do is to >> >> serialize >> >> a graph into a stream. >> >> >> >> The stream I am using is or this: >> >> >> >> (FileDirectory default forceNewFileNamed:Â 'Bench') >> >> >> >> or >> >> >> >> (RWBinaryOrTextStream on: '') >> >> >> >> >> >> I am not sure if I should be doing a #nextPut: or a #nextPutAll:. I >> >> mean, >> >> sometimes anObject is a collection and sometimes it is not. So, which >> >> one >> >> should I use? >> >> >> >> Thanks >> >> >> >> Mariano >> >> >> >> >> >> -- >> >> Mariano >> >> http://marianopeck.wordpress.com >> >> >> >> >> > >> > >> > >> > -- >> > Mariano >> > http://marianopeck.wordpress.com >> > >> > >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Best regards, Igor Stasenko AKA sig.

June 2, 2011

Re: [Pharo-project] I am serializing correctly with SIXX?

by Mariano Martinez Peck

On Thu, Jun 2, 2011 at 3:00 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Btw, what deserializer does, if it discovers that instance of some > class, which you want to bring to life from storage > now has its format changed? > suppose that when saving graph, some class has inst vars 'a b c' > but then you changed the class definition and its inst vars now 'a d e' > ? > In this, Fuel will materialize the object, set the instVar 'a' and 'd' and 'e' will be with nil. After, the user of FUel can do whatever he wants. In fact, we will provide soemthing like #initializeFromFuel or something like that that is automatically called by Fuel after the materialization. We throw error where there is something we cannot do. > > I think it is not a responsibility of serializer to deal with that > (there should be a higher level layer which can handle instance > migration), > while serializer just reports an error that it can't reify an object > because its original class are either gone or changed format. > yes, but there are things that we can do (kind of first pass) so that we can give the user the object already mterialized and he can update it. In fuel, we have these tests: testVariableInsertion "Tests that serializer tolarates when there is a new instance variable on materialization" | stream aPair resultPair | aPair := (self stubClassWithInstanceVars: 'left right') new. aPair instVarAt: 1 put: $A. aPair instVarAt: 2 put: $B. stream := self serializationOf: aPair. self stubClassWithInstanceVars: 'left middle right'. resultPair := self materializationOn: stream reset. self assert: $A equals: (resultPair instVarAt: 1). self assert: nil equals: (resultPair instVarAt: 2). self assert: $B equals: (resultPair instVarAt: 3). testVariableRemoved "Tests that serializer tolarates when an instance variable is missing on materialization" | stream aPair resultPair | aPair := (self stubClassWithInstanceVars: 'left right') new. aPair instVarAt: 1 put: $A. aPair instVarAt: 2 put: $B. stream := self serializationOf: aPair. self stubClassWithInstanceVars: 'right'. resultPair := self materializationOn: stream reset. self assert: $B equals: (resultPair instVarAt: 1). testVariableOrderChange "Tests that serializer tolarates when the order in the instance variables changed between serialization and materialization" | pairClass stream aPair resultPair | pairClass := self stubClassWithInstanceVars: 'left right'. aPair := pairClass new. aPair instVarAt: 1 put: $A. aPair instVarAt: 2 put: $B. stream := self serializationOf: aPair. pairClass := self stubClassWithInstanceVars: 'right left'. resultPair := self materializationOn: stream reset. self assert: $B equals: (resultPair instVarAt: 1). self assert: $A equals: (resultPair instVarAt: 2). > > On 2 June 2011 14:51, Norbert Hartl <norbert(a)hartl.name> wrote: > > > > Am 02.06.2011 um 14:31 schrieb Mariano Martinez Peck: > > > > Thanks Norbert. Now I could successfully run benchmarks for SIXX and > compare > > with Fuel. But that's not really fare because we are comparing a text > based > > serializer against a binary one. > > > > It is interesting anyway. I like to know if it is 20 times faster or even > > more. On the other hand it is not fair either. I don't know fuel but I > think > > it platform dependent, right? So it is not fair the other way round > because > > you compare a cross-platform serializer with a platform-dependent one ;) > I > > think these are the categories that people think about when the are about > to > > choose what util to use. > > Norbert > > > > Mariano > > > > On Thu, Jun 2, 2011 at 12:14 PM, Norbert Hartl <norbert(a)hartl.name> > wrote: > >> > >> Am 02.06.2011 um 11:42 schrieb Mariano Martinez Peck: > >> > >> >> serialize: anObject on: aStream > >> | sws | > >> sws := SixxWriteStream on: aStream. > >> sws nextPut: anObject. > >> sws close. > >> > >> serialize: anObject on: aStream > >> anObject sixxOn: aStream > >> > >> >> materializeFrom: aStream > >> | srs objects | > >> srs := SixxReadStream on: aStream. > >> objects := srs contents. > >> srs close. > >> ^ objects > >> > >> materializeFrom: aStream > >> ^ Object readSixxFrom: aStream > >> Norbert > >> > >> > >> > >> Is that correct or I am doing it wrong? All I want to do is to > serialize > >> a graph into a stream. > >> > >> The stream I am using is or this: > >> > >> (FileDirectory default forceNewFileNamed: 'Bench') > >> > >> or > >> > >> (RWBinaryOrTextStream on: '') > >> > >> > >> I am not sure if I should be doing a #nextPut: or a #nextPutAll:. I > mean, > >> sometimes anObject is a collection and sometimes it is not. So, which > one > >> should I use? > >> > >> Thanks > >> > >> Mariano > >> > >> > >> -- > >> Mariano > >> http://marianopeck.wordpress.com > >> > >> > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > > -- Mariano http://marianopeck.wordpress.com

June 2, 2011

Re: [Pharo-project] I am serializing correctly with SIXX?

by Igor Stasenko

Btw, what deserializer does, if it discovers that instance of some class, which you want to bring to life from storage now has its format changed? suppose that when saving graph, some class has inst vars 'a b c' but then you changed the class definition and its inst vars now 'a d e' ? I think it is not a responsibility of serializer to deal with that (there should be a higher level layer which can handle instance migration), while serializer just reports an error that it can't reify an object because its original class are either gone or changed format. On 2 June 2011 14:51, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 02.06.2011 um 14:31 schrieb Mariano Martinez Peck: > > Thanks Norbert. Now I could successfully run benchmarks for SIXX and compare > with Fuel. But that's not really fare because we are comparing a text based > serializer against a binary one. > > It is interesting anyway. I like to know if it is 20 times faster or even > more. On the other hand it is not fair either. I don't know fuel but I think > it platform dependent, right? So it is not fair the other way round because > you compare a cross-platform serializer with a platform-dependent one ;) I > think these are the categories that people think about when the are about to > choose what util to use. > Norbert > > Mariano > > On Thu, Jun 2, 2011 at 12:14 PM, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> Am 02.06.2011 um 11:42 schrieb Mariano Martinez Peck: >> >> >> serialize: anObject on: aStream >> Â Â Â | sws | >> Â Â Â sws := SixxWriteStream on: aStream. >> Â Â Â sws nextPut: anObject. >> Â Â Â sws close. >> >> serialize: anObject on: aStream >> Â Â anObject sixxOn: aStream >> >> >> materializeFrom: aStream >> Â Â Â | srs objects | >> Â Â Â srs := SixxReadStream on: aStream. >> Â Â Â objects := srs contents. >> Â Â Â srs close. >> Â Â Â ^ objects >> >> materializeFrom: aStream >> ^ Object readSixxFrom: aStream >> Norbert >> >> >> >> Is that correct or I am doing it wrong?Â All I want to do is to serialize >> a graph into a stream. >> >> The stream I am using is or this: >> >> (FileDirectory default forceNewFileNamed:Â 'Bench') >> >> or >> >> (RWBinaryOrTextStream on: '') >> >> >> I am not sure if I should be doing a #nextPut: or a #nextPutAll:. I mean, >> sometimes anObject is a collection and sometimes it is not. So, which one >> should I use? >> >> Thanks >> >> Mariano >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> > > > > -- > Mariano > http://marianopeck.wordpress.com > > > -- Best regards, Igor Stasenko AKA sig.

June 2, 2011

Re: [Pharo-project] I am serializing correctly with SIXX?

by Mariano Martinez Peck

On Thu, Jun 2, 2011 at 2:51 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 02.06.2011 um 14:31 schrieb Mariano Martinez Peck: > > Thanks Norbert. Now I could successfully run benchmarks for SIXX and > compare with Fuel. But that's not really fare because we are comparing a > text based serializer against a binary one. > > It is interesting anyway. I like to know if it is 20 times faster or even > more. > >From my benchmarks, when serializing to a file, I can see: SIXX Total milliseconds for serialization: 169696 SIXX Total milliseconds for materialization: 80622 SIXX Total milliseconds: 250318 For serialization, Fuel is 35.22 times faster than SIXX For materialization, Fuel is 120.51 times faster than SIXX Fuel Total milliseconds for serialization: 4818 Fuel Total milliseconds for materialization: 669 Fuel Total milliseconds: 5487 > On the other hand it is not fair either. I don't know fuel but I think it > platform dependent, right? > Yes. We are dependent in the way that we do special serialization for certain types of objects which may be different to another dialect. For example, FLFloatCluster >> serialize: aFloat on: aWriteStream aWriteStream nextNumber: 4 put: (aFloat at: 1); nextNumber: 4 put: (aFloat at: 2). FLLargePositiveIntegerCluster >> serialize: anInteger on: aWriteStream | size byte | size:=(anInteger log: 256) floor + 1. aWriteStream nextPut: size. (size - 1 to: 0 by: -1) do: [:index | byte := (anInteger bitShift: index * -8) bitAnd: 255. aWriteStream nextPut: byte] FLPositiveSmallIntegerCluster >> serialize: anInteger on: aWriteStream aWriteStream nextPut: (anInteger bitShift: -24). aWriteStream nextPut: ((anInteger bitShift: -16) bitAnd: 255). aWriteStream nextPut: ((anInteger bitShift: -8) bitAnd: 255). aWriteStream nextPut: (anInteger bitAnd: 255). etc..... So...if you want to port Fuel to say Gemstone you will have to adapt those special guys. So it is not fair the other way round because you compare a cross-platform > serializer with a platform-dependent one ;) I think these are the categories > that people think about when the are about to choose what util to use. > > I cannot agree more :) > Norbert > > Mariano > > On Thu, Jun 2, 2011 at 12:14 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > >> >> Am 02.06.2011 um 11:42 schrieb Mariano Martinez Peck: >> >> >> serialize: anObject on: aStream >> | sws | >> sws := SixxWriteStream on: aStream. >> sws nextPut: anObject. >> sws close. >> >> serialize: anObject on: aStream >> anObject sixxOn: aStream >> >> >> >> materializeFrom: aStream >> | srs objects | >> srs := SixxReadStream on: aStream. >> objects := srs contents. >> srs close. >> ^ objects >> >> >> materializeFrom: aStream >> ^ Object readSixxFrom: aStream >> >> Norbert >> >> >> >> Is that correct or I am doing it wrong? All I want to do is to serialize >> a graph into a stream. >> >> The stream I am using is or this: >> >> (FileDirectory default forceNewFileNamed: 'Bench') >> >> or >> >> (RWBinaryOrTextStream on: '') >> >> >> I am not sure if I should be doing a #nextPut: or a #nextPutAll:. I mean, >> sometimes anObject is a collection and sometimes it is not. So, which one >> should I use? >> >> Thanks >> >> Mariano >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > > -- Mariano http://marianopeck.wordpress.com

June 2, 2011

Re: [Pharo-project] I am serializing correctly with SIXX?

by Norbert Hartl

Am 02.06.2011 um 14:31 schrieb Mariano Martinez Peck: > Thanks Norbert. Now I could successfully run benchmarks for SIXX and compare with Fuel. But that's not really fare because we are comparing a text based serializer against a binary one. > It is interesting anyway. I like to know if it is 20 times faster or even more. On the other hand it is not fair either. I don't know fuel but I think it platform dependent, right? So it is not fair the other way round because you compare a cross-platform serializer with a platform-dependent one ;) I think these are the categories that people think about when the are about to choose what util to use. Norbert > Mariano > > On Thu, Jun 2, 2011 at 12:14 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 02.06.2011 um 11:42 schrieb Mariano Martinez Peck: > >> >> serialize: anObject on: aStream >> | sws | >> sws := SixxWriteStream on: aStream. >> sws nextPut: anObject. >> sws close. >> > serialize: anObject on: aStream > anObject sixxOn: aStream > >> >> >> materializeFrom: aStream >> | srs objects | >> srs := SixxReadStream on: aStream. >> objects := srs contents. >> srs close. >> ^ objects > > materializeFrom: aStream > ^ Object readSixxFrom: aStream > > Norbert > >> >> >> Is that correct or I am doing it wrong? All I want to do is to serialize a graph into a stream. >> >> The stream I am using is or this: >> >> (FileDirectory default forceNewFileNamed: 'Bench') >> >> or >> >> (RWBinaryOrTextStream on: '') >> >> >> I am not sure if I should be doing a #nextPut: or a #nextPutAll:. I mean, sometimes anObject is a collection and sometimes it is not. So, which one should I use? >> >> Thanks >> >> Mariano >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > > > > -- > Mariano > http://marianopeck.wordpress.com >

June 2, 2011

Re: [Pharo-project] I am serializing correctly with SIXX?

by Mariano Martinez Peck

Thanks Norbert. Now I could successfully run benchmarks for SIXX and compare with Fuel. But that's not really fare because we are comparing a text based serializer against a binary one. Mariano On Thu, Jun 2, 2011 at 12:14 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 02.06.2011 um 11:42 schrieb Mariano Martinez Peck: > > >> serialize: anObject on: aStream > | sws | > sws := SixxWriteStream on: aStream. > sws nextPut: anObject. > sws close. > > serialize: anObject on: aStream > anObject sixxOn: aStream > > > >> materializeFrom: aStream > | srs objects | > srs := SixxReadStream on: aStream. > objects := srs contents. > srs close. > ^ objects > > > materializeFrom: aStream > ^ Object readSixxFrom: aStream > > Norbert > > > > Is that correct or I am doing it wrong? All I want to do is to serialize a > graph into a stream. > > The stream I am using is or this: > > (FileDirectory default forceNewFileNamed: 'Bench') > > or > > (RWBinaryOrTextStream on: '') > > > I am not sure if I should be doing a #nextPut: or a #nextPutAll:. I mean, > sometimes anObject is a collection and sometimes it is not. So, which one > should I use? > > Thanks > > Mariano > > > -- > Mariano > http://marianopeck.wordpress.com > > > -- Mariano http://marianopeck.wordpress.com

June 2, 2011

Re: [Pharo-project] [squeak-dev] Re: usability of Pharo and Squeak

by StÃ©phane Ducasse

and what do you do to change the situation? Stef On Jun 2, 2011, at 12:23 PM, Andreas Wacknitz wrote: > After following the discussion for some time, I have the impression that there are some smalltalkers suffering similar usability problems like my friend and me and some more or less enjoy the actual state. > Dolphin 6 Professional introduced IdeaSpace. With that you can have both - single windows and tabbed windows. > It's up to the user to either open windows outside IdeaSpace as independent windows or inside IdeaSpace as tabbed windows. > Having the free choice is a good thing. Especially if you don't want to alienate newcomers that are used to use tabbed windows. I like this approach. > > I haven't looked at TWM yet due to lack of time. I am hardly able to read the mail traffic in the evenings. > But I asked my friend to have a look at it. He promised to do so although it's not suited to Pharo 1.2.1. > As Pharo 1.3 is not yet stable I fear that he might have new problems in other areas. > > What strikes me during this discussion is that nobody seem to have the same problem with window sizes and positions. > I don't like RealEstateAgent and I don't think that a revamped one will solve the problems. At least as long it doesn't provide the possibility > to set sizes on the fly. No algorithm can guess the requirements of all users. > I also haven't heard about applications written in Squeak or Pharo and what about user thereof think about the usability. IMO there is a lack of > an appropriate framework for dealing with such things. Or is everybody developing web applications nowadays? > > I have a hard time to promote Smalltalk because of its actual state. I always tell people about my favorite programming > language, but I also tell them that alas there is no good implementation of it available. This is sad but true, even if Pharo and Squeak made > big progress during the last months. Both, Squeak and Pharo, aren't products but just tools. And that makes a big difference. > The commercial products have characteristics that make them not very attractive to people not yet involved. Despite Dolphin they all have > dated user interfaces, too. When I try to convince people to have a look at Dolphin they typically tell me: very nice but it seems to be dead already. > > Regards, > Andreas

June 2, 2011