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

Re: [Pharo-users] Google Summer of Code 2017: Call for mentors for Pharo Consortium

by Serge Stinckwich

Dear all, we have 10 mentors + 4 admin at the moment. We are looking for me ! Please join the #gsoc-planning Slack channel. Thank you. On Wed, Mar 1, 2017 at 1:45 PM, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > 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) -- Serge Stinckwich UCN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

March 5, 2017

Re: [Pharo-users] Voyage and duplicated entry

by Joachim Tuchel

Hilaire Sounds like this has nothing to do with voyage. If you modify part of on object's unique identifier, it's another object. The best you can do is to use a synthetic id that has no business meaning and use that for object identity. Joachim > Am 05.03.2017 um 12:02 schrieb Hilaire <hilaire(a)drgeo.eu>: > > Situation looks a bit clearer. > The duplicated object entries issue arises with two concomitant situations: > > - the object reimplements hash and = methods > - one of the attributes participating in the comparing protocol is modified. > > In that scenario, Voyage guess it is dealing with a new element, even if > it is not the case. > > In some scenario, user really needs to override the comparing protocol, > how to deal with the duplicated entries issue in that case? > > Hilaire > >> Le 05/03/2017 Ã 10:19, Hilaire a Ã©crit : >> I must stress the same instance duplication occurs when I inspect an >> instance, edit one attribute from the inspector, then save it from the >> inspector with "self save" command. > > -- > Dr. Geo > http://drgeo.eu > > >

March 5, 2017

Re: [Pharo-users] Voyage and duplicated entry

by Hilaire

Situation looks a bit clearer. The duplicated object entries issue arises with two concomitant situations: - the object reimplements hash and = methods - one of the attributes participating in the comparing protocol is modified. In that scenario, Voyage guess it is dealing with a new element, even if it is not the case. In some scenario, user really needs to override the comparing protocol, how to deal with the duplicated entries issue in that case? Hilaire Le 05/03/2017 Ã 10:19, Hilaire a Ã©crit : > I must stress the same instance duplication occurs when I inspect an > instance, edit one attribute from the inspector, then save it from the > inspector with "self save" command. -- Dr. Geo http://drgeo.eu

March 5, 2017

Re: [Pharo-users] why is concat of Symbols a string?

by Sven Van Caekenberghe

I also think that allowing concatenation on Symbols does not violate their immutability contract. As a thought experiment, what could be the problem with adding Symbol >> , arg ^ (self , arg) asSymbol ? (I have found the original issue raised annoying as well) > On 5 Mar 2017, at 11:35, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > I don't need (or want) to mutate the receiver. Actually I thought that String is also immutable. > $, could just return a new symbol instance instead. Concating symbols is quite practical for metaprogramming, as most things are named with symbols and compare by identity... > > Peter > > > On Sun, Mar 05, 2017 at 04:29:39AM +0200, Igor Stasenko wrote: >> Hmm.. symbols is usually treated like immutable object(s) in system. They >> tend to stay while rest of data changes.. This could explain why authors of >> this method >> purposedly picked to use ByteString for its species to discourage using >> symbols for collection manipulation(s).. >> Else, if you would need to change this method as well: >> >> at: anInteger put: anObject >> "You cannot modify the receiver." >> >> self errorNoModification >> >> because base class #, implementation is going to use at:put: during >> concatenation. >> >> >> >> On 4 March 2017 at 13:40, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >> >>> Hi, >>> >>> All symbols are interned in the Symbol table. If one does (#foo , #bar , >>> #baz) and each returned value would be a symbol, then both #foobar and >>> #foobarbaz would be registered in the symbol table. >>> >>> I would guess that's why the concatenated value is a string and not a >>> symbol, to avoid registering many unused symbols. But maybe I am wrong. >>> >>> If for your use case you need to concatenate symbols and get a symbol out >>> of it, you can define a new method in Symbol to do what you want. >>> >>> For example: >>> >>> Symbol >> ,, arg >>> ^ (self , arg) asSymbol >>> >>> Then >>> >>> #foo ,, #bar >>> >>> Answers directly the symbol #foobar. >>> >>> Best, >>> >>> >>> >>> >>> On Sat, Mar 4, 2017 at 11:36 AM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >>> >>>> Hi, >>>> >>>> why is the concatenation of symbols a string? >>>> >>>> e.g. #desc, #Name -> 'descName' >>>> >>>> this means that I have to always wrap in parentheses and recast, or >>>> stream it, e.g. >>>> >>>> (#desc, #Name) asSymbol -> #descName >>>> Symbol streamContents: [ :s | s << #desc; << #Name ] -> #descName >>>> >>>> both of which introduce extraneous syntactical clutter. >>>> The technical reason seems to be ByteSymbol>>#species returning >>>> ByteString, but I have no idea why it has to be this complicated. >>>> >>>> Thanks, >>>> Peter >>>> >>>> >>> >> >> >> -- >> Best regards, >> Igor Stasenko. >

March 5, 2017

Re: [Pharo-users] why is concat of Symbols a string?

by Peter Uhnak

I don't need (or want) to mutate the receiver. Actually I thought that String is also immutable. $, could just return a new symbol instance instead. Concating symbols is quite practical for metaprogramming, as most things are named with symbols and compare by identity... Peter On Sun, Mar 05, 2017 at 04:29:39AM +0200, Igor Stasenko wrote: > Hmm.. symbols is usually treated like immutable object(s) in system. They > tend to stay while rest of data changes.. This could explain why authors of > this method > purposedly picked to use ByteString for its species to discourage using > symbols for collection manipulation(s).. > Else, if you would need to change this method as well: > > at: anInteger put: anObject > "You cannot modify the receiver." > > self errorNoModification > > because base class #, implementation is going to use at:put: during > concatenation. > > > > On 4 March 2017 at 13:40, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > Hi, > > > > All symbols are interned in the Symbol table. If one does (#foo , #bar , > > #baz) and each returned value would be a symbol, then both #foobar and > > #foobarbaz would be registered in the symbol table. > > > > I would guess that's why the concatenated value is a string and not a > > symbol, to avoid registering many unused symbols. But maybe I am wrong. > > > > If for your use case you need to concatenate symbols and get a symbol out > > of it, you can define a new method in Symbol to do what you want. > > > > For example: > > > > Symbol >> ,, arg > > ^ (self , arg) asSymbol > > > > Then > > > > #foo ,, #bar > > > > Answers directly the symbol #foobar. > > > > Best, > > > > > > > > > > On Sat, Mar 4, 2017 at 11:36 AM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > > >> Hi, > >> > >> why is the concatenation of symbols a string? > >> > >> e.g. #desc, #Name -> 'descName' > >> > >> this means that I have to always wrap in parentheses and recast, or > >> stream it, e.g. > >> > >> (#desc, #Name) asSymbol -> #descName > >> Symbol streamContents: [ :s | s << #desc; << #Name ] -> #descName > >> > >> both of which introduce extraneous syntactical clutter. > >> The technical reason seems to be ByteSymbol>>#species returning > >> ByteString, but I have no idea why it has to be this complicated. > >> > >> Thanks, > >> Peter > >> > >> > > > > > -- > Best regards, > Igor Stasenko.

March 5, 2017

Re: [Pharo-users] [Modeling with Pharo] How to model a simple human interaction.

by stepharong

> Looks awesome. > > Now, how hard would it be to reuse a WATask from Seaside from normal, > non web code? > > A lot of WAxxx concepts could be brought back into nornal "Spec/Morphic" > apps, like WASession, WATask, filters etc. Indeed and we can accept them and cocoon them :)

March 5, 2017

Re: [Pharo-users] [Modeling with Pharo] How to model a simple human interaction.

by stepharong

On Sun, 05 Mar 2017 00:42:44 +0100, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > This may be overkill for your use but would love to have an MIT licensed > set > of classes that allow for/enable something like this: > > > https://medium.com/assist/theres-a-dozen-ways-to-order-a-coffee-why-do-dumb… looks nice. the first step is to have something basic and improve. Stef

March 5, 2017

Re: [Pharo-users] [Modeling with Pharo] How to model a simple human interaction.

by phil＠highoctane.be

Looks awesome. Now, how hard would it be to reuse a WATask from Seaside from normal, non web code? A lot of WAxxx concepts could be brought back into nornal "Spec/Morphic" apps, like WASession, WATask, filters etc. Phil On Sun, Mar 5, 2017 at 12:42 AM, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > This may be overkill for your use but would love to have an MIT licensed > set > of classes that allow for/enable something like this: > > > https://medium.com/assist/theres-a-dozen-ways-to-order- > a-coffee-why-do-dumb-bots-only-allow-one-27230542636d#.laljhpyt5 > > > > > sergio ruiz wrote > > Hey all.. > > > > I got my first paying gig that i am able to use pharo with, and i am on > > the last leg before calling it complete. > > > > Hereâs what I need to do.. > > > > This application accepts SMS text messages. It allows the user to send > > images via MMS and place an order to a print house for those images.. it > > then compiles the order, and submits it to the order processing system > and > > makes the prints. > > > > The last thing I need to zero in on is handling the interaction. Believe > > it or not, I have never modeled such an interaction. The interaction > goes: > > > > - user sends images{s) > > - bot says âthanksâ and asks if there are more > > - user types âdoneâ or sends more > > - on âdoneâ bot asks for print size > > - bot says âthanksâ and the interaction is done. order is processed. > > > > my first inclination is to use a state machine, progressing through order > > each time the user enters âdoneâ.. > > > > does this sound reasonable, or is there a better model/design pattern for > > this interaction? > > > > Thanks! > > > > > > ---- > > peace, > > sergio > > photographer, journalist, visionary > > > > Public Key: http://bit.ly/29z9fG0 > > #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV > > http://www.Village-Buzz.com > > http://www.ThoseOptimizeGuys.com > > http://www.coffee-black.com > > http://www.painlessfrugality.com > > http://www.twitter.com/sergio_101 > > http://www.facebook.com/sergio101 > > > > signature.asc (852 bytes) > > <http://forum.world.st/attachment/4937293/0/signature.asc> > > > > > > -- > View this message in context: http://forum.world.st/ > Modeling-with-Pharo-How-to-model-a-simple-human- > interaction-tp4937293p4937308.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > >

March 5, 2017

Re: [Pharo-users] Voyage and Date

by Esteban Lorenzano

Voyage cannot guess user intentions. But yes we could add a helper to do the transformation easier (like a special description for dates), but you will always need to configure that by hand. Esteban > On 5 Mar 2017, at 10:22, Hilaire <hilaire(a)drgeo.eu> wrote: > > Hi Esteban, > > This is a recurring problem. May be Voyage should come with the > necessary adaptor to have the Date right. It is likely *every* Voyage > user faces the problem, and it does not fell good about the framework to > have issue on such elementary feature. > > Hilaire > > Le 05/03/2017 Ã 10:06, Esteban Lorenzano a Ã©crit : >> the base of the problem is that mongo does not actually has a Date type, just DateAndTime (even if is called Date). >> So if you want a Date, you need to do some conversion. > > -- > Dr. Geo > http://drgeo.eu > >

March 5, 2017

Re: [Pharo-users] Voyage and Date

by Hilaire

Hi Esteban, This is a recurring problem. May be Voyage should come with the necessary adaptor to have the Date right. It is likely *every* Voyage user faces the problem, and it does not fell good about the framework to have issue on such elementary feature. Hilaire Le 05/03/2017 Ã 10:06, Esteban Lorenzano a Ã©crit : > the base of the problem is that mongo does not actually has a Date type, just DateAndTime (even if is called Date). > So if you want a Date, you need to do some conversion. -- Dr. Geo http://drgeo.eu

March 5, 2017