[Pharo-project] 1.4 - better from Jenkins
I grabbed 1.4 and cog/unix from jenkins, dumped all the files in one directory, made a shell script to run the image using Cog, and all I can say is "wow." The usability problems I was having are gone. In particular, the context menus work. I loaded Migrate and set preferences, with a really nice appearance resulting. One question: why did ClassDescription>>package go away? That seems to be a really useful message. I'll try to build an image using the SqueakSource mirror. No promises, but 1.4 "suddenly" looks a LOT more polished than it did. Are the links on the Pharo page old, or did somebody just do a lot of work to make things better? Bill
I just downloaded the latest CogWin and Pharo 1.4 image and I got "WARNING: Manufactured file handle detected!" at the bottom, and popup full of startup errors. But! It's all actually very friendly! I can look through the errors and try to figure out what caused them. It's way cleaner than the old style mega-DNU-stacks. Nice work! On Thu, Feb 9, 2012 at 11:06 AM, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
I grabbed 1.4 and cog/unix from jenkins, dumped all the files in one directory, made a shell script to run the image using Cog, and all I can say is "wow."
The usability problems I was having are gone. In particular, the context menus work. I loaded Migrate and set preferences, with a really nice appearance resulting.
One question: why did ClassDescription>>package go away? That seems to be a really useful message.
I'll try to build an image using the SqueakSource mirror. No promises, but 1.4 "suddenly" looks a LOT more polished than it did. Are the links on the Pharo page old, or did somebody just do a lot of work to make things better?
Bill
One snag: I'm still getting strangely broken images (won't open process browser or debugger) after trying to download some things. I have mirrored squeak source, BUT, some things (SIXX, ODBC) don't appear to have working configs, so I'm trying to grab the latest packages, and *that* might not be mirrored. I might need to specify the mirror server in my code to make them work. Still, I don't get how simply asking MC to download something will permanently mar the image w/o my doing an explicit save. Does MC snapshot before/during an attempted load? It seems very misguided that an innocent attempt to load something can hobble an image?? One other crazy possibility: is killing a vm from the (Ubunutu) system monitor somehow not sufficient to clear what is running? Dumb question? Maybe, but I'm stumped. Any ideas? Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of blake [dsblakewatson@gmail.com] Sent: Thursday, February 09, 2012 2:58 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] 1.4 - better from Jenkins I just downloaded the latest CogWin and Pharo 1.4 image and I got "WARNING: Manufactured file handle detected!" at the bottom, and popup full of startup errors. But! It's all actually very friendly! I can look through the errors and try to figure out what caused them. It's way cleaner than the old style mega-DNU-stacks. Nice work! On Thu, Feb 9, 2012 at 11:06 AM, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
I grabbed 1.4 and cog/unix from jenkins, dumped all the files in one directory, made a shell script to run the image using Cog, and all I can say is "wow."
The usability problems I was having are gone. In particular, the context menus work. I loaded Migrate and set preferences, with a really nice appearance resulting.
One question: why did ClassDescription>>package go away? That seems to be a really useful message.
I'll try to build an image using the SqueakSource mirror. No promises, but 1.4 "suddenly" looks a LOT more polished than it did. Are the links on the Pharo page old, or did somebody just do a lot of work to make things better?
Bill
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? Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K [bschwab@anest.ufl.edu] Sent: Thursday, February 09, 2012 3:15 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] 1.4 - better from Jenkins One snag: I'm still getting strangely broken images (won't open process browser or debugger) after trying to download some things. I have mirrored squeak source, BUT, some things (SIXX, ODBC) don't appear to have working configs, so I'm trying to grab the latest packages, and *that* might not be mirrored. I might need to specify the mirror server in my code to make them work. Still, I don't get how simply asking MC to download something will permanently mar the image w/o my doing an explicit save. Does MC snapshot before/during an attempted load? It seems very misguided that an innocent attempt to load something can hobble an image?? One other crazy possibility: is killing a vm from the (Ubunutu) system monitor somehow not sufficient to clear what is running? Dumb question? Maybe, but I'm stumped. Any ideas? Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of blake [dsblakewatson@gmail.com] Sent: Thursday, February 09, 2012 2:58 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] 1.4 - better from Jenkins I just downloaded the latest CogWin and Pharo 1.4 image and I got "WARNING: Manufactured file handle detected!" at the bottom, and popup full of startup errors. But! It's all actually very friendly! I can look through the errors and try to figure out what caused them. It's way cleaner than the old style mega-DNU-stacks. Nice work! On Thu, Feb 9, 2012 at 11:06 AM, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
I grabbed 1.4 and cog/unix from jenkins, dumped all the files in one directory, made a shell script to run the image using Cog, and all I can say is "wow."
The usability problems I was having are gone. In particular, the context menus work. I loaded Migrate and set preferences, with a really nice appearance resulting.
One question: why did ClassDescription>>package go away? That seems to be a really useful message.
I'll try to build an image using the SqueakSource mirror. No promises, but 1.4 "suddenly" looks a LOT more polished than it did. Are the links on the Pharo page old, or did somebody just do a lot of work to make things better?
Bill
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
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@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Sven Van Caekenberghe [sven@beta9.be] Sent: Thursday, February 09, 2012 5:14 PM To: Pharo-project@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
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.
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@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Yanni Chiu [yanni@rogers.com] Sent: Thursday, February 09, 2012 6:22 PM To: pharo-project@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.
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@anest.ufl.edu> | To: Pharo-project@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@lists.gforge.inria.fr | [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Yanni | Chiu [yanni@rogers.com] | Sent: Thursday, February 09, 2012 6:22 PM | To: pharo-project@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. | | | |
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@vmware.com> To: Pharo-project@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@anest.ufl.edu> | To: Pharo-project@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@lists.gforge.inria.fr | [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Yanni | Chiu [yanni@rogers.com] | Sent: Thursday, February 09, 2012 6:22 PM | To: pharo-project@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. | | | |
Of course you are right ... if one has nothing constructive to say, then one shouldn't say anything at all:) Dale ----- Original Message ----- | From: "Benoit St-Jean" <bstjean@yahoo.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Thursday, February 9, 2012 5:59:40 PM | Subject: Re: [Pharo-project] 1.4 - better from Jenkins | | | | 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@vmware.com> | To: Pharo-project@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@anest.ufl.edu > | | To: Pharo-project@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@lists.gforge.inria.fr | | [ pharo-project-bounces@lists.gforge.inria.fr ] on behalf of Yanni | | Chiu [ yanni@rogers.com ] | | Sent: Thursday, February 09, 2012 6:22 PM | | To: pharo-project@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. | | | | | | | | | | | |
Thanks for that. I *do* care, which is why I'm trying to actually use this stuff. Well said. ________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Benoit St-Jean [bstjean@yahoo.com] Sent: Thursday, February 09, 2012 8:59 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] 1.4 - better from Jenkins 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@vmware.com> To: Pharo-project@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@anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> | To: Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@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@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> | [pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] on behalf of Yanni | Chiu [yanni@rogers.com<mailto:yanni@rogers.com>] | Sent: Thursday, February 09, 2012 6:22 PM | To: pharo-project@lists.gforge.inria.fr<mailto:pharo-project@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. | | | |
Hi benoit I think that this is clear to everybody :) Now I would like to be able to help and for that we need a case. Stef On Feb 10, 2012, at 2:59 AM, Benoit St-Jean wrote:
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@vmware.com> To: Pharo-project@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@anest.ufl.edu> | To: Pharo-project@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@lists.gforge.inria.fr | [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Yanni | Chiu [yanni@rogers.com] | Sent: Thursday, February 09, 2012 6:22 PM | To: pharo-project@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. | | | |
Dale, I'm not "complaining," I'm stating facts and asking for advice. Not only did I state that I produced a "big" debug log, I also POSTED a smaller one. If you mean something different by a "stack trace," can you provide some instructions for how to obtain it? As for "continuing beyond errors" - AFAIK, *I* am not saving the image in a confused state, but *something* appears to be doing just that. Yes, I "ignored errors" in the sense that I used the task manager to kill off an image that was flailing trying to download packages, and was mystified to discover that, without an explicit save on my part, the image "woke up" trying to do the same fruitless exercise. Several iterations of trying to unravel that led to the large log. I then removed the log, did one cycle, and posted the log from that. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Dale Henrichs [dhenrich@vmware.com] Sent: Thursday, February 09, 2012 8:33 PM To: Pharo-project@lists.gforge.inria.fr 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@anest.ufl.edu> | To: Pharo-project@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@lists.gforge.inria.fr | [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Yanni | Chiu [yanni@rogers.com] | Sent: Thursday, February 09, 2012 6:22 PM | To: pharo-project@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. | | | |
Bill, I guess I missed the Metacello stack and I can't seem to find it... if you could point me to the post with your Metacello stack in it I will be glad to take a loook. Dale ----- Original Message ----- | From: "Wilhelm K Schwab" <bschwab@anest.ufl.edu> | To: Pharo-project@lists.gforge.inria.fr | Sent: Friday, February 10, 2012 2:21:30 AM | Subject: Re: [Pharo-project] 1.4 - better from Jenkins | | Dale, | | I'm not "complaining," I'm stating facts and asking for advice. Not | only did I state that I produced a "big" debug log, I also POSTED a | smaller one. If you mean something different by a "stack trace," | can you provide some instructions for how to obtain it? | | As for "continuing beyond errors" - AFAIK, *I* am not saving the | image in a confused state, but *something* appears to be doing just | that. Yes, I "ignored errors" in the sense that I used the task | manager to kill off an image that was flailing trying to download | packages, and was mystified to discover that, without an explicit | save on my part, the image "woke up" trying to do the same fruitless | exercise. Several iterations of trying to unravel that led to the | large log. I then removed the log, did one cycle, and posted the | log from that. | | Bill | | | | | ________________________________________ | From: pharo-project-bounces@lists.gforge.inria.fr | [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Dale | Henrichs [dhenrich@vmware.com] | Sent: Thursday, February 09, 2012 8:33 PM | To: Pharo-project@lists.gforge.inria.fr | 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@anest.ufl.edu> | | To: Pharo-project@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@lists.gforge.inria.fr | | [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Yanni | | Chiu [yanni@rogers.com] | | Sent: Thursday, February 09, 2012 6:22 PM | | To: pharo-project@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. | | | | | | | | | | |
Dale, This might not be what you want. If not, please outline what I need to do to get exactly what you need and I will do it to the best of my ability. Attached is a debug log from a measured amount of the badness. The huge one I mentioned had been building up over many experiments, and it took me a while to notice same. Once I did, I deleted the log, fiddled some more, and captured the attached zip file. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Dale Henrichs [dhenrich@vmware.com] Sent: Friday, February 10, 2012 12:57 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] 1.4 - better from Jenkins Bill, I guess I missed the Metacello stack and I can't seem to find it... if you could point me to the post with your Metacello stack in it I will be glad to take a loook. Dale ----- Original Message ----- | From: "Wilhelm K Schwab" <bschwab@anest.ufl.edu> | To: Pharo-project@lists.gforge.inria.fr | Sent: Friday, February 10, 2012 2:21:30 AM | Subject: Re: [Pharo-project] 1.4 - better from Jenkins | | Dale, | | I'm not "complaining," I'm stating facts and asking for advice. Not | only did I state that I produced a "big" debug log, I also POSTED a | smaller one. If you mean something different by a "stack trace," | can you provide some instructions for how to obtain it? | | As for "continuing beyond errors" - AFAIK, *I* am not saving the | image in a confused state, but *something* appears to be doing just | that. Yes, I "ignored errors" in the sense that I used the task | manager to kill off an image that was flailing trying to download | packages, and was mystified to discover that, without an explicit | save on my part, the image "woke up" trying to do the same fruitless | exercise. Several iterations of trying to unravel that led to the | large log. I then removed the log, did one cycle, and posted the | log from that. | | Bill | | | | | ________________________________________ | From: pharo-project-bounces@lists.gforge.inria.fr | [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Dale | Henrichs [dhenrich@vmware.com] | Sent: Thursday, February 09, 2012 8:33 PM | To: Pharo-project@lists.gforge.inria.fr | 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@anest.ufl.edu> | | To: Pharo-project@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@lists.gforge.inria.fr | | [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Yanni | | Chiu [yanni@rogers.com] | | Sent: Thursday, February 09, 2012 6:22 PM | | To: pharo-project@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. | | | | | | | | | | |
Bill, This would be exactly the type of information that I would need, except that there is no trace of Metacello in the attached log ... In your mail, you implied that you had posted a small stack that was from a problem you had while using Metacello. The attached log has no trace of Metacello on the stack ... I don't have the time or patience to teach you how to develop in Smalltalk, but if you have specific issues with Metacello I am very interested in addressing them. You have been making statements about Metacello that, until I see an actual stack trace with Metacello on the stack, I will assume are unfounded, which is your prerogative. In the future if you have a stack trace with Metacello on the stack please submit a Metacello bug[1] with the stack trace included, otherwise I won't be paying attention, which is my prerogative. Dale [1] http://code.google.com/p/metacello/issues/entry ----- Original Message ----- | From: "Wilhelm K Schwab" <bschwab@anest.ufl.edu> | To: Pharo-project@lists.gforge.inria.fr | Sent: Friday, February 10, 2012 10:06:10 AM | Subject: Re: [Pharo-project] 1.4 - better from Jenkins | | Dale, | | This might not be what you want. If not, please outline what I need | to do to get exactly what you need and I will do it to the best of | my ability. | | Attached is a debug log from a measured amount of the badness. The | huge one I mentioned had been building up over many experiments, and | it took me a while to notice same. Once I did, I deleted the log, | fiddled some more, and captured the attached zip file. | | Bill | | ________________________________________ | From: pharo-project-bounces@lists.gforge.inria.fr | [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Dale | Henrichs [dhenrich@vmware.com] | Sent: Friday, February 10, 2012 12:57 PM | To: Pharo-project@lists.gforge.inria.fr | Subject: Re: [Pharo-project] 1.4 - better from Jenkins | | Bill, | | I guess I missed the Metacello stack and I can't seem to find it... | if you could point me to the post with your Metacello stack in it I | will be glad to take a loook. | | Dale | | ----- Original Message ----- | | From: "Wilhelm K Schwab" <bschwab@anest.ufl.edu> | | To: Pharo-project@lists.gforge.inria.fr | | Sent: Friday, February 10, 2012 2:21:30 AM | | Subject: Re: [Pharo-project] 1.4 - better from Jenkins | | | | Dale, | | | | I'm not "complaining," I'm stating facts and asking for advice. | | Not | | only did I state that I produced a "big" debug log, I also POSTED a | | smaller one. If you mean something different by a "stack trace," | | can you provide some instructions for how to obtain it? | | | | As for "continuing beyond errors" - AFAIK, *I* am not saving the | | image in a confused state, but *something* appears to be doing just | | that. Yes, I "ignored errors" in the sense that I used the task | | manager to kill off an image that was flailing trying to download | | packages, and was mystified to discover that, without an explicit | | save on my part, the image "woke up" trying to do the same | | fruitless | | exercise. Several iterations of trying to unravel that led to the | | large log. I then removed the log, did one cycle, and posted the | | log from that. | | | | Bill | | | | | | | | | | ________________________________________ | | From: pharo-project-bounces@lists.gforge.inria.fr | | [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Dale | | Henrichs [dhenrich@vmware.com] | | Sent: Thursday, February 09, 2012 8:33 PM | | To: Pharo-project@lists.gforge.inria.fr | | 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@anest.ufl.edu> | | | To: Pharo-project@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@lists.gforge.inria.fr | | | [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Yanni | | | Chiu [yanni@rogers.com] | | | Sent: Thursday, February 09, 2012 6:22 PM | | | To: pharo-project@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. | | | | | | | | | | | | | | | | | | | |
Just checked: no zero-length files. ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Yanni Chiu [yanni@rogers.com] Sent: Thursday, February 09, 2012 6:22 PM To: pharo-project@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.
On Feb 9, 2012, at 11: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.
Sure we will start to work on distribution certification as I mentioned in the draft of Pharo Vision document which escape my hd recently.. new version coming soon. Bill can you post a reproachable case for us to play with?
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@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Sven Van Caekenberghe [sven@beta9.be] Sent: Thursday, February 09, 2012 5:14 PM To: Pharo-project@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
Stef, I have an idea for something that might be simple enough to make the point. It is confusing though, especially that once an image goes bad, it stays bad, even though (AFAIK, I don't save it after the damage is done). I have work to do there. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Friday, February 10, 2012 3:29 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] 1.4 - better from Jenkins On Feb 9, 2012, at 11: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.
Sure we will start to work on distribution certification as I mentioned in the draft of Pharo Vision document which escape my hd recently.. new version coming soon. Bill can you post a reproachable case for us to play with?
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@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Sven Van Caekenberghe [sven@beta9.be] Sent: Thursday, February 09, 2012 5:14 PM To: Pharo-project@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
Schwab,Wilhelm K wrote:
Stef,
I have an idea for something that might be simple enough to make the point. It is confusing though, especially that once an image goes bad, it stays bad, even though (AFAIK, I don't save it after the damage is done). For certainty, you could monitor file timestamps or in the extreme compare md5 checksums on the image at various points. Perhaps the first thing after unzippping a new image add 'self halt' at the top of SmalltalkImage>>snapshot:andQuit: This might help hunt down anything that is forcing an image save without your consent.
cheers, -ben
That's if the debugger still works =:0 Good idea though. ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Ben Coman [btc@openInWorld.com] Sent: Friday, February 10, 2012 8:17 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] 1.4 - better from Jenkins Schwab,Wilhelm K wrote:
Stef,
I have an idea for something that might be simple enough to make the point. It is confusing though, especially that once an image goes bad, it stays bad, even though (AFAIK, I don't save it after the damage is done). For certainty, you could monitor file timestamps or in the extreme compare md5 checksums on the image at various points. Perhaps the first thing after unzippping a new image add 'self halt' at the top of SmalltalkImage>>snapshot:andQuit: This might help hunt down anything that is forcing an image save without your consent.
cheers, -ben
On 9 February 2012 22:27, Schwab,Wilhelm K <bschwab@anest.ufl.edu> 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
seem to be you victim of http://code.google.com/p/pharo/issues/detail?id=5167&q=finalization&colspec=... its indeed prevents debugger from starting in some cases
(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?
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K [bschwab@anest.ufl.edu] Sent: Thursday, February 09, 2012 3:15 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] 1.4 - better from Jenkins
One snag: I'm still getting strangely broken images (won't open process browser or debugger) after trying to download some things. Â I have mirrored squeak source, BUT, some things (SIXX, ODBC) don't appear to have working configs, so I'm trying to grab the latest packages, and *that* might not be mirrored. Â I might need to specify the mirror server in my code to make them work.
Still, I don't get how simply asking MC to download something will permanently mar the image w/o my doing an explicit save. Â Does MC snapshot before/during an attempted load? Â It seems very misguided that an innocent attempt to load something can hobble an image??
One other crazy possibility: is killing a vm from the (Ubunutu) system monitor somehow not sufficient to clear what is running? Â Dumb question? Â Maybe, but I'm stumped. Â Any ideas?
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of blake [dsblakewatson@gmail.com] Sent: Thursday, February 09, 2012 2:58 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] 1.4 - better from Jenkins
I just downloaded the latest CogWin and Pharo 1.4 image and I got "WARNING: Manufactured file handle detected!" at the bottom, and popup full of startup errors.
But!
It's all actually very friendly! I can look through the errors and try to figure out what caused them. It's way cleaner than the old style mega-DNU-stacks.
Nice work!
On Thu, Feb 9, 2012 at 11:06 AM, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
I grabbed 1.4 and cog/unix from jenkins, dumped all the files in one directory, made a shell script to run the image using Cog, and all I can say is "wow."
The usability problems I was having are gone. Â In particular, the context menus work. Â I loaded Migrate and set preferences, with a really nice appearance resulting.
One question: why did ClassDescription>>package go away? Â That seems to be a really useful message.
I'll try to build an image using the SqueakSource mirror. Â No promises, but 1.4 "suddenly" looks a LOT more polished than it did. Â Are the links on the Pharo page old, or did somebody just do a lot of work to make things better?
Bill
-- Best regards, Igor Stasenko.
Schwab,Wilhelm K wrote:
One snag: I'm still getting strangely broken images (won't open process browser or debugger) after trying to download some things. I have mirrored squeak source, BUT, some things (SIXX, ODBC) don't appear to have working configs, so I'm trying to grab the latest packages, and *that* might not be mirrored. I might need to specify the mirror server in my code to make them work.
Still, I don't get how simply asking MC to download something will permanently mar the image w/o my doing an explicit save. Does MC snapshot before/during an attempted load? It seems very misguided that an innocent attempt to load something can hobble an image??
One other crazy possibility: is killing a vm from the (Ubunutu) system monitor somehow not sufficient to clear what is running? Dumb question? Maybe, but I'm stumped. Any ideas?
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of blake [dsblakewatson@gmail.com] Sent: Thursday, February 09, 2012 2:58 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] 1.4 - better from Jenkins
I just downloaded the latest CogWin and Pharo 1.4 image and I got "WARNING: Manufactured file handle detected!" at the bottom, and popup full of startup errors.
A couple of days ago tried Pharo-1.4-14315 and with cogwin_r2522. I had the same warning, with a debugger showing "Error: Got startup errors" in method SmalltalkImage snapshot:andQuit: " at line: startupErrors isEmpty ifFalse: [ self error: 'Got startup errors ' ]. where startupErrors = an OrderedCollection(ShouldBeImplemented: #preferencesFolder should have been implemented in DosFileDirectory class) So I thought I may as well try implementing DosFileDirectory>>preferencesFolder - which I've left as a comment on ISSUE 5255. <http://code.google.com/p/pharo/issues/detail?id=5255> A nice side effect of this was that all the "WARNING: Manufactured file handle detected!" went away. Reverting this change reintroduces the warnings. cheers, -ben
While I was working towards implementing DosFileDirectory>>preferencesFolder & >>preferencesGeneralFolder I was stepping through: SmalltalkImage>>snapshot:andQuit: did a: <Restart> and then stepped down to: Cursor write show at which point the debugger hung the image. Now I guess theres an equal chance this is not really an issue as something "special" might be happening here straddling the save point. Just thought I would report it for review. To reproduce on non-Windows you could probably set preferencesFolder & preferencesGeneralFolder on your platform to self shouldBeImplemented and proceed from the debugger that comes up. SmalltalkImage>>snapshot: save andQuit: quit | snapshotResult resuming startupErrors | Object flushDependents. Object flushEvents. self addSnapshotRecord: save andQuit: quit. self processShutDownList: quit. Cursor write show. <--------Image Hangs Here after a <Restart> of the method while debugging following a resume.. cheers, -ben Ben Coman wrote:
Schwab,Wilhelm K wrote:
One snag: I'm still getting strangely broken images (won't open process browser or debugger) after trying to download some things. I have mirrored squeak source, BUT, some things (SIXX, ODBC) don't appear to have working configs, so I'm trying to grab the latest packages, and *that* might not be mirrored. I might need to specify the mirror server in my code to make them work.
Still, I don't get how simply asking MC to download something will permanently mar the image w/o my doing an explicit save. Does MC snapshot before/during an attempted load? It seems very misguided that an innocent attempt to load something can hobble an image??
One other crazy possibility: is killing a vm from the (Ubunutu) system monitor somehow not sufficient to clear what is running? Dumb question? Maybe, but I'm stumped. Any ideas?
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of blake [dsblakewatson@gmail.com] Sent: Thursday, February 09, 2012 2:58 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] 1.4 - better from Jenkins
I just downloaded the latest CogWin and Pharo 1.4 image and I got "WARNING: Manufactured file handle detected!" at the bottom, and popup full of startup errors.
A couple of days ago tried Pharo-1.4-14315 and with cogwin_r2522. I had the same warning, with a debugger showing "Error: Got startup errors" in method SmalltalkImage snapshot:andQuit: " at line: startupErrors isEmpty ifFalse: [ self error: 'Got startup errors ' ]. where startupErrors = an OrderedCollection(ShouldBeImplemented: #preferencesFolder should have been implemented in DosFileDirectory class)
So I thought I may as well try implementing DosFileDirectory>>preferencesFolder - which I've left as a comment on ISSUE 5255. <http://code.google.com/p/pharo/issues/detail?id=5255> A nice side effect of this was that all the "WARNING: Manufactured file handle detected!" went away. Reverting this change reintroduces the warnings.
cheers, -ben
This is interesting. I am seeing images with behavior that should have not been saved, but was, *and* sometimes oddly flashing cursors and debuggers not opening. Where there's smoke, there's fire?? Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Ben Coman [btc@openInWorld.com] Sent: Friday, February 10, 2012 12:42 PM To: Pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] Debugger hanging... was Re: 1.4 - better from Jenkins While I was working towards implementing DosFileDirectory>>preferencesFolder & >>preferencesGeneralFolder I was stepping through: SmalltalkImage>>snapshot:andQuit: did a: <Restart> and then stepped down to: Cursor write show at which point the debugger hung the image. Now I guess theres an equal chance this is not really an issue as something "special" might be happening here straddling the save point. Just thought I would report it for review. To reproduce on non-Windows you could probably set preferencesFolder & preferencesGeneralFolder on your platform to self shouldBeImplemented and proceed from the debugger that comes up. SmalltalkImage>>snapshot: save andQuit: quit | snapshotResult resuming startupErrors | Object flushDependents. Object flushEvents. self addSnapshotRecord: save andQuit: quit. self processShutDownList: quit. Cursor write show. <--------Image Hangs Here after a <Restart> of the method while debugging following a resume.. cheers, -ben Ben Coman wrote:
Schwab,Wilhelm K wrote:
One snag: I'm still getting strangely broken images (won't open process browser or debugger) after trying to download some things. I have mirrored squeak source, BUT, some things (SIXX, ODBC) don't appear to have working configs, so I'm trying to grab the latest packages, and *that* might not be mirrored. I might need to specify the mirror server in my code to make them work.
Still, I don't get how simply asking MC to download something will permanently mar the image w/o my doing an explicit save. Does MC snapshot before/during an attempted load? It seems very misguided that an innocent attempt to load something can hobble an image??
One other crazy possibility: is killing a vm from the (Ubunutu) system monitor somehow not sufficient to clear what is running? Dumb question? Maybe, but I'm stumped. Any ideas?
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of blake [dsblakewatson@gmail.com] Sent: Thursday, February 09, 2012 2:58 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] 1.4 - better from Jenkins
I just downloaded the latest CogWin and Pharo 1.4 image and I got "WARNING: Manufactured file handle detected!" at the bottom, and popup full of startup errors.
A couple of days ago tried Pharo-1.4-14315 and with cogwin_r2522. I had the same warning, with a debugger showing "Error: Got startup errors" in method SmalltalkImage snapshot:andQuit: " at line: startupErrors isEmpty ifFalse: [ self error: 'Got startup errors ' ]. where startupErrors = an OrderedCollection(ShouldBeImplemented: #preferencesFolder should have been implemented in DosFileDirectory class)
So I thought I may as well try implementing DosFileDirectory>>preferencesFolder - which I've left as a comment on ISSUE 5255. <http://code.google.com/p/pharo/issues/detail?id=5255> A nice side effect of this was that all the "WARNING: Manufactured file handle detected!" went away. Reverting this change reintroduces the warnings.
cheers, -ben
On Feb 10, 2012, at 6:42 PM, Ben Coman wrote:
While I was working towards implementing DosFileDirectory>>preferencesFolder & >>preferencesGeneralFolder I was stepping through: SmalltalkImage>>snapshot:andQuit: did a: <Restart> and then stepped down to: Cursor write show at which point the debugger hung the image.
Now I guess theres an equal chance this is not really an issue as something "special" might be happening here straddling the save point. Just thought I would report it for review.
To reproduce on non-Windows you could probably set preferencesFolder & preferencesGeneralFolder on your platform to self shouldBeImplemented and proceed from the debugger that comes up.
SmalltalkImage>>snapshot: save andQuit: quit | snapshotResult resuming startupErrors | Object flushDependents. Object flushEvents. self addSnapshotRecord: save andQuit: quit. self processShutDownList: quit. Cursor write show. <--------Image Hangs Here after a <Restart> of the method while debugging following a resume..
cheers, -ben
IIRC, the InputEventSensor is deregistered as part of shutdown, if so, that would indeed lead to a non-responsive image at that point. (In the sense that the thing that processes input is no longer there) Cheers, Henry
On 13 February 2012 12:55, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
On Feb 10, 2012, at 6:42 PM, Ben Coman wrote:
While I was working towards implementing DosFileDirectory>>preferencesFolder & >>preferencesGeneralFolder I was stepping through: SmalltalkImage>>snapshot:andQuit: did a: <Restart> and then stepped down to: Â Cursor write show at which point the debugger hung the image.
Now I guess theres an equal chance this is not really an issue as something "special" might be happening here straddling the save point. Â Just thought I would report it for review.
To reproduce on non-Windows you could probably set preferencesFolder & preferencesGeneralFolder on your platform to self shouldBeImplemented and proceed from the debugger that comes up.
SmalltalkImage>>snapshot: save andQuit: quit  | snapshotResult resuming startupErrors |  Object flushDependents.  Object flushEvents.  self addSnapshotRecord: save andQuit: quit.  self processShutDownList: quit.  Cursor write show.  <--------Image Hangs Here after a <Restart> of the method while debugging following a resume..
cheers, -ben
IIRC, the InputEventSensor is deregistered as part of shutdown, if so, that would indeed lead to a non-responsive image at that point. (In the sense that the thing that processes input is no longer there)
Well, its #shutDown method is empty. But still, i think you have right insight. Because there is enough of Delay>>shutDown to stop everything, because most stuff using delays , including UI process. ---- shutDown "Suspend the active delay, if any, before snapshotting. It will be reactived when the snapshot is resumed." "Details: This prevents a timer interrupt from waking up the active delay in the midst snapshoting, since the active delay will be restarted when resuming the snapshot and we don't want to process the delay twice."
Cheers, Henry
-- Best regards, Igor Stasenko.
My bad; I meant the InputEventFetcher, the effect is the same. Cheers, Henry On Feb 13, 2012, at 2:41 PM, Igor Stasenko wrote:
On 13 February 2012 12:55, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
On Feb 10, 2012, at 6:42 PM, Ben Coman wrote:
While I was working towards implementing DosFileDirectory>>preferencesFolder & >>preferencesGeneralFolder I was stepping through: SmalltalkImage>>snapshot:andQuit: did a: <Restart> and then stepped down to: Cursor write show at which point the debugger hung the image.
Now I guess theres an equal chance this is not really an issue as something "special" might be happening here straddling the save point. Just thought I would report it for review.
To reproduce on non-Windows you could probably set preferencesFolder & preferencesGeneralFolder on your platform to self shouldBeImplemented and proceed from the debugger that comes up.
SmalltalkImage>>snapshot: save andQuit: quit | snapshotResult resuming startupErrors | Object flushDependents. Object flushEvents. self addSnapshotRecord: save andQuit: quit. self processShutDownList: quit. Cursor write show. <--------Image Hangs Here after a <Restart> of the method while debugging following a resume..
cheers, -ben
IIRC, the InputEventSensor is deregistered as part of shutdown, if so, that would indeed lead to a non-responsive image at that point. (In the sense that the thing that processes input is no longer there)
Well, its #shutDown method is empty. But still, i think you have right insight.
Because there is enough of Delay>>shutDown to stop everything, because most stuff using delays , including UI process. ---- shutDown "Suspend the active delay, if any, before snapshotting. It will be reactived when the snapshot is resumed." "Details: This prevents a timer interrupt from waking up the active delay in the midst snapshoting, since the active delay will be restarted when resuming the snapshot and we don't want to process the delay twice."
Cheers, Henry
-- Best regards, Igor Stasenko.
Sig, Has there been any decision/update on this? One good suggestion to get to the bottom of my problem is to set a breakpoint in the snapshot code. But, I currently have little faith that this will reveal an offender, because one of the early symptoms of my images going bad is that debuggers will no longer open. If reverting a change or whatever else fixes this, it could be a big help in finding my problem, if not (via event sensor) a fix to it. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Henrik Johansen [henrik.s.johansen@veloxit.no] Sent: Monday, February 13, 2012 6:55 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Debugger hanging... was Re: 1.4 - better from Jenkins On Feb 10, 2012, at 6:42 PM, Ben Coman wrote:
While I was working towards implementing DosFileDirectory>>preferencesFolder & >>preferencesGeneralFolder I was stepping through: SmalltalkImage>>snapshot:andQuit: did a: <Restart> and then stepped down to: Cursor write show at which point the debugger hung the image.
Now I guess theres an equal chance this is not really an issue as something "special" might be happening here straddling the save point. Just thought I would report it for review.
To reproduce on non-Windows you could probably set preferencesFolder & preferencesGeneralFolder on your platform to self shouldBeImplemented and proceed from the debugger that comes up.
SmalltalkImage>>snapshot: save andQuit: quit | snapshotResult resuming startupErrors | Object flushDependents. Object flushEvents. self addSnapshotRecord: save andQuit: quit. self processShutDownList: quit. Cursor write show. <--------Image Hangs Here after a <Restart> of the method while debugging following a resume..
cheers, -ben
IIRC, the InputEventSensor is deregistered as part of shutdown, if so, that would indeed lead to a non-responsive image at that point. (In the sense that the thing that processes input is no longer there) Cheers, Henry
The error I reported here should not affect your using a breakpoint #snapshot:andQuit in to debug this. Just avoid clicking <restart> in the debugger for #snapshot:andQuit: For your problem with the debugger, here is how I would go about it. 1. Check if any failures occur with TestRunner on ToolsTest-Debugger? If any of them do fail (for example #testBasic), then use that as an observation point to help isolate the problem. 2. Automate the loading of additional code using the new preferences feature. After each step check whether #testBasic now fails. This hopefully makes it reproducible and facilitates divide and conquer to isolate which code is interfering with the debugger. A possible startup script (pseudocode) Transcript open. Transcript crShow: 'Loading A failures = ' Load the code for A Transcript show: ( DebuggerTest run: #testBasic ) failures size Transcript crShow: 'Loading B failures = ' Load the code for B Transcript show: ( DebuggerTest run: #testBasic ) failures size ...etc Execute `StartupLoader example` to generate a template startup script. Unzip a fresh image. Seed the local package cache from a previous image. Run the image. 3. Set Debugger>>logDebuggerStackToFile and see if anything spits out (note I haven't used this myself - just saw it in the code) cheers, -ben Schwab,Wilhelm K wrote:
Sig,
Has there been any decision/update on this? One good suggestion to get to the bottom of my problem is to set a breakpoint in the snapshot code. But, I currently have little faith that this will reveal an offender, because one of the early symptoms of my images going bad is that debuggers will no longer open.
If reverting a change or whatever else fixes this, it could be a big help in finding my problem, if not (via event sensor) a fix to it.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Henrik Johansen [henrik.s.johansen@veloxit.no] Sent: Monday, February 13, 2012 6:55 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Debugger hanging... was Re: 1.4 - better from Jenkins
On Feb 10, 2012, at 6:42 PM, Ben Coman wrote:
While I was working towards implementing DosFileDirectory>>preferencesFolder & >>preferencesGeneralFolder I was stepping through: SmalltalkImage>>snapshot:andQuit: did a: <Restart> and then stepped down to: Cursor write show at which point the debugger hung the image.
Now I guess theres an equal chance this is not really an issue as something "special" might be happening here straddling the save point. Just thought I would report it for review.
To reproduce on non-Windows you could probably set preferencesFolder & preferencesGeneralFolder on your platform to self shouldBeImplemented and proceed from the debugger that comes up.
SmalltalkImage>>snapshot: save andQuit: quit | snapshotResult resuming startupErrors | Object flushDependents. Object flushEvents. self addSnapshotRecord: save andQuit: quit. self processShutDownList: quit. Cursor write show. <--------Image Hangs Here after a <Restart> of the method while debugging following a resume..
cheers, -ben
IIRC, the InputEventSensor is deregistered as part of shutdown, if so, that would indeed lead to a non-responsive image at that point. (In the sense that the thing that processes input is no longer there)
Cheers, Henry
Dumb question, *where* do you see these warnings? Just curious, because a bad snapshot/startup seems a likely (if not mysterious) part of my troubles. BTW, sleep intervened, but I did have some additional success after clearing the mc caches. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Ben Coman [btc@openInWorld.com] Sent: Friday, February 10, 2012 12:21 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] 1.4 - better from Jenkins Schwab,Wilhelm K wrote:
One snag: I'm still getting strangely broken images (won't open process browser or debugger) after trying to download some things. I have mirrored squeak source, BUT, some things (SIXX, ODBC) don't appear to have working configs, so I'm trying to grab the latest packages, and *that* might not be mirrored. I might need to specify the mirror server in my code to make them work.
Still, I don't get how simply asking MC to download something will permanently mar the image w/o my doing an explicit save. Does MC snapshot before/during an attempted load? It seems very misguided that an innocent attempt to load something can hobble an image??
One other crazy possibility: is killing a vm from the (Ubunutu) system monitor somehow not sufficient to clear what is running? Dumb question? Maybe, but I'm stumped. Any ideas?
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of blake [dsblakewatson@gmail.com] Sent: Thursday, February 09, 2012 2:58 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] 1.4 - better from Jenkins
I just downloaded the latest CogWin and Pharo 1.4 image and I got "WARNING: Manufactured file handle detected!" at the bottom, and popup full of startup errors.
A couple of days ago tried Pharo-1.4-14315 and with cogwin_r2522. I had the same warning, with a debugger showing "Error: Got startup errors" in method SmalltalkImage snapshot:andQuit: " at line: startupErrors isEmpty ifFalse: [ self error: 'Got startup errors ' ]. where startupErrors = an OrderedCollection(ShouldBeImplemented: #preferencesFolder should have been implemented in DosFileDirectory class) So I thought I may as well try implementing DosFileDirectory>>preferencesFolder - which I've left as a comment on ISSUE 5255. <http://code.google.com/p/pharo/issues/detail?id=5255> A nice side effect of this was that all the "WARNING: Manufactured file handle detected!" went away. Reverting this change reintroduces the warnings. cheers, -ben
I just realized that clearing up those two ShouldBeImplementeds from DosFileDirectory did not really prove that startup preferences worked on MS Windows. So I found the StartupLoader class>>example method and did get... 'I should only be displayed once' ...one time only and do get... 'I should be displayed each time' ...each time I start Pharo. So its good :) !! However the 'each time' also dialog comes _every_ time I save the image. Is that desired behaviour? or is it just not finished yet? btw, I was a little confused at first by how to use StartupLoader class>>example. Initially I copied the whole text of that method into pharo/1.4/startup.st and the started the image - and the 'once' and 'each time' messages did appear - but also a number of errors. It wasn't until I notice and wondered about the created file pharo1.4.st that I worked out that 'StartupLoader class>>example' should have just been executed rather than manually copied. Perhaps you can update the comment to say "An example of script generation. Execute me to write a sample script to the preferences folder" cheers, -ben Ben Coman wrote:
Schwab,Wilhelm K wrote:
One snag: I'm still getting strangely broken images (won't open process browser or debugger) after trying to download some things. I have mirrored squeak source, BUT, some things (SIXX, ODBC) don't appear to have working configs, so I'm trying to grab the latest packages, and *that* might not be mirrored. I might need to specify the mirror server in my code to make them work.
Still, I don't get how simply asking MC to download something will permanently mar the image w/o my doing an explicit save. Does MC snapshot before/during an attempted load? It seems very misguided that an innocent attempt to load something can hobble an image??
One other crazy possibility: is killing a vm from the (Ubunutu) system monitor somehow not sufficient to clear what is running? Dumb question? Maybe, but I'm stumped. Any ideas?
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of blake [dsblakewatson@gmail.com] Sent: Thursday, February 09, 2012 2:58 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] 1.4 - better from Jenkins
I just downloaded the latest CogWin and Pharo 1.4 image and I got "WARNING: Manufactured file handle detected!" at the bottom, and popup full of startup errors.
A couple of days ago tried Pharo-1.4-14315 and with cogwin_r2522. I had the same warning, with a debugger showing "Error: Got startup errors" in method SmalltalkImage snapshot:andQuit: " at line: startupErrors isEmpty ifFalse: [ self error: 'Got startup errors ' ]. where startupErrors = an OrderedCollection(ShouldBeImplemented: #preferencesFolder should have been implemented in DosFileDirectory class)
So I thought I may as well try implementing DosFileDirectory>>preferencesFolder - which I've left as a comment on ISSUE 5255. <http://code.google.com/p/pharo/issues/detail?id=5255> A nice side effect of this was that all the "WARNING: Manufactured file handle detected!" went away. Reverting this change reintroduces the warnings.
cheers, -ben
On 2012-02-10, at 20:06, Ben Coman wrote:
I just realized that clearing up those two ShouldBeImplementeds from DosFileDirectory did not really prove that startup preferences worked on MS Windows. So I found the StartupLoader class>>example method and did get... 'I should only be displayed once' ...one time only and do get... 'I should be displayed each time' ...each time I start Pharo. So its good :) !!
However the 'each time' also dialog comes _every_ time I save the image. Is that desired behaviour? or is it just not finished yet?
see http://code.google.com/p/pharo/issues/detail?id=5275 ;)
btw, I was a little confused at first by how to use StartupLoader class>>example. Initially I copied the whole text of that method into pharo/1.4/startup.st and the started the image - and the 'once' and 'each time' messages did appear - but also a number of errors. It wasn't until I notice and wondered about the created file pharo1.4.st that I worked out that 'StartupLoader class>>example' should have just been executed rather than manually copied. Perhaps you can update the comment to say "An example of script generation. Execute me to write a sample script to the preferences folder"
cheers, -ben
Ben Coman wrote:
Schwab,Wilhelm K wrote:
One snag: I'm still getting strangely broken images (won't open process browser or debugger) after trying to download some things. I have mirrored squeak source, BUT, some things (SIXX, ODBC) don't appear to have working configs, so I'm trying to grab the latest packages, and *that* might not be mirrored. I might need to specify the mirror server in my code to make them work.
Still, I don't get how simply asking MC to download something will permanently mar the image w/o my doing an explicit save. Does MC snapshot before/during an attempted load? It seems very misguided that an innocent attempt to load something can hobble an image??
One other crazy possibility: is killing a vm from the (Ubunutu) system monitor somehow not sufficient to clear what is running? Dumb question? Maybe, but I'm stumped. Any ideas?
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of blake [dsblakewatson@gmail.com] Sent: Thursday, February 09, 2012 2:58 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] 1.4 - better from Jenkins
I just downloaded the latest CogWin and Pharo 1.4 image and I got "WARNING: Manufactured file handle detected!" at the bottom, and popup full of startup errors.
A couple of days ago tried Pharo-1.4-14315 and with cogwin_r2522. I had the same warning, with a debugger showing "Error: Got startup errors" in method SmalltalkImage snapshot:andQuit: " at line: startupErrors isEmpty ifFalse: [ self error: 'Got startup errors ' ]. where startupErrors = an OrderedCollection(ShouldBeImplemented: #preferencesFolder should have been implemented in DosFileDirectory class)
So I thought I may as well try implementing DosFileDirectory>>preferencesFolder - which I've left as a comment on ISSUE 5255. <http://code.google.com/p/pharo/issues/detail?id=5255> A nice side effect of this was that all the "WARNING: Manufactured file handle detected!" went away. Reverting this change reintroduces the warnings.
cheers, -ben
Camillo Bruni wrote:
On 2012-02-10, at 20:06, Ben Coman wrote:
I just realized that clearing up those two ShouldBeImplementeds from DosFileDirectory did not really prove that startup preferences worked on MS Windows. So I found the StartupLoader class>>example method and did get... 'I should only be displayed once' ...one time only and do get... 'I should be displayed each time' ...each time I start Pharo. So its good :) !!
However the 'each time' also dialog comes _every_ time I save the image. Is that desired behaviour? or is it just not finished yet?
That fixed it. Thanks Camillo.
bill can you build a reproducable situation? Because we use daily packages with 1.4 In fact in often only develop in 1.4 and did not experience this problem. but it does not mean that we do not have problems :) Stef On Feb 9, 2012, at 9:15 PM, Schwab,Wilhelm K wrote:
One snag: I'm still getting strangely broken images (won't open process browser or debugger) after trying to download some things. I have mirrored squeak source, BUT, some things (SIXX, ODBC) don't appear to have working configs, so I'm trying to grab the latest packages, and *that* might not be mirrored. I might need to specify the mirror server in my code to make them work.
Still, I don't get how simply asking MC to download something will permanently mar the image w/o my doing an explicit save. Does MC snapshot before/during an attempted load? It seems very misguided that an innocent attempt to load something can hobble an image??
One other crazy possibility: is killing a vm from the (Ubunutu) system monitor somehow not sufficient to clear what is running? Dumb question? Maybe, but I'm stumped. Any ideas?
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of blake [dsblakewatson@gmail.com] Sent: Thursday, February 09, 2012 2:58 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] 1.4 - better from Jenkins
I just downloaded the latest CogWin and Pharo 1.4 image and I got "WARNING: Manufactured file handle detected!" at the bottom, and popup full of startup errors.
But!
It's all actually very friendly! I can look through the errors and try to figure out what caused them. It's way cleaner than the old style mega-DNU-stacks.
Nice work!
On Thu, Feb 9, 2012 at 11:06 AM, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
I grabbed 1.4 and cog/unix from jenkins, dumped all the files in one directory, made a shell script to run the image using Cog, and all I can say is "wow."
The usability problems I was having are gone. In particular, the context menus work. I loaded Migrate and set preferences, with a really nice appearance resulting.
One question: why did ClassDescription>>package go away? That seems to be a really useful message.
I'll try to build an image using the SqueakSource mirror. No promises, but 1.4 "suddenly" looks a LOT more polished than it did. Are the links on the Pharo page old, or did somebody just do a lot of work to make things better?
Bill
Stef, I am trying to simplify it :) You use a Mac, right? I'm using Linux, and the vm differences might be at play?? Thanks for understanding my motivations. I'll keep at it. It might also be interesting for me to try to orchestrate an attempt on a Windows vm. I don't care for Windows, but I have long respected Andreas' work on it vm. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Friday, February 10, 2012 3:26 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] 1.4 - better from Jenkins bill can you build a reproducable situation? Because we use daily packages with 1.4 In fact in often only develop in 1.4 and did not experience this problem. but it does not mean that we do not have problems :) Stef On Feb 9, 2012, at 9:15 PM, Schwab,Wilhelm K wrote:
One snag: I'm still getting strangely broken images (won't open process browser or debugger) after trying to download some things. I have mirrored squeak source, BUT, some things (SIXX, ODBC) don't appear to have working configs, so I'm trying to grab the latest packages, and *that* might not be mirrored. I might need to specify the mirror server in my code to make them work.
Still, I don't get how simply asking MC to download something will permanently mar the image w/o my doing an explicit save. Does MC snapshot before/during an attempted load? It seems very misguided that an innocent attempt to load something can hobble an image??
One other crazy possibility: is killing a vm from the (Ubunutu) system monitor somehow not sufficient to clear what is running? Dumb question? Maybe, but I'm stumped. Any ideas?
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of blake [dsblakewatson@gmail.com] Sent: Thursday, February 09, 2012 2:58 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] 1.4 - better from Jenkins
I just downloaded the latest CogWin and Pharo 1.4 image and I got "WARNING: Manufactured file handle detected!" at the bottom, and popup full of startup errors.
But!
It's all actually very friendly! I can look through the errors and try to figure out what caused them. It's way cleaner than the old style mega-DNU-stacks.
Nice work!
On Thu, Feb 9, 2012 at 11:06 AM, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
I grabbed 1.4 and cog/unix from jenkins, dumped all the files in one directory, made a shell script to run the image using Cog, and all I can say is "wow."
The usability problems I was having are gone. In particular, the context menus work. I loaded Migrate and set preferences, with a really nice appearance resulting.
One question: why did ClassDescription>>package go away? That seems to be a really useful message.
I'll try to build an image using the SqueakSource mirror. No promises, but 1.4 "suddenly" looks a LOT more polished than it did. Are the links on the Pharo page old, or did somebody just do a lot of work to make things better?
Bill
On Feb 10, 2012, at 9:36 PM, Schwab,Wilhelm K wrote:
Stef,
I am trying to simplify it :)
tx
You use a Mac, right? I'm using Linux, and the vm differences might be at play??
May be.
Thanks for understanding my motivations. I'll keep at it. It might also be interesting for me to try to orchestrate an attempt on a Windows vm. I don't care for Windows, but I have long respected Andreas' work on it vm.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Friday, February 10, 2012 3:26 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] 1.4 - better from Jenkins
bill
can you build a reproducable situation? Because we use daily packages with 1.4
In fact in often only develop in 1.4 and did not experience this problem. but it does not mean that we do not have problems :)
Stef
On Feb 9, 2012, at 9:15 PM, Schwab,Wilhelm K wrote:
One snag: I'm still getting strangely broken images (won't open process browser or debugger) after trying to download some things. I have mirrored squeak source, BUT, some things (SIXX, ODBC) don't appear to have working configs, so I'm trying to grab the latest packages, and *that* might not be mirrored. I might need to specify the mirror server in my code to make them work.
Still, I don't get how simply asking MC to download something will permanently mar the image w/o my doing an explicit save. Does MC snapshot before/during an attempted load? It seems very misguided that an innocent attempt to load something can hobble an image??
One other crazy possibility: is killing a vm from the (Ubunutu) system monitor somehow not sufficient to clear what is running? Dumb question? Maybe, but I'm stumped. Any ideas?
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of blake [dsblakewatson@gmail.com] Sent: Thursday, February 09, 2012 2:58 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] 1.4 - better from Jenkins
I just downloaded the latest CogWin and Pharo 1.4 image and I got "WARNING: Manufactured file handle detected!" at the bottom, and popup full of startup errors.
But!
It's all actually very friendly! I can look through the errors and try to figure out what caused them. It's way cleaner than the old style mega-DNU-stacks.
Nice work!
On Thu, Feb 9, 2012 at 11:06 AM, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
I grabbed 1.4 and cog/unix from jenkins, dumped all the files in one directory, made a shell script to run the image using Cog, and all I can say is "wow."
The usability problems I was having are gone. In particular, the context menus work. I loaded Migrate and set preferences, with a really nice appearance resulting.
One question: why did ClassDescription>>package go away? That seems to be a really useful message.
I'll try to build an image using the SqueakSource mirror. No promises, but 1.4 "suddenly" looks a LOT more polished than it did. Are the links on the Pharo page old, or did somebody just do a lot of work to make things better?
Bill
On Thu, Feb 9, 2012 at 1:06 PM, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
I'll try to build an image using the SqueakSource mirror. No promises, but 1.4 "suddenly" looks a LOT more polished than it did. Are the links on the Pharo page old, or did somebody just do a lot of work to make things better?
Are you kidding? How could this possibly "suddenly" happen? What do you think that the Pharo community is doing? Of course isn't suddenly! It is the result of the hard work that Stef, Markus, Igor, INRIA people and the Squeak community (from where a lot of improvements are picked) are doing every day, one step at the time. So, please don't send messages like this. Isn't that "somebody just do a lot work to make things better". It is the result of the long term plan that Pharo was created to fulfill. It is the work of people, with names, with effort invested. This mail is very offensive to the people that, from long ago and with a lot of fights and effort, has been working hard to make a vision a reality. Miguel Cobá
Miguel, Giving you the benefit of the doubt, you misunderstand. Something did change "suddenly" in my experience and (as I ****CLEARLY**** stated in my email), it could easily be that the links on the Pharo site are stale. It is also possible that some small change just made it into 1.4, and fixed several things that were wrong. If you would stop looking for ways to be offended, and READ what I wrote and think instead of reacting emotionally, you would see the likely scenarios. No - I'm not kidding. I'm trying to help with marketing. The systems I was downloading from the Pharo site were "just plain broken" and that does not put a good light on the very hard work that goes into the system. Either a small but important change was recently made, OR, the links on the pharo site need to be condense to point to Jenkins. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Miguel Cobá [miguel.coba@gmail.com] Sent: Thursday, February 09, 2012 3:12 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] 1.4 - better from Jenkins On Thu, Feb 9, 2012 at 1:06 PM, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
I'll try to build an image using the SqueakSource mirror. No promises, but 1.4 "suddenly" looks a LOT more polished than it did. Are the links on the Pharo page old, or did somebody just do a lot of work to make things better?
Are you kidding? How could this possibly "suddenly" happen? What do you think that the Pharo community is doing? Of course isn't suddenly! It is the result of the hard work that Stef, Markus, Igor, INRIA people and the Squeak community (from where a lot of improvements are picked) are doing every day, one step at the time. So, please don't send messages like this. Isn't that "somebody just do a lot work to make things better". It is the result of the long term plan that Pharo was created to fulfill. It is the work of people, with names, with effort invested. This mail is very offensive to the people that, from long ago and with a lot of fights and effort, has been working hard to make a vision a reality. Miguel Cobá
Hi miguel I do not think that bill was nasty and I appreciated his feedback. What is true is that we integrated in our way of life long time ago that doing something today is the best way to have done something that is not left to do :). Stef On Feb 9, 2012, at 9:12 PM, Miguel Cobá wrote:
On Thu, Feb 9, 2012 at 1:06 PM, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
I'll try to build an image using the SqueakSource mirror. No promises, but 1.4 "suddenly" looks a LOT more polished than it did. Are the links on the Pharo page old, or did somebody just do a lot of work to make things better?
Are you kidding?
How could this possibly "suddenly" happen? What do you think that the Pharo community is doing? Of course isn't suddenly! It is the result of the hard work that Stef, Markus, Igor, INRIA people and the Squeak community (from where a lot of improvements are picked) are doing every day, one step at the time. So, please don't send messages like this. Isn't that "somebody just do a lot work to make things better". It is the result of the long term plan that Pharo was created to fulfill. It is the work of people, with names, with effort invested. This mail is very offensive to the people that, from long ago and with a lot of fights and effort, has been working hard to make a vision a reality.
Miguel Cobá
On Feb 9, 2012, at 8:06 PM, Schwab,Wilhelm K wrote:
I grabbed 1.4 and cog/unix from jenkins, dumped all the files in one directory, made a shell script to run the image using Cog, and all I can say is "wow."
tx
The usability problems I was having are gone. In particular, the context menus work. I loaded Migrate and set preferences, with a really nice appearance resulting.
One question: why did ClassDescription>>package go away? That seems to be a really useful message.
we have to check. because this is probably not intended.
I'll try to build an image using the SqueakSource mirror. No promises, but 1.4 "suddenly" looks a LOT more polished than it did. Are the links on the Pharo page old,
which page?
or did somebody just do a lot of work to make things better?
probably that too :)
Bill
participants (12)
-
Ben Coman -
Benoit St-Jean -
blake -
Camillo Bruni -
Dale Henrichs -
Henrik Johansen -
Igor Stasenko -
Miguel Cobá -
Schwab,Wilhelm K -
Stéphane Ducasse -
Sven Van Caekenberghe -
Yanni Chiu