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

[Pharo-project] Show categoy in implementors, senders.. etc

by Mariano Martinez Peck

Hi Ben. I really miss the ability of seing the category in senders/implementors. Lots of time I want to see for example if all implementation or senders are in the correct package or not, etc... So, together with Guille, waiting for the train, we hacked: FlatMessageListBrowser >> createColumnsFor: anItem ^ bindings at: anItem ifAbsentPut: [ {anItem realClass name. anItem selector asString, ' (' ,anItem category asString, ')'} ] Not sure if that's the place, but it would be nice to have :) Thanks -- Mariano http://marianopeck.wordpress.com

April 20, 2012

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

by Camillo Bruni

On 2012-04-20, at 17:45, Mariano Martinez Peck wrote: > > > 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? ok let's clean them a bit :P, I overdid it a bit and accidentally broke some stuff :P > > 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] 1.4, seaside, comet, how to get it working

by Igor Stasenko

On 20 April 2012 16:04, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > > On 20 Apr 2012, at 15:29, Igor Stasenko wrote: > >> On 20 April 2012 13:46, Sven Van Caekenberghe <sven(a)beta9.be> wrote: >>> JB, >>> >>> On 19 Apr 2012, at 19:19, jb wrote: >>> >>>> i just downloaded 1.4, installed seaside using the Â configuration browser and everything went great. >>>> >>>> i added a Zinc server adapator in the Seaside control panel and its all working fine. >>>> >>>> but then i went to set up the comet/streaming server and im kind of stumped. Â there is only one kind of Zinc server adapter and when i try to use it for the comet examples they all complain about needing a server that supports streaming. >>>> >>>> what do i need to do to get a streaming server for the comet applications? >>>> >>>> thanks in advance! >>>> >>>> jb >>> >>> As author of Zinc I would like to help you, but I don't know what functionality is expected from a server that 'supports streaming'. If you or someone else could refer me to code and/or documentation that describes what should be there, maybe I can try to help you. >>> >> >> If you remember we discussed that before. Mainly it Â is about getting >> a stream for contents from HTTP response. >> i.e. something like: >> >> 'http://x.y.z' asUrl getContents >> where you get all contents at once, versus >> >> 'http://x.y.z' asUrl getContentStream >> where you get only a stream and can read incrementally from it. > > I don't really remember ;-) > > But I think I more or less begin to understand: some Seaside (client) code wants to access the underlying socket stream to the client ? For reading and/or for writing ? Inside or outside an existing request/response ? Inside or outside the dynamic context of the request handling ? > > In any case, this seems dangerous. > > Can I read something about the intended use of this somewhere ? Example usage code ? > Yes, you can look at my hacky implementation of SCouchDB, where i partially implemented the HTTP protocol and use streams for content. See http://www.squeaksource.com/SCouchDB there i use a stream to directly parse the input without waiting all data to arrive. This is also useful for up/downloading huge files, where content size can easily surpass the amount of RAM available. >>> Sven >>> >>> >>> -- >>> Sven Van Caekenberghe >>> http://stfx.eu >>> Smalltalk is the Red Pill >>> >>> >>> >>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- Best regards, Igor Stasenko.

April 20, 2012

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

by Schwab,Wilhelm K

Sig, I wonder whether that should be on by default. I have had some real frustrations with FFI of late, and something like this might have avoided the problem. Unless it is easily discoverable, off is almost the same as non-existent. Any rumblings on Spock? It would be nice to have even a facade that unifies the FFI/NB/Alien on all platforms. It would indelicate to mention that this was supposed to happen in January<g>. I never really expected to see it that soon, given the problems I had going from 1.1.1 to 1.3 with FFI, and my rotating errors with Alien callbacks. I changed a bunch of FFI calls (in ways that I genuinely think should not have been necessary) and retreated to C functions for GSL callbacks. The latter is frustrating, BAD for my eventually being able to release a GSL binding (make that REALLY BAD), but not all bad because C++ is a better formula translator that Smalltalk, and the number crunching runs at native speeds. I think these things *can* work - they just don't at present, and the FFI/NB/Alien split makes it hard to know what to try. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Igor Stasenko [siguctua(a)gmail.com] Sent: Friday, April 20, 2012 10:46 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [NativeBoost] Generic failure errors when using nil for void* and char* arguments 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

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