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

Re: [Pharo-project] About mime encoding

by Nicolas Cellier

2010/1/15 Levente Uzonyi <leves(a)elte.hu>: > On Fri, 15 Jan 2010, Nicolas Cellier wrote: > >> Sounds hackish to me. You are right to ask for a rationale and a >> requirement before letting such line in. > > The line is in Pharo, but not in Squeak. > > > Levente > Oh, then it's easier, just post a short ultimatum and if no hands up, slay! Nicolas >> >> Nicolas >> >> 2010/1/15 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> >>> Hi >>> >>> in the squeak trunk >>> >>> jcg in collections-jcg.124 did >>> >>> mimeEncode: aStream >>> Â Â Â Â "Return a ReadWriteStream of characters. Â The data of aStream is >>> encoded as 65 innocuous characters. Â (See class comment). 3 bytes in aStream >>> goes to 4 bytes in output." >>> >>> Â Â Â Â | me | >>>>> >>>>> Â Â Â aStream position: 0. >>> >>> Â Â Â Â me := self new dataStream: aStream. >>> Â Â Â Â me mimeStream: (ReadWriteStream on: (String new: aStream size + 20 >>> * 4 // 3)). >>> Â Â Â Â me mimeEncode. >>> Â Â Â Â me mimeStream position: 0. >>> Â Â Â Â ^ me mimeStream >>> >>> I would like to know if one of you agree on that. >>> >>> Thanks >>> Stef >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 15, 2010

Re: [Pharo-project] Putting Algernon and WorkingSet in a Dev image

by Mariano Martinez Peck

On Fri, Jan 15, 2010 at 5:55 PM, Romain Robbes <romain.robbes(a)gmail.com>wrote: > yes it has overrides ... > > that's because as far as I know, there's no keyboard shortcut management > facility > in Pharo. If there was one, I suppose Algernon and WorkingSet would > coexist. > So...all your overrides are due to the shortcuts? I think it is not fear to "forbid" a package to be included in a Dev image if we don't provide from the core a way to manage shortcuts. So: 1) Or we let this projects to be installed in the Dev image 2) We fix the problem with the shortcuts. Romain: can you tell us where exactly the problem is ? maybe someone can give you a hand. Cheers Mariano > > Romain > > > On Jan 15, 2010, at 6:49 AM, Damien Cassou wrote: > > > 2010/1/15 Mariano Martinez Peck <marianopeck(a)gmail.com>: > >> Thanks Damien. I did that, run the load of both projects but none of > them > >> warn me. > >> > >> Are you sure they have overrides? > > > > I'm sure that WorkingSet has overrides, my detection code is probably > > not correct. > > > > -- > > 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(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 15, 2010

Re: [Pharo-project] us the vm -memory in an image ?

by John M McIntosh

right the memory logic is a moving target. In checking on unix -memory is malloc -mmap is mmap and on grow/shrink it grinds thru munmap/mmap. for os-x I just mmap the memory but I choose not to do the mmap/munmap since over the years I found various operating versions had funky responses to mmap/munmap On 2010-01-15, at 3:40 AM, Laval Jannik wrote: > Hi, > > Thank you for your comment, I will try this. > > Cheers > Jannik > -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Jan. 15, 2010

Re: [Pharo-project] About mime encoding

by Levente Uzonyi

On Fri, 15 Jan 2010, Nicolas Cellier wrote: > Sounds hackish to me. You are right to ask for a rationale and a > requirement before letting such line in. The line is in Pharo, but not in Squeak. Levente > > Nicolas > > 2010/1/15 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> Hi >> >> in the squeak trunk >> >> jcg in collections-jcg.124 did >> >> mimeEncode: aStream >> Â Â Â Â "Return a ReadWriteStream of characters. Â The data of aStream is encoded as 65 innocuous characters. Â (See class comment). 3 bytes in aStream goes to 4 bytes in output." >> >> Â Â Â Â | me | >>>> Â Â Â aStream position: 0. >> Â Â Â Â me := self new dataStream: aStream. >> Â Â Â Â me mimeStream: (ReadWriteStream on: (String new: aStream size + 20 * 4 // 3)). >> Â Â Â Â me mimeEncode. >> Â Â Â Â me mimeStream position: 0. >> Â Â Â Â ^ me mimeStream >> >> I would like to know if one of you agree on that. >> >> Thanks >> Stef >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 15, 2010

Re: [Pharo-project] About mime encoding

by Nicolas Cellier

Sounds hackish to me. You are right to ask for a rationale and a requirement before letting such line in. Nicolas 2010/1/15 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Hi > > in the squeak trunk > > jcg in collections-jcg.124 did > > mimeEncode: aStream > Â Â Â Â "Return a ReadWriteStream of characters. Â The data of aStream is encoded as 65 innocuous characters. Â (See class comment). 3 bytes in aStream goes to 4 bytes in output." > > Â Â Â Â | me | >>> Â Â Â aStream position: 0. > Â Â Â Â me := self new dataStream: aStream. > Â Â Â Â me mimeStream: (ReadWriteStream on: (String new: aStream size + 20 * 4 // 3)). > Â Â Â Â me mimeEncode. > Â Â Â Â me mimeStream position: 0. > Â Â Â Â ^ me mimeStream > > I would like to know if one of you agree on that. > > Thanks > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 15, 2010

Re: [Pharo-project] About RemoteString>>checksum:

by Nicolas Cellier

It's same code, but pharo String does not respond to #base64Encoded Nicolas 2010/1/15 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > in squeak trunk > Can some of you double check this change from squeaktrunk Name: Files-jcg.27 > > In squeak > checkSum: aString > Â Â Â Â "Construct a checksum of the string. Â A three byte number represented as Base64 characters." > Â Â Â Â | sum shift bytes | > Â Â Â Â sum := aString size. > Â Â Â Â shift := 0. > Â Â Â Â aString do: [:char | > Â Â Â Â Â Â Â Â (shift := shift + 7) > 16 ifTrue: [shift := shift - 17]. > Â Â Â Â Â Â Â Â Â Â Â Â "shift by 7 to keep a change of adjacent chars from xoring to same value" > Â Â Â Â Â Â Â Â sum := sum bitXor: (char asInteger bitShift: shift) > Â Â Â Â ]. > Â Â Â Â bytes := ByteArray new: 3. > Â Â Â Â sum := sum + 16r10000000000. > Â Â Â Â 1 to: 3 do: [:ind | bytes at: ind put: (sum digitAt: ind)]. > Â Â Â Â ^bytes base64Encoded > > > > In pharo > > checkSum: aString > Â Â Â Â "Construct a checksum of the string. Â A three byte number represented as Base64 characters." > | sum shift bytes ss bb | > sum := aString size. > shift := 0. > aString do: [:char | > Â Â Â Â (shift := shift + 7) > 16 ifTrue: [shift := shift - 17]. > Â Â Â Â Â Â Â Â "shift by 7 to keep a change of adjacent chars from xoring to same value" > Â Â Â Â sum := sum bitXor: (char asInteger bitShift: shift)]. > bytes := ByteArray new: 3. > sum := sum + 16r10000000000. > 1 to: 3 do: [:ind | bytes at: ind put: (sum digitAt: ind)]. > ss := ReadWriteStream on: (ByteArray new: 3). > ss nextPutAll: bytes. > bb := Base64MimeConverter mimeEncode: ss. > ^ bb contents > > Thanks > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 15, 2010

Re: [Pharo-project] FileStream Squeak harvested

by Nicolas Cellier

2010/1/15 Levente Uzonyi <leves(a)elte.hu>: > On Fri, 15 Jan 2010, Levente Uzonyi wrote: > >> On Fri, 15 Jan 2010, Mariano Martinez Peck wrote: >> >>> Hi: Today Stef and I have being harvested Squeak changes in FileStream. The >>> most important is the work from Levente and the buffer. >>> >>> We commit the first slide in inbox: Â SLICE-FileStream-StephaneDucasse.1 >>> >>> Can someone take a look please because is this quite "important" to >>> integrate. >> >> StandardFileStream >> #readInto:startingAt:count: is wrong, there's a >> newer version. StandardFileStream >> #skip: is missing. >> The changes for MultiByteFileStream are also missing. Without those, the >> files' state may become corrupt and the expected system-wide speedup will >> be less significant. >> Changes of classes other than StandardFileStream are unrelated to the read >> buffering in the slice. > > There's also a new version of StandardFileStream >> #upTo: in the trunk, > which still begs for a cleanup (I wonder who thought that recursion > combined with #, will be fast). > > > Levente > Yeah, kust peek code in Xtream, it's faster Nicolas >> >> Levente >> >>> >>> Thanks >>> >>> Mariano >>> >> >> _______________________________________________ >> 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. 15, 2010

Re: [Pharo-project] FileStream Squeak harvested

by Levente Uzonyi

On Fri, 15 Jan 2010, Levente Uzonyi wrote: > On Fri, 15 Jan 2010, Mariano Martinez Peck wrote: > >> Hi: Today Stef and I have being harvested Squeak changes in FileStream. The >> most important is the work from Levente and the buffer. >> >> We commit the first slide in inbox: SLICE-FileStream-StephaneDucasse.1 >> >> Can someone take a look please because is this quite "important" to >> integrate. > > StandardFileStream >> #readInto:startingAt:count: is wrong, there's a > newer version. StandardFileStream >> #skip: is missing. > The changes for MultiByteFileStream are also missing. Without those, the > files' state may become corrupt and the expected system-wide speedup will > be less significant. > Changes of classes other than StandardFileStream are unrelated to the read > buffering in the slice. There's also a new version of StandardFileStream >> #upTo: in the trunk, which still begs for a cleanup (I wonder who thought that recursion combined with #, will be fast). Levente > > Levente > >> >> Thanks >> >> Mariano >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 15, 2010

Re: [Pharo-project] FileStream Squeak harvested

by Mariano Martinez Peck

On Fri, Jan 15, 2010 at 7:14 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > On Fri, 15 Jan 2010, Mariano Martinez Peck wrote: > > Hi: Today Stef and I have being harvested Squeak changes in FileStream. >> The >> most important is the work from Levente and the buffer. >> >> We commit the first slide in inbox: SLICE-FileStream-StephaneDucasse.1 >> >> Can someone take a look please because is this quite "important" to >> integrate. >> > > StandardFileStream >> #readInto:startingAt:count: is wrong, there's a newer > version. StandardFileStream >> #skip: is missing. > The changes for MultiByteFileStream are also missing. Without those, the > files' state may become corrupt and the expected system-wide speedup will be > less significant. > Changes of classes other than StandardFileStream are unrelated to the read > buffering in the slice. > > Thanks Levetente. That explains the emergency windows we got :) Ok...we will give another round. Thanks for this code!! Mariano > > Levente > > >> Thanks >> >> Mariano >> >>

Jan. 15, 2010

Re: [Pharo-project] FileStream Squeak harvested

by Levente Uzonyi

On Fri, 15 Jan 2010, Mariano Martinez Peck wrote: > Hi: Today Stef and I have being harvested Squeak changes in FileStream. The > most important is the work from Levente and the buffer. > > We commit the first slide in inbox: SLICE-FileStream-StephaneDucasse.1 > > Can someone take a look please because is this quite "important" to > integrate. StandardFileStream >> #readInto:startingAt:count: is wrong, there's a newer version. StandardFileStream >> #skip: is missing. The changes for MultiByteFileStream are also missing. Without those, the files' state may become corrupt and the expected system-wide speedup will be less significant. Changes of classes other than StandardFileStream are unrelated to the read buffering in the slice. Levente > > Thanks > > Mariano >

Jan. 15, 2010