Pharo-dev
By thread
pharo-dev@lists.pharo.org
By month
Messages by month
- ----- 2026 -----
- July
- June
- May
- April
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
March 2017
- 718 messages
Re: [Pharo-dev] strange idea about slots
by Richard Sargent
Ben Coman wrote
> I'm not sure I'm thinking straight, but I wonder...
> Can you put Slots inside an Association?
>
> For example, could have two slots x and y,
> and then be able to do the following...
>
> (x -> y) substitute: (1 -> 2).
> self assert: x equals: 1.
> self assert: y equals: 2.
>
> So the association method #substitute:
> assigns into the relevant variables.
>
> And even better if you could do...
> (x -> y) := (1 -> 2).
> and...
> { x. y ) := #(1 2).
>
> For example, when you're hacking fast and want to return two values from a
> method without mucking around with creating an object for this, it might
> look like...
> myCalc
> ^#(1 2)
>
> but instead of...
> result := inst myCalc.
> x := result at: 1.
> y := result at: 2.
>
> you could do...
> { x . y } := inst myCalc.
I see this often, and even practice it sometimes. :-(
But every time I think about it, I get frustrated. We have no problem
creating instances of an existing class (Array, Association, even
Dictionary) to return multiple values from a method.
However, I always feel like doing so abdicates our responsibilities. At
least with a Dictionary, the values are properly identified rather than
stuffed into an anonymous collection or mis-represented as key and value.
Ultimately, I always conclude that this anti-pattern indicates a modelling
failure. Why not create a class which does the computation, holds the
several desired result objects, and provides the ability to answer them?
Worst case, you have a simple computation that produces more than one result
object. In such a case, create a data transfer object (no real behaviour)
that holds the results in appropriately named instance variables.
There seems to be a fear of creating new classes. Don't let that rule your
designs.
> cheers -ben
--
View this message in context: http://forum.world.st/strange-idea-about-slots-tp4936623p4936691.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
March 1, 2017
Re: [Pharo-dev] Google Summer of Code 2017: Call for mentors for Pharo Consortium
by Max Leske
It seems that I canât. Itâs not in the list of channels, I guess I have to be invited.
> On 1 Mar 2017, at 20:19, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote:
>
> Please join the #gsoc-planning channel on Slack !
>
> On Wed, Mar 1, 2017 at 8:16 PM, Max Leske <maxleske(a)gmail.com> wrote:
>> Good stuff!
>>
>> Iâm up for mentoring.
>>
>>> On 1 Mar 2017, at 13:45, 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
> UCBN & UMI UMMISCO 209 (IRD/UPMC)
> Every DSL ends up being Smalltalk
> http://www.doesnotunderstand.org/
>
March 1, 2017
Re: [Pharo-dev] Google Summer of Code 2017: Call for mentors for Pharo Consortium
by Serge Stinckwich
Please join the #gsoc-planning channel on Slack !
On Wed, Mar 1, 2017 at 8:16 PM, Max Leske <maxleske(a)gmail.com> wrote:
> Good stuff!
>
> Iâm up for mentoring.
>
>> On 1 Mar 2017, at 13:45, 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
UCBN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
http://www.doesnotunderstand.org/
March 1, 2017
Re: [Pharo-dev] Google Summer of Code 2017: Call for mentors for Pharo Consortium
by Max Leske
Good stuff!
Iâm up for mentoring.
> On 1 Mar 2017, at 13:45, 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)
>
March 1, 2017
Re: [Pharo-dev] strange idea about slots
by Clément Bera
On Wed, Mar 1, 2017 at 3:56 PM, Ben Coman <btc(a)openinworld.com> wrote:
>
> I'm not sure I'm thinking straight, but I wonder...
> Can you put Slots inside an Association?
>
> For example, could have two slots x and y,
> and then be able to do the following...
>
> (x -> y) substitute: (1 -> 2).
> self assert: x equals: 1.
> self assert: y equals: 2.
>
For this you can do it by manipulating the stack in #substitute: . Are x
and y temporary variables or instance variables ? You could look-up in the
context's sender method AST what they are and do something accordingly.
>
> So the association method #substitute:
> assigns into the relevant variables.
>
> And even better if you could do...
> (x -> y) := (1 -> 2).
> and...
> { x. y ) := #(1 2).
>
>
For this you need parser extensions as this is not valid Smalltalk.
For example, when you're hacking fast and want to return two values from a
> method without mucking around with creating an object for this, it might
> look like...
> myCalc
> ^#(1 2)
>
> but instead of...
> result := inst myCalc.
> x := result at: 1.
> y := result at: 2.
>
> you could do...
> { x . y } := inst myCalc.
>
You mean like tuples in Python ?
To cover all your use-cases, the best is to change the bytecode compilation
pipeline.
If you need to extend the Syntax, you need to use Opal with an extended
Parser (Typically a subclass of RBParser you write).
Then the easiest is to transform the AST from your extended parser (or the
default AST if you don't extend the syntax) to standard Smalltalk AST doing
what you want before the semantic analysis and feed it to Opal. You can do
something manually or something with RBParseTreeRewriter :-).
In the cases you show it is enough to generate what you want.
Ah yeah, modifying the syntax or modifying the expected behavior of a
syntax is often considered as a bad practice or evil.
>
> cheers -ben
>
March 1, 2017
[pharo-project/pharo-core]
by GitHub
Branch: refs/tags/60420
Home: https://github.com/pharo-project/pharo-core
March 1, 2017
[pharo-project/pharo-core] 6a900f: 60420
by GitHub
Branch: refs/heads/6.0
Home: https://github.com/pharo-project/pharo-core
Commit: 6a900f6d070e3179dfbd5897db9769b5cea5d867
https://github.com/pharo-project/pharo-core/commit/6a900f6d070e3179dfbd5897…
Author: Jenkins Build Server <board(a)pharo-project.org>
Date: 2017-03-01 (Wed, 01 Mar 2017)
Changed paths:
M BaselineOfIDE.package/BaselineOfIDE.class/instance/actions/postload_package_.st
M BaselineOfUI.package/BaselineOfUI.class/instance/actions/postload_package_.st
R BaselineOfUI.package/BaselineOfUI.class/instance/actions/preload_package_.st
M BaselineOfUI.package/BaselineOfUI.class/instance/baseline/baseline_.st
M Morphic-Base.package/EmbeddedMenuMorph.class/instance/control/selectItem_event_.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60419.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60420.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60419.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60420.st
M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
M Tool-FileList.package/FileList.class/instance/private/updateFileList.st
Log Message:
-----------
60420
19777 BaselineOfUI compiles own version of RubScrolledTextMorph>>#font:
https://pharo.fogbugz.com/f/cases/19777
19772 BaselineOfIDE compiles own version of EpLostChangesDetector>>#startUp:
https://pharo.fogbugz.com/f/cases/19772
18784 FileList selected directory entry is not cleared after selecting a new directory
https://pharo.fogbugz.com/f/cases/18784
18871 DNU after showing about box of QA annotation question mark icon
https://pharo.fogbugz.com/f/cases/18871
19774 BaselineOfUI is compiling own version of Pragma>>#methodSelector
https://pharo.fogbugz.com/f/cases/19774
http://files.pharo.org/image/60/60420.zip
March 1, 2017
Re: [Pharo-dev] strange idea about slots
by Pavel Krivanek
Slots only drive access to the instance variables and the association
"literal" is already a message send. But I guess you wold be able to do
such behavior with own Opal plugin.
-- Pavel
2017-03-01 15:56 GMT+01:00 Ben Coman <btc(a)openinworld.com>:
>
> I'm not sure I'm thinking straight, but I wonder...
> Can you put Slots inside an Association?
>
> For example, could have two slots x and y,
> and then be able to do the following...
>
> (x -> y) substitute: (1 -> 2).
> self assert: x equals: 1.
> self assert: y equals: 2.
>
> So the association method #substitute:
> assigns into the relevant variables.
>
> And even better if you could do...
> (x -> y) := (1 -> 2).
> and...
> { x. y ) := #(1 2).
>
> For example, when you're hacking fast and want to return two values from a
> method without mucking around with creating an object for this, it might
> look like...
> myCalc
> ^#(1 2)
>
> but instead of...
> result := inst myCalc.
> x := result at: 1.
> y := result at: 2.
>
> you could do...
> { x . y } := inst myCalc.
>
> cheers -ben
>
March 1, 2017
Re: [Pharo-dev] Google Summer of Code 2017: Call for mentors for Pharo Consortium
by phil@highoctane.be
Ok for helping someone :-)
Phil
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)
>
>
March 1, 2017
strange idea about slots
by Ben Coman
I'm not sure I'm thinking straight, but I wonder...
Can you put Slots inside an Association?
For example, could have two slots x and y,
and then be able to do the following...
(x -> y) substitute: (1 -> 2).
self assert: x equals: 1.
self assert: y equals: 2.
So the association method #substitute:
assigns into the relevant variables.
And even better if you could do...
(x -> y) := (1 -> 2).
and...
{ x. y ) := #(1 2).
For example, when you're hacking fast and want to return two values from a
method without mucking around with creating an object for this, it might
look like...
myCalc
^#(1 2)
but instead of...
result := inst myCalc.
x := result at: 1.
y := result at: 2.
you could do...
{ x . y } := inst myCalc.
cheers -ben
March 1, 2017