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

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

by Dale Henrichs

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

Feb. 10, 2012

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

by Eliot Miranda

On Fri, Feb 10, 2012 at 1:19 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > All you need to do is to send it a stream. If the >>> stream is already at a certain position, it doesn't matter it will start >>> from that position. Say you have stream where you write something first >>> and >>> then you give it to Fuel to serialize. The stream would be at some >>> position >>> different than zero. Say, at position 10. Fuel will start serializing for >>> there. Say we have written 40 bytes. Then, at materialization, when you >>> give it the stream, you have to be sure to give the stream starting at >>> the >>> position 10. >>> >> However if you consider Fuel "the standard file format" - this would >> appear to be broken by people using random offsets. >> > > > yes, sure. But I think its ok to fail from the serializer point of view. > It is YOUR responsability to provide the correct streams. > > > >> Fuel will load EXACTLY 40 bytes and will stop. The stream can >>> continue....fuel doesn't care and it will store exactly when it finishes >>> reading his own bytes. >>> >>> BTW, this is how some databases work. The save several serialized objects >>> in the same stream... >>> >>> >> To reach for the moon... Perhaps Fuel "the standard file format" holding >> multiple streams might be formalized by tagging different each stream with >> a 'name' and/or a 'type' and/or 'deserializerMethod'. The first two of >> these might be '#fuel -> #fuelDeserializer' and '#meta->#textDeserializer'. > > > I don't understand. Fuel holding multiple streams ? why? for what? > e.g. for source code. Imagine storing Monticello packages in Fuel so that the source code is stored in the Fuel file and doesn't have to be written to the changes file. Instead, a more powerful SourceFilesArray (actually a source file manager) can maintain a set of source files, including Fuel files, and fetch source there-from. Hence loading is faster, and the changes file isn't polluted with code loads, containing only one's own code. e.g. for external resources. imagine loading a Fuel package that also contains some dlls that can be unpacked as required. But if you choose this route let me strongly suggest you use the zip file format. Its very useful with Monticello mcz's to be able to pick them apart using unzip. > > >> The the default Fuel system can then automatically ignore 3rd-party data. >> > > I want to make my point clear: Martin proposed an example that solves > Yanni problem. If you serialize with a stream with a certain position, then > you have to materialize it with its correct position. Dot. It is perfect > that the materializer is broken if you do not give him the correct stream. > Now, I DO agree that there could be another solution rather than adhoc, > supported by fuel so that BY DEFAULT some data could be set and ignored at > the same time...so that there is no manipulation of the srteam by the user. > > > >> Cheers >>> >>> >>> >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > -- best, Eliot

Feb. 10, 2012

Re: [Pharo-project] Need help with OpenGL visual creation on linux

by Lawson English

Is that code even ready for consumption? I was told that until there is a new ConfigurationOfNBOpenGL ready, to not load the new packages. L. On 2/10/12 10:12 AM, Javier PimÃ¡s wrote: > I'm trying to create an OpenGL context on linux but glxChooseVisual > fails. Maybe there's someone there experienced with this that can help. > > The code I'm trying is: > > display := NBXLibDisplay open. > window := display defaultRootWindow. > visualInfo := NBXLibVisualInfo fromPointer: (gl chooseVisual: display > screen: display defaultScreen attributes: {GLX_RGBA. GLX_DEPTH_SIZE. > 24. GLX_DOUBLEBUFFER. 0} asWordArray). > ... > > but chooseVisual returns a null pointer. I even tried putting an array > with only 0 on attributes but didn't work either (and these attributes > should be supported). > > Any idea of what could be wrong? The code is available to test in > squeaksource, you need nativeboost+NBXLib to try > > Cheers, > Javier > > -- > Lic. Javier PimÃ¡s > Ciudad de Buenos Aires

Feb. 10, 2012

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

by Yanni Chiu

On 10/02/12 1:03 PM, Martin Dias wrote: > > Great. Maybe we should include #nextMaterializedRootFrom: to fuel. That would be great. Probably best to leave off #allMaterializedRootsFrom: - it seemed necessary for completeness, but I've no actual need for it. > Based on metadata you might decide to not materialize the "real" > content. Like: > > metadata := (aMaterializer nextMaterializedRootFrom: aStream). > [ metadata isWhatINeed ] ifTrue: [ > realContent := aMaterializer nextMaterializedRootFrom: aStream ]. Yes, that's the usage scenario.

Feb. 10, 2012

Re: [Pharo-project] Debugger hanging... was Re: 1.4 - better from Jenkins

by Schwab,Wilhelm K

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(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Ben Coman [btc(a)openInWorld.com] Sent: Friday, February 10, 2012 12:42 PM To: Pharo-project(a)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(a)lists.gforge.inria.fr >> [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of blake >> [dsblakewatson(a)gmail.com] >> Sent: Thursday, February 09, 2012 2:58 PM >> To: Pharo-project(a)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 > >

Feb. 10, 2012

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

by Schwab,Wilhelm K

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

Feb. 10, 2012

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

by Martin Dias

On Fri, Feb 10, 2012 at 2:45 PM, Yanni Chiu <yanni(a)rogers.com> wrote: > On 10/02/12 10:24 AM, Martin Dias wrote: > >> Maybe is too much overhead, but it is also possible to serialize an >> object that represents the metadata as a prefix: >> >> FileStream forceNewFileNamed: 'demoMetadata.fuel' do: [:aStream | >> aStream binary. >> metadata := Dictionary with: #meta -> 5. >> content := 'stuff'. >> FLSerializer newDefault >> serialize: metadata on: aStream; >> serialize: content on: aStream ]. >> >> FileStream oldFileNamed: 'demoMetadata.fuel' do: [:aStream | >> | aMaterializer | >> aStream binary. >> aMaterializer := FLMaterializer newDefault. >> metadata := (aMaterializer materializeFrom: aStream) root. >> content := (aMaterializer materializeFrom: aStream) root ]. >> > > I like this solution best, since it doesn't change the Fuel "file format". > > I added some helper methods to my code base to make this usage scenario > more obvious: > > FLMaterializer>>**nextMaterializedRootFrom: sourceStream > ^ (self materializeFrom: sourceStream) root > > FLMaterializer>>**allMaterializedRootsFrom: sourceStream > | contents | > contents := OrderedCollection new. > [ sourceStream atEnd ] > whileFalse: [ contents add: (self nextMaterializedRootFrom: > sourceStream) ]. > ^ contents > > > Sample usage: > > > FileStream forceNewFileNamed: 'demoMetadata.fuel' do: [:aStream | > | serializer | > aStream binary. > serializer := FLSerializer newDefault. > (1 to: 5) do: [ :each | serializer serialize: (Dictionary with: each -> > (each * each)) on: aStream ]. > > ]. > > FileStream oldFileNamed: 'demoMetadata.fuel' do: [:aStream | > | aMaterializer | > aStream binary. > aMaterializer := FLMaterializer newDefault. > aMaterializer allMaterializedRootsFrom: aStream ]. > > > > FileStream oldFileNamed: 'demoMetadata.fuel' do: [:aStream | > | aMaterializer | > aStream binary. > aMaterializer := FLMaterializer newDefault. > aMaterializer nextMaterializedRootFrom: aStream. > aMaterializer nextMaterializedRootFrom: aStream. > ]. > Great. Maybe we should include #nextMaterializedRootFrom: to fuel. Based on metadata you might decide to not materialize the "real" content. Like: metadata := (aMaterializer nextMaterializedRootFrom: aStream). [ metadata isWhatINeed ] ifTrue: [ realContent := aMaterializer nextMaterializedRootFrom: aStream ].

Feb. 10, 2012

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

by Yanni Chiu

On 10/02/12 5:33 AM, Schwab,Wilhelm K wrote: > > For all I know, I have made this reproducible. I must have missed the steps to reproduce it. Can you repeat them: - what Pharo-1.4 image are you starting from? - what doIt's are you executing, up to the point you see a problem? > One response said > essentially, "yeah, I sometimes just load the packages MC would load" > - hardly the way one speaks of a robust infrastructure. If you're loading configurations into Pharo-1.4-unstable, you're doing a porting task. Pharo1.4 is under development and is a work in progress. It's quite possible that a package you're trying to load does not work on the particular Pharo-1.4-unstable you're using. This says nothing about "robust infrastructure". When I said to load the MC packages individually, that was the process you might need to follow to debug a problem with that package on Pharo-1.4-unstable.

Feb. 10, 2012

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

by Schwab,Wilhelm K

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(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Ben Coman [btc(a)openInWorld.com] Sent: Friday, February 10, 2012 12:21 PM To: Pharo-project(a)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(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of blake [dsblakewatson(a)gmail.com] > Sent: Thursday, February 09, 2012 2:58 PM > To: Pharo-project(a)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

Feb. 10, 2012

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

by Dale Henrichs

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

Feb. 10, 2012