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

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

by Schwab,Wilhelm K

Thanks for that. I *do* care, which is why I'm trying to actually use this stuff. Well said. ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Benoit St-Jean [bstjean(a)yahoo.com] Sent: Thursday, February 09, 2012 8:59 PM To: Pharo-project(a)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(a)vmware.com> To: Pharo-project(a)lists.gforge.inria.fr Sent: Thursday, February 9, 2012 8:33:20 PM Subject: Re: [Pharo-project] 1.4 - better from Jenkins Bill, The last time you complained about Metacello being broken I asked you for a stack trace and I have seen no stack trace, although I believe that you were able to confirm that Metacello worked fine until you loaded some of your own code into the system ... Here you are complaining again ... if you don't provide specifics, the issues cannot be resolved ... There are apparently a lot of moving parts in your system, so it takes great attention to detail to get such a system running smoothly. The fact that you don't provide specifics tells me that perhaps you are not paying attention to the details ... When you are porting to a new environment (for you) like Pharo 1.4, you should stop and isolate the FIRST ERROR that you encounter ... in a complicated system once an error occurs, all bets are off ... You MUST pay attention to details ... You state that you have a giant debug log ... so it sounds like you tried to keep moving forward in the face of initial errors...I say good luck with that approach! If you post a Metacello stack trace I can very likely tell you what went wrong, if you prefer to continue to whine and complain about Metacello without even attempting to help me characterize the issues, then I will leave you to your own devices and you can can complain about Metacello all you want --- I won't be paying attention any more:) Dale ----- Original Message ----- | From: "Wilhelm K Schwab" <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> | To: Pharo-project(a)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(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> | [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] on behalf of Yanni | Chiu [yanni(a)rogers.com<mailto:yanni@rogers.com>] | Sent: Thursday, February 09, 2012 6:22 PM | To: pharo-project(a)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. | | | |

Feb. 10, 2012

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

by Schwab,Wilhelm K

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

[Pharo-project] [update 1.4] #14325

by Marcus Denker

14325 ----- Issue 4647: Update Filesystem Dialogs to use the new FS implementation http://code.google.com/p/pharo/issues/detail?id=4647 -- Marcus Denker -- http://marcusdenker.de

Feb. 10, 2012

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

by Igor Stasenko

On 9 February 2012 22:27, Schwab,Wilhelm K <bschwab(a)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(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu] > Sent: Thursday, February 09, 2012 3:15 PM > To: Pharo-project(a)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(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. > > 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(a)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.

Feb. 10, 2012

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

by Mariano Martinez Peck

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

Feb. 10, 2012

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

by Ben Coman

Mariano Martinez Peck wrote: > On Fri, Feb 10, 2012 at 7:01 AM, Yanni Chiu <yanni(a)rogers.com> wrote: > > >> On 09/02/12 10:20 PM, Martin Dias wrote: >> >> >>> Hi! >>> We don't have unused fields, but there is no problem to add your own >>> prefix: >>> [...] >>> >>> >>> Is this ok for you? >>> >>> >> It'll do the job. Here's what the file would have: >> >> yanni$ od -c demoMetadata.fuel >> 0000000 \n m e t a d a t a = 5 F U E L \0 >> 0000020 021 017 F L U I n t 1 6 C l u s t e >> 0000040 r \0 \0 \0 001 \0 \0 \0 001 \0 \0 \0 \0 023 F L >> 0000060 B y t e S t r i n g C l u s t e >> 0000100 r \0 \0 \0 001 005 s t u f f \0 001 >> 0000115 >> >> It's strange that there is a '\n' at the start. [Okay, figured it out, >> it's the character count.] >> >> Having "FUEL" and version number appear some where other than the start of >> file doesn't feel right. And, for sure, FLMaterializer will not just read >> the file, without some prior code to position the stream past the metadata >> - i.e. the file is no longer in "standard" Fuel format. >> >> Would Fuel have a problem with extra bytes at the end? >> >> >> >> > No. Fuel doesn't care. If you consider Fuel "the technology" you may be right. > 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. > 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'. The the default Fuel system can then automatically ignore 3rd-party data. > Cheers > >

Feb. 10, 2012

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

by Mariano Martinez Peck

On Fri, Feb 10, 2012 at 7:01 AM, Yanni Chiu <yanni(a)rogers.com> wrote: > On 09/02/12 10:20 PM, Martin Dias wrote: > >> Hi! >> We don't have unused fields, but there is no problem to add your own >> prefix: >> [...] >> >> >> Is this ok for you? >> > > It'll do the job. Here's what the file would have: > > yanni$ od -c demoMetadata.fuel > 0000000 \n m e t a d a t a = 5 F U E L \0 > 0000020 021 017 F L U I n t 1 6 C l u s t e > 0000040 r \0 \0 \0 001 \0 \0 \0 001 \0 \0 \0 \0 023 F L > 0000060 B y t e S t r i n g C l u s t e > 0000100 r \0 \0 \0 001 005 s t u f f \0 001 > 0000115 > > It's strange that there is a '\n' at the start. [Okay, figured it out, > it's the character count.] > > Having "FUEL" and version number appear some where other than the start of > file doesn't feel right. And, for sure, FLMaterializer will not just read > the file, without some prior code to position the stream past the metadata > - i.e. the file is no longer in "standard" Fuel format. > > Would Fuel have a problem with extra bytes at the end? > > > No. Fuel doesn't care. 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. 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... Cheers -- Mariano http://marianopeck.wordpress.com

Feb. 10, 2012

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

by Yanni Chiu

On 09/02/12 10:20 PM, Martin Dias wrote: > Hi! > We don't have unused fields, but there is no problem to add your own prefix: >[...] > > Is this ok for you? It'll do the job. Here's what the file would have: yanni$ od -c demoMetadata.fuel 0000000 \n m e t a d a t a = 5 F U E L \0 0000020 021 017 F L U I n t 1 6 C l u s t e 0000040 r \0 \0 \0 001 \0 \0 \0 001 \0 \0 \0 \0 023 F L 0000060 B y t e S t r i n g C l u s t e 0000100 r \0 \0 \0 001 005 s t u f f \0 001 0000115 It's strange that there is a '\n' at the start. [Okay, figured it out, it's the character count.] Having "FUEL" and version number appear some where other than the start of file doesn't feel right. And, for sure, FLMaterializer will not just read the file, without some prior code to position the stream past the metadata - i.e. the file is no longer in "standard" Fuel format. Would Fuel have a problem with extra bytes at the end?

Feb. 10, 2012

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

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

Feb. 10, 2012

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

by Martin Dias

Hi! We don't have unused fields, but there is no problem to add your own prefix: FileStream newFileNamed: 'demoMetadata.fuel' do: [:aStream | aStream binary. aStream nextStringPut: 'metadata=5'. FLSerializer newDefault serialize: 'stuff' on: aStream ]. FileStream oldFileNamed: 'demoMetadata.fuel' do: [:aStream | aStream binary. metadata := aStream nextString. stuff := (FLMaterializer newDefault materializeFrom: aStream) root ]. Is this ok for you? Best regards, Martin On Thu, Feb 9, 2012 at 8:25 PM, Yanni Chiu <yanni(a)rogers.com> wrote: > I'd like to store some metadata in a Fuel serialized file. I'd like to be > able to read that metadata, without de-serializing the file. So, if there > were a fixed header at the start of the file, with some "unused" fields, > that would be ideal. > > >

Feb. 10, 2012