- Pharo-dev - lists.pharo.org

about push up and pull up
by Stephane Ducasse March 26, 2017

March 26, 2017

Hi guys I wonder why we have push up method and pull up instance variables. I remember that long time ago we got a discussion but I forgot. Do you remember? Stef (writing chapters for new books for total newbies: yes the future pharoers)

3 4

Estebanâs list of blocking issues for release Pharo 6.0
by Esteban Lorenzano March 26, 2017

March 26, 2017

Hi, I wanted to share with you the list of blocking issues I see to do the release :) Image ===== - Cairo surface crash. Of course, as it is now is unnaceptable... I have some solution to test but if that does not work, I will workaround the problem by adding a (hopefully temporal) CairoPlugin. - Iceberg needs to enter the system as preview before release. This is needed to use the new process, and it was almost ready but we get blocked for a problem in VM for linux (see below). - I'm quite sure there is still a leak. During too much time we had the compactor problem so we blame it for our increasing sizes. Now it works and images continue growing without control, so we need to find it. Image 64bits ============ - Athens is working in general, but there are still some places where it uses a `long` as a pointer and of course, that's not true on 64bits (at least in windows). VM == - New VM compactor has problems when image hits a big size. Eliot is working on it, but we cannot release with VM as it is now... I hope it will be fixed next days too. - here are still some glitches and tests do not pass completely. Methods failing in travis are: DelayMicrosecondSchedulerTest>>#testForMilliseconds MutexTest>>#testFailedCriticalSectionShouldUnblockWaitingOne This, in linux VM. I think is important but I think we will have a solution next days - Dependency libraries problem. Again, in linux... we distribute libgit2, libssh2 and libssl (because we cannot rely on linux installed versions), and there is a problem to solve the paths. Ultimate solution is to use a script as entry point (not the binary), and do a LD_LIBRARY_PATH to solve it. Iâm testing this. VM 64bits ========= - Is incredibly hard to compile a 64bits version of libgit2 0.23 (the one we are using) for macOS, which makes impossible to use Iceberg. Not sure this is blocking, but well... I needed to point it :) - No VM for windows. Again, this is a know issueâ¦ but maybe I can add a StackVM for windowsâ¦ I need to see how is working.

6 16

Good way to promote Smalltalk
by askoh March 26, 2017

March 26, 2017

Being able to shine in software competitions is a very good way for Smalltalk to get exposure. We should present our technologies as such competitions as much as possible. Enjoy the case below. http://www.cincomsmalltalk.com/main/2017/03/one-cincom-engineer-got-450-pro… Aik-Siong Koh -- View this message in context: http://forum.world.st/Good-way-to-promote-Smalltalk-tp4939758.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

3 4

ZnEasy problem?
by Stephane Ducasse March 25, 2017

March 25, 2017

Hi guys in the mooc (first example) we have the following expression (ZnEasy getPng: 'http://pharo.org/web/files/pharo.png') and it does not work anymore. I'm pair programming with Amal in Rennes from the university in italy and from her univ in Rennes we both get on 60 and 50 and time out https sslException: text code: code self error: (String streamContents: [ :stream | stream << 'SSL Exception: ' << text << ' [code:'. stream print: code. stream << ']' ]) Any idea. Tx in advance

5 10

Is this a report for an announcement?
by Eliot Miranda March 24, 2017

March 24, 2017

Hi All, there's probably no issue here, except that I'm seeing a report for an announcement, and I fear it might be wasted effort. So can someone who understands this examine the following and check whether announcements are being reported by mistake? This is an a 6.0 image with Scorch loaded (so it may be completely irrelevant). [0mProcess>>terminate NECController>>stopCompletionDelay NECController>>closeMenu MessageSend>>value MessageSend>>cull: MessageSend>>cull:cull: [ action cull: anAnnouncement cull: announcer ] in AnnouncementSubscription>>deliver: in Block: [ action cull: anAnnouncement cull: announcer ] FullBlockClosure(BlockClosure)>>on:do: FullBlockClosure(BlockClosure)>>on:fork: AnnouncementSubscription>>deliver: [ "Ensure delivery to remaining announcements" subscription deliver: anAnnouncement ] in SubscriptionRegistry>>deliver:to:startingAt: in Block: [ "Ensure delivery to remaining announcements" sub...etc... FullBlockClosure(BlockClosure)>>ifCurtailed: SubscriptionRegistry>>deliver:to:startingAt: SubscriptionRegistry>>deliver:to: SubscriptionRegistry>>deliver: Announcer>>announce: RubEditingArea(Morph)>>doAnnounce: RubEditingArea(Morph)>>announceKeyboardFocusChange: RubEditingArea(Morph)>>keyboardFocusChange: RubEditingArea(RubAbstractTextArea)>>keyboardFocusChange: HandMorph>>newKeyboardFocus: HandMorph>>releaseKeyboardFocus [ :hand | hand releaseKeyboardFocus ] in WorldMorph>>viewBox: in Block: [ :hand | hand releaseKeyboardFocus ] Array(SequenceableCollection)>>do: WorldState>>handsDo: WorldMorph>>viewBox: WorldMorph(PasteUpMorph)>>restoreMorphicDisplay WorldMorph class>>startUp WorldMorph class(Behavior)>>startUp: ClassSessionHandler>>startup: [0m _,,,^..^,,,_ best, Eliot

1 0

Serial Port not working on Mac
by Guillermo Polito March 24, 2017

March 24, 2017

Hi all, We are here with Olivier taking a loot at how serial ports work, because he wants to use it to connect to arduino/raspberries. We saw that the serial port works nice in unix, in windows we had a look but we found some problems (and we do not have now a windows machine to test well), and we found that in mac it does not work. We are seeing that this behaviour is there since Pharo 3 (4 years ago). We tried to see if it was a problem of the VM plugin (missing depenencies using ld / otool) but everything seemed ok. Finally, we took the vm from git and tried to compile it from scratch. *Meta-question 1:* Is there a way to create an xcode project from the vm sources? We would have lost less time if we used a graphical debugger to take a look at this :). There, we found that - apparently the mac VM is using an empty implementation of the serial port plugin: https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/Mac%20… We replaced the contents of that file by the one in the Unix plugin and it worked *when the plugin was compiled as internal* (delta some differences between the default values in mac and unix like uppercasing the 's' of ttyS and ttys) https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/p… However, as soon as we retried to recompile the plugin as external it did not work any more... The initializeModule function was never called, the module was not loaded (from the system report) and the Serial port could not be open. For this we would have liked a debugger. And I'm not a friend of gdb on the terminal... *Meta-question 2:* Is there any clean/make clean used to remove generated files. We found ourselves a lot of times bitten by the fact that even recompiling everything using `mvm -A` did not really recompile and we had to remove files from here and there... How should we propose a fix? - do we duplicate the code of the plugin in the mac and unix platforms? - or do we somehow tell the compilation process that for this plugin it should use the sources in the unix platform code? Thanks! Guille and Olivier

2 1

[pharo-project/pharo-core]
by GitHub March 24, 2017

March 24, 2017

Branch: refs/tags/60451 Home: https://github.com/pharo-project/pharo-core

1 0

[pharo-project/pharo-core] 6f7772: 60451
by GitHub March 24, 2017

March 24, 2017

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 6f7772a796bf7238b33ebcaca3263b10a7cc591e https://github.com/pharo-project/pharo-core/commit/6f7772a796bf7238b33ebcac… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-03-24 (Fri, 24 Mar 2017) Changed paths: M Refactoring-Core.package/RBMoveMethodToClassRefactoring.class/instance/transforming/transform.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60450.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60451.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60450.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60451.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60451 19863 RBMoveMethodToClassRefactoring reset method protocol https://pharo.fogbugz.com/f/cases/19863 http://files.pharo.org/image/60/60451.zip

1 0

inspector performance improvement
by Tudor Girba March 23, 2017

March 23, 2017

Hi, Andrei and Alex did a great job at improving the performance and scalability of the inspector. There are a couple of main improvements: - Added FastTable support for the Raw presentation for all objects. This implied completing the support for the tree presentation binding to fast table. - Moved the Items presentation for collections to FastTable. - Improved the rendering of Glamour to no longer rely on the default Morph>>#adoptPaneColor. It turns out that using adoptPaneColor triggers a relayout of the morph, even if it is not visible. We extended PanelMorph in the context of Glamour with a less needy logic. I will not tell you how fast it is. I would rather want you to play with it :). The change is already in the Moose image. It is not yet in Pharo, but it will be soon. In the meantime you can be load it in Pharo 6 like this: Gofer new smalltalkhubUser: 'Moose' project: 'GToolkit'; package: 'ConfigurationOfGToolkitCore'; load. (#ConfigurationOfGToolkitCore asClass project version: #stable) load To play with it, try this with both the current version and the new one and the Spec Inspector if you want (just make sure you save the image beforehand): collection := (1 to: 100000000) asArray. [collection inspect] timeToRun. collection := (1 to: 100000000). [collection inspect] timeToRun. (for these two ones notice that Items do not appear at all in the old implementation) [World inspect] timeToRun. There are still a couple of issues open, such as the sorting of the columns. We would need your help with testing this, and report possible missing issues. Cheers, Doru -- www.tudorgirba.com www.feenk.com "Obvious things are difficult to teach."

5 5

Fwd: GSoC 2017: Tips on Reviewing Student Proposals
by Serge Stinckwich March 23, 2017

March 23, 2017

Dear all, this is a short update for the Google Summer of Code 2017. The students have to submit your proposals on the Google website before April 3rd. See details below. I dunno exactly who are the students/mentors who are submitting a proposal for Pharo. Can the mentors (or students) send me in private an email about the name of the students/mentors + a title of your project ? Thank you very much. Regards, ---------- Forwarded message ---------- From: Google Summer of Code <summerofcode-noreply(a)google.com> Date: Mon, Mar 20, 2017 at 7:26 PM Subject: GSoC 2017: Tips on Reviewing Student Proposals To: sergestinckwich(a)gmail.com [image: Google Summer of Code] Hi Serge Stinckwich, Thank you for registering to be a GSoC 2017 mentor or organization administrator! We have many new mentors and organizations this year so we wanted to go through some important details to help you understand the process for the next couple of months. Please take the time to reach out to your organization administrator about what is expected of you this year as a mentor. We also encourage you to read the entire Google Summer of Code mentor manual <http://write.flossmanuals.net/gsoc-mentoring/about-this-manual/> and the Roles and Responsibilities doc if you haven't done so already. Both the manual and Roles and Responsibilities doc were written by GSoC veteran Org Admins, Mentors, former students and Google Program Admins. They have helpful information about the program and how to participate successfully at each step in GSoC. *New GSoC Orgs*: the section about participating in your first GSoC has some great tips. To see all emails sent to mentors and org admins visit this page <https://developers.google.com/open-source/gsoc/2017/mentor-oa-announcements> that will continue to be updated throughout the program. Student Proposals As of today, students are able to submit their proposals via the website. Each student may submit up to 5 proposals to the program. They can submit multiple proposals to the same organization for different projects if they wish. Historically, the students with the best proposals reach out to the orgs early to receive feedback before submitting their final proposal. To encourage more students to seek feedback on their proposals we made draft proposals part of the official proposal workflow. Be sure to refresh your dashboard periodically so that you can see when new drafts are ready to review. You will not receive an email. We are encouraging the use of Google Docs for proposals as this will allow you to comment directly on the proposal (if the student sets their sharing settings correctly). Over the next couple of weeks you will be interacting with dozens and in some cases hundreds of students interested in working with your project. We know many of you may become overwhelmed and some students can be impatient, so you may want to have an auto-responder or some sort of canned response to let students know you are looking at their proposals but it could take X days to receive a response. Students *must* submit their final proposal as a PDF through the website. It will be visible to you after the deadline for student applications (April 3 16:00 UTC). You should make your decisions on which students to accept based on the contents of the final PDF proposal and your interactions with the student. Students can delete their proposals and you will not receive an email of the deletion. If a proposal disappears from your list, it is likely because they deleted it. Working with Students All student projects must have at least 1 mentor assigned to the project. We strongly encourage assigning a second mentor as a backup mentor or co-mentor. A mentor should not be the primary mentor for more than one or two students. Mentoring can be a lot of work and we donât want anyone to burn out and become frustrated with the program. Important GSoC 2017 Dates and Deadlines *March 20 - April 3 16:00 UTC*: Mentors and Org Admins review student draft proposals and give students feedback on their proposals. *April 3 - 16:* Review all submitted student proposals with your org and consider how many you want to select and how many you can handle. Decide on the minimum/maximum number of student slots to request. *April 17, 16:00 UTC*: Deadline to submit slot requests (OAs enter requests) *April 19, 16:00 UTC*: Slot allocations are announced by Google *April 19 - 24 16:00 UTC* : Select the proposals to become student projects. At least 1 mentor must be assigned to each project before it can be selected. (OAs enter selections) *April 24 - May 4:* Google Program Admins will do another review of student eligibility *May 4*: Accepted GSoC students/projects are announced *May 4 - 29*: Community Bonding Period *May 30*: Coding begins *June 26-30*: First evaluation period - mentors evaluate students, students evaluate mentors *July 24 - 28*: Second evaluation period - mentors evaluate students, students evaluate mentors *August 21- 29*: Students wrap up their projects and submit final evaluation of their mentor *August 29 - September 5*: Mentors submit final evaluations of students *September 6*: Students passing GSoC 2017 are announced Mentors Mailing List If you want to be included on the GSoC mentors mailing list be sure to opt in on your User Profile page. We will add anyone who has opted in to the list every few days for the next month. And then every couple of weeks throughout the program. You can always opt out once you have been added by unsubscribing using the link on any of the emails. Contact Us Please use the gsoc-support(a)google.com email address for questions so that anyone on our team can answer your question for you. We look forward to working with all of you over these next 6 months! Thanks again for being a mentor for GSoC 2017! Google Open Source Programs Office This email was sent to serge.stinckwich(a)gmail.com. You are receiving this email because of your participation in Google Summer of Code 2017. https://summerofcode.withgoogle.com To leave the program and stop receiving all emails, you can go to your profile <https://summerofcode.withgoogle.com/dashboard/profile/> and request deletion of your program profile. For any questions, please contact gsoc-support(a)google.com. Replies to this message go to an unmonitored mailbox. Â© 2017 Google Inc., 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA -- Serge Stinckwich UCN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

1 0