Re: [Pharo-project] update server down?
apparently the forge was down yesterday evening. Not sure that this is available now. On Oct 26, 2009, at 8:31 PM, Michael Roberts wrote: i'm getting timeouts from the update server. can someone confirm? thanks, Mike ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] (a = b) = (a hash = b hash)
Yes. Filenames and URLs are particularly problematic. Fortunately they tend to be O(100) in size, as opposed to O(1000) in size. Thus, the less demanding path of just hashing the characters is efficient enough for the cases I've seen so far. IMO, we should not let Array hash ~= Interval hash coexist with Array = Interval Because it's like putting some traps on programmers path. Yes, I agree. I'd vote on breaking #=, with the caveat that chances are some code will be broken. Does Pharo have a release strategy that allows more fundamental changes to go in, as opposed to maintenance/improvement fixes? yes we talk then we summarize and describe a bug entry and Now I'm thinking that it would be good to have a page with important changes per version I would put there the discussions about the float changes we did in 1.0. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Thread-safe collections
On Oct 25, 2009, at 10:15 PM, Schwab,Wilhelm K wrote: Stef, It sounds like I am indeed missing something in saving slices. I saw mention of it, but thought I read that it was not the preferred method and didn't dig further. Are you saying that I can make one big slice with all of my stuff and suddenly all becomes easy?? if you have a package and some dependents when you will save a comments will be propagated to all the dependents no need to repeat that. On the load side, I was having problems over name mis-matches that would not exist given a good packaging system. I could probably get around them now by reifying the names in my load script. I suggest that you start also to look at metacello because dale is managing glass with it and doru moose/mondrian in the future we want to manage the release with it. Stef Bill -Original Message- From: pharo-project-boun...@lists.gforge.inria.fr [mailto:pharo- project-boun...@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Sunday, October 25, 2009 2:59 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Thread-safe collections On Oct 23, 2009, at 3:31 PM, Schwab,Wilhelm K wrote: Stef, With no disrespect to Sig's opinions, I'm glad to hear that. I very quickly cobbled together a class called SharedLookupTable, and have no problems making it (suitably debugged) available. Now it's time for me to kick your ass a little, to coin a phrase :) no problem Monticello is pretty good at what it does, but I sense the things it does not do interfering with good decision making. The class ended up in my Dolphin compatibility package, in part because it belongs there, though it really should be separate so I can easily release it and people would be able to get it w/o having to accept other ideas they might not want. But it went in the compatiblity package so I would not have to mess around with another package. Saving them is a pain; loading them into a new image is a pain. why? Saving: the interface works well once understood, and the features it offers should never go away. However, either by script or by multiple selection, it would be nice to provide a comment to be applied to everything to be saved now vs. having to be prompted for it, then have the list scroll, then have to click away another window. Do that 30 times and it starts to get old. this is strange because I thought that we fixed that pop up plague when saving slices Then you get all the comments you already typed in one of the button of the poped up window. Did you see it? Loading: I spent a chunk of yesterday trying to build an RC1 image. Doing so revealed that my script-loader for script-loader does not validate package names. I had one build attempt come to a halt over case-sensitivity; I do not mind that. What I mind is that the particular case mix in question was more or less forced on me by a typo of mine. If MC were better about offering choices when they apply, I might not have typed it that way. I realize that Gofer is coming, and it might fix a lot of this. yes and also metacello which is coming along well The ideas above are probably not new, but I list them just in case. Bill -Original Message- From: pharo-project-boun...@lists.gforge.inria.fr [mailto:pharo- project-boun...@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Friday, October 23, 2009 2:46 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Thread-safe collections I would really like to see some packages getting implementing around the idea of a couple of robust and well tested thread safe collections. Stef On Oct 23, 2009, at 2:16 AM, Schwab,Wilhelm K wrote: Sig, One can always construct examples in which protecting the entire loop is the better option. That's not the scenario of interest. Just as shared queues are useful, shared sets and dictionaries have value for sporadic access scenarios. Doing it your way, everyone writes their own incompletely protected (read buggy/dangerous) ad- hoc implementations of these common collections. I favor having solid implementations that are complete and as correct as we can get them, leaving people to optimize as you suggest when it makes sense to do so. Bill -Original Message- From: pharo-project-boun...@lists.gforge.inria.fr [mailto:pharo- project-boun...@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Thursday, October 22, 2009 5:23 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Thread-safe collections 2009/10/23 Schwab,Wilhelm K bsch...@anest.ufl.edu: Hello all, I just looked around for thread-safe collections, and found nothing that looks like a shared dictionary. The squeak-dev archives contain the obligatory newbie posts (wanting all collections to be thread safe) and the expected replies,
Re: [Pharo-project] update server down?
yes it's working now. thanks Mike On Tue, Oct 27, 2009 at 7:51 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: apparently the forge was down yesterday evening. Not sure that this is available now. On Oct 26, 2009, at 8:31 PM, Michael Roberts wrote: i'm getting timeouts from the update server. can someone confirm? thanks, Mike ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] ClassOrganizer oddities
2009/10/27 Igor Stasenko siguc...@gmail.com: 2009/10/26 Stéphane Ducasse stephane.duca...@inria.fr: so what is the fix? I would really like to get announcement instead of event systemNotification but I'm sure that this can be a bit tricky. Yes, tricky :) Here what i have in mind: Any change to system should be captured _before_ it applied. This allows us to introduce a policy which can validate the change and decide whether it allowed to be made or not. I made the SystemChangeEvent class, which having following state: - changeKind - a symbol, which identifies the change Hi Igor, IMHO, nowadays, the trend would be to create subclasses rather than internal symbols... Shouldn't there be a symmetry with the hierarchy of changes in DeltaStream (for example) ? Nicolas - parameters - a dictionary , which holding different parameters, important for change - subject - the object which is going to be changed (or taking a main role in change) - action - a block closure which , if evaluated, will apply the change to system For example, here the method which creates populates the system change event: classify: element under: heading suppressIfDefault: aBoolean (self subject newSystemEvent: #changeSelectorCategory) subject: element; param: #behavior-self subject; param: #category-heading asSymbol; param: #suppressIfDefault-aBoolean; action: [ super classify: element under: heading suppressIfDefault: aBoolean ]; signal. - The event handling procedure is following: - first of all, an event passed to a system arbiter object - a system arbiter checking with the policy - if everything ok, change is applied by evaluating action. - and finally, change is announced to any interesting parties I want to make each package to hold own policy (a set of flags identified by name, to ease fileout). Then, any event could be validated by policy by issuing: package policy validate: change For example, lets see , what validations we could introduce for method recategorization event. - lets take most interesting case, when we want to recategorize the method in ClassA, which belongs to PackageA, and putting it into extension category, like *PackageB - check, if we allow any changes to ClassA (policy of PackageA) - check if PackageA allows method extensions (policy of PackageA) - check if PackageB allows extending the classes of another packages (policy of PackageB) - check if extension overrides existing method - and of course, we should check that given extension does not creates a circular dependency between the packages. There, of course, some problems which arising. - changes nesting. Some changes is complex ones, and even a simple method recategorization could lead to another event - creating a new category in class. Optimally, it would be cool to have only most basic events, which can't be nested. And any action which may lead to multiple changes, should be split on a number of basic ones. A SystemChangeNotifier solving this by allowing doing things silently: SystemChangeNotifier uniqueInstance doSilently: [ ... ]. so, any changes within the block , if any, won't be announced. - atomicity support. To support the bulk model updating, i can imagine the framework, which capturing any changes without applying them, by building/collecting all changes in parallel, and then applying them by a single mass-become. This is what SystemEditor does. - metaprogramming. There should be a means to leave a room for metaprogramming. We wouldn't want to signal a system change for anonymous classes, and many other things, which can be tricky here. P.S. as you can see , the plans is quite bold, and will require numerous refactorings :) So, the more people is interested in that, the better. Stef -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] update server down?
Wasn't this problem due to the announced maintenance of GForge for Monday 26th October 2009, from 18:30 to 22:00? Doru On 27 Oct 2009, at 08:57, Michael Roberts wrote: yes it's working now. thanks Mike On Tue, Oct 27, 2009 at 7:51 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: apparently the forge was down yesterday evening. Not sure that this is available now. On Oct 26, 2009, at 8:31 PM, Michael Roberts wrote: i'm getting timeouts from the update server. can someone confirm? thanks, Mike ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com Problem solving should be concentrated on describing the problem in a way that is relevant for the solution. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] update server down?
Wasn't this problem due to the announced maintenance of GForge for Monday 26th October 2009, from 18:30 to 22:00? or related to a squeaksource server reset: http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-October/140479.html -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] update server down?
Probably. Where are they announced? Can they be posted here? Cheers mike On Tuesday, October 27, 2009, Tudor Girba tudor.gi...@gmail.com wrote: Wasn't this problem due to the announced maintenance of GForge for Monday 26th October 2009, from 18:30 to 22:00? Doru On 27 Oct 2009, at 08:57, Michael Roberts wrote: yes it's working now. thanks Mike On Tue, Oct 27, 2009 at 7:51 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: apparently the forge was down yesterday evening. Not sure that this is available now. On Oct 26, 2009, at 8:31 PM, Michael Roberts wrote: i'm getting timeouts from the update server. can someone confirm? thanks, Mike ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com Problem solving should be concentrated on describing the problem in a way that is relevant for the solution. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] SeasideTesting
Hi, is there a SeasideTesting that is working in pharo? Norbert ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] ClassOrganizer oddities
2009/10/27 Nicolas Cellier nicolas.cellier.aka.n...@gmail.com: 2009/10/27 Igor Stasenko siguc...@gmail.com: 2009/10/26 Stéphane Ducasse stephane.duca...@inria.fr: so what is the fix? I would really like to get announcement instead of event systemNotification but I'm sure that this can be a bit tricky. Yes, tricky :) Here what i have in mind: Any change to system should be captured _before_ it applied. This allows us to introduce a policy which can validate the change and decide whether it allowed to be made or not. I made the SystemChangeEvent class, which having following state: - changeKind - a symbol, which identifies the change Hi Igor, IMHO, nowadays, the trend would be to create subclasses rather than internal symbols... Shouldn't there be a symmetry with the hierarchy of changes in DeltaStream (for example) ? Well, my own 'trend' is to use GLOBALS as little as possible. So instead of spawning a whole tree of different event types, and then spit them around in different places, i prefer to use messages instead. I am using a single #newSystemEvent: message to create an instance of system event. So, there will be only a few places, where #SystemChangeEvent global be referenced, and therefore you can refactor the whole thing by changing few places. I don't plan to put into the SystemChangeEvent any kind of clever code. It just a state holder, notthing more. And handlers usually do a simple dispatch to handle the event. Moreover, i won't be using numerous #isX stinky tests, which is just a code bloat and don't really helpful unless you writing plainly wrong code ( remember? don't ask - tell ) :) For instance, i tried to track all listeners of particular SystemNotification event, and had hard times to find them out, because its dispatching scheme generates the selector consisting from 3 parts: itemKind, changeKind, 'Event:' (see implementation of #eventSelector) but when i staring at code which creates a notification, i don't see these selectors, and to figure out, that is the actual method is used to handle given notification i need to go exploring the internals of dozens of AbstractEvent subclasses. In contrast, if i would want to find out all handlers of particular SystemChangeEvent , i would need only to see implementors of changeKind selector (such as #changeSelectorCategory) , which is right before my eyes, in the code which emits the system change event. But i want to hear your counterarguments, why bunch of subclasses is more appropriate. Symmetry with DeltaStreams: no symmetry. The difference is that deltas capturing 'before' and 'after' state. While for SystemChangeEvent, there is no 'after' happened yet. It should carry the only state which is enough to analyze perform the change. And its not necessary that this state will consist of simple objects (strings, symbols etc), simply for speed efficiency purposes - i could pass the CompiledMethod instance instead of the source of method, behavior object, instead of a class name and 'isMeta' boolean, and so on. Moreover, it is not necessary that change will be applied at all. The users of SystemChangeEvent operating directly with system data model, therefore you don't need to translate everything to simplest forms, as deltastreams doing, because these events living dying inside the system and have little use for outside. Of course, the arbiter object, which i mentioned before could easily capture all 'before' and 'after' state, and then broadcast this to all subscribers. And of course its free to translate the event into more edigible form. Nicolas - parameters - a dictionary , which holding different parameters, important for change - subject - the object which is going to be changed (or taking a main role in change) - action - a block closure which , if evaluated, will apply the change to system For example, here the method which creates populates the system change event: classify: element under: heading suppressIfDefault: aBoolean (self subject newSystemEvent: #changeSelectorCategory) subject: element; param: #behavior-self subject; param: #category-heading asSymbol; param: #suppressIfDefault-aBoolean; action: [ super classify: element under: heading suppressIfDefault: aBoolean ]; signal. - The event handling procedure is following: - first of all, an event passed to a system arbiter object - a system arbiter checking with the policy - if everything ok, change is applied by evaluating action. - and finally, change is announced to any interesting parties I want to make each package to hold own policy (a set of flags identified by name, to ease fileout). Then, any event could be validated by policy by issuing: package policy validate: change For example, lets see , what validations we could introduce for method recategorization event. - lets take most
Re: [Pharo-project] NewCompiler for pharo?
Hi Stef, On Sun, Oct 25, 2009 at 10:37 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: - is there a way to get something compiled in between? Two of us use the ThothCompiler in the mean time, which supports all the source code transformations of the NewCompiler, because it features the same AST: - http://smalltalkthoughts.blogspot.com/2009/09/introducing-thothcompiler.html If I understand it correctly, NewCompiler sort of works, but is being cleaned up. I'm sure Lukas and Jorge can correct me here. Cheers, Niko ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Preferences refactoring pushed
Alain Plantec wrote: * Remove the annotationPane preference (no more annotation pane in browsers and MC) * Remove optionalButtons preferences (optional buttons are always present except in the ChangeSetSorter) Very likely I've missed some discussion about this, but I find the annotation pane incredible useful, not just in the change sorter. I also hate the optional buttons (useless and very bad UI as well IMHO), but that might just be me used to using short cuts ;-) So how is the annotation information accessible in the future? Michael ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Preferences refactoring pushed
Michael Rueger wrote: Alain Plantec wrote: * Remove the annotationPane preference (no more annotation pane in browsers and MC) * Remove optionalButtons preferences (optional buttons are always present except in the ChangeSetSorter) Hi Michael, Very likely I've missed some discussion about this, but I find the annotation pane incredible useful, not just in the change sorter. I should have said no more annotation pane in old browser (the one of the core) and in MC. annotation panes from Pharo are still present and untouched by this SLICE. an OB specific setting will have to be declared. Have a look at the issue discussions (Issue 810). http://code.google.com/p/pharo/issues/detail?id=810 Is it ok like that ? Alain I also hate the optional buttons (useless and very bad UI as well IMHO), but that might just be me used to using short cuts ;-) So how is the annotation information accessible in the future? Michael ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] What happened to InputSensor? -- Pharo by Example Lights Out game is broken
Hi Folks, The class InputSensor has mysteriously disappeared between PharoCore-1.0-10488-BETA.zip and PharoCore-1.0-10491rc1.zip Does anyone know what happened to it? The class is needed by the First Application chapter in the Pharo by Example book. - on ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] What happened to InputSensor? -- Pharo by Example Lights Out game is broken
InputSensor has been replaced with InputEventSensor. The global Sensor points to the right instance in old and new images. Lukas 2009/10/27 Oscar Nierstrasz os...@iam.unibe.ch: Hi Folks, The class InputSensor has mysteriously disappeared between PharoCore-1.0-10488-BETA.zip and PharoCore-1.0-10491rc1.zip Does anyone know what happened to it? The class is needed by the First Application chapter in the Pharo by Example book. - on ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [update] #10492 (1.0rc1)
Well, what do you propose? Deprecating asNumber calls altogether?
Cheers,
Niko
On Sat, Oct 24, 2009 at 10:32 AM, Stéphane Ducasse
stephane.duca...@inria.fr wrote:
Yes a good deprecation is needed.
Stef
On Oct 24, 2009, at 11:13 AM, Adrian Lienhard wrote:
Sounds ok. At the same time as integrating the change, all senders of
asNumber in the image need to be checked and adapted to the new
semantics if necessary. IIRC MC was not properly working after the
change. Also, users and maintainers of external packages should be
made aware of the change since it may break their code.
Adrian
On Oct 24, 2009, at 10:46 , Stéphane Ducasse wrote:
Thanks niko
So does everybody agree with
asNumber raising an error
and
squeezeOutNumber
I like the proposal.
Stef
On Oct 24, 2009, at 10:30 AM, Niko Schwarz wrote:
Hi all, I made a follow-up patch like discussed on the workshop. Now
porting becomes as easy as changing asNumber to
squeezeOutNumber.
Name: SLICE-issue-1258-squeezeOutNumber-NikoSchwarz.2
This slice adds squeezeNumberOutOfString: to Number, as discussed in
the Pharo workshop. On the way, it
fixes an issue in SqNumberParser, where it would return itself
rather
than the result of the failblack, when
parsing fails.
Also, a test is added to test and document the new squeezing number
out of strings behavior.
Example usage:
self assert: '123blabla' squeezeOutNumber equals: 123.
self assert: 'blabla123' squeezeOutNumber equals: 123.
self assert: 'blabla12blabla' squeezeOutNumber equals: 12.
self assert: ('12.3bla' squeezeOutNumber -12.3 ) abs 0.0001.
self assert: '.1' squeezeOutNumber 0.
Cheers,
Niko
On Tue, Oct 20, 2009 at 2:14 PM, Adrian Lienhard a...@netstyle.ch
wrote:
10492 (this is the stream of the branch 1.0rc1)
-
- Issue 1320: [squeak trunk] Sort the conflicts. This is required
when
merging a distant version, like Pharo for example...
- Issue 1338: HostWindowTeststestOne is failing in Windows
- Issue 1345: Revert Number classreadFrom: (was integrated with
issue 1258)
___
http://www.adrian-lienhard.ch/
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [update] #10492 (1.0rc1)
Not really
we could do the following
- check all the users of asNumber and let them as asNUmber or
squeezeOutNumber
- then put a deprecation during the alpha phase that state that they
should pay attention
- when we are in rc 1.1 we remove the deprecation
- create a package which would override it with a deprecation.
stef
On Oct 27, 2009, at 2:38 PM, Niko Schwarz wrote:
Well, what do you propose? Deprecating asNumber calls altogether?
Cheers,
Niko
On Sat, Oct 24, 2009 at 10:32 AM, Stéphane Ducasse
stephane.duca...@inria.fr wrote:
Yes a good deprecation is needed.
Stef
On Oct 24, 2009, at 11:13 AM, Adrian Lienhard wrote:
Sounds ok. At the same time as integrating the change, all senders
of
asNumber in the image need to be checked and adapted to the new
semantics if necessary. IIRC MC was not properly working after the
change. Also, users and maintainers of external packages should be
made aware of the change since it may break their code.
Adrian
On Oct 24, 2009, at 10:46 , Stéphane Ducasse wrote:
Thanks niko
So does everybody agree with
asNumber raising an error
and
squeezeOutNumber
I like the proposal.
Stef
On Oct 24, 2009, at 10:30 AM, Niko Schwarz wrote:
Hi all, I made a follow-up patch like discussed on the workshop.
Now
porting becomes as easy as changing asNumber to
squeezeOutNumber.
Name: SLICE-issue-1258-squeezeOutNumber-NikoSchwarz.2
This slice adds squeezeNumberOutOfString: to Number, as
discussed in
the Pharo workshop. On the way, it
fixes an issue in SqNumberParser, where it would return itself
rather
than the result of the failblack, when
parsing fails.
Also, a test is added to test and document the new squeezing
number
out of strings behavior.
Example usage:
self assert: '123blabla' squeezeOutNumber equals: 123.
self assert: 'blabla123' squeezeOutNumber equals: 123.
self assert: 'blabla12blabla' squeezeOutNumber equals: 12.
self assert: ('12.3bla' squeezeOutNumber -12.3 ) abs 0.0001.
self assert: '.1' squeezeOutNumber 0.
Cheers,
Niko
On Tue, Oct 20, 2009 at 2:14 PM, Adrian Lienhard a...@netstyle.ch
wrote:
10492 (this is the stream of the branch 1.0rc1)
-
- Issue 1320: [squeak trunk] Sort the conflicts. This is
required
when
merging a distant version, like Pharo for example...
- Issue 1338: HostWindowTeststestOne is failing in Windows
- Issue 1345: Revert Number classreadFrom: (was integrated
with
issue 1258)
___
http://www.adrian-lienhard.ch/
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-
project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] OCompletion in the rc1 dev image
Hi list, in the most recent dev image (9.10.5), OCompletion is broken for me. I lost my reproducible test case, but the gist was that sometimes when OCompletion had no idea which type a temporal variable would be, you were unable to insert code behind that variable, because if you tried, a debugger would show up. The problem appears to be DebuggerguessTypeForName:. debuggerMap can be nil and if it is, the method fails. I changed the method to the following, and then the strange errors that occur on my image disappear: guessTypeForName: aString | index object | index := debuggerMap ifNotNil: [(debuggerMap tempNamesForContext: self selectedContext) indexOf: aString ifAbsent: []]. object := index ifNil: [index := self receiver class allInstVarNames indexOf: aString ifAbsent: []. index ifNil: [^ nil]. self receiver instVarAt: index] ifNotNil: [self selectedContext tempAt: index]. ^ object class Essentially, I leave index at nil, if debugerMap is nil. I don't know enough about OCompletion to tell whether this is a fix, or makes things worse somehow. Cheers, Niko ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [update] #10492 (1.0rc1)
Well, by doing that you will confuse users that only relied on the
consensual functionality of asNumber.
It's difficult both ways, and because of that, I'd suggest going the
lazy way and not helping the users other than by adding a comment to
#asNumber which explains the evolution of the message and points to
#squeezeOutNumber. I know that the users would appreciate help in the
migration, but I don't see a non-obtrusive way to do so.
Cheers,
Niko
On Tue, Oct 27, 2009 at 2:59 PM, Stéphane Ducasse
stephane.duca...@inria.fr wrote:
Not really
we could do the following
- check all the users of asNumber and let them as asNUmber or
squeezeOutNumber
- then put a deprecation during the alpha phase that state that they
should pay attention
- when we are in rc 1.1 we remove the deprecation
- create a package which would override it with a deprecation.
stef
On Oct 27, 2009, at 2:38 PM, Niko Schwarz wrote:
Well, what do you propose? Deprecating asNumber calls altogether?
Cheers,
Niko
On Sat, Oct 24, 2009 at 10:32 AM, Stéphane Ducasse
stephane.duca...@inria.fr wrote:
Yes a good deprecation is needed.
Stef
On Oct 24, 2009, at 11:13 AM, Adrian Lienhard wrote:
Sounds ok. At the same time as integrating the change, all senders
of
asNumber in the image need to be checked and adapted to the new
semantics if necessary. IIRC MC was not properly working after the
change. Also, users and maintainers of external packages should be
made aware of the change since it may break their code.
Adrian
On Oct 24, 2009, at 10:46 , Stéphane Ducasse wrote:
Thanks niko
So does everybody agree with
asNumber raising an error
and
squeezeOutNumber
I like the proposal.
Stef
On Oct 24, 2009, at 10:30 AM, Niko Schwarz wrote:
Hi all, I made a follow-up patch like discussed on the workshop.
Now
porting becomes as easy as changing asNumber to
squeezeOutNumber.
Name: SLICE-issue-1258-squeezeOutNumber-NikoSchwarz.2
This slice adds squeezeNumberOutOfString: to Number, as
discussed in
the Pharo workshop. On the way, it
fixes an issue in SqNumberParser, where it would return itself
rather
than the result of the failblack, when
parsing fails.
Also, a test is added to test and document the new squeezing
number
out of strings behavior.
Example usage:
self assert: '123blabla' squeezeOutNumber equals: 123.
self assert: 'blabla123' squeezeOutNumber equals: 123.
self assert: 'blabla12blabla' squeezeOutNumber equals: 12.
self assert: ('12.3bla' squeezeOutNumber -12.3 ) abs 0.0001.
self assert: '.1' squeezeOutNumber 0.
Cheers,
Niko
On Tue, Oct 20, 2009 at 2:14 PM, Adrian Lienhard a...@netstyle.ch
wrote:
10492 (this is the stream of the branch 1.0rc1)
-
- Issue 1320: [squeak trunk] Sort the conflicts. This is
required
when
merging a distant version, like Pharo for example...
- Issue 1338: HostWindowTeststestOne is failing in Windows
- Issue 1345: Revert Number classreadFrom: (was integrated
with
issue 1258)
___
http://www.adrian-lienhard.ch/
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-
project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] OCompletion in the rc1 dev image
Niko, What is the version of OCompletion in the image? I thought the fix in Ocompletion-RomainRobbes.36.mcz solved that issue. If you are indeed using that version, I'll have a look at your fix. Otherwise, it is just a matter of time before the latest version of OCompletion is used instead of the older one. Cheers, Romain On Oct 27, 2009, at 3:07 PM, Niko Schwarz wrote: Hi list, in the most recent dev image (9.10.5), OCompletion is broken for me. I lost my reproducible test case, but the gist was that sometimes when OCompletion had no idea which type a temporal variable would be, you were unable to insert code behind that variable, because if you tried, a debugger would show up. The problem appears to be DebuggerguessTypeForName:. debuggerMap can be nil and if it is, the method fails. I changed the method to the following, and then the strange errors that occur on my image disappear: guessTypeForName: aString | index object | index := debuggerMap ifNotNil: [(debuggerMap tempNamesForContext: self selectedContext) indexOf: aString ifAbsent: []]. object := index ifNil: [index := self receiver class allInstVarNames indexOf: aString ifAbsent: []. index ifNil: [^ nil]. self receiver instVarAt: index] ifNotNil: [self selectedContext tempAt: index]. ^ object class Essentially, I leave index at nil, if debugerMap is nil. I don't know enough about OCompletion to tell whether this is a fix, or makes things worse somehow. Cheers, Niko ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Romain Robbes http://www.inf.unisi.ch/phd/robbes ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [update] #10492 (1.0rc1)
may be you are right.
I do not know
so at least we should check all the users in the system
On Oct 27, 2009, at 3:13 PM, Niko Schwarz wrote:
Well, by doing that you will confuse users that only relied on the
consensual functionality of asNumber.
It's difficult both ways, and because of that, I'd suggest going the
lazy way and not helping the users other than by adding a comment to
#asNumber which explains the evolution of the message and points to
#squeezeOutNumber. I know that the users would appreciate help in the
migration, but I don't see a non-obtrusive way to do so.
Cheers,
Niko
On Tue, Oct 27, 2009 at 2:59 PM, Stéphane Ducasse
stephane.duca...@inria.fr wrote:
Not really
we could do the following
- check all the users of asNumber and let them as asNUmber or
squeezeOutNumber
- then put a deprecation during the alpha phase that state
that they
should pay attention
- when we are in rc 1.1 we remove the deprecation
- create a package which would override it with a deprecation.
stef
On Oct 27, 2009, at 2:38 PM, Niko Schwarz wrote:
Well, what do you propose? Deprecating asNumber calls altogether?
Cheers,
Niko
On Sat, Oct 24, 2009 at 10:32 AM, Stéphane Ducasse
stephane.duca...@inria.fr wrote:
Yes a good deprecation is needed.
Stef
On Oct 24, 2009, at 11:13 AM, Adrian Lienhard wrote:
Sounds ok. At the same time as integrating the change, all senders
of
asNumber in the image need to be checked and adapted to the new
semantics if necessary. IIRC MC was not properly working after the
change. Also, users and maintainers of external packages should be
made aware of the change since it may break their code.
Adrian
On Oct 24, 2009, at 10:46 , Stéphane Ducasse wrote:
Thanks niko
So does everybody agree with
asNumber raising an error
and
squeezeOutNumber
I like the proposal.
Stef
On Oct 24, 2009, at 10:30 AM, Niko Schwarz wrote:
Hi all, I made a follow-up patch like discussed on the workshop.
Now
porting becomes as easy as changing asNumber to
squeezeOutNumber.
Name: SLICE-issue-1258-squeezeOutNumber-NikoSchwarz.2
This slice adds squeezeNumberOutOfString: to Number, as
discussed in
the Pharo workshop. On the way, it
fixes an issue in SqNumberParser, where it would return itself
rather
than the result of the failblack, when
parsing fails.
Also, a test is added to test and document the new squeezing
number
out of strings behavior.
Example usage:
self assert: '123blabla' squeezeOutNumber equals: 123.
self assert: 'blabla123' squeezeOutNumber equals: 123.
self assert: 'blabla12blabla' squeezeOutNumber equals: 12.
self assert: ('12.3bla' squeezeOutNumber -12.3 ) abs
0.0001.
self assert: '.1' squeezeOutNumber 0.
Cheers,
Niko
On Tue, Oct 20, 2009 at 2:14 PM, Adrian Lienhard a...@netstyle.ch
wrote:
10492 (this is the stream of the branch 1.0rc1)
-
- Issue 1320: [squeak trunk] Sort the conflicts. This is
required
when
merging a distant version, like Pharo for example...
- Issue 1338: HostWindowTeststestOne is failing in Windows
- Issue 1345: Revert Number classreadFrom: (was integrated
with
issue 1258)
___
http://www.adrian-lienhard.ch/
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-
project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-
project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] *ServiceProvider classes??
Hello all, Something, perhaps SIF, is creating creating classes named *ServiceProvider in a new category named *. Any ideas? Bill ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] OCompletion in the rc1 dev image
My image is indeed still on version damiencassou.33. I marked the bug as 1.0 in the bugtracker (http://code.google.com/p/pharo/issues/detail?id=1351) hoping that it will be integrated in the next 1.0 dev image, as the image is hardly usable without the fix. Cheers, Niko On Tue, Oct 27, 2009 at 3:18 PM, Romain Robbes romain.rob...@lu.unisi.ch wrote: Niko, What is the version of OCompletion in the image? I thought the fix in Ocompletion-RomainRobbes.36.mcz solved that issue. If you are indeed using that version, I'll have a look at your fix. Otherwise, it is just a matter of time before the latest version of OCompletion is used instead of the older one. Cheers, Romain On Oct 27, 2009, at 3:07 PM, Niko Schwarz wrote: Hi list, in the most recent dev image (9.10.5), OCompletion is broken for me. I lost my reproducible test case, but the gist was that sometimes when OCompletion had no idea which type a temporal variable would be, you were unable to insert code behind that variable, because if you tried, a debugger would show up. The problem appears to be DebuggerguessTypeForName:. debuggerMap can be nil and if it is, the method fails. I changed the method to the following, and then the strange errors that occur on my image disappear: guessTypeForName: aString | index object | index := debuggerMap ifNotNil: [(debuggerMap tempNamesForContext: self selectedContext) indexOf: aString ifAbsent: []]. object := index ifNil: [index := self receiver class allInstVarNames indexOf: aString ifAbsent: []. index ifNil: [^ nil]. self receiver instVarAt: index] ifNotNil: [self selectedContext tempAt: index]. ^ object class Essentially, I leave index at nil, if debugerMap is nil. I don't know enough about OCompletion to tell whether this is a fix, or makes things worse somehow. Cheers, Niko ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Romain Robbes http://www.inf.unisi.ch/phd/robbes ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] OCompletion in the rc1 dev image
By the way, what is the proper way to propose changes to the dev image script? On Tue, Oct 27, 2009 at 3:57 PM, Niko Schwarz niko.schw...@googlemail.com wrote: My image is indeed still on version damiencassou.33. I marked the bug as 1.0 in the bugtracker (http://code.google.com/p/pharo/issues/detail?id=1351) hoping that it will be integrated in the next 1.0 dev image, as the image is hardly usable without the fix. Cheers, Niko On Tue, Oct 27, 2009 at 3:18 PM, Romain Robbes romain.rob...@lu.unisi.ch wrote: Niko, What is the version of OCompletion in the image? I thought the fix in Ocompletion-RomainRobbes.36.mcz solved that issue. If you are indeed using that version, I'll have a look at your fix. Otherwise, it is just a matter of time before the latest version of OCompletion is used instead of the older one. Cheers, Romain On Oct 27, 2009, at 3:07 PM, Niko Schwarz wrote: Hi list, in the most recent dev image (9.10.5), OCompletion is broken for me. I lost my reproducible test case, but the gist was that sometimes when OCompletion had no idea which type a temporal variable would be, you were unable to insert code behind that variable, because if you tried, a debugger would show up. The problem appears to be DebuggerguessTypeForName:. debuggerMap can be nil and if it is, the method fails. I changed the method to the following, and then the strange errors that occur on my image disappear: guessTypeForName: aString | index object | index := debuggerMap ifNotNil: [(debuggerMap tempNamesForContext: self selectedContext) indexOf: aString ifAbsent: []]. object := index ifNil: [index := self receiver class allInstVarNames indexOf: aString ifAbsent: []. index ifNil: [^ nil]. self receiver instVarAt: index] ifNotNil: [self selectedContext tempAt: index]. ^ object class Essentially, I leave index at nil, if debugerMap is nil. I don't know enough about OCompletion to tell whether this is a fix, or makes things worse somehow. Cheers, Niko ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Romain Robbes http://www.inf.unisi.ch/phd/robbes ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [SIXX] feedback
Masashi, Thanks for adding support for Pharo! So far, I have tried only the example from the workspace opened by the installation, but it was nice to see it work. Your timing was perfect, because I just encountered my first need for a serializer on Pharo. The download packaging and instructions are a little confusing. Under Installation, you say to file in install.st. The only mention of Pharo in the download section is next to the .sar file, which Pharo appears to load correctly. If the .sar is the intended way to load it, it should be mentioned in the Installation section. Thanks! Bill ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Making packages shipped with Pharo ready for 1.0
RB -- - undeclared reference to RBBasicLintRuleTest and RBTransformationRuleTest I take responsible for the AST and Refactoring packages. I believe these undeclared references have been fixed quite some time ago. See the attached dependency graph for details. Please make sure to take the latest code, the current Pharo distributions use outdated packages. I suggest that you do not load the separately packaged tests, some tests must fail because some parts of the refactoring engine are broken. It is getting better though, I already fixed over 40 tests and discovered and fixed many tests. Also some basic refactorings without reformatting the code are in reach. Use the following snipped to load the latest code: Gofer new squeaksource: 'rb'; addPackage: 'AST-Core'; addPackage: 'Refactoring-Core'; addPackage: 'Refactoring-Spelling'; load. OB -- - undeclared references: HttpResponse, Json, JsonObject It looks like the Pharo images contains OB-Web (the web view for OB), while all the prerequisites (Kom, Json) are not loaded. - #dropOnClass: references InputSensor (this class does not exist anymore!) That was fixed a long time ago. Lukas -- Lukas Renggli http://www.lukas-renggli.ch rb.pdf Description: Adobe PDF document ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Making packages shipped with Pharo ready for 1.0
2009/10/27 Adrian Lienhard a...@netstyle.ch: Pharo-core tests failing - FontTesttestFallback (assumes different font, to be removed) - FontTesttestParagraphFallback (assumes different font, to be removed) - FontTesttestResetAfterEmphasized (assumes different font, to be removed) - StandardSystemFontsTesttestRestoreDefaultFonts (assumes different font, to be removed) - TestIndentingtestNewLineStartsIndentedWhenWrapped (assumes different font, to be removed) - TestIndentingtestSetUp (assumes different font, to be removed) - LocaleTesttestIsFontAvailable (some Japanese font checking that fails with DejaVu, to be removed) - testFinalizationOfEquals (was on my to do list, but works again: remove expected failure tag) This remind me discussions with Norbert http://bugs.squeak.org/view.php?id=6347 and also http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-September/131654.html Nicolas - testObsoleteClasses: again includes classes from MC and others (have to be checked) MorphExamplesAndDemos - - undeclared references to DescriptionForPartsBin and ScreeningMorph Cheers, Adrian BTW, Damien, do we know for each package who the maintainer is? Does each package have one? ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Thread-safe collections
On 2009-10-26, at 10:37 PM, Igor Stasenko wrote: and why the key should go away? I think that this is an implementation nuance, but not bug or missing feature. No-one would expect from dictionary keys to automatically mutate depending on the state of the associated values. If you want such behavior, why not implement own WeakLookupTable ? Ok, well (a) I don't think any of the set or dictionary logic is particularly written with thread safety in mind. No doubt a Mutex is needed to protect the integrity of the data. Someone can decide which version of Pharo should a fix for 0006955 (b) Although as Igor mentioned the fact the key goes away is a implementation detail, this in fact is useful. The situation you run into is storing entities in a weak value dictionary where the values do disappear however if you store a million entries then you end up with a million keys, so who is responsible for the cleanup? -- = = = John M. McIntosh john...@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] OCompletion in the rc1 dev image
On Tue, Oct 27, 2009 at 4:00 PM, Niko Schwarz niko.schw...@googlemail.com wrote: By the way, what is the proper way to propose changes to the dev image script? Talk about them on the mailing list and add me on CC. Also, open an issue in the tracker and assign it to me. -- 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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Thread-safe collections
John, I'm not sure whether we agree or disagree on individual points, but that's ok. I will invoke Sig in the case of 10^6 entries - something tells me one would end up with a customized implementation long before a weak collection became that large. However, I think automatic cleanup is important to keep a long-lived map from getting that large. Bill -Original Message- From: pharo-project-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of John M McIntosh Sent: Tuesday, October 27, 2009 12:27 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Thread-safe collections On 2009-10-26, at 10:37 PM, Igor Stasenko wrote: and why the key should go away? I think that this is an implementation nuance, but not bug or missing feature. No-one would expect from dictionary keys to automatically mutate depending on the state of the associated values. If you want such behavior, why not implement own WeakLookupTable ? Ok, well (a) I don't think any of the set or dictionary logic is particularly written with thread safety in mind. No doubt a Mutex is needed to protect the integrity of the data. Someone can decide which version of Pharo should a fix for 0006955 (b) Although as Igor mentioned the fact the key goes away is a implementation detail, this in fact is useful. The situation you run into is storing entities in a weak value dictionary where the values do disappear however if you store a million entries then you end up with a million keys, so who is responsible for the cleanup? -- = = = John M. McIntosh john...@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] OCompletion in the rc1 dev image
say it on the mailing-list and damien takes into account the result. Stef By the way, what is the proper way to propose changes to the dev image script? On Tue, Oct 27, 2009 at 3:57 PM, Niko Schwarz niko.schw...@googlemail.com wrote: My image is indeed still on version damiencassou.33. I marked the bug as 1.0 in the bugtracker (http://code.google.com/p/pharo/issues/detail?id=1351) hoping that it will be integrated in the next 1.0 dev image, as the image is hardly usable without the fix. Cheers, Niko On Tue, Oct 27, 2009 at 3:18 PM, Romain Robbes romain.rob...@lu.unisi.ch wrote: Niko, What is the version of OCompletion in the image? I thought the fix in Ocompletion-RomainRobbes.36.mcz solved that issue. If you are indeed using that version, I'll have a look at your fix. Otherwise, it is just a matter of time before the latest version of OCompletion is used instead of the older one. Cheers, Romain On Oct 27, 2009, at 3:07 PM, Niko Schwarz wrote: Hi list, in the most recent dev image (9.10.5), OCompletion is broken for me. I lost my reproducible test case, but the gist was that sometimes when OCompletion had no idea which type a temporal variable would be, you were unable to insert code behind that variable, because if you tried, a debugger would show up. The problem appears to be DebuggerguessTypeForName:. debuggerMap can be nil and if it is, the method fails. I changed the method to the following, and then the strange errors that occur on my image disappear: guessTypeForName: aString | index object | index := debuggerMap ifNotNil: [(debuggerMap tempNamesForContext: self selectedContext) indexOf: aString ifAbsent: []]. object := index ifNil: [index := self receiver class allInstVarNames indexOf: aString ifAbsent: []. index ifNil: [^ nil]. self receiver instVarAt: index] ifNotNil: [self selectedContext tempAt: index]. ^ object class Essentially, I leave index at nil, if debugerMap is nil. I don't know enough about OCompletion to tell whether this is a fix, or makes things worse somehow. Cheers, Niko ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Romain Robbes http://www.inf.unisi.ch/phd/robbes ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Making packages shipped with Pharo ready for 1.0
Adrian I will have a look at Nile with cyrille and else we remove it from 1.0 (which would be a pity). Stef On Oct 27, 2009, at 5:04 PM, Adrian Lienhard wrote: Hi, I've more closely looked at the failing tests and undeclared references in the Pharo image. The test result is 14 expected failures, 34 failures, 54 errors, 2 unexpected passes. Considering that the Pharo-core ships with all tests green, this situation needs to be fixed. I urge the package maintainers to closely look at the list below and provide fixes and cleanups of their code. There are also 9 tests failing from Pharo-core. I will take care of those. Nil - - Sends deprecated message: #findLastOccuranceOfString:startingAt: - A test opens a workspace that says: Squeak is a beautiful language. Look at http:\\www.squeak.org ... - Another test opens another workspace - NSBuffer has method that references an undeclared variable 'collection' - undeclared reference to GradientFillMorph, StringSocketStream - Total failing tests: 10 - Total tests with errors: 11 ECompleteion - 7 tests failing - 2 errors O2 -- - #dropOnClass: references InputSensor (this class does not exist anymore!) - 15 undeclared references to OB* classes, to non-existent variable hasChanges, modifiedTimeStamp, smartGroup, and sensor - 11 failing tests - 30 tests with errors OB -- - undeclared references: HttpResponse, Json, JsonObject - #dropOnClass: references InputSensor (this class does not exist anymore!) NewInspector - undeclared reference automaticallyHideIfNoChild - NewInspector DNU #inspect (sent in #testSymbolTableM6812) Shout - - undeclared variable sourceMap RB -- - undeclared reference to RBBasicLintRuleTest and RBTransformationRuleTest Pharo-core tests failing - FontTesttestFallback (assumes different font, to be removed) - FontTesttestParagraphFallback (assumes different font, to be removed) - FontTesttestResetAfterEmphasized (assumes different font, to be removed) - StandardSystemFontsTesttestRestoreDefaultFonts (assumes different font, to be removed) - TestIndentingtestNewLineStartsIndentedWhenWrapped (assumes different font, to be removed) - TestIndentingtestSetUp (assumes different font, to be removed) - LocaleTesttestIsFontAvailable (some Japanese font checking that fails with DejaVu, to be removed) - testFinalizationOfEquals (was on my to do list, but works again: remove expected failure tag) - testObsoleteClasses: again includes classes from MC and others (have to be checked) MorphExamplesAndDemos - - undeclared references to DescriptionForPartsBin and ScreeningMorph Cheers, Adrian BTW, Damien, do we know for each package who the maintainer is? Does each package have one? ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Strange behavior of #printString method
I don´t understand the behavior of printString method.
in a class I define a method #style , which returns an array...
style
style notNil ifTrue:[ ^style ]
ifFalse:[ ^{ self borderColor . self
borderWidth . self color . self
gradientColor . (self cornerStyle = #rounded) . true }].
That method returns many times an Array. If #printString of that array is
called the result is...
'{Color black. 0. (Color r: 0.892 g: 0.887 b: 0.879). nil. false. true}'
Well i have another method with same name in another class
style
^{ self borderColor . self borderWidth . self color . self
gradientColor .
(self cornerStyle = #rounded) . true }
but in that case when i call #printString of the Array result ...
'an Array(Color transparent 0 (Color r: 0.827 g: 0.827 b: 0.827) nil true
true)'.
I don´t understand nothing :| Both are instances of Array, and both is
declared of same way.
Regards
--
View this message in context:
http://n2.nabble.com/Strange-behavior-of-printString-method-tp3902051p3902051.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Strange behavior of #printString method
I am by no means the expert on such things, but you caught my attention and a
quick look at ArrayprintOn: reveals #isLiteral and #isSelfEvaluating. The
way an array prints itself changes if all of the arguments (and sometimes the
receiver) fit the conditions.
One of your arguments is probably failing to meet a condition in one case.
Bill
-Original Message-
From: pharo-project-boun...@lists.gforge.inria.fr
[mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of nullPointer
Sent: Tuesday, October 27, 2009 4:58 PM
To: pharo-project@lists.gforge.inria.fr
Subject: [Pharo-project] Strange behavior of #printString method
I don´t understand the behavior of printString method.
in a class I define a method #style , which returns an array...
style
style notNil ifTrue:[ ^style ]
ifFalse:[ ^{ self borderColor . self
borderWidth . self color . self gradientColor . (self cornerStyle = #rounded) .
true }].
That method returns many times an Array. If #printString of that array is
called the result is...
'{Color black. 0. (Color r: 0.892 g: 0.887 b: 0.879). nil. false. true}'
Well i have another method with same name in another class
style
^{ self borderColor . self borderWidth . self color . self
gradientColor .
(self cornerStyle = #rounded) . true }
but in that case when i call #printString of the Array result ...
'an Array(Color transparent 0 (Color r: 0.827 g: 0.827 b: 0.827) nil true
true)'.
I don´t understand nothing :| Both are instances of Array, and both is
declared of same way.
Regards
--
View this message in context:
http://n2.nabble.com/Strange-behavior-of-printString-method-tp3902051p3902051.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Making packages shipped with Pharo ready for 1.0
On Oct 27, 2009, at 10:45 PM, Schwab,Wilhelm K wrote: Stef, I do not yet use Nile, but after learning a little more about the existing file streams, my first thought was Nile is installed, right? It would be a shame to see it removed. Yes but we should fix the tests. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Strange behavior of #printString method
The problem is in the Transparent color element of the my bad array.
Transparent color class implements #isSelfEvaluating of that way...
isSelfEvaluating
^ self class == Color
That condition dont works in the first element of my bad array.
Regards, and thanks for the help :|
2009/10/27 Stéphane Ducasse [via Smalltalk]
ml-node+3902115-101729...@n2.nabble.comml-node%2b3902115-101729...@n2.nabble.com
Apparently you find a problem in self evaluating on color or related.
Let me explain:
The idea of printing an object is that in some case
anObject printString let you recreate the object
example
1
true
#(1)
#(1 2)
1...@50
this means that either you get the same object or when you executed
its printed representation you get it back.
This is handy when playing with an inspector or in a workspace
now for array if you get an array of points in the past
printing it would return
#(10 #@ 50 20 #@ 50)
which is different from what is was really
{...@50 . 2...@50}
or Array new: 2 at:1 put: 1...@50 ; at:2 put: 2...@50
So when an object is selfevaluating it measn that its printed
representation can be used to recreate it
When an array contains only self evaluating objects then it is printed
with { } since it can also be recreated
now if you get an object inside an array taht is not self evaluating
then your collection cannot be self evaluating.
so we say it anarray of ... instead of a #( 10 # @ 20)
But in your case something went wrong because color and others are
self evaluating.
could you provide with a snippet of code that we can check where the
problem is coming from?
Stef
On Oct 27, 2009, at 10:58 PM, nullPointer wrote:
I don´t understand the behavior of printString method.
in a class I define a method #style , which returns an array...
style
style notNil ifTrue:[ ^style ]
ifFalse:[ ^{ self borderColor . self borderWidth . self color .
self
gradientColor . (self cornerStyle = #rounded) . true }].
That method returns many times an Array. If #printString of that
array is
called the result is...
'{Color black. 0. (Color r: 0.892 g: 0.887 b: 0.879). nil. false.
true}'
Well i have another method with same name in another class
style
^{ self borderColor . self borderWidth . self color . self
gradientColor .
(self cornerStyle = #rounded) . true }
but in that case when i call #printString of the Array result ...
'an Array(Color transparent 0 (Color r: 0.827 g: 0.827 b: 0.827) nil
true
true)'.
I don´t understand nothing :| Both are instances of Array, and both
is
declared of same way.
Regards
--
View this message in context:
http://n2.nabble.com/Strange-behavior-of-printString-method-tp3902051p3902051.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
___
Pharo-project mailing list
[hidden
email]http://n2.nabble.com/user/SendEmail.jtp?type=nodenode=3902115i=0
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
[hidden
email]http://n2.nabble.com/user/SendEmail.jtp?type=nodenode=3902115i=1
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
View message @
http://n2.nabble.com/Strange-behavior-of-printString-method-tp3902051p3902115.html
To unsubscribe from Strange behavior of #printString method, click here
(link removed) .
--
View this message in context:
http://n2.nabble.com/Strange-behavior-of-printString-method-tp3902051p3902316.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Linux FFI question: library given function name?
Hello all, In the short term, I'm looking for where I might find syslog() and friends, but a fishing lesson would be even better. How does one figure out in which library a named function lives? Bill ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
