Excuse me for my poor english.
I´m developing a GUI Builder for Pharo -> http://www.youtube.com/watch?v=CHbc1t83fEI One of my problems is the way of persist a morph.Now i use the same way for create a Morph than message #saveOnFile but not saving in a external file else in array of bytes returned for a #spec message. I would know if morphic allow or exists another way of persistence more readable and fast. A complex morph serialized of that way is too slow in load. Regards. |
2009/7/21 nullPointer <[hidden email]>:
> > Excuse me for my poor english. > > I´m developing a GUI Builder for Pharo -> > http://www.youtube.com/watch?v=CHbc1t83fEI > > One of my problems is the way of persist a morph.Now i use the same way for > create a Morph than message #saveOnFile but not saving in a external file > else in array of bytes returned for a #spec message. > > I would know if morphic allow or exists another way of persistence more > readable and fast. A complex morph serialized of that way is too slow in > load. > original objects - just keep them somewhere in classvars. Then to create a new view of it, just do a #deepCopy. P.S. counter asString don't needs to be enclosed in parenthesis. > Regards. > -- > View this message in context: http://n2.nabble.com/Persist-a-morph-in-a-message.-tp3292117p3292117.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by gerard alis
On Mon, Jul 20, 2009 at 7:15 PM, nullPointer <[hidden email]> wrote:
Perhaps you can use another serializer. Here a some: http://www.seaside.st/documentation/persistence For example, http://www.seaside.st/documentation/persistence#230290016 or http://www.seaside.st/documentation/persistence#40827471 Your project seems very interesting, tough. Best, Mariano
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by gerard alis
Why don't you a kind of literalArray syntax like in VW.
Declarative syntax for saving description are the way to go. I would not serialize the composite. You could use mse for example: there are loader and saver for mse in the Fame package I guess. Stef > Excuse me for my poor english. > > I´m developing a GUI Builder for Pharo -> > http://www.youtube.com/watch?v=CHbc1t83fEI > > One of my problems is the way of persist a morph.Now i use the same > way for > create a Morph than message #saveOnFile but not saving in a > external file > else in array of bytes returned for a #spec message. > > I would know if morphic allow or exists another way of persistence > more > readable and fast. A complex morph serialized of that way is too > slow in > load. > > Regards. > -- > View this message in context: http://n2.nabble.com/Persist-a-morph-in-a-message.-tp3292117p3292117.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Mariano Martinez Peck
Yes something like that.
Use a system that we can hack and modify (have a look at the VW windowspec) this way your builder to build morphic but also something else too. windowSpec "UIPainter new openOnClass: self andSelector: #windowSpec" <resource: #canvas> ^#(#{UI.FullSpec} #window: #(#{UI.WindowSpec} #properties: #(#{UI.PropertyListDictionary} #sizeType #specifiedSize #positionType #screenCenter #openType #advanced ) #label: #(#{Kernel.UserMessage} #key: #aboutVisualWorks #defaultString: 'About Visual Works' #catalogID: #labels) #min: #(#{Core.Point} 20 20 ) #max: #(#{Core.Point} 1024 768 ) #bounds: #(#{Graphics.Rectangle} 512 384 992 704 ) ) #component: #(#{UI.SpecCollection} #collection: #( #(#{UI.TabControlSpec} #layout: #(#{Graphics.LayoutFrame} 10 0 10 0 -10 1 -40 1 ) #name: #tabs #model: #tabListHolder #labels: #() ) #(#{UI.ActionButtonSpec} #layout: #(#{Graphics.LayoutFrame} -90 1 -35 1 -10 1 -10 1 ) #name: #ok #model: #accept #label: #(#{Kernel.UserMessage} #key: #OK #defaultString: 'OK' #catalogID: #labels) #isDefault: true #defaultable: true ) ) ) ) Stef On Jul 21, 2009, at 2:58 AM, Mariano Martinez Peck wrote: > > > On Mon, Jul 20, 2009 at 7:15 PM, nullPointer <[hidden email]> > wrote: > > Excuse me for my poor english. > > I´m developing a GUI Builder for Pharo -> > http://www.youtube.com/watch?v=CHbc1t83fEI > > One of my problems is the way of persist a morph.Now i use the same > way for > create a Morph than message #saveOnFile but not saving in a > external file > else in array of bytes returned for a #spec message. > > I would know if morphic allow or exists another way of persistence > more > readable and fast. A complex morph serialized of that way is too > slow in > load. > > Perhaps you can use another serializer. Here a some: http://www.seaside.st/documentation/persistence > > For example, http://www.seaside.st/documentation/persistence#230290016 > or http://www.seaside.st/documentation/persistence#40827471 > > Your project seems very interesting, tough. > > Best, > > Mariano > > > > > Regards. > -- > View this message in context: http://n2.nabble.com/Persist-a-morph-in-a-message.-tp3292117p3292117.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
This is way better than having a methods carrying a multi-kilobyte
long bytearray, but still not perfect. Why just don't 'serialize' the morph as a code which builds it? buildMyMorph | myMorph | myMorph := MyMorph new. myMorph layout: blablahblah.. myMorph label: blabla... ... ^ myMorph 2009/7/21 Stéphane Ducasse <[hidden email]>: > Yes something like that. > Use a system that we can hack and modify (have a look at the VW > windowspec) > > this way your builder to build morphic but also something else too. > > windowSpec > "UIPainter new openOnClass: self andSelector: #windowSpec" > > <resource: #canvas> > ^#(#{UI.FullSpec} > #window: > #(#{UI.WindowSpec} > #properties: #(#{UI.PropertyListDictionary} #sizeType > #specifiedSize #positionType #screenCenter #openType #advanced ) > #label: #(#{Kernel.UserMessage} #key: #aboutVisualWorks > #defaultString: 'About Visual Works' #catalogID: #labels) > #min: #(#{Core.Point} 20 20 ) > #max: #(#{Core.Point} 1024 768 ) > #bounds: #(#{Graphics.Rectangle} 512 384 992 704 ) ) > #component: > #(#{UI.SpecCollection} > #collection: #( > #(#{UI.TabControlSpec} > #layout: #(#{Graphics.LayoutFrame} 10 0 10 0 -10 1 -40 1 ) > #name: #tabs > #model: #tabListHolder > #labels: #() ) > #(#{UI.ActionButtonSpec} > #layout: #(#{Graphics.LayoutFrame} -90 1 -35 1 -10 1 -10 1 ) > #name: #ok > #model: #accept > #label: #(#{Kernel.UserMessage} #key: #OK #defaultString: 'OK' > #catalogID: #labels) > #isDefault: true > #defaultable: true ) ) ) ) > > Stef > > > On Jul 21, 2009, at 2:58 AM, Mariano Martinez Peck wrote: > >> >> >> On Mon, Jul 20, 2009 at 7:15 PM, nullPointer <[hidden email]> >> wrote: >> >> Excuse me for my poor english. >> >> I´m developing a GUI Builder for Pharo -> >> http://www.youtube.com/watch?v=CHbc1t83fEI >> >> One of my problems is the way of persist a morph.Now i use the same >> way for >> create a Morph than message #saveOnFile but not saving in a >> external file >> else in array of bytes returned for a #spec message. >> >> I would know if morphic allow or exists another way of persistence >> more >> readable and fast. A complex morph serialized of that way is too >> slow in >> load. >> >> Perhaps you can use another serializer. Here a some: http://www.seaside.st/documentation/persistence >> >> For example, http://www.seaside.st/documentation/persistence#230290016 >> or http://www.seaside.st/documentation/persistence#40827471 >> >> Your project seems very interesting, tough. >> >> Best, >> >> Mariano >> >> >> >> >> Regards. >> -- >> View this message in context: http://n2.nabble.com/Persist-a-morph-in-a-message.-tp3292117p3292117.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Yeah, then zip the text file... much more compact!
Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <[hidden email]> To: <[hidden email]> Sent: Tuesday, July 21, 2009 5:28 PM Subject: Re: [Pharo-project] Persist a morph in a message. > This is way better than having a methods carrying a multi-kilobyte > long bytearray, > but still not perfect. > > Why just don't 'serialize' the morph as a code which builds it? > > buildMyMorph > > | myMorph | > myMorph := MyMorph new. > myMorph layout: blablahblah.. > myMorph label: blabla... > ... > ^ myMorph > > 2009/7/21 Stéphane Ducasse <[hidden email]>: >> Yes something like that. >> Use a system that we can hack and modify (have a look at the VW >> windowspec) >> >> this way your builder to build morphic but also something else too. >> >> windowSpec >> "UIPainter new openOnClass: self andSelector: #windowSpec" >> >> <resource: #canvas> >> ^#(#{UI.FullSpec} >> #window: >> #(#{UI.WindowSpec} >> #properties: #(#{UI.PropertyListDictionary} #sizeType >> #specifiedSize #positionType #screenCenter #openType #advanced ) >> #label: #(#{Kernel.UserMessage} #key: #aboutVisualWorks >> #defaultString: 'About Visual Works' #catalogID: #labels) >> #min: #(#{Core.Point} 20 20 ) >> #max: #(#{Core.Point} 1024 768 ) >> #bounds: #(#{Graphics.Rectangle} 512 384 992 704 ) ) >> #component: >> #(#{UI.SpecCollection} >> #collection: #( >> #(#{UI.TabControlSpec} >> #layout: #(#{Graphics.LayoutFrame} 10 0 10 0 -10 1 -40 1 ) >> #name: #tabs >> #model: #tabListHolder >> #labels: #() ) >> #(#{UI.ActionButtonSpec} >> #layout: #(#{Graphics.LayoutFrame} -90 1 -35 1 -10 1 -10 1 ) >> #name: #ok >> #model: #accept >> #label: #(#{Kernel.UserMessage} #key: #OK #defaultString: 'OK' >> #catalogID: #labels) >> #isDefault: true >> #defaultable: true ) ) ) ) >> >> Stef >> >> >> On Jul 21, 2009, at 2:58 AM, Mariano Martinez Peck wrote: >> >>> >>> >>> On Mon, Jul 20, 2009 at 7:15 PM, nullPointer <[hidden email]> >>> wrote: >>> >>> Excuse me for my poor english. >>> >>> I´m developing a GUI Builder for Pharo -> >>> http://www.youtube.com/watch?v=CHbc1t83fEI >>> >>> One of my problems is the way of persist a morph.Now i use the same >>> way for >>> create a Morph than message #saveOnFile but not saving in a >>> external file >>> else in array of bytes returned for a #spec message. >>> >>> I would know if morphic allow or exists another way of persistence >>> more >>> readable and fast. A complex morph serialized of that way is too >>> slow in >>> load. >>> >>> Perhaps you can use another serializer. Here a some: >>> http://www.seaside.st/documentation/persistence >>> >>> For example, http://www.seaside.st/documentation/persistence#230290016 >>> or http://www.seaside.st/documentation/persistence#40827471 >>> >>> Your project seems very interesting, tough. >>> >>> Best, >>> >>> Mariano >>> >>> >>> >>> >>> Regards. >>> -- >>> View this message in context: >>> http://n2.nabble.com/Persist-a-morph-in-a-message.-tp3292117p3292117.html >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Igor Stasenko
The manipulation and construction that Torsten is currently pursuing
is useful and independent of the "ultimate" format. It should not be hard to change the storage/representation format: a visitor walks the tree and invokes the right i/o broker. The brokers could become more sophisticated as generality is needed. In fact, this can be added at any time ... so for his needs right now what is easiest? Ultimately, I would strongly encourage making it more abstract (not referencing concrete morphs) -- to address what Stef mentioned. Of course, that begs the question of how to map unique morphs that have no analogs in other windowing systems. Translation problem example: I have a ClsQuoteTickerMorph (or something like that) that inherits straight off of StringMorph, and it knows how to update itself every two minutes, and it requires net access to work. -Cam On Jul 21, 2009, at 12:28 PM, Igor Stasenko wrote: > This is way better than having a methods carrying a multi-kilobyte > long bytearray, > but still not perfect. > > Why just don't 'serialize' the morph as a code which builds it? > > buildMyMorph > > | myMorph | > myMorph := MyMorph new. > myMorph layout: blablahblah.. > myMorph label: blabla... > ... > ^ myMorph > > 2009/7/21 Stéphane Ducasse <[hidden email]>: >> Yes something like that. >> Use a system that we can hack and modify (have a look at the VW >> windowspec) >> >> this way your builder to build morphic but also something else too. >> >> windowSpec >> "UIPainter new openOnClass: self andSelector: #windowSpec" >> >> <resource: #canvas> >> ^#(#{UI.FullSpec} >> #window: >> #(#{UI.WindowSpec} >> #properties: #(#{UI.PropertyListDictionary} >> #sizeType >> #specifiedSize #positionType #screenCenter #openType #advanced ) >> #label: #(#{Kernel.UserMessage} #key: >> #aboutVisualWorks >> #defaultString: 'About Visual Works' #catalogID: #labels) >> #min: #(#{Core.Point} 20 20 ) >> #max: #(#{Core.Point} 1024 768 ) >> #bounds: #(#{Graphics.Rectangle} 512 384 992 >> 704 ) ) >> #component: >> #(#{UI.SpecCollection} >> #collection: #( >> #(#{UI.TabControlSpec} >> #layout: >> #(#{Graphics.LayoutFrame} 10 0 10 0 -10 1 -40 1 ) >> #name: #tabs >> #model: #tabListHolder >> #labels: #() ) >> #(#{UI.ActionButtonSpec} >> #layout: >> #(#{Graphics.LayoutFrame} -90 1 -35 1 -10 1 -10 1 ) >> #name: #ok >> #model: #accept >> #label: >> #(#{Kernel.UserMessage} #key: #OK #defaultString: 'OK' >> #catalogID: #labels) >> #isDefault: true >> #defaultable: true ) ) ) ) >> >> Stef >> >> >> On Jul 21, 2009, at 2:58 AM, Mariano Martinez Peck wrote: >> >>> >>> >>> On Mon, Jul 20, 2009 at 7:15 PM, nullPointer <[hidden email]> >>> wrote: >>> >>> Excuse me for my poor english. >>> >>> I´m developing a GUI Builder for Pharo -> >>> http://www.youtube.com/watch?v=CHbc1t83fEI >>> >>> One of my problems is the way of persist a morph.Now i use the same >>> way for >>> create a Morph than message #saveOnFile but not saving in a >>> external file >>> else in array of bytes returned for a #spec message. >>> >>> I would know if morphic allow or exists another way of persistence >>> more >>> readable and fast. A complex morph serialized of that way is too >>> slow in >>> load. >>> >>> Perhaps you can use another serializer. Here a some: http://www.seaside.st/documentation/persistence >>> >>> For example, http://www.seaside.st/documentation/persistence#230290016 >>> or http://www.seaside.st/documentation/persistence#40827471 >>> >>> Your project seems very interesting, tough. >>> >>> Best, >>> >>> Mariano >>> >>> >>> >>> >>> Regards. >>> -- >>> View this message in context: http://n2.nabble.com/Persist-a-morph-in-a-message.-tp3292117p3292117.html >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Torsten,
Are you wanting to resolve your storage format right now, or just improve the I/O? And, when the generalization/abstraction comes about, it seem that fonts should draw on local default setting and be adjusted "larger" and "smaller" somehow. I have two computers on my desktop right here that have wildly different screen resolutions. -cam On Jul 21, 2009, at 12:59 PM, Cameron Sanders wrote: > The manipulation and construction that Torsten is currently pursuing > is useful and independent of the "ultimate" format. > > It should not be hard to change the storage/representation format: a > visitor walks the tree and invokes the right i/o broker. The brokers > could become more sophisticated as generality is needed. In fact, this > can be added at any time ... so for his needs right now what is > easiest? > > Ultimately, I would strongly encourage making it more abstract (not > referencing concrete morphs) -- to address what Stef mentioned. Of > course, that begs the question of how to map unique morphs that have > no analogs in other windowing systems. Translation problem example: I > have a ClsQuoteTickerMorph (or something like that) that inherits > straight off of StringMorph, and it knows how to update itself every > two minutes, and it requires net access to work. > > -Cam > > On Jul 21, 2009, at 12:28 PM, Igor Stasenko wrote: > >> This is way better than having a methods carrying a multi-kilobyte >> long bytearray, >> but still not perfect. >> >> Why just don't 'serialize' the morph as a code which builds it? >> >> buildMyMorph >> >> | myMorph | >> myMorph := MyMorph new. >> myMorph layout: blablahblah.. >> myMorph label: blabla... >> ... >> ^ myMorph >> >> 2009/7/21 Stéphane Ducasse <[hidden email]>: >>> Yes something like that. >>> Use a system that we can hack and modify (have a look at the VW >>> windowspec) >>> >>> this way your builder to build morphic but also something else too. >>> >>> windowSpec >>> "UIPainter new openOnClass: self andSelector: #windowSpec" >>> >>> <resource: #canvas> >>> ^#(#{UI.FullSpec} >>> #window: >>> #(#{UI.WindowSpec} >>> #properties: #(#{UI.PropertyListDictionary} >>> #sizeType >>> #specifiedSize #positionType #screenCenter #openType #advanced ) >>> #label: #(#{Kernel.UserMessage} #key: >>> #aboutVisualWorks >>> #defaultString: 'About Visual Works' #catalogID: #labels) >>> #min: #(#{Core.Point} 20 20 ) >>> #max: #(#{Core.Point} 1024 768 ) >>> #bounds: #(#{Graphics.Rectangle} 512 384 992 >>> 704 ) ) >>> #component: >>> #(#{UI.SpecCollection} >>> #collection: #( >>> #(#{UI.TabControlSpec} >>> #layout: >>> #(#{Graphics.LayoutFrame} 10 0 10 0 -10 1 -40 1 ) >>> #name: #tabs >>> #model: #tabListHolder >>> #labels: #() ) >>> #(#{UI.ActionButtonSpec} >>> #layout: >>> #(#{Graphics.LayoutFrame} -90 1 -35 1 -10 1 -10 1 ) >>> #name: #ok >>> #model: #accept >>> #label: >>> #(#{Kernel.UserMessage} #key: #OK #defaultString: 'OK' >>> #catalogID: #labels) >>> #isDefault: true >>> #defaultable: true ) ) ) ) >>> >>> Stef >>> >>> >>> On Jul 21, 2009, at 2:58 AM, Mariano Martinez Peck wrote: >>> >>>> >>>> >>>> On Mon, Jul 20, 2009 at 7:15 PM, nullPointer <[hidden email]> >>>> wrote: >>>> >>>> Excuse me for my poor english. >>>> >>>> I´m developing a GUI Builder for Pharo -> >>>> http://www.youtube.com/watch?v=CHbc1t83fEI >>>> >>>> One of my problems is the way of persist a morph.Now i use the same >>>> way for >>>> create a Morph than message #saveOnFile but not saving in a >>>> external file >>>> else in array of bytes returned for a #spec message. >>>> >>>> I would know if morphic allow or exists another way of persistence >>>> more >>>> readable and fast. A complex morph serialized of that way is too >>>> slow in >>>> load. >>>> >>>> Perhaps you can use another serializer. Here a some: http://www.seaside.st/documentation/persistence >>>> >>>> For example, http://www.seaside.st/documentation/persistence#230290016 >>>> or http://www.seaside.st/documentation/persistence#40827471 >>>> >>>> Your project seems very interesting, tough. >>>> >>>> Best, >>>> >>>> Mariano >>>> >>>> >>>> >>>> >>>> Regards. >>>> -- >>>> View this message in context: http://n2.nabble.com/Persist-a-morph-in-a-message.-tp3292117p3292117.html >>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by gerard alis
My apologies, I got confused about the source of this thread in my
last email. nullPoint, nice start! (So that question in my last email was directed at you.) -Cam On Jul 20, 2009, at 6:15 PM, nullPointer wrote: > > Excuse me for my poor english. > > I´m developing a GUI Builder for Pharo -> > http://www.youtube.com/watch?v=CHbc1t83fEI > > One of my problems is the way of persist a morph.Now i use the same > way for > create a Morph than message #saveOnFile but not saving in a > external file > else in array of bytes returned for a #spec message. > > I would know if morphic allow or exists another way of persistence > more > readable and fast. A complex morph serialized of that way is too > slow in > load. > > Regards. > -- > View this message in context: http://n2.nabble.com/Persist-a-morph-in-a-message.-tp3292117p3292117.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Igor Stasenko
>Just a guess: maybe it is better to persist a morph(s) as is - as
>original objects - just keep them somewhere in classvars. >Then to create a new view of it, just do a #deepCopy. Perhaps could be a combined solution. Persist the morph in a method, but only load one time, if class var is nothing. Then in the next times send #deepCopy to prototype morph . That could be a solution for the velocity :) I believe than EasyMorphicGUI works of that way too. Regards. |
In reply to this post by Mariano Martinez Peck
>Perhaps you can use another serializer. Here a some: >http://www.seaside.st/documentation/persistence I did try sixx, but was failed for big morphs.The xml text resultant was too great. >Your project seems very interesting, tough. Thanks, I am putting much effort to it :)) |
In reply to this post by gerard alis
2009/7/21 nullPointer <[hidden email]>:
> >>Just a guess: maybe it is better to persist a morph(s) as is - as >>original objects - just keep them somewhere in classvars. >>Then to create a new view of it, just do a #deepCopy. > > Perhaps could be a combined solution. Persist the morph in a method, but > only load one time, if class var is nothing. Then in the next times send > #deepCopy to prototype morph . That could be a solution for the velocity :) > I believe than EasyMorphicGUI works of that way too. > > Regards. Any reasons to stay anonymous? Hey, we don't/can't harm you in any way :) Instead, i think that it would be not only me, who could say, that we would really like to help you with that. > > > > -- > View this message in context: http://n2.nabble.com/Persist-a-morph-in-a-message.-tp3292117p3295437.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Perhaps Stef is "moonlighting" under an alias... ? (He replied to
himself for cover.) -cam On Jul 21, 2009, at 5:16 PM, Igor Stasenko wrote: > 2009/7/21 nullPointer <[hidden email]>: >> >>> Just a guess: maybe it is better to persist a morph(s) as is - as >>> original objects - just keep them somewhere in classvars. >>> Then to create a new view of it, just do a #deepCopy. >> >> Perhaps could be a combined solution. Persist the morph in a >> method, but >> only load one time, if class var is nothing. Then in the next times >> send >> #deepCopy to prototype morph . That could be a solution for the >> velocity :) >> I believe than EasyMorphicGUI works of that way too. >> >> Regards. > > Any reasons to stay anonymous? Hey, we don't/can't harm you in any > way :) > Instead, i think that it would be not only me, who could say, that we > would really like to help you with that. > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
2009/7/22 Cameron Sanders <[hidden email]>:
> Perhaps Stef is "moonlighting" under an alias... ? (He replied to > himself for cover.) > Then you are 'moonlighting' under a 'Sherlock Holmes' alias :) > -cam > > On Jul 21, 2009, at 5:16 PM, Igor Stasenko wrote: > >> 2009/7/21 nullPointer <[hidden email]>: >>> >>>> Just a guess: maybe it is better to persist a morph(s) as is - as >>>> original objects - just keep them somewhere in classvars. >>>> Then to create a new view of it, just do a #deepCopy. >>> >>> Perhaps could be a combined solution. Persist the morph in a >>> method, but >>> only load one time, if class var is nothing. Then in the next times >>> send >>> #deepCopy to prototype morph . That could be a solution for the >>> velocity :) >>> I believe than EasyMorphicGUI works of that way too. >>> >>> Regards. >> >> Any reasons to stay anonymous? Hey, we don't/can't harm you in any >> way :) >> Instead, i think that it would be not only me, who could say, that we >> would really like to help you with that. >> > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
You are better than I suspected, Watson!
On Jul 21, 2009, at 8:16 PM, Igor Stasenko wrote: > 2009/7/22 Cameron Sanders <[hidden email]>: >> Perhaps Stef is "moonlighting" under an alias... ? (He replied to >> himself for cover.) >> > Then you are 'moonlighting' under a 'Sherlock Holmes' alias :) > >> -cam >> >> On Jul 21, 2009, at 5:16 PM, Igor Stasenko wrote: >> >>> 2009/7/21 nullPointer <[hidden email]>: >>>> >>>>> Just a guess: maybe it is better to persist a morph(s) as is - as >>>>> original objects - just keep them somewhere in classvars. >>>>> Then to create a new view of it, just do a #deepCopy. >>>> >>>> Perhaps could be a combined solution. Persist the morph in a >>>> method, but >>>> only load one time, if class var is nothing. Then in the next times >>>> send >>>> #deepCopy to prototype morph . That could be a solution for the >>>> velocity :) >>>> I believe than EasyMorphicGUI works of that way too. >>>> >>>> Regards. >>> >>> Any reasons to stay anonymous? Hey, we don't/can't harm you in any >>> way :) >>> Instead, i think that it would be not only me, who could say, that >>> we >>> would really like to help you with that. >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Cameron Sanders-3
I would loved to have the time to do that but no :)
Stef On Jul 22, 2009, at 1:53 AM, Cameron Sanders wrote: > Perhaps Stef is "moonlighting" under an alias... ? (He replied to > himself for cover.) > > -cam > > On Jul 21, 2009, at 5:16 PM, Igor Stasenko wrote: > >> 2009/7/21 nullPointer <[hidden email]>: >>> >>>> Just a guess: maybe it is better to persist a morph(s) as is - as >>>> original objects - just keep them somewhere in classvars. >>>> Then to create a new view of it, just do a #deepCopy. >>> >>> Perhaps could be a combined solution. Persist the morph in a >>> method, but >>> only load one time, if class var is nothing. Then in the next times >>> send >>> #deepCopy to prototype morph . That could be a solution for the >>> velocity :) >>> I believe than EasyMorphicGUI works of that way too. >>> >>> Regards. >> >> Any reasons to stay anonymous? Hey, we don't/can't harm you in any >> way :) >> Instead, i think that it would be not only me, who could say, that we >> would really like to help you with that. >> > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Igor Stasenko
>Any reasons to stay anonymous? Hey, we don't/can't harm you in any way :) >Instead, i think that it would be not only me, who could say, that we >would really like to help you with that. Well, my name is Gerard Navarro. Really is needed have real name and not an alias? :) |
Now not :)
This is a nice pseudo. I like also destinationVoid (frank herbert) Stef > > >> Any reasons to stay anonymous? Hey, we don't/can't harm you in any >> way :) >> Instead, i think that it would be not only me, who could say, that we >> would really like to help you with that. > > Well, my name is Gerard Navarro. Really is needed have real name and > not an > alias? :) > > -- > View this message in context: http://n2.nabble.com/Persist-a-morph-in-a-message.-tp3292117p3305535.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
2009/7/22 Stéphane Ducasse <[hidden email]>:
> Now not :) > This is a nice pseudo. I like also destinationVoid (frank herbert) > Yeah, if you remember, i was using own alias before (Sig) but then someone asked me to uncover my true identity :) > Stef > >> >> >>> Any reasons to stay anonymous? Hey, we don't/can't harm you in any >>> way :) >>> Instead, i think that it would be not only me, who could say, that we >>> would really like to help you with that. >> >> Well, my name is Gerard Navarro. Really is needed have real name and >> not an >> alias? :) >> >> -- >> View this message in context: http://n2.nabble.com/Persist-a-morph-in-a-message.-tp3292117p3305535.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Free forum by Nabble | Edit this page |