December 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [RFC] Zinc-Resources

by Igor Stasenko

On 7 December 2012 20:47, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > This is request for comment on an idea, as suggested by Pavel because he needs it for his kernel building/packaging work, but also in line with several existing issues related to URL, URI and mime types. > > The idea would be to create a new package called 'Zinc-Resources' or maybe 'Zinc-Resource-Description' to contain just ZnUrl and ZnMimeType (and their supporting clases if any). The packaging requirement would be that the new package can only depend on core Smalltalk and not on any IO related packages such as File, Network or HTTP (Zn). Afterwards, File, Network or HTTP (Zn) could then add extensions, like #retrieveContents. > > After the separation I would like to extend ZnUrl to at least support file URIs (file://) since these are very useful. I am not sure that extending ZnUrl to be more general and to satisfy all users will be easy, I fear some conflicting goals, but we'll see. > > The end goal is of course to replace the old classes and simply Pharo. > > Any comments ? > No comments. Do it. :) yeah. we could have a simple registry for schema handlers and for mime handlers.. so, other packages can add own handlers to either of them. as result, no tight coupling. > Sven > > PS: Of course, there would be a unit tests package as well. Actually, any changes should be test driven. > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > -- Best regards, Igor Stasenko.

Dec. 7, 2012

Re: [Pharo-project] [RFC] Zinc-Resources

by StÃ©phane Ducasse

On Dec 7, 2012, at 8:47 PM, Sven Van Caekenberghe wrote: > Hi, > > This is request for comment on an idea, as suggested by Pavel because he needs it for his kernel building/packaging work, but also in line with several existing issues related to URL, URI and mime types. > > The idea would be to create a new package called 'Zinc-Resources' or maybe 'Zinc-Resource-Description' to contain just ZnUrl and ZnMimeType (and their supporting clases if any). The packaging requirement would be that the new package can only depend on core Smalltalk and not on any IO related packages such as File, Network or HTTP (Zn). Afterwards, File, Network or HTTP (Zn) could then add extensions, like #retrieveContents. > > After the separation I would like to extend ZnUrl to at least support file URIs (file://) since these are very useful. I am not sure that extending ZnUrl to be more general and to satisfy all users will be easy, I fear some conflicting goals, but we'll see. I would really like to have one good URL/URI class and I like the idea proposed by pavel/you! > > The end goal is of course to replace the old classes and simply Pharo. > > Any comments ? > > Sven > > PS: Of course, there would be a unit tests package as well. Actually, any changes should be test driven. > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > > >

Dec. 7, 2012

Re: [Pharo-project] Progress Update

by StÃ©phane Ducasse

On Dec 7, 2012, at 7:17 PM, Camillo Bruni wrote: > > On 2012-12-06, at 18:14, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> Camillo I do not know. >> Now I will have a look at your change because I was also fixing a bit the progressBar class. Removing some useless methods >> and I grouped all the job class under >> kernel-job >> and progressbar under >> morphic progress bar because I was fed up to see them in process and system support mixed with other. > > ok, that looks fine :) separate packages should clarifiy things a bit :) I could not separate the packages because we found a bug in rpackage integration. > Maybe I have time to look into it, today. Otherwise I won't touch the computer for 7 days :P and enjoy the georgious argentinian country side! > >>> > there should be no more min-max, hence no more 0 divide possible. > But yeah, I got a bit lost in fixing the UI part ;) so I still have to > do the proper transformations on the rest of the image. I see what you mean because there are plenty of places where it is based on size. I will try to integrate my changes with progressBar (I try to fix the size problem but it often depends on the users). Stef

Dec. 7, 2012

[Pharo-project] [RFC] Zinc-Resources

by Sven Van Caekenberghe

Hi, This is request for comment on an idea, as suggested by Pavel because he needs it for his kernel building/packaging work, but also in line with several existing issues related to URL, URI and mime types. The idea would be to create a new package called 'Zinc-Resources' or maybe 'Zinc-Resource-Description' to contain just ZnUrl and ZnMimeType (and their supporting clases if any). The packaging requirement would be that the new package can only depend on core Smalltalk and not on any IO related packages such as File, Network or HTTP (Zn). Afterwards, File, Network or HTTP (Zn) could then add extensions, like #retrieveContents. After the separation I would like to extend ZnUrl to at least support file URIs (file://) since these are very useful. I am not sure that extending ZnUrl to be more general and to satisfy all users will be easy, I fear some conflicting goals, but we'll see. The end goal is of course to replace the old classes and simply Pharo. Any comments ? Sven PS: Of course, there would be a unit tests package as well. Actually, any changes should be test driven. -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Dec. 7, 2012

Re: [Pharo-project] Progress Update

by Camillo Bruni

On 2012-12-06, at 18:14, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Camillo I do not know. > Now I will have a look at your change because I was also fixing a bit the progressBar class. Removing some useless methods > and I grouped all the job class under > kernel-job > and progressbar under > morphic progress bar because I was fed up to see them in process and system support mixed with other. ok, that looks fine :) separate packages should clarifiy things a bit :) Maybe I have time to look into it, today. Otherwise I won't touch the computer for 7 days :P and enjoy the georgious argentinian country side! >> I promised to fix my partial refactoring for the ProgressBar. >> Finally this evening I hacked on the whole progress mess :), now I am almost done with one little bug left.\\ > > Cool you are addicted! > >> - the progress bar is always responsive >> - all processes showing a progress with priority <60 can be interrupted >> - refreshes periodically 16 times per second >> - only forces a manual refresh when blocking the UI >> - no more out of bounds progress bars >> - no more ugly display buffer pattern when resizing the screen during a running progress >> >> this is a massive improvement for me :) For instance now you can simply interrupt the test runner >> with a click on the progress bar. > > Did you check that it works with 1 to: 1 because in the past I got a zeroDivide there should be no more min-max, hence no more 0 divide possible. But yeah, I got a bit lost in fixing the UI part ;) so I still have to do the proper transformations on the rest of the image.

Dec. 7, 2012

Re: [Pharo-project] [NativeBoost] New kid on the block: NBExternalTypeArray + future plans

by StÃ©phane Ducasse

> less complaining and more fixes :) ;)

Dec. 7, 2012

Re: [Pharo-project] [NativeBoost] New kid on the block: NBExternalTypeArray + future plans

by Esteban Lorenzano

less complaining and more fixes :) On Dec 7, 2012, at 4:57 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 7 December 2012 16:12, Igor Stasenko <siguctua(a)gmail.com> wrote: >> ok, i changed class name >> NBExternalTypeArray => NBExternalArray >> >> (config updated) >> > > not so fast.. > due to some bug in class rename refactoring, the class lost all its methods.. > so i had to put these methods back. > > and then people laughing why i don't use refactoring tools? > exactly because of that: every time i trying to rely on it, it results > in lost code & time to restore things back. > > .. uploaded new version of config with fixed package. > > -- > Best regards, > Igor Stasenko. >

Dec. 7, 2012

Re: [Pharo-project] [NativeBoost] New kid on the block: NBExternalTypeArray + future plans

by Igor Stasenko

On 7 December 2012 16:12, Igor Stasenko <siguctua(a)gmail.com> wrote: > ok, i changed class name > NBExternalTypeArray => NBExternalArray > > (config updated) > not so fast.. due to some bug in class rename refactoring, the class lost all its methods.. so i had to put these methods back. and then people laughing why i don't use refactoring tools? exactly because of that: every time i trying to rely on it, it results in lost code & time to restore things back. .. uploaded new version of config with fixed package. -- Best regards, Igor Stasenko.

Dec. 7, 2012

Re: [Pharo-project] [update 2.0] #20432

by Igor Stasenko

On 7 December 2012 13:35, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Dec 7, 2012, at 1:28 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > >> >> 20432 >> ----- >> >> Issue 7103: Job should use normalize progress [0.0 - 1.0] PART 1 >> http://code.google.com/p/pharo/issues/detail?id=7103 >> Diff information: >> http://ss3.gemstone.com/ss/Pharo20/Polymorph-Widgets-StephaneDucasse.742.di… >> http://ss3.gemstone.com/ss/Pharo20/Morphic-StephaneDucasse.1300.diff >> http://ss3.gemstone.com/ss/Pharo20/KernelTests-StephaneDucasse.458.diff >> http://ss3.gemstone.com/ss/Pharo20/Kernel-StephaneDucasse.1265.diff >> http://ss3.gemstone.com/ss/Pharo20/Deprecated20-StephaneDucasse.27.diff >> >> >> I will raise a debugger at the end. Just close it :). > > How do we do that on the build server? since it is headless, there should be no problems of changing the code of progress bar -- Best regards, Igor Stasenko.

Dec. 7, 2012

Re: [Pharo-project] [update 2.0] #20432

by StÃ©phane Ducasse

>> >> 20432 >> ----- >> >> Issue 7103: Job should use normalize progress [0.0 - 1.0] PART 1 >> http://code.google.com/p/pharo/issues/detail?id=7103 >> Diff information: >> http://ss3.gemstone.com/ss/Pharo20/Polymorph-Widgets-StephaneDucasse.742.di… >> http://ss3.gemstone.com/ss/Pharo20/Morphic-StephaneDucasse.1300.diff >> http://ss3.gemstone.com/ss/Pharo20/KernelTests-StephaneDucasse.458.diff >> http://ss3.gemstone.com/ss/Pharo20/Kernel-StephaneDucasse.1265.diff >> http://ss3.gemstone.com/ss/Pharo20/Deprecated20-StephaneDucasse.27.diff >> >> >> I will raise a debugger at the end. Just close it :). > > How do we do that on the build server? we skip it. Sorry I cannot do magic. Modifying the progress bar when the progress bar is involved. I do not want to spend more time to turn around an infrastructure glitch. Sometimes we should break eggs to do omelet. Stef

Dec. 7, 2012