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

Character>>#leadingChar

by Sven Van Caekenberghe

Hi, So once again we have an issue with Character>>#leadingChar, see https://pharo.fogbugz.com/f/cases/6368 Do we really need this ? Any Japanese, Chinese or Korean users willing to comment ? Thx, Sven

Oct. 18, 2013

new validation reports

by Camillo Bruni

1.5 h train delay resulted in a productive personal mini sprint :P, the monkey reports now a twitter bootstrap styled page with lots of useful information: https://ci.inria.fr/pharo/job/Pharo-3.0-Issue-Validator/905//artifact/valid… now I will see how it behaves with the most common validation problems :)

Oct. 18, 2013

Re: [Pharo-dev] Second Scheduler migration from SqS to STHub

by HernÃ¡n Morales Durand

Hi Torsten, Yes, I didn't see it because I was searching by class name. Now I have removed the second copy from the repository. Thanks for the advice, HernÃ¡n 2013/10/18 Torsten Bergmann <astares(a)gmx.de> > 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 >

Oct. 18, 2013

Anyone else teaching programming in Pharo?

by J.F. Rick

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

Oct. 18, 2013

Re: [Pharo-dev] Generators implemented only with blocks

by Francisco Garau

On 18 Oct 2013, at 08:55, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 18.10.2013 um 09:35 schrieb Francisco Garau <francisco.garau(a)gmail.com>: > >> Hi - >> >> On 18 Oct 2013, at 06:54, Norbert Hartl <norbert(a)hartl.name> wrote: >> >>> Why not just >>> >>> gen := [ | current | >>> current := 0. >>> [ current := current + 1 ] ] value. >>> >> >> Much concise indeed. But I am trying to have several generators instantiated from the same block definition and be able to set their initial values to any number. Just for fun, of course. >> > genGen := [ : initial | | current | > current := initial. > [ current := current + 1 ] ]. > > gen := genGen value: 10. > gen2 := genGen value: 50. > > (1 to: 10) inject: OrderedCollection new into: [ :col :elem | > col add: gen value. > col add: gen2 value. > col ] Very nice! I also wanted to reset their values at any time. That's why I had to return blocks to initialise and provide the next value. > Norbert > >>> >>> I think there is two sides of using blocks. One is the ability to carry some code around which is a useful thing. The other one is that encloses over the current environement. The latter is something that you can use for quite powerful stuff. But it is also something people have problems to understand and that can easily introduce problems in code because you didn't think of what it does. >>> Just remember the last problem with announcements that was caused by blocks. So blocks are to me like a lot of other programming techniques: If you don't really need them don't use them. >>> >>> Norbert >>> >>> Am 18.10.2013 um 00:46 schrieb Francisco Garau <francisco.garau(a)gmail.com>: >>> >>>> 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 >>>> >>> >

Oct. 18, 2013

Re: [Pharo-dev] enclosing compile errors & <PrintIt> in double quotes

by Camillo Bruni

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 >

Oct. 18, 2013

Re: [Pharo-dev] recovering from a deep disc crashâ¦.

by Igor Stasenko

On 18 October 2013 12:52, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > Igor, > your hardware never failed? > It must be some special brand crafted in former soviet union ;) > > well, sure i had problems with it, but not at cost of total data loss. couple times its keyboard, mouse, once it was monitor and once is motherboard, but never the hard drive :) > 2013/10/18 Igor Stasenko <siguctua(a)gmail.com> > >> thankfully, i never had problems with hardware: it serves me well. >> But still didn't prevented from losing precious data: the humans who >> break into my apartment and stole the machine, >> with all data it has :( >> >> >> >> On 18 October 2013 11:18, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >> >>> I remember trying to recover mail folders by reading the blocks on disk >>> one by one with a binary editor... >>> >>> Ended learning far too much about the internal layout of an ext2 >>> filesystem. >>> >>> But dead harddrive is nice in one way: you don't loose time trying to >>> recover stuff, you know it's dead :( >>> >>> Thierry >>> >>> Le 17/10/2013 23:10, StÃ©phane Ducasse a Ã©crit : >>> >>> so backup your machineâ¦ because mine was still working at 8h this >>>> morning and 8h40 dropped dead >>>> >>>> >>>> >>>> >>> -- >>> Thierry Goubier >>> CEA list >>> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >>> 91191 Gif sur Yvette Cedex >>> France >>> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >>> >>> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- Best regards, Igor Stasenko.

Oct. 18, 2013

Second Scheduler migration from SqS to STHub

by Torsten Bergmann

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

Oct. 18, 2013

Mac VM Maintainer resignation (for the general purpose VM, not for PharoVM)

by Esteban Lorenzano

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

Oct. 18, 2013

[pharo-project/pharo-core]

by GitHub

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

Oct. 18, 2013