December 2014 - Pharo-users

Re: [Pharo-users] PetitParser and PPBrowser in Pharo 3.0

by Stephan Eggermont

Jan Kurs wrote: >Anyone experience with Athens can help with the first issue? TRLabelShape>>drawOn: seem to be somehow responsible, but I don't see into this :( Sure. The default fonts you ar easing are bitmap fonts. Roassal2 only works with FreeType fonts. If you open the settings, select appearance and open standard fonts, you'll probably see Bitmap DejaVu Sans. If you select one of the Source Code Fonts Predefined styles you might have better results. (Standard fonts are not updated correctly, you might have to close/open the Standard Font tree element for it to refresh). Stephan

Dec. 16, 2014

Re: [Pharo-users] New Pharo Collections

by dboeren

Sounds like a great idea for a project. Off the top of my head, I would be interested in support for "slices" meaning taking being able to treat a subset of a larger OrderedCollection as its own OrderedCollection rather than using copyFrom:to: to create a duplicate object to work with. It seems to me that this would be a more efficient method and should not be difficult to implement I think. -- View this message in context: http://forum.world.st/New-Pharo-Collections-tp4796132p4796156.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Dec. 16, 2014

Re: [Pharo-users] [ANN] RProjectConnector V1.0

by HernÃ¡n Morales Durand

Vincent, First of all, thank you for publishing such useful package. This is a very valuable contribution and I would be glad to contribute to the RProjectConnector project. There is one thing which bothers me: Having to manually copy the R library files (.dll or .so) is time-consuming and prevents unattended installation. In BioSmalltalk I am currently downloading library files supporting several URI locations by using Metacello. This is just adding a line in the #baseline: method spec preLoadDoIt: #preLoad. The problem could be incompatibility of versions between the R installed in the user's machine and the .dll/.so versions provided by the RProjectConnector. A better option is to detect the R installation path and copying the libraries to the pharo-vm/ directory. What do you think? Cheers, HernÃ¡n 2014-12-08 11:10 GMT-03:00 Blondeau Vincent <vincent.blondeau(a)worldline.com> : > > Hello everyone, > > > > I am glad to announce the first version of the RProjectConnector, a > binding between Pharo and R using NativeBoost. > > > > You can now call directly your R methods from Pharo: > > data := (1 to: 1000) collect: #yourself. > > res := (#acf asRFunctionWith: {data}) eval > > > > To use it, you should copy the R libraries near the Pharo VM (see the > documentation on SmalltalkHub to see how to proceed) and > > Gofer it > > smalltalkhubUser: 'VincentBlondeau' project: 'RProjectConnector'; > > configuration; > > loadStable > > Donât forget to relaunch Pharo after the installation to be able to use > the connector. > > > > The sources are available on Smalltalkhub: > > http://smalltalkhub.com/#!/~VincentBlondeau/RProjectConnector > > > > if you want to participate, just ask me! > > > > Cheers, > > > > Vincent BLONDEAU > > ------------------------------ > > Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage > exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret > professionnel. Si vous recevez ce message par erreur, merci d'en avertir > immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne > pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra > Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs > efforts soient faits pour maintenir cette transmission exempte de tout > virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa > responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un > virus transmis. > > This e-mail and the documents attached are confidential and intended > solely for the addressee; it may also be privileged. If you receive this > e-mail in error, please notify the sender immediately and destroy it. As > its integrity cannot be secured on the Internet, the Worldline liability > cannot be triggered for the message content. Although the sender endeavours > to maintain a computer virus-free network, the sender does not warrant that > this transmission is virus-free and will not be liable for any damages > resulting from any virus transmitted. >

Dec. 16, 2014

Re: [Pharo-users] PetitParser and PPBrowser in Pharo 3.0

by Jan KurÅ¡

Hi, Anyone experience with Athens can help with the first issue? TRLabelShape>>drawOn: seem to be somehow responsible, but I don't see into this :( Regarding to the second issue, there are some cases, when one really needs a start rule, e.g when computing follow. Yet I updated the code so that it handles missing start rule a bit better. Please, let me know, if you have some other ideas/suggestions/issues. Regards, Jan On 9 December 2014 at 15:17, Hartmut <krasemann(a)acm.org> wrote: > > Hi to all, > > I'm working with PetitParser in a Pharo 3 image. > Until now I had to do without the PPBrowser which I loved in Pharo 2. > > On forum.world.st I now found the hint by Jan Kurs to install all of the > Petit suite: > > > "Configuration should be loaded like this:" > > Gofer new smalltalkhubUser: 'Moose' project: 'PetitParser'; > > configurationOf: #PetitParser; load. > > > > "All the petit parser suite:" > > ConfigurationOfPetitParser loadDevelopment. > > Apart from the fact that this installed a real lot into my image, I notice > the following problems > in PPBrowser: > > 1. The map of none of the 18 parsers included, is displayed (it becomes > red crossed). > However, this was the most useful part of it > > 2. My interrelated parsers consist of a tree of parsers where each leave > has its own start clause. > They define related languages. It makes no sense to add a *start* > clause to the root. > However, without such a meaningless *start* clause, only the *source* > is displayed, > neither *graph, example, first* or *follow* of any clause. > (this can be reproduced when you move PPJsonGrammar>>start to > PPJsonParser) > > I like the style of having a grammar class above a parser (or compiler) > class. > This is as seen in most of the accompanying parsers. > My preferred petit parser style comprises: > a) keeping grammar rules (without ==>) in the upper classes of the > grammar hierarchy tree, > such that we find the complete grammar there (without the *start* > clause). > b) keeping replacement rules (using ==>) as low as possible the grammar > hierarchy tree > c) writing the start clause to the class that is actually called. (this > gives different entries > in a grammar allowing for different languages with grammar subsets) > > Is there an idea to have 1. and/or 2. resolved? > > Hartmut > > -- > Hartmut Krasemann > KÃ¶nigsberger Str. 41 c > â¨D 22869 Schenefeld > Tel. 040.8307097 > Mobil 0171.6451283â¨krasemann(a)acm.org > >

Dec. 16, 2014

Re: [Pharo-users] [Pharo-dev] how do you use scripts?

by Tudor Girba

Hi, On Tue, Dec 16, 2014 at 1:41 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > > 2014-12-16 13:23 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: >> >> Just a clarification: >> Playground is saving after each change, not only after a Go. To some >> extent, it is some sort of duplication with the DoIt actions, but the >> Playground saves the entire code, not just the executed one. >> > > It doesn't make the distinction between a go on a selection or on the full > code? I'd wonder about the correctness of the save, then. > I do not understand what you mean. Playground saves all contents after each edit operation. So, you can open a Playground, type 42, close it without executing anything, and you will have a page with '42' contents. We used to have the saving triggered only on Go, but that was too brittle as sometimes you might close a Playground by mistake before executing anything. Does that make sense now? It saves the contents in a play-cache folder by default, but you can >> configure it to be in a central folder shared by multiple images. >> > > Ok. > > If we have a better log format than the changes, could all this (changes > and those scripts) be unified/integrated? > Indeed, that would be interesting. Cheers, Doru >> The idea is exactly to try to find a mechanism that is transparent and >> let's you play without worrying about save/load. We still have to refine >> the mechanism a bit though. >> >> Please also note that GTSpotter searches through past Playground pages >> which means that discovery is now easier than before. >> > > I expected that feature :) > > Thanks, > > Thierry > > >> >> Cheers, >> Doru >> >> On Tue, Dec 16, 2014 at 1:17 PM, Thierry Goubier < >> thierry.goubier(a)gmail.com> wrote: >>> >>> >>> >>> 2014-12-16 13:00 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >>>> >>>> >>>> > On 16 Dec 2014, at 12:54, Thierry Goubier <thierry.goubier(a)gmail.com> >>>> wrote: >>>> > >>>> > >>>> > >>>> > 2014-12-16 12:44 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >>>> > >>>> > >>>> > === >>>> > >>>> > We need something very low friction, like automatic >>>> saving/remembering. >>>> > >>>> > >>>> > Why not searching among the doit(s) stored in the changes? >>>> > >>>> > Thierry >>>> >>>> Yes, that combined with Workspace's 'Previous contents' and the new >>>> automatic saving of Playground after Go. >>>> >>> >>> Isn't the Playground saving after go a duplication of the Changes >>> recording of the associated doit? >>> >>> >>>> >>>> It just needs to become a really safe and dependable - so that you just >>>> know you can safely close a workspace/playground with an important script >>>> and always can get it back. >>>> >>> >>> I rebuilt my images regularly, so it could be nice to have that linked >>> to a repository. And yes, simple and dependable. Like in: there is no need >>> to explain how it works... Or that the how is obvious. >>> >>> Saving states of the workspaces / playground in a kind of log and doits >>> as actions on those? Visible in searches? Stored in the package cache? >>> Robust to multiple images use on it? >>> >>> Thierry >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > -- www.tudorgirba.com "Every thing has its own flow"

Dec. 16, 2014

Re: [Pharo-users] [Pharo-dev] how do you use scripts?

by Thierry Goubier

2014-12-16 13:23 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > > Just a clarification: > Playground is saving after each change, not only after a Go. To some > extent, it is some sort of duplication with the DoIt actions, but the > Playground saves the entire code, not just the executed one. > It doesn't make the distinction between a go on a selection or on the full code? I'd wonder about the correctness of the save, then. > It saves the contents in a play-cache folder by default, but you can > configure it to be in a central folder shared by multiple images. > Ok. If we have a better log format than the changes, could all this (changes and those scripts) be unified/integrated? > The idea is exactly to try to find a mechanism that is transparent and > let's you play without worrying about save/load. We still have to refine > the mechanism a bit though. > > Please also note that GTSpotter searches through past Playground pages > which means that discovery is now easier than before. > I expected that feature :) Thanks, Thierry > > Cheers, > Doru > > On Tue, Dec 16, 2014 at 1:17 PM, Thierry Goubier < > thierry.goubier(a)gmail.com> wrote: >> >> >> >> 2014-12-16 13:00 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >>> >>> >>> > On 16 Dec 2014, at 12:54, Thierry Goubier <thierry.goubier(a)gmail.com> >>> wrote: >>> > >>> > >>> > >>> > 2014-12-16 12:44 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >>> > >>> > >>> > === >>> > >>> > We need something very low friction, like automatic saving/remembering. >>> > >>> > >>> > Why not searching among the doit(s) stored in the changes? >>> > >>> > Thierry >>> >>> Yes, that combined with Workspace's 'Previous contents' and the new >>> automatic saving of Playground after Go. >>> >> >> Isn't the Playground saving after go a duplication of the Changes >> recording of the associated doit? >> >> >>> >>> It just needs to become a really safe and dependable - so that you just >>> know you can safely close a workspace/playground with an important script >>> and always can get it back. >>> >> >> I rebuilt my images regularly, so it could be nice to have that linked to >> a repository. And yes, simple and dependable. Like in: there is no need to >> explain how it works... Or that the how is obvious. >> >> Saving states of the workspaces / playground in a kind of log and doits >> as actions on those? Visible in searches? Stored in the package cache? >> Robust to multiple images use on it? >> >> Thierry >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Dec. 16, 2014

Re: [Pharo-users] [Pharo-dev] how do you use scripts?

by Tudor Girba

Just a clarification: Playground is saving after each change, not only after a Go. To some extent, it is some sort of duplication with the DoIt actions, but the Playground saves the entire code, not just the executed one. It saves the contents in a play-cache folder by default, but you can configure it to be in a central folder shared by multiple images. The idea is exactly to try to find a mechanism that is transparent and let's you play without worrying about save/load. We still have to refine the mechanism a bit though. Please also note that GTSpotter searches through past Playground pages which means that discovery is now easier than before. Cheers, Doru On Tue, Dec 16, 2014 at 1:17 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > > 2014-12-16 13:00 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >> >> >> > On 16 Dec 2014, at 12:54, Thierry Goubier <thierry.goubier(a)gmail.com> >> wrote: >> > >> > >> > >> > 2014-12-16 12:44 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >> > >> > >> > === >> > >> > We need something very low friction, like automatic saving/remembering. >> > >> > >> > Why not searching among the doit(s) stored in the changes? >> > >> > Thierry >> >> Yes, that combined with Workspace's 'Previous contents' and the new >> automatic saving of Playground after Go. >> > > Isn't the Playground saving after go a duplication of the Changes > recording of the associated doit? > > >> >> It just needs to become a really safe and dependable - so that you just >> know you can safely close a workspace/playground with an important script >> and always can get it back. >> > > I rebuilt my images regularly, so it could be nice to have that linked to > a repository. And yes, simple and dependable. Like in: there is no need to > explain how it works... Or that the how is obvious. > > Saving states of the workspaces / playground in a kind of log and doits as > actions on those? Visible in searches? Stored in the package cache? Robust > to multiple images use on it? > > Thierry > -- www.tudorgirba.com "Every thing has its own flow"

Dec. 16, 2014

Re: [Pharo-users] [Pharo-dev] how do you use scripts?

by Thierry Goubier

2014-12-16 13:00 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > > On 16 Dec 2014, at 12:54, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > > > > > > > 2014-12-16 12:44 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > > > > === > > > > We need something very low friction, like automatic saving/remembering. > > > > > > Why not searching among the doit(s) stored in the changes? > > > > Thierry > > Yes, that combined with Workspace's 'Previous contents' and the new > automatic saving of Playground after Go. > Isn't the Playground saving after go a duplication of the Changes recording of the associated doit? > > It just needs to become a really safe and dependable - so that you just > know you can safely close a workspace/playground with an important script > and always can get it back. > I rebuilt my images regularly, so it could be nice to have that linked to a repository. And yes, simple and dependable. Like in: there is no need to explain how it works... Or that the how is obvious. Saving states of the workspaces / playground in a kind of log and doits as actions on those? Visible in searches? Stored in the package cache? Robust to multiple images use on it? Thierry

Dec. 16, 2014

Re: [Pharo-users] [Pharo-dev] how do you use scripts?

by Sven Van Caekenberghe

> On 16 Dec 2014, at 12:54, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > > 2014-12-16 12:44 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > === > > We need something very low friction, like automatic saving/remembering. > > > Why not searching among the doit(s) stored in the changes? > > Thierry Yes, that combined with Workspace's 'Previous contents' and the new automatic saving of Playground after Go. It just needs to become a really safe and dependable - so that you just know you can safely close a workspace/playground with an important script and always can get it back.

Dec. 16, 2014

Re: [Pharo-users] [Pharo-dev] how do you use scripts?

by Thierry Goubier

2014-12-16 12:44 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > > === > > We need something very low friction, like automatic saving/remembering. > > Why not searching among the doit(s) stored in the changes? Thierry

Dec. 16, 2014