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

[Pharo-project] Why is Stack extending from LinkedList?

by Bart Gauquie

Hi list, is there a specific reason Stack is extending from LinkedList, instead of using a LinkedList internally? To me, it seems that the protocol that LinkedList, SequenceableCollection, ... provides is not the protocol you expect from a Stack? Any thoughts on this? 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 However beautiful the strategy, you should occasionally look at the results. - Sir Winston Churchill It's not enough that we do our best; sometimes we have to do what's required. - Sir Winston Churchill

Aug. 26, 2010

Re: [Pharo-project] [SPAM] Re: Hudson Question

by Sven Van Caekenberghe

On 26 Aug 2010, at 12:08, Lukas Renggli wrote: >> If I click on a artifact, say Seaside 3.0, is it then somehow possible to see the actual build script that was used ? > > The build script deletes it after a successful build. Maybe the script > should be left there? > >> I know about your github builder repository, and I learned a lot from it, but the scripts their do not seem to match 100%, or do they ? > > Yeah, they should match 100%. > > However note that I don't build images from scratch all the time, but > they build on top of each other: > > Pharo --> Development --> Seaside 3 --> Magritte 2 --> Pier 2 > \--> Seaside 2 --> Magritte --> Pier > \--> PetitParser > ... > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch Well, I am looking at the scripts in the git repo. There seems to be no script for Pharo (I guess you download core and run the tests). There seems to be no script for Development. I guess that Seaside 3.0 is seaside3.st + seaside3-komanche.st, but I am not sure. I would like to try to build these myself (not that the ones from Hudson are bad, I just want to learn from this). Sven

Aug. 26, 2010

Re: [Pharo-project] Hudson Question

by Lukas Renggli

On 26 August 2010 12:08, Lukas Renggli <renggli(a)gmail.com> wrote: >> If I click on a artifact, say Seaside 3.0, is it then somehow possible to see the actual build script that was used ? > > The build script deletes it after a successful build. Maybe the script > should be left there? Actually the build scripts are in the workspace. They are just not archived. Lukas -- Lukas Renggli www.lukas-renggli.ch

Aug. 26, 2010

Re: [Pharo-project] Hudson Question

by Lukas Renggli

> If I click on a artifact, say Seaside 3.0, is it then somehow possible to see the actual build script that was used ? The build script deletes it after a successful build. Maybe the script should be left there? > I know about your github builder repository, and I learned a lot from it, but the scripts their do not seem to match 100%, or do they ? Yeah, they should match 100%. However note that I don't build images from scratch all the time, but they build on top of each other: Pharo --> Development --> Seaside 3 --> Magritte 2 --> Pier 2 \--> Seaside 2 --> Magritte --> Pier \--> PetitParser ... Lukas -- Lukas Renggli www.lukas-renggli.ch

Aug. 26, 2010

Re: [Pharo-project] cog vm

by Sven Van Caekenberghe

On 25 Aug 2010, at 02:05, Levente Uzonyi wrote: > No, there's none, but in short: > The package consists of a 3 "APIs". The lowest level API is the PG3Connection. This works pretty much like PostgresV2, though some method names are different, but if you know how to use PostgresV2, then you will find out in 5 minutes how to use this. A higher level API is the PG3ConnectionPool which implements a simple connection pool. It's fairly easy to use the pool too. In 10 minutes one can set up a pool for a db without docs. The highest level API (in the public repository) is the PG3FunctionClient which allows you to call Postgres functions which return a refcursor. Most of our apps use this API to communicate with the DB. In our private repo we implemented a new high level API, which allows one to edit the Postgres functions in the Browser, fix bugs in the Debugger, version them with Monticello, etc. It also allows one to call "normal" functions which don't return a refcursor. Since the package is getting fat, we are at the point where we have to split it. When we're done with that, we'll push it to the public repo. > So feel free to experiment with it and if you need a feature or found a bug, let us know. OK, thanks for the update. I am mostly interested in plugging it under Glorp, I guess PG3Connect will do then. It is not high on my list, but I might get to it one day. Sven

Aug. 26, 2010

[Pharo-project] A look at seaside and pharo from a Rails/Ruby perspective

by Marcus Denker

Hi, It's always interesting how things are seen from the outside... (from http://on-ruby.blogspot.com/2010/08/rubyweb-interview-with-pat-maddox.html seems there will be a talk about seaside at a ruby conference early september...) --> begin quote Seaside is interesting technology, how did you discover it? ------------------------------------------------------------ Pat Seaside is a fascinating and fun technology!! I came across it a few years ago, not long after I got into Rails. Over the years I had a couple of false starts with it...it's a bit opaque at first because the development environment is so different from anything I'm used to. And it's only fairly recently with Pharo that it's become easier to get started, because it's such a clean environment geared towards development. Also the documentation for both Pharo and Seaside are getting really good. There are free books on each at pharobyexample.org and book.seaside.st/book. Okay as for what's so interesting to me about Seaside... it's 50% the framework and 50% the Pharo environment. Seaside itself represents a step forward in web development similar to how Rails did. Rails takes care of a lot of the plumbing for you - you don't have to parse query params, set up response headers, manage the session (unless you want to of course). Seaside does all that of course but also manages application state for you. So you don't have to worry about putting stuff into a database, then pulling it back out and operating on it. I can't do it justice in a few sentences, but that's why I'll be showing lots of examples at the conference! :) At any rate, that same feeling you get when you code Rails for the first time and see how much easier things are, you get that same feeling with Seaside. It's not a replacement for Rails by any means - Rails definitely has a sweet spot, particularly when it comes to RESTful websites and interoperability with the unix ecosystem - but for the things that Seaside is strong at (which for me so far has been complex and/or configurable workflows), it runs circles around everything else. The other thing I'm loving about Seaside development is Pharo, an open-source smalltalk environment. Smalltalk is a great language, and Pharo has great tools that allow you to discover everything in the system. Honestly it makes RubyMine or etags look plain silly. The best bit is that nearly everything in Pharo is implemented in smalltalk, including all of the tools. So if you want to see the mechanics of a refactoring tool, and even build your own, it's trivial to do so, because it's just smalltalk code. Wow this answer got long. I could go on all day about this stuff. Gonna stop now. --> end quote -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Aug. 26, 2010

[Pharo-project] [update 1.2] #12113

by Marcus Denker

12113 ----- Issue 2863: BlockClosure>>assert: is the same as in Object Issue 2861: tiny dead code removal, mostly Morph Issue 2853: Unnecessary URLArgumentList>>associationsDo Issue 2845: remove PluggableMultiColumnListMorphByItem and some unsent partbin related methods. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Aug. 26, 2010

Re: [Pharo-project] Philippe's WebClient patches

by StÃ©phane Ducasse

Philippe it would be better to target 1.2 since we will probably to go in beta end of sept or before if the list I sent is integrated. Stef >>> Currently I'm down to one multipart test failure. >> >> Did you start from the latest 1.2 merged version ? > > Nope, from Andreas' version. I'm on 1.1 an that's what I'm targeting. > > Cheers > Philippe > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 26, 2010

Re: [Pharo-project] Philippe's WebClient patches

by Sven Van Caekenberghe

On 26 Aug 2010, at 08:54, Philippe Marschall wrote: > Nope, from Andreas' version. I'm on 1.1 an that's what I'm targeting. That's not good, this way we're working next to each other. Couldn't our port of WebClient-Core be made compatible with both 1.1 and 1.2 ? It's bad enough that the original author is not really interested in the Pharo port, but we should at least work together. Sven

Aug. 26, 2010

Re: [Pharo-project] Philippe's WebClient patches

by Philippe Marschall

On 08/26/2010 07:45 AM, Sven Van Caekenberghe wrote: > > On 26 Aug 2010, at 07:39, Philippe Marschall wrote: > >> Currently I'm down to one multipart test failure. > > Did you start from the latest 1.2 merged version ? Nope, from Andreas' version. I'm on 1.1 an that's what I'm targeting. Cheers Philippe

Aug. 26, 2010