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

Re: [Pharo-project] Changesets with LF/CRLF instead of CR?

by Schwab,Wilhelm K

A possible wrinkle: what about using Linux to write a file for a Windows user? ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Stefan Marr [pharo(a)stefan-marr.de] Sent: Tuesday, November 30, 2010 7:13 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Changesets with LF/CRLF instead of CR? Hello: On 30 Nov 2010, at 09:20, StÃ©phane Ducasse wrote: > as a general principle, I'm open to change for the better :) > Now how much? > - cost to do Cleaning it up completely does not looks like a simple/localized change to a single method. There are 'aFileStream cr' message sends all over the place, which from my perspective are wrong in the sense that they are not platform independent. I guess the best way would be to have something like 'aFileStream nl' or 'lineEnd' instead. Where nl/lineEnd uses MultiByteFileStream LineEndDefault. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Nov. 30, 2010

Re: [Pharo-project] Issue 3354 in pharo: Clean of RecentMessageList

by pharo＠googlecode.com

Updates: Status: Closed Comment #4 on issue 3354 by marcus.denker: Clean of RecentMessageList http://code.google.com/p/pharo/issues/detail?id=3354 12265

Nov. 30, 2010

Re: [Pharo-project] Issue 3361 in pharo: CompiledMethod's copy

by pharo＠googlecode.com

Comment #1 on issue 3361 by gbarbuto: CompiledMethod's copy http://code.google.com/p/pharo/issues/detail?id=3361 Published SLICE-Issue-3361-CompiledMethods-copy-GabrielBarbuto.1 to Pharo Inbox that allows to duplicate a CompiledMethod.

Nov. 30, 2010

Re: [Pharo-project] Changesets with LF/CRLF instead of CR?

by Alain Plantec

Le 30/11/2010 13:13, Stefan Marr a Ã©crit : > > Cleaning it up completely does not looks like a simple/localized change to a single method. > > There are 'aFileStream cr' message sends all over the place, which from my perspective are wrong in the sense that they are not platform independent. I guess the best way would be to have something like 'aFileStream nl' or 'lineEnd' instead. Where nl/lineEnd uses MultiByteFileStream LineEndDefault. maybe eol for end of line ? Alain > Best regards > Stefan >

Nov. 30, 2010

[Pharo-project] Issue 3361 in pharo: CompiledMethod's copy

by pharo＠googlecode.com

Status: Accepted Owner: gbarbuto New issue 3361 by gbarbuto: CompiledMethod's copy http://code.google.com/p/pharo/issues/detail?id=3361 Pharo image: core Pharo core version: Pharo1.2a Latest update: #12264 Virtual machine used: <any Steps to reproduce: 1. Try to completely copy a CompiledMethod and the copy still have references to the original CompiledMethod.

Nov. 30, 2010

Re: [Pharo-project] Issue 3354 in pharo: Clean of RecentMessageList

by pharo＠googlecode.com

Comment #3 on issue 3354 by Benjamin.VanRyseghem.Pharo: Clean of RecentMessageList http://code.google.com/p/pharo/issues/detail?id=3354 I do not know why the version 52 is missing, but I just posted a new version based on 51, you shouldn't have this problem anymore. Now you can get it from the both repository: Gofer new squeaksource: 'PharoInbox'; package: 'RecentSubmissions'; load. or Gofer new squeaksource: 'PharoTaskForces'; package: 'RecentSubmissions'; load.

Nov. 30, 2010

Re: [Pharo-project] Changesets with LF/CRLF instead of CR?

by Stefan Marr

Hello: On 30 Nov 2010, at 09:20, StÃ©phane Ducasse wrote: > as a general principle, I'm open to change for the better :) > Now how much? > - cost to do Cleaning it up completely does not looks like a simple/localized change to a single method. There are 'aFileStream cr' message sends all over the place, which from my perspective are wrong in the sense that they are not platform independent. I guess the best way would be to have something like 'aFileStream nl' or 'lineEnd' instead. Where nl/lineEnd uses MultiByteFileStream LineEndDefault. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Nov. 30, 2010

Re: [Pharo-project] TextConverter handling of binary streams

by Sven Van Caekenberghe

On 30 Nov 2010, at 12:20, StÃ©phane Ducasse wrote: > fix fix fix :) I created issue #3360. I already knew that you would be asking for code, so yesterday I wrote an alternative UTF-8 encoder as a support class to Zinc HTTP Components. The problem is that what we are now calling 'wrong' seems to be added 'by design'. The question is why and what will be the impact of changing that behavior ? Sven

Nov. 30, 2010

[Pharo-project] Issue 3360 in pharo: TextConverter handling of binary streams is wrong

by pharo＠googlecode.com

Status: New Owner: ---- New issue 3360 by sven.van.caekenberghe: TextConverter handling of binary streams is wrong http://code.google.com/p/pharo/issues/detail?id=3360 It seems that the way binary (#isBinary true) streams are handled by TextConverter and its subclasses is wrong. When given a binary stream, the core text converter methods (#nextPut:toStream and #nextFromStream:) simply do no longer encode or decode at all. Moreover, the unit test UTF8TextConverter>>#testPutSingleCharacter seems plain wrong. The actual encoded bytes should be #[97 226 130 172]. However, this behavior seems to be added by design, so it is hard to estimate the impact of changing this. It is currently very ugly to get a binary UTF-8 encoding, one has to write to a character stream and then turn those characters into bytes. I wrote an alternative UTF-8 encoder as a support class to the Zinc HTTP Components (http://www.squeaksource.com/ZincHTTPComponents.html) together with the following unit test: testUTF8Encoder "The examples are taken from http://en.wikipedia.org/wiki/UTF-8#Description" | encoder inputBytes outputBytes inputString outputString | encoder := ZnUTF8Encoder new. inputString := String with: $$ with: (Unicode value: 16r00A2) with: (Unicode value: 16r20AC) with: (Unicode value: 16r024B62). inputBytes := #[16r24 16rC2 16rA2 16rE2 16r82 16rAC 16rF0 16rA4 16rAD 16rA2]. outputBytes := self encodeString: inputString with: encoder. self assert: outputBytes = inputBytes. outputString := self decodeBytes: inputBytes with: encoder. self assert: outputString = inputString based on the helper methods: encodeString: string with: encoder ^ ByteArray streamContents: [ :stream | string do: [ :each | encoder nextPut: each toStream: stream ] ] decodeBytes: bytes with: encoder | input | input := bytes readStream. ^ String streamContents: [ :stream | [ input atEnd ] whileFalse: [ stream nextPut: (encoder nextFromStream: input) ] ] The new encoder code is simpler, but might not handle everything that is needed (leading chars, language codes), but is all that still needed ? Sven

Nov. 30, 2010

Re: [Pharo-project] Ideas for CompiledMethod proxies?

by Levente Uzonyi

On Tue, 30 Nov 2010, Mariano Martinez Peck wrote: > On Sun, Nov 21, 2010 at 5:31 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> Obviously you can't having a single object representation (a tagged >> machine word with lowest bit set) >> and have two different classes for it. >> >> > Yes, that's true. The thing is that I have a big problem using SmallInteger > as proxies....So far I always used a subclass of ProtoObject for the > proxies. This is cool because most of the messages are not understood by > ProtoObject, thus I can intercept most messages. Now, the problem using > SmallInteger as proxies is that there are several methods that ARE > understood by both. This is a big problem because the original > CompiledMethod is not installed, and the method answers but with a different > value. > > For example, suppose I do something like this: > > MyClass methodDict at: #foo put: 5. > (MyClass >> #foo) size > > In this case, I would like that size is NOT understood by the proxy and that > loads back the original compiled method. But this is not the case since > SmallIngeger DOES understand the message #size. Thus, it answers...and > something different than the size of the compiled method... That's why you should change MethodDictionary >> #at:ifAbsent: to load the CompiledMethod and return that instead of the integer. Levente > > So in summary I have problems with all methods that are understood by both, > even all those in Object I think... > > Best regards, > > Mariano > > > >> On 21 November 2010 16:51, Mariano Martinez Peck <marianopeck(a)gmail.com> >> wrote: >>> >>> >>> On Sun, Nov 21, 2010 at 12:13 AM, Levente Uzonyi <leves(a)elte.hu> wrote: >>>> >>>> On Sat, 20 Nov 2010, Mariano Martinez Peck wrote: >>>> >>>>> On Sat, Nov 20, 2010 at 5:41 PM, Levente Uzonyi <leves(a)elte.hu> wrote: >>>>>> >>>>>> The only problem is that you can't swap-out a method that's used by >> the >>>>>> swap-in code. >>>>>> >>>>>> >>>>> Yes, but that's easy to solve. Before swapping everything, I "simulate" >>>>> the >>>>> swapping of a dummy CompiledMethod. During that, I mark all the >>>>> CompiledMethods that were used to perform that. And then, I exclude >> those >>>>> objects from being swapped :) >>>> >>>> That won't work, because during the simulation you'll only try a single >>>> execution path. Swapping in a real method may invoke methods that >> weren't >>>> used during the simulation. For example my implementation uses >> #storeString >>>> to serialize the methods and Compiler >> #evaluate: to deserialize them. >> So >>>> during deserialization a lot of different methods may be invoked. >>> >>> Ahhh I got it.... >>> >>> Are you using Cog? because with the SmallInteger I have the problem I >>> described with #run:with:in: >>> >>> Last question....to use SmallIntegers, I need to put some methods in >>> SmallInteger, like #run:with:in: , #doesNotUnderstand: , and all the >>> methods related to writing and loading back the original compiledMethod. >> Of >>> course I can put all those methods under a category *MyProxyPackage ... >>> but I was thinking if there is another way. I would love to have >>> MySmallIntegerProxy that extends from ProtoObject (because I want my >> proxy >>> to understand as less messages as possible) and that is threated by the >> VM >>> like a SmallInetger, I mean, that it directly stores the number value in >> the >>> address, and put the last bit in 1. >>> >>> Is this possible? how much work can it be? >>> >>> Thanks in advance, >>> >>> Mariano >>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> >

Nov. 30, 2010