- Pharo-users - lists.pharo.org

Re: [Pharo-users] sharing context/variables between multiple playgrounds

by Tim Mackinnon

I mentioned this a while back 2, less between different playground windows, but more when you drill down on a value in a playground and then want to use a value on the first pane. There was some discussion about this (Denis had some good ideas), and it seemed like a good idea but something to put on the todo list to implement and propose. Tim > On 7 Aug 2017, at 09:16, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > Hi, > > is there a way to share context/variables between multiple playgrounds? > > E.g. in Playground window 1 I declare > > ``` > factor := 70. > ``` > > and in Playground window 2 I do (without declaring `factor`) > > ``` > 5 * factor. "-> 350" > ``` > > > Thanks, > Peter >

Aug. 7, 2017

Re: [Pharo-users] Lazy-initialization patterns

by Henrik Sperre Johansen

Esteban A. Maringolo wrote > 2017-08-05 19:21 GMT-03:00 Peter Uhnak < > i.uhnak@ > >: > >> If I want to initialize the value in a separate method (typically for >> testing or reuse), then I prefer to avoid state mutation there and >> instead I return the result. >> >> MyClass>>#property >> ^ property ifNil: [ property := self createNewProperty ] >> >> MyClass>>createNewProperty >> "I won't touch property instance variable here, just create a new >> value and return it" >> ^ self bar collect: [ :e | e drink ] >> >> >> > an initializationMethod returning the value instead of the receiver is >> a code smell to me. >> >> For this reason I tend to name such methods createNewX, initializeX says >> to me "only mutate state and return self" > > I like this approach very much, it makes the accessor code concise and > separates the implementation of the property creation. > > Thank you! > > Esteban A. Maringolo +1. It also avoids having to dive a level deeper in a debugger when you want to inspect the current value vs initial value without modifying state. For naming, I tend to use one of several depending on the use; a) initialX b) defaultX c) calculateX depending on whether the property is a) expected to change value during the lifetime of the object b) have an optional value provided at creation, then be static c) always be calculated (ie, an instvar used to cache expensive results used often) Cheers, Henry -- View this message in context: http://forum.world.st/Lazy-initialization-patterns-tp4958897p4959054.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 7, 2017

Re: [Pharo-users] sharing context/variables between multiple playgrounds

by Pavel Krivanek

In that cases I simply make them global. -- Pavel 2017-08-07 10:16 GMT+02:00 Peter Uhnak <i.uhnak(a)gmail.com>: > Hi, > > is there a way to share context/variables between multiple playgrounds? > > E.g. in Playground window 1 I declare > > ``` > factor := 70. > ``` > > and in Playground window 2 I do (without declaring `factor`) > > ``` > 5 * factor. "-> 350" > ``` > > > Thanks, > Peter > >

Aug. 7, 2017

sharing context/variables between multiple playgrounds

by Peter Uhnak

Hi, is there a way to share context/variables between multiple playgrounds? E.g. in Playground window 1 I declare ``` factor := 70. ``` and in Playground window 2 I do (without declaring `factor`) ``` 5 * factor. "-> 350" ``` Thanks, Peter

Aug. 7, 2017

Re: [Pharo-users] gtInspector override default select behavior

by Andrei Chis

Hi, On Mon, Aug 7, 2017 at 5:28 AM, Evan Donahue <emdonahu(a)gmail.com> wrote: > Hello, > > I have a gtInspector extension a tree-structured object. By default, when > I click on one of the objects in the gtInspector, the inspector opens up > another inspector on that node (using the finder-style display). > > What I would like to know is, is it possible to override the default click > behavior so that, instead of opening the next inspector on that node of the > tree, it opens on the result of a block run on that tree. Specifically, I > have this: > > gtInspectorSource: composite > <ignoreForCoverage> > <gtInspectorPresentationOrder: 10> > composite tree > title: 'Source'; > children: [ :r | r sourceChildren ]; > format: [ :r | r sourceName ]; > display: self > > and I was hoping there was some way I could do something like this: > > ... > display: self; > onSelectAction: [ :r | r next ] > > so when I click, I get an inspector not on the node of the tree r, but on > r next. > You can get this behaviour by using #send:. This method gets a block that is executed to determine the value that will be sent to the next column. composite tree title: 'Source'; children: [ :r | r sourceChildren ]; format: [ :r | r sourceName ]; display: self send: [ :r | r next ] Cheers, Andrei > > Thanks, > > Evan >

Aug. 7, 2017

gtInspector override default select behavior

by Evan Donahue

Hello, I have a gtInspector extension a tree-structured object. By default, when I click on one of the objects in the gtInspector, the inspector opens up another inspector on that node (using the finder-style display). What I would like to know is, is it possible to override the default click behavior so that, instead of opening the next inspector on that node of the tree, it opens on the result of a block run on that tree. Specifically, I have this: gtInspectorSource: composite <ignoreForCoverage> <gtInspectorPresentationOrder: 10> composite tree title: 'Source'; children: [ :r | r sourceChildren ]; format: [ :r | r sourceName ]; display: self and I was hoping there was some way I could do something like this: ... display: self; onSelectAction: [ :r | r next ] so when I click, I get an inspector not on the node of the tree r, but on r next. Thanks, Evan

Aug. 7, 2017

Re: [Pharo-users] Glorp: `session login` fails for Garage SQLite

by Herby VojÄÃk

Esteban A. Maringolo wrote: > 2017-08-06 8:05 GMT-03:00 Herby VojÄÃk<herby(a)mailbox.sk>: >> Guillermo Polito wrote: >>> How did you install garage and glorp? Catalog, configurations? Can you >>> paste here the installation instructions you followed? >> >> Just adding GarageGlorp as dependency: >> configuration: 'GarageGlorp' with: [ spec >> version: #stable; >> repository: > >> I presume this is how it should be done? > > It is. [1] > > >> In fact, from what I saw, it seems Glorp accumulated its share of technical >> debt, drivers came and went, platforms, too, dialects on which it runs, too. >> It seems to me it needs serious detanglement. Get rid of ifs, structure >> clenly, change ifs comparing to hardcoded symbols with double dispatch, etc. > > Glorp as a project accumulates technical debt because it is an old > framework, which in the last years has received maintenance in its > main trunk but is missing several refactorings and a good > re-architecture of its internals. > > Also, since there wasn't an official maintenance of the ports from VW > to other languages, there are many "old" ports still around, some > work, some doesn't, but they add to the confusion. Think of Seaside > being ported several times from Pharo to, let's say, VW, and many of > those ports were abandoned for a long time. > > I attach a screenshot from the latest version of Glorp in VisualWorks > 8 (the main trunk), it has the same login methods as the Pharo > version. Yeah, those probably aren't a problem (though, sometime self accessor, sometimes accessor), it's PharoDatabaseAccessor >> encoding which sends the mythical #queryEncoding. > [1] See: http://files.pharo.org/books-pdfs/booklet-Glorp/2017-05-02-Glorp-Spiral.pdf Yeah, thanks, without that book I would be hardly be able to use Glorp at all. > Regards, > > Esteban A. Maringolo

Aug. 6, 2017

Re: [Pharo-users] Best Practices for Bundling Documentation

by Offray Vladimir Luna CÃ¡rdenas

Hi Evan, I have been working on the issue of documentation in Pharo, including bundling. So here comes my take on that. Sorry if it sounds a little bit self-promotional, but I'm really passionate about the almost unknown and unexplored possibilities of Pharo for documentation. Grafoscopio is a tool for interactive documentation, data storytelling and reproducible research made in Pharo [1]. You can see a short video of how it looks and what it does in [1a]. With Grafoscopio, you can have a single document for your different documentation tasks from a complete book, to a small tutorial, to something in between, to a small outline with just notes and links, etc. Documents in Grafoscopio are organized as structured as trees, which gives them hierarchy and sequence. Grafoscopio User Manual [2] was made, of course, in Grafoscopio (we love self-referential systems :-P). Grafoscopio uses the powerful, versatile, well maintained, easy to setup and configure Pandoc [3] to export documents to several formats. You can add custom templates and options to your documents in several formats (see for example [4]). All document information, including setup options can be hold in a single Grafoscopio file, called notebook, and you can even choose if you want to keep something in the notebook that will be hidden in some exportation format and use/define special words and tags to control the way the documents are traversed and exported (see the %keywords part of the manual). Grafoscopio has preliminary integration with the minimalist and self contained Fossil[5], to support collaboration and reproducible research and also with Zotero bibliographic management system. [1] http://mutabit.com/grafoscopio/index.en.html [1a] http://mutabit.com/repos.fossil/alvicoda/ [2] http://mutabit.com/repos.fossil/grafoscopio/doc/tip/Docs/En/Books/Manual/ma… [3] http://pandoc.org/ [4] http://mutabit.com/repos.fossil/piamed/doc/tip/Libro/libro.pdf [5] http://fossil-scm.org/ [6] https://www.zotero.org/ To package manuals and tutorials, there is a GrafoscopioDocumentation object that defines a (Fossil) documentation repository and the files there that are part of a documentation project. GrafoscopioDocumentation knows how to query and update the repositories using the standard Fossil JSON API. That's the way I use to package documents about several projects made in Grafoscopio, including its manual, and the Dataviz[6] project and the upcoming Data Journalism Manual [7]. [6] http://mutabit.com/repos.fossil/grafoscopio/doc/tip/Packages/Dataviz/intro.… [7] http://mutabit.com/repos.fossil/mapeda/index We have an small, active and diverse community of people using and extending Grafoscopio in our hackerspace [8], that includes librarians, journalists, activists, philosophers and others and in our Spanish mailing list we also get and answer English mail, if you need any support (see [1] for community links). [8] http://hackbo.co/ So, give a look to Grafoscopio for your documentation needs and let us know if you need any help with it. Cheers, Offray On 04/08/17 19:19, Evan Donahue wrote: > Hello, > > I'm working on cleaning up a couple of projects for release, and I was > wondering what the best practices were for including appropriate > documentation with projects. Should I just drop a text blob in a > prominent class comment? Is there a tool for structuring > documentation? Is documentation typically kept separate from the code? > Seems natural to include it so you never have to leave the image, but > I'm not sure what most people do. > > Thanks, > Evan

Aug. 6, 2017

Re: [Pharo-users] PetitParser: Parse X as long as it's not Y

by PBKResearch

Sean A supplementary point I have just realised. The basic 'and' idea is correct, but my example is over-simplified. As written, it will reject any string beginning with 'Bar' or 'Baz'. If you use this pattern, you will need to be careful how you define the exclusion. Peter -----Original Message----- From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of PBKResearch Sent: 06 August 2017 13:28 To: 'Any question about pharo is welcome' <pharo-users(a)lists.pharo.org> Subject: Re: [Pharo-users] PetitParser: Parse X as long as it's not Y Sean This seems to be what the PPAndParser is designed for. I tried the following: identifier := #letter asParser plus flatten. exclusion := ('Bar' asParser / 'Baz' asParser) negate. restricted := identifier and, exclusion. restricted matches: 'abc'. "--> true" restricted matches: 'Baz'. "--> false" (Note the comma after 'and' is necessary - this wasted me a few minutes in trying.) Hope this helps Peter Kenny -----Original Message----- From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Sean P. DeNigris Sent: 05 August 2017 21:26 To: pharo-users(a)lists.pharo.org Subject: [Pharo-users] PetitParser: Parse X as long as it's not Y How do I tell Petit Parser to parse a string of certain allowable characters as long as the final result isn't a particular string? E.g. consume an identifier as long as it's not 'Baz' or 'Bar' Thanks ----- Cheers, Sean -- View this message in context: http://forum.world.st/PetitParser-Parse-X-as-long-as-it-s-not-Y-tp4958895.ht ml Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 6, 2017

Re: [Pharo-users] Glorp: `session login` fails for Garage SQLite

by Esteban A. Maringolo

2017-08-06 8:05 GMT-03:00 Herby VojÄÃk <herby(a)mailbox.sk>: > Guillermo Polito wrote: >> >> How did you install garage and glorp? Catalog, configurations? Can you >> paste here the installation instructions you followed? > > > Just adding GarageGlorp as dependency: > configuration: 'GarageGlorp' with: [ spec > version: #stable; > repository: > I presume this is how it should be done? It is. [1] > In fact, from what I saw, it seems Glorp accumulated its share of technical > debt, drivers came and went, platforms, too, dialects on which it runs, too. > It seems to me it needs serious detanglement. Get rid of ifs, structure > clenly, change ifs comparing to hardcoded symbols with double dispatch, etc. Glorp as a project accumulates technical debt because it is an old framework, which in the last years has received maintenance in its main trunk but is missing several refactorings and a good re-architecture of its internals. Also, since there wasn't an official maintenance of the ports from VW to other languages, there are many "old" ports still around, some work, some doesn't, but they add to the confusion. Think of Seaside being ported several times from Pharo to, let's say, VW, and many of those ports were abandoned for a long time. I attach a screenshot from the latest version of Glorp in VisualWorks 8 (the main trunk), it has the same login methods as the Pharo version. [1] See: http://files.pharo.org/books-pdfs/booklet-Glorp/2017-05-02-Glorp-Spiral.pdf Regards, Esteban A. Maringolo

Aug. 6, 2017