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

Re: [Pharo-project] self halt

by Hilaire Fernandes

http://code.google.com/p/pharo/issues/detail?id=2088 StÃ©phane Ducasse a Ã©crit : > which update? > > On Feb 27, 2010, at 11:25 AM, Hilaire Fernandes wrote: > >> On a updated pharo 1.1 image, a "self halt" block the image. >> The debugger is raised but the UI is frozen. >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 27, 2010

Re: [Pharo-project] Quasi-stateful traits?

by Stan Shepherd

Igor Stasenko wrote: > > > Traits can be reformulated to be purely a method source holders, not > holders of compiled methods. > (And btw, this is actually true, due to the latest changes in traits, > because of super sends issues and #methodClass) > OK, so that explains why they can currently be used as if they are stateful. > , we only need to push it a little further and get rid of > useless limitations. > > The point is, that all trait methods should _always_ be compiled in > the scope of the class to which it applied. > Because, for any variable name, which not declared explicitly in the > method's scope, we can't tell anything about it, > until we apply this method to the real class (See the Class>>bindingOf: ) > This means that, even if you having the trait method: > > foo > ^ Array new: 10 > > the binding of 'Array' variable may be different, depending on class > where its installed. > To check it, you can try following at home: > > Object subclass: #ZZZZ > instanceVariableNames: '' > classVariableNames: 'DD' > poolDictionaries: '' > category: 'ZZZZ' > > "add new pool variable" > ZZZZ classPool at: #Array put: 10. > > "now add the method" > array > ^ Array > > and now evaluate the following: > ZZZZ new array > > ------------- > But what makes > array > ^ Array > > method any better than > > array > ^ array := 10. > > in this regard? > > Nothing. So, why not drop the limitation, and instead of punishing > developer for use undeclared vars in trait methods, > punish him for use of undeclared variables, when he tries to apply the > trait to concrete class, where all such var names should obtain > meaning? > > Then, ultimately, what is the point in storing compiling methods in > Trait (not for classes, where it applied). We could just check the > syntax, but should not produce any CompiledMethod instances at all. > > What other problems i don't see here? > The merged OB/O2 case still passes a full system test, so I didn't run into any show-stoppers. Traits that work this way, supported by the tools, would appear to make them applicable to a lot more cases. ...Stan > On 27 February 2010 02:10, Stan Shepherd <stan.shepherd414(a)gmail.com> > wrote: >> >> >> Igor Stasenko wrote: >>> >>> One of the ways of introducing a stateful traits is changing the VM >>> object format. >>> >> Sounds like it could be very powerful. >> >> As it happens, in the fork healing example, it's the very statelessness >> of >> the traits that make it work so simply. By taking out the Â check for >> statefulness when the method is moved to a trait, the trait will quite >> happily address the several variables in its user classes. This then >> removes >> any need for accessors, helper classes for state, initialization, or >> other >> attempts to tame the beast. >> >> I wouldn't want to rely on it continuing to work in all conditions, but >> as a >> step in a refactoring it seems very handy. >> >> ..Stan >> -- >> View this message in context: >> http://n4.nabble.com/Quasi-stateful-traits-tp1571120p1571553.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- View this message in context: http://n4.nabble.com/Quasi-stateful-traits-tp1571120p1571899.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 27, 2010

Re: [Pharo-project] self halt

by StÃ©phane Ducasse

which update? On Feb 27, 2010, at 11:25 AM, Hilaire Fernandes wrote: > On a updated pharo 1.1 image, a "self halt" block the image. > The debugger is raised but the UI is frozen. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 27, 2010

Re: [Pharo-project] Simple (but effective) Optimization of PackageOrganizer

by Serge Stinckwich

I see that a big earthquake hit Chile : http://www.alertnet.org/thenews/newsdesk/LDE61Q02O.htm I hope everything is ok with you. On Fri, Feb 26, 2010 at 6:58 PM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > issue #2085 > > Replace the method PackageOrganizer>>packageOfClass: aClass ifNone: > errorBlock by > -=-=-=-=-= > packageOfClass: aClass ifNone: errorBlock > Â Â Â Â | classCategory | > Â Â Â Â classCategory := aClass category. > Â Â Â Â packages at: classCategory ifPresent: [:v | ^ v]. > > Â Â Â Â (classCategory includes: $-) > Â Â Â Â Â Â Â Â ifTrue: [ packages at: (classCategory copyUpTo: $-) ifPresent: [:v | > ^ v] ]. > > Â Â Â Â ^ self packages detect: [:ea | ea includesClass: aClass] ifNone: > errorBlock > -=-=-=-=-= > > Before this enhancement: > [100 timesRepeat: [Object package]] timeToRun > => 141 > > After the fix: > => 2 > > Easy thing to do. > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel Â http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > 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 > -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Smalltalkers do: [:it | All with: Class, (And love: it)] http://doesnotunderstand.org/

Feb. 27, 2010

Re: [Pharo-project] [update 1.1] #11234

by Marcus Denker

On Feb 27, 2010, at 12:11 PM, Marcus Denker wrote: > 11235 > -------- 11234 > > - Issue 2057: Clean Codeloader more... > - Issue 2029: Undeclared Variables > - Issue 1922: use #forceNewFileNamed:do: pattern > > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Feb. 27, 2010

[Pharo-project] [update 1.1] #11235

by Marcus Denker

11235 --------- - Issue 1628: Error: There is no free space in this set!. - Enh Diff tool -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Feb. 27, 2010

[Pharo-project] [update 1.1] #11235

by Marcus Denker

11235 -------- - Issue 2057: Clean Codeloader more... - Issue 2029: Undeclared Variables - Issue 1922: use #forceNewFileNamed:do: pattern -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Feb. 27, 2010

[Pharo-project] self halt

by Hilaire Fernandes

On a updated pharo 1.1 image, a "self halt" block the image. The debugger is raised but the UI is frozen.

Feb. 27, 2010

Re: [Pharo-project] Streams. Status and where to go?

by Levente Uzonyi

On Sat, 27 Feb 2010, Richard Durr wrote: > So what speaks against using VisualWorks' Xtreams? > http://www.cincomsmalltalk.com/blog/blogView?entry=3444278480&printTitle=Sm… 1. Someone has to port it. 2. It's optimized for VW, so the ported code's performance will probably be bad. Levente > > On Fri, Feb 26, 2010 at 11:01 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> On 26 February 2010 21:30, Nicolas Cellier >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> 2010/2/26 Igor Stasenko <siguctua(a)gmail.com>: >>>> On 26 February 2010 18:59, Nicolas Cellier >>>> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>>> 2010/2/26 Igor Stasenko <siguctua(a)gmail.com>: >>>>>> Hello, Nicolas. >>>>> >>>>> Hi igor. >>>>> You should load it in trunk. >>>>> >>>> Ah, i think my image is a bit outdated then. >>>> >>>>>> I want to try it out. >>>>>> I tried to load it (XTream-Core) into my image, and it bug me about >>>>>> unresolved dependencies: >>>>>> ---- >>>>>> This package depends on the following classes: >>>>>> Â ByteTextConverter >>>>>> You must resolve these dependencies before you will be able to load >>>>>> these definitions: >>>>>> Â ByteTextConverter>>nextFromXtream: >>>>>> Â ByteTextConverter>>nextPut:toXtream: >>>>>> Â ByteTextConverter>>readInto:startingAt:count:fromXtream: >>>>>> ---- >>>>>> I ignored these warnings, pressing continue, and here what it warns >>>>>> about in my trunk image: >>>>>> >>>>>> TextConverter>>next:putAll:startingAt:toXtream: (latin1Map is Undeclared) >>>>>> TextConverter>>next:putAll:startingAt:toXtream: (latin1Encodings is Undeclared) >>>>>> TextConverter>>readInto:startingAt:count:fromXtream: (latin1Map is Undeclared) >>>>>> >>>>>> Is ByteTextConverter a Pharo-specific class? >>>>>> >>>>> >>>>> This is a refactoring of TextConverter I made in trunk. >>>>> Pharo did the same before me (it comes from Sophie), but I missed it >>>>> unfortunately... >>>>> >>>>>> If you seen my previous message, i think you noticed that >>>>>> XXXTextConverter is abdominations (IMO), and should be reimplemented >>>>>> as a wrapping-streams instead. >>>>>> Would you be willing to change that in XStreams? I mean implementing a >>>>>> conversion streams model, which can wrap around any other stream, >>>>>> like: >>>>>> >>>>>> myStream := UTFReaderStream on: otherStream. >>>>>> myString := myStream contents. >>>>>> >>>>>> or using other way: >>>>>> >>>>>> myString := (someBaseStream wrapWith: UTFReaderStream) contents. >>>>>> >>>>>> or.. >>>>>> myDecodedString := (someBaseStream wrapWith: (DecodingStreams >>>>>> decoderFor: myEncoding) contents. >>>>>> >>>>>> That's would be much nicer than using converters. >>>>> >>>>> Currently, I have a ConverterReadXtream and a ConverterWriteXtream >>>>> which are stream wrappers. >>>>> They use old TextConverter to do the real job, but I agree, a full >>>>> rewrite of this one is needed. >>>>> However, I would like to keep these two layers for Stream composition: >>>>> - the generic converter stream >>>>> - the conversion algorithm >>>>> >>>> >>>> Why? >>>> In your implementation you already added the >>>> readInto: aCollection startingAt: startIndex count: anInteger >>>> and >>>> next: count into: aString startingAt: startIndex >>>> into converters, which makes them even more like streams. >>>> >>> >>> Yes, you may be right. >>> Maybe my ratio innovating/reusing was a bit low :) >>> >>>> So, what stopping you from making an abstract, generic XtreamWrapper class, >>>> and then a number of subclasses Â (LatinConversionStream , >>>> UnicodeConversionStream etc), >>> >>> Yes, that's possible. But it's already what ConverterReadXtream and >>> ConverterWriteXtream are. >>> >> >> I suggesting to use a following hierarchy >> >> Xtream -> XtreamWrapper -> ConverterXtream -> (bunch of subclasses) >> >> or just >> >> Xtream -> XtreamWrapper -> (bunch of subclasses) >> >> since i don't think there a lot of specific behavior in >> ConverterXtream worth creating a separate class. >> But maybe i'm wrong. >> >>>> as well as BufferedWrapper? >>>> >>> >>> BufferedReadXtream and BufferedWriteXtream already are generic. It's >>> just that I have separated read and write... >>> So you will find ReadXtream>>buffered >>> Â Â Â Â ^(BufferedReadXtream new) >>> Â Â Â Â Â Â Â Â contentsSpecies: self contentsSpecies bufferSize: self preferredBufferSize; >>> Â Â Â Â Â Â Â Â source: self >>> >>> Or do you mean a single Buffer for read/write ? >>> That would look more like original VW I think. >>> >> >> obviously, if you reading and writing to same stream , you should take >> care of keeping any buffered i/o in sync. >> The #buffered can decide what kind of stream to create >> self isWritable ifTrue: [ create R/W wrapper ] ifFalse: [ create R/O wrapper ] >> >> this is , of course if you promote #buffered to Xtream class. Which i >> think worthful thing. >> >>>> So, it will cost us 1 less message dispatch in >>>> a := stream next. >>>> >>>> In your model you having: >>>> >>>> (converter stream) -> (converter) -> basic stream >>>> >>>> while if using wrapper it will be just: >>>> (converter wrapper) -> basic stream >>>> >>> >>> I must re-think why I made this decision of additional indirection... >>> Maybe it was just reusing... >>> >> >> I think this is just about reuse. But as i shown in >> UFT8TextConverter>>nextFromStream: >> its in addition to extra dispatch, using a characters instead of >> bytes, which can be avoided >> if you wrap the stream to be converted and tell it to work in binary >> mode, since your wrapper are in control. >> >>>> >>>>> Though current XTream is a quick hack reusing Yoshiki TextConverter, >>>>> it already demonstrates possible gains coming from buffering. >>>>> The speed comes from,applying utf8ToSqueak, squeakToUtf8 trick: copy >>>>> large ASCII encoded portions verbatim. >>>>> This works very well with squeak source because 99,99% of characters are ASCII. >>>>> >>>>>> >>>>>> Wrappers is more flexible comparing to TextConverters, since they are >>>>>> not obliged to convert to/from text-based collections only. >>>>>> For example, we can use same API for wrapping with ZIP stream: >>>>>> >>>>>> myUnpackedData := (someBaseStream wrapWith: ZIPReaderStream) contents. >>>>>> >>>>>> and many other (ab)uses.. Like reading changeset chunks: >>>>>> >>>>>> nextChunk := (fileStream wrapWith: ChunkReaderStream) next. >>>>>> >>>>> >>>>> Yes, that fits my intentions. >>>>> What I want is to preserve buffered operations along the chain, and >>>>> avoid byte-by-byte conversions when possible. >>>>> >>>> >>>> Buffering is just a wrapper. Btw, again, why you don't providing a >>>> generic wrapper class which everyone can subclass from? >>>> >>>> bufferedStream := anyStreamClass buffered >>>> >>>> (buffered wrapper) -> (anyStreamClass) >>>> >>> >>> See above, it's just split in BufferedRead/WriteXtream >>> >>> Or see the example (a bit heavy) >>> Â tmp := ((StandardFileStream readOnlyFileNamed: (SourceFiles at: 2) name) >>> Â Â Â readXtream ascii buffered decodeWith: (UTF8TextConverter new >>> installLineEndConvention: nil)) buffered. >>> >> >> yes. its a bit heavy, but this is a way how one should build a chains >> of streams. >> Except that there should be only streams in chain, no non-stream >> converters in between :) >> >>> >>>> i don't see where else you should care of buffering explicitly in >>>> anyStreamClass. >>>> >>>> And, how you can avoid byte-by-byte conversion in utf8? It should >>>> iterate over bytes to determine the characters anyways. >>> >>> True, it is faster because you scan fast with a primitive, >>> then copy a whole chunk with replaceFrom:to:with:startingAt: primitive >>> >>> Of course, if you handle some cyrillic files, then this strategy won't >>> be efficient. It just work in ASCII dominated files. >>> UTF8 itself would not be an optimal choice for cyrillic anyway... >>> >> I prefer to use UFT8 nowadays, instead of old rubbish encodings, which >> is many :) >> >>>> But sure thing, nothing prevents you from buffering things in a way like: >>>> >>>> reader := anyStream buffered wrapWith: UTF8Reader. >>>> >>> >>> My above example is just equivalent to: >>> >>> reader := (anyStream buffered wrapWith: UTF8Reader) buffered. >>> >>> Then even if I use reader next, a whole buffer of UTF8 is converted >>> (presumably by large chunks) >>> >> >> Right, nobody says that its not possible to do double-buffering. >> First, by wrapping an original stream (presumably file-based) >> and second - an output of utf8 converter. >> >> [snip] >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 27, 2010

Re: [Pharo-project] [Fwd: [squeak-dev] The Trunk: Kernel-ar.411.mcz]

by StÃ©phane Ducasse

:) http://code.google.com/p/pharo/issues/detail?id=2087 :) On Feb 27, 2010, at 8:29 AM, Miguel Enrique CobÃ¡ Martinez wrote: > Maybe we can add this to the cleanUpForRelease script. > > Cheers > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > From: commits(a)source.squeak.org > Date: February 26, 2010 6:38:01 PM GMT+01:00 > To: squeak-dev(a)lists.squeakfoundation.org, packages(a)lists.squeakfoundation.org > Subject: [squeak-dev] The Trunk: Kernel-ar.411.mcz > Reply-To: squeak-dev(a)lists.squeakfoundation.org > > > Andreas Raab uploaded a new version of Kernel to project The Trunk: > http://source.squeak.org/trunk/Kernel-ar.411.mcz > > ==================== Summary ==================== > > Name: Kernel-ar.411 > Author: ar > Time: 26 February 2010, 7:36:40.257 pm > UUID: b69a28db-8475-bc4b-89ed-285ccf3841cd > Ancestors: Kernel-ul.410 > > Add MethodDictionary class>>compactAllInstances to save space in releases. Compacting all MDs in my images saves 600k in image size which isn't bad at all. > > =============== Diff against Kernel-ul.410 =============== > > Item was added: > + ----- Method: MethodDictionary class>>compactAllInstances (in category 'initialization') ----- > + compactAllInstances "MethodDictionary compactAllInstances" > + "Compacts all MethodDictionaries to save space" > + > + | oldInstances newInstances | > + oldInstances := self allInstances. > + newInstances := oldInstances collect:[:md| > + (self new: md size) > + compactCopyFrom: md; > + yourself]. > + oldInstances elementsForwardIdentityTo: newInstances. > + ! > > Item was added: > + ----- Method: MethodDictionary>>compactCopyFrom: (in category 'private') ----- > + compactCopyFrom: sourceMD > + "Copy the contents of source dictionary without growing" > + > + sourceMD keysAndValuesDo:[:key :value| | index | > + index := self scanFor: key. > + (self basicAt: index) ifNotNil:[self error: 'Something is horribly broken']. > + self basicAt: index put: key. > + array at: index put: value. > + tally := tally + 1. > + ]. > + self size = self capacity ifTrue:[self grow]. "grow only if we reach capacity" > + ! > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 27, 2010