[Pharo-project] FileStream Squeak harvested
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. Thanks Mariano
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
On Fri, Jan 15, 2010 at 7:14 PM, Levente Uzonyi <leves@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
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/1/15 Levente Uzonyi <leves@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Fri, 15 Jan 2010, Nicolas Cellier wrote:
2010/1/15 Levente Uzonyi <leves@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
I'm not about to fix it. The method comment made me think, that #upTo: is used by #nextChunk, so I added the check for the simple case, but later realized that #nextChunk doesn't use #upTo:, because it can't, so I just kept the fallback code. (The bug was unnoticed for more than a month, so I guess #upTo: is not used at all, I found it while I was reviewing the code.) Levente
Nicolas
Levente
Thanks
Mariano
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
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).
:)
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. 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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/1/15 Stéphane Ducasse <stephane.ducasse@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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.
sure now I do not know what is the semantics of proceed. is it stop? Stef
ok I imagine that this is this change. Name: Monticello-nice.342 Author: nice Time: 27 December 2009, 9:03:54 am UUID: ead29222-29d3-421a-8d89-08d667014c1c Ancestors: Monticello-bf.341 change #findSnapshotWithVersionInfo: to silently ignore a missing ancestor rather than sending #snapshot to nil. This happens for example when merging Pharo/CollectionTests. Don't know if this is the good strategy though (maybe a notification could be signalled) + Cosmetic: move or remove a few temps inside closures
2010/1/15 Stéphane Ducasse <stephane.ducasse@inria.fr>:
ok I imagine that this is this change.
Yes, comments are such good things ! You shall prefer to have a proceedable exception in pharo and keep an explicit message...
Name: Monticello-nice.342 Author: nice Time: 27 December 2009, 9:03:54 am UUID: ead29222-29d3-421a-8d89-08d667014c1c Ancestors: Monticello-bf.341
change #findSnapshotWithVersionInfo: to silently ignore a missing ancestor rather than sending #snapshot to nil. This happens for example when merging Pharo/CollectionTests. Don't know if this is the good strategy though (maybe a notification could be signalled)
+ Cosmetic: move or remove a few temps inside closures
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Fri, 15 Jan 2010, Stéphane Ducasse wrote:
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.
Indeed, noone wants the latter, because it limits the range of changes available.
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 ->
This is the bug I was talking about. It's a bug, since viewing the changes is indepentent of the ancestors.
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?
MC shows you the ancestors of the currently loaded package (normal style, no undelines, not bold). There's also the history button which shows all ancestors with their commit messages, UUIDs, etc. Levente
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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.
Indeed, noone wants the latter, because it limits the range of changes available.
But I would pay to have that possibility (but it will not possible in Smalltalk since Smalltalk does not have a declarative model of execution).
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 ->
This is the bug I was talking about. It's a bug, since viewing the changes is indepentent of the ancestors.
Ok then I will have a look.
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?
MC shows you the ancestors of the currently loaded package (normal style, no undelines, not bold). There's also the history button which shows all ancestors with their commit messages, UUIDs, etc.
Levente
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (4)
-
Levente Uzonyi -
Mariano Martinez Peck -
Nicolas Cellier -
Stéphane Ducasse