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

[Pharo-project] OBSystemBrowser and class comments

by Torsten Bergmann

Maybe the code pane still updates Shout/eCompletion like in "method/class definition editing mode" while in "edit class comment mode". Bye T. -- GMX DSL: Internet-, Telefon- und Handy-Flat ab 19,99 EUR/mtl. Bis zu 150 EUR Startguthaben inklusive! http://portal.gmx.net/de/go/dsl

June 18, 2010

[Pharo-project] OBSystemBrowser and class comments

by Adrien BARREAU

Hello all, I'm writing some class comment for Citezen. But I think something is strange: when I type something on my keyboard, there are 1 or 2 secondes of latent period before it display it on the screen. I don't know if it has already been signaled. Adrien. _________________________________________________________________ Installez gratuitement les nouvelles Emoch'ticones ! http://www.ilovemessenger.fr/emoticones/telecharger-emoticones-emochticones…

June 18, 2010

[Pharo-project] Autotest (TDD), request for comments

by laurent laffont

Hi, Autotest is a live testing tool (similar too Ruby Autotest, but the Smalltalk way, more dynamic). Autotest automatically runs tests related to the methods you edit. Screencast to see it in action: http://lolgzs.free.fr/pharo/autotest3.mpeg Autotest uses the following heuritics to find the tests to run: - if the method is a test, runs it - it the method is a test setUp or tearDown, run all the tests of the TestCase - else find all senders which are tests in the same package and runs them (it detects different packages that are related, for example ProfStef-Core and ProfStef-Test) To activate the Autotest dashboard: - open the settings browser - go under System - check "Show Autotest Dashboard" option To load it: Gofer new squeaksource: 'Autotest'; package: 'Autotest'; load HelpSystem book included. I would like to know what needs enhancements, what to add (and to remove :) and whether you would use it or not (and why). Thanks for feedback. Cheers, Laurent Laffont http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/

June 17, 2010

[Pharo-project] Why announcer subscriptions is dectionary?

by Denis Kudriashov

Hello, I found that subscribers handle announcements in order differ then order in which they subscribe. Reason - announcer subscriptions is dictionary. Maybe dependency of announcement handling order is bad code design. But it can be usefull. Example. I need announcerA delegates announcements from another announcerB. And I need announcerA handles some specific announcement for own task. I try this code: announcerB on: SpecificEvent send: #specificHandler: to: announcerA. announcerB on: Announcement send: #announce: to: announcerA I want announcerA handles SpecificEvent (by #specificHandler) before other subscribers to announcerA .With current announcements implementation this code not work. What you think about this? I see announcer implementation. And I dont found some reason for dictionary subscriptions. Maybe we can fix it.

June 17, 2010

Re: [Pharo-project] Issue 2560 : Convenient methods from Grease for Strings

by Michael Roberts

I'm missing something. Why do we need to adopt the (copy of) methods and not just adopt the package as lukas said? I thought we wanted core to get smaller over time and better modularised anyway? We would just need to track a stable version rather than maintaining our own branch. Surely it is worse to copy the methods renamed or not but put them in a pharo specific package? Cheers mike On 17 Jun 2010, at 14:14, Julian Fitzell <jfitzell(a)gmail.com> wrote: > 2010/6/17 Marcus Denker <marcus.denker(a)inria.fr>: >> >> On Jun 17, 2010, at 12:27 PM, Lukas Renggli wrote: >> >> - If included with Pharo I suggest to rename all the methods, >> otherwise we will run into big troubles with Seaside and other >> projects that depend on Grease. >> >> >> From a philosophical standpoint, I *hate* that. this means that as a >> plattform, we can not >> grow and improve our libraris anymore? >> Shouldn't be the goal that useful extensions gets adopted by the >> core? > > We will need to find a way to allow platforms to adopt Grease methods > - I do think this is the end goal. It's a bit of a nightmare from our > point of view because we end up having to have different Grease > versions for different versions of the platforms, but isn't that sort > of unavoidable in the long run anyway? Part of the reason that's so > awful is simply due to the lack of good branching and management tools > in our version control systems... > > Julian > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 17, 2010

Re: [Pharo-project] Issue 2560 : Convenient methods from Grease for Strings

by Dale Henrichs

Julian, The Grease-Core package contains a mixture of things (for convenience): the GR* family of classes using a naming convention that is unlikely to collide with platform classes and a collection of extensions to well-known classes using names that could very easily collide with platform methods (or prevent a platform from implementing that method in their base system). The well-known class extension methods could easily be moved to the platform-side, then as platforms adopt the Grease extensions (an obvious goal of Grease in the first place) the platform extensions can be adjusted accordingly...the Grease-Tests for those methods should remain so that from the Grease-Users perspective the behavior for those methods will remain consistent (relative to Grease) over time... It _would be convenient_ to preserve the current well-known class extension method implementations so that when Grease is ported to a new platform the "standard implementation" can be used as a bootstrap. In fact if the well-known class extension methods were moved into a separate platform package, then you'd have the gold standard implementation and the initial pharo/squeak implementation rolled into one. In the end this doesn't sound that awful... Dale Julian Fitzell wrote: > 2010/6/17 Marcus Denker <marcus.denker(a)inria.fr>: >> On Jun 17, 2010, at 12:27 PM, Lukas Renggli wrote: >> >> - If included with Pharo I suggest to rename all the methods, >> otherwise we will run into big troubles with Seaside and other >> projects that depend on Grease. >> >> >> From a philosophical standpoint, I *hate* that. this means that as a >> plattform, we can not >> grow and improve our libraris anymore? >> Shouldn't be the goal that useful extensions gets adopted by the core? > > We will need to find a way to allow platforms to adopt Grease methods > - I do think this is the end goal. It's a bit of a nightmare from our > point of view because we end up having to have different Grease > versions for different versions of the platforms, but isn't that sort > of unavoidable in the long run anyway? Part of the reason that's so > awful is simply due to the lack of good branching and management tools > in our version control systems... > > Julian > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 17, 2010

Re: [Pharo-project] OpenDBX for dbase files

by Facundo Vozzi

Beniot, do you use this for OBDC on Pharo, http://www.squeaksource.com/@N-vIVE5EmBTpAjWY/bYzXEKgO ? Last night, I tried it but i had my image blocked. Tonight, i'll try it again. Thanks, Facundo 2010/6/17 Benoit St-Jean <bstjean(a)hotmail.ca> > Hi Facundo, > > You can use ODBC to access it. > > From what I read on the SqueakDBX web page, they don't support xBase files > nor ODBC (only ODBC for POstgreSQL is listed) yet. > > The xBase package on squeaksource might work but your best bet would be > ODBC as far as I know. > > ODBC works fine and is rock-solid in Pharo. I'm using it to connect to > PostGreSQL, InterBase, MySQL, Oracle, DB2 and SQL Server without any > problem. > > Hope this helps. > > ----------------- > Benoit St-Jean > A standpoint is an intellectual horizon of radius zero. > (Albert Einstein) > > > > > ------------------------------ > Date: Fri, 11 Jun 2010 08:18:14 -0300 > From: facundov79(a)gmail.com > > To: Pharo-project(a)lists.gforge.inria.fr > Subject: [Pharo-project] OpenDBX for dbase files > > > Hi at all, > can I used openDBX for read dbase (.dbf) files or I need try with xbase ? > > regards, > Facu > > > ------------------------------ > Turn down-time into play-time with Messenger games Play Now!<http://go.microsoft.com/?linkid=9734381> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Facundo Vozzi InfOil S.A. Project Leader (+54-11) 4542-9999 x108 fvozzi(a)infoil.com.ar

June 17, 2010

Re: [Pharo-project] Prof Stef browser

by laurent laffont

On Thu, Jun 17, 2010 at 4:46 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > Laurent, > > I don't have a fix yet. In fact, I am so impressed with what you have done > that I am thinking of abandoning, or least strongly altering, my GUI efforts > based on what you are doing. > Indeed, I'm the author of ProfStef. But ProfStefBrowser has been written by Danny Chan, so give credits to him :) We need to document GUI. Hilaire and I have started to work on it through the Pharo Book or Pharocasts, but a lot of work remains. I think it's easier to improve it once we now how it works and document the "right" way to do it. IMHO we don't need to have the best GUI tools (now), we need to have easy-to-understand recipes to make basic and powerful stuff so newbies can do it, more newbies means more contributors later and we need contributors :) So let's learn together. Laurent > Having some basic Dolphin-like classes for presenters (text, list, tree, > image) could be very useful. But another approach I am considering is to > try to approach it more like Seaside code which has some advantages. > > Bill > > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of laurent laffont > [laurent.laffont(a)gmail.com] > Sent: Thursday, June 17, 2010 10:34 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Prof Stef browser > > On Thu, Jun 17, 2010 at 4:20 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu > <mailto:bschwab@anest.ufl.edu>> wrote: > For fun, open two Prof Stef browsers and see what happens when you click on > the tree in one of them. Then close the second one, and click on the tree > in the first. They should act independently. Beyond just a nice system for > newbies, this is a potentially important example to get people started > building GUIs in Pharo, so the details are important. > > I agree. I'll try to have a look (repository is public write, if you have a > fix just commit it). > > Cheers, > > Laurent Laffont > > http://pharocasts.blogspot.com/ > http://magaloma.blogspot.com/ > > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr<mailto: > 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 >

June 17, 2010

Re: [Pharo-project] Prof Stef browser

by Schwab,Wilhelm K

Laurent, I don't have a fix yet. In fact, I am so impressed with what you have done that I am thinking of abandoning, or least strongly altering, my GUI efforts based on what you are doing. Having some basic Dolphin-like classes for presenters (text, list, tree, image) could be very useful. But another approach I am considering is to try to approach it more like Seaside code which has some advantages. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of laurent laffont [laurent.laffont(a)gmail.com] Sent: Thursday, June 17, 2010 10:34 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Prof Stef browser On Thu, Jun 17, 2010 at 4:20 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: For fun, open two Prof Stef browsers and see what happens when you click on the tree in one of them. Then close the second one, and click on the tree in the first. They should act independently. Beyond just a nice system for newbies, this is a potentially important example to get people started building GUIs in Pharo, so the details are important. I agree. I'll try to have a look (repository is public write, if you have a fix just commit it). Cheers, Laurent Laffont http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/ _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 17, 2010

Re: [Pharo-project] Issue 2560 : Convenient methods from Grease for Strings

by Schwab,Wilhelm K

+1 on the idea that this should be a whole lot slicker than it is. That said, Lukas' idea of keeping the relevant methods in an external package is certainly a way around the problem, and not even a bad way either. In fact, Dolphin's package system is VERY picky, and the way one usually gets it to relax is to create what I call "yet another package" so that things can load in the correct order. FWIW, I am still trying to figure out whether MC is superior (more flexible) to (than) Dolphin's package load mechanism, or if I simply haven't yet been burned by what it fails to prevent. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Lukas Renggli [renggli(a)gmail.com] Sent: Thursday, June 17, 2010 7:25 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Issue 2560 : Convenient methods from Grease for Strings > - If included with Pharo I suggest to rename all the methods, > otherwise we will run into big troubles with Seaside and other > projects that depend on Grease. > > > From a philosophical standpoint, I *hate* that. this means that as a > plattform, we can not > grow and improve our libraris anymore? > Shouldn't be the goal that useful extensions gets adopted by the core? I agree, from Pharo point of view. However, for any software built on top of Pharo it means troubles if Pharo suddenly implements the same methods. Lukas -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 17, 2010