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

[Pharo-project] Issue 3344 in pharo: No brainer fix for hasBindingThatBeginWith:
by pharo＠googlecode.com Nov. 30, 2010

Nov. 30, 2010

Status: Fixed Owner: stephane.ducasse Labels: Milestone-1.2 New issue 3344 by stephane.ducasse: No brainer fix for hasBindingThatBeginWith: http://code.google.com/p/pharo/issues/detail?id=3344 SystemDictionary>>hasBindingThatBeginsWith: aString "Use the cached class and non-class names for better performance." | name searchBlock | searchBlock := [ :element | (element beginsWith: aString) ifTrue: [ 0 ] ifFalse: [ aString < element ifTrue: [ -1 ] ifFalse: [ 1 ] ] ]. name := self classNames findBinary: searchBlock + ifNone: [ nil ]. - ifNone: nil. name ifNotNil: [ ^true ]. name := self nonClassNames findBinary: searchBlock + ifNone: [ nil ]. - ifNone: nil. ^name notNil!

1 1

[Pharo-project] [update 1.2] #12264
by Marcus Denker Nov. 30, 2010

Nov. 30, 2010

12264 ----- Issue 3359: categorize some methods Issue 3358: Another fix for SourceReference Issue 3351: Comments in MIMEDocument erroneously refer to MIMEObject Issue 3344: No brainer fix for hasBindingThatBeginWith: ... and hudson auto-build was triggered successfully. https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.2/ -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

[Pharo-project] Issue 3351 in pharo: Comments in MIMEDocument erroneously refer to MIMEObject
by pharo＠googlecode.com Nov. 30, 2010

Nov. 30, 2010

Status: New Owner: ---- New issue 3351 by tony.fleig: Comments in MIMEDocument erroneously refer to MIMEObject http://code.google.com/p/pharo/issues/detail?id=3351 Pharo image: Pharo Pharo core version: 1.1-11411 Virtual machine used: n/a Class browser used (if applicable): n/a In the following method, comments refer to MIMEObject (which I assume is an earlier name for MIMEDocument): MIMEDocument class>>#contentType:content I realize this is a small thing, but it did cause me to hunt around for MIMEObject for a while.

1 4

[Pharo-project] Issue 3358 in pharo: Another fix for SourceReference
by pharo＠googlecode.com Nov. 30, 2010

Nov. 30, 2010

Status: Fixed Owner: Benjamin.VanRyseghem.Pharo New issue 3358 by Benjamin.VanRyseghem.Pharo: Another fix for SourceReference http://code.google.com/p/pharo/issues/detail?id=3358 Just a little fix which replace 'historical' by '<historical>' Attachments: FixSourceReference.1.cs 1.3 KB

1 1

[Pharo-project] Issue 3359 in pharo: categorize some methods
by pharo＠googlecode.com Nov. 30, 2010

Nov. 30, 2010

Status: Fixed Owner: marcus.denker Labels: Milestone-1.2 New issue 3359 by marcus.denker: categorize some methods http://code.google.com/p/pharo/issues/detail?id=3359 ... to make some more tests green Attachments: categorize methods.1.cs 5.6 KB

1 1

Re: [Pharo-project] New to PHP 5.4: Traits
by Marcus Denker Nov. 30, 2010

Nov. 30, 2010

On Nov 21, 2010, at 10:53 PM, jaayer wrote: >> > > No, there isn't, at least not compared with the rate of Smalltalk's adoption of Traits. Face it. There are just too many Smalltalkers who seem to think the language is a complete revelation that no mortal has the right to amend. Other languages can grow to accommodate new features; Smalltalk, which went through a number major revisions in the 70s at PARC, remains frozen in the amber of 1980. I think there are two forces at work: 1) Those that block any change because Smalltalk is not supposed to be changed by mortals. 2) Those that want to go "beyond Smalltalk". But it has to be perfect! So better do nothing. (Aka: The Squeak Desease). This is the far greater problem. Point 2 actually has fractal properties. You can see it at all scales. From the small. (Why fix a typo when you want to do something oh-so-great!) up to the big picture. The old man story. One can not quote this too often: "One of the sad memories of my life is a visit to the celebrated mathematician and inventor, Mr Babbage. He was far advanced in age, but his mind was still as vigorous as ever. He took me through his work-rooms. In the first room I saw parts of the original Calculating Machine, which had been shown in an incomplete state many years before and had even been put to some use. I asked him about its present form. 'I have not finished it because in working at it I came on the idea of my Analytical Machine, which would do all that it was capable of doing and much more. Indeed, the idea was so much simpler that it would have taken more work to complete the Calculating Machine than to design and construct the other in its entirety, so I turned my attention to the Analytical Machine.'" "After a few minutes' talk, we went into the next work-room, where he showed and explained to me the working of the elements of the Analytical Machine. I asked if I could see it. 'I have never completed it,' he said, 'because I hit upon an idea of doing the same thing by a different and far more effective method, and this rendered it useless to proceed on the old lines.' Then we went into the third room. There lay scattered bits of mechanism, but I saw no trace of any working machine. Very cautiously I approached the subject, and received the dreaded answer, 'It is not constructed yet, but I am working on it, and it will take less time to construct it altogether than it would have token to complete the Analytical Machine from the stage in which I left it.' I took leave of the old man with a heavy heart." -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

3 3

Re: [Pharo-project] <script language="smalltalk">
by Simon Denier Nov. 30, 2010

Nov. 30, 2010

On 26 nov. 2010, at 19:26, Janko MivÅ¡ek wrote: > On 26. 11. 2010 18:20, csrabak(a)bol.com.br wrote: >> Em 24/11/2010 11:50, Jan van de Sandt < jvdsandt(a)gmail.com > escreveu: > >>> A Smalltalk variant would use Smalltalk as the source language >>> instead of Java, the other parts of GWT can be reused. GWT is open >>> source (Apache 2.0 license). > >> I think we have first to evaluate to what audience/market are thinking of >> targeting this effort, then estimate the effort, in order to see if its >> worth it. > > Specially we the web guys are very interested of such a beast, because > we need to develop more in more on the client side and in JavaScript, > which is a bit hard, because of our Smalltalk habits, you know :) > > Even more, Smalltalk on the client (Clamato way) can also solve one of > the main JavaScript problems: debugging on the client side. If we can > have near the same debugger on the client as we have in our IDE's, well, > this would be a huge step forward. Well then, We have the Smalltalk IDE but nobody is interested to look at it because it's Smalltalk. We have Seaside but nobody is interested to look at it because it's Smalltalk. But maybe if someone brings a Javascript IDE built in Smalltalk, people will start to look at it :) We may even already have one edge with PetitParser. (and the trick is of course that you don't advertize Smalltalk, you advertize Javascript). Strangely, this reminds me of the story of Lucid which built a powerful C++ IDE... in Lisp. This leads to XEmacs. http://www.jwz.org/doc/lemacs.html http://dreamsongs.com/Cadillac.html -- Simon

1 0

[Pharo-project] How to update Pharo
by Tony Fleig Nov. 30, 2010

Nov. 30, 2010

In the document at: http://code.google.com/p/pharo/wiki/HowToContribute, I find - Download the latest Pharo image from http://code.google.com/p/pharo/wiki/Downloads?tm=2. - Launch the fresh image and load the latest updates by using the option in the menu. The Pharo-1.1 One-Click image has no "update" option in the menu. Should I be using a different image? How would I go about updating the One-Click image "manually"? Regards, TF

2 1

[Pharo-project] NewInspector does not work well with delegated collections
by jaayer Nov. 30, 2010

Nov. 30, 2010

Enclosed is a fileout of a sample collection named DelegatedSet that works by delegating to an instance of Set stored in an instance variable. It implements the basic protocol Collection requires, including #add:, #remove:ifAbsent: and #do: as well as some additional messages, all through delegation. Create an instance of it and then inspect that instance with NewInsepctor, and you will notice the "Elements" item does not work. Nothing happens when you click it. To inspect the elements, you need to click "set," the instance variable containing the Set, and then inspect that object further. Apparently, unless you override one or more messages under the extension category *Newinspector, NewInspector will not know how to inspect your collection properly. Worse, as soon as you do implement those methods, unless you change their category, they will now be considered part of the *Newinspector package rather than the package your collection belongs to and will not be saved along with the collection. I think at a minimum, any collection understanding #do: and #size should be inspectable by NewInspector.

2 1

Nov. 30, 2010

> > > > > > One question, you have the pharo-project.org domain, why isn't this > > hudson a subdomain of that domain. Hosted on inria, but accessible by > > the official project domain? > > > One step at a time :-) > > > > Anyway, very good news. I suppose that the download page of pharo will > > point to the latest successful build link of the hudson server very > > soon. > > > Yes... that's the goal. The artefact that people download should be generated completely > automatically. (This way we can move much faster). > > > The Dev images can be automatically generated but shouldn't be consider stable, and should NOT be the dev image that a final user download. > To build a dev image, you have to options: > > 1) Just load all the latest versions of all external packages with a large gofer script. This way is easiest to just try to build an image and see how it works. But this doesn't scale, this is not reproducible in the future, and what is worst, it can be not stable (not always the latest versions are the required). > This was the previous way to create a Pharo dev. > > 2) Using Metacello configurations. With this we can make it reproducable and stable. BUUUUT in order to make it stable, we need to define stable metacello versions for all the configuration. And this is not done automatically. we should do 1) for now but 2) as soon as we have metacello repositories. and projects without metacello descriptions will not be published in pharo-dev. Stef > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > >

1 0