March 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] running pharo on iPad
by David Li March 2, 2010

March 2, 2010

Well, I have tried the Pharo-iPhone tree under 3.2 simulator. It works. I am working on making it work with iPad's native resolution. Due to the NDA of that dev kit, I can't really talk much here. Anyone interested in this, please contact me in private message. I do need help in figuring out the canvas drawing codes in the Pharo-iPhone. My goal is to get Scartch to run on this. ;) David

1 0

[Pharo-project] Linux clipboard
by Pavel Krivanek March 2, 2010

March 2, 2010

In Pharo 1.1 the clipboard doesn't work on Linux VM (because of fix of Issue 1793: Remove SqueakClipBoard). Alain replaced SqueakClipboard with ExternalClipboard as default OSPlatform clipboardClass. The ExternalClipboard class requires VM with ClipboardExtendedPlugin. The default clipboard class should be Clipboard. Cheers, -- Pavel

3 3

[Pharo-project] obsolete classes in 11239
by Pavel Krivanek March 2, 2010

March 2, 2010

There are some Undeclared and obsolete classes in the image #11239. This cleans it: Locale classPool at: #LocaleChangeListeners put: OrderedCollection new. SmalltalkImage current fixObsoleteReferences. Smalltalk cleanOutUndeclared. -- Pavel

2 1

[Pharo-project] O2 now loads in Pharo Core 1.1
by Alexandre Bergel March 2, 2010

March 2, 2010

I just wanted to announce this :-) Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

2 2

Re: [Pharo-project] Scamper revival
by Schwab,Wilhelm K March 2, 2010

March 2, 2010

First, I'm not using Squeak. Second, this is not the first time I've heard that xyz was going to wipe out Smalltalk's place in the world, and I doubt it will be the last. Bill -----Original Message----- From: Eagle Offshore [mailto:eagleoffshore@mac.com] Sent: Monday, March 01, 2010 12:09 AM To: Schwab,Wilhelm K Subject: Re: [Pharo-project] Scamper revival Then what are you doing with Squeak? :-) The browsers support offline development with local databases in HTML 5. This is here, now. They will replace squeak's mission in about another three years. Probably less. On Feb 28, 2010, at 12:04 PM, Schwab,Wilhelm K wrote: > There is the further concern about the browser. It wastes screen space (which is at a premium) and adds weight and distracting functionality. There is something to be said for the a fat client app that does what it needs to do and nothing else. > > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of > Eagle Offshore > Sent: Sunday, February 28, 2010 2:23 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Scamper revival > > I wouldn't be so sure. > > http://html5demos.com/ > http://jqtouch.com/ > > On Feb 27, 2010, at 4:41 PM, Schwab,Wilhelm K wrote: > >> there is no way in hell that HTML+CSS+JavaScript is going to keep up > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

3 3

[Pharo-project] Packages remodularization
by Torsten Bergmann March 2, 2010

March 2, 2010

> We can use dashes in package names, however it's a little bit > confusing and Monticello cannot process it well if one package has > shorter name, for example Announcements and Announcements-View Yes. But to remain consistent with most projects on SqS I would like to go the "use a Core" and "use dashes" way to provide: MyPackage-Core MyPackage-Example MyPackage-Tests MyPackage-Help Using only "MyPackage" would help to package the code of a whole project (so we can see this bug as a feature). It will be irrelevant with better package tools anyway. Using a dash would also make a clear distinction between a "Announcement-View" (package) and a possible class "AnnouncementView" if you see it written in a book or tutorial. Bye Torsten -- GMX DSL: Internet, Telefon und Entertainment fÃ¼r nur 19,99 EUR/mtl.! http://portal.gmx.net/de/go/dsl02

1 0

[Pharo-project] Q: is there a way to get the classes referenced by a class?
by Esteban Lorenzano March 2, 2010

March 2, 2010

Hi, I'm trying to get a "dependency map" of a certain project (playing with pavel's kernel image, I'm trying to figure out how to feed it with all needed dependences). What I'm doing now is very inneficient (usign #allCallsOn and reversing the search), and I'm sure there should be something better... Thanks, Esteban

4 7

[Pharo-project] Call for fixing the network problem
by Adrian Lienhard March 1, 2010

March 1, 2010

To release Pharo 1.0, we need to fix the network problem: http://code.google.com/p/pharo/issues/detail?id=1884 Anyone volunteers to help? I can allocate some time but would welcome if somebody would team up to get rid of this issue. Cheers, Adrian ___________________ http://www.adrian-lienhard.ch/

4 4

[Pharo-project] about code formatting in pharo
by stephane ducasse March 1, 2010

March 1, 2010

Hi guys I would like to build a set of canonical code formatting convention for Pharo. I need your help. Now take time before replying :) I would like to structure the discussion and proceed step by step. So at max I would like to discuss one or two formatting approach per mail. Once we agree I would like to define a wiki page. **Space after : rule ============= for example I would like to always have a space after a : classes := Smalltalk allClasses select:[:aClass| (aClass class includesSelector: #cleanUp) or:[aClass class includesSelector: #cleanUp:] ]. -> classes := Smalltalk allClasses select: [:aClass| (aClass class includesSelector: #cleanUp) or: [aClass class includesSelector: #cleanUp:] ]. **Block arg rule ============= Do we want a space before and after block arg Smalltalk allClasses select: [:aClass :method| -> Smalltalk allClasses select: [ :aClass :method | ** selector or block indented compared to receiver ======================================= Finally do we follow kent block ideas? classes := Smalltalk allClasses select: [:aClass| (aClass class includesSelector: #cleanUp) or: [aClass class includesSelector: #cleanUp:] ]. -> classes := Smalltalk allClasses select: [:aClass| (aClass class includesSelector: #cleanUp) or: [aClass class includesSelector: #cleanUp:]]. Stef

8 42

Re: [Pharo-project] about code formatting in pharo
by Dale Henrichs March 1, 2010

March 1, 2010

Stef, I really like formatters, but as the discussion has already shown, there isn't one format that fits everyone's definition of beauty/readability. Personally I am willing to use any formatter that saves me from having to hand edit code for format, but I think I am in the minority. Presumably the formatter can be configured to produce different output formats ... if the format operation avoided dirtying the method, then supporting multiple formats would be less onerous ... I can reformat a method in my image using my formatter so that I can read someone else's code is pretty useful...Along the same line, having Monticello use the canonical formatter to format code when writing out mcz files would eliminate format issues for saved mczs (note that for source code comparison in Monticello, the canonical formatter should be used on both strings), finally it might make sense to format code on read, so that noone will ever have to know that their chosen format is not the canonical one:) ... Just some thoughts that might minimize the impact of "format wars"... Dale ----- "stephane ducasse" <stephane.ducasse(a)free.fr> wrote: | Hi guys | | I would like to build a set of canonical code formatting convention | for Pharo. | I need your help. Now take time before replying :) | I would like to structure the discussion and proceed step by step. So | at max I would like to discuss one or two formatting approach per | mail. | Once we agree I would like to define a wiki page. | | | **Space after : rule | ============= | for example I would like to always have a space after a : | | classes := Smalltalk allClasses select:[:aClass| | (aClass class includesSelector: #cleanUp) | or:[aClass class includesSelector: #cleanUp:] | ]. | | -> | | | classes := Smalltalk allClasses select: [:aClass| | (aClass class includesSelector: #cleanUp) | or: [aClass class includesSelector: #cleanUp:] | ]. | | | **Block arg rule | ============= | Do we want a space before and after block arg | | Smalltalk allClasses select: [:aClass :method| | | -> Smalltalk allClasses select: [ :aClass :method | | | | ** selector or block indented compared to receiver | ======================================= | | Finally do we follow kent block ideas? | | classes := Smalltalk allClasses select: [:aClass| | (aClass class includesSelector: #cleanUp) | or: [aClass class includesSelector: #cleanUp:] | ]. | | -> | classes := Smalltalk allClasses | select: [:aClass| (aClass class includesSelector: #cleanUp) | or: [aClass class includesSelector: | #cleanUp:]]. | | Stef | _______________________________________________ | Pharo-project mailing list | Pharo-project(a)lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

4 8