- Pharo-dev - lists.pharo.org

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

[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