February 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] 1.4 - better from Jenkins

by Benoit St-Jean

Before we even get to the details, we should make sure we all exchange on a polite and non agressive tone. That being said, I don't think Bill is whining.Â You never hear people who don't care.Â I don't give a damn about product X, environment Y and programming language Z.Â That's why I never complain (or whine) about X, Y or Z.Â On the other hand, that's why you'll hear me complain about Smalltalk, Pharo, mathematics and a few other topics.Â Why?Â Because I care! Saying stuff don't work shouldn't be perceived as an ad hominem attack.Â It just shows someone, somewhere, somehow had an interest to say it so it gets fixed.Â And please, no "if you're no happy why don't you fix it and contribute" answer...Â This is the kind of answer that made me walk away from Pharo at a certain point... If we can't take critics/bugs/suggestions/tickets/whatever without entering a "defensive mode", we won't get far. Let's keep it cool and remember that nobody forced anyone to use Pharo and read this mailing list and take the time to post. We're all here because we do care! Â ----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein) >________________________________ > From: Dale Henrichs <dhenrich(a)vmware.com> >To: Pharo-project(a)lists.gforge.inria.fr >Sent: Thursday, February 9, 2012 8:33:20 PM >Subject: Re: [Pharo-project] 1.4 - better from Jenkins > >Bill, > >The last time you complained about Metacello being broken I asked you for a stack trace and I have seen no stack trace, although I believe that you were able to confirm that Metacello worked fine until you loaded some of your own code into the system ... > >Here you are complaining again ... if you don't provide specifics, the issues cannot be resolved ... > >There are apparently a lot of moving parts in your system, so it takes great attention to detail to get such a system running smoothly. The fact that you don't provide specifics tells me that perhaps you are not paying attention to the details ... > >When you are porting to a new environment (for you) like Pharo 1.4, you should stop and isolate the FIRST ERROR that you encounter ... in a complicated system once an error occurs, all bets are off ... You MUST pay attention to details ... > >You state that you have a giant debug log ... so it sounds like you tried to keep moving forward in the face of initial errors...I say good luck with that approach! > >If you post a Metacello stack trace I can very likely tell you what went wrong, if you prefer to continue to whine and complain about Metacello without even attempting to help me characterize the issues, then I will leave you to your own devices and you can can complain about Metacello all you want --- I won't be paying attention any more:) > >Dale > > >----- Original Message ----- >| From: "Wilhelm K Schwab" <bschwab(a)anest.ufl.edu> >| To: Pharo-project(a)lists.gforge.inria.fr >| Sent: Thursday, February 9, 2012 4:26:27 PM >| Subject: Re: [Pharo-project] 1.4 - better from Jenkins >| >| I think you might be right about loading the .mcz files.Â But I don't >| have an expectation other than what has been said here many times: >| that Metacello is the future.Â So far, I don't see it. >| >| Bill >| >| >| ________________________________________ >| From: pharo-project-bounces(a)lists.gforge.inria.fr >| [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Yanni >| Chiu [yanni(a)rogers.com] >| Sent: Thursday, February 09, 2012 6:22 PM >| To: pharo-project(a)lists.gforge.inria.fr >| Subject: Re: [Pharo-project] 1.4 - better from Jenkins >| >| On 09/02/12 5:39 PM, Schwab,Wilhelm K wrote: >| > Sven, >| > >| > Fair enough, but the game plan is for people to use Metacello >| > configurations to load what they need to build an image.Â I am >| > attempting to do just that, and am reporting (rather negative so >| > far) experience, with debug logs. >| > >| > Pharo's fault or not, something is broken.Â But if Pharo is going >| > to send users into the current state of Metacello, the weather >| > around the lighthouse is going to be grim. >| > >| > Interesting ideas about the package cache being damaged.Â Maybe the >| > logs will reveal something?? >| >| You might want to check the package cache for 0-length .mcz files, >| which >| might happen when the server is down. >| >| When I upgrade to a new image version, I just start my build process >| with the new image, and cross my fingers. If it fails, then I do it >| manually with the build script in a workspace - select each >| framework/package and "doIt". Sometimes I run the framework's tests, >| after each step. >| >| I load all "community" code first, unless I have extensions to this >| code. Sometimes I've had to upgrade to a newer version of the >| framework, >| if available. At other times, I had to create patches because I was >| tracking the Pharo updates (so no fixed version was available yet). >| >| In extreme cases, I've had to generate the list of packages that >| Metacello would load, then load each .mcz individually. >| >| Typically, I'd do "save image as" at various points, to be able to >| get >| back to the problem code, more quickly. >| >| I think you're pretty much following a similar process, except the >| expectation that a Metacello configuration should just load without >| problems on Pharo1.4-unstable is too optimistic. >| >| >| >| > > > >

Feb. 10, 2012

Re: [Pharo-project] 1.4 - better from Jenkins

by Dale Henrichs

Bill, The last time you complained about Metacello being broken I asked you for a stack trace and I have seen no stack trace, although I believe that you were able to confirm that Metacello worked fine until you loaded some of your own code into the system ... Here you are complaining again ... if you don't provide specifics, the issues cannot be resolved ... There are apparently a lot of moving parts in your system, so it takes great attention to detail to get such a system running smoothly. The fact that you don't provide specifics tells me that perhaps you are not paying attention to the details ... When you are porting to a new environment (for you) like Pharo 1.4, you should stop and isolate the FIRST ERROR that you encounter ... in a complicated system once an error occurs, all bets are off ... You MUST pay attention to details ... You state that you have a giant debug log ... so it sounds like you tried to keep moving forward in the face of initial errors...I say good luck with that approach! If you post a Metacello stack trace I can very likely tell you what went wrong, if you prefer to continue to whine and complain about Metacello without even attempting to help me characterize the issues, then I will leave you to your own devices and you can can complain about Metacello all you want --- I won't be paying attention any more:) Dale ----- Original Message ----- | From: "Wilhelm K Schwab" <bschwab(a)anest.ufl.edu> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Thursday, February 9, 2012 4:26:27 PM | Subject: Re: [Pharo-project] 1.4 - better from Jenkins | | I think you might be right about loading the .mcz files. But I don't | have an expectation other than what has been said here many times: | that Metacello is the future. So far, I don't see it. | | Bill | | | ________________________________________ | From: pharo-project-bounces(a)lists.gforge.inria.fr | [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Yanni | Chiu [yanni(a)rogers.com] | Sent: Thursday, February 09, 2012 6:22 PM | To: pharo-project(a)lists.gforge.inria.fr | Subject: Re: [Pharo-project] 1.4 - better from Jenkins | | On 09/02/12 5:39 PM, Schwab,Wilhelm K wrote: | > Sven, | > | > Fair enough, but the game plan is for people to use Metacello | > configurations to load what they need to build an image. I am | > attempting to do just that, and am reporting (rather negative so | > far) experience, with debug logs. | > | > Pharo's fault or not, something is broken. But if Pharo is going | > to send users into the current state of Metacello, the weather | > around the lighthouse is going to be grim. | > | > Interesting ideas about the package cache being damaged. Maybe the | > logs will reveal something?? | | You might want to check the package cache for 0-length .mcz files, | which | might happen when the server is down. | | When I upgrade to a new image version, I just start my build process | with the new image, and cross my fingers. If it fails, then I do it | manually with the build script in a workspace - select each | framework/package and "doIt". Sometimes I run the framework's tests, | after each step. | | I load all "community" code first, unless I have extensions to this | code. Sometimes I've had to upgrade to a newer version of the | framework, | if available. At other times, I had to create patches because I was | tracking the Pharo updates (so no fixed version was available yet). | | In extreme cases, I've had to generate the list of packages that | Metacello would load, then load each .mcz individually. | | Typically, I'd do "save image as" at various points, to be able to | get | back to the problem code, more quickly. | | I think you're pretty much following a similar process, except the | expectation that a Metacello configuration should just load without | problems on Pharo1.4-unstable is too optimistic. | | | |

Feb. 10, 2012

Re: [Pharo-project] ss3.gemstone.com

by GermÃ¡n Arduino

I am moving my projects from ss with no problems until now. Always available! 2012/2/9, Alexandre Bergel <alexandre.bergel(a)me.com>: > Hi! > > The main page of ss3.gemstone.com gives an "Important Announcement > (September 7, 2011)". Does it make sense to have it still? > > The website is apparently in alpha. Isn't it ready for a release? > > Has anyone experienced some problem with it? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > -- Enviado desde mi dispositivo mÃ³vil ============================================ GermÃ¡n S. Arduino <gsa @ arsol.net> Twitter: garduino Arduino Software http://www.arduinosoftware.com PasswordsPro http://www.passwordspro.com greensecure.blogspot.com germanarduino.blogpost.com ============================================

Feb. 10, 2012

Re: [Pharo-project] ss3.gemstone.com

by Dale Henrichs

Tobias has fixed a number of issues that have been reported for the site[1], but there are still a handful of open issues[2] that need to be addressed. There is a task list[3] for the upgrade process that is tracking the status of the upgrade process ... For the most part we need to get some bugs fixed and some tests written before performing the upgrade. As you have noted the site is stable modulo the existing issues and I don't want to destabilize things with the upgrade ... Dale [1] http://code.google.com/p/squeaksource3/issues/list?can=1&q=status%3AVerifie… [2] http://code.google.com/p/squeaksource3/issues/list?can=2&q=Milestone%3D3.0-… [3] http://code.google.com/p/squeaksource3/issues/list?can=2&q=Milestone%3D3.0-… ----- Original Message ----- | From: "Alexandre Bergel" <alexandre.bergel(a)me.com> | To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> | Sent: Thursday, February 9, 2012 4:16:27 PM | Subject: [Pharo-project] ss3.gemstone.com | | Hi! | | The main page of ss3.gemstone.com gives an "Important Announcement | (September 7, 2011)". Does it make sense to have it still? | | The website is apparently in alpha. Isn't it ready for a release? | | Has anyone experienced some problem with it? | | Cheers, | Alexandre | -- | _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: | Alexandre Bergel http://www.bergel.eu | ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. | | | | | | |

Feb. 10, 2012

Re: [Pharo-project] 1.4 - better from Jenkins

by Schwab,Wilhelm K

Just checked: no zero-length files. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Yanni Chiu [yanni(a)rogers.com] Sent: Thursday, February 09, 2012 6:22 PM To: pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] 1.4 - better from Jenkins On 09/02/12 5:39 PM, Schwab,Wilhelm K wrote: > Sven, > > Fair enough, but the game plan is for people to use Metacello configurations to load what they need to build an image. I am attempting to do just that, and am reporting (rather negative so far) experience, with debug logs. > > Pharo's fault or not, something is broken. But if Pharo is going to send users into the current state of Metacello, the weather around the lighthouse is going to be grim. > > Interesting ideas about the package cache being damaged. Maybe the logs will reveal something?? You might want to check the package cache for 0-length .mcz files, which might happen when the server is down. When I upgrade to a new image version, I just start my build process with the new image, and cross my fingers. If it fails, then I do it manually with the build script in a workspace - select each framework/package and "doIt". Sometimes I run the framework's tests, after each step. I load all "community" code first, unless I have extensions to this code. Sometimes I've had to upgrade to a newer version of the framework, if available. At other times, I had to create patches because I was tracking the Pharo updates (so no fixed version was available yet). In extreme cases, I've had to generate the list of packages that Metacello would load, then load each .mcz individually. Typically, I'd do "save image as" at various points, to be able to get back to the problem code, more quickly. I think you're pretty much following a similar process, except the expectation that a Metacello configuration should just load without problems on Pharo1.4-unstable is too optimistic.

Feb. 10, 2012

Re: [Pharo-project] 1.4 - better from Jenkins

by Schwab,Wilhelm K

I think you might be right about loading the .mcz files. But I don't have an expectation other than what has been said here many times: that Metacello is the future. So far, I don't see it. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Yanni Chiu [yanni(a)rogers.com] Sent: Thursday, February 09, 2012 6:22 PM To: pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] 1.4 - better from Jenkins On 09/02/12 5:39 PM, Schwab,Wilhelm K wrote: > Sven, > > Fair enough, but the game plan is for people to use Metacello configurations to load what they need to build an image. I am attempting to do just that, and am reporting (rather negative so far) experience, with debug logs. > > Pharo's fault or not, something is broken. But if Pharo is going to send users into the current state of Metacello, the weather around the lighthouse is going to be grim. > > Interesting ideas about the package cache being damaged. Maybe the logs will reveal something?? You might want to check the package cache for 0-length .mcz files, which might happen when the server is down. When I upgrade to a new image version, I just start my build process with the new image, and cross my fingers. If it fails, then I do it manually with the build script in a workspace - select each framework/package and "doIt". Sometimes I run the framework's tests, after each step. I load all "community" code first, unless I have extensions to this code. Sometimes I've had to upgrade to a newer version of the framework, if available. At other times, I had to create patches because I was tracking the Pharo updates (so no fixed version was available yet). In extreme cases, I've had to generate the list of packages that Metacello would load, then load each .mcz individually. Typically, I'd do "save image as" at various points, to be able to get back to the problem code, more quickly. I think you're pretty much following a similar process, except the expectation that a Metacello configuration should just load without problems on Pharo1.4-unstable is too optimistic.

Feb. 10, 2012

[Pharo-project] ss3.gemstone.com

by Alexandre Bergel

Hi! The main page of ss3.gemstone.com gives an "Important Announcement (September 7, 2011)". Does it make sense to have it still? The website is apparently in alpha. Isn't it ready for a release? Has anyone experienced some problem with it? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 10, 2012

[Pharo-project] Is there an adhoc header field in Fuel?

by Yanni Chiu

I'd like to store some metadata in a Fuel serialized file. I'd like to be able to read that metadata, without de-serializing the file. So, if there were a fixed header at the start of the file, with some "unused" fields, that would be ideal.

Feb. 9, 2012

Re: [Pharo-project] 1.4 - better from Jenkins

by Yanni Chiu

On 09/02/12 5:39 PM, Schwab,Wilhelm K wrote: > Sven, > > Fair enough, but the game plan is for people to use Metacello configurations to load what they need to build an image. I am attempting to do just that, and am reporting (rather negative so far) experience, with debug logs. > > Pharo's fault or not, something is broken. But if Pharo is going to send users into the current state of Metacello, the weather around the lighthouse is going to be grim. > > Interesting ideas about the package cache being damaged. Maybe the logs will reveal something?? You might want to check the package cache for 0-length .mcz files, which might happen when the server is down. When I upgrade to a new image version, I just start my build process with the new image, and cross my fingers. If it fails, then I do it manually with the build script in a workspace - select each framework/package and "doIt". Sometimes I run the framework's tests, after each step. I load all "community" code first, unless I have extensions to this code. Sometimes I've had to upgrade to a newer version of the framework, if available. At other times, I had to create patches because I was tracking the Pharo updates (so no fixed version was available yet). In extreme cases, I've had to generate the list of packages that Metacello would load, then load each .mcz individually. Typically, I'd do "save image as" at various points, to be able to get back to the problem code, more quickly. I think you're pretty much following a similar process, except the expectation that a Metacello configuration should just load without problems on Pharo1.4-unstable is too optimistic.

Feb. 9, 2012

Re: [Pharo-project] 1.4 - better from Jenkins

by Schwab,Wilhelm K

Sven, Fair enough, but the game plan is for people to use Metacello configurations to load what they need to build an image. I am attempting to do just that, and am reporting (rather negative so far) experience, with debug logs. Pharo's fault or not, something is broken. But if Pharo is going to send users into the current state of Metacello, the weather around the lighthouse is going to be grim. Interesting ideas about the package cache being damaged. Maybe the logs will reveal something?? Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Sven Van Caekenberghe [sven(a)beta9.be] Sent: Thursday, February 09, 2012 5:14 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] 1.4 - better from Jenkins On 09 Feb 2012, at 22:27, Schwab,Wilhelm K wrote: > My new 1.4 image is behaving a *little* better than its predecessors, but there is still a problem. It seems to happen after invoking Metacello loads, even with the mirror. Odd behaviors include: > > (1) can't open debugger > (2) can't open process browser > (3) intermittent flashing/alternating cursors in text editors. > > Whatever happens, it seems to be saved into the image as MC works, because killing the image and reloading results in a hobbled system. > > At least with 1.4, I can sometimes break into a debugger, presumably because something is busy in a tight loop. That might be a/the parser?? > > BTW, in an hour (max) of playing around, I've generated a 38 MB debug log - too big to read :( There are mentions of a parser, but my grep creativity has not allowed me to pull out any useful information. Perhaps I can start over with a clean log, let it get into some trouble, and review the log at a smaller size. > > Suggestions? Some remarks: - if you load code and it fails for whatever reason, and there was no hidden save somewhere, I would be extremely surprised if killing the image (clean or otherwise) would result in permanent damage; the only side effect could be in your filesystem (local package cache), but even that would normally not hurt the image itself - you are obviously loading lots of stuff: when this does not work, that is not 'Pharo's fault', you should ask the people who wrote these libraries for help (maybe through this list); you can't call gcc crap or unstable when a certain library fails - when you are reporting bugs and ask for help, you really have to bring your problem down to a simple test case that others can reproduce; even if people would want to help you, they cannot do so with these generalizations Sven

Feb. 9, 2012