August 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] SerialPort - named ports on Linux

by Serge Stinckwich

To be tested : http://code.google.com/p/pharo/issues/detail?id=1057 On Tue, Aug 31, 2010 at 3:24 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Hello all, > > I recalled seeing mention of the Linux vm's now supporting named ports, and I found the code for that, at least in the vm. Â My understanding gets fuzzy as we enter the plugin and primitives. Â At a minimum, there are a few ByName methods to be added, and Squeak 4.1 contains open and close methods that test on type (int vs. string) to open or close by name or not as appropriate. > > Is this as simple as gathering the changes and adding them to Pharo, or does it require VMMaker magic? > > Bill > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

Aug. 31, 2010

Re: [Pharo-project] return character magic?

by Eliot Miranda

2010/8/30 Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> > On 31.08.2010 01:32, Eliot Miranda wrote: > > Hi Henrik, > > twice you write a slip that the compiler should not allow: > > (map := characterToGlyphMap) > ifNotNil: [:map | code := map at: code + 1]. > > code := (map := characterToGlyphMap) > ifNil: [aCharacter charCode] > ifNotNil: [:map | map at: aCharacter charCode + 1] > > these should read > > characterToGlyphMap ifNotNil: [:map | code := map at: code + 1]. > > code := characterToGlyphMap > ifNil: [aCharacter charCode] > ifNotNil: [:map | map at: aCharacter charCode + 1] > > HTH, > Eliot > > Hum, unless I posted a previous version, the code in the changeset was: > > characterToGlyphMap ifNotNil: [:map | code := map at: code +1]. > and > code := characterToGlyphMap > ifNotNil: [:map | map at: aCharacter charCode +1] > ifNil: [aCharacter charCode]. > > Seem to me they got decompiled somehow? > Oops, quite right! I think I did pretty diffs and this is what I got. Bad pretty diffs, bad :) > > > > also in BitBlt>>#primDisplayString:from:to:map:xTable:kern: you write > > ascii := glyphMap at: (aString at: charIndex) asciiValue + 1. > > whereas the current Squeak code reads > > ascii := (aString at: charIndex) asciiValue. > glyphMap ifNotNil:[ascii := glyphMap at: ascii+1]. > > Should Squeak keep its original code (which seems equivalent) or is there > a specific reason to eliminate the ifNotNil: test? > > TIA > Eliot > > Yes, it should keep it. > Getting late, I made that change in that method first to have Pharo display > correctly, and didn't yet think of that glyphMap may be nil :) > For Squeak, the two methods in StrikeFont should be sufficient. > Cool, thanks! Eliot > > Cheers, > Henry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 30, 2010

Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final

by Henrik Sperre Johansen

On 31.08.2010 01:21, Levente Uzonyi wrote: > On Tue, 31 Aug 2010, Henrik Sperre Johansen wrote: > > snip > >> Yeah, that's why I added the 200000 4KB docs / sec number. >> I really doubt the conversion will be a significant part of the >> processing time if what you send out is so small you are able to >> convert 800k messages per second... > > It depends on the machine/load/etc. I feel like we already had this discussion over the cull: implementation, and I doubt either of us is going to change their mind, so let's stop here :) > >> >> See the code I attached last mail, switching to convertToEncoding: >> 'utf8' sort of implied implementing something like that, which gives >> it nearly the same speed as convertToWithConverter: UTF8TextConverter >> new in your examples. > > Sorry, I didn't see that. It looks cool, but I still wouldn't use > #convertToEncoding: in my code, because there's a similar looking > method (#converToWithConverter:) with better performance :). Sure, though I find it quite ugly, I wouldn't vehemently oppose using it either, but the issue here was finding something Andreas would accept :) > But it's definitely better than the current version, though if a > converter is added/changed/removed, the dictionary has to be updated > manually. > > > Levente Yeah, the code was merely a proof of concept to show off that you could get acceptable (for some :P) performance using it, as a middleground between squeakToUtf8 and convertToWithConverter in terseness. Cheers, Henry

Aug. 30, 2010

Re: [Pharo-project] return character magic?

by Henrik Sperre Johansen

On 31.08.2010 01:32, Eliot Miranda wrote: > Hi Henrik, > > twice you write a slip that the compiler should not allow: > > (map := characterToGlyphMap) > ifNotNil: [:map | code := map at: code + 1]. > > code := (map := characterToGlyphMap) > ifNil: [aCharacter charCode] > ifNotNil: [:map | map at: aCharacter charCode + 1] > > these should read > > characterToGlyphMap ifNotNil: [:map | code := map at: code + 1]. > > code := characterToGlyphMap > ifNil: [aCharacter charCode] > ifNotNil: [:map | map at: aCharacter charCode + 1] > > HTH, > Eliot Hum, unless I posted a previous version, the code in the changeset was: characterToGlyphMap ifNotNil: [:map | code := map at: code +1]. and code := characterToGlyphMap ifNotNil: [:map | map at: aCharacter charCode +1] ifNil: [aCharacter charCode]. Seem to me they got decompiled somehow? > > also in BitBlt>>#primDisplayString:from:to:map:xTable:kern: you write > > ascii := glyphMap at: (aString at: charIndex) asciiValue + 1. > > whereas the current Squeak code reads > > ascii := (aString at: charIndex) asciiValue. > glyphMap ifNotNil:[ascii := glyphMap at: ascii+1]. > > Should Squeak keep its original code (which seems equivalent) or is > there a specific reason to eliminate the ifNotNil: test? > > TIA > Eliot Yes, it should keep it. Getting late, I made that change in that method first to have Pharo display correctly, and didn't yet think of that glyphMap may be nil :) For Squeak, the two methods in StrikeFont should be sufficient. Cheers, Henry

Aug. 30, 2010

Re: [Pharo-project] return character magic?

by Eliot Miranda

Hi Henrik, twice you write a slip that the compiler should not allow: (map := characterToGlyphMap) ifNotNil: [:map | code := map at: code + 1]. code := (map := characterToGlyphMap) ifNil: [aCharacter charCode] ifNotNil: [:map | map at: aCharacter charCode + 1] these should read characterToGlyphMap ifNotNil: [:map | code := map at: code + 1]. code := characterToGlyphMap ifNil: [aCharacter charCode] ifNotNil: [:map | map at: aCharacter charCode + 1] HTH, Eliot also in BitBlt>>#primDisplayString:from:to:map:xTable:kern: you write ascii := glyphMap at: (aString at: charIndex) asciiValue + 1. whereas the current Squeak code reads ascii := (aString at: charIndex) asciiValue. glyphMap ifNotNil:[ascii := glyphMap at: ascii+1]. Should Squeak keep its original code (which seems equivalent) or is there a specific reason to eliminate the ifNotNil: test? TIA Eliot 2010/8/30 Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> > On 30.08.2010 22:05, Nicolas Cellier wrote: > >> 2010/8/30 StÃ©phane Ducasse<stephane.ducasse(a)inria.fr>: >> >>> On Aug 30, 2010, at 8:33 PM, Johan Brichau wrote: >>> >>> so what did you do? >>>> >>>> I see that the file got removed... I will submit a bug issue for that >>>> with the file attached. >>>> >>>> The *real* problem is that you cannot remove it either! It does _not_ >>>> want to go away! >>>> >>> Oops! A bad spirit in pharo :) >>> >>> Any person able to understand MultiDisplayScanner arcanes wouldn't see >> any magic in this. But I really wonder whether a single person can >> manage such complexity... Henrik ? >> >> Nicolas >> > Hurr durr, I hate a challenge, can't really stop... > In Pharo, the display primitive fails, and the fallback code does not deal > correctly with the characterToGlyphMap used by StrikeFonts to store arrows > at the normal ^_ spots, and substitute with characters at slots 128/129. > In Squeak, the glyph-by-glyph rendering is encountered, and neither > hasGlyphOf: nor glyphInfoInto: takes the map into account > Attached is the fixed code for all three methods, should work in both Pharo > and Squeak with these. > (Issue 2886 on the Pharo tracker) > > Cheers, > Henry > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 30, 2010

Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final

by Levente Uzonyi

On Mon, 30 Aug 2010, Miguel Enrique CobÃ¡ MartÃnez wrote: > El mar, 31-08-2010 a las 00:43 +0200, Levente Uzonyi escribiÃ³: > On Mon, 30 Aug 2010, Miguel Enrique CobÃ¡ MartÃnez wrote: > > > El mar, 31-08-2010 a las 00:25 +0200, Levente Uzonyi escribiÃ³: > > On Mon, 30 Aug 2010, Friedrich Dominicus wrote: > > > > > Levente Uzonyi <leves(a)elte.hu> writes: > > > > > On Mon, 30 Aug 2010, StÃ©phane Ducasse wrote: > > > > > >>>> > > >>>> I suggest that the people that want and know, group together and build an open-source one. > > >>> > > >>> Why do you have to have your "own" library? > > >> > > >> Did I say "pharo library"? reread carefully I said an "open-source one". > > > > > > What I get from Andreas' words is that he's willing to make it open > > > source if it won't be forked. > > Hm I think this is impossible. If it's OS it's up to whomever get its > > hand on it. Or am I mistaken? > > > > > > Just think about GPL, it's open source, but you can't fork the code if you > > don't release your changes as GPL too. > > "I don't get it. If it is open source then is forkable. Period. > If it is a special case like GPL, it add some other restriction, like > you can't redistribute the new code without it being also GPL. You can > fork it and not using GPL for the new changes, the restriction is that > you can't redistribute it." > > From wikipedia: "Open-source software (OSS) is computer software that is > available in source code form for which the source code and certain other > rights normally reserved for copyright holders are provided under a > software license that permits users to study, change, and improve the > software." > > There's nothing about forking or redistributing here. I could make a > license that says: you can study, change and improve the software, but > you can't redistribute it without my permission. > > "But the fact remains that it is forkable always. If you don't want it > forkable, then use other non open source license." > > See above. You could "fork" it, but that wouldn't be open source anymore. > "You must be kidding. The freedom to fork is a essential right of open source software: http://news.cnet.com/8301-13505_3-10379280-16.html http://asay.blogspot.com/2006/10/wither-right-to-fork.html http://www.gnu.org/philosophy/free-sw.html http://www.opensource.org/docs/osd http://www.opensource.org/node/357 period." If you agree with OSI. Levente > > Levente > > > Cheers > > > > > > > > > Levente > > > > > > Regards > > Friedrich > > > > -- > > Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim > > Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus > > > > _______________________________________________ > > 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 > > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > 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 -- Miguel CobÃ¡ http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 30, 2010

Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final

by Levente Uzonyi

On Tue, 31 Aug 2010, Nicolas Cellier wrote: > 2010/8/31 Levente Uzonyi <leves(a)elte.hu>: >> On Mon, 30 Aug 2010, Nicolas Cellier wrote: >> >>> Hi Pharoers, >> >> snip >> >>> Come-on guys, despite Levente's cutting remark, you're not inferior to >>> squeakers ;) (and you don't have to answer to that stupid conclusion). >> >> Uh, what remark? >> > > Oh, you know, the missinterpreted _and_... (that's wall I call "lancer > une pique"). It wasn't me who misinterpreted that "and". I would agree with you, if I were using "or", but that wasn't the case. > I should have included you in the list of people not having to answer ;) :) Levente > > Nicolas > >>> >>> Nicolas >>> >> >> snip >> >> >> _______________________________________________ >> 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 >

Aug. 30, 2010

Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final

by Levente Uzonyi

On Tue, 31 Aug 2010, Henrik Sperre Johansen wrote: snip > Yeah, that's why I added the 200000 4KB docs / sec number. > I really doubt the conversion will be a significant part of the processing > time if what you send out is so small you are able to convert 800k messages > per second... It depends on the machine/load/etc. > > See the code I attached last mail, switching to convertToEncoding: 'utf8' > sort of implied implementing something like that, which gives it nearly the > same speed as convertToWithConverter: UTF8TextConverter new in your examples. Sorry, I didn't see that. It looks cool, but I still wouldn't use #convertToEncoding: in my code, because there's a similar looking method (#converToWithConverter:) with better performance :). But it's definitely better than the current version, though if a converter is added/changed/removed, the dictionary has to be updated manually. Levente > > IMHO, that might be a nice tradeoff between speed and the two desires of not > bringing back #squeakToUtf8 in Pharo, nor having to use the > convertToWithConverter: call Andreas was strongly opposed to (and which I > agree is rather ugly). > > Cheers, > Henry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 30, 2010

Re: [Pharo-project] return character magic?

by Nicolas Cellier

Henrik, you must be a kind of sorcerer or maybe a devil! Nicolas 2010/8/31 Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no>: > Â On 30.08.2010 22:05, Nicolas Cellier wrote: >> >> 2010/8/30 StÃ©phane Ducasse<stephane.ducasse(a)inria.fr>: >>> >>> On Aug 30, 2010, at 8:33 PM, Johan Brichau wrote: >>> >>>> so what did you do? >>>> >>>> I see that the file got removed... Â I will submit a bug issue for that >>>> with the file attached. >>>> >>>> The *real* problem is that you cannot remove it either! It does _not_ >>>> want to go away! >>> >>> Oops! A bad spirit in pharo :) >>> >> Any person able to understand MultiDisplayScanner arcanes wouldn't see >> any magic in this. But I really wonder whether a single person can >> manage such complexity... Henrik ? >> >> Nicolas > > Hurr durr, I hate a challenge, can't really stop... > In Pharo, the display primitive fails, and the fallback code does not deal > correctly with the characterToGlyphMap used by StrikeFonts to store arrows > at the normal ^_ spots, and substitute with characters at slots 128/129. > In Squeak, the glyph-by-glyph rendering is encountered, and neither > hasGlyphOf: nor glyphInfoInto: takes the map into account > Attached is the fixed code for all three methods, should work in both Pharo > and Squeak with these. > (Issue 2886 on the Pharo tracker) > > Cheers, > Henry > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 30, 2010

Re: [Pharo-project] return character magic?

by Miguel Enrique CobÃ¡ MartÃnez

El mar, 31-08-2010 a las 00:44 +0200, Henrik Sperre Johansen escribiÃ³: > On 30.08.2010 22:05, Nicolas Cellier wrote: > > 2010/8/30 StÃ©phane Ducasse<stephane.ducasse(a)inria.fr>: > >> On Aug 30, 2010, at 8:33 PM, Johan Brichau wrote: > >> > >>> so what did you do? > >>> > >>> I see that the file got removed... I will submit a bug issue for that with the file attached. > >>> > >>> The *real* problem is that you cannot remove it either! It does _not_ want to go away! > >> Oops! A bad spirit in pharo :) > >> > > Any person able to understand MultiDisplayScanner arcanes wouldn't see > > any magic in this. But I really wonder whether a single person can > > manage such complexity... Henrik ? > > > > Nicolas > Hurr durr, I hate a challenge, can't really stop... > In Pharo, the display primitive fails, and the fallback code does not > deal correctly with the characterToGlyphMap used by StrikeFonts to store > arrows at the normal ^_ spots, and substitute with characters at slots > 128/129. > In Squeak, the glyph-by-glyph rendering is encountered, and neither > hasGlyphOf: nor glyphInfoInto: takes the map into account > Attached is the fixed code for all three methods, should work in both > Pharo and Squeak with these. > (Issue 2886 on the Pharo tracker) Impressive! :) > > Cheers, > Henry > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Aug. 30, 2010