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

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

by Igor Stasenko

On 28 February 2010 12:00, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2010/2/28 Igor Stasenko <siguctua(a)gmail.com>: >> Hi, i'm also did some hacking. I uploaded XTream-Wrappers-sig.1 into SqS/XTream. >> >> There is a basic XtreamWrapper class, which should work transparently >> for any stream (hopefully ;). >> Next, in subclass i created converter. Sure thing i could also add a >> buffered wrapper, but maybe later :) >> >> Here some benchmarks. The file i used to test is utf-8 russian doc >> text - in attachment.. >> >> | str | >> str := (StandardFileStream readOnlyFileNamed: 'unitext.txt') readXtream. >> { >> [ str reset. (XtreamUTF8Converter on: str readXtream) upToEnd ] bench. >> [ str reset. (UTF8Decoder new source: str readXtream) upToEnd ] bench. >> } >> #('21.71314741035857 per second.' '14.0371688414393 per second.') >> Â #('22.16896345116836 per second.' '14.5186953062848 per second.') >> >> Next, buffered >> >> | str | >> str := (StandardFileStream readOnlyFileNamed: 'unitext.txt') readXtream. >> { >> [ str reset. (XtreamUTF8Converter on: str readXtream buffered) upToEnd ] bench. >> [ str reset. (UTF8Decoder new source: str readXtream buffered) upToEnd ] bench. >> } >> #('58.52976428286057 per second.' '25.44225800039754 per second.') >> #('58.90575079872205 per second.' '25.87064676616916 per second.') >> >> >> I'm also tried double-buffering, but neither my class nor yours >> currently works with it: >> >> | str | >> str := (StandardFileStream readOnlyFileNamed: 'unitext.txt') readXtream. >> { >> [ str reset. (XtreamUTF8Converter on: str readXtream buffered) >> buffered upToEnd ] bench. >> [ str reset. (UTF8Decoder new source: str readXtream buffered) >> buffered upToEnd ] bench. >> } >> >> Please , take a look. There are some quirks which not because i >> cleaned up decoding/encoding code. >> See XtreamWrapper>>upToEnd implementation. >> >> > > Yes I published a bit soon and messed up because one temp from text > converter method (source) had same name as CharacterDecoder inst var > :( > Find a second attempt: > > | str | > str := (StandardFileStream readOnlyFileNamed: 'unitext.txt') readXtream binary. > { > [ str reset. (XtreamUTF8Converter on: str readXtream buffered) > buffered upToEnd ] bench. > [ str reset. (UTF8Decoder new source: str readXtream buffered) > buffered upToEnd ] bench. > } > #('118.0347513481126 per second.' '31.38117129722167 per second.') > > > As you can see, the optimistic ASCII version is pessimistic in case of > non ASCII... > It creates a composite stream and perform a lot of copys... > This is known and waiting better algorithm :) > whoops.. you got more than 3x speedup, while mine was around 2x. But please, try on ascii files. | str | str := (String new: 1000 withAll: $a) asByteArray. { [ (XtreamUTF8Converter on: str readXtream binary) upToEnd ] bench. [ (UTF8Decoder new source: str readXtream binary) upToEnd ] bench. [ str readXtream binary upToEnd ] bench. } #('2039.392121575685 per second.' '1158.568286342731 per second.' '92143.1713657269 per second.') so, conversion is 90..45 times slower than just copying data :) We need to tighten up this gap. One would be to optimize #readInto:startingAt:count: using batch-mode conversion. > Nicolas > >> -- >> 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 > -- Best regards, Igor Stasenko AKA sig.

Feb. 28, 2010

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

by Nicolas Cellier

2010/2/28 Igor Stasenko <siguctua(a)gmail.com>: > Hi, i'm also did some hacking. I uploaded XTream-Wrappers-sig.1 into SqS/XTream. > > There is a basic XtreamWrapper class, which should work transparently > for any stream (hopefully ;). > Next, in subclass i created converter. Sure thing i could also add a > buffered wrapper, but maybe later :) > > Here some benchmarks. The file i used to test is utf-8 russian doc > text - in attachment.. > > | str | > str := (StandardFileStream readOnlyFileNamed: 'unitext.txt') readXtream. > { > [ str reset. (XtreamUTF8Converter on: str readXtream) upToEnd ] bench. > [ str reset. (UTF8Decoder new source: str readXtream) upToEnd ] bench. > } > #('21.71314741035857 per second.' '14.0371688414393 per second.') > Â #('22.16896345116836 per second.' '14.5186953062848 per second.') > > Next, buffered > > | str | > str := (StandardFileStream readOnlyFileNamed: 'unitext.txt') readXtream. > { > [ str reset. (XtreamUTF8Converter on: str readXtream buffered) upToEnd ] bench. > [ str reset. (UTF8Decoder new source: str readXtream buffered) upToEnd ] bench. > } > #('58.52976428286057 per second.' '25.44225800039754 per second.') > #('58.90575079872205 per second.' '25.87064676616916 per second.') > > > I'm also tried double-buffering, but neither my class nor yours > currently works with it: > > | str | > str := (StandardFileStream readOnlyFileNamed: 'unitext.txt') readXtream. > { > [ str reset. (XtreamUTF8Converter on: str readXtream buffered) > buffered upToEnd ] bench. > [ str reset. (UTF8Decoder new source: str readXtream buffered) > buffered upToEnd ] bench. > } > > Please , take a look. There are some quirks which not because i > cleaned up decoding/encoding code. > See XtreamWrapper>>upToEnd implementation. > > Yes I published a bit soon and messed up because one temp from text converter method (source) had same name as CharacterDecoder inst var :( Find a second attempt: | str | str := (StandardFileStream readOnlyFileNamed: 'unitext.txt') readXtream binary. { [ str reset. (XtreamUTF8Converter on: str readXtream buffered) buffered upToEnd ] bench. [ str reset. (UTF8Decoder new source: str readXtream buffered) buffered upToEnd ] bench. } #('118.0347513481126 per second.' '31.38117129722167 per second.') As you can see, the optimistic ASCII version is pessimistic in case of non ASCII... It creates a composite stream and perform a lot of copys... This is known and waiting better algorithm :) Nicolas > -- > 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 >

Feb. 28, 2010

Re: [Pharo-project] about code formatting in pharo

by StÃ©phane Ducasse

Lukas do you have some code samples. Something that I particularly hate is the following self bla ifTrue: [ ... ] ifFalse: [ ... ] That is see in the code. I want self bla ifTrue: [ ... ] ifFalse: [ ... ] > I would use a formatter, like this you can make it really consistent. > The RBConfigurableFormatter is pretty good in that, the only thing I > don't like is the placing of the square brackets. I should look into > fixing that, otherwise it formats exactly the way I would format > myself (and in the way you propose). I would really like to play with the idea of automatic formatting to see how it goes. Stef > > Lukas > > On 28 February 2010 10:36, stephane ducasse <stephane.ducasse(a)free.fr> wrote: >> Hi guys >> >> I would like to build a set of canonical code formatting convention for Pharo. >> I need your help. Now take time before replying :) >> I would like to structure the discussion and proceed step by step. So at max I would like to discuss one or two formatting approach per mail. >> Once we agree I would like to define a wiki page. >> >> >> **Space after : rule >> ============= >> for example I would like to always have a space after a : >> >> classes := Smalltalk allClasses select:[:aClass| >> (aClass class includesSelector: #cleanUp) >> or:[aClass class includesSelector: #cleanUp:] >> ]. >> >> -> >> >> >> classes := Smalltalk allClasses select: [:aClass| >> (aClass class includesSelector: #cleanUp) >> or: [aClass class includesSelector: #cleanUp:] >> ]. >> >> >> **Block arg rule >> ============= >> Do we want a space before and after block arg >> >> Smalltalk allClasses select: [:aClass :method| >> >> -> Smalltalk allClasses select: [ :aClass :method | >> >> >> ** selector or block indented compared to receiver >> ======================================= >> >> Finally do we follow kent block ideas? >> >> classes := Smalltalk allClasses select: [:aClass| >> (aClass class includesSelector: #cleanUp) >> or: [aClass class includesSelector: #cleanUp:] >> ]. >> >> -> >> classes := Smalltalk allClasses >> select: [:aClass| (aClass class includesSelector: #cleanUp) >> or: [aClass class includesSelector: #cleanUp:]]. >> >> Stef >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 28, 2010

Re: [Pharo-project] about code formatting in pharo

by Lukas Renggli

I would use a formatter, like this you can make it really consistent. The RBConfigurableFormatter is pretty good in that, the only thing I don't like is the placing of the square brackets. I should look into fixing that, otherwise it formats exactly the way I would format myself (and in the way you propose). Lukas On 28 February 2010 10:36, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > Hi guys > > I would like to build a set of canonical code formatting convention for Pharo. > I need your help. Now take time before replying :) > I would like to structure the discussion and proceed step by step. So at max I would like to discuss one or two formatting approach per mail. > Once we agree I would like to define a wiki page. > > > **Space after : rule > ============= > for example I would like to always have a space after a : > > classes := Smalltalk allClasses select:[:aClass| > Â Â Â Â Â Â Â (aClass class includesSelector: #cleanUp) > Â Â Â Â Â Â Â Â Â Â Â or:[aClass class includesSelector: #cleanUp:] > Â Â Â ]. > > -> > > > classes := Smalltalk allClasses select: [:aClass| > Â Â Â Â Â Â Â (aClass class includesSelector: #cleanUp) > Â Â Â Â Â Â Â Â Â Â Â or: [aClass class includesSelector: #cleanUp:] > Â Â Â ]. > > > **Block arg rule > ============= > Do we want a space before and after block arg > > Smalltalk allClasses select: [:aClass :method| > > -> Smalltalk allClasses select: [ :aClass :method | > > > ** selector or block indented compared to receiver > ======================================= > > Finally do we follow kent block ideas? > > classes := Smalltalk allClasses select: [:aClass| > Â Â Â Â Â Â Â (aClass class includesSelector: #cleanUp) > Â Â Â Â Â Â Â Â Â Â Â or: [aClass class includesSelector: #cleanUp:] > Â Â Â ]. > > -> > classes := Smalltalk allClasses > Â Â Â Â Â Â Â Â Â Â Â Â select: [:aClass| (aClass class includesSelector: #cleanUp) > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â or: [aClass class includesSelector: #cleanUp:]]. > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 28, 2010

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

by StÃ©phane Ducasse

If you feel that this is important we can take some time and port the code from VW. Let us know I can ask cyrille to give a try. Stef On Feb 27, 2010, at 10:56 PM, Nicolas Cellier wrote: > 2010/2/27 Levente Uzonyi <leves(a)elte.hu>: >> 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 >> > > Licensing was not clear when I begun, so I just picked a few ideas and > re-implement from scratch. > Now it would be interesting to try porting VW Xtream (I should say the > original XTream, I just hijacked the name...). > Concerning performance, VW XTream use exeptions extensively, which I > tried to avoid. > > Nicolas > >>> >>> 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 >> >> _______________________________________________ >> 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. 28, 2010

Re: [Pharo-project] SqueakSave on Pharo

by StÃ©phane Ducasse

Yanni excellent to have it on squeaksource. Now did you contact the maintainer (if any) or the people that developed it (I like it a lot) to mention that? Because at least they should know if some changes get introduced that they can cherrypick it. Stef On Feb 28, 2010, at 2:49 AM, Yanni Chiu wrote: > laurent laffont wrote: >> On Fri, Feb 19, 2010 at 9:24 PM, Yanni Chiu >>> >>> Can you put it on squeaksource ? >> >> I'll clean up the package I have, and then ping the author for how >> contributions are to be handled (before forking it on squeaksource). >> BTW, the HPI repository is now back online. > > Okay, it's at: > > http://www.squeaksource.com/SqueakSave > > SqSave-tkow.127.mcz - This version was created from the HPI version by > unzip'ing the .mcz, fixing the issues that prevented it from loading > into Pharo, by editing the source.st file, then re-zip'ing into a .mcz > package. > > SqSave-YanniChiu.135.mcz - This version was developed for my needs at > the time, then clean up somewhat for public release. Using the native > postgres driver (and probably dbx one too), the following 3 tests are > still failing: > >>>> SqsCTISearchQueryTest.testQueryBlob >>>> SqsCTISearchQueryTest.testReferenceToSubclassElementWithinCollection >>>> SqsSTISearchQueryTest.testQueryBlob > > > Some class category names were changed, and some example code left out. > The original .127.mcz should be loadable, so you can see what was > changed. The repository is set for global read/write. > > -- > Yanni > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 28, 2010

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

by StÃ©phane Ducasse

Let us know. Seems to be a really big earthquake. Probably at santiago some old houses suffered but not the new ones. Stef On Feb 28, 2010, at 1:39 AM, Alexandre Bergel wrote: > Fortunately yes. I am currently on the seaside, these has been some > tsunami alert, but I haven't more than a very strong tide. > Wondering how I will find my flat in Santiago. > > Thanks for asking, > Alexandre > > > On 27 Feb 2010, at 08:17, Serge Stinckwich wrote: > >> 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/ >> >> _______________________________________________ >> 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

Feb. 28, 2010

[Pharo-project] about code formatting in pharo

by stephane ducasse

Hi guys I would like to build a set of canonical code formatting convention for Pharo. I need your help. Now take time before replying :) I would like to structure the discussion and proceed step by step. So at max I would like to discuss one or two formatting approach per mail. Once we agree I would like to define a wiki page. **Space after : rule ============= for example I would like to always have a space after a : classes := Smalltalk allClasses select:[:aClass| (aClass class includesSelector: #cleanUp) or:[aClass class includesSelector: #cleanUp:] ]. -> classes := Smalltalk allClasses select: [:aClass| (aClass class includesSelector: #cleanUp) or: [aClass class includesSelector: #cleanUp:] ]. **Block arg rule ============= Do we want a space before and after block arg Smalltalk allClasses select: [:aClass :method| -> Smalltalk allClasses select: [ :aClass :method | ** selector or block indented compared to receiver ======================================= Finally do we follow kent block ideas? classes := Smalltalk allClasses select: [:aClass| (aClass class includesSelector: #cleanUp) or: [aClass class includesSelector: #cleanUp:] ]. -> classes := Smalltalk allClasses select: [:aClass| (aClass class includesSelector: #cleanUp) or: [aClass class includesSelector: #cleanUp:]]. Stef

Feb. 28, 2010

Re: [Pharo-project] Introducing Myself / FFI comments

by Hilaire Fernandes

Andreas Raab a Ã©crit : > The *one* tradeoff I wasn't willing to make for the sake of my users was > to break their code; was to make their code non-loadable for absolutely > no benefit for these users. Cleaning up two methods and fifty lines of > code isn't worth breaking six years of work from lots of people. It > wasn't then, it isn't today. However, breaking code compatibility is very common in opensource world, probably to ease evolution. I remember to read somewhere it happens several time in Python, an alive and kicking community...

Feb. 28, 2010

[Pharo-project] PhD proposal: Security in Dynamic Languages

by Marcus Denker

(I am reposting this with updated links) The RMoD team at INRIA Lille / France is offering a PhD position. "Reflection and Security in Dynamic Languages". Applications must be submitted online, the deadline is *Mai 4*. More information and online application: http://bit.ly/cbAlE9 More on doing a PhD at INRIA: http://www.inria.fr/travailler/opportunites/doc.en.html ====================================================================== Reflection and Security in Dynamic Languages ============================================ Position type: PhD Student Functional area: Lille (Villeneuve d'Asq) Project: RMOD Environnement ============= To support the creation and evolution of complex systems, dynamic languages provide support for reflection. A reflective system contains a model of itself to enable runtime change: if we change the model, the system changes and vice versa. Reflection allows the programmer to do any kind of change at runtime, even those that render the system useless or breach any kind of security guarantees. Reflection is an established research theme and has seen a lot of work over the last decades. The question of how to control reflection and related that of secure reflective systems in general has not seen much research activity. The PhD Student therefore will work on the question on how to control reflection and work towards enabling systems that are both reflective and secure. Missions ======== The goal of this PhD is to propose a new secure reflective language kernel for dynamic languages. The following points should be explored: - Study existing models of security. - Study existing reflective systems and especially prior work on security and reflection. - Propose a new, secure model of reflection. - Implemented the model in a dynamic, object-oriented language. CompÃ©tences et Profil ===================== - Reflective programming - Smalltalk / C - English Informations complÃ©mentaires ============================ Chercheur(s) Ã contacter pour plus dâinformation/advisors : StÃ©phane Ducasse : stephane.ducasse(a)inria.fr Marcus Denker : marcus.denker(a)inria.fr References ========== [1] Marcus Denker, Tudor GÃ®rba, Adrian Lienhard, Oscar Nierstrasz, Lukas Renggli and Pascal Zumkehr, âEncapsulating and Exploiting Change with Changeboxes,â Proceedings of the 2007 International Conference on Dynamic Languages (ICDL 2007), ACM Digital Library, 2007, pp. 25--49. [2] Oscar Nierstrasz, Alexandre Bergel, Marcus Denker, StÃ©phane Ducasse, Markus Gaelli and Roel Wuyts, âOn the Revival of Dynamic Languages,â Proceedings of Software Composition 2005, Thomas Gschwind and Uwe AÃmann (Eds.), vol. 3628, LNCS 3628, 2005, pp. 1-13 [3] Mark S. Miller and Jonathan S. Shapiro. Paradigm Regained: Abstraction Mechanisms for Access Control. In Proceedings of the Eigth Asian Computing Science Conference, p. 224-242, 2003. [4] Mark Samuel Miller. Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control. Ph.D. thesis, Johns Hopkins University, Baltimore, Maryland, USA, May 2006. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Feb. 28, 2010