[Pharo-users] Playground doesn't respect LF endings
Hi, when I paste a text into the playground with line endings containing just LF (unix-style), then navigation to beginning/end of a line instead jumps to the beginning/end of the text. (I guess it is hardcoded to CR only). Right now I have to execute `Clipboard clipboardText withSqueakLineEndings asString` and then copy&paste the result. Peter
Re: [Pharo-users] Problem with ThreadPool on os windows - no execution
Hi Sabine, There shouldn't be any differences between the platforms. Maybe I broke something in the update recently where I make the pool start/stop based on whether it has any jobs. You could try the older version that starts the pool on startup and report back if it works or not. Seems strange that having a halt in there makes it run. Another thing you could do with the current version is open the process browser (e.g. World Menu > Tools > Process Browser) and set it to auto-update then run something like: 1000 timesRepeat:[[100 milliSeconds wait. 1+1] queueWork]. And see if it the ThreadPool wakes up and runs them. If it is working a number of processes that start with the name "pool:" will appear in the list. And then disappear.Up to 15 I think. And I haven't tried the new code on anything but Pharo 5 and don't plan to for a while but would be surprised if that was important. Sabine Manaa wrote > Hi, > > because of [1] I use ThreadPool [2] and while developing on my mac it > worked fine. > But now, testing it on my production server which is a windows machine, it > does not work which means, it is some kind of magic, the code within the > block > > [anObject doSomething] queueWork is not run. When changing it to > [anObject halt doSomething] queueWork the code is run! > > Changing my code from >>queueWork back to >>fork proves that everything is > fine now and there is a problem with ThreadPool. > > When I was playing around to find the problem, I noticed the following: > > I created a button like this: > > html mdlButton onClick: (html jQuery ajax > script: [ :script | | theSession | > theSession := self session. > [ theSession inspect ] queueWork. ]); > with: 'test' > > Mac: it works nearly immediately > Windows: it does not work ... except when I add a halt in it > but: When I then do this after clicking on the test button: > > 20 timesRepeat: [[ Transcript crShow: Time now printString] queueWork ], > > the sessions inspector also comes up > > It seems that the process is hanging until the next work is to be done. > > Before going deeper in it my question is: > does anyone use it on windows? > is it made for windows, too? > are there any experiences with windows and ThreadPool? > did I miss something? > how can I fix this? > > Regards > Sabine > > [1] > http://forum.world.st/ThreadPool-with-Seaside-how-td4956812.html#a4957192 > [2] http://smalltalkhub.com/#!/~pdebruic/ThreadPool/ -- View this message in context: http://forum.world.st/Problem-with-ThreadPool-on-os-windows-no-execution-tp4958454p4959151.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] gtInspector override default select behavior
Perfect. Do you know if these methods are systematically documented anywhere? I feel like if I understood Glamour better these things might be more obvious, but I can never manage to infer the gtInspector calls from the Glamour docs. Thanks. -- View this message in context: http://forum.world.st/gtInspector-override-default-select-behavior-tp4959037p4959141.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] Best Practices for Bundling Documentation
Gracias, pronto lo reviso. -- View this message in context: http://forum.world.st/Best-Practices-for-Bundling-Documentation-tp4958788p4959140.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] Best Practices for Bundling Documentation
Ok, thanks. -- View this message in context: http://forum.world.st/Best-Practices-for-Bundling-Documentation-tp4958788p4959139.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] Lazy-initialization patterns
> On 7 Aug 2017, at 10:50, Henrik Sperre Johansen > 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
Re: [Pharo-users] sharing context/variables between multiple playgrounds
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 > >
Re: [Pharo-users] Fetching https site content with Zinc
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 : > 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. >
[Pharo-users] Fetching https site content with Zinc
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.
Re: [Pharo-users] sharing context/variables between multiple playgrounds
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 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 >
Re: [Pharo-users] Lazy-initialization patterns
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.
Re: [Pharo-users] sharing context/variables between multiple playgrounds
In that cases I simply make them global. -- Pavel 2017-08-07 10:16 GMT+02:00 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 > >
[Pharo-users] sharing context/variables between multiple playgrounds
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
Re: [Pharo-users] gtInspector override default select behavior
Hi, On Mon, Aug 7, 2017 at 5:28 AM, Evan Donahue 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 > > > 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 >
