The road to 1.0
Locked
 
|
Since 1.0-beta.23 has been released, I have not heard of many issues
related to the currentVersion code or the removal of all of those methods, so it appears that things are fairly stable for Metacello. I am planning on fixing the address following issues before releasing 1.0: - Issue 47 "Standardize date format for spec " - Issue 53 "OB-Metacello menu should have 'How To...' menu " - Issue 54 "Add a changelog message to spec to avoid using description as a multiline message " - Issue 57 "specificy method category for version category in Metacello version constructor " - Issue 58 "make #file: optional in project reference specification " - Issue 59 "repository overrides should be used for MetacelloProject>>updateProject " - finalize the Metacello version format Scan the issue list[1] and let me know if there are any other issues that should be addressed or submit an issue for things you'd like addressed before 1.0. Dale [1] - http://code.google.com/p/metacello/issues/list |
|
|
On 19 févr. 2010, at 02:22, Dale wrote: > Since 1.0-beta.23 has been released, I have not heard of many issues > related to the currentVersion code or the removal of all of those > methods, so it appears that things are fairly stable for Metacello. > > I am planning on fixing the address following issues before releasing > 1.0: > > - Issue 47 "Standardize date format for spec " > - Issue 53 "OB-Metacello menu should have 'How To...' menu " > - Issue 54 "Add a changelog message to spec to avoid using > description as a multiline message " > - Issue 57 "specificy method category for version category in > Metacello version constructor " > - Issue 58 "make #file: optional in project reference specification > " > - Issue 59 "repository overrides should be used for > MetacelloProject>>updateProject " > - finalize the Metacello version format > > Scan the issue list[1] and let me know if there are any other issues > that should be addressed or submit an issue for things you'd like > addressed before 1.0. Yep, I would like issue 56 to be tackled with 1.0, please Dan :) "save configurtion that uses Gofer>>commit:" -- Simon |
|
|
done:)
----- "Simon Denier" <[hidden email]> wrote: | On 19 févr. 2010, at 02:22, Dale wrote: | | > Since 1.0-beta.23 has been released, I have not heard of many | issues | > related to the currentVersion code or the removal of all of those | > methods, so it appears that things are fairly stable for Metacello. | > | > I am planning on fixing the address following issues before | releasing | > 1.0: | > | > - Issue 47 "Standardize date format for spec " | > - Issue 53 "OB-Metacello menu should have 'How To...' menu " | > - Issue 54 "Add a changelog message to spec to avoid using | > description as a multiline message " | > - Issue 57 "specificy method category for version category in | > Metacello version constructor " | > - Issue 58 "make #file: optional in project reference | specification | > " | > - Issue 59 "repository overrides should be used for | > MetacelloProject>>updateProject " | > - finalize the Metacello version format | > | > Scan the issue list[1] and let me know if there are any other | issues | > that should be addressed or submit an issue for things you'd like | > addressed before 1.0. | | | Yep, I would like issue 56 to be tackled with 1.0, please Dan :) | "save configurtion that uses Gofer>>commit:" | | | -- | Simon |
|
|
El vie, 19-02-2010 a las 09:58 -0800, Dale Henrichs escribió:
> done:) > Some thing that I would like is that metacello, after resolving the install sequence, and just before beginning installing, connect to the relevant repositories, and download the required packages files to the machine being installed. Then only after getting all the packages downloaded, begin the actual install. Why? because somethimes, after downloading and installing 40 packages, the number 41 can't be downloaded due to - network problems, - repository down, - you have just 5 minutes left before the flight leave - you're testing your ConfigurationOfXXX and can't bear the time between a package install and the next one while is downloading. :) - you don't want the image get half installed in the event that the last package wasn't found in the repo. I hope isn't that hard but if could be done would be great. I think that is related to: http://code.google.com/p/metacello/issues/detail?id=24 Cheers > > ----- "Simon Denier" <[hidden email]> wrote: > > | On 19 févr. 2010, at 02:22, Dale wrote: > | > | > Since 1.0-beta.23 has been released, I have not heard of many > | issues > | > related to the currentVersion code or the removal of all of those > | > methods, so it appears that things are fairly stable for Metacello. > | > > | > I am planning on fixing the address following issues before > | releasing > | > 1.0: > | > > | > - Issue 47 "Standardize date format for spec " > | > - Issue 53 "OB-Metacello menu should have 'How To...' menu " > | > - Issue 54 "Add a changelog message to spec to avoid using > | > description as a multiline message " > | > - Issue 57 "specificy method category for version category in > | > Metacello version constructor " > | > - Issue 58 "make #file: optional in project reference > | specification > | > " > | > - Issue 59 "repository overrides should be used for > | > MetacelloProject>>updateProject " > | > - finalize the Metacello version format > | > > | > Scan the issue list[1] and let me know if there are any other > | issues > | > that should be addressed or submit an issue for things you'd like > | > addressed before 1.0. > | > | > | Yep, I would like issue 56 to be tackled with 1.0, please Dan :) > | "save configurtion that uses Gofer>>commit:" > | > | > | -- > | Simon -- Miguel Cobá http://miguel.leugim.com.mx |
|
|
Miguel,
Good point ... it shouldn't be too difficult and it certainly would be worth doing ... If it turns out to turn into a rats nest I'll defer it, but it is definitely worth making an attempt, since it will save grief ... As I ponder this feature, I imagine that I would add a command something like 'prefetchLoad:' that would initiate the prefetch operation ...Would that work for you? Dale ----- "Miguel Enrique Cobá Martinez" <[hidden email]> wrote: | El vie, 19-02-2010 a las 09:58 -0800, Dale Henrichs escribió: | > done:) | > | | Some thing that I would like is that metacello, after resolving the | install sequence, and just before beginning installing, connect to | the | relevant repositories, and download the required packages files to | the | machine being installed. Then only after getting all the packages | downloaded, begin the actual install. Why? because somethimes, after | downloading and installing 40 packages, the number 41 can't be | downloaded due to | - network problems, | - repository down, | - you have just 5 minutes left before the flight leave | - you're testing your ConfigurationOfXXX and can't bear the time | between | a package install and the next one while is downloading. :) | - you don't want the image get half installed in the event that the | last | package wasn't found in the repo. | | I hope isn't that hard but if could be done would be great. | | I think that is related to: | | http://code.google.com/p/metacello/issues/detail?id=24 | | Cheers | | > | > ----- "Simon Denier" <[hidden email]> wrote: | > | > | On 19 févr. 2010, at 02:22, Dale wrote: | > | | > | > Since 1.0-beta.23 has been released, I have not heard of many | > | issues | > | > related to the currentVersion code or the removal of all of | those | > | > methods, so it appears that things are fairly stable for | Metacello. | > | > | > | > I am planning on fixing the address following issues before | > | releasing | > | > 1.0: | > | > | > | > - Issue 47 "Standardize date format for spec " | > | > - Issue 53 "OB-Metacello menu should have 'How To...' menu " | > | > - Issue 54 "Add a changelog message to spec to avoid using | > | > description as a multiline message " | > | > - Issue 57 "specificy method category for version category in | > | > Metacello version constructor " | > | > - Issue 58 "make #file: optional in project reference | > | specification | > | > " | > | > - Issue 59 "repository overrides should be used for | > | > MetacelloProject>>updateProject " | > | > - finalize the Metacello version format | > | > | > | > Scan the issue list[1] and let me know if there are any other | > | issues | > | > that should be addressed or submit an issue for things you'd | like | > | > addressed before 1.0. | > | | > | | > | Yep, I would like issue 56 to be tackled with 1.0, please Dan :) | > | "save configurtion that uses Gofer>>commit:" | > | | > | | > | -- | > | Simon | | -- | Miguel Cobá | http://miguel.leugim.com.mx |
|
|
El vie, 19-02-2010 a las 11:19 -0800, Dale Henrichs escribió:
> Miguel, > > Good point ... it shouldn't be too difficult and it certainly would be worth doing ... If it turns out to turn into a rats nest I'll defer it, but it is definitely worth making an attempt, since it will save grief ... > > As I ponder this feature, I imagine that I would add a command something like 'prefetchLoad:' that would initiate the prefetch operation ...Would that work for you? > Yes, I was thinking that this should be, if implemented, transparent to the user, that is, he shouldn't have to specify that wants to first download the packages and then proceed with the install. I think that the way Metacello work should be always to first download everything (with progress bars of course) and then proceed with the install. Just like apt-get/aptitude work. they first resolve the packages versions, then download everything, finally install and configure. Unless someone have an argument for having the option to mix download/install packages, I think that this is the way to go. And as we are already reviewing the wish list, (I suppose that this is more feasible to do for 1.1 version) that Metacello avoid to use progress bars, outputing all the text messages and warnings to the transcript only, maybe with a message like silently: true (that by default is false so the behaviour is just like now). Why, because this will permit to completly script a metacello config and (maybe redirecting the transcript output to the console) help in the build process like the ones lukas and the pharo team is working at. But as I said, maybe this isn't as necessary but in a posterior release it would be good to have. Anyway, thanks for the hard work you're putting on this. It's already help us a lot and shown their value to the community. Cheers > Dale > ----- "Miguel Enrique Cobá Martinez" <[hidden email]> wrote: > > | El vie, 19-02-2010 a las 09:58 -0800, Dale Henrichs escribió: > | > done:) > | > > | > | Some thing that I would like is that metacello, after resolving the > | install sequence, and just before beginning installing, connect to > | the > | relevant repositories, and download the required packages files to > | the > | machine being installed. Then only after getting all the packages > | downloaded, begin the actual install. Why? because somethimes, after > | downloading and installing 40 packages, the number 41 can't be > | downloaded due to > | - network problems, > | - repository down, > | - you have just 5 minutes left before the flight leave > | - you're testing your ConfigurationOfXXX and can't bear the time > | between > | a package install and the next one while is downloading. :) > | - you don't want the image get half installed in the event that the > | last > | package wasn't found in the repo. > | > | I hope isn't that hard but if could be done would be great. > | > | I think that is related to: > | > | http://code.google.com/p/metacello/issues/detail?id=24 > | > | Cheers > | > | > > | > ----- "Simon Denier" <[hidden email]> wrote: > | > > | > | On 19 févr. 2010, at 02:22, Dale wrote: > | > | > | > | > Since 1.0-beta.23 has been released, I have not heard of many > | > | issues > | > | > related to the currentVersion code or the removal of all of > | those > | > | > methods, so it appears that things are fairly stable for > | Metacello. > | > | > > | > | > I am planning on fixing the address following issues before > | > | releasing > | > | > 1.0: > | > | > > | > | > - Issue 47 "Standardize date format for spec " > | > | > - Issue 53 "OB-Metacello menu should have 'How To...' menu " > | > | > - Issue 54 "Add a changelog message to spec to avoid using > | > | > description as a multiline message " > | > | > - Issue 57 "specificy method category for version category in > | > | > Metacello version constructor " > | > | > - Issue 58 "make #file: optional in project reference > | > | specification > | > | > " > | > | > - Issue 59 "repository overrides should be used for > | > | > MetacelloProject>>updateProject " > | > | > - finalize the Metacello version format > | > | > > | > | > Scan the issue list[1] and let me know if there are any other > | > | issues > | > | > that should be addressed or submit an issue for things you'd > | like > | > | > addressed before 1.0. > | > | > | > | > | > | Yep, I would like issue 56 to be tackled with 1.0, please Dan :) > | > | "save configurtion that uses Gofer>>commit:" > | > | > | > | > | > | -- > | > | Simon > | > | -- > | Miguel Cobá > | http://miguel.leugim.com.mx -- Miguel Cobá http://miguel.leugim.com.mx |
|
|
Miguel,
You have a good point ... I've already got something like this for the GemStone release process, where we create a directory-based repository containing all of the mcz needed to bootstrap a GLASS configuration, so I could adapt the algorithm to work for Metacello in general. I've submitted an issue about the progress bars ... originally I dumped all of the progress info to the transcript, but folks who don't normally open Transcripts complained about how long loads would take, so put in the progress bars. Would it make sense to push the progress bars into the Metacello tools group (i.e., OB-Metacello)? Loading OB-Metacello is an indication that you're in an interactive development image...Personally when I'm interactively loading things I can get a better feel for how far things have progressed with the progress bars than I can get from the Transcript... Dale ----- "Miguel Enrique Cobá Martinez" <[hidden email]> wrote: | El vie, 19-02-2010 a las 11:19 -0800, Dale Henrichs escribió: | > Miguel, | > | > Good point ... it shouldn't be too difficult and it certainly would | be worth doing ... If it turns out to turn into a rats nest I'll defer | it, but it is definitely worth making an attempt, since it will save | grief ... | > | > As I ponder this feature, I imagine that I would add a command | something like 'prefetchLoad:' that would initiate the prefetch | operation ...Would that work for you? | > | | Yes, I was thinking that this should be, if implemented, transparent | to | the user, that is, he shouldn't have to specify that wants to first | download the packages and then proceed with the install. I think that | the way Metacello work should be always to first download everything | (with progress bars of course) and then proceed with the install. | Just | like apt-get/aptitude work. they first resolve the packages versions, | then download everything, finally install and configure. | Unless someone have an argument for having the option to mix | download/install packages, I think that this is the way to go. | | And as we are already reviewing the wish list, (I suppose that this | is | more feasible to do for 1.1 version) that Metacello avoid to use | progress bars, outputing all the text messages and warnings to the | transcript only, maybe with a message like silently: true (that by | default is false so the behaviour is just like now). Why, because | this | will permit to completly script a metacello config and (maybe | redirecting the transcript output to the console) help in the build | process like the ones lukas and the pharo team is working at. But as | I | said, maybe this isn't as necessary but in a posterior release it | would | be good to have. | | Anyway, thanks for the hard work you're putting on this. It's already | help us a lot and shown their value to the community. | | Cheers | | | > Dale | > ----- "Miguel Enrique Cobá Martinez" <[hidden email]> wrote: | > | > | El vie, 19-02-2010 a las 09:58 -0800, Dale Henrichs escribió: | > | > done:) | > | > | > | | > | Some thing that I would like is that metacello, after resolving | the | > | install sequence, and just before beginning installing, connect | to | > | the | > | relevant repositories, and download the required packages files | to | > | the | > | machine being installed. Then only after getting all the packages | > | downloaded, begin the actual install. Why? because somethimes, | after | > | downloading and installing 40 packages, the number 41 can't be | > | downloaded due to | > | - network problems, | > | - repository down, | > | - you have just 5 minutes left before the flight leave | > | - you're testing your ConfigurationOfXXX and can't bear the time | > | between | > | a package install and the next one while is downloading. :) | > | - you don't want the image get half installed in the event that | the | > | last | > | package wasn't found in the repo. | > | | > | I hope isn't that hard but if could be done would be great. | > | | > | I think that is related to: | > | | > | http://code.google.com/p/metacello/issues/detail?id=24 | > | | > | Cheers | > | | > | > | > | > ----- "Simon Denier" <[hidden email]> wrote: | > | > | > | > | On 19 févr. 2010, at 02:22, Dale wrote: | > | > | | > | > | > Since 1.0-beta.23 has been released, I have not heard of | many | > | > | issues | > | > | > related to the currentVersion code or the removal of all of | > | those | > | > | > methods, so it appears that things are fairly stable for | > | Metacello. | > | > | > | > | > | > I am planning on fixing the address following issues before | > | > | releasing | > | > | > 1.0: | > | > | > | > | > | > - Issue 47 "Standardize date format for spec " | > | > | > - Issue 53 "OB-Metacello menu should have 'How To...' menu | " | > | > | > - Issue 54 "Add a changelog message to spec to avoid using | > | > | > description as a multiline message " | > | > | > - Issue 57 "specificy method category for version category | in | > | > | > Metacello version constructor " | > | > | > - Issue 58 "make #file: optional in project reference | > | > | specification | > | > | > " | > | > | > - Issue 59 "repository overrides should be used for | > | > | > MetacelloProject>>updateProject " | > | > | > - finalize the Metacello version format | > | > | > | > | > | > Scan the issue list[1] and let me know if there are any | other | > | > | issues | > | > | > that should be addressed or submit an issue for things | you'd | > | like | > | > | > addressed before 1.0. | > | > | | > | > | | > | > | Yep, I would like issue 56 to be tackled with 1.0, please Dan | :) | > | > | "save configurtion that uses Gofer>>commit:" | > | > | | > | > | | > | > | -- | > | > | Simon | > | | > | -- | > | Miguel Cobá | > | http://miguel.leugim.com.mx | | -- | Miguel Cobá | http://miguel.leugim.com.mx |
|
|
El vie, 19-02-2010 a las 14:14 -0800, Dale Henrichs escribió:
> Miguel, > > You have a good point ... I've already got something like this for the GemStone release process, where we create a directory-based repository containing all of the mcz needed to bootstrap a GLASS configuration, so I could adapt the algorithm to work for Metacello in general. > > I've submitted an issue about the progress bars ... originally I dumped all of the progress info to the transcript, but folks who don't normally open Transcripts complained about how long loads would take, so put in the progress bars. Would it make sense to push the progress bars into the Metacello tools group (i.e., OB-Metacello)? > Loading OB-Metacello is an indication that you're in an interactive development image...Personally when I'm interactively loading things I can get a better feel for how far things have progressed with the progress bars than I can get from the Transcript... > Yes, I agree that there isn't anything better than a progress bar to get the current state of a process. Just a simple usage like: my_build_script.st Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfPackage'; load. ((Smalltalk at: #ConfigurationOfPackage) project version: '1.0') silently: true; "or outputToTranscript: true" load. "Save as magma.image" SmalltalkImage current saveAs: 'magma'. SmalltalkImage current snapshot: true andQuit: true. Where silently, if not specified is false, so that uses progress bar as now. But when someone is scripting some image build, they specify it to true so that the image just work "headless" in loading packages. But Dale, I know that this particular change, even externally is simple, is very intrusive changing calls to progress bar with calls to log to transcript, so don't worry a lot for this. If someday is implemented, it will be good, if not, well, nothing is lost. The code works correctly and as good as it can be with the current behavior. Besides, maybe this feature isn't really needed, I *think* that it will be useful for continuous integration and automatic builds of pharo images where the complete log of the image building can be extracted to a file and shown in the interface of the image building software (like mason). But it is just what I think. Lukas or the people building the infrastructure will have better opinions than mine. -- Miguel Cobá http://miguel.leugim.com.mx |
|
|
For the progressBar, I would let something by default as it is in MetacelloPlatform >> do: aBlock displaying: aString
The MetacelloPharoPlatform >> do: aBlock displaying: aString I would like to have it only with Metacello-OB as Dale suggested. Regarding the prefetchLoad: cannot we use the project loadType: #linear. So that we can do project loadType: #preFetch. ? or the type is something different that I a confusing and mixing ? Cheers Mariano 2010/2/20 Miguel Enrique Cobá Martinez <[hidden email]> El vie, 19-02-2010 a las 14:14 -0800, Dale Henrichs escribió: |
|
|
Hi Dale. I am experimenting again the problem with the progress bar. Do you remember that when loading ImageForDevelopers trough Metacello I have this problem as in the post load of that package I reset the progress bar ?
Ok...today I put ImageForDevelopers again inside the Metacello configuartion, to try if it was working but I am still having problems. I attach PharoDebug.log To reproduce you have to take a PharoCore10515. If you try to load ConfigurationOfPharo in that image, in this way, it works ok: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfPharo'; load. ((Smalltalk at: #ConfigurationOfPharo) project version: '1.0-rc3.10515') load. The problem is that I run the core image from command line sending that text in a file (as parameter). Only there I have this problem :( Thanks Mariano On Tue, Feb 23, 2010 at 11:10 AM, Mariano Martinez Peck <[hidden email]> wrote: For the progressBar, I would let something by default as it is in MetacelloPlatform >> do: aBlock displaying: aString To unsubscribe from this group, send email to metacello+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject. |
PharoDebug.log (29K) |
|
In reply to this post by Miguel Cobá
Miguel,
I've implemented #silently: in 1.0-beta.25...it is a message to the MetacelloMCVersion and it turns off (or on) progress bars during that load. I've fixed the transcript feedback so that you can get pretty good information from the transcript if you have the progress bars turned off (Gemstone doesn't have proress bars yet)... In a future release we can get fancier with the logging/notification. I really appreciate your feedback. Dale ----- "Miguel Enrique Cobá Martinez" <[hidden email]> wrote: | El vie, 19-02-2010 a las 14:14 -0800, Dale Henrichs escribió: | > Miguel, | > | > You have a good point ... I've already got something like this for | the GemStone release process, where we create a directory-based | repository containing all of the mcz needed to bootstrap a GLASS | configuration, so I could adapt the algorithm to work for Metacello in | general. | > | > I've submitted an issue about the progress bars ... originally I | dumped all of the progress info to the transcript, but folks who don't | normally open Transcripts complained about how long loads would take, | so put in the progress bars. Would it make sense to push the progress | bars into the Metacello tools group (i.e., OB-Metacello)? | | > Loading OB-Metacello is an indication that you're in an interactive | development image...Personally when I'm interactively loading things I | can get a better feel for how far things have progressed with the | progress bars than I can get from the Transcript... | > | | | Yes, I agree that there isn't anything better than a progress bar to | get | the current state of a process. Just a simple usage like: | | my_build_script.st | Gofer new | squeaksource: 'MetacelloRepository'; | package: 'ConfigurationOfPackage'; | load. | | ((Smalltalk at: #ConfigurationOfPackage) project version: '1.0') | silently: true; "or outputToTranscript: true" | load. | | "Save as magma.image" | SmalltalkImage current saveAs: 'magma'. | SmalltalkImage current snapshot: true andQuit: true. | | | Where silently, if not specified is false, so that uses progress bar | as | now. But when someone is scripting some image build, they specify it | to | true so that the image just work "headless" in loading packages. | | But Dale, I know that this particular change, even externally is | simple, | is very intrusive changing calls to progress bar with calls to log to | transcript, so don't worry a lot for this. If someday is implemented, | it | will be good, if not, well, nothing is lost. The code works correctly | and as good as it can be with the current behavior. Besides, maybe | this | feature isn't really needed, I *think* that it will be useful for | continuous integration and automatic builds of pharo images where the | complete log of the image building can be extracted to a file and | shown | in the interface of the image building software (like mason). But it | is | just what I think. Lukas or the people building the infrastructure | will | have better opinions than mine. | | -- | Miguel Cobá | http://miguel.leugim.com.mx To unsubscribe from this group, send email to metacello+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject. |
|
|
In reply to this post by Dale
Mariano,
Try using Metacello 1.0-beta.25 ... today I've just run through loading latest for Seaside3.0/Seaside2.8/Moose so I don't anticipate to many changes and if you run into other troubles now would be a good time. So I've tried the following to good effect (once 1.0-beta.25 is loaded noisily): | version | version := ConfigurationOfMetacello project version: '1.0-beta.25'. version silently: true. version load: 'ALL'. and it should work if you with ConfigurationOfPharo... Dale ----- "Mariano Martinez Peck" <[hidden email]> wrote: | Hi Dale. I am experimenting again the problem with the progress bar. | Do you | remember that when loading ImageForDevelopers trough Metacello I have | this | problem as in the post load of that package I reset the progress bar | ? | | Ok...today I put ImageForDevelopers again inside the Metacello | configuartion, to try if it was working but I am still having | problems. I | attach PharoDebug.log | | To reproduce you have to take a PharoCore10515. If you try to load | ConfigurationOfPharo in that image, in this way, it works ok: | | Gofer new | squeaksource: 'MetacelloRepository'; | package: 'ConfigurationOfPharo'; | load. | | ((Smalltalk at: #ConfigurationOfPharo) project version: | '1.0-rc3.10515') | load. | | The problem is that I run the core image from command line sending | that text | in a file (as parameter). Only there I have this problem :( | | Thanks | | Mariano | | On Tue, Feb 23, 2010 at 11:10 AM, Mariano Martinez Peck < | [hidden email]> wrote: | | > For the progressBar, I would let something by default as it is in | > MetacelloPlatform >> do: aBlock displaying: aString | > | > The MetacelloPharoPlatform >> do: aBlock displaying: aString | > | > I would like to have it only with Metacello-OB as Dale suggested. | > | > Regarding the prefetchLoad: cannot we use the project loadType: | #linear. | > | > So that we can do project loadType: #preFetch. | > | > ? | > | > or the type is something different that I a confusing and mixing ? | > | > Cheers | > | > Mariano | > | > 2010/2/20 Miguel Enrique Cobá Martinez <[hidden email]> | > | > El vie, 19-02-2010 a las 14:14 -0800, Dale Henrichs escribió: | >> > Miguel, | >> > | >> > You have a good point ... I've already got something like this | for the | >> GemStone release process, where we create a directory-based | repository | >> containing all of the mcz needed to bootstrap a GLASS | configuration, so I | >> could adapt the algorithm to work for Metacello in general. | >> > | >> > I've submitted an issue about the progress bars ... originally I | dumped | >> all of the progress info to the transcript, but folks who don't | normally | >> open Transcripts complained about how long loads would take, so put | in the | >> progress bars. Would it make sense to push the progress bars into | the | >> Metacello tools group (i.e., OB-Metacello)? | >> | >> > Loading OB-Metacello is an indication that you're in an | interactive | >> development image...Personally when I'm interactively loading | things I can | >> get a better feel for how far things have progressed with the | progress bars | >> than I can get from the Transcript... | >> > | >> | >> | >> Yes, I agree that there isn't anything better than a progress bar | to get | >> the current state of a process. Just a simple usage like: | >> | >> my_build_script.st | >> Gofer new | >> squeaksource: 'MetacelloRepository'; | >> package: 'ConfigurationOfPackage'; | >> load. | >> | >> ((Smalltalk at: #ConfigurationOfPackage) project version: '1.0') | >> silently: true; "or outputToTranscript: true" | >> load. | >> | >> "Save as magma.image" | >> SmalltalkImage current saveAs: 'magma'. | >> SmalltalkImage current snapshot: true andQuit: true. | >> | >> | >> Where silently, if not specified is false, so that uses progress | bar as | >> now. But when someone is scripting some image build, they specify | it to | >> true so that the image just work "headless" in loading packages. | >> | >> But Dale, I know that this particular change, even externally is | simple, | >> is very intrusive changing calls to progress bar with calls to log | to | >> transcript, so don't worry a lot for this. If someday is | implemented, it | >> will be good, if not, well, nothing is lost. The code works | correctly | >> and as good as it can be with the current behavior. Besides, maybe | this | >> feature isn't really needed, I *think* that it will be useful for | >> continuous integration and automatic builds of pharo images where | the | >> complete log of the image building can be extracted to a file and | shown | >> in the interface of the image building software (like mason). But | it is | >> just what I think. Lukas or the people building the infrastructure | will | >> have better opinions than mine. | >> | >> -- | >> Miguel Cobá | >> http://miguel.leugim.com.mx | >> | >> | > | | To unsubscribe from this group, send email to | metacello+unsubscribegooglegroups.com or reply to this email with the | words "REMOVE ME" as the subject. To unsubscribe from this group, send email to metacello+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject. |
|
|
Thanks Dale!!! here is too late but tomorrow I will test it !!! but...it was exaclty what I was looking for :)
Thanks a lot. Mariano On Sat, Mar 20, 2010 at 2:12 AM, Dale Henrichs <[hidden email]> wrote: Mariano, To unsubscribe from this group, send email to metacello+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject. |
|
|
In reply to this post by Mariano Martinez Peck
El sáb, 20-03-2010 a las 01:43 +0100, Mariano Martinez Peck escribió:
> Hi Dale. I am experimenting again the problem with the progress bar. > Do you remember that when loading ImageForDevelopers trough Metacello > I have this problem as in the post load of that package I reset the > progress bar ? > Is this problem again? http://lists.gforge.inria.fr/pipermail/pharo-project/2010-January/020973.html or is a new one? Cheers > Ok...today I put ImageForDevelopers again inside the Metacello > configuartion, to try if it was working but I am still having > problems. I attach PharoDebug.log > > To reproduce you have to take a PharoCore10515. If you try to load > ConfigurationOfPharo in that image, in this way, it works ok: > > Gofer new > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfPharo'; > load. > > ((Smalltalk at: #ConfigurationOfPharo) project version: > '1.0-rc3.10515') load. > > The problem is that I run the core image from command line sending > that text in a file (as parameter). Only there I have this problem :( > > Thanks > > Mariano > > On Tue, Feb 23, 2010 at 11:10 AM, Mariano Martinez Peck > <[hidden email]> wrote: > For the progressBar, I would let something by default as it is > in MetacelloPlatform >> do: aBlock displaying: aString > > The MetacelloPharoPlatform >> do: aBlock displaying: aString > > I would like to have it only with Metacello-OB as Dale > suggested. > > Regarding the prefetchLoad: cannot we use the project > loadType: #linear. > > So that we can do project loadType: #preFetch. > > ? > > or the type is something different that I a confusing and > mixing ? > > Cheers > > Mariano > > 2010/2/20 Miguel Enrique Cobá Martinez <[hidden email]> > > > El vie, 19-02-2010 a las 14:14 -0800, Dale Henrichs > escribió: > > Miguel, > > > > You have a good point ... I've already got something > like this for the GemStone release process, where we > create a directory-based repository containing all of > the mcz needed to bootstrap a GLASS configuration, so > I could adapt the algorithm to work for Metacello in > general. > > > > I've submitted an issue about the progress bars ... > originally I dumped all of the progress info to the > transcript, but folks who don't normally open > Transcripts complained about how long loads would > take, so put in the progress bars. Would it make sense > to push the progress bars into the Metacello tools > group (i.e., OB-Metacello)? > > > Loading OB-Metacello is an indication that you're > in an interactive development image...Personally when > I'm interactively loading things I can get a better > feel for how far things have progressed with the > progress bars than I can get from the Transcript... > > > > > > Yes, I agree that there isn't anything better than a > progress bar to get > the current state of a process. Just a simple usage > like: > > my_build_script.st > Gofer new > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfPackage'; > load. > > ((Smalltalk at: #ConfigurationOfPackage) project > version: '1.0') > silently: true; "or outputToTranscript: true" > load. > > "Save as magma.image" > SmalltalkImage current saveAs: 'magma'. > SmalltalkImage current snapshot: true andQuit: true. > > > Where silently, if not specified is false, so that > uses progress bar as > now. But when someone is scripting some image build, > they specify it to > true so that the image just work "headless" in loading > packages. > > But Dale, I know that this particular change, even > externally is simple, > is very intrusive changing calls to progress bar with > calls to log to > transcript, so don't worry a lot for this. If someday > is implemented, it > will be good, if not, well, nothing is lost. The code > works correctly > and as good as it can be with the current behavior. > Besides, maybe this > feature isn't really needed, I *think* that it will be > useful for > continuous integration and automatic builds of pharo > images where the > complete log of the image building can be extracted to > a file and shown > in the interface of the image building software (like > mason). But it is > just what I think. Lukas or the people building the > infrastructure will > have better opinions than mine. > > > -- > Miguel Cobá > http://miguel.leugim.com.mx > > > > > > > To unsubscribe from this group, send email to metacello > +unsubscribegooglegroups.com or reply to this email with the words > "REMOVE ME" as the subject. -- Miguel Cobá http://miguel.leugim.com.mx To unsubscribe from this group, send email to metacello+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject. |
|
|
In reply to this post by Dale
On Sat, Mar 20, 2010 at 2:12 AM, Dale Henrichs <[hidden email]> wrote: Mariano, Here I have a problem. Evaluating this: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfMetacello'; load. version := ((Smalltalk at: #ConfigurationOfMetacello) project version: '1.0-beta.25'). version silently: true. Gives me a DNU with silently: After that, I checked evaluating: ConfigurationOfMetacello project currentVersion and prints ~1.0-beta.24.1 [ConfigurationOfMetacello] Instead of beta.25. Of course, in 24.1 there was no silently, and thus, the DNU. Any idae how can I fix this ? do you know when you are going to release beta25 ? As I want to release PharoRC3 SOON I want so see if I rollback my change (not a big deal at all) or if I wait. Thanks a lot Dale. Mariano
To unsubscribe from this group, send email to metacello+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject. |
|
|
In reply to this post by Miguel Cobá
2010/3/20 Miguel Enrique Cobá Martinez <[hidden email]> El sáb, 20-03-2010 a las 01:43 +0100, Mariano Martinez Peck escribió: Yes, it is the same problem. Look how I changed ConfigurationOfPharo in the last version. Cheers Mariano
To unsubscribe from this group, send email to metacello+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject. |
|
|
In reply to this post by Mariano Martinez Peck
Woops, I hadn't pushed a recent ConfigurationOfMetacello to MetacelloRepository ... try again ..
Dale ----- "Mariano Martinez Peck" <[hidden email]> wrote: | On Sat, Mar 20, 2010 at 2:12 AM, Dale Henrichs | <[hidden email]>wrote: | | > Mariano, | > | > Try using Metacello 1.0-beta.25 ... today I've just run through | loading | > latest for Seaside3.0/Seaside2.8/Moose so I don't anticipate to many | changes | > and if you run into other troubles now would be a good time. So I've | tried | > the following to good effect (once 1.0-beta.25 is loaded noisily): | > | > | version | | > version := ConfigurationOfMetacello project version: | '1.0-beta.25'. | > version silently: true. | > version load: 'ALL'. | > | | Here I have a problem. Evaluating this: | | | Gofer new | squeaksource: 'MetacelloRepository'; | package: 'ConfigurationOfMetacello'; | load. | | | version := ((Smalltalk at: #ConfigurationOfMetacello) project | version: | '1.0-beta.25'). | version silently: true. | | Gives me a DNU with silently: | | After that, I checked evaluating: | | ConfigurationOfMetacello project currentVersion | | and prints ~1.0-beta.24.1 [ConfigurationOfMetacello] | | Instead of beta.25. Of course, in 24.1 there was no silently, and | thus, the | DNU. | | Any idae how can I fix this ? do you know when you are going to | release | beta25 ? | | As I want to release PharoRC3 SOON I want so see if I rollback my | change | (not a big deal at all) or if I wait. | | Thanks a lot Dale. | | Mariano | | | | > | > and it should work if you with ConfigurationOfPharo... | > | > Dale | > ----- "Mariano Martinez Peck" <[hidden email]> wrote: | > | > | Hi Dale. I am experimenting again the problem with the progress | bar. | > | Do you | > | remember that when loading ImageForDevelopers trough Metacello I | have | > | this | > | problem as in the post load of that package I reset the progress | bar | > | ? | > | | > | Ok...today I put ImageForDevelopers again inside the Metacello | > | configuartion, to try if it was working but I am still having | > | problems. I | > | attach PharoDebug.log | > | | > | To reproduce you have to take a PharoCore10515. If you try to | load | > | ConfigurationOfPharo in that image, in this way, it works ok: | > | | > | Gofer new | > | squeaksource: 'MetacelloRepository'; | > | package: 'ConfigurationOfPharo'; | > | load. | > | | > | ((Smalltalk at: #ConfigurationOfPharo) project version: | > | '1.0-rc3.10515') | > | load. | > | | > | The problem is that I run the core image from command line | sending | > | that text | > | in a file (as parameter). Only there I have this problem :( | > | | > | Thanks | > | | > | Mariano | > | | > | On Tue, Feb 23, 2010 at 11:10 AM, Mariano Martinez Peck < | > | [hidden email]> wrote: | > | | > | > For the progressBar, I would let something by default as it is | in | > | > MetacelloPlatform >> do: aBlock displaying: aString | > | > | > | > The MetacelloPharoPlatform >> do: aBlock displaying: aString | > | > | > | > I would like to have it only with Metacello-OB as Dale | suggested. | > | > | > | > Regarding the prefetchLoad: cannot we use the project | loadType: | > | #linear. | > | > | > | > So that we can do project loadType: #preFetch. | > | > | > | > ? | > | > | > | > or the type is something different that I a confusing and mixing | ? | > | > | > | > Cheers | > | > | > | > Mariano | > | > | > | > 2010/2/20 Miguel Enrique Cobá Martinez <[hidden email]> | > | > | > | > El vie, 19-02-2010 a las 14:14 -0800, Dale Henrichs escribió: | > | >> > Miguel, | > | >> > | > | >> > You have a good point ... I've already got something like | this | > | for the | > | >> GemStone release process, where we create a directory-based | > | repository | > | >> containing all of the mcz needed to bootstrap a GLASS | > | configuration, so I | > | >> could adapt the algorithm to work for Metacello in general. | > | >> > | > | >> > I've submitted an issue about the progress bars ... | originally I | > | dumped | > | >> all of the progress info to the transcript, but folks who | don't | > | normally | > | >> open Transcripts complained about how long loads would take, so | put | > | in the | > | >> progress bars. Would it make sense to push the progress bars | into | > | the | > | >> Metacello tools group (i.e., OB-Metacello)? | > | >> | > | >> > Loading OB-Metacello is an indication that you're in an | > | interactive | > | >> development image...Personally when I'm interactively loading | > | things I can | > | >> get a better feel for how far things have progressed with the | > | progress bars | > | >> than I can get from the Transcript... | > | >> > | > | >> | > | >> | > | >> Yes, I agree that there isn't anything better than a progress | bar | > | to get | > | >> the current state of a process. Just a simple usage like: | > | >> | > | >> my_build_script.st | > | >> Gofer new | > | >> squeaksource: 'MetacelloRepository'; | > | >> package: 'ConfigurationOfPackage'; | > | >> load. | > | >> | > | >> ((Smalltalk at: #ConfigurationOfPackage) project version: | '1.0') | > | >> silently: true; "or outputToTranscript: true" | > | >> load. | > | >> | > | >> "Save as magma.image" | > | >> SmalltalkImage current saveAs: 'magma'. | > | >> SmalltalkImage current snapshot: true andQuit: true. | > | >> | > | >> | > | >> Where silently, if not specified is false, so that uses | progress | > | bar as | > | >> now. But when someone is scripting some image build, they | specify | > | it to | > | >> true so that the image just work "headless" in loading | packages. | > | >> | > | >> But Dale, I know that this particular change, even externally | is | > | simple, | > | >> is very intrusive changing calls to progress bar with calls to | log | > | to | > | >> transcript, so don't worry a lot for this. If someday is | > | implemented, it | > | >> will be good, if not, well, nothing is lost. The code works | > | correctly | > | >> and as good as it can be with the current behavior. Besides, | maybe | > | this | > | >> feature isn't really needed, I *think* that it will be useful | for | > | >> continuous integration and automatic builds of pharo images | where | > | the | > | >> complete log of the image building can be extracted to a file | and | > | shown | > | >> in the interface of the image building software (like mason). | But | > | it is | > | >> just what I think. Lukas or the people building the | infrastructure | > | will | > | >> have better opinions than mine. | > | >> | > | >> -- | > | >> Miguel Cobá | > | >> http://miguel.leugim.com.mx | > | >> | > | >> | > | > | > | | > | To unsubscribe from this group, send email to | > | metacello+unsubscribegooglegroups.com or reply to this email with | the | > | words "REMOVE ME" as the subject. | > | > To unsubscribe from this group, send email to metacello+ | > unsubscribegooglegroups.com or reply to this email with the words | "REMOVE | > ME" as the subject. | > | | To unsubscribe from this group, send email to | metacello+unsubscribegooglegroups.com or reply to this email with the | words "REMOVE ME" as the subject. To unsubscribe from this group, send email to metacello+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject. |
«
Return to Metacello
|
1 view|%1 views
| Free forum by Nabble | Edit this page |