December 2009 - Pharo-dev - lists.pharo.org

[Pharo-project] Let's hire a Pharo developer

by alesch

I'm new in the Smalltalk community, and even newer in Pharo. If the following has been discussed before, I have not found it in the archives. What do you think about hiring a developer to work exclusively and full time on Pharo? At ESUG'09 there were about 250 people, and Smalltalks'09 had about the same number of attendees. 100 people paying â¬10/month yields â¬1000/month. I'm not sure, but I think that it is a good salary in Argentina. Let's take advantage (in the good sense) of the vibrant Smalltalk community in Argentina, and the actual state of the euro/peso. For europeans, â¬10 is about two beers. Make it an automatic withdrawal, so once you've taken the desition, you never think about again. I'm the first one in the list. Who else? -- View this message in context: http://n2.nabble.com/Let-s-hire-a-Pharo-developer-tp4161222p4161222.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 13, 2009

[Pharo-project] SystemVersion 1.1 Part 2

by Michael Roberts

http://code.google.com/p/pharo/issues/detail?id=1566 I have uploaded to PharoInbox an upgrade for SystemVersion so that the various images can be better aware of their version state. After the upgrade SystemVersion current type --> #PharoCore major --> 1 minor --> 1 suffix --> ALPHA Then the Pharo build script needs SystemVersion current type: #Pharo I didn't want to make it too complicated. It is also backwards compatible with the old API until the deprecation is thought through. The idea of doing this is to make automated image building and testing a little easier. thanks, Mike

Dec. 13, 2009

[Pharo-project] FAME: support for multiple inheritance?

by alesch

Hello list: Does FAME supports mutltiple inheritance? I guess the answer is NO, but I thought I would ask to be sure. The scenario is a description language that today is implemented as 4 UML profiles, on top of each other. This profiles are then realized with Eclipse EMF (ecore), and Java. Quite a heavy framework for prototyping, =) I'm evaluating the possibility of replacing this stack with FAME. Thanks in advance! -- View this message in context: http://n2.nabble.com/FAME-support-for-multiple-inheritance-tp4161084p416108… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 13, 2009

Re: [Pharo-project] package documentation viewer

by Lukas Renggli

> Is there another search string or way to detect other empty comments? Smalltalk allClasses select: [ :class | class organization classComment isEmpty ] Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 13, 2009

Re: [Pharo-project] package documentation viewer

by csrabak＠bol.com.br

Em 09/12/2009 21:30, Simon Denier <Simon.Denier(a)inria.fr> escreveu: > On 9 dÃ©c. 2009, at 19:11, csrabak(a)bol.com.br wrote: > > I also vote for having it running at Pharo website. > > However it gives another opportunity to my canvassing: it is > > imperative that the comments written (class and methods) be > > accurate and uptodate!! > > Can someone quickly run some query to see how bad it is? That is, > how many classes without comment or with the generic template? > I ran the following script in the Workspace: nocomments := Smalltalk allClasses select: [:c | c comment string prefixMatchesRegex: '. [A-z]+ is x+\.$']. The results in the images I have are: +--------+------+------+ |Image |update|result| +--------+------+------+ |1.0-dev | 10502| 954| +--------+------+------+ |1.1-core| 11097| 613| +--------+------+------+ | 1.1-dev| 11097| 967| +--------+------+------+ Doing the same exercise with a bloc [:c| c comment string isEmpty] returns no class. Is there another search string or way to detect other empty comments? -- Cesar Rabak

Dec. 13, 2009

Re: [Pharo-project] Keyboard Shortcuts in Pharo?

by StÃ©phane Ducasse

thanks for the pointer. Note also that we should get the textEditor done in CUIS and integrated in squeak. Stef On Dec 13, 2009, at 6:35 PM, Benjamin Pollack wrote: > On Fri, Dec 11, 2009 at 2:44 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > Safara was an attempt to implement a replacement for the current text > editor, where nothing was hardcoded but everything could be configured > by the tool (highlighting, completing, shortcuts, ...). Unfortunately > this project never made it into a useable state. Writing a text editor > is difficult. > > > I hadn't heard of Safara, but SVI (http://map.squeak.org/package/ab5ae6be-b705-40a2-8d63-a992442086ec) is (in my opinion) a very successful attempt at modernizing the editor. It comes with vim- and Emacs-like keybindings, which include shortcuts for selecting and navigating through blocks, paren groups, messages and the like--exactly what we're talking about here. It doesn't run on Pharo or trunk Squeak, but it worked just fine in heavy use for me on Squeak ~3.6 through 3.9. I don't have the time to make it run on Pharo right now, but I doubt someone with sufficient motivation would have that much of a problem getting it running comfortably. If I recall correctly, the main effort was going to be updating the OmniBrowser integration. > > --Benjamin > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 13, 2009

[Pharo-project] Fwd: [ANN] Mason 1.0

by Lukas Renggli

---------- Forwarded message ---------- From: Colin Putney <cputney(a)wiresong.ca> Date: 2009/12/13 Subject: [squeak-dev] [ANN] Mason 1.0 To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> Hi folks, As I mentioned yesterday, here's the release version of Mason, a Squeak build system. It relies on OSProcess to build images, but it should be possible to build other artifacts, such as directory trees, zip files, SAR files etc without OSProcess. The download is available here: http://www.wiresong.ca/downloads/Mason-1.0.0.sar There's no documentation yet, but I've pasted below a brief description that I sent to the Pharo folks a little while ago. Cheers, Colin --- The core model is a hierarchy of targets. Targets represent the artifacts that Mason can produce, such as files, directories, images, packages etc, and the hierarchy represents the desired state, which Mason will work to create. There's a Canvas-like API for creating target hierarchies, and Products are objects that know how to specify targets using that API. A Product is an abstract thing, which represents a high-level concept such as "the latest version of a given package" or "the HTML documentation for a project." The role of a Product is to reduce that abstraction to a set of concrete targets which it specifies using the canvas API. A Product probably has to examine the environment to decide what targets to specify - it might scan a repository to determine the latest version of a package or scan a directory of creole files to determine which HTML files need to be generated. Given a target hierarchy, Mason can generate a Build. A Build contains a number of jobs, which collectively create the artifacts specified by the targets. Jobs essentially MethodObjects, and each do small amounts of work. The Build is responsible for running the jobs and managing dependencies between them. The build runs the jobs in parallel where possible, and since many jobs involve IO or spawning other processes via OSProcess, so there's actually a pretty decent performance advantage. Those are the broad outlines. There's a few issues here still, both architectural and with the current implementation. One is that building a target tree may be an unnecessary intermediate step. It would feasible to have targets just be transient entities the way TagBrushes are in Seaside - Products would specify a Build directly. Another is that I haven't tried to do any optimization along the lines of make - everything is built fresh every time. The targets -> build converter could try to examine the disk and see if it could avoid building things that are already up to date. I have an idea to address both these issues by having a step that walks over the target tree and optimizes it before the Build is created. This could involve identifying and merging common intermediate steps, and then doing the make trick of eliminating any targets that already exist and are up-to-date. For now though, I've been quite happy with even the unoptimized version. I've used it to build distribution SAR archives for OB, MC2 and Filesystem, development images, load-order and package dependency testing etc.

Dec. 13, 2009

Re: [Pharo-project] Keyboard Shortcuts in Pharo?

by Lukas Renggli

> I hadn't heard of Safara, but SVI > (http://map.squeak.org/package/ab5ae6be-b705-40a2-8d63-a992442086ec) is (in > my opinion) a very successful attempt at modernizing the editor. It is a hack on top of the Pluggable Morphic editor, that is a hack on top of the Morphic editor, that is a hack on top of the MVC editor, that is a hack on top of the original Smalltalk-80 editor. No joke. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 13, 2009

Re: [Pharo-project] Keyboard Shortcuts in Pharo?

by Bart Gauquie

Hi Adrian, Thanks for adding me. I will try to write something during the week. Kind Regards, Bart On Sun, Dec 13, 2009 at 12:39 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Hi Bart, > > This sounds like a good plan! > > I added you as a project committer, which should give you write access > to the wiki. > > Cheers, > Adrian > > On Dec 13, 2009, at 04:58 , Bart Gauquie wrote: > > > All, > > > > Looking at all the responses, it looks to me we should do the > > following > > things: > > > > - Check at the list ( > > > http://lists.gforge.inria.fr/pipermail/pharo-project/2009-December/017196.h… > ) > > of shortcuts Mariano Martinez Peck already provided. Put it on the > > wiki as a > > WorkInProgress. See which ones are still valid, see which ones can > > be > > removed, ... > > - Create a wiki document which outlines the changes we want to > > make to > > the window changing, code selecting, refactoring behaviour I > > suggested. I > > take the liberty to humbly suggest my initial list of behaviour as a > > starting point for this? > > - Point out who is doing what ... > > > > I'm not sure how new enhancements are discussed on this list. My > > suggestion > > is to create a wiki document which serves as a working document, and > > so > > always displays the latest up to date info. Discussions about it are > > done on > > the mailing list and decisions 'committed' to this doc. > > I'll be happy to create this pages, but don't seem to have the > > rights to > > create a new page on the wiki. > > > > Kind Regards, > > > > Bart > > -- > > imagination is more important than knowledge - Albert Einstein > > Logic will get you from A to B. Imagination will take you everywhere - > > Albert Einstein > > Learn from yesterday, live for today, hope for tomorrow. The > > important thing > > is not to stop questioning. - Albert Einstein > > The true sign of intelligence is not knowledge but imagination. - > > Albert > > Einstein > > Gravitation is not responsible for people falling in love. - Albert > > Einstein > > _______________________________________________ > > 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 > -- imagination is more important than knowledge - Albert Einstein Logic will get you from A to B. Imagination will take you everywhere - Albert Einstein Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning. - Albert Einstein The true sign of intelligence is not knowledge but imagination. - Albert Einstein Gravitation is not responsible for people falling in love. - Albert Einstein

Dec. 13, 2009

Re: [Pharo-project] getting rid of Symbol >> new: ?

by Mariano Martinez Peck

On Thu, Dec 10, 2009 at 3:32 AM, Martin McClure <martin(a)hand2mouse.com>wrote: > Sheridan Mahoney wrote: > > > Martin and I had been working towards the idea that ImageSegments should > > never create non-Canonical symbols, and the user should not have to use > > manual techniques to preserve symbols they are interested in keeping > alive. > > > > I ended up getting stuck however, in trying to discover what process > > ImageSegment > > goes through while it is installing objects - ImageSegment #install has > a > > call to an > > unimplemented method #readFromFileWithSymbols which it seems it should > be > > using, but isn't....(wha' the?) > > > > > > install > > "This operation retrieves the segment if necessary from file > storage, > > installs it in memory, and replaces (using become:) all the root stubs > with > > the reconstructed roots of the segment." > > > > | newRoots | > > state = #onFile ifTrue: [self readFromFile]. > > state = #onFileWithSymbols ifTrue: [self readFromFileWithSymbols. > > My guess (and only a guess) is that #onFileWithSymbols never becomes a > state in the test case that's failing. > > Even more...#onFileWithSymbols becomes as state in the method writeToFileWithSymbols But, look the first line of this method: writeToFileWithSymbols | symbols nonSymbols pound | state = #extracted ifFalse: [self error: 'wrong state']. The state #extracted DOES NOT EXISTS!!! Look the senders and you will find only that method hahahahahah I guess it should be #active, because, as you can see in the method extract, the final states it sets is #active. So....you always get "wrong state" ;) Cheers, Mariano > And my opinion is that it's suspicious to require something different > for a image segment that contains symbols as opposed to one that > doesn't; the ideal would be to have image segments just transparently > handle Symbols correctly. Users just shouldn't have to deal with details > at that level; the correct semantics are extremely clear. > > Regards, > > -Martin > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 13, 2009