FileStream Squeak harvested
Locked
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: FileStream Squeak harvested
|
|
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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: FileStream Squeak harvested
|
|
On Fri, Jan 15, 2010 at 7:14 PM, Levente Uzonyi <[hidden email]> wrote:
Thanks Levetente. That explains the emergency windows we got :) Ok...we will give another round. Thanks for this code!! Mariano
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: FileStream Squeak harvested
|
|
In reply to this post by Levente Uzonyi-2
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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: FileStream Squeak harvested
|
|
2010/1/15 Levente Uzonyi <[hidden email]>:
> 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: FileStream Squeak harvested
|
|
On Fri, 15 Jan 2010, Nicolas Cellier wrote:
> 2010/1/15 Levente Uzonyi <[hidden email]>: >> 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 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 >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: FileStream Squeak harvested
|
|
In reply to this post by Levente Uzonyi-2
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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: FileStream Squeak harvested
|
|
In reply to this post by Levente Uzonyi-2
>>>
>> >> 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). :) _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: FileStream Squeak harvested
|
|
In reply to this post by Levente Uzonyi-2
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: FileStream Squeak harvested
|
|
In reply to this post by Stéphane Ducasse
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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: FileStream Squeak harvested
|
|
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 >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: FileStream Squeak harvested
|
|
2010/1/15 Stéphane Ducasse <[hidden email]>:
> > 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 >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: FileStream Squeak harvested
|
|
In reply to this post by Stéphane Ducasse
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. 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 >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: FileStream Squeak harvested
|
|
In reply to this post by Nicolas Cellier
>>
> > 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: FileStream Squeak harvested
|
|
In reply to this post by Levente Uzonyi-2
>>>
>>>> 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 >>>>> [hidden email] >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: FileStream Squeak harvested
|
|
In reply to this post by Nicolas Cellier
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: FileStream Squeak harvested
|
|
2010/1/15 Stéphane Ducasse <[hidden email]>:
> 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |