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

Re: [Pharo-project] FileStream Squeak harvested

by Nicolas Cellier

2010/1/15 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > On Jan 15, 2010, at 9:50 PM, Levente Uzonyi wrote: > >> On Fri, 15 Jan 2010, StÃ©phane Ducasse wrote: >> >>> thanks levente. >>> >>> Now since this can also help squeak people. The trunk does not contain the complete history so this breaks monticello >>> then browsing history. In pharo we pay attention to get **all** the ancestor chain for such a kind of analysis. >> >> I don't get you. The trunk allows you to rebuild an image from 3.10.2 to the actual state, so it contains the complete history since 3.10.2. > > There is a huge difference between been able to build an image as a list of changes apply to the previous snapshot from > apply the last version of package to the original image. We learned that the hard way doing 3.9. > > Now this was not my point. My point is that MC like to have all the ancestors when we use merge in the history panel. > if you click on File-ul.58.mcz then History you get the list with all the ancestors but some of them are not on the repository > so you cannot view changes -> > >> IIRC this MC bug has been fixed in the trunk. > > ok what is the logic to find that File.31 was the ancestor of File.47? > If this is the just to take the next matching number I prefer to get a pop up saying that 46 is not found. > Because MC is a distributed version system so you should not take the hypothesis that all the versions are in the same > repository. So I'm curious to know if we talk about the same. > > Stef I find MC a bit pedantic sometimes. I think this happens when we merged a private version somewhere on someone disk with a trunk version then published. MC keep track of the merged private version and insist on having this branch when we further merge in Pharo. FYI, exactly the same happened to me when I tried to merge some Pharo version in squeak (an obscure DamienCassou branch was missing in pharo repository, can't remember which package though...). Instead of complaining instructively, MC was sending snapshot to nil... I just let it ignore the problem. In Pharo, you choosed to signal the problem with an explicit message, maybe that help fixing wrong configurations, but sometimes you should just have the option to ignore and proceed. Nicolas >> >>> >>> Stef >>> >>> On Jan 15, 2010, at 7:14 PM, 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. >>>> >>>> >>>> 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 >> _______________________________________________ >> 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 StÃ©phane Ducasse

romain I really like that you use another layer for meta action like the dashboard this is good because else the browser will get more complex and right now the infrastructure of browser is not as cool as it could be.

Jan. 15, 2010

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

by StÃ©phane Ducasse

>> Taking a look at that, there are 2 overrides in WorkingSet > > PasteupMorph>>keystrokeInWorld: > but the diff is the same with my default version! So it can be removed > > HandMorph>>sendKeyboardEvent: > which is the real conflicting method > > Looking at it, there are 3 different versions, the default one, one from WorkingSet and one from Algernon. On the plus sign, it's quite easy to merge the last two and make WorkingSet works together with Algernon. > > > But the one from Algernon is actually the worst way to patch things, because it is all in a changeset which is encoded in binary format (see ConfigurationOfAlgernons>>multipleFocusHolderCs :( > > It adds an instance variable to HandMorph and overrides two methods in HandMorph. Of course you cant see it at first since these are hidden in the binary changeset :( what is a binary changeset > > '''From Squeak3.7gamma of ''''17 July 2004'''' [latest update: #5985] on 9 August 2004 at 7:56:10 pm''! > "Change Set: MultipleFocusHolder-hpt > Date: 9 August 2004 > Author: Hernan Tylim > > This changesets does the simplest modifications to HandMorph for it to support various focus holders. > > The important changes are: > > * addiionalKeyboardFocuses instance variable was added with its getter and setter methods. > > * HandMorph>>sendKeyboardEvent: was changed to traverse the list of keyboard focus holders and call HandMorph>>sendEvent:focus:clear: to each one of them. > > * HandMorph>>sendEvent:focus:clear: was changed to preserve the ''wasHandled'' status of the event, before that info were lost because the Event instance were copied before passed to the Morph. > "! > > The comment itself is misleading, it overrides sendFocusEvent:to:clear:, not sendEvent:focus:clear: > > I feel much less keen to include Algernon now that I have seen that. Yes. We should pay attention because we can have a lot of hackishi code.

Jan. 15, 2010

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

by Simon Denier

On 15 janv. 2010, at 21:20, Mariano Martinez Peck wrote: > > > 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. Taking a look at that, there are 2 overrides in WorkingSet PasteupMorph>>keystrokeInWorld: but the diff is the same with my default version! So it can be removed HandMorph>>sendKeyboardEvent: which is the real conflicting method Looking at it, there are 3 different versions, the default one, one from WorkingSet and one from Algernon. On the plus sign, it's quite easy to merge the last two and make WorkingSet works together with Algernon. But the one from Algernon is actually the worst way to patch things, because it is all in a changeset which is encoded in binary format (see ConfigurationOfAlgernons>>multipleFocusHolderCs :( It adds an instance variable to HandMorph and overrides two methods in HandMorph. Of course you cant see it at first since these are hidden in the binary changeset :( '''From Squeak3.7gamma of ''''17 July 2004'''' [latest update: #5985] on 9 August 2004 at 7:56:10 pm''! "Change Set: MultipleFocusHolder-hpt Date: 9 August 2004 Author: Hernan Tylim This changesets does the simplest modifications to HandMorph for it to support various focus holders. The important changes are: * addiionalKeyboardFocuses instance variable was added with its getter and setter methods. * HandMorph>>sendKeyboardEvent: was changed to traverse the list of keyboard focus holders and call HandMorph>>sendEvent:focus:clear: to each one of them. * HandMorph>>sendEvent:focus:clear: was changed to preserve the ''wasHandled'' status of the event, before that info were lost because the Event instance were copied before passed to the Morph. "! The comment itself is misleading, it overrides sendFocusEvent:to:clear:, not sendEvent:focus:clear: I feel much less keen to include Algernon now that I have seen that. > > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Simon

Jan. 15, 2010

[Pharo-project] VB-Regex News

by Lukas Renggli

Gofer new renggli: 'unsorted'; package: 'VB-Regex'; load - The VB-Regex engine has 160 new SUnit tests that cover 88% of the code-base. A few tests I wrote myself, but most of it comes from the class-side of RxParser that had an ad-hock test suite that painfully logged its results to the transcript. - I fixed the issue with the duplicated matches that was reported here <http://code.google.com/p/pharo/issues/detail?id=1747>. Unfortunately Vassili Bykov did not answer my questions. The fix is quite ugly and I had to rewrite most of the logic in RxMatcher. The test pass, but there might be new bugs. - The bad news is that matching is roughly 7% slower. I guess that's the price to pay for correct results. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Jan. 15, 2010

Re: [Pharo-project] FileStream Squeak harvested

by StÃ©phane Ducasse

On Jan 15, 2010, at 9:50 PM, Levente Uzonyi wrote: > On Fri, 15 Jan 2010, StÃ©phane Ducasse wrote: > >> thanks levente. >> >> Now since this can also help squeak people. The trunk does not contain the complete history so this breaks monticello >> then browsing history. In pharo we pay attention to get **all** the ancestor chain for such a kind of analysis. > > I don't get you. The trunk allows you to rebuild an image from 3.10.2 to the actual state, so it contains the complete history since 3.10.2. There is a huge difference between been able to build an image as a list of changes apply to the previous snapshot from apply the last version of package to the original image. We learned that the hard way doing 3.9. Now this was not my point. My point is that MC like to have all the ancestors when we use merge in the history panel. if you click on File-ul.58.mcz then History you get the list with all the ancestors but some of them are not on the repository so you cannot view changes -> > IIRC this MC bug has been fixed in the trunk. ok what is the logic to find that File.31 was the ancestor of File.47? If this is the just to take the next matching number I prefer to get a pop up saying that 46 is not found. Because MC is a distributed version system so you should not take the hypothesis that all the versions are in the same repository. So I'm curious to know if we talk about the same. Stef > >> >> Stef >> >> On Jan 15, 2010, at 7:14 PM, 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. >>> >>> >>> 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 > _______________________________________________ > 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

[Pharo-project] Last failing tests in OB and EC

by Mariano Martinez Peck

Hi: Sorry to bother you again, I am tryng to get all green tests for next PharoDev image. I have one test failing in OB and one in EC ECUntypedModelTest >> testNarrowWith fails in self assert: count > 100. because count is 98 OBButtonBarTest >> testLayout fails in self assert: rects third right <= bar right because "rects third right " is 402 and "bar right" is 400. Any ideas how to make them green or remove them if are obsolete? Thanks Mariano

Jan. 15, 2010

Re: [Pharo-project] FileStream Squeak harvested

by Levente Uzonyi

On Fri, 15 Jan 2010, StÃ©phane Ducasse wrote: > thanks levente. > > Now since this can also help squeak people. The trunk does not contain the complete history so this breaks monticello > then browsing history. In pharo we pay attention to get **all** the ancestor chain for such a kind of analysis. I don't get you. The trunk allows you to rebuild an image from 3.10.2 to the actual state, so it contains the complete history since 3.10.2. IIRC this MC bug has been fixed in the trunk. Levente > > Stef > > On Jan 15, 2010, at 7:14 PM, 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. >> >> >> 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] About RemoteString>>checksum:

by StÃ©phane Ducasse

It does in 11161. Strange, do you have a different version? Stef On Jan 15, 2010, at 9:12 PM, Nicolas Cellier wrote: > 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 >> > > _______________________________________________ > 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 StÃ©phane Ducasse

at one point is the past I did the project to save in VW format all Squeak versions because I wanted to be able to analyse version evolution as a research topics. (I went up to 1.1 and I could load all squeak version in VW -- not run them). Nobody in the team decided it was worth to have a look and the same people did Jboss analysis- power of marketing and relevance. Anyway what was terrible is to see the way allButLast and other terrible code is used to push/get remotestring and other beast like saving h3 everywhere. This code broke on each version. Stef

Jan. 15, 2010