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

Re: [Pharo-users] Jupyter notebooks / Dynabook / JupyterTalk

by JesÃºs MarÃ

I found it...you just have to add the subdirectory to the repository path Metacello new baseline: 'JupyterTalk'; repository: 'github://jmari/JupyterTalk/repository/'; load:#all -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Aug. 13, 2018

Re: [Pharo-users] Jupyter notebooks / Dynabook / JupyterTalk

by JesÃºs MarÃ

Hi Hannes, I did not find a nice way to solve the problem but you will be able to load jupytertalk following these simple steps: - Try to load it executing Metacello new baseline: 'JupyterTalk'; repository: 'github://jmari/JupyterTalk'; load:'all' - It will fail...open Iceberg, there must be a new repository "JupyterTalk" in. - Edit the repository (cmd+E) and add "repository" to the code subdirectory field. - Try to execute this again, Metacello new baseline: 'JupyterTalk'; repository: 'github://jmari/JupyterTalk'; load:'all' ------ Befor installing Jupytertalk, you need ZeroMQ and Jupyter installed in your system and you must create a the folder '/usr/local/share/jupyter/kernels/pharo'. and a file 'kernel.json' with the contents like that... '{ "argv": [ "/Applications/Pharo6.1-64_ZeroMQ.app/Contents/MacOS/Pharo", "/Applications/Pharo6.1-64_ZeroMQ.app/Contents/Resources/Pharo6.1-64.image", "ipharo", "{connection_file}" ], "display_name": "Pharo Smalltalk", "language": "smalltalk" }' feel free to ask more questions, I'll be glad to help! -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Aug. 13, 2018

Re: [Pharo-users] Deprecation rewrite introduces infinite recursionâ¦ how to prevent that?

by Damien Pollet

Turns out it was pretty easy to implement: https://github.com/pharo-project/pharo/pull/1683 On Sat, 11 Aug 2018 at 15:59, Damien Pollet <damien.pollet(a)gmail.com> wrote: > I have a double-dispatch chain: > x generic: y â y firstDispatch: x â x secondDispatchFromY: y > > However this has been added after the fact, so there are direct uses of > the secondDispatchFromY: layer, which I'd like to deprecate/rewrite to use > the generic: one. But if I do so, the intermediate firstDispatch: gets > rewritten in the process, and this results in an infinite recursion. > > Is there a way to formulate the rewrite rule to avoid that? > > I could make a whole new set of secondDispatchFromYbis: methods, change > the firstDispatch: ones to use those, and then the rewrite would be ok, but > it seems like a lot of noise in the code for a small deprecationâ¦ > > Thinking of it, this is not really a deprecation, more like an advice on > proper useâ¦ > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Aug. 13, 2018

Re: [Pharo-users] mustache bug?

by Norbert Hartl

Hmmm. To easy for me to figure out :) https://github.com/noha/mustache/issues/2 <https://github.com/noha/mustache/issues/2> Norbert > Am 13.08.2018 um 14:06 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > > >> On 13 Aug 2018, at 13:59, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> Where did you read this about the parent context? Maybe Iâm blind to see it. That would explain why I didnât see it when implementing it :) > > Search for parent in http://mustache.github.io/mustache.5.html > > Variables > The most basic tag type is the variable. A {{name}} tag in a basic template will try to find the name key in the current context. If there is no name key, the parent contexts will be checked recursively. If the top context is reached and the name key is still not found, nothing will be rendered. > >> Norbert >> >>> Am 13.08.2018 um 10:24 schrieb Peter UhnÃ¡k <i.uhnak(a)gmail.com>: >>> >>> Hi, >>> >>> I'm using Mustache for Pharo, and according to mustache docs ( https://mustache.github.io/mustache.5.html ), when a key is not found, it should look into parents contexts. >>> >>> However that does not seem to be the case: >>> >>> str := '{{root}} >>> {{#items}} >>> {{root}}.{{name}} >>> {{/items}}'. >>> >>> data := { >>> 'root' -> 'ROOT'. >>> 'items' -> { >>> { 'name' -> 'first' } asDictionary. >>> { 'name' -> 'second' } asDictionary. >>> } >>> } asDictionary. >>> >>> (MustacheTemplate on: str) value: data. >>> >>> I should get "ROOT.first", etc., but instead I get ".first", ".second". >>> >>> Thanks, >>> Peter >>> >> > >

Aug. 13, 2018

Re: [Pharo-users] mustache bug?

by Sven Van Caekenberghe

> On 13 Aug 2018, at 13:59, Norbert Hartl <norbert(a)hartl.name> wrote: > > Where did you read this about the parent context? Maybe Iâm blind to see it. That would explain why I didnât see it when implementing it :) Search for parent in http://mustache.github.io/mustache.5.html Variables The most basic tag type is the variable. A {{name}} tag in a basic template will try to find the name key in the current context. If there is no name key, the parent contexts will be checked recursively. If the top context is reached and the name key is still not found, nothing will be rendered. > Norbert > >> Am 13.08.2018 um 10:24 schrieb Peter UhnÃ¡k <i.uhnak(a)gmail.com>: >> >> Hi, >> >> I'm using Mustache for Pharo, and according to mustache docs ( https://mustache.github.io/mustache.5.html ), when a key is not found, it should look into parents contexts. >> >> However that does not seem to be the case: >> >> str := '{{root}} >> {{#items}} >> {{root}}.{{name}} >> {{/items}}'. >> >> data := { >> 'root' -> 'ROOT'. >> 'items' -> { >> { 'name' -> 'first' } asDictionary. >> { 'name' -> 'second' } asDictionary. >> } >> } asDictionary. >> >> (MustacheTemplate on: str) value: data. >> >> I should get "ROOT.first", etc., but instead I get ".first", ".second". >> >> Thanks, >> Peter >> >

Aug. 13, 2018

Re: [Pharo-users] mustache bug?

by Norbert Hartl

Where did you read this about the parent context? Maybe Iâm blind to see it. That would explain why I didnât see it when implementing it :) Norbert > Am 13.08.2018 um 10:24 schrieb Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > > Hi, > > I'm using Mustache for Pharo, and according to mustache docs ( https://mustache.github.io/mustache.5.html <https://mustache.github.io/mustache.5.html> ), when a key is not found, it should look into parents contexts. > > However that does not seem to be the case: > > str := '{{root}} > {{#items}} > {{root}}.{{name}} > {{/items}}'. > > data := { > 'root' -> 'ROOT'. > 'items' -> { > { 'name' -> 'first' } asDictionary. > { 'name' -> 'second' } asDictionary. > } > } asDictionary. > > (MustacheTemplate on: str) value: data. > > I should get "ROOT.first", etc., but instead I get ".first", ".second". > > Thanks, > Peter >

Aug. 13, 2018

mustache bug?

by Peter UhnÃ¡k

Hi, I'm using Mustache for Pharo, and according to mustache docs ( https://mustache.github.io/mustache.5.html ), when a key is not found, it should look into parents contexts. However that does not seem to be the case: str := '{{root}} {{#items}} {{root}}.{{name}} {{/items}}'. data := { 'root' -> 'ROOT'. 'items' -> { { 'name' -> 'first' } asDictionary. { 'name' -> 'second' } asDictionary. } } asDictionary. (MustacheTemplate on: str) value: data. I should get "ROOT.first", etc., but instead I get ".first", ".second". Thanks, Peter

Aug. 13, 2018

Re: [Pharo-users] Is there a project Label for packages

by Peter UhnÃ¡k

BaselineOf/ConfigurationOf is the only place that contains this information, e.g. (BaselineOfCalypso project version packages collect: #name) asSet Peter On Sat, Aug 11, 2018 at 7:41 PM, Eric Gade <eric.gade(a)gmail.com> wrote: > Unless I'm mistaken, the `BaselineOfXXX` is, in part, a description of all > the packages used by a given project. > > On Sat, Aug 11, 2018 at 1:18 PM, Alidra Abdelghani via Pharo-users < > pharo-users(a)lists.pharo.org> wrote: > >> >> >> ---------- Forwarded message ---------- >> From: Alidra Abdelghani <alidrandco(a)yahoo.fr> >> To: pharo-users(a)lists.pharo.org >> Cc: >> Bcc: >> Date: Sat, 11 Aug 2018 18:18:17 +0100 >> Subject: Is there a project Label for packages >> Hi, >> >> I would like to filter Packages according to the project they have been >> developed in (For instance, the Roassal packages, the Seaside packages, the >> Moose packages,â¦) >> >> >> So I am wondering if there is any way to question a package about the >> project(s) it belong to? >> If not in Pharo, maybe there such a thing in Famix? >> If not, is there a way to reach this information (a repo, a web site, â¦.) >> NB. >> I could use the prefix of the name of the package, but this does not seem >> to be always accurate (for the Pharo project for instance) >> >> Thanks a lot in advance >> Abdelghani >> >> >> >> > > > -- > Eric >

Aug. 12, 2018

Re: [Pharo-users] [ANN] Magritte moved to github

by Sean P. DeNigris

Ben Coman wrote > An interesting challenge. I've had a go at it and got it as far as I can > without knowing Magritte. Thanks for the push! Not knowing all that much about git, I tried a different way and seem to have successfully rebuilt the master branch of my fork (https://github.com/seandenigris/Magritte3) on top of the master from the upstream, based on the last shared (content) commit (upstream 51f648b vs fork 47df0a5, both titled "[FIX]: Respect action shortcutsâ¦") In case it helps anyone in the future, here is what I did: 1. Create new branch from upstream master and revert to 51f648b 2. Create git log of commits from fork's first divergent commit (bff9c25 "Dynamic Optionsâ¦") to HEAD, via git log `47df0a5..eedd386 --pretty=fuller > ../export.txt` 3. For each commit in log: a. `git mv source repository` - temporarily rename "source" (code subfolder from upstream) to "repository" (subfolder from fork) to ease merging b. `git cherry-pick -n $sha1` (where sha1 = e.g. bff9c25) - replay changes without committing c. `git rm -f */methodProperties.json` and then `git rm -f */version` - remove metadata, since upstream commits are metadata-less d. `git reset HEAD` - reset git so it forgets about steps a and c, which are just to conform the fork commits to upstream, but leaves the actual changes in place e. `mv repository/ source` f. `git add -A` - inform git about all changes now that everything is how we want it g. `git commit --date="Sun Mar 25 22:57:40 2018 -0400" -m "Fix #17â¦" --author="Sean DeNigris <github(a)clipperadams.com>"`- commit preserving original author and author date The above process was eased by a single Pharo helper class, `GitCommit`, which parsed the log from #2 above into domain objects and created and executed the commands in #3. I used quick and dirty `LibC system:â¦` messages instead of libgit since I'm a novice and the whole task was a hack. Now my fork's master is branched off upstream master, so hopefully that eases integration of my enhancements. I'm not exactly sure how to proceed from here, so suggestions welcomeâ¦ ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Aug. 12, 2018

Re: [Pharo-users] Making TDD in pharo work properly (aka - walkback on a missing class is nasty)

by Tim Mackinnon

I guess for a bit of historical record - I fixed the Pharo 6.1 image in exercism to properly handle the creation of a missing class. Not a lot of code (but you do need the right code - and it is slightly confusing how the debugger window is so tightly tied to the model which also has the stack and context - and thus getting rid of the window gets rid of the context - which in retrospect makes sense as closing the debugger should terminate everything). Iâll kick it around a bit with Exercism - and if it seems good Iâll make a PR for Pharo 7 as Think its worth having? It does raise an interesting point however - when you hit a missing class, the debugger says â#message was sent to nilâ - I would think we can do better than that given what Marcus discussed further below. If we were to save an UndefinedClass in the compiled method - then the error could be much better (not nil - but UndefinedClass, or UndefinedGlobal) - and equally the corrective action could be much better too. I think this is what Marcus was getting at - and I think it would be a much better thing for us to do. Having used one of his suggestions below (and tried it when coding some exercises) - I also think we should stop the disruptive prompting for missing classes or variables when you save and just show them as gutter warnings or squiggles in the editor. You could add some other key to walk you through fixes if you want to deal with them right at that moment. Anyway - this really shows how flexible our environment is (and the work we can keep doing). Tim > On 10 Aug 2018, at 23:16, Tim Mackinnon <tim(a)testit.works> wrote: > > Actually I think I figured that bit out - a bit clumsily - (pointers appreciated) > > createMissingClassActionFor: aMessage in: aContext > |errorNode senderContext newClass variableNode | > senderContext := aContext sender. > errorNode := senderContext method sourceNodeExecutedForPC: senderContext pc. > variableNode := errorNode receiver receiver. > > newClass := OCUndeclaredVariableWarning new node: variableNode; defineClass: variableNode name. > aContext restart. > > However that last line is wrong, as it doesnât restart with my newly defined class - I also tried > > aContext restartWithNewReceiver: newClass > > But again, I get a debugger where my class is still bound to nil. So whatâs the trick to re-evaluate with the new class Iâve created? Or maybe Iâm totally on the wrong track (still its very interestingâ¦) > > Tim > >> On 10 Aug 2018, at 16:30, Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: >> >> Hey Marcus (or those knowledgable about stacks and contexts) - to self #1 - where the create button generates a class instead of a method, Iâm a bit out of my depth. >> >> I can see there is a DoesNotUnderstandDebugAction (which the create button calls). >> >> So to determine if the failure was due to a missing class or method - would this work? >> >> msg := self interruptedContext tempAt: 1. >> (msg lookupClass == UndefinedObject ) ifTrue: [ â¦ create a class >> >> E.g. if youâre trying to send a msg to nil (which is what got patched into the compiled method for a missing class) then you are dealing with a missing class? >> >> >> AND then for create a class - how do I extract the name? >> >> I can get the compiled method for msg - but how do I marry that up with what you were executing? Am I write in thinking that the AST nodes and there locations might line up with the stack pointer somehow (or something like that)â¦ if I can get that - then I get the name of the missing class and can then create it and then rerun the method right? >> >> This is very neat stuff I âve never played with before. >> >> Tim >> >> >> >> >> >>> On 9 Aug 2018, at 11:02, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >>> >>> >>> >>>> On 9 Aug 2018, at 10:59, Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: >>>> >>>> Hi Marcus, >>>> >>>> Is it wise to backport things that may break things like this? >>> maybe not, but it just took 5 minutes as it is very simple >>> >>>> I'd prefer to put the energy on backporting the workaround to avoid the infinite debuggers... >>>> >>> >>> Yes. >>> >>>> On Thu, Aug 9, 2018 at 10:50 AM Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >>>>> >>>>>> 2) when coding - if you want reference a missing class, why donât we let you? TonelReader seems to do it, why canât the editor? (This probably applies to variables as well - show them broken, let me fix it when I choose. The iVar case is a little rarer - although I hate the way we prompt fix, prompt fix instead of doing it in one go - itâs very old fashioned) >>>>>> >>>>> >>>>> This is fixed in Pharo7: we added a menu entry âleave undeclaredâ as the first option: >>>>> <leave undeclared.png> >>>>>> Does anyone have tips on solving these? It spoils the exercism experience that I thought we could convey, so Iâd like to at least fix #1 in 6.1 if I can. >>>>>> >>>>> >>>>> I will back port the fix for 2) to Pharo6 and will do a quick prototype for 1) >>>>> >>>> >>>> https://pharo.fogbugz.com/f/cases/22305/Backport-to-Pharo6-Leave-Variable-U… <https://pharo.fogbugz.com/f/cases/22305/Backport-to-Pharo6-Leave-Variable-U…> >>>> >>>> Marcus >>>> >>>> >>>> >>>> -- >>>> >>>> Guille Polito >>>> Research Engineer >>>> >>>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>>> CRIStAL - UMR 9189 >>>> French National Center for Scientific Research - http://www.cnrs.fr <http://www.cnrs.fr/> >>>> >>>> Web: http://guillep.github.io <http://guillep.github.io/> >>>> Phone: +33 06 52 70 66 13 >>> >> >

Aug. 11, 2018