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

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

by Marcus Denker

> On 17 Aug 2018, at 14:20, Tim Mackinnon <tim(a)testit.works> wrote: > > The direct link to instructions is here: https://exercism.io/tracks/pharo/installation (not sure if you have to be signed up to see it otherwise its in the repo here: https://github.com/exercism/pharo/blob/master/docs/INSTALLATION.md) > Hmâ¦ AllExercismTests seems to not be there (just a green test in Welcome) Is this supposed to contain the code below (the createMissingClassActionFor:in:) ? It would be nice to have an image that shows exactly the problem (I do not have that much time sadly to work on it,but I do have some time to check if I have an image that is set up to the point where i can easily recreate the problem) Marcus > Tim > >> On 17 Aug 2018, at 07:17, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> >> >>> On 17 Aug 2018, at 13:00, Tim Mackinnon <tim(a)testit.works> wrote: >>> >>> >>> Hi Marcus - I can put an image somewhere if that helps (do you just need the .image and .changes)? >>> >>> Or you can repro from a fresh 6.1 if you follow the exercism Pharo instructions (https://exercism.io/tracks/pharo) to load the first hello world-world example and run the tests. This has my code changes to make create work with a nil class - but maybe we can do better? >>> >> I will do that and have a look! >> >>> Tim >>> >>> >>> Sent from my iPhone >>> >>> On 17 Aug 2018, at 06:21, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>>> >>>> >>>>> 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â¦) >>>>> >>>> >>>> >>>> what is a bit bad is that you catch the problem âtoo lateâ (that is, the DNU to nil, not the read of nil), so nil is already pushed on the stack at this point. >>>> >>>> I tried it in the inspector and at least the class binding was correct after defining the classâ¦ do you have an image with the whole code to try? >>>> >>>> Marcus >>>> >>>> >> >

Aug. 22, 2018

RDF

by Torsten Bergmann

I remember an old discussion on RDF and Pharo: http://forum.world.st/RDF-Framework-and-Pharo-td3526849.html Just as an info and for the records: Now Christian Haider released [RDF] - an RDF/XML implementation in VisualWorks Smalltalk https://wiki.pdftalk.de/doku.php?id=rdf License is MIT. Maybe someone is interested in a port to Pharo and/or Squeak/Cuis.

Aug. 21, 2018

Re: [Pharo-users] How best to cope with 2 editor/browser frameworks - Calypso and RubSmalltalkEditor

by Denis Kudriashov

Hi Tim. Currently commands are loaded after rubric. So RubSmalltalkEditor can't use them directly. 2018-08-21 13:03 GMT+01:00 Tim Mackinnon <tim(a)testit.works>: > AH - this makes sense then that SystemCommands is in its own Repo then > (although all these tiny repos get quite difficult the track so you can > understand where/how to contribute). > > This leads to another question - if I stick my commands for extend > selection and jump to keyword in SystemCommands - is the load order such > that RubSmalltalkEditor can safely access those commands (I know that for > Calypso its ok, but can I reference those commands in the older > RubSmalltalkEditor). Otherwise I will need to put the guts of my commands > in the RubSmalltalkCodeMode which is shared by al editors (but it feels a > bit too generic place for textMorph navigation stuff). > > Tim > > > > On 21 Aug 2018, at 05:48, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > > On 20 Aug 2018, at 00:39, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2018-08-19 23:12 GMT+01:00 Tim Mackinnon <tim(a)testit.works>: > >> Thanks Denis - I guess for now I can put the methods in >> RubSmalltalkEditor so that the playground can operate and then my Calypso >> plugins can also reference that code too (if class methods). >> >> Is the idea that playground will become part of Calypso too? >> > > No. > What we can try to achieve is to reused Commander everywhere. So these > SystemCommands will be reused by different tools. > > > Yes, this is what we are targeting, to have a centralised command library > that manages all system commands (so we do not need to duplicate code all > around). > With enough time to implement, all tools will use same command mechanism. > > Esteban > > > >> If so, I can add the methods I need as an extension (although I guess >> this wonât work as the keyboard mapping for playground in one method and >> not extensible like Calypso which uses pragmas). >> >> Iâll do something as a pr and we can figure it out. >> >> Itâs worth saying, that for my Calypso plugins Iâve had to abuse your >> mechanism a bit as the simple #execute mechanism doesnât give me access to >> the text morph to control the cursor. I was able to do it though via the >> prompting mechanism (I just donât show any ui prompt). >> >> Tim >> >> Sent from my iPhone >> >> On 19 Aug 2018, at 14:28, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> >> Hi. >> >> I dont't know answer to your question. But for the note: >> Calypso was needed to override existing way to spawn implementors/senders >> and so on. So I added subclass of RubSmalltalkEditor - ClyTextEditor which >> overrides required methods. >> So if you will put new methods into the RubSmalltalkEditor then Calypso >> will be able to use them. >> >> 2018-08-19 16:55 GMT+01:00 Tim Mackinnon <tim(a)testit.works>: >> >>> Hi Iâm trying to work out the best way to cope with the fact that we are >>> in a hybrid place where the Playground is using an RubSmalltalkEditor but >>> Calypso has its own mechanisms for editing code. >>> >>> I have commands that should/can work in both the playground as well as >>> code method editor (in Calypso). >>> >>> Previously my code lived in RubSmalltalkEditor and Nautilus was using >>> that too - but now Iâm not sure where to put some reusable methods that use >>> RBParser and the AST to find the best place to position your cursor. >>> >>> I can make a class method on RubSmalltalkEditor and Calypso commands >>> could reference that (but that feels wrong somehow). I could make some >>> extension methods on RBParser and both places reference that - but then who >>> should own the extension method (as I think RubSmalltalkEditor is lower >>> level and Calypso is then loaded on top). >>> >>> Anyone have some good suggestions? >>> >>> Tim >>> >> >> > > >

Aug. 21, 2018

Unable to install Roassal2 on pharo7 64bits

by Federico.Balaguer

Hello all, I need to install Roassal2 on Pharo7 64bits . I notice that there is a dialog warning about Roassal 2 not being tested on Pharo7 64bits. I wonder if someone was able to laod it I tried loading the stable configuration but it results making the image to close/quit. The image comes from the PharoLauncher's Pharo 7.0 development list. Is there a version of Pharo7 x64 that is known to work with Roassal2? Thanks! Federico -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Aug. 21, 2018

Submit your Project to the ESUG Awards

by N. Bouraqadi

Hi everyone! This is a reminder to submit your projects to the ESUG Innovation Technology Awards. It will be held on september the 10th as part of the ESUG conference in Sardinia (https://esug.github.io/2018-Conference/conf2018.html) Any Pharo Smalltalk-related project is eligible. All you need to do is provide me with few info and give a short demo during the awards session. I hope to hear from you soon, Noury

Aug. 21, 2018

Re: [Pharo-users] How best to cope with 2 editor/browser frameworks - Calypso and RubSmalltalkEditor

by Tim Mackinnon

AH - this makes sense then that SystemCommands is in its own Repo then (although all these tiny repos get quite difficult the track so you can understand where/how to contribute). This leads to another question - if I stick my commands for extend selection and jump to keyword in SystemCommands - is the load order such that RubSmalltalkEditor can safely access those commands (I know that for Calypso its ok, but can I reference those commands in the older RubSmalltalkEditor). Otherwise I will need to put the guts of my commands in the RubSmalltalkCodeMode which is shared by al editors (but it feels a bit too generic place for textMorph navigation stuff). Tim > On 21 Aug 2018, at 05:48, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > >> On 20 Aug 2018, at 00:39, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: >> >> >> 2018-08-19 23:12 GMT+01:00 Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>>: >> Thanks Denis - I guess for now I can put the methods in RubSmalltalkEditor so that the playground can operate and then my Calypso plugins can also reference that code too (if class methods). >> >> Is the idea that playground will become part of Calypso too? >> >> No. >> What we can try to achieve is to reused Commander everywhere. So these SystemCommands will be reused by different tools. > > Yes, this is what we are targeting, to have a centralised command library that manages all system commands (so we do not need to duplicate code all around). > With enough time to implement, all tools will use same command mechanism. > > Esteban > >> >> If so, I can add the methods I need as an extension (although I guess this wonât work as the keyboard mapping for playground in one method and not extensible like Calypso which uses pragmas). >> >> Iâll do something as a pr and we can figure it out. >> >> Itâs worth saying, that for my Calypso plugins Iâve had to abuse your mechanism a bit as the simple #execute mechanism doesnât give me access to the text morph to control the cursor. I was able to do it though via the prompting mechanism (I just donât show any ui prompt). >> >> Tim >> >> Sent from my iPhone >> >> On 19 Aug 2018, at 14:28, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: >> >>> Hi. >>> >>> I dont't know answer to your question. But for the note: >>> Calypso was needed to override existing way to spawn implementors/senders and so on. So I added subclass of RubSmalltalkEditor - ClyTextEditor which overrides required methods. >>> So if you will put new methods into the RubSmalltalkEditor then Calypso will be able to use them. >>> >>> 2018-08-19 16:55 GMT+01:00 Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>>: >>> Hi Iâm trying to work out the best way to cope with the fact that we are in a hybrid place where the Playground is using an RubSmalltalkEditor but Calypso has its own mechanisms for editing code. >>> >>> I have commands that should/can work in both the playground as well as code method editor (in Calypso). >>> >>> Previously my code lived in RubSmalltalkEditor and Nautilus was using that too - but now Iâm not sure where to put some reusable methods that use RBParser and the AST to find the best place to position your cursor. >>> >>> I can make a class method on RubSmalltalkEditor and Calypso commands could reference that (but that feels wrong somehow). I could make some extension methods on RBParser and both places reference that - but then who should own the extension method (as I think RubSmalltalkEditor is lower level and Calypso is then loaded on top). >>> >>> Anyone have some good suggestions? >>> >>> Tim >>> >> >

Aug. 21, 2018

Re: [Pharo-users] How best to cope with 2 editor/browser frameworks - Calypso and RubSmalltalkEditor

by Esteban Lorenzano

Hi, > On 20 Aug 2018, at 00:39, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2018-08-19 23:12 GMT+01:00 Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>>: > Thanks Denis - I guess for now I can put the methods in RubSmalltalkEditor so that the playground can operate and then my Calypso plugins can also reference that code too (if class methods). > > Is the idea that playground will become part of Calypso too? > > No. > What we can try to achieve is to reused Commander everywhere. So these SystemCommands will be reused by different tools. Yes, this is what we are targeting, to have a centralised command library that manages all system commands (so we do not need to duplicate code all around). With enough time to implement, all tools will use same command mechanism. Esteban > > If so, I can add the methods I need as an extension (although I guess this wonât work as the keyboard mapping for playground in one method and not extensible like Calypso which uses pragmas). > > Iâll do something as a pr and we can figure it out. > > Itâs worth saying, that for my Calypso plugins Iâve had to abuse your mechanism a bit as the simple #execute mechanism doesnât give me access to the text morph to control the cursor. I was able to do it though via the prompting mechanism (I just donât show any ui prompt). > > Tim > > Sent from my iPhone > > On 19 Aug 2018, at 14:28, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: > >> Hi. >> >> I dont't know answer to your question. But for the note: >> Calypso was needed to override existing way to spawn implementors/senders and so on. So I added subclass of RubSmalltalkEditor - ClyTextEditor which overrides required methods. >> So if you will put new methods into the RubSmalltalkEditor then Calypso will be able to use them. >> >> 2018-08-19 16:55 GMT+01:00 Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>>: >> Hi Iâm trying to work out the best way to cope with the fact that we are in a hybrid place where the Playground is using an RubSmalltalkEditor but Calypso has its own mechanisms for editing code. >> >> I have commands that should/can work in both the playground as well as code method editor (in Calypso). >> >> Previously my code lived in RubSmalltalkEditor and Nautilus was using that too - but now Iâm not sure where to put some reusable methods that use RBParser and the AST to find the best place to position your cursor. >> >> I can make a class method on RubSmalltalkEditor and Calypso commands could reference that (but that feels wrong somehow). I could make some extension methods on RBParser and both places reference that - but then who should own the extension method (as I think RubSmalltalkEditor is lower level and Calypso is then loaded on top). >> >> Anyone have some good suggestions? >> >> Tim >> >

Aug. 21, 2018

Re: [Pharo-users] don't understand why cascading doesn't work

by Richard Sargent

On Mon, Aug 20, 2018, 23:09 Gregg Williams <gregg13(a)innerpaths.net> wrote: > I'm embarrassed to write about this. I've been playing with the code, > reading docs, etc. for an hour: > > With a Transcript window open, executing any of the following lines (from > a Playground): > > Transcript show: 1; ' '; 2; cr. > > Transcript show: 'a'; cr; 'b'. > > Transcript show: 1; cr; '2'. > > fails, after which is shown a pink box with the text 'Message expected ->'. > > I'm sure it's something simple. What am I missing? Thanks. > Sven has answered. I would offer the clarification that "cascaded" refers to message sends. You send successive messages to the same receiver. Those messages may or may not take arguments. > > >

Aug. 21, 2018

Re: [Pharo-users] don't understand why cascading doesn't work

by Sven Van Caekenberghe

Gregg, > On 21 Aug 2018, at 08:08, Gregg Williams <gregg13(a)innerpaths.net> wrote: > > I'm embarrassed to write about this. I've been playing with the code, reading docs, etc. for an hour: > > With a Transcript window open, executing any of the following lines (from a Playground): > > Transcript show: 1; ' '; 2; cr. > > Transcript show: 'a'; cr; 'b'. > > Transcript show: 1; cr; '2'. > > fails, after which is shown a pink box with the text 'Message expected ->'. > > I'm sure it's something simple. What am I missing? Thanks. You have to repeat the selector, you cannot send a string or a number to an object. #cr is a message though. Transcript show: 1; show: ' '; show: 2; cr. Transcript show: 'a'; cr; show: 'b'. Transcript show: 1; cr; show: '2'. Furthermore, Transcript only generates output with #show: or #crShow: else it buffers until you send #endEntry or #flush. HTH, Sven

Aug. 21, 2018

don't understand why cascading doesn't work

by Gregg Williams

I'm embarrassed to write about this. I've been playing with the code, reading docs, etc. for an hour: With a Transcript window open, executing any of the following lines (from a Playground): Transcript show: 1; ' '; 2; cr. Transcript show: 'a'; cr; 'b'. Transcript show: 1; cr; '2'. fails, after which is shown a pink box with the text 'Message expected ->'. I'm sure it's something simple. What am I missing? Thanks.

Aug. 21, 2018