- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Who are you?

by StÃ©phane Ducasse

On Jul 21, 2009, at 5:17 PM, Esteban A. Maringolo wrote: > I'm a smalltalker doing the transition from Dolphin to Pharo (not an > easy one). > > At work I use VSE and Dolphin since several years, and now I'm > starting a personal project, which eventually will become commercial. > > After many hesitations (I was reluctant to use Squeak) I decided to > use Pharo for it and not Dolphin (my favorite Smalltalk), because of > several reasons. I hope that you will not be disappointed because we do not have full time engineers. It seems to me that Dolphin is really good (it was never working on mac to my own dispair). > I hope to contribute in the future, by know I'm just getting aquainted > back with some tools, some I already knew from when I used Squeak 3.1, > and "the new" like Monticello, PackageInfo, OmniBrowser, and the > frameworks like Magritte and Seaside. > > Regards, > > Esteban A. Maringolo > > > > 2009/7/21 Alexandre Bergel <alexandre(a)bergel.eu>: >> Ok, so there is approximately 11 commercial entities (which includes >> company, consultant, self-employed) using Pharo. >> This is an excellent news! >> >> Cheers, >> Alexandre >> >> >> On 21 Jul 2009, at 10:59, Alexandre Bergel wrote: >> >>>>> How many companies are using Pharo? Without thinking too much, I >>>>> know >>>>> there are Netstyle.ch and Pinesoft. Are there more? >>>> >>>> Yeah, several companies I am consulting are using it. >>> >>> I have no doubt Pharo is reliable enough to be used in production. I >>> am essentially interested in a number here :-) >>> >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> 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] [ANN] update 10387

by Adrian Lienhard

- integrate hash functions from Cryptography (MIT licensed) - fix Host* tests - remove VersionHistory and VersionNumber ___________________ http://www.adrian-lienhard.ch/

July 21, 2009

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