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

[Pharo-project] Very strange behavior with MC

by Alexandre Bergel

Dear all, I just save a new version in PharoInbox, but this version appears to be empty. I checked on squeaksource [*]. In Pharo, it seems that two files are being saved (.143(142).mcd and . 143.mcz) [**]. when I browse .143(142).mcd I see all the content (probably because it is local to my machine). When I browse .143.mcz it is empty. What this .mcd file is about? I am not the only one to experience this. Anyone had an idea what's going on? I haven't closely followed the list of changes that were included in Pharo. Alexandre [*] http://bergel.eu/EmptyVersion.png [**] http://bergel.eu/TwoSavedVersions.png -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 6, 2009

Re: [Pharo-project] Next Issue ;-)

by Bill Schwab

I saw some similar goofiness at one point, but do not recall whether it was related to cryptography. I am interested in it and the SSL classes. I managed to install same at one point, but it is no longer clear how I did it. Mining the change log of the most recent image where it works (I have one) and/or searching my email exchanges with Ron might help. The idea being to figure out when it worked and then look for special instructions that I might have followed. Gary, it would be nice to have your mutex fix in Pharo. One of the first things I would hope to get working on Pharo is very multi-process oriented, and a reliable #adddeferredUIMessage: would be most helpful. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029 >>> gazzaguru2(a)btinternet.com 01/06/09 7:22 AM >>> That is normally a symptom of something updating the World morphs in a non-UI process. Morphs should only be changed from the UI process otherwise all kind of inconsistencies can happen. WorldState addDeferredUIMessage: can be used top safely perform actions but, for some applications, finer control is needed. We have developed Squeak applications that are of necessity multi-process driven and were forced to modify WorldState to allow (mutex based) synchronisation with the event loop, thus avoiding the issues. Regards, Gary. ----- Original Message ----- From: "Brian Brown" <brian(a)ablelinktech.com> To: "An open mailing list to discuss any topics related to an open-sourceSmalltalk" <Pharo-project(a)lists.gforge.inria.fr> Sent: Monday, January 05, 2009 10:26 PM Subject: [Pharo-project] Next Issue ;-) > I'm trying to load cryptography 1.1 from the Universe browser. > Everything seems to go well, and the dialog completes and exits. > Immediately following that, whenever the mouse moves over any morphs, > you get the below traceback. the ivars leftMorphs, enteredMorphs, and > overMorphs are all nil, but are being treated as collections... > > > UndefinedObject(Object)>>doesNotUnderstand: #includes: > MouseOverHandler>>noticeMouseOver:event: > HandMorph>>noticeMouseOver:event: > OBTextMorphWithShout(Morph)>>handleMouseOver: > MouseEvent>>sentTo: > OBTextMorphWithShout(Morph)>>handleEvent: > MorphicEventDispatcher>>dispatchDefault:with: > MorphicEventDispatcher>>dispatchEvent:with: > OBTextMorphWithShout(Morph)>>processEvent:using: > MorphicEventDispatcher>>dispatchDefault:with: > MorphicEventDispatcher>>dispatchEvent:with: > TransformMorph(Morph)>>processEvent:using: > MorphicEventDispatcher>>dispatchDefault:with: > MorphicEventDispatcher>>dispatchEvent:with: > OBPluggableTextMorphWithShout(Morph)>>processEvent:using: > MorphicEventDispatcher>>dispatchDefault:with: > MorphicEventDispatcher>>dispatchEvent:with: > OBGroupingMorph(Morph)>>processEvent:using: > MorphicEventDispatcher>>dispatchDefault:with: > MorphicEventDispatcher>>dispatchEvent:with: > SystemWindow(Morph)>>processEvent:using: > MorphicEventDispatcher>>dispatchDefault:with: > MorphicEventDispatcher>>dispatchEvent:with: > PasteUpMorph(Morph)>>processEvent:using: > PasteUpMorph>>processEvent:using: > PasteUpMorph(Morph)>>processEvent: > HandMorph>>sendEvent:focus:clear: > HandMorph>>sendMouseEvent: > HandMorph>>handleEvent: > MouseOverHandler>>processMouseOver: > HandMorph>>handleEvent: > HandMorph>>processEvents > [] in WorldState>>doOneCycleNowFor: {[:h | ActiveHand := h. h > processEvents. ActiveHand := nil]} > Array(SequenceableCollection)>>do: > WorldState>>handsDo: > WorldState>>doOneCycleNowFor: > WorldState>>doOneCycleFor: > PasteUpMorph>>doOneCycle > [] in Project class>>spawnNewProcess {[[World doOneCycle. Processor > yield. false] whileFalse. nil]} > [] in BlockContext>>newProcess {[self value. Processor > terminateActive]} > > > > _______________________________________________ > 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

Jan. 6, 2009

Re: [Pharo-project] Underscores question

by Bill Schwab

Gwenael, This might be it. I thought there was a little more to it, but c_a call: b. and the interpretations (number list) might be what I was remembering; I thought it were a few other concrete examples. There are other parts of the thread that seem very familar. My own take is that the default should be to treat underscores as a letter, and to allow file-in of code with underscore assignment as an option. That helps with external interfacing, cross-dialect compatibility, and retains access to existing/older code. I do not like Burt's idea of a class method #allowUnderscores, because (I think??) it assumes _ will not appear in class names, which would be very helpful in mapping external names to classes. However, a global variable could work. However, I still see underscore assignment as something that should be supported only when filing in code that uses it. Sorry I didn't find more. Bill ============================ Gmane From: Bert Freudenberg <bert <at> impara.de> Subject: Underscores in Identifiers (was: Re: Random and unsolicited feedback on 3.9a) Newsgroups: gmane.comp.lang.smalltalk.squeak.general Date: 2005-11-19 10:58:23 GMT (3 years, 6 weeks, 6 days, 10 hours and 10 minutes ago) When dealing with low_level_code, I'd love to have underscores in identifiers - not even just method names, but for variables, too. This could probably be achieved simply by using a different type table with $_ being an #xLetter in Scanner (not sure about the SmaCC- based Compiler). However, I would also strongly suggest *not* to allow this as a standard. Apart from breaking old code file-ins, we would soon get tons of unreadable gibberish by C-trained newbies ;-) Instead, when filing in, the compiler would interpret underscores as assignment, just as it is now. *Only* if specifically enabled by the filed-in code would it be switched to allow underscores in identifiers. Same goes for normal development - *unless* a class answer true when asked #allowUnderscoresInIdentifiers, underscores are compiled as assignments. The file-out code would take that into account to generate the code snippet enabling underscores in identifiers needed for later file-in. How does that sound? - Bert - Am 19.11.2005 um 01:39 schrieb Andreas Raab: > Can we please consider the consequences of doing that (like > potentially breaking lots of code from fileIns) and how we are > going to deal with it *before* such a change gets included? I would > hate it to have another one of those situations where things break > for absolutely no good reason. > > Cheers, > - Andreas ============================ Gmane From: Andreas Raab <andreas.raab <at> gmx.de> Subject: Re: 3.9 underscore still there? Newsgroups: gmane.comp.lang.smalltalk.squeak.general Date: 2006-10-30 20:18:13 GMT (2 years, 9 weeks, 5 days, 6 hours and 46 minutes ago) Bill Schwab wrote: > My preference would be for ANSI compatibility. With that said, having > underscored in selectors, and even just all but the first slot, would do > almost everying I need. I doubt I use them in variable names, and if I > do, I could change it. If I were to move my production code to Squeak, > I would be editing a lot more than a few variable names. Most of uses > of underscores are matching the outside world, and that is not so > readily altered to suit my whim or Squeak's limitations. If all you want to do is to get your code going in Squeak, a fairly simple alternative is to subclass the current parser/compiler, apply Ian's patch and use those for loading your own classes. It ain't exactly a great solution but may be helpful in the short term. > If we can get > Ian's fix in the mainstream, it would be greatly appreciated. This is one of these situations where a little more thought is in order because there are both short-term and long-term implications. Consider an example like this: c_a call: b. Depending on the interpretation of underscore we have 3 possibilities: 1) Underscore means assignment: The above is a legal expression. 2) Underscore is a letter: The above is a legal, too. 3) Underscore is a letter in selectors except if first, and invalid for variable names: The above is illegal. So in two out of three interpretations the above is legal, only in the last one it is not. What troubles me here is that while it may be an okay solution in the short term to put the burden on the user of the underscore (e.g., basically saying "if you use underscores you need to understand where exactly you can use them and where not") the inconsistency and complexity inherent in the description that "underscores are treated as letters in selectors unless they are the first character and cannot be used in variable names" strikes me as a *very* poor choice in the long term. I'd rather do something where (based on some meta-annotations) the parser can decide whether to to treat underscores as assignments or as letters and possibly rewrite them on the fly. The essential idea being that legacy code (using underscore as assignments) can still be loaded into a later version. Cheers, - Andreas Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029

Jan. 6, 2009

[Pharo-project] Fwd: [ANN] 10202

by StÃ©phane Ducasse

> > From: stephane ducasse <stephane.ducasse(a)free.fr> > Date: January 6, 2009 3:24:29 PM CEST > To: Pharo Development <Pharo-project(a)lists.gforge.inria.fr> > Subject: [ANN] 10202 > > > - More test in DictionaryTest. The class Dictionary is now covered > at 66% > - Issue 433: TPureBehavior>>traits to get a collection of used traits. > - Issue 226: Resize comment pane in Monticello browser > - Issue 426: Code coverage > - Collection extension: groupedBy, flatCollect:, collectAsSet:, > should remove sixx as package > > Stef > > >

Jan. 6, 2009

Re: [Pharo-project] DictionaryTest

by Alexandre Bergel

Yes, all the tests of 136 were properly packaged in 142. Alexandre On 6 Jan 2009, at 11:16, StÃ©phane Ducasse wrote: > in PharoTreated > > > On Jan 6, 2009, at 2:54 PM, Alexandre Bergel wrote: > >> Probably, but I do not see where 136 is. In Pharo@squeaksource the >> last version is CollectionsTests-stephane_ducasse.ducasse.135 >> In PharoInbox, it is mine ( CollectionsTests-AlexandreBergel.142). >> >> Alexandre >> >> >> On 5 Jan 2009, at 17:43, StÃ©phane Ducasse wrote: >> >>> Alex >>> >>> are the sorted and changes that were in 136 included in the new >>> ones? >>> >>> Stef >>> >>> On Jan 5, 2009, at 6:27 PM, Alexandre Bergel wrote: >>> >>>> MC behaved strangely. >>>> >>>> I produced a new version: >>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>>> Name: CollectionsTests-AlexandreBergel.142 >>>> Author: AlexandreBergel >>>> Time: 5 January 2009, 2:24:21 pm >>>> UUID: 0e32b9b7-708d-4c01-913a-2a07c9319ac7 >>>> Ancestors: CollectionsTests-AlexandreBergel.141 >>>> >>>> More test in DictionaryTest. The class Dictionary is now covered at >>>> 66% >>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>>> >>>> I checked, and it is not empty >>>> >>>> Alexandre >>>> >>>> On 5 Jan 2009, at 13:14, StÃ©phane Ducasse wrote: >>>> >>>>> Alex >>>>> >>>>> I do not really understand since 139, 138 are also empty when I >>>>> browse >>>>> them via the squeaksource web ui >>>>> I can move everything to treated and you republish the package. >>>>> I really want to see this code can you send to me a package via >>>>> email? >>>>> >>>>> Stef >>>>> >>>>> On Jan 5, 2009, at 3:58 PM, Lukas Renggli wrote: >>>>> >>>>>>> If I browse the file CollectionsTests-AlexandreBergel.140 within >>>>>>> Squeak stored on PharoInbox, I see the content. If I go on >>>>>>> squeaksource, and look the content of the version that I saved, >>>>>>> it >>>>>>> is >>>>>>> empty. I tried to save CollectionTests, but the content is >>>>>>> empty. >>>>>>> Any >>>>>>> hint? >>>>>> >>>>>> The Pharo image uses the cache in memory or on your file-system >>>>>> to >>>>>> display mcz files you recently committed. You should ask an >>>>>> administrator of the PharoInbox to delete the defective version >>>>>> from >>>>>> the repository and try to copy your local version to >>>>>> squeaksource.com >>>>>> again. >>>>>> >>>>>> Lukas >>>>>> >>>>>> -- >>>>>> Lukas Renggli >>>>>> http://www.lukas-renggli.ch >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 6, 2009

Re: [Pharo-project] DictionaryTest

by StÃ©phane Ducasse

in PharoTreated On Jan 6, 2009, at 2:54 PM, Alexandre Bergel wrote: > Probably, but I do not see where 136 is. In Pharo@squeaksource the > last version is CollectionsTests-stephane_ducasse.ducasse.135 > In PharoInbox, it is mine ( CollectionsTests-AlexandreBergel.142). > > Alexandre > > > On 5 Jan 2009, at 17:43, StÃ©phane Ducasse wrote: > >> Alex >> >> are the sorted and changes that were in 136 included in the new ones? >> >> Stef >> >> On Jan 5, 2009, at 6:27 PM, Alexandre Bergel wrote: >> >>> MC behaved strangely. >>> >>> I produced a new version: >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>> Name: CollectionsTests-AlexandreBergel.142 >>> Author: AlexandreBergel >>> Time: 5 January 2009, 2:24:21 pm >>> UUID: 0e32b9b7-708d-4c01-913a-2a07c9319ac7 >>> Ancestors: CollectionsTests-AlexandreBergel.141 >>> >>> More test in DictionaryTest. The class Dictionary is now covered at >>> 66% >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>> >>> I checked, and it is not empty >>> >>> Alexandre >>> >>> On 5 Jan 2009, at 13:14, StÃ©phane Ducasse wrote: >>> >>>> Alex >>>> >>>> I do not really understand since 139, 138 are also empty when I >>>> browse >>>> them via the squeaksource web ui >>>> I can move everything to treated and you republish the package. >>>> I really want to see this code can you send to me a package via >>>> email? >>>> >>>> Stef >>>> >>>> On Jan 5, 2009, at 3:58 PM, Lukas Renggli wrote: >>>> >>>>>> If I browse the file CollectionsTests-AlexandreBergel.140 within >>>>>> Squeak stored on PharoInbox, I see the content. If I go on >>>>>> squeaksource, and look the content of the version that I saved, >>>>>> it >>>>>> is >>>>>> empty. I tried to save CollectionTests, but the content is empty. >>>>>> Any >>>>>> hint? >>>>> >>>>> The Pharo image uses the cache in memory or on your file-system to >>>>> display mcz files you recently committed. You should ask an >>>>> administrator of the PharoInbox to delete the defective version >>>>> from >>>>> the repository and try to copy your local version to >>>>> squeaksource.com >>>>> again. >>>>> >>>>> Lukas >>>>> >>>>> -- >>>>> Lukas Renggli >>>>> http://www.lukas-renggli.ch >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 6, 2009

Re: [Pharo-project] Fwd: [ANN] Number comparison, hash, NaN, Point, and other partially ordered sets

by Alexandre Bergel

Thanks Nicolas, You made really good points! Alexandre On 5 Jan 2009, at 15:38, nicolas cellier wrote: > StÃ©phane Ducasse <stephane.ducasse@...> writes: > >> >> Nicolas >> >> could you summarize your solution? >> >> Stef >> >> On Jan 5, 2009, at 12:55 AM, nicolas cellier wrote: >> > > Here is the summary: > > 1) equality relation is not transitive due to inexact asFloat > conversion > > example: > (1/2) = 0.5. "This is exact" > (1/2) + (1/(2 raisedTo: 100)) = 0.5. "This is an inexact conversion" > (1/2) + (1/(2 raisedTo: 100)) ~= (1/2). "If equal where transitive, > they > should be equal" > > Solution: base comparison on inexact->exact conversions rather than > the > contrary... > inexact->exact is called #asTrueFraction (#asExactFraction in GNU > Smalltalk). > > This solution is known from the wise lispers for so long... > http://www.lispworks.com/documentation/lcl50/aug/aug-170.html > This is http://bugs.squeak.org/view.php?id=3374 > > 2) Some numbers are equal, but have different hash codes > > Since some Float can equal some Integer or Fraction, it is necessary > to > change at least 2 out of 3 hash implementations. > > Solution I retained: > - preserve Integer hash > - change Float hash if they have a fractionPart = 0.0 (they are > equal to > anInteger) > - change Fraction hash if they could be equal to a Float (I only test > that denominator is a power of two, which is a necessary but not a > sufficient condition). > > This is http://bugs.squeak.org/view.php?id=6601, and > http://bugs.squeak.org/view.php?id=3360, solution has been posted at > #3374. > > Note: this results in loosing a little speed for small Float hash, and > lot more for large Float hash. > But make it right > make it fast... > > 3) Comparing Float nan to a Float or an Integer does not follow IEEE > 754 > conventions > comparison should always return false since nan cannot be ordered. > > Magnitude assume subInstances form a totally ordered set. > Thus Number is not a well behaved Magnitude. > > Consequently, Number must define not only < but also <= >= and > > Note that only < and <= would be strictly necessary. > The other two could be defined like this: >> b > ^b < self >> = b > ^b <= self > > I choose to change >= implementation in Magnitude, and reimplement > everything in Number subclasses > (though > and >= would not be strictly necessary). > > This is http://bugs.squeak.org/view.php?id=6719 > > But the VM also makes same assumption as Magnitude and must be changed > too - this is http://bugs.squeak.org/view.php?id=7260 > > 4) Comparing a Number and a Point is weird (different result with an > Integer and a Float) > > Float did coerce to a Point, then compare. > Integer did use a false total order assumption through super > Magnitude. > > Two main solutions: > - either coerce Number to a Point (might be implicitely used this > way in > the image... hard to tell). > - or raise an Exception > > Solution: I choosed to raise an Exception. > > This is http://bugs.squeak.org/view.php?id=7259 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 6, 2009

Re: [Pharo-project] Collection extensions

by Alexandre Bergel

Maybe the solution is to have a downloadable package >> >> Why can't we tag the methods with <notAnsi> and build a tool that >> check when you do a fill out. > > The problem is that such message sends can't be reliably detected > statically. You're right, but a fairly good approximation can be made. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 6, 2009

Re: [Pharo-project] DictionaryTest

by Alexandre Bergel

Probably, but I do not see where 136 is. In Pharo@squeaksource the last version is CollectionsTests-stephane_ducasse.ducasse.135 In PharoInbox, it is mine ( CollectionsTests-AlexandreBergel.142). Alexandre On 5 Jan 2009, at 17:43, StÃ©phane Ducasse wrote: > Alex > > are the sorted and changes that were in 136 included in the new ones? > > Stef > > On Jan 5, 2009, at 6:27 PM, Alexandre Bergel wrote: > >> MC behaved strangely. >> >> I produced a new version: >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> Name: CollectionsTests-AlexandreBergel.142 >> Author: AlexandreBergel >> Time: 5 January 2009, 2:24:21 pm >> UUID: 0e32b9b7-708d-4c01-913a-2a07c9319ac7 >> Ancestors: CollectionsTests-AlexandreBergel.141 >> >> More test in DictionaryTest. The class Dictionary is now covered at >> 66% >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> >> I checked, and it is not empty >> >> Alexandre >> >> On 5 Jan 2009, at 13:14, StÃ©phane Ducasse wrote: >> >>> Alex >>> >>> I do not really understand since 139, 138 are also empty when I >>> browse >>> them via the squeaksource web ui >>> I can move everything to treated and you republish the package. >>> I really want to see this code can you send to me a package via >>> email? >>> >>> Stef >>> >>> On Jan 5, 2009, at 3:58 PM, Lukas Renggli wrote: >>> >>>>> If I browse the file CollectionsTests-AlexandreBergel.140 within >>>>> Squeak stored on PharoInbox, I see the content. If I go on >>>>> squeaksource, and look the content of the version that I saved, it >>>>> is >>>>> empty. I tried to save CollectionTests, but the content is empty. >>>>> Any >>>>> hint? >>>> >>>> The Pharo image uses the cache in memory or on your file-system to >>>> display mcz files you recently committed. You should ask an >>>> administrator of the PharoInbox to delete the defective version >>>> from >>>> the repository and try to copy your local version to >>>> squeaksource.com >>>> again. >>>> >>>> Lukas >>>> >>>> -- >>>> Lukas Renggli >>>> http://www.lukas-renggli.ch >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 6, 2009

Re: [Pharo-project] Underscores question

by Bill Schwab

Gwenael, Is the plan to do this for 1.0? Have you considered a flag for _ assignment? It seems like something that would be most useful on file-in, unless you think you can make it all work at the same time. Shortly after m17n gained acceptance, I re-raised the question of whether _ really needed a special status. Andreas argued for the status quo, but did so with some interesting examples. I can't do it this minute (will try later today unless you are already have read it), but it might be interesting to search for that exchange and consider his examples for your tests. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029 >>> mrgwen(a)gmail.com 01/06/09 4:50 AM >>> On Tuesday 06 January 2009 09:54:56 Lukas Renggli wrote: > > This is not yet integrated > > I assume a change like that will affect many different places. Is > there a list of things that remain to be fixed (Debugger, > RefactoringBrowser, Method Finder, ...). > > Lukas Yes, I don't have the list but I will publish the list on the mailing list before any public release and off course I'll publish the fix. Gwenael _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 6, 2009