- Pharo-dev - lists.pharo.org

Re: [Pharo-project] hex

by csrabak＠bol.com.br

Stef, I've posted this yesterday, but here it is: In Pharo '16r7A2BD507' asNumber = 2049692935 '16r7a2bd507' asNumber = 7 In Squeak (3.10.2-7179) '16r7A2BD507' asNumber = 2049692935 '16r7a2bd507' asNumber = 7 Obviously I printed in the Workspace (Shout) -- Cesar Rabak Em 24/02/2010 19:41, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr > escreveu: On Feb 24, 2010, at 6:47 PM, csrabak(a)bol.com.br wrote: > Stef, > > Squeak prints in lowercase and reads *correctly* only in uppercase. . . can you post the expression you use? Are you talking about byteArray? or plain number? > > -- > Cesar Rabak > > > Em 24/02/2010 04:05, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr > escreveu: > >> The main reason for not using lowercase in squeak was Dan extension of >> number with radix plus exponent. >> 16r8e7 -> 16r8 * (16 raisedTo: 7) >> and the Float variations... >> >> If you decided to abandon this notation, then go with either upper or lower. >> But a bit of consistency could help... > > I'm confused what is the situation now in squeak? > Because it seems that hex in squeak now prints and read lowercase? > So did > 16r8e7 and float > so will someone fix squeak to be consistent. > I'm a bit confused by the decision process in squeak (even if I should not worried too much). > > Stef > _______________________________________________ > 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

Feb. 25, 2010

Re: [Pharo-project] hex

by csrabak＠bol.com.br

Em 24/02/2010 16:03, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com > escreveu: 2010/2/24 : > > Stef, > > Squeak prints in lowercase and reads *correctly* only in > > uppercase. . . > > > > -- Cesar Rabak > > > I think recent trunk version read both correctly. Did you try > recently? Nicolas, As I reported in an earlier post to this list, I used: In Squeak (3.10.2-7179), I've not been downloading newer images for Squeak for long time indeed. If newer Squeak versions work differently, I cannot ascertain that, others will have to perform the test as well. HTH, -- Cesar Rabak

Feb. 25, 2010

[Pharo-project] Re-licensing Squeak

by Torsten Bergmann

FYI: http://lists.squeakfoundation.org/pipermail/news/2010-February/000215.html -- GMX DSL: Internet, Telefon und Entertainment fÃ¼r nur 19,99 EUR/mtl.! http://portal.gmx.net/de/go/dsl02

Feb. 25, 2010

Re: [Pharo-project] Why a package management system

by Nicolas Cellier

2010/2/24 GermÃ¡n Arduino <garduino(a)gmail.com>: > > > 2010/2/24 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> >> Thanks for your steady building approach >> > > +111111111111111 > This is the attitude, Thanks Dale! > Are you in base 1r from Cuis 2.0 ? Nicolas > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 24, 2010

Re: [Pharo-project] Why a package management system

by Henrik Sperre Johansen

On 23.02.2010 19:01, StÃ©phane Ducasse wrote: >> I've been meaning to make system-change notifications for Pharo so the >> recording-part could work there too, but I never seem to get around to it :( >> Part of the problem is of course my own personal "The Best Way"(tm), >> which f.ex. would include Announcements. >> Since I'd like the ability to have Weak subscriptions, I'd first have to >> deoptimize the Announcement-package Levente made a bit to make it >> "prettier", > can you explain a bit more the technical aspect? Well, Levente's implementation, each kind of arg has it's own Subscription class, for performance reasons. What I was hoping to do was consolidate these so there's only two classes, one for Strong, and one for weak subscriptions. Using cull: this is possible, with a small performance penalty at subscriber evaluation time (IIRC, 4 times less overhead compared to valueWithPossibleArgs:, but double the overhead of direct value: evaluation which you achieve with the one-class-per-arg-type approach ), but with faster subscription creation. Thus, you get a simpler implementation at the cost of some performance. Lacking Weak subscriptions is, as Bill put it in an earlier mail: "a lot like the dependency days of MVC - remember #release? I'm trying to forget" - If you don't outlive your announcer, you have to unsubscribe manually to be GC'd. >> make it a strict superset of what if found in Core already, >> fix WeakRegistry so each resource registered for an object actually gets >> finalized, which again means... etc... Oh, and hope it'd end up good >> enough that it'd warrant inclusion:) > I would love to see a bit more enhancement on Announcement. I described the issue with WeakRegistry>>toFinalize:send:to:with: in a previous mail, it's only related in the term that Levente's implementation uses it. (I encountered it while writing some tests for weak subscriptions) Reading Squeak-Dev, it seems he's picked it up, and there's a version in the Inbox, I'll be reviewing that :D As for the Announcement implementation, AXAnnouncements follow what was described in the post of Vassily more closely, which both make use of them more portable, as well as provide some other benefits, the ones which seems of most value to me is the simple implementation of weak subscriptions, plus support for registering actions taking more than the announcement itself as a parameter for handlers. http://n4.nabble.com/Notifications-of-windows-opening-closing-focus-td12965… (where the above quote is taken from) contains a relevant discussion as to why I find these features useful. Changing Lukas' implementation as provided in Core to do the same, (I think) you'd loose much of its simple elegance The one thing I'm ambivalent about regarding VW/AX implementation vs. Lukas', is whether when:do: should be setting the block as subscriber (VW) instead of the instance sending when:do: (Lukas). When using this method together with strong subscriptions in VW, I almost always ended up using when:do:for: so I could register the instance as subscriber instead. Cheers, Henry

Feb. 24, 2010

Re: [Pharo-project] hex

by Nicolas Cellier

2010/2/24 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > On Feb 24, 2010, at 6:47 PM, csrabak(a)bol.com.br wrote: > >> Stef, >> >> Squeak prints in lowercase and reads *correctly* only in uppercase. . . > > can you post the expression you use? > Are you talking about byteArray? or plain number? ByteArray, UUID and plain Number Andreas Raab uploaded a new version of Collections to project The Trunk: http://source.squeak.org/trunk/Collections-ar.310.mcz ==================== Summary ==================== Name: Collections-ar.310 Author: ar Time: 23 February 2010, 7:16:34.191 am UUID: eb685ed0-dba7-d546-b63e-08f76154d027 Ancestors: Collections-ul.309 Conversions from/to hex representations in ByteArray, for example: #[122 43 213 7] hex => '7a2bd507' ByteArray readHexFrom: '7a2bd507' => #[122 43 213 7] Similarly these can be used for subclasses, e.g., UUID new hex => '97c1f2ddf9209948b329319a30c16386' UUID readHexFrom: '97c1f2ddf9209948b329319a30c16386' => 97c1f2dd-f920-9948-b329-319a30c16386 Andreas Raab uploaded a new version of Multilingual to project The Trunk: http://source.squeak.org/trunk/Multilingual-ar.87.mcz ==================== Summary ==================== Name: Multilingual-ar.87 Author: ar Time: 11 February 2010, 11:48:33.736 pm UUID: ca61be1a-7e30-2840-9b77-9cc7ecfc2d3f Ancestors: Multilingual-ar.86 Change EncodedCharSet>>digitValue: to EncodedCharSet>>digitValueOf:. Part 3/3. =============== Diff against Multilingual-ar.86 =============== Item was changed: ----- Method: EncodedCharSet class>>digitValueOf: (in category 'class methods') ----- digitValueOf: char "Answer 0-9 if the receiver is $0-$9, 10-35 if it is $A-$Z, and < 0 otherwise. This is used to parse literal numbers of radix 2-36." | value | value := char charCode. + value <= $9 asciiValue ifTrue: + [^value - $0 asciiValue]. + value >= $A asciiValue ifTrue: + [value <= $Z asciiValue ifTrue: [^value - $A asciiValue + 10]. + (value >= $a asciiValue and: [value <= $z asciiValue]) ifTrue: + [^value - $a asciiValue + 10]]. - value <= $9 asciiValue - ifTrue: [^value - $0 asciiValue]. - value >= $A asciiValue - ifTrue: [value <= $Z asciiValue ifTrue: [^value - $A asciiValue + 10]]. ^ -1 ! snip... >> >> -- >> Cesar Rabak >> >> >> Em 24/02/2010 04:05, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr > escreveu: >> >>> The main reason for not using lowercase in squeak was Dan extension of >>> number with radix plus exponent. >>> 16r8e7 -> 16r8 * (16 raisedTo: 7) >>> and the Float variations... >>> >>> If you decided to abandon this notation, then go with either upper or lower. >>> But a bit of consistency could help... >> >> I'm confused what is the situation now in squeak? >> Because it seems that hex in squeak now prints and read lowercase? >> So did >> 16r8e7 and float >> so will someone fix squeak to be consistent. >> I'm a bit confused by the decision process in squeak (even if I should not worried too much). >> >> Stef >> _______________________________________________ >> 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 >

Feb. 24, 2010

Re: [Pharo-project] Building Pharo on a Core 1.1

by Dale Henrichs

----- "Alexandre Bergel" <alexandre(a)bergel.eu> wrote: | But I get an error raised by MetacelloPackageSpec>>instVarNames:put: | | apparently some reflective operations try to access a non-existing | variable. | | I know that Pharo is meant to be built from a stable core. But I would | like to benefit from the snappy interface and the nice menu. Anyone | tried ? Odd... there's one spot where Metacello uses instVarNamed:put: and the names being used should correspond 1 to 1 with instance variables of the specs. Do you have more detail about the error? The receiver's class and the value and class of the args to instVarNamed:put: might help. Dale

Feb. 24, 2010

[Pharo-project] Building Pharo on a Core 1.1

by Torsten Bergmann

>But I would like to benefit from the snappy interface and the nice menu. Yes - but since we changed more than just the nice menu I think the whole config and anything that gets loaded need to be revised for 1.1. Bye T. -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser

Feb. 24, 2010

Re: [Pharo-project] hex

by StÃ©phane Ducasse

On Feb 24, 2010, at 6:47 PM, csrabak(a)bol.com.br wrote: > Stef, > > Squeak prints in lowercase and reads *correctly* only in uppercase. . . can you post the expression you use? Are you talking about byteArray? or plain number? > > -- > Cesar Rabak > > > Em 24/02/2010 04:05, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr > escreveu: > >> The main reason for not using lowercase in squeak was Dan extension of >> number with radix plus exponent. >> 16r8e7 -> 16r8 * (16 raisedTo: 7) >> and the Float variations... >> >> If you decided to abandon this notation, then go with either upper or lower. >> But a bit of consistency could help... > > I'm confused what is the situation now in squeak? > Because it seems that hex in squeak now prints and read lowercase? > So did > 16r8e7 and float > so will someone fix squeak to be consistent. > I'm a bit confused by the decision process in squeak (even if I should not worried too much). > > Stef > _______________________________________________ > 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

Feb. 24, 2010

Re: [Pharo-project] withAllSubclasses -> Set or OrderedCollection

by StÃ©phane Ducasse

tx since we are in unstable we can go full speed. Stef On Feb 24, 2010, at 2:21 PM, Nicolas Cellier wrote: > Ah, I just found this starting point: > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-January/143063.… > > 2010/2/24 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> The impact is: >> - breaking some tools (easy to fix with asSet) I can't tell you >> which... I saw an update recently related to this change. >> - speeding up some other tools (unecessary asSet is unecessary cost) >> - increasing Kernel consistency (selectors, instVarNames, >> classVarNames don't return a Set). >> >> The speed-up gained by eliminating all these useless Set is visible in the IDE. >> >> Nicolas >> >> 2010/2/24 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> Since this is obvious that in a tree you do not get twice the same node >>> I was wondering why in the first place a set was returned. >>> So apparently I'm not the only to not know and I was then curious about the >>> impact of the changes. >>> I was more interested in the impact of the changes that its justification :) >>> >>> http://code.google.com/p/pharo/issues/detail?id=2071 >>> >>> Stef >>> >>> On Feb 24, 2010, at 9:33 AM, Nicolas Cellier wrote: >>> >>>> 2010/2/24 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>>> this was not really my question :) I know that a tree does not twice the same node >>>>> do you know when it changed in squeak or pharo and the reason? >>>>> >>>>> Stef >>>> >>>> I return the question: so why answer a Set ? >>>> For multiple inheritance experiments or for some tools conveniency ? >>>> >>>> Nicolas >>>> >>>>> >>>>> On Feb 23, 2010, at 11:02 PM, Nicolas Cellier wrote: >>>>> >>>>>> The single inheritance hierarchy is a Tree... >>>>>> I don't see any interest in answering a Set. >>>>>> Some tools might expect a Set... >>>>>> If so, they just have to use withAllSubclasses asSet. >>>>>> >>>>>> If my own tool expect a LinkedList, I ain't gonna change the Kernel >>>>>> library for my conveniency, or am I ? >>>>>> >>>>>> Nicolas >>>>>> >>>>>> 2010/2/23 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>>>>> Nicolas I remember that we discussed this point or a related one a while ago >>>>>>> >>>>>>> Squeak >>>>>>> >>>>>>> Point withAllSubclasses >>>>>>> an OrderedCollection(Point) >>>>>>> >>>>>>> >>>>>>> Pharo >>>>>>> >>>>>>> Point withAllSubclasses >>>>>>> a Set(Point) >>>>>>> >>>>>>> Do you remember? >>>>>>> I forgot? >>>>>>> >>>>>>> Stef >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>> >>>> _______________________________________________ >>>> 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

Feb. 24, 2010