- Pharo-dev - lists.pharo.org

Re: [Pharo-project] programmatically update a Pharo image

by StÃ©phane Ducasse

Hi cyrille I published a read to be tested version of UpdateStreamer. Please have a look this is in PharoTaskForces/Updater I'm a little class inspired heavily from Utilities that download update.list and launch update. you can tell me to update throw a given number of update or to be verbose. UpdateStreamer new beVerbose; updateFromServer This will update all the updates available and show up dialogs UpdateStreamer new beSilent; upToNumber: 13000; updateFromServer let me know if this is working. I tested it and it seems so. Once we are a bit more confident :), we can use it in pharo and nuke (yeah) Utilities. Stef

Sept. 1, 2010

Re: [Pharo-project] Metacello for pharo 1.2

by Dale Henrichs

Mariano Martinez Peck wrote: > Try (ConfigurationOfMetacello project version: '1.0-beta.27-baseline' ) load > > 2010/9/1 Cyrille Delaunay <cy.delaunay(a)gmail.com > <mailto:cy.delaunay@gmail.com>> > > When I try to load moose in a pharo 1.2 image, Metacello is loading > (via ConfigurationOfMetacello) an ancient version of OB which is no > longer compatible with pharo 1.2 (at least for the use of > 'Preferences'). > Does anyone know if there is a version of metacello working for 1.2? > > > _______________________________________________ > 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 > > ...Except that when you do that, you may get Metacello work in progress. I am working on 1.0-beta.27.4 right now and you could end up with code that I am attempting to debug which could lead to unexpected results for you:) If you load in a version of OmniBrowser that is compatible with 1.2, before loading the Metacello UI that should work ... A safer course of action would be to do this...load the latest packages from OmniBrowser and then the latest _released_ version of Metacello: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfOmniBrowser'; package: 'ConfigurationOfMetacello'; load. then: (ConfigurationOfOmniBrowser project version: '1.1-baseline') load. (ConfigurationOfMetacello project latestVersion) load: 'UI'. You'll get an OmniBrowser that runs in 1.2 and the OB-Metacello tools. I've tried this and it appears to work fine... Dale

Sept. 1, 2010

Re: [Pharo-project] Linux vm default plugins directory

by Schwab,Wilhelm K

Bert, Eliot, FWIW, I have had terrible results with LD_LIBRARY_PATH on Ubuntu - maybe I'm just missing something. I probably should let the squeak script handle it, but it seems silly to use a script to call a script, so I've typically gone straight to the vm; that appears to be getting harder to do with time. About plugins not loading, my big point is that we should not have to guess about what is or is not happening. The vm does not provide enough information to reliably fix problems. Bill On 01.09.2010, at 21:12, Eliot Miranda wrote: > Hi Wilhelm, > > On Wed, Sep 1, 2010 at 12:01 PM, Schwab,Wilhelm K <bschwab at anest.ufl.edu> wrote: > >> A recurring theme is that I encounter a problem for which there is no explanation from the system, hack the vm sources to add some tracing, and correct the problem. As a result, I end up building the vm from source and so tend to use a shell script that runs it. >> > Set LD_LIBRARY_PATH to include the relevant directory. Here's the script I use at Teleplace The current "squeak" script fills in the plugins path, so there is no need to fiddle with LD_LIBRARY_PATH. http://squeakvm.org/svn/squeak/trunk/platforms/unix/cmake/squeak.in However, I occasionally too see a plugin that inexplicably does not want to load. - Bert -

Sept. 1, 2010

Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final

by Sven Van Caekenberghe

Andreas, Thanks a lot for taking the time to look into these problems and for the patches. Shouldn't we try to capture these problems with unit tests running across Squeak and its derivatives ? What would be the procedure to contribute to these tests ? Sven On 01 Sep 2010, at 06:16, Andreas Raab wrote: > Hi Sven - > > I had a quick look at the failing tests on Pharo and they seem mostly the result of bugs in Pharo's Network package. First, MimeDocument>>url needs to return an instance of Url not a string (check the senders; all users of it expect it to be a Url not a string) so if you change that to return a url it'll take care of the pathForFile issue. > > The failure of testMultiPartPost2 is a combination of two bugs in HTTPSocket. First, there's a typo in getResponseUpTo: at the end (this needs to be #copyFrom:to: (the "to" is missing the colon). Second, there is httpPostMultiPart: which adds an erroneous CrLf at the end of a persistent HTTP/1.1 connection. That causes an interesting series of things to go wrong (which I'm partly still investigating) but the easy solution is to insert a "Connection: close" header. > > Fixes attached. These are of course also broken in Pharo 1.0 and 1.1. > > Cheers, > - Andreas > > On 8/30/2010 2:17 AM, Sven Van Caekenberghe wrote: >> Hi Andreas, >> >> Thank you for clarifying your position and for pointing out the lack of a proper license for WebClient code. >> >> I and other people in the Pharo community made a mistake and we're sorry. We will be more careful in the future. >> >> But to our defense, as others pointed out, you're communications gave the impression that this was true open source, compatible with the standard Squeak one in spirit. >> >> Futhermore, and this to your credit as well, you yourself wrote the WebClient-Pharo package, giving the impression that you valued that port. It also proves that you did the actual effort. Thanks you! >> >> And indeed, you did incorporate some changes, so the intention was certainly there. >> >> Now, I would not say that we already actually forked the code. We just tried to port it. The process of following your progress proved difficult (you probably made a diff between your and our latest versions), precisely because of some of these little things like #asString, #utf8Encoding, #and:and:and:and:, but also some deeper ones like #pathForFile that kept coming back. >> >> You have every right to refuse to follow the Pharo Smalltalk spirit or style. I respect that, and the Pharo community as a whole should too. >> >> But your refusal to do so and the lack of a license give us no alternative than to look for other solutions. >> >> I wasn't there when the discussion that let to the birth of Pharo took place. But it is clear that the Smalltalk community is too small to not work together. >> >> The Smalltalk-80 inheritance and the enormeous contributions of the Squeak community over the years should be respected by all. At the same time you cannot ignore the positive effect that Pharo had since then. For me and many others, Pharo definitively has its place, along many other viable Smalltalk implementations. >> >> Regards, >> >> Sven >> >> On 30 Aug 2010, at 00:00, Andreas Raab wrote: >> >>> Hi Sven, >>> >>> [cc: pharo list since I think there are some larger issues to discuss] >>> >>> First of all thank you for your continued interest in WebClient. It is nice to see that people like to use it. However, I'm more than a bit surprised about what you are saying below about having WebClient in Pharo 1.2. Honestly, I was dumbfounded when I went to read some of the discussions on the Pharo list. >>> >>> May I ask what the due diligence process is for including packages in Pharo? I would have expected that the process includes 1) checking the project page on SS for the license and 2) sending the author a courtesy note along the lines of "hey we want to include your code, are you okay with that?" (in particular if the author of the package isn't on the Pharo list and consequently has no clue about what you're doing). >>> >>> 1. Regarding WebClient's license, please have a look at any of the following repositories, all of which are under MIT: >>> >>> http://www.squeaksource.com/Balloon3D.html >>> http://www.squeaksource.com/CroquetGL.html >>> http://www.squeaksource.com/ToolBuilder.html >>> http://www.squeaksource.com/TweakCore.html >>> ... etc ... >>> >>> As you can see, when I mean to put code under the MIT license, I try to state that by including a copy of the license on the front page of the repository as well as setting the license field. Contrary to, for example, the following repositories: >>> >>> http://www.squeaksource.com/ar.html >>> http://www.squeaksource.com/SqueakSSL.html >>> http://www.squeaksource.com/WebClient.html >>> >>> which are not (or not yet) under MIT. Obviously, I'm trying to be as clear as possible on these matters, which is why I was pointing out that your repository incorrectly claims that the version of WebClient in it is LGPLv2. I'm surprised (and shocked) that apparently nobody in Pharo even tries to find out what the license status for WebClient is. >>> >>> 2. Regarding my intentions / position you'll have to keep in mind that I don't read the Pharo list. I tried to follow it in the past only to be faced with several vicious attacks against Squeak and myself and as a consequence I stopped reading it. Consequently, this is the first time anyone has ever mentioned the inclusion of WebClient in Pharo to me. >>> >>> In short, my position is that we need more shared libraries, not more forks. You will probably see the irony that I specifically didn't set a license on WebClient to prevent such forks without any prior discussion (under the hopelessly naive assumption that there would be some sort of due diligence process) only to find out that you've forked WebClient already. How very ironic indeed. >>> >>> Because of my position above, I think WebClient should be an external package, loaded for example via Metacello configuration. In fact, that's exactly why I provided a Metacello configuration to begin with. Can someone perhaps explain where the urge to include (and consequently fork) WebClient comes from? WebClient is a perfectly good external package and for the time being I prefer it should stay that way. If you want to replace HTTPSocket, then have a look at Squeak 4.2 which contains a very simple HTTPSocket implementation that has hooks so that WebClient will be used if it's loaded. >>> >>> Regarding fixes for Pharo, as far as I know the only changes that I haven't included was a bunch of #asString sprinkled all over the places, and the abominations of replacing #squeakToUtf8 and #utf8ToSqueak with "convert[From|To]WithConverter: UTF8TextConverter new". On both of these issues I feel very strongly; I will not make the code substantially worse only to deal with shortcomings of Pharo. So if you cannot come to a reasonable resolution for these, you'll need the extension methods. Outside of that, I believe that not only have I integrated all the fixes that have been sent to me, I have also added several patches to WebClient-Pharo that provide important fixes for (in Pharo broken) network operations without which WebClient would not work in any released Pharo versions. >>> >>> Summary: >>> * I'm surprised and I'm shocked to see that there is apparently no due diligence regarding new packages in Pharo. I find this in particular shocking giving the wild claims on the Pharo web site that "From the beginning of Pharo we have maintained a strict rule that every contributor has to sign our license agreement." I haven't. (and geez, when did Michael got dropped from the Pharo board?) >>> >>> * I don't want WebClient to be included in Pharo since this means you will be producing a Pharo-only fork of WebClient which is counter-productive from my perspective. I want WebClient to remain a shared loadable package with a canonical source repository available to all forks of Squeak, including Pharo. >>> >>> * I have, and will continue to do so, integrate fixes for Pharo as long as I consider them reasonable. If there is interest, I can also provide an updated Metacello configuration; although that really just boils down to updating it to the latest package versions. >>> >>> Cheers, >>> - Andreas >> >> > <NetworkFixes-ar.1.cs>

Sept. 1, 2010

Re: [Pharo-project] Serial ports on Linux

by Schwab,Wilhelm K

Markus, If you have some experience with serial I/O on Linux, I would appreciate your giving it a quick shakedown; if it is just plain broken or is still known to work, it would be nice to confirm either way. I would like to use the binary distribution, but it does not report enough of what it is trying to do (so no clues when things fail) and I end up hacking to add tracing with possible installation troubles as a result. That said, this time around, I find myself in serialPortOpenByName() and puzzled by the failure being allegedly detected by: /* save the old state */ if (tcgetattr(sp->spDescriptor, &sp->spTermios)) My question: is there old state to save on the first pass? errno is not helpful; it is set to 5 aka I/O error :( I find myself wondering whether this should be conditional on the internal state of the descriptor, and the failure to open simply being that it gives up too easily? Then again, it could be detecting a true error condition and preventing certain disaster in the lines that would follow. Any ideas? I can't get /dev/ttyS0 to open by name or number. 'COM1' worked nicely on Windows. Bill Markus Lampert markuslampert at yahoo.com Wed Sep 1 15:28:38 UTC 2010 Hi Bill, haven't used the serial interface with the new VMs (yet), but previously under Linux I had to use the vm option '-notimer'. I did not find any negative side effects with that option. Hope this helps, Markus

Sept. 1, 2010

Re: [Pharo-project] Please help!! Error: There is no free space in this set!'

by Mariano Martinez Peck

2010/9/1 Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> > The error no free space in set should be fixed in 1.1. > Except abysmal performance, what problem do you have exactly? > I am not talking about performance. I am talking that it just raise that error. What I do particulary in SqueakDBX (it is optional thus) is that when a Connection is created, it is added to WeakRegistry default so that I can implement #finalize and this method releases the database connection if it was not already done. This is for possible bugs or developers where they don't cal correctly yhe#disconnect method. Of course, if you use the pool you won't have this problem (depending how many connections you define in the pool as max). Anyway, while running tests, I create a lot of connections, thus, I get the error "There is no free space in this set!'" when the code tries to add the connection to the WeakRegistry. Thanks Henry. mariano > > Cheers, > Henry > > > On 01.09.2010 16:41, Mariano Martinez Peck wrote: > > So....any helpers? > > http://code.google.com/p/pharo/issues/detail?id=2551 > http://code.google.com/p/pharo/issues/detail?id=1628 > > I would like to help, but I am 100% newbie in this. Please consider me as > tester. > > Cheers > > mariano > > 2010/8/5 Miguel Enrique CobÃ¡ MartÃnez <miguel.coba(a)gmail.com> > >> El jue, 05-08-2010 a las 21:35 +0200, Mariano Martinez Peck escribiÃ³: >> > I know this is a alraedy known issue: >> > http://code.google.com/p/pharo/issues/detail?id=1628 >> > I am trying to make SqueakDBX work in 1.1 and it doesn't work because >> > of this. Each DBXConnection is registered in the WeakRegistry just to >> > close the database connection in case they don't do it explicitly. >> > >> > This this, I have a: >> > >> > addObjectToGarbageCollect: anObject >> > >> > WeakRegistry default add: anObject. >> > >> > >> > And in DBXConnetion >> connect, I call that method. >> > >> > Do you know how to solve the problem? I read the issue but I am >> > uncertain what should I do nor if it is fixed. I think this bug is >> > really important. >> >> Not a solution sorry, but a suggestion (or maybe this is already >> implemented, I haven't used SqueakDBX). :) >> >> Maybe it would be useful to add a pool for the connections so they >> aren't so many at the same time. Also, the database admin will be >> grateful. >> >> Cheers >> >> >> > >> > Thanks >> > >> > Mariano >> > _______________________________________________ >> > 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 >> >> >> _______________________________________________ >> 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 listPharo-project@lists.gforge.inria.frhttp://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 >

Sept. 1, 2010

Re: [Pharo-project] Please help!! Error: There is no free space in this set!'

by Henrik Sperre Johansen

The error no free space in set should be fixed in 1.1. Except abysmal performance, what problem do you have exactly? Cheers, Henry On 01.09.2010 16:41, Mariano Martinez Peck wrote: > So....any helpers? > > http://code.google.com/p/pharo/issues/detail?id=2551 > <http://code.google.com/p/pharo/issues/detail?id=2551> > http://code.google.com/p/pharo/issues/detail?id=1628 > <http://code.google.com/p/pharo/issues/detail?id=1628> > > I would like to help, but I am 100% newbie in this. Please consider me > as tester. > > Cheers > > mariano > > 2010/8/5 Miguel Enrique CobÃ¡ MartÃnez <miguel.coba(a)gmail.com > <mailto:miguel.coba@gmail.com>> > > El jue, 05-08-2010 a las 21:35 +0200, Mariano Martinez Peck escribiÃ³: > > I know this is a alraedy known issue: > > http://code.google.com/p/pharo/issues/detail?id=1628 > > I am trying to make SqueakDBX work in 1.1 and it doesn't work > because > > of this. Each DBXConnection is registered in the WeakRegistry > just to > > close the database connection in case they don't do it explicitly. > > > > This this, I have a: > > > > addObjectToGarbageCollect: anObject > > > > WeakRegistry default add: anObject. > > > > > > And in DBXConnetion >> connect, I call that method. > > > > Do you know how to solve the problem? I read the issue but I am > > uncertain what should I do nor if it is fixed. I think this bug is > > really important. > > Not a solution sorry, but a suggestion (or maybe this is already > implemented, I haven't used SqueakDBX). :) > > Maybe it would be useful to add a pool for the connections so they > aren't so many at the same time. Also, the database admin will be > grateful. > > Cheers > > > > > > Thanks > > > > Mariano > > _______________________________________________ > > 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 > > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > 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 > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 1, 2010

Re: [Pharo-project] Fwd: [squeak-dev] The Trunk: System-eem.366.mcz

by Adrian Lienhard

I created a changeset and attached it to the appropriate ticket: http://code.google.com/p/pharo/issues/detail?id=2896 Adrian On Sep 1, 2010, at 09:52 , StÃ©phane Ducasse wrote: > seems like we should do something :) > > Begin forwarded message: > >> From: John M McIntosh <johnmci(a)smalltalkconsulting.com> >> Date: September 1, 2010 1:12:28 AM GMT+02:00 >> To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> Subject: Fwd: [squeak-dev] The Trunk: System-eem.366.mcz >> Reply-To: johnmci(a)smalltalkconsulting.com >> >> In case this gets overlooked being hidden in a update for The Trunk: System-eem. >> >> The EndianCache does need to be cleared at shutdown versus in startup. >> I can't speak for the SystemChangeNotifier since I'm not sure what the bug is.. >> >> Of course I'm not quite sure if anyone in the Pharo group looks and the trunk updates and moves things across? >> >> >> Begin forwarded message: >> >>> From: commits(a)source.squeak.org >>> Date: August 31, 2010 5:47:35 PM PDT >>> To: squeak-dev(a)lists.squeakfoundation.org, packages(a)lists.squeakfoundation.org >>> Subject: [squeak-dev] The Trunk: System-eem.366.mcz >>> Reply-To: squeak-dev(a)lists.squeakfoundation.org >>> >>> Eliot Miranda uploaded a new version of System to project The Trunk: >>> http://source.squeak.org/trunk/System-eem.366.mcz >>> >>> ==================== Summary ==================== >>> >>> Name: System-eem.366 >>> Author: eem >>> Time: 31 August 2010, 10:47:17.97 am >>> UUID: 2126e5d9-4d47-4cc1-921f-daefd935aedd >>> Ancestors: System-nice.365 >>> >>> Make sure system notifications for Smalltalk are up-to-date >>> on start-up. >>> Fix voiding of Smalltalk's endian cache which needs to be done >>> in a timely manner. >>> >>> =============== Diff against System-nice.365 =============== >>> >>> Item was changed: >>> ----- Method: SmalltalkImage class>>startUp (in category 'class initialization') ----- >>> startUp >>> + SystemChangeNotifier uniqueInstance notify: Smalltalk ofAllSystemChangesUsing: #event:! >>> - "XXXX: This is broken. SmalltalkImage startUp happens quite late in the startup sequence; earlier startups may very well need the information about the endianness of the platform." >>> - EndianCache := nil. >>> - ! >>> >>> Item was changed: >>> ----- Method: SmalltalkImage>>processShutDownList: (in category 'snapshot and quit') ----- >>> processShutDownList: quitting >>> + "Send #shutDown to each class that needs to wrap up before a snapshot. >>> + Also void the endianness chace; this can't safely be done on start-up because >>> + Smalltalk is too late in the start-up sequence." >>> - "Send #shutDown to each class that needs to wrap up before a snapshot." >>> >>> + EndianCache := nil. >>> + self send: #shutDown: toClassesNamedIn: ShutDownList with: quitting! >>> - self send: #shutDown: toClassesNamedIn: ShutDownList with: quitting. >>> - ! >>> >>> >> >> -- >> =========================================================================== >> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 >> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >> =========================================================================== >> >> >> >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 1, 2010

[Pharo-project] Linux vm default plugins directory

by Schwab,Wilhelm K

A recurring theme is that I encounter a problem for which there is no explanation from the system, hack the vm sources to add some tracing, and correct the problem. As a result, I end up building the vm from source and so tend to use a shell script that runs it. FWIW, without a -plugins option, this is what happens with the current sources: Load failed for: /usr/local/lib/squeak/4.0.3-2202//so.vm-sound-OSS Load failed for: /usr/local/lib/squeak/4.0.3-2202//so.vm-sound-MacOSX Load failed for: /usr/local/lib/squeak/4.0.3-2202//so.vm-sound-Sun Load failed for: /usr/local/lib/squeak/4.0.3-2202//so.vm-sound-pulse Load failed for: /usr/local/lib/squeak/4.0.3-2202//so.vm-sound-ALSA Load failed for: /usr/local/lib/squeak/4.0.3-2202//so.MiscPrimitivePlugin Load failed for: /usr/local/lib/squeak/4.0.3-2202//so.FilePlugin Load failed for: /usr/local/lib/squeak/4.0.3-2202//so.SecurityPlugin Load failed for: /usr/local/lib/squeak/4.0.3-2202//so.LargeIntegers Load failed for: /usr/local/lib/squeak/4.0.3-2202//so.BitBltPlugin Load failed for: /usr/local/lib/squeak/4.0.3-2202//so.B2DPlugin Load failed for: /usr/local/lib/squeak/4.0.3-2202//so.LocalePlugin Load failed for: /usr/local/lib/squeak/4.0.3-2202//so.SocketPlugin Load failed for: /usr/local/lib/squeak/4.0.3-2202//so.FloatArrayPlugin Load failed for: /usr/local/lib/squeak/4.0.3-2202//so.Matrix2x3Plugin Note the extra / in the paths. Some of the plugins should fail to load; the point is that *all* of them fail to load. Bill

Sept. 1, 2010

Re: [Pharo-project] MethodName

by Marcus Denker

On Sep 1, 2010, at 8:09 PM, Alexandre Bergel wrote: > I have a 12121, it works very well! > I will use it. > > Is there a configuration I can use instead of the gofer invocation? Why? Does it depend on strange things? Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Sept. 1, 2010