July 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] VersionHistory and VersionNumber

by Marcus Denker

On 21.07.2009, at 13:36, Adrian Lienhard wrote: > Does anybody use these two classes? Are they worth being kept in the > core (there are no users in the core)? > > Class comment: A version history is a collection of VersionNumbers > that together form a tree of versions. I enforce rules about how > versions are added and removed from the history. > I think they are used only in SqueakMap. Marcus -- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile

July 21, 2009

Re: [Pharo-project] VersionHistory and VersionNumber

by Mariano Martinez Peck

On Tue, Jul 21, 2009 at 4:36 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Does anybody use these two classes? Are they worth being kept in the > core (there are no users in the core)? > I remember Goran said in IRC that those classes were not necessary if we removed SM. At that moment I browsed senders and references to the class and I didn't found nothing. So, I think they should removed. I cc goran just in case. Mariano > > Class comment: A version history is a collection of VersionNumbers > that together form a tree of versions. I enforce rules about how > versions are added and removed from the history. > > Adrian > ___________________ > http://www.adrian-lienhard.ch/ > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 21, 2009

[Pharo-project] VersionHistory and VersionNumber

by Adrian Lienhard

Does anybody use these two classes? Are they worth being kept in the core (there are no users in the core)? Class comment: A version history is a collection of VersionNumbers that together form a tree of versions. I enforce rules about how versions are added and removed from the history. Adrian ___________________ http://www.adrian-lienhard.ch/

July 21, 2009

Re: [Pharo-project] Persist a morph in a message.

by Cameron Sanders

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 > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 21, 2009

[Pharo-project] HostSystemMenuTest MNU

by Adrian Lienhard

Hi Marcus, In the test below, which has your initials, the following methods are not understood. calculateShouldBeFrom:using: and modifySqueakMenu: Maybe you know where to get these methods from, how to implement them, or if we should rather delete the test? Cheers, Adrian HostSystemMenuTest>>testCharacterChanging | testString item shouldBe resultingString where | #(';' '^' '!' '<' '/' '(' ) do: [:c | #('*' '* ' '* ' '**' '** ' '** ' ')' '*)' '* )' '* )' '**)' '** )' '** )' ')' '*)' '*X)' '*XX)' '**)' '**X)' '**XX)' '))' '*))' '*X))' '*XX))' '**))' '**X))' '**XX))' '(' '*(' '*X(' '*XX(' '**)' '**X(' '**XX(' '((' '*((' '*X((' '*XX((' '**((' '**X((' '**XX((' ) do: [:template | testString := template copyReplaceAll: '*' with: c. testString permutationsDo: [:mixedUp | item := mixedUp copy. shouldBe := self calculateShouldBeFrom: item using: c. resultingString := self modifySqueakMenu: item copy. self should: [shouldBe = resultingString]. (where := resultingString indexOf: $/) > 0 ifTrue: [self should: [(mixedUp at: where) = $(]. self should: [(mixedUp at: where+2) = $)]. self should: [(mixedUp at: where+1) asUppercase = (resultingString at: where+1)]]]]]

July 21, 2009

Re: [Pharo-project] Persist a morph in a message.

by Cameron Sanders

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 <stephane.ducasse(a)inria.fr>: >>> 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 <epicfan(a)gmail.com> >>>> 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 >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 21, 2009

Re: [Pharo-project] Persist a morph in a message.

by Cameron Sanders

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 <stephane.ducasse(a)inria.fr>: >> 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 <epicfan(a)gmail.com> >>> 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 >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 21, 2009

Re: [Pharo-project] Show stopper network bug on Windows

by Adrian Lienhard

In this case the first step woud be to identify which update introduced the problem. Suppose that a core #10200 image still works, you could do: 10200 to: 10384 do: [ :i | Utilities updateFromServerThroughUpdateNumber: i. NetNameResolver localHostAddress ] And then see after which update number the first exception is thrown. I did not test this, but it should work. Adrian On Jul 21, 2009, at 18:47 , Schwab,Wilhelm K wrote: > Again, I *think* the problem is too much code removed, and failure > to protect with #useOldNetwork. It blows up on IPv4; it happens > both on Windows and Linux. If anyone has counter examples or can > otherwise show me wrong, please set me straight. > > Bill > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr > ] On Behalf Of Damien Cassou > Sent: Tuesday, July 21, 2009 11:29 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Show stopper network bug on Windows > > On Tue, Jul 21, 2009 at 12:56 PM, Adrian Lienhard<adi(a)netstyle.ch> > wrote: >> If this bug also exists in Squeak (which I expect since it seems a VM >> problem), I suggest to report it there too (and create a Mantis >> entry). > > No, it's only Pharo. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 21, 2009

[Pharo-project] jpg woes

by Brian Mason

I am trying to take an image off the new and save it to a file. This is what I have so far: (FileStream newFileNamed: 'test.jpg') nextPutAll: ('http://freetalklive.com/images/amondson.jpg' asUrl retrieveContents) getContentFromStream; close The image exists, is found, and the file is written. There is something wrong with the format of the local jpg. I would appreciate some guidance. "You can have everything you want if you just help enough other people get what they want." - Zig Zigglar

July 21, 2009

Re: [Pharo-project] Why Pharo?

by Adrian Lienhard

On Jul 21, 2009, at 18:22 , Mariano Martinez Peck wrote: > On Tue, Jul 21, 2009 at 2:59 PM, Esteban A. Maringolo > <emaringolo(a)gmail.com>wrote: > >> Hello, >> >> Mariano's post spurred me to write my reasons of "why to use it", >> so I >> started this post. >> > > yes, I asked because I saw that perhaps a "Why pharo?" section in > www.pharo-project.org could be a good idea :) Indeed. If you or somebody else writes up some text, I'm happy to add it to the website. Adrian

July 21, 2009