- Pharo-dev - lists.pharo.org

[Pharo-project] The Keys to the Kingdom
by Sean P. DeNigris Aug. 31, 2011

Aug. 31, 2011

This incredible piece of feedback was hiding at http://code.google.com/p/pharo/wiki/HowToContribute . We should all have this pinned to the wall behind our computer: Sometimes I make some "exercise" on Smalltalk/Squeak for the fun, sometimes I try to build tools in Squeak to solve some practical problem or personal need. I'm not a programmer, just a curious guy, completely ignorant about programming, who, some years ago, found Smalltalk/Squeak to be the only human programming language I could cope with. But every time I try to do something with Squeak I stumble on this inevitable conclusion: it is one of the most entropic things I ever met in my life. The reason for this may lay partly on structural reasons - I wouldn't know, because I'm an ignorant, as I stated before. But there is a second reason I know for sure: the owners' and contributors' inability to step out of the developer's perspective, to put a distance towards themselves (and towards the result of their work). As a result, Squeak is probably the worst documented language in the world. Documentation and comments on the code are completely entropic, self-centered, tautological; it is experts talking to all-knowing experts - like those stupid old-fashioned dictionaries where every word definition tends to be built with the defined word. Until now I had a look to Pharo system browser only for a few minutes, but that was enough for me to get the impression that you are trying to get over this dreadful limitation, to jump over the limits of an strictly enclosed community, rehearsing new tentative styles to comment code and classes. If I got it right and this is true, congratulations and thank you very much for your effort. -- View this message in context: http://forum.world.st/The-Keys-to-the-Kingdom-tp3780556p3780556.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

4 4

[Pharo-project] Symbol>value:
by niko.schwarz＠googlemail.com Aug. 31, 2011

Aug. 31, 2011

Hi, Symbol responds to #value:, but not to #value:value:. At some point, Symbol and Block were decided to have the invocation protocol in common. I find this great. Therefore, I think, Symbol should also respond to #value:value:, as follows: value: anObject value: anotherObject ^ anObject perform: self with: anotherObject Of course, it should also respond to #value:value:value: and #value:value:value:value: Niko -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41786126354

13 22

[Pharo-project] The Keys to the Kingdom
by Torsten Bergmann Aug. 31, 2011

Aug. 31, 2011

Yes, and I think these special thanks are addressed to Stef and Laurent. Stef started with the idea not to include code that is not documented - which was a little bit unrealistic but lead to Laurents idea of a "Comment of the day" game. The archive is your friend: http://lists.gforge.inria.fr/pipermail/pharo-project/2011-February/041356.h… Looks like we should continue to play this game ;) Bye T. -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurÃ¼ck-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone

3 2

[Pharo-project] Please comment: Issue 4725: extend the string protocol
by Torsten Bergmann Aug. 31, 2011

Aug. 31, 2011

Stef wrote >hence I would like to introduce some extensions: > >- chomp (ruby like) #chomp is not a very intention revealing name. What about #withoutTerminatingNewline Bye T. -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurÃ¼ck-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone

1 0

[Pharo-project] Please comment: Issue 4725: extend the string protocol
by StÃ©phane Ducasse Aug. 31, 2011

Aug. 31, 2011

http://code.google.com/p/pharo/issues/detail?id=4725 I always feel a bit lost when using string manipulation in pharo... hence I would like to introduce some extensions: - chomp (ruby like) - #padLeft: #padRight: (as a replacement for the broken padded:to:with:) - #copyFrom:to: extensions with several specialized methods (the classical way would be to support negative indices, but this will most likely break existing tools) camillo could you illustrate your request. Some tests would be the ideal way to describe them.

1 0

[Pharo-project] Addition to "About Pharo" dialog
by GermÃ¡n Arduino Aug. 31, 2011

Aug. 31, 2011

Hi Guys: Is just me that think that is useful to have the VM version at hand (may be in the "About Pharo" dialog)? In my case, using different computers, and having differents vm's is so useful and I added a little code to have this info in such Dialog. If may be of interest I cand send a slice. Let me know. Cheers. -- ================================================= GermÃ¡n S. ArduinoÂ <gsa @ arsol.net>Â Â Twitter: garduino Arduino Software & Web HostingÂ Â http://www.arduinosoftware.com PasswordsProÂ http://www.passwordspro.com =================================================

11 29

[Pharo-project] Deprecation policy
by Sean P. DeNigris Aug. 31, 2011

Aug. 31, 2011

I want to add a comment to #deprecated:on:in: This is my understanding (it is implemented inconsistently in 1.4 update #14112): For methods: 1. Have the method call deprecated:on:in: as its first step - the versionString should be e.g. 'Pharo1.4' (although I found #Pharo1.4, see the problem; and '1.4', those were mine, hee hee). Is it redundant to say 'PharoXxx'? 2. Move the method to protocol e.g. deprecated14 for Pharo 1.4 For classes: 1. Move to Category e.g. 'Deprecated14' for Pharo 1.4 2? Should #deprecated:on:in: be called from the methods? It's inconsistent in the image and seems unnecessary, except maybe for some class-side methods. Is all this correct? Thanks. Sean -- View this message in context: http://forum.world.st/Deprecation-policy-tp3777647p3777647.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

3 6

[Pharo-project] Redirect CI link
by Torsten Bergmann Aug. 30, 2011

Aug. 30, 2011

Anyone able to redirect "http://ci.pharo-project.org" from old hudson https://pharo-ic.lille.inria.fr/hudson/ to new Jenkins https://ci.lille.inria.fr/pharo/ Would also be nice if "bugs.pharo-project.org" would point to the issue tracker as well (similar to "issues.pharo-project.org") Thanks T. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

1 0

[Pharo-project] Pharo 1.3 and 1.4 status update
by laurent laffont Aug. 30, 2011

Aug. 30, 2011

Here's a Pharo status update: http://www.pharo-project.org/news Please review. Laurent Laffont - @lolgzs <http://twitter.com/#!/lolgzs> Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/ Developer group: http://cara74.seasidehosting.st

1 0

[Pharo-project] Why MC when you copying a package doing too much things?
by Igor Stasenko Aug. 30, 2011

Aug. 30, 2011

If you look how MC copies package from remote repository to package-cache dir, you will find out , that it: - reads and parses all definitions from source package - and then writes all these definitions into a new file while instead it could just simply copy the contents of existing file to the directory and that's it. This actually explains why uploading VMMaker to squeaksource takes ages (and most of the times time outs), simply because on server we have this unnecessary load of read-deserialize-serialize-write cycle while it could be just read-write (copying). I think we could make it faster by copying and then parsing only the necessary parts of package, like commit log and ancestry information, but not parsing the whole package contents. Another approach is of course to split bloated VMMaker package into parts.. but the problem is that for building VMs there's already too many stuff there.. for example look at the configuration of cog: package: 'FFI-Pools' with: 'FFI-Pools-eem.3'; package: 'SharedPool-Speech' with: 'SharedPool-Speech-dtl.2'; package: 'Balloon-Engine-Pools' with: 'Balloon-Engine-Pools-JB.2'; package: 'Alien-Core' with: 'Alien-Core-IgorStasenko.68'; package: 'Sound' with: 'Sound-StephaneDucasse.62'; package: 'VMConstruction-Plugins-OSProcessPlugin' with: 'VMConstruction-Plugins-OSProcessPlugin.oscog-eem.31'; package: 'Freetype-Plugin' with: 'Freetype-Plugin-IgorStasenko.61'; package: 'ObjectiveC-Plugin' with: 'ObjectiveC-Plugin-John M McIntosh.20'; package: 'Cog' with: 'Cog-eem.45'; package: 'VMMaker-oscog' with: 'VMMaker-oscog-IgorStasenko.122'; package: 'Qwaq-VMProfiling-Plugins' with: 'Qwaq-VMProfiling-Plugins-JB.5'; package: 'Applescript-Core' with: 'Applescript-Core-SeanDeNigris.2'; package: 'CMakeVMMaker' with: 'CMakeVMMaker-IgorStasenko.136' ]. but i think we can deal with it nicely. Anyways, i think we should consider splitting VMMaker, because it goes nowhere. For Cog VMMaker , i think we could remove an Interpreter class, which can make a package like 20% smaller, without any need of refactoring and dependency rewiring. -- Best regards, Igor Stasenko AKA sig.

1 0