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

Re: [Pharo-project] [ANN] ConfigurationOfMagma for Magma 1.1r1

by Miguel Enrique CobÃ¡ MartÃnez

El mar, 20-07-2010 a las 18:33 +0200, Andreas Wacknitz escribiÃ³: > Am 20.07.10 16:42, schrieb Miguel Enrique CobÃ¡ MartÃnez: > > El mar, 20-07-2010 a las 10:17 +0200, Mariano Martinez Peck escribiÃÂ³: > >> Hi Miguel. I understand your problem, and we are working on that with > >> Dale and Stef. Having repositories for a specific Pharo version and so > >> on. But we are just starting.... > >> > >> By the moment, you can use what Sean told you, or, just update the > >> configuration, but in a new version. I mean....if you had the version > >> 2.3.4 that was released and working in pharo 1.0, then don't touch it, > >> create a new one, say, 2.4 and that works in 1.1. Of course this is > >> not the perfect solution, but for the moment. But one thing for sure: > >> do not update the SAME version that was working for 1.0. > >> Magma should continue working in 1.0 using the same metacello version. > > > > Exactly. I will do it this night. > > > > BTW. What will be the solution, copying directories (debian does this > > too. They copy the repository contents and then diverge from them. The > > previous repository only receives bug fixes) but the solution of Dale, > > as I understand it uses tags to identify what version is running on and > > then load only the packages for that version. This solution is a third > > alternative. So by now we have: > > > > - Copy repositories of configurations for each new release > > - Use version attributes for conditionally loading packages in version > > methods. > > - Use tags to mark the pharo release a given version method applies. > > Then metacello searches for the version method with the highest number > > that is tagged with the release number of the image (got from > > SystemVersion) > > > > Cheers > Hi, > > Wouldn't it be good to also ask the maintainer of the offending packages > to change the assignments such that Pharo will be happy without changing > the preference? Chris Muller announced some time ago that he was changing the underscores to := assignments in them Magma codebase. He had concerns about the scripts for automating this because it changed the author timestamps of each method modified and he didn't want to lost those original timestamps. So until he publishes the new code without underscores, we must use the preference when loading the code. Cheers > > Regards, > Andreas > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel CobÃ¡ http://miguel.leugim.com.mx

July 20, 2010

Re: [Pharo-project] [ANN] ConfigurationOfMagma for Magma 1.1r1

by Andreas Wacknitz

Am 20.07.10 16:42, schrieb Miguel Enrique CobÃ¡ MartÃnez: > El mar, 20-07-2010 a las 10:17 +0200, Mariano Martinez Peck escribiÃÂ³: >> Hi Miguel. I understand your problem, and we are working on that with >> Dale and Stef. Having repositories for a specific Pharo version and so >> on. But we are just starting.... >> >> By the moment, you can use what Sean told you, or, just update the >> configuration, but in a new version. I mean....if you had the version >> 2.3.4 that was released and working in pharo 1.0, then don't touch it, >> create a new one, say, 2.4 and that works in 1.1. Of course this is >> not the perfect solution, but for the moment. But one thing for sure: >> do not update the SAME version that was working for 1.0. >> Magma should continue working in 1.0 using the same metacello version. > > Exactly. I will do it this night. > > BTW. What will be the solution, copying directories (debian does this > too. They copy the repository contents and then diverge from them. The > previous repository only receives bug fixes) but the solution of Dale, > as I understand it uses tags to identify what version is running on and > then load only the packages for that version. This solution is a third > alternative. So by now we have: > > - Copy repositories of configurations for each new release > - Use version attributes for conditionally loading packages in version > methods. > - Use tags to mark the pharo release a given version method applies. > Then metacello searches for the version method with the highest number > that is tagged with the release number of the image (got from > SystemVersion) > > Cheers Hi, Wouldn't it be good to also ask the maintainer of the offending packages to change the assignments such that Pharo will be happy without changing the preference? Regards, Andreas

July 20, 2010

Re: [Pharo-project] about hex

by StÃ©phane Ducasse

tx! I was thinking that we could keep old hex as hexDigits Stef On Jul 20, 2010, at 4:42 PM, Yanni Chiu wrote: > Originally, the NATIVE postgresql driver was (somewhat?) ANSI ST incompatible. I had it working in VAST. Along the way, the Cryptography package was added as a dependency to support MD5 passwords. > > If #hex is not ANSI ST, then the postgres native driver is likely unaffected by changes to #hex, other than its effect on MD5. I can verify this later today. > > -- > Yanni > > > Mariano Martinez Peck wrote: >> On Tue, Jul 20, 2010 at 2:46 AM, Henrik Johansen <henrik.s.johansen(a)veloxit.no <mailto:henrik.s.johansen@veloxit.no>> wrote: >> Iirc, it was reintroduced in Pharo in relation to SqueakDBX, might >> want to check with Mariano that changes will be compatible/SqueakDBX >> is updated. >> Hi Henrik. Indeed, it was included for SqueakDBX. Actually, not for itself, but the NATIVE postgresql driver used to depends in the chripto package. Then, the MD5 class was put in PharoCore so it didn't depend anymore. But the hex was missing. >> Now...if you ask me if this change will affect the postgres native driver, I HAVE NO IDEA. The only thing I can do is to run the tests. But for that I need a postgres with encrypthion running handly. >> Do you know Yanni? >> Cheers >> Mariano > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 20, 2010

Re: [Pharo-project] [ANN 1.1] pre-built 1.1 Release #11411 Core

by StÃ©phane Ducasse

apparently ours kills our server :) the disc got filled up :) Stef On Jul 20, 2010, at 3:52 PM, Lukas Renggli wrote: > Thank you Marcus, my hudson is rebuilding the whole shebang now. > > Lukas > > On 20 July 2010 15:48, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> https://gforge.inria.fr/frs/download.php/27296/PharoCore-1.1.zip >> >> -- >> Marcus Denker -- http://www.marcusdenker.de >> INRIA Lille -- Nord Europe. Team RMoD. >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > 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

July 20, 2010

Re: [Pharo-project] Can TestRunner notify failures and errors while they happen?

by StÃ©phane Ducasse

the idea is that adrian proposed to have a testcase acting as an announcer and the testRunner listening So I would start there. On Jul 20, 2010, at 3:15 PM, Mariano Martinez Peck wrote: > Hi folks. One of my tasks while creating the dev images is to run all the tests and analyze the errors and failures. TestRunner list the results (failures and errors) at the end. I would like it to update show and update the TestRunner UI. Why ? Because if it shows me the errors and failures while they happen, I can take the same image, open it again, and start to analyze them. And I don't have to wait until de endâ¦ > > Can someone help me with this? what do you think ? > > Thanks > > Mariano > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 20, 2010

[Pharo-project] Squeak devices and applications

by Torsten Bergmann

Just read the post from Hilaire about Pharo on OLPC [1]. This leads to the following interesting question: What is the most crazy device Squeak VM is running on? What is the most interesting application where nobody would have expected Squeak/Pharo/Cuis? Feel free to answer by posting screenshots/pictures even if you think the device/app is boring. Would be nice to know and we can collect these to do a little bit of advertising on the Squeak/Pharo web pages... Bye T. [1] http://blog.ofset.org/hilaire/index.php?post/2010/07/20/Pharo-Smalltalk-on-… -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail

July 20, 2010

Re: [Pharo-project] How to see failures/erros of the Hudson server?

by Mariano Martinez Peck

this is cool :) thank you very much mariano On Tue, Jul 20, 2010 at 3:49 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > As Nick points out. Additionally, the image with the tests is saves so > you can download and run it. > > Lukas > > 2010/7/20 Nick Ager <nick.ager(a)gmail.com>: > > Failing tests: > > http://hudson.lukas-renggli.ch/job/Pharo/lastCompletedBuild/testReport/ > > > http://hudson.lukas-renggli.ch/job/Pharo/lastCompletedBuild/testReport/Test… > > log: > > http://hudson.lukas-renggli.ch/job/Pier/64/console > > > > 2010/7/20 Mariano Martinez Peck <marianopeck(a)gmail.com> > >> > >> I know we have just started with the Hudson server, but is there a way > to > >> see why a test is failing/error ? For the errors, at least we can see > the > >> PharoDebug.log ? > >> THe other idea we have today (talking with Marcus) is to have RFB > running > >> in the hudson images. So that we can connect and browse it. Of course, > it > >> could be password protected so that not everybody can do it. > >> > >> What do you think? > >> > >> Cheers > >> > >> Mariano > >> > >> _______________________________________________ > >> 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 > > > > > > -- > 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 >

July 20, 2010

[Pharo-project] Bug with Windows titles not refreshing (in OB)

by Mariano Martinez Peck

Hi, there is a bug with windows titles as they don't refresh and keeps a previous title. Steps to reproduce: 1) Search senders of a particular message, for example, doesNotUnderstand: 2) You will see that the opened windows for senders, has the title "Senders of '#doesNotUnderstand:" 3) Now, select one of the senders, for example, ContextPart >> send: selector to: rcvr with: args super: superFlag 4) That will open the senders of that message, BUT the windows title still says "Senders of '#doesNotUnderstand:" instead of "Senders of '#send:to:with:super:" Issue: http://code.google.com/p/pharo/issues/detail?id=2707 Cheers Mariano

July 20, 2010

Re: [Pharo-project] about hex

by Yanni Chiu

Originally, the NATIVE postgresql driver was (somewhat?) ANSI ST incompatible. I had it working in VAST. Along the way, the Cryptography package was added as a dependency to support MD5 passwords. If #hex is not ANSI ST, then the postgres native driver is likely unaffected by changes to #hex, other than its effect on MD5. I can verify this later today. -- Yanni Mariano Martinez Peck wrote: > > > On Tue, Jul 20, 2010 at 2:46 AM, Henrik Johansen > <henrik.s.johansen(a)veloxit.no <mailto:henrik.s.johansen@veloxit.no>> wrote: > > Iirc, it was reintroduced in Pharo in relation to SqueakDBX, might > want to check with Mariano that changes will be compatible/SqueakDBX > is updated. > > > Hi Henrik. Indeed, it was included for SqueakDBX. Actually, not for > itself, but the NATIVE postgresql driver used to depends in the chripto > package. Then, the MD5 class was put in PharoCore so it didn't depend > anymore. But the hex was missing. > Now...if you ask me if this change will affect the postgres native > driver, I HAVE NO IDEA. The only thing I can do is to run the tests. But > for that I need a postgres with encrypthion running handly. > > Do you know Yanni? > > Cheers > > Mariano

July 20, 2010

Re: [Pharo-project] [ANN] ConfigurationOfMagma for Magma 1.1r1

by Miguel Enrique CobÃ¡ MartÃnez

El mar, 20-07-2010 a las 10:17 +0200, Mariano Martinez Peck escribiÃ³: > Hi Miguel. I understand your problem, and we are working on that with > Dale and Stef. Having repositories for a specific Pharo version and so > on. But we are just starting.... > > By the moment, you can use what Sean told you, or, just update the > configuration, but in a new version. I mean....if you had the version > 2.3.4 that was released and working in pharo 1.0, then don't touch it, > create a new one, say, 2.4 and that works in 1.1. Of course this is > not the perfect solution, but for the moment. But one thing for sure: > do not update the SAME version that was working for 1.0. > Magma should continue working in 1.0 using the same metacello version. Exactly. I will do it this night. BTW. What will be the solution, copying directories (debian does this too. They copy the repository contents and then diverge from them. The previous repository only receives bug fixes) but the solution of Dale, as I understand it uses tags to identify what version is running on and then load only the packages for that version. This solution is a third alternative. So by now we have: - Copy repositories of configurations for each new release - Use version attributes for conditionally loading packages in version methods. - Use tags to mark the pharo release a given version method applies. Then metacello searches for the version method with the highest number that is tagged with the release number of the image (got from SystemVersion) Cheers > > cheers > > mariano > > On Tue, Jul 20, 2010 at 9:26 AM, Sean P. DeNigris > <sean(a)clipperadams.com> wrote: > > For now, you can use the hack that Dale suggested in > http://groups.google.com/group/metacello/browse_thread/thread/a27c95d24974a…. > > > Take a look a ConfigurationOfGemTools>>project. In that > method I created a > > #'pharo1.0Beta' attribute by looking at the SystemVersion > current > > version... > -- > View this message in context: > http://forum.world.st/ANN-ConfigurationOfMagma-for-Magma-1-1r1-tp2242566p22… > 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel CobÃ¡ http://miguel.leugim.com.mx

July 20, 2010