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

Re: [Pharo-project] What we should do with the Dev image? Re: question about O2 vs OB

by Mariano Martinez Peck

On Wed, Jan 20, 2010 at 2:38 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > I am very much in favor or providing ready choice in the browsers and > tools. It would also help to have the browswers somehow brand themselves. > Conversation here centers on things like O2 vs. OB, but there are at least > two O2 browswers (package and system). > This is exactly why having both browser is confusing a newcomer. If you cannot choose, you don't confuse :) > > I am probably most concerned about keeping the standard tool set which does > away with the new inspector and might have other favorable side effects. > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto: > pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Miguel Enrique > CobÃ¡ Martinez > Sent: Wednesday, January 20, 2010 12:20 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] What we should do with the Dev image? Re: > question about O2 vs OB > > El miÃ©, 20-01-2010 a las 17:44 +0100, Mariano Martinez Peck escribiÃ³: > > > > That's the reason of having OB and O2. While both now work > > together in the same image > > without inferring each other, this indeed increases the number > > of classes in the image > > quite a lot as they duplicate a whole bunch of code. So I > > strongly suggest to either use > > OB or O2, even though you can have both. But I do not see a > > reason why people want to > > switch between the two dynamically in the same image. > > > > > > > > We have two things to choose: which browser is default and which ones > > are installed. Both ? only one ? The solution I like most, is in > > these options: > > > > 1) Install both: OB and O2. Let OB as default. > > > > 2) Install only OB, of course, as default, and those who wants can > > install O2 in that dev image. They way to install O2 now is very easy. > > > > 3) Install only OB, of course, as default, but create a group in > > ConfigurationOfPharo like "StandardDevImageWithO2" so that those > > people who want a dev image with O2 can just evaluate that in a core > > image and wala! > > > > With 1 the image will be smaller but won't have O2 preinstalled. With > > 2) and 3) you will have also O2 but bigger image. > > > > I think I will coose 2) AND 3). Those who want to install O2 directly > > in a dev image, use the ConfigurationOfO2 and those who wants to > > create a dev image over the core, they use ConfigurationOfPharo with > > the new group I can create. > > I think that group are the way to go. A group for pharo dev with OB (and > only OB) a group with O2 (and only O2) a group with both (and this could be > the default because most new users won't have a preference). Also, this > avoid give any package preference over the other. > > Of course, the documentation for creating a dev image, should state clearly > the three options to build an image. > > my 2 cents > > > > > > > What do you think ? > > > > Mariano > > > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > 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. 20, 2010

Re: [Pharo-project] What we should do with the Dev image? Re: question about O2 vs OB

by Mariano Martinez Peck

On Wed, Jan 20, 2010 at 3:03 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Hi Mariano, > > > 2) Install only OB > > is a reasonable choice. We are very close to a 1.0 release and including OB > again at this point does not make sense. The risk for unknown bugs that we > needed to fix in maintenance releases of 1.0 is too high in my opinion. > > Thanks Adrian. I didn't want to say it, but yes. I think like you. WE NEED TO RELEASE 1.0 NOW!!!! and as much as stable possible. For new comers, I think it is even easier to have only one browser. Having two, bring to confussion, insecurity, etc. Once the newcomer stop to be newcomer, he will be able to install O2 by himself and take his own opinion on both browsers. And come on...that's the idea of Metacello!! that each people can load whatever they want. so.... +1 (ouch...I have already voted!) > However, when we start building images for 1.1 we should consider to add it > again. > > Cheers, > Adrian > > On Jan 20, 2010, at 17:44 , Mariano Martinez Peck wrote: > > >> That's the reason of having OB and O2. While both now work together in > the > >> same image > >> without inferring each other, this indeed increases the number of > classes > >> in the image > >> quite a lot as they duplicate a whole bunch of code. So I strongly > suggest > >> to either use > >> OB or O2, even though you can have both. But I do not see a reason why > >> people want to > >> switch between the two dynamically in the same image. > >> > >> > > > > We have two things to choose: which browser is default and which ones are > > installed. Both ? only one ? The solution I like most, is in these > options: > > > > 1) Install both: OB and O2. Let OB as default. > > > > 2) Install only OB, of course, as default, and those who wants can > install > > O2 in that dev image. They way to install O2 now is very easy. > > > > 3) Install only OB, of course, as default, but create a group in > > ConfigurationOfPharo like "StandardDevImageWithO2" so that those people > who > > want a dev image with O2 can just evaluate that in a core image and wala! > > > > With 1 the image will be smaller but won't have O2 preinstalled. With 2) > and > > 3) you will have also O2 but bigger image. > > > > I think I will coose 2) AND 3). Those who want to install O2 directly in > a > > dev image, use the ConfigurationOfO2 and those who wants to create a dev > > image over the core, they use ConfigurationOfPharo with the new group I > can > > create. > > > > What do you think ? > > > > 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. 20, 2010

Re: [Pharo-project] ocompletion bug fix

by Adrian Lienhard

It is best to create an issue in our tracker and put Romain Robbes, the maintainer of Ocompletion, in cc. Also post the issue URL to the mailing list. This problem, though, sounds familiar to me. Which versions are you using? You may find already closed reports of this problem in the tracker. Thanks, Adrian On Jan 20, 2010, at 18:59 , Sean Allen wrote: > I just fixed a bug that has been driving me crazy for a while in the > Ocompletion package. > > When you select an area of text and delete, if you are deleting all of > it, it throws a subscript out of bounds error. > > What is the proper process for getting this change integrated? > I'm not really sure who this small fix should be sent to. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 20, 2010

Re: [Pharo-project] What we should do with the Dev image? Re: question about O2 vs OB

by Adrian Lienhard

Hi Mariano, > 2) Install only OB is a reasonable choice. We are very close to a 1.0 release and including OB again at this point does not make sense. The risk for unknown bugs that we needed to fix in maintenance releases of 1.0 is too high in my opinion. However, when we start building images for 1.1 we should consider to add it again. Cheers, Adrian On Jan 20, 2010, at 17:44 , Mariano Martinez Peck wrote: >> That's the reason of having OB and O2. While both now work together in the >> same image >> without inferring each other, this indeed increases the number of classes >> in the image >> quite a lot as they duplicate a whole bunch of code. So I strongly suggest >> to either use >> OB or O2, even though you can have both. But I do not see a reason why >> people want to >> switch between the two dynamically in the same image. >> >> > > We have two things to choose: which browser is default and which ones are > installed. Both ? only one ? The solution I like most, is in these options: > > 1) Install both: OB and O2. Let OB as default. > > 2) Install only OB, of course, as default, and those who wants can install > O2 in that dev image. They way to install O2 now is very easy. > > 3) Install only OB, of course, as default, but create a group in > ConfigurationOfPharo like "StandardDevImageWithO2" so that those people who > want a dev image with O2 can just evaluate that in a core image and wala! > > With 1 the image will be smaller but won't have O2 preinstalled. With 2) and > 3) you will have also O2 but bigger image. > > I think I will coose 2) AND 3). Those who want to install O2 directly in a > dev image, use the ConfigurationOfO2 and those who wants to create a dev > image over the core, they use ConfigurationOfPharo with the new group I can > create. > > What do you think ? > > Mariano > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 20, 2010

[Pharo-project] ocompletion bug fix

by Sean Allen

I just fixed a bug that has been driving me crazy for a while in the Ocompletion package. When you select an area of text and delete, if you are deleting all of it, it throws a subscript out of bounds error. What is the proper process for getting this change integrated? I'm not really sure who this small fix should be sent to.

Jan. 20, 2010

Re: [Pharo-project] A dog-slow browser

by Adrian Lienhard

Ok, in the class Morph it is not really smooth, also on my MacBook Pro. I quickly did some profiling and came up with the following speedups (i.e., experimental hacks): Is it better now? Cheers, Adrian BTW, not GC makes it slow but often recomputing the method list. Also, button colors are computed expensively, even though they are not used. On Jan 20, 2010, at 17:56 , Levente Uzonyi wrote: > On Wed, 20 Jan 2010, Mariano Martinez Peck wrote: > >> On Wed, Jan 20, 2010 at 5:44 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: >> >>> Smalltalk garbageCollect >>> >> >> hahahaha sorry. As you said "a full GC" I imagined that there was another > > There is: incremental gc. You can trigger it with Smalltalk > garbageCollectMost. > > > Levente > >> kind of GC (like gemstine) that I was not aware of :) >> >> >>> >>> On Jan 20, 2010, at 17:37 , Mariano Martinez Peck wrote: >>> >>>> On Wed, Jan 20, 2010 at 5:33 PM, Adrian Lienhard <adi(a)netstyle.ch> >>> wrote: >>>> >>>>> just a wild guess: maybe its a GC edge case? >>>>> >>>>> When it happens, trigger a full GC and see if it is still slow... >>>>> >>>>> >>>> how do you do that Adrian ? >>>> >>>> >>>>> Adrian >>>>> >>>>> On Jan 20, 2010, at 17:26 , Gary Chambers wrote: >>>>> >>>>>> A good few months back I noticed similarly inexplicable slowness (that >>> I >>>>>> mistakenly ascribed to some changes...). Went away after image >>>>>> save/restart... maybe that kind of thing has happened. >>>>>> >>>>>> Regards, Gary >>>>>> >>>>>> ----- Original Message ----- >>>>>> From: "Igor Stasenko" <siguctua(a)gmail.com> >>>>>> To: <Pharo-project(a)lists.gforge.inria.fr> >>>>>> Sent: Wednesday, January 20, 2010 4:16 PM >>>>>> Subject: Re: [Pharo-project] A dog-slow browser >>>>>> >>>>>> >>>>>>> 2010/1/20 Gary Chambers <gazzaguru2(a)btinternet.com>: >>>>>>>> Super quick here... (1.1 latest updates, admittedly a quad-core, only >>>>> one >>>>>>>> used though...) >>>>>>> >>>>>>> I have to take my words back. >>>>>>> Strange, very strange.. its now magically started working quite fast.. >>>>>>> As i said, first time i run it, it was flickering the hourglass mouse >>>>>>> cursor each time i switching between methods in browser. >>>>>>> What was it? And why it disappears? Any suggestions? >>>>>>> >>>>>>>> >>>>>>>> Regards, Gary >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>> From: "Marcus Denker" <marcus.denker(a)inria.fr> >>>>>>>> To: <Pharo-project(a)lists.gforge.inria.fr> >>>>>>>> Sent: Wednesday, January 20, 2010 3:47 PM >>>>>>>> Subject: Re: [Pharo-project] A dog-slow browser >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> On Jan 20, 2010, at 4:35 PM, Igor Stasenko wrote: >>>>>>>>> >>>>>>>>>> 2010/1/20 Marcus Denker <marcus.denker(a)inria.fr>: >>>>>>>>>>> >>>>>>>>>>> On Jan 20, 2010, at 4:28 PM, Igor Stasenko wrote: >>>>>>>>>>> >>>>>>>>>>>> Please, don't take it as a offense, but as a constructive critics >>>>> :) >>>>>>>>>>>> >>>>>>>>>>>> Pharo-core browser is awfully slooow! >>>>>>>>>>>> >>>>>>>>>>> Pharo core? Or Pharo dev? >>>>>>>>>>> >>>>>>>>>> core >>>>>>>>> >>>>>>>>> It should not... it uses the fast fonts, no syntax highligting... >>>>>>>>> In essense, it should be the same performance than Squeak 3.9. >>>>>>>>> >>>>>>>>> Is it slower than that? I can not see any problem (the curse of a >>> fast >>>>>>>>> machine?) >>>>>>>>> >>>>>>>>> Marcus >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Marcus Denker -- http://www.marcusdenker.de >>>>>>>>> INRIA Lille -- Nord Europe. Team RMoD. >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Best regards, >>>>>>> Igor Stasenko AKA sig. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>> >>> >>> _______________________________________________ >>> 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. 20, 2010

Re: [Pharo-project] What we should do with the Dev image? Re: question about O2 vs OB

by Schwab,Wilhelm K

I am very much in favor or providing ready choice in the browsers and tools. It would also help to have the browswers somehow brand themselves. Conversation here centers on things like O2 vs. OB, but there are at least two O2 browswers (package and system). I am probably most concerned about keeping the standard tool set which does away with the new inspector and might have other favorable side effects. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Miguel Enrique CobÃ¡ Martinez Sent: Wednesday, January 20, 2010 12:20 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] What we should do with the Dev image? Re: question about O2 vs OB El miÃ©, 20-01-2010 a las 17:44 +0100, Mariano Martinez Peck escribiÃ³: > > That's the reason of having OB and O2. While both now work > together in the same image > without inferring each other, this indeed increases the number > of classes in the image > quite a lot as they duplicate a whole bunch of code. So I > strongly suggest to either use > OB or O2, even though you can have both. But I do not see a > reason why people want to > switch between the two dynamically in the same image. > > > > We have two things to choose: which browser is default and which ones > are installed. Both ? only one ? The solution I like most, is in > these options: > > 1) Install both: OB and O2. Let OB as default. > > 2) Install only OB, of course, as default, and those who wants can > install O2 in that dev image. They way to install O2 now is very easy. > > 3) Install only OB, of course, as default, but create a group in > ConfigurationOfPharo like "StandardDevImageWithO2" so that those > people who want a dev image with O2 can just evaluate that in a core > image and wala! > > With 1 the image will be smaller but won't have O2 preinstalled. With > 2) and 3) you will have also O2 but bigger image. > > I think I will coose 2) AND 3). Those who want to install O2 directly > in a dev image, use the ConfigurationOfO2 and those who wants to > create a dev image over the core, they use ConfigurationOfPharo with > the new group I can create. I think that group are the way to go. A group for pharo dev with OB (and only OB) a group with O2 (and only O2) a group with both (and this could be the default because most new users won't have a preference). Also, this avoid give any package preference over the other. Of course, the documentation for creating a dev image, should state clearly the three options to build an image. my 2 cents > > What do you think ? > > Mariano > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel CobÃ¡ http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 20, 2010

Re: [Pharo-project] What we should do with the Dev image? Re: question about O2 vs OB

by Miguel Enrique CobÃ¡ Martinez

El miÃ©, 20-01-2010 a las 17:44 +0100, Mariano Martinez Peck escribiÃ³: > > That's the reason of having OB and O2. While both now work > together in the same image > without inferring each other, this indeed increases the number > of classes in the image > quite a lot as they duplicate a whole bunch of code. So I > strongly suggest to either use > OB or O2, even though you can have both. But I do not see a > reason why people want to > switch between the two dynamically in the same image. > > > > We have two things to choose: which browser is default and which ones > are installed. Both ? only one ? The solution I like most, is in > these options: > > 1) Install both: OB and O2. Let OB as default. > > 2) Install only OB, of course, as default, and those who wants can > install O2 in that dev image. They way to install O2 now is very > easy. > > 3) Install only OB, of course, as default, but create a group in > ConfigurationOfPharo like "StandardDevImageWithO2" so that those > people who want a dev image with O2 can just evaluate that in a core > image and wala! > > With 1 the image will be smaller but won't have O2 preinstalled. With > 2) and 3) you will have also O2 but bigger image. > > I think I will coose 2) AND 3). Those who want to install O2 directly > in a dev image, use the ConfigurationOfO2 and those who wants to > create a dev image over the core, they use ConfigurationOfPharo with > the new group I can create. I think that group are the way to go. A group for pharo dev with OB (and only OB) a group with O2 (and only O2) a group with both (and this could be the default because most new users won't have a preference). Also, this avoid give any package preference over the other. Of course, the documentation for creating a dev image, should state clearly the three options to build an image. my 2 cents > > What do you think ? > > Mariano > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Jan. 20, 2010

Re: [Pharo-project] Parrot VM

by Miguel Enrique CobÃ¡ Martinez

El miÃ©, 20-01-2010 a las 09:20 +0100, Stefan Marr escribiÃ³: > You mean how their approaches compare? (I would guess, there is no direct involvement of people in both projects.) > > PyPy is a generator approach, your language specification i.e. the interpreter is used > to generate a VM. > You use a high-level language i.e. RPython to implement a classic interpreter, which is then transformed by a powerful tool-chain to your C implementation (and a JIT). Stuff like GC is just generated for you. > The result is one specific VM, which is generated for your language. > > > With Parrot it is much like with a classic VM like JVM or CLR/.NET. > You are using one existing VM. > Language developers use the Parrot Assembly language (PASM) or the Parrot > Intermediate Representation (PIR) which can then be compiled to the bytecode set. > Furthermore, they can extend the bytecode set with their own instructions (primitives). > So, you are basically compiling your target language while using all the runtime features of the Parrot VM. So, here the 'power' is in the VM, not in a transformation tool chain. > > Best > Stefan > Very interesting, thanks for the info. > > > On 20 Jan 2010, at 09:02, StÃ©phane Ducasse wrote: > > > stefan > > > > do you know how this is linked with pypy? > > > > Stef > > > > On Jan 20, 2010, at 8:50 AM, Stefan Marr wrote: > > > >> > >> On 20 Jan 2010, at 06:12, Miguel Enrique CobÃ¡ Martinez wrote: > >> > >>> Parrot has just been released: > >>> http://www.parrot.org/news/2010/Parrot-2.0.0 > >>> > >>> I would like to know, from the VM experts from the community, if this VM > >>> can be used to run Smalltalk. > >> Well, as someone mentioned, there seems to be Smalltalk implementation... > >> > >> But, probably it is hard to get it fast. > >> Parrot uses a very unique approach. > >> Actually, they try to provide a language runtime for all kinds of languages, and the right tools to build them: http://www.linux-mag.com/cache/7373/1.html > >> > >> Eliot mentioned primitives, well, there is no concept of a primitive in Parrot. > >> Instead, they have a unification of bytecodes and primitives. The idea is, to give you the tools to develop the bytecode you need for your language, which can be loaded dynamically during execution. > >> It will be interesting to see, how they can get their JIT fast with this strategy. > >> > >> Best > >> Stefan > >> > >> > >>> The site says that > >>> > >>> "Parrot is a virtual machine aimed at running all dynamic languages.". > >>> > >>> but I don't know anything about VM so this sounds to me a bit like black > >>> magic. > >>> > >>> Is there something in the squeak vm that is specific to the way > >>> smalltalk works or a generic virtual machine (maybe with a upper layer > >>> understanding Smalltalk specifics) can be used. > >>> > >>> Thanks for the answers > >>> > >>> -- > >>> Miguel CobÃ¡ > >>> http://miguel.leugim.com.mx > >>> > >>> > >>> _______________________________________________ > >>> Pharo-project mailing list > >>> Pharo-project(a)lists.gforge.inria.fr > >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> -- > >> Stefan Marr > >> Software Languages Lab > >> Vrije Universiteit Brussel > >> Pleinlaan 2 / B-1050 Brussels / Belgium > >> http://soft.vub.ac.be/~smarr > >> Phone: +32 2 629 3956 > >> Fax: +32 2 629 3525 > >> > >> > >> _______________________________________________ > >> 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 > -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Jan. 20, 2010

Re: [Pharo-project] FileStream speed up

by Levente Uzonyi

On Wed, 20 Jan 2010, StÃ©phane Ducasse wrote: > Hi levente > > can you have a look at the attached cs? > I had a quick look and found that the changes for MultiByteFileStream are still missing. Those are the first that you should apply. Why? Because some methods (#upToEnd IIRC) use the collection instance variable for no reason. If you keep that method and apply the changes to StandardFileStream, (as I pointed out earlier) the system may break. Also the fix from Files-ul.67 is missing (StandardFileStream >> #upTo:). I suggest you to make 3 steps to integrate the changes: 1. Integrate the changes to MultiByteFileStream 2. Integrate the changes to StandardFileStream 3. Evaluate: StandardFileStream allSubInstancesDo: [ :each | each closed ifFalse: [ each enableReadBuffering ] ] Then save the image, run tests, reopen the image, run tests. Every test should pass which passed before. Levente

Jan. 20, 2010