October 2013 - Pharo-dev - lists.pharo.org

Anyone else teaching programming in Pharo?
by J.F. Rick Oct. 19, 2013

Oct. 19, 2013

I've been teaching introductory programming in Pharo for the last three semesters and starting my fourth. I was wondering whether anyone else is doing that. I've put quite a bit of effort into it and would be willing to share my materials if anyone was interested. For instance, I've created a few little MicroWorlds for beginners to use (jumping directly into the browser is too difficult for complete programming novices). One is for doing turtle graphics. I've gone ahead and shared that for Pharo 2.0. You can get it in the Configuration Browser under the name EduTech. If you have some interest, let me know and I'll see what I can do. Cheers, Jeff -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick

3 2

recovering from a deep disc crashâ¦.
by StÃ©phane Ducasse Oct. 19, 2013

Oct. 19, 2013

so backup your machineâ¦ because mine was still working at 8h this morning and 8h40 dropped dead

7 9

Is there a Roadmap for Pharo 3.0 and Pharo 4.0
by kilon Oct. 19, 2013

Oct. 19, 2013

I really like the idea of roadmap. In an open source project people are free to work in anything they like , even bring new nice features of their design as long as they don't disturb the existing code. But the same people, including me, or even mere users , wonder where the software is heading. Even an exploration ship , that sets to explore new areas has goals. I would like to see in the pharo website a roadmap not just for 3 but even for pharo 4. I know that Stephane has given a presentation about pharo 3 roadmap , maybe you could link those slides. So what is the future of pharo ? Another request for the website would be a small collection of bullet points about what makes Pharo special, in the about section there is a very general description of what pharo is. I would like something more concrete. I want specific features, specific libraries. Assume that people reading this have no idea what smalltalk is and no idea what Squeak is. 10-30 bullet points should be a good start. No lengthy descriptions, straight to the point. What you feel about this ? -- View this message in context: http://forum.world.st/Is-there-a-Roadmap-for-Pharo-3-0-and-Pharo-4-0-tp4714… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

6 13

Re: [Pharo-dev] enclosing compile errors & <PrintIt> in double quotes
by Camillo Bruni Oct. 19, 2013

Oct. 19, 2013

That is the first step :), if you have a decent text editor, you could add a real print-it or do-it token, which is not regarged as source code, but just as meta information. I think we could quite easily do this in Amber right now ;). But yes, why not, sounds like a reasonable idea to put print-its and compilation errors in double quotes. On 2013-10-18, at 14:59, btc(a)openinworld.com wrote: > > Just a random idea flitting thought my mind... When trying to <Accept> some code with an error in it, the error message gets inserted into the code such that it screws up syntax highlighting and also you need to use <Undo> to remove it. I wonder if the error might be inserted between double-quotes making it a comment. The same could be said for if you <PrintIt> from a debugger. It seems such a simple and obvious idea that I presume its been considered before and there are good reasons not to do it. I am curious what others think might be the pros/cons of it. > In the case of <PrintIt> one benefit might be that the code could still be saved, with the result left as a kind-of example. This might be good for temporary code development in a Workspace. > > cheers -ben >

3 2

Mac VM Maintainer resignation (for the general purpose VM, not for PharoVM)
by Esteban Lorenzano Oct. 18, 2013

Oct. 18, 2013

Hi, This is an announce for VM-dev and Squeak-dev list, Pharo-dev list is copy to keep people informed. Last years I tried to keep a working version of the Mac builds of VM while at the same time trying to keep my job going. It was a hard work but I did my best. When I assumed the responsibility I said that my first task was going to be to automatize the builds and at the same time Igor was doing the same so I joined that effort. Since then the VM is buildable even by the not so good at VM level and I never seen the point in keeping the manual build or the non-smalltalk-generated configuration files. Nevertheless, I preferred to work on the new builds of Eliot than in the old interpreter and when keeping all working became more work that what I could manage, I choose to keep Stack and Cog VM working. Maybe because of that, or because the animosity between communities, or because what I'm doing just does not match Squeak vision, or because since Eliot is providing regular builds mine are not needed, truth is that I've seen my work mostly ignored in squeak community and for some of the people in vm-dev list. That's why I resign as a maintainer. I have a process that does not match squeak vision and is fair for squeak community to look for someone who does. I have no bad feelings, I'm complete grateful to the community for give me the opportunity (specially to John, who thrusted me) and to all the rest. I also know that there is great people both in vm-dev and in squeak-dev, but I cannot your mac-guy anymore (and I think this is obvious since ever). And of course I will continue working in the pharo flavor of VM :) Cheers, Esteban

2 1

Second Scheduler migration from SqS to STHub
by Torsten Bergmann Oct. 18, 2013

Oct. 18, 2013

Hi Hernan, I've seen that you now registered "TaskScheduler" on STHub with the Scheduler code on STHub. But the "Scheduler" project was already migrated to SmalltalkHub, together with a config and documented STHub page: http://smalltalkhub.com/#!/~TorstenBergmann/Scheduler and it is available also in the config browser for Pharo 2.0 since a long time. No need for duplicated effort... Is there a reason you provide it a second time? May I kindly ask that you remove your second copy to avoid confusion. Thanks Torsten

2 1

Fwd: Generators implemented only with blocks
by Francisco Garau Oct. 18, 2013

Oct. 18, 2013

Hi As an exercise, I've implemented a simple Generator using only blocks: gen := [ [ | currentValue | Array with: [ currentValue := 0 ] with: [ currentValue := currentValue + 1 ] ] value ] value. gen first value. next := [:a | a last value]. getTen := [(1 to: 10) collect: [ :i | next value: gen ]]. getTen value = #(1 2 3 4 5 6 7 8 9 10). getTen value = #(11 12 13 14 15 16 17 18 19 20). There have been some funny arguments in the past whether Blocks are a fundamental part of Smalltalk or not. My code above supports Vassili's view that we could get rid of Objects and implement everything in terms of Blocks. http://live.exept.de/doc/online/english/programming/humor.html But more seriously, I find it quite interesting that Lars Bak choose not to implement Blocks for his Resilient Smalltalk. He choose to implement LIFO blocks; that is, blocks that cannot survive the creating activation context (see chapter 2.3 for more details). http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.84.7354&rep=rep1&t… - Francisco

3 5

[pharo-project/pharo-core]
by GitHub Oct. 18, 2013

Oct. 18, 2013

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

1 0

[pharo-project/pharo-core] 3ab076: 30500
by GitHub Oct. 18, 2013

Oct. 18, 2013

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 3ab0764a1658214c915a01509eaaf9aec8e78b17 https://github.com/pharo-project/pharo-core/commit/3ab0764a1658214c915a0150… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-10-18 (Fri, 18 Oct 2013) Changed paths: M Collections-Abstract.package/SequenceableCollection.class/instance/splitjoin/joinUsing_last_.st M CollectionsTests.package/SplitJoinTest.class/instance/running/testJoinUsingLastOnArray.st M MenuRegistration.package/PragmaMenuBuilder.class/instance/menu building/buildTree.st M Morphic-Base.package/ImageMorph.class/instance/geometry/extent_.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script155.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30500.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Inspector.package/EyeMorphViewer.class/class/spec/inspectorSpec.st M Spec-Inspector.package/EyeMorphViewer.class/instance/accessing/container.st M Spec-Inspector.package/EyeMorphViewer.class/instance/event-handling/objectChanged.st A Spec-Inspector.package/EyeMorphViewer.class/instance/initialization/initializePresenter.st R Spec-Inspector.package/EyeMorphViewer.class/instance/initialization/initializeWidgets.st A Spec-Inspector.package/EyeMorphViewer.class/instance/initialize/initialize.st A Spec-Inspector.package/extension/ImageMorph/instance/resize_.st Log Message: ----------- 30500 11835 Cannnot revert <Make uncloseable> https://pharo.fogbugz.com/f/cases/11835 11924 Resize the morph while inspecting it https://pharo.fogbugz.com/f/cases/11924 11915 #joinUsing:last: incorrect for single item collection https://pharo.fogbugz.com/f/cases/11915 http://files.pharo.org/image/30/30500.zip

1 0

[regression reporter]regression occurred
by no-reply＠ci.inria.fr Oct. 18, 2013

Oct. 18, 2013

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation-M-Z/labe… 1 regressions found. Tests.Release.ReleaseTest.testLocalMethodsOfTheClassShouldNotBeRepeatedInItsTraits

1 0