- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Monticello enhancement - Repository browser - faster loading of comment for review

by Mariano Martinez Peck

On Fri, Apr 20, 2012 at 5:42 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > hi ben... > > what you talk about is almost done: > > - all files are downloaded and put into the local package-cache > > however: > > - MC always queries the server, even if the files exist locally > - MC has to decode the complete version history even if you just want to > see the commit message... > > fixes: > > - I made a local hack to make sure MC always queries the local repo first > - when downloading versions don't re-serialize them again when saving to > the local package-cache > directly write out the loaded bytestream > - Using a shared package-cache avoids downloading multiple times the same > version > - Maybe we should add a separate entry for an mzc which contains an > isolated version info > - Maybe we should just move to git :) (my premature version browses > commits instantaneously) > > With the first two hacks I got nice performance when browsing history / > commit messages. > I need to quite frequently see the commit messages. Are your "hacks" available? should they be integrated? > By having a shared package-cache I could improve the load-time roughly by > a factor 5... > > best > cami > > On 2012-04-20, at 15:46, Ben Coman wrote: > > > This is a second idea for an enhancement to the Monticello Repository > browser that at least myself and perhaps others would find useful. > > > > In the Monticello Repository browser, when a package has many new > versions and I am wanting to review all of the comments for each package > (both for curiosity and also trying to select which I want to load), it is > time consuming to do this, having to wait for the selected version to > download before seeing the comment, then select the next one and wait, then > select the next one and wait, etc... > > > > It would be nice if all comments for the various versions could be > downloaded in one go at the start - for example from a single file. I see > two different ways this might be done. > > 1. Monticello clients downloads such information from the repository, > updates it and then uploads it upon a Save or Copy. > > 2. A smart backend server process culls the information from the > uploaded mcz files to build a single file. > > > > However when I say 'single file', when the incremental comments build to > some maximum size, that incremental file could be archived to a static > version which clients would keep hold of, and roll over to a fresh > 'incremental' file) > > > > I hope that makes sense, > > cheers -ben > > > > btw, I didn't chime in before but congratulations with the 1.4 release. > Its a bigger effort than I realized and I'm impressed. I'm looking for to > using Pharo even more. > > > > > -- Mariano http://marianopeck.wordpress.com

April 20, 2012

Re: [Pharo-project] Monticello enhancement - Repository browser - faster loading of comment for review

by Camillo Bruni

hi ben... what you talk about is almost done: - all files are downloaded and put into the local package-cache however: - MC always queries the server, even if the files exist locally - MC has to decode the complete version history even if you just want to see the commit message... fixes: - I made a local hack to make sure MC always queries the local repo first - when downloading versions don't re-serialize them again when saving to the local package-cache directly write out the loaded bytestream - Using a shared package-cache avoids downloading multiple times the same version - Maybe we should add a separate entry for an mzc which contains an isolated version info - Maybe we should just move to git :) (my premature version browses commits instantaneously) With the first two hacks I got nice performance when browsing history / commit messages. By having a shared package-cache I could improve the load-time roughly by a factor 5... best cami On 2012-04-20, at 15:46, Ben Coman wrote: > This is a second idea for an enhancement to the Monticello Repository browser that at least myself and perhaps others would find useful. > > In the Monticello Repository browser, when a package has many new versions and I am wanting to review all of the comments for each package (both for curiosity and also trying to select which I want to load), it is time consuming to do this, having to wait for the selected version to download before seeing the comment, then select the next one and wait, then select the next one and wait, etc... > > It would be nice if all comments for the various versions could be downloaded in one go at the start - for example from a single file. I see two different ways this might be done. > 1. Monticello clients downloads such information from the repository, updates it and then uploads it upon a Save or Copy. > 2. A smart backend server process culls the information from the uploaded mcz files to build a single file. > > However when I say 'single file', when the incremental comments build to some maximum size, that incremental file could be archived to a static version which clients would keep hold of, and roll over to a fresh 'incremental' file) > > I hope that makes sense, > cheers -ben > > btw, I didn't chime in before but congratulations with the 1.4 release. Its a bigger effort than I realized and I'm impressed. I'm looking for to using Pharo even more. >

April 20, 2012

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

by Mariano Martinez Peck

And the Pharo team does not rest even on Friday having released Pharo 1.4 yesterday!!! Excellent :) On Fri, Apr 20, 2012 at 4:31 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > :D > > Thanks!! > > > On Fri, Apr 20, 2012 at 4:26 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > >> 20006 >> ----- >> >> Issue 5615: clean up #contextForLocalVariables >> http://code.google.com/p/pharo/issues/detail?id=5615 >> >> >> -- >> Marcus Denker -- http://marcusdenker.de >> >> >> > -- Mariano http://marianopeck.wordpress.com

April 20, 2012

[Pharo-project] About the new release process

by Esteban Lorenzano

Hi folks, Now that Pharo 1.4 is out, I want to talk a bit about our new release process. As you know (if you read the Pharo vision document [1]), we are switching our release process into a more predictable one: time based, not feature based. We are adopting an "Ubuntu like" model, with one mayor release per year, and two bug fix releases at month 4 and month 8. So, the next releases will have this numbering: 2.0 big release (we hope to have it in january or february), 2.4 in april and 2.8 in august (all 2013, if Mayans were wrong and we are still alive). During this year we'll also release bugfix versions of Pharo 1.4. Each major version we want to improve the system in a lot of different ways. These are examples of what we want to achieve during 2.0 development: -Improve our release process. This is not just by being more predictable, but also about improving the current process technically. For instance, we are going to switch our release building to metacello configurations, starting with a minimal image. That means: you can take a minimal image and modify a metacello pharoconfig to build the image that you want (on your own responsibility). â We are going to adopt Opal as new compiler (this will allow us to improve a lot in that area, also to fix important bugs now living in the debugger). â Replace old SystemChangeNotification with a new announcement based system. â use Fuel as standard serialization tool (remove SmartRefStream). â remove old File System (use new based on Filesystem). â remove old HTTP (use Zinc instead). â remove old categorizer (Use RPackage instead). â remove old browser (Use nautilus instead). â remove old basic tools (use Spec to replace them). â clean up URL/URI mess (replace with some coherent unique API). In summary, it is: a) replacing old subsystems for something better. b) add new features, which is long-awaited by people. Most of your projects will not notice the changes, but some might do. In that cases, we will not break backward compatibility just because we want, but there are reasons of improvement. Also, we will follow the deprecation policy we have followed so far (whenever is possible). We want to invent the future, one step at a time. Thanks, Esteban [1] http://www.pharo-project.org/download/pictures/be/j32hajf3kjdbsebqo0a9zc5tk…

April 20, 2012

Re: [Pharo-project] How to disable development tools on Pharo 1.4

by Esteban Lorenzano

Hi Noury, I opened the project (I don't know why it was closed)... please upload your changes :) best, Esteban On Apr 20, 2012, at 5:14 PM, Noury Bouraqadi wrote: > Hi, > > I tried it with WorldSwitch-Preferences from SS3. > A minor fix was required to have it run on 1.4 (use rehash instead of rehachWithoutBecome not in the system anymore). > Attached the fixed version since I can't write on the repo. > > I get a "closed" image. I don't know how to test it further. > > Noury > > > > > Afin de contribuer au respect de l'environnement, > > > merci de n'imprimer ce courriel qu'en cas de necessite > > > > > > Please consider the environment before you print > > > > > > <WorldSwitch-Preferences-NouryBouraqadi.2.mcz> > > On 2 fÃ©vr. 2012, at 14:32, Esteban Lorenzano wrote: > >> Hi Noury, >> >> I packaged what I have. And even create a settings configuration for it (under "Deployment" category). >> Notice that is very hacky and ugly and needs a lot (and I mean A LOT) of polish... but is a start :) >> >> see WSSettings class>>#setDeployment: for a start. >> >> <WorldSwitch-Preferences-EstebanLorenzano.2.mcz> >> >> best, >> Esteban >> >> El 02/02/2012, a las 6:40a.m., Noury Bouraqadi escribiÃ³: >> >>> Hi Esteban, >>> >>> On 31 janv. 2012, at 14:23, Esteban Lorenzano wrote: >>> >>>> Hi, >>>> >>>> in fact, what Mariano posted is just a part... disable everything is complicated, because code is everywhere... I'm collection all of this changes in a package, to see in advance if it is possible to abstract that. >>> >>> Thanks Esteban! >>> Do you have a version of this package already? >>> Otherwise, I'll start packaging what Mariano sent. >>> >>> >>>> Ideally, we should have a preference "Disable Development Mode", or something like that to allow desktop developers to easily switch... >>>> >>> Yes. We should have a menu for this. It's part of dev tools. >>> It's a shame that this critical feature isn't available yet. >>> >>> Noury >>> >>>> best, >>>> Esteban >>>> >>>> El 31/01/2012, a las 10:16a.m., Ben Coman escribiÃ³: >>>> >>>>> Noury Bouraqadi wrote: >>>>>> I remember having seen some time in the past a menu that allows to shrink the image and disable the world menu. >>>>>> But, I can't retrieve any thing related. I don't care about the menu per se. I'd be happy with a message to send to some object that does the job. >>>>>> >>>>>> >>>>>> Noury >>>>>> -- >>>>>> http://twitter.com/#!/NouryBouraqadi >>>>>> http://www.kroobe.com/profile/noury >>>>>> >>>>>> >>>>> Squeak 3.9 based, but perhaps something useful... >>>>> "Prepare For Application Deployment" http://squeak.preeminent.org/tut2007/html/205.html >>>>> >>>>> >>>> >>>> >>> >>> Noury >>> -- >>> http://twitter.com/#!/NouryBouraqadi >>> http://www.kroobe.com/profile/noury >>> >>> >>> Afin de contribuer au respect de l'environnement, >>> merci de n'imprimer ce courriel qu'en cas de necessite >>> >>> Please consider the environment before you print >>> >>> >>> >>> >> > > Noury > -- > http://twitter.com/#!/NouryBouraqadi > http://www.kroobe.com/profile/noury >

April 20, 2012

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

by Marcus Denker

On Apr 20, 2012, at 5:24 PM, Bernardo Ezequiel Contreras wrote: > excuse me, where's the build for pharo 2.0? > There is no jenkins yet... we will do that next. (and a Trello, and a page on pharo-project...) The only thin there is for now is a section in https://gforge.inria.fr/frs/?group_id=1299 more soon... -- Marcus Denker -- http://marcusdenker.de

April 20, 2012

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

by Bernardo Ezequiel Contreras

excuse me, where's the build for pharo 2.0? thanks On Fri, Apr 20, 2012 at 12:20 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > 20007 > ----- > > Issue 5610: layout variable on Behavior > http://code.google.com/p/pharo/issues/detail?id=5610 > > PLEASE NOTE: this update adds a fourth iVar in Behavor. > > -> use a old Squeak VM for loading this update > -> the DNU at the end, just force return self. > > ;-) It's called unstable for a reason! > > Camillo and Marcus > > if someone wonders... we want to slowly iterate to reach something like > the stuff > described here: > http://scg.unibe.ch/archive/papers/Verw11bFlexibleObjectLayouts.pdf > > -- > Marcus Denker -- http://marcusdenker.de > > >

April 20, 2012

[Pharo-project] [update 2.0] #20007

by Marcus Denker

20007 ----- Issue 5610: layout variable on Behavior http://code.google.com/p/pharo/issues/detail?id=5610 PLEASE NOTE: this update adds a fourth iVar in Behavor. -> use a old Squeak VM for loading this update -> the DNU at the end, just force return self. ;-) It's called unstable for a reason! Camillo and Marcus if someone wonders... we want to slowly iterate to reach something like the stuff described here: http://scg.unibe.ch/archive/papers/Verw11bFlexibleObjectLayouts.pdf -- Marcus Denker -- http://marcusdenker.de

April 20, 2012

[Pharo-project] How to disable development tools on Pharo 1.4

by Noury Bouraqadi

Hi, I tried it with WorldSwitch-Preferences from SS3. A minor fix was required to have it run on 1.4 (use rehash instead of rehachWithoutBecome not in the system anymore). Attached the fixed version since I can't write on the repo. I get a "closed" image. I don't know how to test it further. Noury Afin de contribuer au respect de l'environnement, merci de n'imprimer ce courriel qu'en cas de necessite Please consider the environment before you print On 2 fÃ©vr. 2012, at 14:32, Esteban Lorenzano wrote: > Hi Noury, > > I packaged what I have. And even create a settings configuration for it (under "Deployment" category). > Notice that is very hacky and ugly and needs a lot (and I mean A LOT) of polish... but is a start :) > > see WSSettings class>>#setDeployment: for a start. > > <WorldSwitch-Preferences-EstebanLorenzano.2.mcz> > > best, > Esteban > > El 02/02/2012, a las 6:40a.m., Noury Bouraqadi escribiÃ³: > >> Hi Esteban, >> >> On 31 janv. 2012, at 14:23, Esteban Lorenzano wrote: >> >>> Hi, >>> >>> in fact, what Mariano posted is just a part... disable everything is complicated, because code is everywhere... I'm collection all of this changes in a package, to see in advance if it is possible to abstract that. >> >> Thanks Esteban! >> Do you have a version of this package already? >> Otherwise, I'll start packaging what Mariano sent. >> >> >>> Ideally, we should have a preference "Disable Development Mode", or something like that to allow desktop developers to easily switch... >>> >> Yes. We should have a menu for this. It's part of dev tools. >> It's a shame that this critical feature isn't available yet. >> >> Noury >> >>> best, >>> Esteban >>> >>> El 31/01/2012, a las 10:16a.m., Ben Coman escribiÃ³: >>> >>>> Noury Bouraqadi wrote: >>>>> I remember having seen some time in the past a menu that allows to shrink the image and disable the world menu. >>>>> But, I can't retrieve any thing related. I don't care about the menu per se. I'd be happy with a message to send to some object that does the job. >>>>> >>>>> >>>>> Noury >>>>> -- >>>>> http://twitter.com/#!/NouryBouraqadi >>>>> http://www.kroobe.com/profile/noury >>>>> >>>>> >>>> Squeak 3.9 based, but perhaps something useful... >>>> "Prepare For Application Deployment" http://squeak.preeminent.org/tut2007/html/205.html >>>> >>>> >>> >>> >> >> Noury >> -- >> http://twitter.com/#!/NouryBouraqadi >> http://www.kroobe.com/profile/noury >> >> >> Afin de contribuer au respect de l'environnement, >> merci de n'imprimer ce courriel qu'en cas de necessite >> >> Please consider the environment before you print >> >> >> >> > Noury -- http://twitter.com/#!/NouryBouraqadi http://www.kroobe.com/profile/noury

April 20, 2012

Re: [Pharo-project] [NativeBoost] Generic failure errors when using nil for void* and char* arguments

by Jan van de Sandt

Yes, now it works! Thanks Igor. On Fri, Apr 20, 2012 at 4:46 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 20 April 2012 15:59, Jan van de Sandt <jvdsandt(a)gmail.com> wrote: > > Hello, > > > > I use NativeBoost to call some icu4c functions. This works fine most of > the > > time. But now I run into the problem that when I pass nil as the argument > > value for one or more void* / char* parameters I get an error. When I > pass a > > value or an empty ByteArray than it works. > > > > According to the icu4c documentation I should be able to pass NULL as an > > argument value. > > > > What am I missing? > > > > For pointers, there is an options in callouts, #optCoerceNilToNull > which should be set, > then you can invoke the call with nil as argument, which will convert > it to C NULL. > > By default this option is OFF, because extra check means extra cycles. > > You can control a callout options by either per function call (see > NBBasicExamples>>readDoubleFrom:) > or for all methods of your class as a whole, like: > > MyClass class>>ffiCalloutOptions > "by default, return all pointers as an instance of external address > " > ^ #( > + optReturnPtrAsExternalAddress > + optCoerceNilToNull "passing nil as pointer, will convert > it to null(0) " > ) > > > Jan. > > > > -- > Best regards, > Igor Stasenko. > >

April 20, 2012