1.4 - better from Jenkins

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
52 messages Options
123
Reply | Threaded
Open this post in threaded view
|

1.4 - better from Jenkins

Schwab,Wilhelm K
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


Reply | Threaded
Open this post in threaded view
|

Re: 1.4 - better from Jenkins

blake watson
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 <[hidden email]> 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
>
>

Reply | Threaded
Open this post in threaded view
|

Re: 1.4 - better from Jenkins

Miguel Cobá
In reply to this post by Schwab,Wilhelm K
On Thu, Feb 9, 2012 at 1:06 PM, Schwab,Wilhelm K <[hidden email]> 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á

Reply | Threaded
Open this post in threaded view
|

Re: 1.4 - better from Jenkins

Schwab,Wilhelm K
In reply to this post by blake watson
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: [hidden email] [[hidden email]] on behalf of blake [[hidden email]]
Sent: Thursday, February 09, 2012 2:58 PM
To: [hidden email]
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 <[hidden email]> 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
>
>


Reply | Threaded
Open this post in threaded view
|

Re: 1.4 - better from Jenkins

Schwab,Wilhelm K
In reply to this post by 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: [hidden email] [[hidden email]] on behalf of Miguel Cobá [[hidden email]]
Sent: Thursday, February 09, 2012 3:12 PM
To: [hidden email]
Subject: Re: [Pharo-project] 1.4 - better from Jenkins

On Thu, Feb 9, 2012 at 1:06 PM, Schwab,Wilhelm K <[hidden email]> 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á


Reply | Threaded
Open this post in threaded view
|

Re: 1.4 - better from Jenkins

Marcus Denker-4
In reply to this post by Miguel Cobá

On Feb 9, 2012, at 9:23 PM, Schwab,Wilhelm K wrote:

> 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.  

They are not. At least a) the link to 1.4 points to update 315, which is just 9 updates old. And for sure you would do a "load updates" anyway?
The download is just a copy from the build server. (same .zip, renamed), of some days ago. This is used by jenkins. Jenkins does nothing
else then "load updates" and save.

        Marcus

--
Marcus Denker -- http://marcusdenker.de


Reply | Threaded
Open this post in threaded view
|

Re: 1.4 - better from Jenkins

Schwab,Wilhelm K
I did not load updates - that might be the difference.  But there is also a difference in the vm.  The web site says to "just use the vm from 1.3" which I took to be the one-click?  So I renamed and copied the 1.4 image and changes into the resources directory.  It make one think there should be a better way, maybe there is?

For this image, I simply dumped 1.4 and Cog-linux from Jenkins into one folder and made a shell script to run the image.  Overall, that is a much simpler process.  If it is sound, it might be best to reduce the number of links on the site and to recommend the above for using 1.4.

Bill


________________________________________
From: [hidden email] [[hidden email]] on behalf of Marcus Denker [[hidden email]]
Sent: Thursday, February 09, 2012 3:32 PM
To: [hidden email]
Subject: Re: [Pharo-project] 1.4 - better from Jenkins

On Feb 9, 2012, at 9:23 PM, Schwab,Wilhelm K wrote:

> 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.

They are not. At least a) the link to 1.4 points to update 315, which is just 9 updates old. And for sure you would do a "load updates" anyway?
The download is just a copy from the build server. (same .zip, renamed), of some days ago. This is used by jenkins. Jenkins does nothing
else then "load updates" and save.

        Marcus

--
Marcus Denker -- http://marcusdenker.de



Reply | Threaded
Open this post in threaded view
|

Re: 1.4 - better from Jenkins

Schwab,Wilhelm K
In reply to this post by Schwab,Wilhelm K
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: [hidden email] [[hidden email]] on behalf of Schwab,Wilhelm K [[hidden email]]
Sent: Thursday, February 09, 2012 3:15 PM
To: [hidden email]
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: [hidden email] [[hidden email]] on behalf of blake [[hidden email]]
Sent: Thursday, February 09, 2012 2:58 PM
To: [hidden email]
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 <[hidden email]> 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
>
>



Reply | Threaded
Open this post in threaded view
|

Re: 1.4 - better from Jenkins

Sven Van Caekenberghe

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


Reply | Threaded
Open this post in threaded view
|

Re: 1.4 - better from Jenkins

Schwab,Wilhelm K
Sven,

Fair enough, but the game plan is for people to use Metacello configurations to load what they need to build an image.  I am attempting to do just that, and am reporting (rather negative so far) experience, with debug logs.

Pharo's fault or not, something is broken.  But if Pharo is going to send users into the current state of Metacello, the weather around the lighthouse is going to be grim.

Interesting ideas about the package cache being damaged.  Maybe the logs will reveal something??

Bill

________________________________________
From: [hidden email] [[hidden email]] on behalf of Sven Van Caekenberghe [[hidden email]]
Sent: Thursday, February 09, 2012 5:14 PM
To: [hidden email]
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



Reply | Threaded
Open this post in threaded view
|

Re: 1.4 - better from Jenkins

Yanni Chiu
On 09/02/12 5:39 PM, Schwab,Wilhelm K wrote:
> Sven,
>
> Fair enough, but the game plan is for people to use Metacello configurations to load what they need to build an image.  I am attempting to do just that, and am reporting (rather negative so far) experience, with debug logs.
>
> Pharo's fault or not, something is broken.  But if Pharo is going to send users into the current state of Metacello, the weather around the lighthouse is going to be grim.
>
> Interesting ideas about the package cache being damaged.  Maybe the logs will reveal something??

You might want to check the package cache for 0-length .mcz files, which
might happen when the server is down.

When I upgrade to a new image version, I just start my build process
with the new image, and cross my fingers. If it fails, then I do it
manually with the build script in a workspace - select each
framework/package and "doIt". Sometimes I run the framework's tests,
after each step.

I load all "community" code first, unless I have extensions to this
code. Sometimes I've had to upgrade to a newer version of the framework,
if available. At other times, I had to create patches because I was
tracking the Pharo updates (so no fixed version was available yet).

In extreme cases, I've had to generate the list of packages that
Metacello would load, then load each .mcz individually.

Typically, I'd do "save image as" at various points, to be able to get
back to the problem code, more quickly.

I think you're pretty much following a similar process, except the
expectation that a Metacello configuration should just load without
problems on Pharo1.4-unstable is too optimistic.


Reply | Threaded
Open this post in threaded view
|

Re: 1.4 - better from Jenkins

Schwab,Wilhelm K
I think you might be right about loading the .mcz files.  But I don't have an expectation other than what has been said here many times: that Metacello is the future.  So far, I don't see it.

Bill


________________________________________
From: [hidden email] [[hidden email]] on behalf of Yanni Chiu [[hidden email]]
Sent: Thursday, February 09, 2012 6:22 PM
To: [hidden email]
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.



Reply | Threaded
Open this post in threaded view
|

Re: 1.4 - better from Jenkins

Schwab,Wilhelm K
In reply to this post by Yanni Chiu
Just checked: no zero-length files.


________________________________________
From: [hidden email] [[hidden email]] on behalf of Yanni Chiu [[hidden email]]
Sent: Thursday, February 09, 2012 6:22 PM
To: [hidden email]
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.



Reply | Threaded
Open this post in threaded view
|

Re: 1.4 - better from Jenkins

Dale Henrichs
In reply to this post by Schwab,Wilhelm K
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" <[hidden email]>
| To: [hidden email]
| 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: [hidden email]
| [[hidden email]] on behalf of Yanni
| Chiu [[hidden email]]
| Sent: Thursday, February 09, 2012 6:22 PM
| To: [hidden email]
| 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.
|
|
|
|

Reply | Threaded
Open this post in threaded view
|

Re: 1.4 - better from Jenkins

Benoit St-Jean
Before we even get to the details, we should make sure we all exchange on a polite and non agressive tone.

That being said, I don't think Bill is whining.  You never hear people who don't care.  I don't give a damn about product X, environment Y and programming language Z.  That's why I never complain (or whine) about X, Y or Z.  On the other hand, that's why you'll hear me complain about Smalltalk, Pharo, mathematics and a few other topics.  Why?  Because I care!

Saying stuff don't work shouldn't be perceived as an ad hominem attack.  It just shows someone, somewhere, somehow had an interest to say it so it gets fixed.  And please, no "if you're no happy why don't you fix it and contribute" answer...  This is the kind of answer that made me walk away from Pharo at a certain point...

If we can't take critics/bugs/suggestions/tickets/whatever without entering a "defensive mode", we won't get far.

Let's keep it cool and remember that nobody forced anyone to use Pharo and read this mailing list and take the time to post.

We're all here because we do care!
 
-----------------
Benoit St-Jean
Yahoo! Messenger: bstjean
A standpoint is an intellectual horizon of radius zero.
(Albert Einstein)

From: Dale Henrichs <[hidden email]>
To: [hidden email]
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" <[hidden email]>
| To: [hidden email]
| 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: [hidden email]
| [[hidden email]] on behalf of Yanni
| Chiu [[hidden email]]
| Sent: Thursday, February 09, 2012 6:22 PM
| To: [hidden email]
| 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.
|
|
|
|



Reply | Threaded
Open this post in threaded view
|

Re: 1.4 - better from Jenkins

Dale Henrichs
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" <[hidden email]>
| To: [hidden email]
| 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 <[hidden email]>
| To: [hidden email]
| 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" < [hidden email] >
| | To: [hidden email]
| | 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: [hidden email]
| | [ [hidden email] ] on behalf of Yanni
| | Chiu [ [hidden email] ]
| | Sent: Thursday, February 09, 2012 6:22 PM
| | To: [hidden email]
| | 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.
| |
| |
| |
| |
|
|
|
|

Reply | Threaded
Open this post in threaded view
|

Re: 1.4 - better from Jenkins

Igor Stasenko
In reply to this post by Schwab,Wilhelm K
On 9 February 2012 22:27, Schwab,Wilhelm K <[hidden email]> 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=ID%20Type%20Status%20Summary%20Milestone%20Difficulty
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: [hidden email] [[hidden email]] on behalf of Schwab,Wilhelm K [[hidden email]]
> Sent: Thursday, February 09, 2012 3:15 PM
> To: [hidden email]
> 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: [hidden email] [[hidden email]] on behalf of blake [[hidden email]]
> Sent: Thursday, February 09, 2012 2:58 PM
> To: [hidden email]
> 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 <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: 1.4 - better from Jenkins

Schwab,Wilhelm K
In reply to this post by Dale Henrichs
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: [hidden email] [[hidden email]] on behalf of Dale Henrichs [[hidden email]]
Sent: Thursday, February 09, 2012 8:33 PM
To: [hidden email]
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" <[hidden email]>
| To: [hidden email]
| 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: [hidden email]
| [[hidden email]] on behalf of Yanni
| Chiu [[hidden email]]
| Sent: Thursday, February 09, 2012 6:22 PM
| To: [hidden email]
| 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.
|
|
|
|


Reply | Threaded
Open this post in threaded view
|

Re: 1.4 - better from Jenkins

Schwab,Wilhelm K
In reply to this post by Benoit St-Jean
Thanks for that.  I *do* care, which is why I'm trying to actually use this stuff.  Well said.




From: [hidden email] [[hidden email]] on behalf of Benoit St-Jean [[hidden email]]
Sent: Thursday, February 09, 2012 8:59 PM
To: [hidden email]
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 <[hidden email]>
To: [hidden email]
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" <[hidden email]>
| To: [hidden email]
| 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: [hidden email]
| [[hidden email]] on behalf of Yanni
| Chiu [[hidden email]]
| Sent: Thursday, February 09, 2012 6:22 PM
| To: [hidden email]
| 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.
|
|
|
|



Reply | Threaded
Open this post in threaded view
|

Re: 1.4 - better from Jenkins

Marcus Denker-4
In reply to this post by Dale Henrichs

On Feb 10, 2012, at 11:22 AM, Schwab,Wilhelm K wrote:

> 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?
>
What we need is a description of how to re-produce the problem.
Do not think that anyone can (or even wants to help) if you just say "I did something and than I got strange results".

Make it reproducable, and then add a bug report.

        Marcus

--
Marcus Denker -- http://marcusdenker.de


123