December 2017 - Pharo-users

Re: [Pharo-users] Simplest 'REPL'

by Tudor Girba

Hi, I would encourage you to simply extend the inspector. Something like this: MyEvaluator>>gtInspectorEvaluateIn: composite <gtInspectorPresentationOrder: 0> composite text title: âEvaluatorâ; populate: #selection iconName:#glamorousGo entitled: âEvaluate' with: [ :textPresentation | self from: (MyReader from: textPresentation text)] And then inspect MyEvaluator new. If you cannot have an evaluator instance without the reader, add the extension to the class side of MyEvaluator and inspect the MyEvaluator class. Cheers, Doru > On Dec 9, 2017, at 12:04 AM, cheshirecatalyst <dekathexis(a)gmail.com> wrote: > > I've recently picked up pharo, and am writing a small interpreter for a trivial language the details of which are unimportant. However I am looking for the simplest way to avoid having to use playground and Transcript to do something like > > | reader eval | > reader := MyReader from: 'some stuff in my DSL'. > eval := MyEvaluator from: reader. > Transcript show: eval evaluate. > > I'm tired of having to change 'some stuff in my DSL' to a new expression and run it in playground. > > I don't really care which is easier, a Morphic with an input box at the bottom to put my expressions in with output up top, or a something like CommandShellTranscript (which i have looked at but is too complex for me to figure out how to get the desired result from). > > Basically I want to be able to use my DSL outside of playground, but still in image. -- www.tudorgirba.com www.feenk.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."

Dec. 9, 2017

Re: [Pharo-users] [Moose-dev] [ann] gtmondrian

by Tudor Girba

Hi, Here is an example that shows the distinction between edge and line: elementToVisualize := BlChicken chicken. elementToVisualize forceLayout. root := BlElement new constraintsDo: [:c | c horizontal matchParent. c vertical matchParent]. elementToVisualize allChildrenBreadthFirstDo: [ :each | | label | label := BlTextElement new text: each gtDisplayString asRopedText; background: Color white; effect: (BlDropShadowEffect color: (Color gray alpha: 0.5) width: 10 offset: 0@0). label userData at: #model put: each. root children detect: [ :child | (child userData at: #model ifAbsent: [ nil ]) = each parent ] ifFound: [ :parentLabel | | edge | edge := GtGraphEdge new from: parentLabel to: label. parentLabel constraints graph addConnectedEdge: edge. label constraints graph addConnectedEdge: edge ]. root addChild: label]. root layout: (GtGraphHorizontalTreeLayout new layered; verticalGap: 20). root With this we visualize the elements that make the chicken element demo: - we create a label for each element - we find the parentLabel corresponding to the parent element - we create an edge between the parentLabel and the current label The example gives us this: The edge is a constraint. It has no visual impact. And the graph layouts take the edge constraints into account. The cool thing is the GtGraphEdge is defined next to the graph layout classes, not in the core of Bloc. To add a visual impact, we have to create a separate line: Thanks for the question. This email is now a comment in the graph layout examples and can be viewed like this: Cheers, Doru > On Dec 9, 2017, at 8:43 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > Super super cool. > > >> On 9 Dec 2017, at 08:14, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Hi, >> >> We are happy to announce GT Mondrian, a graph visualization engine built on top of Bloc. >> >> It is similar to the original Mondrian and the Mondrian from Roassal, but it is different in that it is built directly out of Bloc elements. This is interesting because it allows us to combine typical widgets with visualizations. The other interesting thing about it is that it validates the design of Bloc: right now, the implementation has 509 lines of code (excluding graph-specific layouts). The goal is to make visualization a first class citizen and an integral part of the IDE. >> >> The key ingredient that made this happen is that Bloc can now treat graph layouts, such as tree or force based, behave under the same rules as typical widget layouts, such as grid or flow. The challenge comes from the fact that a graph layout depends on the notion of edges between elements, and we did not want to have elements know about edges in the core of Bloc. >> >> The solution was to split the typical edge implementation in graph visualization libraries into two distinct concepts: >> â¢ Line is an element that draws the connections. >> â¢ Edge defines constraints imposed by connections between elements. > > Can you give an example? > > BTW doru did you think about having a bloc layer on top of telescope model? > Because from that perspective telescope offers a visualisation model while roassal/mondrian like design are > more a pen-oriented metaphor. > > I wanted to do it to learn Bloc but Iâm running against time and trying to flush pilling duties (I want to also release > the book that we wrote with luc and olivier and convert the seaside book and and andâ¦.. :( > > > >> >> Thus, edges form constraints, and constraints are what layouts deal with. That is one reason why elements in bloc have the ability of defining layout-specific constraints. Using this, we can nicely define edges between elements as a plugin to Bloc, but still be able to connect arbitrary elements. What's more, it turns out that we need constraints for other layouts as well. For example, an element in a grid layout might specify the span. >> >> The API of GT Mondrian is similar to the one from Roassal, but there are a few differences as well. These are described in the Pillar documentation available in the GitHub repo. >> >> The best way to experience GT Mondrian and its documentation is to load the GToolkit as described here: >> https://github.com/feenkcom/gtoolkit >> >> If you download the GT code through Iceberg, the documentation can be experienced live by inspecting: >> './pharo-local/iceberg/feenkcom/gtoolkit-visualizer/doc/mondrian/index.pillar' asFileReference >> >> >> <mondrian-doc.png> >> >> >> >> >> >> Cheers, >> The feenk team >> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Quality cannot be an afterthought." >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev > > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr > http://www.synectique.eu / http://www.pharo.org > 03 59 35 87 52 > Assistant: Julie Jonas > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza > Villeneuve d'Ascq 59650 > France > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev -- www.tudorgirba.com www.feenk.com "Every successful trip needs a suitable vehicle."

Dec. 9, 2017

Re: [Pharo-users] HTTP request question for an arango driver

by Yann Lesage

Le 09/12/2017 Ã 15:52, Sven Van Caekenberghe a Ã©critÂ : > Hi Yann, > > Zinc HTTP Components can do 1000s of requests per second, to localhost (so excluding a real network) and using a single ZnClient instance with a reused connection (HTTP/1.1's default). Of course, data size is also a factor, I am talking about small requests/responses. > > I browsed your code a bit on GitHub. You do reuse an instance, so that is good. But I think you are using HTTPS (TLS), which is a real slowdown (encryption is native, but costs real resources). Also, your data payload is using JSON which also adds a cost (parsing, generating). Thanks for this review. > > So what you measured sounds about right. You might be able to optimise a bit, but that won't give you a factor 10 improvement, IMHO. The trick is usually to make as few requests as possible. A factor of 10 maximum ? Ok, this indication help me. For the trick, I know it. But it's must be performed by user no ? > Sven > >> On 8 Dec 2017, at 16:32, Yann Lesage <yannlesag(a)gmail.com> wrote: >> >> Hello, >> >> >> I write an driver for Arangodb . So like it's indicated in Arango documentation, I use the HTTP API. The repo is https://github.com/Valtena/Pharango >> >> >> Now, the problem : Arango using Znclient make around 1 000 requests/second. >> >> >> And the question : Are there any recommended pratice to have the better performance with ZNClient or a better way to perform lot of HTTP requests ? >> >> >> Thanks for your attention, >> >> Yann Lesage >> >> >> >

Dec. 9, 2017

Re: [Pharo-users] Behold Pharo: The Modern Smalltalk

by Dimitris Chloupis

The beginner way ------ 1. Open Pharo 6 2. Go to Welcome window 3. Go to Keymap Browser tab 4. Right click on a shortcut entry (for example global shortcut for close window) 5. Choose Inspect Action 6. Go to Source Code tab 7. Profit The Pharo coder way ---- Or go to SystemWindow class >> buildShortcutsOn: or got to NautilusWindow class >> build....ShortcutsOn: (any method will do) or search for any method using the <keymap> pragma On Sat, Dec 9, 2017 at 12:06 PM Prof. Andrew P. Black <black(a)cs.pdx.edu> wrote: > > On 9 Dec 2017, at 07:44 , Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > Making shortcuts in Pharo is no big deal, if 10% of people asking for > Emacs or vim shortcuts bothered creating just 10 shortcuts each we would > have by now at least 100 Emacs shortcuts in Pharo. When one say that needs > something that He or she is not willing to do even 1% of its work, then he > does not need it enough for others to bother. > > > In September, I posted an Issue on pharo.fogbuz > <https://pharo.fogbugz.com/f/cases/20466/Keyboard-Shortcuts>: making > keyboard shortcuts for the Pharo Smalltalk editor is not easy, but should > be. No one has responded to that issue saying that it really is easy, and > explaining how to do it. So if you know, I invite you to work on this > issue. tl;dr: I though that it was easy too, but after spending a couple > of days trying to figure it out, gave up. > > If 10% of the energy expended in this thread had gone into fixing open > issues, then Pharo would be getting better every day. >

Dec. 9, 2017

Re: [Pharo-users] HTTP request question for an arango driver

by Sven Van Caekenberghe

Hi Yann, Zinc HTTP Components can do 1000s of requests per second, to localhost (so excluding a real network) and using a single ZnClient instance with a reused connection (HTTP/1.1's default). Of course, data size is also a factor, I am talking about small requests/responses. I browsed your code a bit on GitHub. You do reuse an instance, so that is good. But I think you are using HTTPS (TLS), which is a real slowdown (encryption is native, but costs real resources). Also, your data payload is using JSON which also adds a cost (parsing, generating). So what you measured sounds about right. You might be able to optimise a bit, but that won't give you a factor 10 improvement, IMHO. The trick is usually to make as few requests as possible. Sven > On 8 Dec 2017, at 16:32, Yann Lesage <yannlesag(a)gmail.com> wrote: > > Hello, > > > I write an driver for Arangodb . So like it's indicated in Arango documentation, I use the HTTP API. The repo is https://github.com/Valtena/Pharango > > > Now, the problem : Arango using Znclient make around 1 000 requests/second. > > > And the question : Are there any recommended pratice to have the better performance with ZNClient or a better way to perform lot of HTTP requests ? > > > Thanks for your attention, > > Yann Lesage > > >

Dec. 9, 2017

Re: [Pharo-users] Simplest 'REPL'

by Ben Coman

On 9 December 2017 at 07:04, cheshirecatalyst <dekathexis(a)gmail.com> wrote: > I've recently picked up pharo, and am writing a small interpreter for a > trivial language the details of which are unimportant. However I am looking > for the simplest way to avoid having to use playground and Transcript to do > something like > > | reader eval | > reader := MyReader from: 'some stuff in my DSL'. > eval := MyEvaluator from: reader. > Transcript show: eval evaluate. > > I'm tired of having to change 'some stuff in my DSL' to a new expression > and run it in playground. > > I don't really care which is easier, a Morphic with an input box at the > bottom to put my expressions in with output up top, or a something like > CommandShellTranscript (which i have looked at but is too complex for me to > figure out how to get the desired result from). > > Basically I want to be able to use my DSL outside of playground, but still > in image. > A while ago I had success embedding the old Workspace into an application. Start with... Workspace subclass: #MyWorkspace instanceVariableNames: '' classVariableNames: '' package: 'Tool-Workspace' MyWorkspace >> whenTextAccepted: anAnnouncement "MyWorkspace open" self inform: anAnnouncement text MyWorkspace >> createTextView | v | v := super createTextView. v beForPlainText. ^v. cheers -ben

Dec. 9, 2017

Re: [Pharo-users] Behold Pharo: The Modern Smalltalk

by Ben Coman

An extra thing for the first article, maybe change the package name from "HelloDemo" to "HelloWorld" On 9 December 2017 at 11:37, horrido <horrido.hobbies(a)gmail.com> wrote: > Pharo: The Next Ten Minutes > <https://medium.com/@richardeng/pharo-the-next-ten-minutes-a17899dc9a58> > . > > Feedback welcome. > > I will be leaving for vacation on Sunday for two weeks. Feedback should be > given to me asap. Thanks. > I see you have auto-update-process turned on, but you didn't tell users to do this. (I think it is useful to have on. @all, I'm curious why its not on by default) Double "little" in first sentence. You should describe how you enter the second method over the top of the first. People sometimes get stuck thinking they'll be altering the #sayIt method. In hindsight, when readers go to experiment themselves, some may drop the #wait to see how fast it can generate messages which will lock up the UI due to co-operative scheduling within a priority. It will be better to use... [...] #forkAt: 30 named: 'Count de Money' > How do you like it? maybe... How do you like it? The implication is that in the early stages of protoyping, you don't need to slow down to build an object/relational mapping. Just design with pure objects and persist sample data in the Image. ----------------- The article is good but feels too short. One additional demonstration would look good. To facilitate this, change the demo code to use two methods. sayCount: anInteger self inform: anInteger printString. counter | count | count := 0. [1000 timesRepeat: [count := count + 1. self sayCount: count. 2 seconds wait]] forkNamed: 'Count de Money' Then after the existing end of the article... Now consider your current language of choice... Say you are part of the Testing Team and a unit test errors intermittently, or you're in Operations where an intermittent error occurs in a production system. Typically the program exits, maybe dumping state but losing the live context where the error occurred. What would it take to reproduce the exact error context for Developers to analyze? Lets see how Pharo handles this by introducing an error into a running 'Count de Money' process. (If its not running, evaluate "Greeter new counter") Make this modification... sayCount: anInteger self inform: anInteger * 10 printString. Immediately after you save this, a pre-debug window pops up... [screen snapshot pre-debug top of stack] Scroll down and click on "sayCount:" and you should see the debugger... [screen snapshot full debugger on sayCount with "* 10 printString" highlighted] Now as before, you can record the execution state of all running threads by saving a Pharo Image. Later when you reopen Pharo you can continue debugging the faulted thread. So give this a try. Save and quit Pharo now. (You could even transfer the .image file together with its paired .changes file to another machine with Pharo.) Open the Pharo Image again. Now we are ready to fix the error. To explain the error, one thing Pharo newcomers need to adapt to is that arithmetic operators are just normal message sends with no special precedence. Pharo has simple semantics with just three precedence rules, evaluated right to left. Unary messages like "printString" are always evaluated first. Binary messages like " * " are evaluated second. Keyword messages like "inform:" are evaluated last. So the error here is that we multiplied an integer with a string. Easily fixed... sayCount: anInteger self inform: (anInteger * 10) printString. After saving, click <Proceed> and observe the running process continues rather than needing to restart it. In many situations, continuing from errors like this rather than waiting for a restarted program to progress to the same state facilitates a very quick "debug->edit->compile->run" development loop. For a similar demonstration, check out [PharoLambda Serverless Debugging, https://www.youtube.com/watch?v=bNNCT1hLA3E ] HTH cheers -ben

Dec. 9, 2017

Re: [Pharo-users] Simplest 'REPL'

by H. Hirzel

I understand that you want to write a tool with an input field and an output field and a button 'Evaluate'. Is this correct? If yes you need to learn a little bit of Spec to construct your own tool. Have a look at the examples for Spec in the help system. There is also a booklet about Spec. http://books.pharo.org/spec-tutorial/ HTH Hannes On 12/9/17, cheshirecatalyst <dekathexis(a)gmail.com> wrote: > I've recently picked up pharo, and am writing a small interpreter for a > trivial language the details of which are unimportant. However I am looking > for the simplest way to avoid having to use playground and Transcript to do > something like > > | reader eval | > reader := MyReader from: 'some stuff in my DSL'. > eval := MyEvaluator from: reader. > Transcript show: eval evaluate. > > I'm tired of having to change 'some stuff in my DSL' to a new expression > and run it in playground. > > I don't really care which is easier, a Morphic with an input box at the > bottom to put my expressions in with output up top, or a something like > CommandShellTranscript (which i have looked at but is too complex for me to > figure out how to get the desired result from). > > Basically I want to be able to use my DSL outside of playground, but still > in image. >

Dec. 9, 2017

Re: [Pharo-users] HTTP request question for an arango driver

by Norbert Hartl

> Am 08.12.2017 um 21:14 schrieb Stephane Ducasse <stepharo.self(a)gmail.com>: > > Yann > I do not think that connecting a database via a HTTP client can be as > fast as with a FFI or other means. > This is mainly why database like Gemstone are superior for accessing a > lot of data. > Stef > Do you have any numbers to back this? We are not talking about a local database. The usual deployment case is that the database is remote and clustered so you need to connect one or more hosts at the same time. Via FFI you would trigger native code that does network calls to the database. The main network handling part is in the SocketPlugin. So Iâm not sure how much faster it will be to use FFI. IIRC using FFI is still a stop-the-world action, right? This has some drawbacks, too. In order to get the maximum out of it you would need to use callbacks (do they work with uffi?) and write a lot stuff in C. And debugging is hell. I think that one of the things that make gemstone fast is that the in-memory format is the same as the disk-format so no need to serialize/materialize. That is one of the high costs in using a database. And this you would still do in pharo, right? So I would be really interested in some numbers of a use case like this. Norbert >> On Fri, Dec 8, 2017 at 4:32 PM, Yann Lesage <yannlesag(a)gmail.com> wrote: >> Hello, >> >> >> I write an driver for Arangodb . So like it's indicated in Arango >> documentation, I use the HTTP API. The repo is >> https://github.com/Valtena/Pharango >> >> >> Now, the problem : Arango using Znclient make around 1 000 requests/second. >> >> >> And the question : Are there any recommended pratice to have the better >> performance with ZNClient or a better way to perform lot of HTTP requests ? >> >> >> Thanks for your attention, >> >> Yann Lesage >> >> >>

Dec. 9, 2017

Re: [Pharo-users] Behold Pharo: The Modern Smalltalk

by serge.stinckwich＠gmail.com

EnvoyÃ© de mon iPhone > Le 9 dÃ©c. 2017 Ã 11:05, Prof. Andrew P. Black <black(a)cs.pdx.edu> a Ã©crit : > > >> On 9 Dec 2017, at 07:44 , Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: >> >> Making shortcuts in Pharo is no big deal, if 10% of people asking for Emacs or vim shortcuts bothered creating just 10 shortcuts each we would have by now at least 100 Emacs shortcuts in Pharo. When one say that needs something that He or she is not willing to do even 1% of its work, then he does not need it enough for others to bother. > > In September, I posted an Issue on pharo.fogbuz: making keyboard shortcuts for the Pharo Smalltalk editor is not easy, but should be. No one has responded to that issue saying that it really is easy, and explaining how to do it. So if you know, I invite you to work on this issue. tl;dr: I though that it was easy too, but after spending a couple of days trying to figure it out, gave up. > > If 10% of the energy expended in this thread had gone into fixing open issues, then Pharo would be getting better every day. +1 Less talk more Pharo !

Dec. 9, 2017