- Pharo-users - lists.pharo.org

Re: [Pharo-users] Proof of Concept: FileTree and Fossil

by Pierce Ng

On Tue, Feb 28, 2017 at 10:09:06AM -0500, Offray Vladimir Luna CÃ¡rdenas wrote: > BTW, when installing Grafoscopio you get a FossilRepo object that is > used to query Fossil repositories via the JSON API and update > documentation. Still in early stages, but I will experiment how > Pierce's Fossil support give a more cohesive user experience when > working with publication and collaboration of interactive notebooks. Currently FossilFileTree runs Fossil "at the command line". But certainly talking JSON with a Fossil server is another avenue to explore, similar to having gitfiletree:// and remote git repository. Pierce

March 1, 2017

Re: [Pharo-users] Proof of Concept: FileTree and Fossil

by Pierce Ng

On Tue, Feb 28, 2017 at 04:23:12PM +0100, Thierry Goubier wrote: > 2017-02-28 1:19 GMT+01:00 Pierce Ng <pierce(a)samadhiweb.com>: > > I have written a simple integration of FileTree with Fossil to avoid the > Congratulations! This was one of my objectives with GitFileTree: open up > the Pharo infrastructure to other DVCS such as Fossil. And indeed runOSSubprocessFossilCommand is basically runOSSubprocessGitCommand, so thank you for GitFileTree. I've only implemented #basicStoreVersion: and it is simply this: basicStoreVersion: aVersion super basicStoreVersion: aVersion (MCFossil new repoDir: self directory fullName) addRemove; commit: aVersion info message The last 3 lines is of course just the Smalltalk way of saying "fossil addremove; fossil commit ..." Currently that's all it does. > How does Fossil handles merging the FileTree format? Just to be sure I get your question, do you mean whether FossilFileTree sees the changes if I edit the .st files using vi, say? Right now, after committing in Monticello Browser, when I click 'refresh' or 'changes' everything shows up as new again. That can't be right. Which part of GitFileTree deals that? Pierce

March 1, 2017

Re: [Pharo-users] Crash in Athens

by Esteban Lorenzano

> On 1 Mar 2017, at 04:42, Alexander Samoylovich <samoylovich(a)gmail.com> wrote: > > Thanks everybody for the explanation. > > I tried to apply Igor's suggestion. I allocate an offscreen surface 1 row larger than needed > and when converting discard one row. > > The code looks more stable now. The test was up for about 30 minutes before crashing instead of 1 minute before the fix. > Is it the right code change or just a coincidence? > > > AthensCairoSurface>>asForm > > "create a form and copy an image data there" > self checkSession. > > self flush. > ^ Form extent: (self width@self height) - (0@1) depth: 32 bits: id can you add that *in addition* to Ronieâs suggestion? (the one I posted?) Esteban > > > On Mon, Feb 27, 2017 at 2:39 PM, Stephane Ducasse <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com>> wrote: > Tx igor I added > > https://pharo.fogbugz.com/f/cases/19764/Improve-comment-of-AthensCairoSurfa… <https://pharo.fogbugz.com/f/cases/19764/Improve-comment-of-AthensCairoSurfa…> > > On Mon, Feb 27, 2017 at 7:35 PM, Igor Stasenko <siguctua(a)gmail.com <mailto:siguctua@gmail.com>> wrote: > and i was dealing with it by adding 1 extra line to cairo surface, > but reporting 1 less to Form. Like so, bitblt still reads past the > allowed size, but it is safe, because there are unused bit(s). > > On 27 February 2017 at 20:31, Igor Stasenko <siguctua(a)gmail.com <mailto:siguctua@gmail.com>> wrote: > > > On 27 February 2017 at 12:29, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > Hi, > > the problem wit Ronieâs fix is that (as he says) you are copying another time the surface, before passing it to the VM (who makes yet-another-copy) so this is not optimalâ¦ and you can see it when running the Tiger demo: there are a lot of pauses. > So I would prefer the other approach he suggests: > > Form subclass: #AthensCairoSurfaceForm > instanceVariableNames: 'surface' > classVariableNames: '' > package: 'Athens-Cairo' > > AthensCairoSurfaceForm>>surface > ^ surface > > AthensCairoSurfaceForm>>surface: anObject > surface := anObject > > AthensCairoSurface>>asForm > "create a form and copy an image data there" > self checkSession. > self flush. > ^ (AthensCairoSurfaceForm extent: (self width@self height) depth: 32 bits: id) > surface: self; > yourself > > that seems to work. Can you try and see? > > > Btw, remember the culprit there , that you must have extra word in trailing buffer space, > this is because bit-blt using read-ahead . Which is OK for objects located in object memory, > since there are always something past the last object (unallocated space), > but not so ok for buffers allocated by malloc (such as cairo surface bitmap), and so, > if you read even a single byte past it, you get protection fault. > > Esteban > > > On 24 Feb 2017, at 15:47, stepharong <stepharong(a)free.fr <mailto:stepharong@free.fr>> wrote: > > > > Hi alex > > > > can you try the fix of ronie and let us know if it makes roassal more stable? > > > > Stef > > > >> Dear Alexander, > >> > >> Sine the new FFI of Pharo, using Athens has become unreliable. This is a pity, but fixing this is not trivial at all (we have been trying for years). > >> > >> What exactly are you doing with Athens? > >> > >> Alexandre > >> > >> > >>> On Feb 22, 2017, at 12:55 AM, Alexander Samoylovich <samoylovich(a)gmail.com <mailto:samoylovich@gmail.com>> wrote: > >>> > >>> Hello > >>> > >>> I am writing graphic demo programs using Athens on Mac Sierra. > >>> Time by time Pharo VM crashes. Programs not using Athens work reliably. > >>> I believe the behavior is reproducible. > >>> How should I report a bug? > >>> > >>> Alex > >> > > > > > > -- > > Using Opera's mail client: http://www.opera.com/mail/ <http://www.opera.com/mail/> > > > > > > > > -- > Best regards, > Igor Stasenko. > > > > -- > Best regards, > Igor Stasenko. > >

March 1, 2017

Re: [Pharo-users] How to capture the execution of a playground?

by phil＠highoctane.be

You can see what's going on with this: p := GTPlayground open. pmodel := p model. logger := GLMMemoryLogger new. pmodel logger: logger. pmodel Then open the annoucements pane to see what is going on. Be ready to use the interrupt combo as I have experienced strange effects :-) If you have a handle on the model, you can see a lot. Somewhere one can find the bindings, which can then be persisted to disk, STON comes to mind. HTH Phil On Wed, Mar 1, 2017 at 5:45 AM, Ben Coman <btc(a)openinworld.com> wrote: > > > On Wed, Mar 1, 2017 at 10:06 AM, Offray Vladimir Luna CÃ¡rdenas < > offray.luna(a)mutabit.com> wrote: > >> >> On 28/02/17 02:12, Ben Coman wrote: >> >> >> >> On Tue, Feb 28, 2017 at 11:28 AM, Offray Vladimir Luna CÃ¡rdenas < >> offray.luna(a)mutabit.com> wrote: >> >>> Hi, >>> >>> I would like to store the object resulting from executing a playground. >>> This would imply two steps: >>> >>> - Knowing that the playground content was executed (via the play button >>> or its shortcuts Ctrl + Shift + g or Ctrl + g). >>> - Getting the results of that execution. For example if the result at >>> the end is a string or a dictionary, I would like to get that string or >>> dictionary. >>> >>> Any pointers on how to make that will be welcomed. >>> >>> Cheers, >>> >>> Offray >>> >>> Ps: I still get lost when I search by myself trying to answer questions >>> like the ones above. I imagine that in some way is related with >>> evaluationAction and presentations, by looking for the source code of "do >>> it and go", but still I can't get a functional code snippet to start >>> prototyping. >>> >>> >> In playground, if you evaluate "self halt. 42" at top of the debug stack >> you'll see method... >> Undefined>>DoIt >> self halt. >> ^ 42 >> >> where stepping >> OVER returns 42 into "value" variable in OpalCompiler>>evaluate >> OVER returns 42 into "result" variable in RubSmalltalkEditor>>evaluate:a >> ndDo: >> at the end of which stepping >> INTO "^aBlock value: result" takes you to RubSmalltalkEditor>>highlightEvaluateAndDo:, >> where >> INTO "[:result | aBlock value: result]" takes you to >> GLMPharoScriptPResentation(GLMRubricSmalltalkCodePresentatio >> n)>>executionSelectionActions >> >> >> Wow that was pretty insightful! Thanks Ben. I still don't know when to >> use Over or Into, >> > It helps to observe the three types of stepping behavior side by side. > I've devised a little demo. > > First, to help keep track of the windows, hack this mod into > RubSmalltalkEditor>>debug:receiver:in: > debugSession := guineaPig newDebugSessionNamed: ('debug ' , > aCompiledMethod selector printString asUppercase) startedAt: context. > > In playground evaluate... > Object subclass: #DebugDemo > instanceVariableNames: '' > classVariableNames: '' > package: 'DebugDemo'. > > In playground evaluate... > #('over' 'through' 'into') do: [ :demoMethodName| > DebugDemo compile: demoMethodName , ' > x := 0. > #(1 2) do: [:n | x := x + 1]. > self inform: x printString.'. > RubSmalltalkEditor new debug: (DebugDemo>>(demoMethodName > asSymbol)) receiver: nil in: nil. > ]. > > Arrange the three debug windows side by side, left to right, OVER, > THROUGH, INTO. > > > 1. Moving left to right, click once on each window's related "step" button > - OVER then THROUGH then INTO. > While views remain the same, repeat 1. > > 2. When views diverge, keep clicking INTO until it matches THROUGH. > > 3. While THROUGH and INTO views remain the same, keep alternately clicking > these. > When they diverge return to 2. > When all views are the same, return to 1. > > The key thing to observe with the INTO window, is that sending #value: to > the array gets you to the same place as THROUGH got in one step. It skips > through the block support infrastructure. > > i think maybe it would help to rearrange the "step" buttons in order of > increasing detail. i.e. OVER, THROUGH, INTO. > Also maybe the "through" icon could be a right arrow inside square > brackets like this... [-->]. > That would probably look neater without the underline. > > > To put the terminology into perspective, I've contrived a poor analogy > of... > A method being a path along the ground. > http://www.instructables.com/id/How-to-lay-pathpatiowalkway-and-build- > slabs/ > Each slab is a message send. Under each slab is an offshoot tunnel with > further slabs along it. > > The quickest way down the path is to step OVER each slab(message send) > because you don't care what is happening beneath the slab. > > Sometimes you need to know everything that is going on underneath, so you > lift up the slab and go INTO the tunnel and step on each of the slabs in > the tunnel. > > Now to stretch the analogy, consider that a block is held at the end #do: > tunnel. You are interested in the individual steps of the block, but not > in all the steps of the tunnel (which is the support infrastructure that > iterates a collection sending #value: to each element), so you fly THROUGH > the tunnel without touching the individual steps, and just step the slabs > of the block held at the end. Phew! > > So in summary, > INTO steps into every message send. > OVER and THROUGH are similar, but the first steps over blocks, and the > latter steps through blocks. > > HTH, > cheers -ben > > > > >

March 1, 2017

Re: [Pharo-users] How to capture the execution of a playground?

by Ben Coman

On Wed, Mar 1, 2017 at 10:06 AM, Offray Vladimir Luna CÃ¡rdenas < offray.luna(a)mutabit.com> wrote: > > On 28/02/17 02:12, Ben Coman wrote: > > > > On Tue, Feb 28, 2017 at 11:28 AM, Offray Vladimir Luna CÃ¡rdenas < > offray.luna(a)mutabit.com> wrote: > >> Hi, >> >> I would like to store the object resulting from executing a playground. >> This would imply two steps: >> >> - Knowing that the playground content was executed (via the play button >> or its shortcuts Ctrl + Shift + g or Ctrl + g). >> - Getting the results of that execution. For example if the result at the >> end is a string or a dictionary, I would like to get that string or >> dictionary. >> >> Any pointers on how to make that will be welcomed. >> >> Cheers, >> >> Offray >> >> Ps: I still get lost when I search by myself trying to answer questions >> like the ones above. I imagine that in some way is related with >> evaluationAction and presentations, by looking for the source code of "do >> it and go", but still I can't get a functional code snippet to start >> prototyping. >> >> > In playground, if you evaluate "self halt. 42" at top of the debug stack > you'll see method... > Undefined>>DoIt > self halt. > ^ 42 > > where stepping > OVER returns 42 into "value" variable in OpalCompiler>>evaluate > OVER returns 42 into "result" variable in RubSmalltalkEditor>>evaluate: > andDo: > at the end of which stepping > INTO "^aBlock value: result" takes you to RubSmalltalkEditor>>highlightEvaluateAndDo:, > where > INTO "[:result | aBlock value: result]" takes you to > GLMPharoScriptPResentation(GLMRubricSmalltalkCodePresentation)>> > executionSelectionActions > > > Wow that was pretty insightful! Thanks Ben. I still don't know when to use > Over or Into, > It helps to observe the three types of stepping behavior side by side. I've devised a little demo. First, to help keep track of the windows, hack this mod into RubSmalltalkEditor>>debug:receiver:in: debugSession := guineaPig newDebugSessionNamed: ('debug ' , aCompiledMethod selector printString asUppercase) startedAt: context. In playground evaluate... Object subclass: #DebugDemo instanceVariableNames: '' classVariableNames: '' package: 'DebugDemo'. In playground evaluate... #('over' 'through' 'into') do: [ :demoMethodName| DebugDemo compile: demoMethodName , ' x := 0. #(1 2) do: [:n | x := x + 1]. self inform: x printString.'. RubSmalltalkEditor new debug: (DebugDemo>>(demoMethodName asSymbol)) receiver: nil in: nil. ]. Arrange the three debug windows side by side, left to right, OVER, THROUGH, INTO. 1. Moving left to right, click once on each window's related "step" button - OVER then THROUGH then INTO. While views remain the same, repeat 1. 2. When views diverge, keep clicking INTO until it matches THROUGH. 3. While THROUGH and INTO views remain the same, keep alternately clicking these. When they diverge return to 2. When all views are the same, return to 1. The key thing to observe with the INTO window, is that sending #value: to the array gets you to the same place as THROUGH got in one step. It skips through the block support infrastructure. i think maybe it would help to rearrange the "step" buttons in order of increasing detail. i.e. OVER, THROUGH, INTO. Also maybe the "through" icon could be a right arrow inside square brackets like this... [-->]. That would probably look neater without the underline. To put the terminology into perspective, I've contrived a poor analogy of... A method being a path along the ground. http://www.instructables.com/id/How-to-lay-pathpatiowalkway-and-build-slabs/ Each slab is a message send. Under each slab is an offshoot tunnel with further slabs along it. The quickest way down the path is to step OVER each slab(message send) because you don't care what is happening beneath the slab. Sometimes you need to know everything that is going on underneath, so you lift up the slab and go INTO the tunnel and step on each of the slabs in the tunnel. Now to stretch the analogy, consider that a block is held at the end #do: tunnel. You are interested in the individual steps of the block, but not in all the steps of the tunnel (which is the support infrastructure that iterates a collection sending #value: to each element), so you fly THROUGH the tunnel without touching the individual steps, and just step the slabs of the block held at the end. Phew! So in summary, INTO steps into every message send. OVER and THROUGH are similar, but the first steps over blocks, and the latter steps through blocks. HTH, cheers -ben

March 1, 2017

Re: [Pharo-users] Socket, network, testing and coding

by Evan Donahue

Hi, Depending on what exactly you are doing, you could either use or look at the source of: http://smalltalkhub.com/#!/~EvanDonahue/P2P It is basically a simple API for setting up image-to-image networked communication. You make a server object, set it running, and then open a connection from a client image. The threading etc is all handled. A simple chat system only takes a couple lines, and there is a well commented example of a simple multi (3+) person chat server in the examples package. Yes, one image does need to be the "server," but it only matters for setting up the initial connection. After that, they are essentially peer to peer, and either party can send to the other. I would imagine that this still fits your requirements, unless you have a very special use case like UDP hole punching, which I ultimately plan to implement one day when I return to this project. But the current form is very stable and complete. Let me know if you have any questions. Cheers, Evan -- View this message in context: http://forum.world.st/Proof-of-Concept-FileTree-and-Fossil-tp4936260p493649… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

March 1, 2017

Re: [Pharo-users] Crash in Athens

by Alexander Samoylovich

Thanks everybody for the explanation. I tried to apply Igor's suggestion. I allocate an offscreen surface 1 row larger than needed and when converting discard one row. The code looks more stable now. The test was up for about 30 minutes before crashing instead of 1 minute before the fix. Is it the right code change or just a coincidence? AthensCairoSurface>>asForm "create a form and copy an image data there" self checkSession. self flush. ^ Form extent: (self width@self height) - (0@1) depth: 32 bits: id On Mon, Feb 27, 2017 at 2:39 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Tx igor I added > > https://pharo.fogbugz.com/f/cases/19764/Improve-comment- > of-AthensCairoSurfaceForm > > On Mon, Feb 27, 2017 at 7:35 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> and i was dealing with it by adding 1 extra line to cairo surface, >> but reporting 1 less to Form. Like so, bitblt still reads past the >> allowed size, but it is safe, because there are unused bit(s). >> >> On 27 February 2017 at 20:31, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> >>> >>> On 27 February 2017 at 12:29, Esteban Lorenzano <estebanlm(a)gmail.com> >>> wrote: >>> >>>> Hi, >>>> >>>> the problem wit Ronieâs fix is that (as he says) you are copying >>>> another time the surface, before passing it to the VM (who makes >>>> yet-another-copy) so this is not optimalâ¦ and you can see it when running >>>> the Tiger demo: there are a lot of pauses. >>>> So I would prefer the other approach he suggests: >>>> >>>> Form subclass: #AthensCairoSurfaceForm >>>> instanceVariableNames: 'surface' >>>> classVariableNames: '' >>>> package: 'Athens-Cairo' >>>> >>>> AthensCairoSurfaceForm>>surface >>>> ^ surface >>>> >>>> AthensCairoSurfaceForm>>surface: anObject >>>> surface := anObject >>>> >>>> AthensCairoSurface>>asForm >>>> "create a form and copy an image data there" >>>> self checkSession. >>>> self flush. >>>> ^ (AthensCairoSurfaceForm extent: (self width@self height) >>>> depth: 32 bits: id) >>>> surface: self; >>>> yourself >>>> >>>> that seems to work. Can you try and see? >>>> >>>> >>> Btw, remember the culprit there , that you must have extra word in >>> trailing buffer space, >>> this is because bit-blt using read-ahead . Which is OK for objects >>> located in object memory, >>> since there are always something past the last object (unallocated >>> space), >>> but not so ok for buffers allocated by malloc (such as cairo surface >>> bitmap), and so, >>> if you read even a single byte past it, you get protection fault. >>> >>> >>>> Esteban >>>> >>>> > On 24 Feb 2017, at 15:47, stepharong <stepharong(a)free.fr> wrote: >>>> > >>>> > Hi alex >>>> > >>>> > can you try the fix of ronie and let us know if it makes roassal more >>>> stable? >>>> > >>>> > Stef >>>> > >>>> >> Dear Alexander, >>>> >> >>>> >> Sine the new FFI of Pharo, using Athens has become unreliable. This >>>> is a pity, but fixing this is not trivial at all (we have been trying for >>>> years). >>>> >> >>>> >> What exactly are you doing with Athens? >>>> >> >>>> >> Alexandre >>>> >> >>>> >> >>>> >>> On Feb 22, 2017, at 12:55 AM, Alexander Samoylovich < >>>> samoylovich(a)gmail.com> wrote: >>>> >>> >>>> >>> Hello >>>> >>> >>>> >>> I am writing graphic demo programs using Athens on Mac Sierra. >>>> >>> Time by time Pharo VM crashes. Programs not using Athens work >>>> reliably. >>>> >>> I believe the behavior is reproducible. >>>> >>> How should I report a bug? >>>> >>> >>>> >>> Alex >>>> >> >>>> > >>>> > >>>> > -- >>>> > Using Opera's mail client: http://www.opera.com/mail/ >>>> > >>>> >>>> >>>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > >

March 1, 2017

Re: [Pharo-users] Socket, network, testing and coding

by Juraj Kubelka

Hi, > El 28-02-2017, a las 14:27, Benoit St-Jean via Pharo-users <pharo-users(a)lists.pharo.org> escribiÃ³: > > > De: Benoit St-Jean <bstjean(a)yahoo.com> > Asunto: Socket, network, testing and coding > Fecha: 28 de febrero de 2017, 14:27:58 CLST > Para: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > Responder a: Benoit St-Jean <bstjean(a)yahoo.com> > > > Hi guys, > > Quick question regarding sockets and testing. > > I'm trying to implement a simple communication protocol to exchange data (strings) between 2 images and I was wondering what was the easiest way to test/develop my code? I want to be able to do something similar to a chat client between 2 images where none of those 2 images acts as a server. So data can originate from any of those 2 images and both images have to "listen" to each other. Besides, both images would have to transmit/receive on the same port. > > 1) Is this possible (the way I want to do/test it)? Yes, you can test it. > 2) How do I simulate something like this on a *single* machine running those 2 images? Something like this: | listener clientSocket serverSocket | listener := Socket newTCP. [ listener listenOn: 0 backlogSize: 4. clientSocket := Socket newTCP. clientSocket connectTo: #[127 0 0 1] port: listener localPort. clientSocket waitForConnectionFor: 1. serverSocket := listener waitForAcceptFor: 1. ] ensure: [ listener destroy ]. since then you have client and server socket. You can call it clientOne, clientTwo. > 3) Do I need to have one of those 2 images act as a "serverâ ? At least one image has to serve as a server (listen to connections). Maybe you could use a discovery service protocol. I do not have any experience about it. > 4) Any helpful tip and/or interesting link to propose? > 5) Can you think of any simple code or example I could look at to understand what I need to do? There is a Trantor project where you could learn from: http://smalltalkhub.com/#!/~EvanDonahue/Trantor <http://smalltalkhub.com/#!/~EvanDonahue/Trantor> You can check an example here: TRNLog exampleOpenChatWithUserIdUsingTrantor But you are going to be more interested in testing: TrantorNodeTest Download it using: Gofer it smalltalkhubUser: 'EvanDonahue' project: 'Trantor'; configuration; loadBleedingEdge. And maybe Zinc (part of the Pharo image) has also good test examples. Cheers, Juraj > > ----------------- > BenoÃ®t St-Jean > Yahoo! Messenger: bstjean > Twitter: @BenLeChialeux > Pinterest: benoitstjean > Instagram: Chef_Benito > IRC: lamneth > Blogue: endormitoire.wordpress.com > "A standpoint is an intellectual horizon of radius zero". (A. Einstein) > >

March 1, 2017

Re: [Pharo-users] How to capture the execution of a playground?

by Offray Vladimir Luna CÃ¡rdenas

On 28/02/17 02:12, Ben Coman wrote: > > > On Tue, Feb 28, 2017 at 11:28 AM, Offray Vladimir Luna CÃ¡rdenas > <offray.luna(a)mutabit.com <mailto:offray.luna@mutabit.com>> wrote: > > Hi, > > I would like to store the object resulting from executing a > playground. This would imply two steps: > > - Knowing that the playground content was executed (via the play > button or its shortcuts Ctrl + Shift + g or Ctrl + g). > - Getting the results of that execution. For example if the result > at the end is a string or a dictionary, I would like to get that > string or dictionary. > > Any pointers on how to make that will be welcomed. > > Cheers, > > Offray > > Ps: I still get lost when I search by myself trying to answer > questions like the ones above. I imagine that in some way is > related with evaluationAction and presentations, by looking for > the source code of "do it and go", but still I can't get a > functional code snippet to start prototyping. > > > In playground, if you evaluate "self halt. 42" at top of the debug > stack you'll see method... > Undefined>>DoIt > self halt. > ^ 42 > > where stepping > OVER returns 42 into "value" variable in OpalCompiler>>evaluate > OVER returns 42 into "result" variable in > RubSmalltalkEditor>>evaluate:andDo: > at the end of which stepping > INTO "^aBlock value: result" takes you to > RubSmalltalkEditor>>highlightEvaluateAndDo:, where > INTO "[:result | aBlock value: result]" takes you to > GLMPharoScriptPResentation(GLMRubricSmalltalkCodePresentation)>>executionSelectionActions Wow that was pretty insightful! Thanks Ben. I still don't know when to use Over or Into, but that idea of inserting a halt in a playground to inspect behavior from them is really powerful. > where changing "aPresentation highlightEvaluateAndDo: [ :result | ] ]; > to "aPresentation highlightEvaluateAndDo: [ > :result | self inform: 'Result ' , result printString] ]; " > and opening a new Playground, then evaluating "42" informs us that > 42 is the result. > Yes, that captures and informs the result of the playground. Something similar happens when I change GLMPharoScriptPresentation>>goAction with: action: [ :t :entity | t highlightEvaluateAndDo: [ :result | t selection: result. self inform: 'Result ' , result printString ] ]; So, I'm able now to capture the result of a code execution in a playground (a partial selection or the full code) > Stepping further along, in > GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodePresentation)>>highlightEvaluateAndDo:: > > the value returned from... > self > evaluate: self highlightedTextAsStream > andDo: [:result | aBlock value: result. ]. > > is not 42 but aGLMPharoScriptPresentation. it might help to change > that to... > andDo: [:result | aBlock value: result. result ]. > but anyway that return value is thrown away in > GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodePresentation)>>actOnHighlightAndEvaluate: > > > So subclassing GLMRubricSmalltalkCodePresentation and overriding > #executionSelectionActions > is perhaps your best bet. Or some GLM expert provides a nice way for > a user to set this customAssignmentBlock... > aPresentation highlightEvaluateAndDo: [ :result | > customAssignmentBlock value: result ]. > in #executionSelectionActions. > Yes, I would expect a more "user friendly" way to do it. Something related with playground announcements to know when the play button has been executed and how the resulting object of this particular action is showed in the resulting pane. Is there a possibility like this? Cheers, Offray

March 1, 2017

Re: [Pharo-users] Proof of Concept: FileTree and Fossil

by stepharong

it means that we could also use the same setup to store pillar books > > > > On 28/02/17 10:56, Thierry Goubier wrote: >> >> >> 2017-02-28 16:43 GMT+01:00 Offray Vladimir Luna CÃ¡rdenas >> <offray.luna(a)mutabit.com>: >>> >>> Hi Thierry, >>> >>> What I'm using is the Fossil JSON API as described in [1]. Managing >>> Grafoscopio documentation with it is pretty easy and yes I believe it >>> could help in bringing >>>a unified API across several repositories (I >>> have not tested that though). >>> [1] http://fossil.wanderinghorse.net/repos/fwiki/index.cgi/wiki/README >> >> You probably intended [2], isn't it? >> > > Yep, I meant that one. :-) > >> I wasn't thinking much about multiple repos, but it could be one >> target. I was just thinking that there was/is one attempt to have a >> close integration to github API >>over HTTP in Pharo, and that this >> effort would have to b partially redone for, say GitLab, or Bitbucket >> because git does not defines a HTTP API and every hosting >>company >> creates one, whereas in Fossil everybody uses the JSON API. >> > > Ohh I understand now. Well is useful in both scenarios, and a showcase > of the power of simplicity and being late in the game :-). > > Cheers, > > Offray -- Using Opera's mail client: http://www.opera.com/mail/

Feb. 28, 2017