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

Google Summer of Code 2017: Call for mentors for Pharo Consortium

by Serge Stinckwich

Heartiest Congratulations ! Pharo Consortium has been selected as a mentor organisation for Google Summer of Code 2017. Google Summer of Code is a global program focused on introducing students to open source software development. Students work on a 3 month programming project with an open source organisation during their break from university. Read more at https://summerofcode.withgoogle.com/ How the program works ? Organizations: Open source projects apply to be mentor organizations. Once accepted, organizations discuss possible ideas with students and then decide on the proposals they wish to mentor for the summer. They provide mentors to help guide each student through the program. Mentors: Existing contributors with the organizations can choose to mentor a student project. Mentors and students work together to determine appropriate milestones and requirements for the summer. Mentor interaction is a vital part of the program. A mentor may propose or endorse a project and each project has to be about Pharo or its ecosystem (e.g., a library). Projects will be mentored by one or more mentors and executed by one student. Students: Students contact the mentor organizations they want to work with and write up a project proposal for the summer. If accepted, students spend a month integrating with their organizations prior to the start of coding. Students then have three months to code, meeting the deadlines agreed upon with their mentors. Student coding period: May 30 - Aug 29 (Entire timeline can be viewed at: https://summerofcode.withgoogle.com/how-it-works/#timeline) Student stipend: https://developers.google.com/open-source/gsoc/help/student-stipends We are currently at the phase of identifying mentors and projects. The next phases will be about students selecting projects, and the community selecting the projects with their associated mentors and students which will be sponsored by the GSOC program. How to register ? Simply by replying to this email and joining the Slack channel... to have more discussion about what project the mentor will take up, what she/he wants at the end of the coding period and then we can invite them to the GSoC org dashboard). Hence, we invite regular & enthusiastic Pharo contributors to be a mentor with Pharo Consortium for GSoC 2017: 1. Kindly respond on this thread if you'd like to be a mentor, or wish to propose a project. An existing list of projects is already available here: http://gsoc.pharo.org/ and we already have a handful of projects and mentors chosen. Feel free to collaborate with existing mentors as well. 2. Join dedicated channels, #gsoc-students for general interactions with students & #gsoc-planning channel only for GSOC admins and mentors on Pharo slack. In order to get an invitation for pharoproject.slack.com visit the URL here: http://slackinvites.pharo.org/ 3. Please open relevant issues and make a roadmap of the projects being mentored by you so that students can start contributing to them already. If you want to mentor a project and there is no open-source repository at the moment, please built one ASAP. 4. If you know any students that might be interested to work on Pharo during the summer and be a part of GSoC as well, please ask him/her to start contributing to the Pharo projects, discuss their proposal, follow instructions that shall be posted soon in this mailing thread and submit their application by April 3, 2017. We don't know the number of slots attributed by Google to Pharo org, but the more students proposal we will receive, the more slots will be attributed to us. We remind you about the mentor responsibilities: ... to your Org Admins - Communicate availability and interaction expectations - Inform when mentoring capacity will be reduced, as early as possible (e.g., family, health, vacation) - Inform when there is an issue with a student - Lacking communication, activity, visibility (MIA), or progress - Participant Agreement violations (e.g., plagiarism, harassment, fraud) - Bad fit or stepping down - Formally evaluate student participation. - Communicate with admin and student before failing ... to your Students - Help and/or teach the student - how to be a part of your community - communicate more effectively and in the open - work with your orgâs preferred communication channel (IRC, Slack, etc) - use your orgâs version control system - ask good questions and get answers to their questions - provide convincing technical argument and constructive discussion - be independently motivated and productive - solve difficult technical problems - Keep track of their progress, keep student informed as to their status - Communicate on a regular basis, once a week or better (for GSoC) - Give constructive feedback, be patient, and be respectful - Respond to questions within 24 hours (occasionally under 36 hours is ok) - Establish realistic work objectives and timeline expectations - Re-evaluate scope with student when significantly ahead of or behind expectations - Work with devs and community to facilitate acceptance of student work Read more about responsibilities here: https://developers.google.com/open-source/gsoc/help/responsibilities Looking forward to a great guided summer by the talented mentors of our organisation. Warm Regards Pharo Organisation Admins (Alexandre Bergel, Jigyasa Grover, Serge Stinckwich & Yuriy Tymchuk)

March 1, 2017

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