May 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Filetree and merging

by phil＠highoctane.be

On Tue, May 27, 2014 at 9:21 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > > 2014-05-27 20:41 GMT+02:00 Johan Brichau <johan(a)inceptive.be>: > >> Have you tried this? >> >> https://github.com/ThierryGoubier/GitFileTree-MergeDriver >> >> Not sure about the ^M problem though... >> >> Johan >> >> > I second this, with GitFileTree it solves most problems of false conflicts > caused by MC metadata. > For true conflicts, I did not inquire. > Ok, will have a look. At first sight, it looks scary and less friendly than a plain old MCZ merge. But... git is the standard and it is painful to have to maintain things in two places... Phil > > >> On 27 May 2014, at 20:38, phil(a)highoctane.be wrote: >> >> > Hello, >> > >> > I am working with Sebastian on some code and we tried out filetree:// >> > >> > We have our packages saved there on disk and then we commit/push them >> on the git server. >> > >> > Now, as we develop and then need to merge, I find it hard to do those >> merges on the .st files. >> > >> > As ^M is used as separator, the merge tools seem to have a difficult >> time and show us 2 huge lines. >> > >> > What is the current best practice for merging packages that way? >> > >> > TIA >> > Phil >> >> >> >

May 27, 2014

Re: [Pharo-dev] Filetree and merging

by Nicolas Cellier

2014-05-27 20:41 GMT+02:00 Johan Brichau <johan(a)inceptive.be>: > Have you tried this? > > https://github.com/ThierryGoubier/GitFileTree-MergeDriver > > Not sure about the ^M problem though... > > Johan > > I second this, with GitFileTree it solves most problems of false conflicts caused by MC metadata. For true conflicts, I did not inquire. > On 27 May 2014, at 20:38, phil(a)highoctane.be wrote: > > > Hello, > > > > I am working with Sebastian on some code and we tried out filetree:// > > > > We have our packages saved there on disk and then we commit/push them on > the git server. > > > > Now, as we develop and then need to merge, I find it hard to do those > merges on the .st files. > > > > As ^M is used as separator, the merge tools seem to have a difficult > time and show us 2 huge lines. > > > > What is the current best practice for merging packages that way? > > > > TIA > > Phil > > >

May 27, 2014

OS/2 Smalltalks

by blake

Cleaning out the garage I came across copies of Digitalk's, IBM's and (I think) ParcPlace's Smalltalks for OS/2. If there's any interest in these dinosaurs, let me know, else they will be recycled.... ===Blake===

May 27, 2014

Re: [Pharo-dev] [squeak-dev] Re: String >> #=

by Eliot Miranda

On Tue, May 27, 2014 at 6:54 AM, J. Vuletich (mail lists) < juanlists(a)jvuletich.org> wrote: > Quoting Eliot Miranda <eliot.miranda(a)gmail.com>: > > Hi Phillipe, > > > On Mon, May 26, 2014 at 12:51 AM, Philippe Marschall < > philippe.marschall(a)netcetera.ch> wrote: > >> Hi >> >> I have been investigating why Dictionary look up performance with String >> keys is not as good as I would expected. Something I noted is that String >> >> #= is implemented in terms of #compare:with:collated:. There is no short >> circuit if Strings are not the same size. In my case some Strings have the >> same prefix but a different length eg 'Content-Type' and 'Content-Length'. >> In that case a #compare:with:collated: is performed even though we know in >> advance the answer will be false because they have different sizes. >> > > Why not rewrite > > String>>= aString > "Answer whether the receiver sorts equally as aString. > The collation order is simple ascii (with case differences)." > aString isString ifFalse: [ ^ false ]. > ^ (self compare: self with: aString collated: AsciiOrder) = 2 > > as > > String>>= aString > "Answer whether the receiver sorts equally as aString. > The collation order is simple ascii (with case differences)." > > (aString isString > and: [self size = aString size]) ifFalse: [^false]. > ^ (self compare: self withSize: with: aString collated: AsciiOrder) = 2 > > ? > > This makes a huge difference, over 3 times faster: | bs t1 t2 | bs := ByteString allInstances first: 10000. t1 := [bs do: [:a| bs do: [:b| a = b]]] timeToRun. (FileStream fileNamed: '/Users/eliot/Squeak/Squeak4.5/String-=.st') fileIn. t2 := [bs do: [:a| bs do: [:b| a = b]]] timeToRun. { t1. t2 } #(13726 4467) 4467 - 13726 / 137.26 -67.46% > > One /could/ add a replacement compare:with:collated: > primitive primitiveCompareString which took the sizes as arguments to avoid > asking twice. But it wouldn't be safe. One could abuse the primitive and > lie about the size. So I suspect it is best to add the size check to > String>>#= and accept the duplication of the primitive finding the sizes of > the two strings. The cost in the primitive is minimal. A WideString > version of the primitive might pay its way, but if Spur and Sista arrive > soon the primitive shouldn't be faster than the optimised Smalltalk code. > -- > best, > Eliot > > BTW, any good reason for not prefixing all the implementors of #= with > this? > > "Any object is equal to itself" > self == argument ifTrue: [ ^ true ]. > It doesn't make much difference: | bs t1 t2 | bs := ByteString allInstances first: 10000. t1 := [bs do: [:a| bs do: [:b| a = b]]] timeToRun. (FileStream fileNamed: '/Users/eliot/Squeak/Squeak4.5/String-=.st') fileIn. t2 := [bs do: [:a| bs do: [:b| a = b]]] timeToRun. { t1. t2 } #(4628 4560) 4560 - 4628 / 46.28 -1.47% So is it worth it? If you feel it is I've no objection other than it feels a little kludgey for such little benefit. And there are the Symbols if one needs quick comparison and can bear the cost of slow interning. -- best, Eliot

May 27, 2014

Re: [Pharo-dev] Filetree and merging

by Johan Brichau

Have you tried this? https://github.com/ThierryGoubier/GitFileTree-MergeDriver Not sure about the ^M problem though... Johan On 27 May 2014, at 20:38, phil(a)highoctane.be wrote: > Hello, > > I am working with Sebastian on some code and we tried out filetree:// > > We have our packages saved there on disk and then we commit/push them on the git server. > > Now, as we develop and then need to merge, I find it hard to do those merges on the .st files. > > As ^M is used as separator, the merge tools seem to have a difficult time and show us 2 huge lines. > > What is the current best practice for merging packages that way? > > TIA > Phil

May 27, 2014

Filetree and merging

by phil＠highoctane.be

Hello, I am working with Sebastian on some code and we tried out filetree:// We have our packages saved there on disk and then we commit/push them on the git server. Now, as we develop and then need to merge, I find it hard to do those merges on the .st files. As ^M is used as separator, the merge tools seem to have a difficult time and show us 2 huge lines. What is the current best practice for merging packages that way? TIA Phil

May 27, 2014

Re: [Pharo-dev] OSProcess tests (was: Coral is green)

by phil＠highoctane.be

On Tue, May 27, 2014 at 6:45 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > David T. Lewis wrote > > I am guessing that you may have been doing something that resulted in > > unclosed file handles, which eventually will cause a failure when > > the OS resource limits are exceeded. > > Yes, I've run into that quite a bit. IIRC remembering to "proc close; > closePipes" does the trick... > > Duly noted! > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Coral-is-green-tp4759893p4760543.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

May 27, 2014

Re: [Pharo-dev] OSProcess tests (was: Coral is green)

by Sean P. DeNigris

David T. Lewis wrote > I am guessing that you may have been doing something that resulted in > unclosed file handles, which eventually will cause a failure when > the OS resource limits are exceeded. Yes, I've run into that quite a bit. IIRC remembering to "proc close; closePipes" does the trick... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Coral-is-green-tp4759893p4760543.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 27, 2014

Re: [Pharo-dev] [squeak-dev] Re: String >> #=

by J. Vuletich (mail lists)

Quoting Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi Phillipe, > > > On Mon, May 26, 2014 at 12:51 AM, Philippe Marschall > <philippe.marschall(a)netcetera.ch> wrote: > >> Hi >> >> I have been investigating why Dictionary look up performance with >> String keys is not as good as I would expected. Something I noted is >> that String >> #= is implemented in terms of #compare:with:collated:. >> There is no short circuit if Strings are not the same size. In my case >> some Strings have the same prefix but a different length eg >> 'Content-Type' and 'Content-Length'. In that case a >> #compare:with:collated: is performed even though we know in advance the >> answer will be false because they have different sizes. > > Â > Why not rewrite > Â > String>>= aStringÂ > "Answer whether the receiver sorts equally as aString. > The collation order is simple ascii (with case differences)." > aString isString ifFalse: [ ^ false ]. > ^ (self compare: self with: aString collated: AsciiOrder) = 2 > Â > as > Â > String>>= aStringÂ > "Answer whether the receiver sorts equally as aString. > The collation order is simple ascii (with case differences)." > Â > (aString isString > and: [self size = aString size]) ifFalse: [^false]. > ^ (self compare: self withSize: with: aString collated: > AsciiOrder) = 2 > > Â > ? > > Â > One /could/ add a replacement compare:with:collated: > primitiveÂ primitiveCompareString which took the sizes as arguments to > avoid asking twice. Â But it wouldn't be safe. Â One could abuse the > primitive and lie about the size. Â So I suspect it is best to add the > size check to String>>#= and accept the duplication of > theÂ primitiveÂ finding the sizes of the two strings. Â The cost in the > primitive is minimal. Â A WideString version of the primitive might pay > its way, but if Spur and Sista arrive soon the primitive shouldn't be > faster than the optimised Smalltalk code. > -- > best, Eliot BTW, any good reason for not prefixing all the implementors of #= with this? "Any object is equal to itself" self == argument ifTrue: [ ^ true ]. Cheers, Juan Vuletich

May 27, 2014

Re: [Pharo-dev] String >> #=

by Philippe Marschall

On 26.05.14 09:51, Philippe Marschall wrote: > Hi > > I have been investigating why Dictionary look up performance with String > keys is not as good as I would expected. Something I noted is that > String >> #= is implemented in terms of #compare:with:collated:. There > is no short circuit if Strings are not the same size. In my case some > Strings have the same prefix but a different length eg 'Content-Type' > and 'Content-Length'. In that case a #compare:with:collated: is > performed even though we know in advance the answer will be false > because they have different sizes. Some follow up on this: In Seaside we have a custom dictionary GRSmallDictionary which is more or less an OrderedCollection of Associations (not actually but conceptually). I did a microbenchmark with 11 keys [1] and out of the box Dictionary is about twice as fast as GRSmallDictionary. However when I change GRSmallDictionary to first send and compare #size before sending #= then GRSmallDictionary is slightly faster than Dictionary. [1] #('Content-Type' 'Content-Language' 'Content-Length' 'Date' 'Last-Modified' 'Location' 'Set-Cookie' 'Set-Cookie2' 'Servlet-Engine' 'Status' 'WWW-Authenticate') Cheers Philippe

May 27, 2014