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

Re: [Pharo-users] Documentation

by Offray Vladimir Luna CÃ¡rdenas

Hi Jimmie, I really like the impulse you bring and the recent discussion about Beyond Live Coding... it is pretty timely precisely about a discussion we were having with one friend about Python vs Pharo. On the documentation front, I have created a interactive documentation called Grafoscopio [1]. It follows a different path that Pillar and leverage on existing solutions like Pandoc to convert to several format. Also it tries to bring ideas from the interactive notebooks from (Jupyter, Beaker, Zeppeling) and outlining worlds (Leo Editor, Org Mode) to the Pharo world and, hopefully, new bring ideas also. I'm preparing a new edition of Grafoscopio with suggestions for a paper send to the Journal of Open Source Software [2], by our own Serge Stinckwich, on first week of August, and also we will have a re-release of the Data Driven Journalist Handbook this weekend as a Grafoscopio document. So stay tuned. [1] http://mutabit.com/grafoscopio/index.en.html [2] http://joss.theoj.org/papers/c92ed13fa746bc681081f9b31678841b [3] http://datajournalismhandbook.org/ If your interest is contributing to current documentation, Pillar and GitHub are the current option and if you're interested in documentation in general, and extended interactive documentation, checking Grafoscopio could be interesting. Cheers, Offray On 26/07/17 15:58, Jimmie Houchin wrote: > I am looking at participating in the documentation if that is a good > area to plug in. > > I do not necessarily have the expertise on the subjects, but I can > bring fresh eyes and the eyes of a native English speaker. > > What is the best way to assist? > > For example I am currently reading the Booklet-uFFI. > > I have some questions and suggestions. How or to whom do I communicate > these? > > If I modify the UnifiedFFI.pillar file, do I do the normal GitHub pull > requests? Or is this process handled via Iceberg? > > Do I edit them manually in a normal text editor or is there a > preferred way within Pharo. > > Is this process documented somewhere? Or do I need to document it? :) > > And what about similar for the MOOC? > > Any guidance or suggestions, and suggestions where you would like help > the most are greatly appreciated. > > Thanks. > > > Jimmie > > > >

July 27, 2017

Re: [Pharo-users] Documentation

by Herby VojÄÃk

Herby VojÄÃk wrote: > Jimmie Houchin wrote: >> I am looking at participating in the documentation if that is a good >> area to plug in. > > Pity there isn't someone like you for Amber. It's documentation is in *$##^, s/It's/Its/ > horrible state. (I don't know for Pharo's one :-) ) > > Herby >

July 27, 2017

Re: [Pharo-users] Documentation

by Herby VojÄÃk

Jimmie Houchin wrote: > I am looking at participating in the documentation if that is a good > area to plug in. Pity there isn't someone like you for Amber. It's documentation is in horrible state. (I don't know for Pharo's one :-) ) Herby

July 27, 2017

Re: [Pharo-users] Zinc: Are start and stop meant to be idempotent?

by Herby VojÄÃk

Sven Van Caekenberghe wrote: > Herby, > > In Zn #bleedingEdge > > === > Name: Zinc-HTTP-SvenVanCaekenberghe.464 > Author: SvenVanCaekenberghe > Time: 27 July 2017, 1:10:32.048978 pm > UUID: 63589259-ac11-0d00-9153-678c0082c0ce > Ancestors: Zinc-HTTP-SvenVanCaekenberghe.460 > > Make ZnSingleThreadedServer>>#start idempotent (since it called #stop and #stop does a #unregister there was a possible side effect, call #stop: false from #start instead) [thx Herby VojÄÃk] > === > > This still does not solve the core problem of #startUp[:] being called twice (apparently) in some situation. But some extra protection won't hurt. Yes, it will solve it, but mask the bigger problem. OTOH, adding debug output to #start can uncover it for those who want to experiment. Thanks, Herby P.S.: I'll wait with it until I need it, maybe it gets blessed before it it a real problem (on the dev machine, I can have no --headless for a while). > Thx for the suggestion, I hope this solves your curren t issue (remember to load Zn #bleedingEdge). > > Sven > >> On 26 Jul 2017, at 20:19, Herby VojÄÃk<herby(a)mailbox.sk> wrote: >> >> Hi, >> >> Looking at ZnServer>> start and ZnSingleThreadedServer>> stop (as ZnServer>> stop is #subclassResponsibility), I had the impression they are meant to be idempotent. >> >> The start comment is: >> >> "Start me. I will start listening on my port for incoming HTTP connections. >> If I am running, I will first stop and thus effectively restart" >> >> The stop comment is: >> >> "Stop me. I will stop listening on my port for incoming HTTP connections. >> Does nothing when I am not running" >> >> So, it seems like both start and stop try to be safe to be sent twice in a row. >> >> I did a few Transcript prints: >> >> --- >> >> 1. just stop: is ok. >> >> ZnManagingMultiThreadedServer allInstances do: #stop. >> ZnServer managedServers do: #unregister. >> Smalltalk garbageCollect. >> >> (ZnServer on: 4998) stop. >> (ZnServer on: 4997) stop ; stop. >> >> Transcript show: ZnServer managedServers; cr; >> show: ZnManagingMultiThreadedServer allInstances; cr. >> >> ==> >> >> an IdentitySet() >> an Array(a ZnManagingMultiThreadedServer(stopped 4998) a ZnManagingMultiThreadedServer(stopped 4997)) >> >> --- >> >> 2. start; stop: is ok. >> >> ZnManagingMultiThreadedServer allInstances do: #stop. >> ZnServer managedServers do: #unregister. >> Smalltalk garbageCollect. >> >> (ZnServer on: 4998) start; stop. >> (ZnServer on: 4997) start; stop; stop. >> >> Transcript show: ZnServer managedServers; cr; >> show: ZnManagingMultiThreadedServer allInstances; cr. >> >> ==> >> >> an IdentitySet() >> an Array(a ZnManagingMultiThreadedServer(stopped 4998) a ZnManagingMultiThreadedServer(stopped 4997)) >> >> --- >> >> 3. register; start; stop: is ok. >> >> ZnManagingMultiThreadedServer allInstances do: #stop. >> ZnServer managedServers do: #unregister. >> Smalltalk garbageCollect. >> >> (ZnServer on: 4998) register; start; stop. >> (ZnServer on: 4997) register; start; stop; stop. >> >> Transcript show: ZnServer managedServers; cr; >> show: ZnManagingMultiThreadedServer allInstances; cr. >> >> ==> >> >> an IdentitySet() >> an Array(a ZnManagingMultiThreadedServer(stopped 4998) a ZnManagingMultiThreadedServer(stopped 4997)) >> >> --- >> >> 4. start: is ok. >> >> ZnManagingMultiThreadedServer allInstances do: #stop. >> ZnServer managedServers do: #unregister. >> Smalltalk garbageCollect. >> >> (ZnServer on: 4998) start. >> (ZnServer on: 4997) start; start. >> >> Transcript show: ZnServer managedServers; cr; >> show: ZnManagingMultiThreadedServer allInstances; cr. >> >> ==> >> >> an IdentitySet() >> an Array(a ZnManagingMultiThreadedServer(running 4998) a ZnManagingMultiThreadedServer(running 4997)) >> >> 5. register; start: is not ok. >> >> ZnManagingMultiThreadedServer allInstances do: #stop. >> ZnServer managedServers do: #unregister. >> Smalltalk garbageCollect. >> >> (ZnServer on: 4998) register; st art. >> (ZnServer on: 4997) register; start; start. >> >> Transcript show: ZnServer managedServers; cr; >> show: ZnManagingMultiThreadedServer allInstances; cr. >> >> ==> >> >> an IdentitySet(a ZnManagingMultiThreadedServer(running 4998)) >> an Array(a ZnManagingMultiThreadedServer(running 4998) a ZnManagingMultiThreadedServer(running 4997)) >> >> The last case is not idempotent for #start. With one #start, the server is registered, with two #start's, it is not registered. >> >> Shouldn't the last case be idempotent as well? >> >> If it is, it is the bug that should be put into issue tracker? >> >> Herby >> > >

July 27, 2017

Re: [Pharo-users] Zinc: Are start and stop meant to be idempotent?

by Sven Van Caekenberghe

Herby, In Zn #bleedingEdge === Name: Zinc-HTTP-SvenVanCaekenberghe.464 Author: SvenVanCaekenberghe Time: 27 July 2017, 1:10:32.048978 pm UUID: 63589259-ac11-0d00-9153-678c0082c0ce Ancestors: Zinc-HTTP-SvenVanCaekenberghe.460 Make ZnSingleThreadedServer>>#start idempotent (since it called #stop and #stop does a #unregister there was a possible side effect, call #stop: false from #start instead) [thx Herby VojÄÃk] === This still does not solve the core problem of #startUp[:] being called twice (apparently) in some situation. But some extra protection won't hurt. Thx for the suggestion, I hope this solves your current issue (remember to load Zn #bleedingEdge). Sven > On 26 Jul 2017, at 20:19, Herby VojÄÃk <herby(a)mailbox.sk> wrote: > > Hi, > > Looking at ZnServer >> start and ZnSingleThreadedServer >> stop (as ZnServer >> stop is #subclassResponsibility), I had the impression they are meant to be idempotent. > > The start comment is: > > "Start me. I will start listening on my port for incoming HTTP connections. > If I am running, I will first stop and thus effectively restart" > > The stop comment is: > > "Stop me. I will stop listening on my port for incoming HTTP connections. > Does nothing when I am not running" > > So, it seems like both start and stop try to be safe to be sent twice in a row. > > I did a few Transcript prints: > > --- > > 1. just stop: is ok. > > ZnManagingMultiThreadedServer allInstances do: #stop. > ZnServer managedServers do: #unregister. > Smalltalk garbageCollect. > > (ZnServer on: 4998) stop. > (ZnServer on: 4997) stop; stop. > > Transcript show: ZnServer managedServers; cr; > show: ZnManagingMultiThreadedServer allInstances; cr. > > ==> > > an IdentitySet() > an Array(a ZnManagingMultiThreadedServer(stopped 4998) a ZnManagingMultiThreadedServer(stopped 4997)) > > --- > > 2. start; stop: is ok. > > ZnManagingMultiThreadedServer allInstances do: #stop. > ZnServer managedServers do: #unregister. > Smalltalk garbageCollect. > > (ZnServer on: 4998) start; stop. > (ZnServer on: 4997) start; stop; stop. > > Transcript show: ZnServer managedServers; cr; > show: ZnManagingMultiThreadedServer allInstances; cr. > > ==> > > an IdentitySet() > an Array(a ZnManagingMultiThreadedServer(stopped 4998) a ZnManagingMultiThreadedServer(stopped 4997)) > > --- > > 3. register; start; stop: is ok. > > ZnManagingMultiThreadedServer allInstances do: #stop. > ZnServer managedServers do: #unregister. > Smalltalk garbageCollect. > > (ZnServer on: 4998) register; start; stop. > (ZnServer on: 4997) register; start; stop; stop. > > Transcript show: ZnServer managedServers; cr; > show: ZnManagingMultiThreadedServer allInstances; cr. > > ==> > > an IdentitySet() > an Array(a ZnManagingMultiThreadedServer(stopped 4998) a ZnManagingMultiThreadedServer(stopped 4997)) > > --- > > 4. start: is ok. > > ZnManagingMultiThreadedServer allInstances do: #stop. > ZnServer managedServers do: #unregister. > Smalltalk garbageCollect. > > (ZnServer on: 4998) start. > (ZnServer on: 4997) start; start. > > Transcript show: ZnServer managedServers; cr; > show: ZnManagingMultiThreadedServer allInstances; cr. > > ==> > > an IdentitySet() > an Array(a ZnManagingMultiThreadedServer(running 4998) a ZnManagingMultiThreadedServer(running 4997)) > > 5. register; start: is not ok. > > ZnManagingMultiThreadedServer allInstances do: #stop. > ZnServer managedServers do: #unregister. > Smalltalk garbageCollect. > > (ZnServer on: 4998) register; start. > (ZnServer on: 4997) register; start; start. > > Transcript show: ZnServer managedServers; cr; > show: ZnManagingMultiThreadedServer allInstances; cr. > > ==> > > an IdentitySet(a ZnManagingMultiThreadedServer(running 4998)) > an Array(a ZnManagingMultiThreadedServer(running 4998) a ZnManagingMultiThreadedServer(running 4997)) > > The last case is not idempotent for #start. With one #start, the server is registered, with two #start's, it is not registered. > > Shouldn't the last case be idempotent as well? > > If it is, it is the bug that should be put into issue tracker? > > Herby >

July 27, 2017

Re: [Pharo-users] is Renraku general purpose rule checker?

by Juraj Kubelka

Hi, At ESUG 2016, Yuriy showed that someone can use Renraku for any domain (object). So, it is not limited to AST/code based rules. In the recent effort of Benoit, he adds some rules to improve writing and executing test cases experience. This is related to AST/source code, but with more complex logic behind. Juraj > El 22-07-2017, a las 14:44, Peter Uhnak <i.uhnak(a)gmail.com> escribiÃ³: > > Hi, > > I'm looking at Renraku and I wonder, would Renraku be a good start for general-purpose checking? > > E.g. I have a domain, where Person cannot drink if they are underage. > > So I've created a simple ReAbstractRule subclass that does basic check > > SomeRule>>basicCheck: anEntity > ^ anEntity age < 18 > > and also custom Critique. > > So for everything seems that it works well, however I am not sure if there are some potential roadbloacks down the road, because e.g. Renraku is meant only for AST/code based rules. > > Thanks, > Peter >

July 27, 2017

Re: [Pharo-users] Documentation

by phil＠highoctane.be

pillar things: fork and PR Use https://github.com/cdlm/docker-texlive for generating artefacts like PDFs. Edit in any text editor. I am using Vim with pillar syntax. There is some Emacs available but I do not use Emacs. HTH Phil On Jul 26, 2017 22:58, "Jimmie Houchin" <jlhouchin(a)gmail.com> wrote: I am looking at participating in the documentation if that is a good area to plug in. I do not necessarily have the expertise on the subjects, but I can bring fresh eyes and the eyes of a native English speaker. What is the best way to assist? For example I am currently reading the Booklet-uFFI. I have some questions and suggestions. How or to whom do I communicate these? If I modify the UnifiedFFI.pillar file, do I do the normal GitHub pull requests? Or is this process handled via Iceberg? Do I edit them manually in a normal text editor or is there a preferred way within Pharo. Is this process documented somewhere? Or do I need to document it? :) And what about similar for the MOOC? Any guidance or suggestions, and suggestions where you would like help the most are greatly appreciated. Thanks. Jimmie

July 27, 2017

Re: [Pharo-users] NeoJSON "conditional" parsing/mapping

by Sven Van Caekenberghe

Esteban, I had a quick look at the spec you mentioned. I am a bit puzzled though. Result can be anything, so how are you going to map that to specific classes (and why) ? That would require serious prior knowledge and even then, not every situation can be mapped easily to a class. You speak about subclassing NeoJSONObject, which is cool, because it is so flexible, but then why type it further ? If I were you, I would at least start the easy/lazy way. For example you could do NeoJSONObject fromString: '...' And see how far you get. If things get slow, I would look for alternatives. Sven > On 26 Jul 2017, at 02:38, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > Hi Sven, all, > > I'm working on a JSON-RPC client, I started using LtJsonRpcClient, but > since it's based on the "legacy" JSON package I decided to try to > adapt it to use NeoJSON. So I created a NeoJSONRPCClient based on > LtJson... because... why not. > > At its core JSON-RPC is a pretty simple protocol, every response is a > JSON object with a 'result' attribute holding the returned object from > the RPC call, an 'error' one (nil if no error happened), and a few > other ones [1]. > > If I convert the response using the traditional `NeoJSONReader > fromString: responseObject` all the object three is converted to a > Dictionary, and what I want is to be able to: > > 1. Determine whether there was an error in the response > 2. If there was no error, convert the 'result' field to my preferred > class of object instead of a Dictionary. I plan to make my classes > inherit from NeoJSONObject though. > > All the above to avoid the use of an intermediate set of nested > dictionaries (which could be in the thousands). > I understand I could subclass NeoJSONReader to perform that at the > character stream level, but I wanted to ask first whether there is a > pattern/configuration of dealing with something like this. > > Best regards! > > [1] http://www.jsonrpc.org/specification#response_object > > Esteban A. Maringolo >

July 26, 2017

Documentation

by Jimmie Houchin

I am looking at participating in the documentation if that is a good area to plug in. I do not necessarily have the expertise on the subjects, but I can bring fresh eyes and the eyes of a native English speaker. What is the best way to assist? For example I am currently reading the Booklet-uFFI. I have some questions and suggestions. How or to whom do I communicate these? If I modify the UnifiedFFI.pillar file, do I do the normal GitHub pull requests? Or is this process handled via Iceberg? Do I edit them manually in a normal text editor or is there a preferred way within Pharo. Is this process documented somewhere? Or do I need to document it? :) And what about similar for the MOOC? Any guidance or suggestions, and suggestions where you would like help the most are greatly appreciated. Thanks. Jimmie

July 26, 2017

Re: [Pharo-users] Beyond Live Coding

by Jimmie Houchin

Thanks for the reply. Absolutely, I love what you say, "Pharo is yours". Which is why last month I joined the Association. I felt I needed to make the commitment. I had thought I wanted to do BountySource on a monthly basis. I signed up at the Association level but nothing happened with regarding to any membership. So I went ahead and did the Annual fee. But I do like the idea of monthly support. So I may do that again anyway. I would love to see the monthly support via BountySource or directly to the Association whichever is best for you to grow and help sustainability. I have also been thinking about ways to contribute of my time. I am looking at how I can help with documentation type areas. The team that contributes toward Pharo is amazing, especially considering the size. Again thanks. Jimmie On 07/22/2017 05:04 AM, Stephane Ducasse wrote: > Thanks Jimmie. Do not hesitate to improve Pharo, because Pharo is what > we have and each we can make it better. > BTW: it was not my roadmap it is the result of everybody in the team > brainstorming. [snip]

July 26, 2017