August 2017 - Pharo-users - lists.pharo.org

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

by Evan Donahue

Ok, thanks. -- View this message in context: http://forum.world.st/Best-Practices-for-Bundling-Documentation-tp4958788p4… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 7, 2017

Re: [Pharo-users] Lazy-initialization patterns

by Esteban Lorenzano

> On 7 Aug 2017, at 10:50, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > >>> 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 ] I favour this approach :) andâ¦ I consider it the âstandard approachâ for what goes into Pharo itself. Esteban

Aug. 7, 2017

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

by Offray Vladimir Luna CÃ¡rdenas

Hi, I have been thinking in a similar problem for Grafoscopio. In that way, we could have the same persistence among playgrounds in a similar way to Jupyter's persistence among code cells. My bet would be on using the playground bindings that you get when it is executed. In Grafoscopio's case, I'm thinking in storing a them into some kind of ordered set that is available to all notebook nodes... still these are early thoughts and I don't like that the bindings only operate when you have not defined the variable between bars... see screenshot below. So, to add to Peter's question: - There is any way to access not only variables bindings in a playground, but all variables that are declared there, once it is executed? - How can tap into the playgrounds self-completion behavior, so it can read variable names stored in a particular place? Thanks, Offray On 07/08/17 03:16, Peter Uhnak 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] Fetching https site content with Zinc

by Esteban A. Maringolo

Hi, Probably, the hashbang (#code) is causing the front end proxy to respond with a 400 error. It works if you do: ZnEasy get: 'https://etherscan.io/address/0xbcff2d15c698d3874bc29aa170c89fd7a6146a4b' However, I think there might be an specify REST API to get the Solidity code of that SmartContract. Also, you can use an available Pharo driver for Ethereum: https://github.com/sbragagnolo/Fog I'm not familiar with Ethereum, but according to Fog's docs you can get the contract doing: FogConnection eth getContract: 'ContractHash' blockTag: 'latest' Regards! Esteban A. Maringolo 2017-08-07 9:16 GMT-03:00 Henrique Rocha <henrique.rocha(a)gmail.com>: > Hi there, > > I am trying to automate the fetching of a site content in Pharo. Basically, > I want to fetch smart contract information from Etherscan. Here is an > example URL: > https://etherscan.io/address/0xbcff2d15c698d3874bc29aa170c89fd7a6146a4b#code > > I tried to use Zinc to fetch that, here is my code (very simple): > > ZnEasy get: > 'https://etherscan.io/address/0x9C169d81420aAD7D8a0D6d9F295C3ba2C33575De#code' > > Although it runs without errors the fetched content is "Bad Request - > Invalid URL" and not the actual website. > > Anyone know what am I doing wrong here? > > > > -- > View this message in context: http://forum.world.st/Fetching-https-site-content-with-Zinc-tp4959072.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

Aug. 7, 2017

Fetching https site content with Zinc

by Henrique Rocha

Hi there, I am trying to automate the fetching of a site content in Pharo. Basically, I want to fetch smart contract information from Etherscan. Here is an example URL: https://etherscan.io/address/0xbcff2d15c698d3874bc29aa170c89fd7a6146a4b#code I tried to use Zinc to fetch that, here is my code (very simple): ZnEasy get: 'https://etherscan.io/address/0x9C169d81420aAD7D8a0D6d9F295C3ba2C33575De#code' Although it runs without errors the fetched content is "Bad Request - Invalid URL" and not the actual website. Anyone know what am I doing wrong here? -- View this message in context: http://forum.world.st/Fetching-https-site-content-with-Zinc-tp4959072.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 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