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

[Pharo-project] Athens/Cairo and Nautilus MNU: ClassTrait>>correspondingForTest

by Alexis Parseghian

After loading Athens from Metacello configuration, and following Igor's advice as to where to fix the library path in TCairoLibrary class. - Downloading a new official 1.4 image - Loading ConfigurationOfAthens from squeaksource, version 1.0 - viewing TCairoLibrary with the basic browser => ok on both instance and class side - load Nautilus from MetacelloConfigurationBrowser ("Load configuration and stable version) - viewing TCairoLibrary with Nautilus, instance side OK, class side raises this MNU - viewing TEasilyThemed (for instance) with Nautilus, works on both sides.

April 20, 2012

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

by Sven Van Caekenberghe

On 20 Apr 2012, at 17:37, Mariano Martinez Peck wrote: > And the Pharo team does not rest even on Friday having released Pharo 1.4 yesterday!!! > Excellent :) I hope there was at least a little celebration ?

April 20, 2012

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

by Igor Stasenko

oh, and as meta-comment, i should add a more comprehensible error message, like 'FFI Callout failed, when trying to coerce arguments' or something like that, instead of 'Generic failure' which is just a sign that primitive failed and no call were performed. But right now, just keep that in mind: every time you got a generic error in FFI callout, first thing you should look at is what are you passing as arguments, and what is C function expects. -- Best regards, Igor Stasenko.

April 20, 2012

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

by Pavel Krivanek

Please do not forget to change version in ScriptLoader class >> #initialize. -- Pavel On Fri, Apr 20, 2012 at 5:27 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > 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] [Pharo-users] Final 1.4 images...

by Mariano Martinez Peck

On Fri, Apr 20, 2012 at 12:03 PM, Bernat Romagosa < tibabenfortlapalanca(a)gmail.com> wrote: > One more thing, how does one rename a method? Was this option removed from > the browser? > > The problem is that the image you are using comes by default with a limited system browser. It does not know anything about refactorings. To have a really development image, install Nautilus on it. Imagine you are using like the previous PharoCore + code completion + shout > > 2012/4/20 Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> > >> Congratulations, Pharo 1.4 looks really neat and so far very usable! >> >> Just one thing, what happened to the format shortcut (control+r)? I use >> it all the time, like three times per method I write... is it possible to >> get it back? :) >> >> Cheers, >> >> Bernat. >> >> >> 2012/4/19 Marcus Denker <marcus.denker(a)inria.fr> >> >>> We added more infos in the worspace: >>> >>> https://gforge.inria.fr/frs/download.php/30620/Pharo-1.4-14438.zip >>> >>> https://gforge.inria.fr/frs/download.php/30621/Pharo-1.4-14438-OneClick.zip >>> >>> >>> On Apr 18, 2012, at 2:39 PM, Marcus Denker wrote: >>> >>> > Hi, >>> > >>> > final images: >>> > >>> > One-Click: >>> > >>> > >>> https://gforge.inria.fr/frs/download.php/30615/Pharo-1.4-14437-OneClick.zip >>> > >>> > Just image: >>> > >>> https://gforge.inria.fr/frs/download.php/30613/Pharo-1.4-14437.zip >>> > >>> > already linked on >>> > >>> > http://www.pharo-project.org/pharo-download/release-1-4 >>> > >>> > >>> > -- >>> > Marcus Denker -- http://marcusdenker.de >>> > >>> >>> -- >>> Marcus Denker -- http://marcusdenker.de >>> >>> >>> >> >> >> -- >> Bernat Romagosa. >> > > > > -- > Bernat Romagosa. > -- Mariano http://marianopeck.wordpress.com

April 20, 2012

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

by Igor Stasenko

On 20 April 2012 17:45, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > 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. > Well, it depends on POV. For the strictness of usage, i thought it is better to pass explicitly (NBExternalAddress value: 0) than nil, so that your code passing correct value types to function(s). Automatic coercion and weak typing is something which i hate in C, and try to avoid (smalltalk is strong typed language) i.e. unsigned long a = 10000000; char x = a; producing only a compiler warning. and if you put: char x = (char) a; you can suppress it. But this is like placing a time bomb into your code, which you never know when it will explode. Weak typing is common source of many errors and bugs which is hard to find. This is one of the reasons, why i don't want nil to be a valid argument for functions expecting pointer(s) by default. Because while some library functions say that NULL is valid argument, on opposite side, there another functions which expecting a valid pointer value, and if you pass nil (as a result of not fully initialized object), you will crash the application. > 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>. Yes, i am lazy guy, who cannot do much. Sorry :) The plans are still there: add callbacks support, add threading, unify Alien and NB. >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. > i want that everything start working too.. so i can move on oh higher levels, since NativeBoost is infrastructural kind of project. > Bill -- Best regards, Igor Stasenko.

April 20, 2012

Re: [Pharo-project] 1.4, seaside, comet, how to get it working

by Lukas Renggli

> 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 ? For writing only, see WAListenerAdaptor in Seaside-Adaptors-Comanche. WAListenerAdaptor is a custom server implementation that uses Kom for some utility functions. It enables Seaside to directly write to the Socket and to keep the response open as longs as Seaside needs (to stream contents). Lukas -- Lukas Renggli www.lukas-renggli.ch

April 20, 2012

Re: [Pharo-project] The video about Athens

by Alexis Parseghian

On Fri, Apr 20, 2012 at 2:54 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > i uploaded the new version of Athens-Cairo, which takes the 'default' path > depending on platform it running, also fixed it, so you don't have to > change multiple places. > also , updated config version 1.0 to load this package. Retried in a fresh image and refetch of the new config and I can confirm the proper lib path (assuming 32-bits arch). Still doesn't work here but that's related to the 32-bit/64-bit mix ; not worth wasting time on at this point. I'll retest in a pure 32-bit environment but considering your last post I don't expect any surprise there. Somewhat related, trying to view TCairoLibrary class with Nautilus, I get a MNU which I'll detail in a separate post. Thanks for your time and efforts :)

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:47 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > > 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 > > please :) I have a 5gb shared package-cache and Monticello gets unusable :( > > > > 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 > > > > > -- Mariano http://marianopeck.wordpress.com

April 20, 2012

Re: [Pharo-project] Monticello enhancement - Repository browser <changes from last version>

by Ben Coman

Damien Cassou wrote: > On Fri, Apr 20, 2012 at 3:26 PM, Ben Coman <btc(a)openinworld.com> wrote: > >> This is an idea for an enhancement to the Monticello Repository browser that >> at least myself and perhaps others would find useful - or maybe this is >> already exists and I just don't know about it. >> > > 1- Select the version you want to study > 2- Press the 'History' button > 3- Select the version you want to compare to (the second in the list > in your scenario) > 4- Right click and select 'View changes' > > Is it what you want? > > That is exactly what I was looking for. Thanks for the tip Damien. Except CASE 2 below seems very slow... CASE 1 In Repository browser... 1. With package version "88" selected (and download finsihed) 2. Selected package version "87" (which downloaded in about 5 seconds) 3. Selected package "88" and clicked <History> In History... 4. Selected package "87" and menu item View Changes -> "88" --> Changes are displayed immediately Quit image with saving and cleared package-cache. CASE 2 In Repository browser... 1. With package version "88" selected (and download finsihed) 2. Clicked <History> In History... 3. Selected package "87" and menu item View Changes -> "88" --> Takes 30 seconds for changed to be displayed. From an outside point of view, I would this to take only the same 5 seconds as STEP 2 CASE 1. Perhaps it is just doing more than I expect but thought this was worth mentioning for experts to judge. cheers, Ben

April 20, 2012