- Pharo-dev - lists.pharo.org

[Pharo-project] Package management info
by GeertClaes Dec. 16, 2009

Dec. 16, 2009

I tried to search for more info about the "Package management system" mentioned to be part of the next 1.1 Pharo milestone. Can someone point me to more info about this package management system? I also could not find that much info about MetaCello either. Any links to papers, presentation and/or video much appreciated. -- View this message in context: http://n2.nabble.com/Package-management-info-tp4176930p4176930.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

3 2

Re: [Pharo-project] [squeak-dev] Re: [BUG] [ :a | ] value: 1
by Stephen Pair Dec. 16, 2009

Dec. 16, 2009

On Wed, Dec 16, 2009 at 1:24 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > > I like Peter's response. How about making it a preference? ;) ;) What I > mean is we replace the code by something that compiles code that either > raises an error or answers nil. y default the preference is set to generate > the error code. Then we force people to write [:arg| nil] because [:arg| ] > will generate a run-time error (with a verbose and helpful explanatory > comment). Then in a few months, years, decades we'll be in a position to > remove the preference and generate code that answers nil because all the > uses will have been caught. > > I can imagine wanting to keep the preference and turning it on when > importing code from other dialects for error checking. > > The downside to this approach is that empty blocks with arguments will > include the "nil" noise. But that;s very easy to remove automatically once > the putsch is stable. > Egads! I thought it was a really good joke at first, but now I realize you are half serious. Make it work right, fix all the code in the base image, maybe write something that can reveal places where this is done in a particular class or package, then publish it while reminding people of: THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. - Stephen

1 0

[Pharo-project] Fwd: [BUG] [ :a | ] value: 1
by Lukas Renggli Dec. 16, 2009

Dec. 16, 2009

---------- Forwarded message ---------- From: Eliot Miranda <eliot.miranda(a)gmail.com> Date: 2009/12/16 Subject: Re: [BUG] [ :a | ] value: 1 To: Lukas Renggli <renggli(a)gmail.com> Cc: Dan Ingalls <Dan.Ingalls(a)sun.com>, "L. Peter Deutsch" <lpd(a)major2nd.com>, The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org>, Pharo Development <pharo-project(a)lists.gforge.inria.fr> On Wed, Dec 16, 2009 at 9:44 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > > > :) :) Â This is funny. Â VisualWorks has exactly the same bug^H^H^Hfeature. > > Â And if you look at the ANSI standard (ok, this is from the draft, but it is > > essentially the actual document) there is an exception for precisely this > > case, Â See the last sentence in section 3.4.4 Blocks: > > > > If a block has no <block body> or no <statements> in its <block body> then > > the value of the block is undefined. > > Ok, I did not check that document. I somehow expected that all empty > blocks would return nil. As do we all, which is why this is so horribly broken :) Â The sad thing is, we've been living with it for thirty years. > > > Which allows [] to be implemented as e.g. [Random new next]. Â In fact both > > VisualWorks and Squeak answer the last argument: > > [:a ] value: 1 1 > > [:a :b|] value: 1 value: 2 2 > > [:a :b :c :d :e :f :g :h| ] valueWithArguments: (1 to: 8) 8 > > [:a | nil] value: 1 nil > > [:a :b| nil] value: 1 value: 2 nil > > At least it is consistent whether the block is inlined or not ;) > > 1+2 ifNotNil: [:arg|] 3 > > It as ever been so. > > Thank you for the additional insight. I learned something new on the > Smalltalk semantics today :-) > > I will fix my code then. > > > P.S. Â I'm caught between wanting to fix it and wanting to let sleeping dogs > > lie. Â I'd like to know what all the other dialects do. Â If a substantial > > majority have the same curio I think we have to live with this, uh, > > ornament. Â Just to be clear, making it a preference is a sick joke on my > > part. > > I think we'd better let it sleep. In my image I have 61 empty blocks > with one or more argument. Some of them might depend on that hidden > behavior. > I like Peter's response. Â How about making it a preference? ;) ;) What I mean is we replace the code by something that compiles code that either raises an error or answers nil. Â y default the preference is set to generate the error code. Â Then we force people to write [:arg| nil] because [:arg| ] will generate a run-time error (with a verbose and helpful explanatory comment). Â Then in a few months, years, decades we'll be in a position to remove the preference and generate code that answers nil because all the uses will have been caught. I can imagine wanting to keep the preference and turning it on when importing code from other dialects for error checking. The downside to this approach is that empty blocks with arguments will include the "nil" noise. Â But that;s very easy to remove automatically once the putsch is stable. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch -- Lukas Renggli http://www.lukas-renggli.ch

1 0

Re: [Pharo-project] [BUG] [ :a | ] value: 1
by Lukas Renggli Dec. 16, 2009

Dec. 16, 2009

> :) :) Â This is funny. Â VisualWorks has exactly the same bug^H^H^Hfeature. > Â And if you look at the ANSI standard (ok, this is from the draft, but it is > essentially the actual document) there is an exception for precisely this > case, Â See the last sentence in section 3.4.4 Blocks: > > If a block has no <block body> or no <statements> in its <block body> then > the value of the block is undefined. Ok, I did not check that document. I somehow expected that all empty blocks would return nil. > Which allows [] to be implemented as e.g. [Random new next]. Â In fact both > VisualWorks and Squeak answer the last argument: > [:a ] value: 1 1 > [:a :b|] value: 1 value: 2 2 > [:a :b :c :d :e :f :g :h| ] valueWithArguments: (1 to: 8) 8 > [:a | nil] value: 1 nil > [:a :b| nil] value: 1 value: 2 nil > At least it is consistent whether the block is inlined or not ;) > 1+2 ifNotNil: [:arg|] 3 > It as ever been so. Thank you for the additional insight. I learned something new on the Smalltalk semantics today :-) I will fix my code then. > P.S. Â I'm caught between wanting to fix it and wanting to let sleeping dogs > lie. Â I'd like to know what all the other dialects do. Â If a substantial > majority have the same curio I think we have to live with this, uh, > ornament. Â Just to be clear, making it a preference is a sick joke on my > part. I think we'd better let it sleep. In my image I have 61 empty blocks with one or more argument. Some of them might depend on that hidden behavior. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

2 1

Re: [Pharo-project] Package management info
by Dale Henrichs Dec. 16, 2009

Dec. 16, 2009

These are two places to get started with Metacello: http://code.google.com/p/metacello/ http://groups.google.com/group/metacello If you have questions, join the mailing group and ask away. Dale ----- "GeertClaes" <geert.wl.claes(a)gmail.com> wrote: | I tried to search for more info about the "Package management system" | mentioned to be part of the next 1.1 Pharo milestone. Can someone | point me | to more info about this package management system? | | I also could not find that much info about MetaCello either. Any | links to | papers, presentation and/or video much appreciated. | -- | View this message in context: | http://n2.nabble.com/Package-management-info-tp4176930p4176930.html | Sent from the Pharo Smalltalk mailing list archive at Nabble.com. | | _______________________________________________ | Pharo-project mailing list | Pharo-project(a)lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

[Pharo-project] EventInterceptor and MessageSendTree
by HernÃ¡n Morales Durand Dec. 16, 2009

Dec. 16, 2009

Dear all, I've attached a little cool tool for intercepting Morphic events I just resurrected today, from the class comments: This morph is a button which, when pressed, begins listening to the hand's event stream. When an even of the appropriate type is encountered, this morph intercepts it and traces the dispatch of the event using MessageSendTree, and opens a SendTreeExplorer on the results. This is useful for debugging parts of the UI process which are otherwise difficult to trace. The eventType can be any of the Morphic event types, but #mouseUp, #mouseDown, and #keystroke are by far the most useful because they are the triggers for the majority of actual UI activity. This is a list of morphic events to try: #mouseDown #mouseMove #mouseUp #mouseOver #mouseEnter #mouseLeave #mouseLeaveDragging #keystroke #keyDown #keyUp #unknown #click To install it load first MessageSendTree. The original author is Jesse Welton http://jwelton.v-space.org/squeak/ Cheers, HernÃ¡n

4 6

[Pharo-project] [BUG] [ :a | ] value: 1
by Lukas Renggli Dec. 16, 2009

Dec. 16, 2009

Hi Eliot While working on a way to use the RB-AST with the standard compiler I think I found a problem in your code. To reproduce evaluate the following expression: [ :a | ] value: 1 According to my understanding that should return nil, not the first argument 1. The generated bytecode is: pushTemp: 0 blockReturn I think it should be: pushConstant nil blockReturn Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

1 0

[Pharo-project] This interpreter (vers. 6502) cannot read image file (vers. 6504).
by Monty Kamath Dec. 15, 2009

Dec. 15, 2009

I'm trying to run my Pharo image on CentOS using Squeak-3.11.3.2135-linux_i386.tar.gz which I think is the latest linux vm. When I do I get this: This interpreter (vers. 6502) cannot read image file (vers. 6504). Press CR to quit... This doesn't happen with my older Squeak image. Also, this doesn't happen on Windows with the Pharo vm and my Pharo image. Can someone point me to the vm I should be using? Thanks, Monty -- View this message in context: http://n2.nabble.com/This-interpreter-vers-6502-cannot-read-image-file-vers… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

5 6

[Pharo-project] [Fwd: windowColorSpecification]
by Alain Plantec Dec. 15, 2009

Dec. 15, 2009

6 8

[Pharo-project] [update 1.1] #11105
by Marcus Denker Dec. 15, 2009

Dec. 15, 2009

11105 ----- Issue 1612: remove halt from MenuItemMorph>>drawOn

1 0