Quantcast

[Pharo-dev] Metacello doubt

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Pharo-dev] Metacello doubt

Guido Chari
I have a question since i'm trying to create some jenkins job for the first time. Sorry if this was already discussed...

I have a dependency with for example NativeBoost. And i want NativeBoost in its bleedingEdge version. If I "loadBleedingEdge" NativeBoost is on its last version on every package but not its own dependencies as for example AsmJit. Is this the right behavior? How can i express to have not only my dependency but also the dependencies of my dependencies in its bleedingEdge version?




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Pharo-dev] Metacello doubt

Damien Cassou
On Wed, Jun 26, 2013 at 4:27 PM, Guido Chari <[hidden email]> wrote:
> I have a dependency with for example NativeBoost. And i want NativeBoost in
> its bleedingEdge version. If I "loadBleedingEdge" NativeBoost is on its last
> version on every package but not its own dependencies as for example AsmJit.
> Is this the right behavior? How can i express to have not only my dependency
> but also the dependencies of my dependencies in its bleedingEdge version?


you can't I guess. Each package maintainer decides what is best for
the dependencies. If you want to override this, I still guess you have
to make your package depend on all the dependencies of all your
dependencies (recursively).

--
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm."
Winston Churchill

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Pharo-dev] Metacello doubt

Dale Henrichs-3
In reply to this post by Guido Chari
Guido,

If the maintainer of a configuration would like to support bleeding edge loads that propagate through the dependent projects then they should specify which baseline version to use for each dependent project. For Native Boost the entry for AsmJit in the #baseline13: method could be changed to:

        project: 'AsmJit'
          with: [
              spec
                className: 'ConfigurationOfAsmJit';
"==>"        versionString: #bleedingEdge;
                repository: 'http://www.smalltalkhub.com/mc/Pharo/AsmJit/main' ];

Then the bleedingEdge load would be propagated through to the dependents ... but then you'd want the AsmJit configuration modified as well:)

Dale


From: "Guido Chari" <[hidden email]>
To: [hidden email]
Sent: Wednesday, June 26, 2013 7:27:19 AM
Subject: [Pharo-dev] Metacello doubt

I have a question since i'm trying to create some jenkins job for the first time. Sorry if this was already discussed...

I have a dependency with for example NativeBoost. And i want NativeBoost in its bleedingEdge version. If I "loadBleedingEdge" NativeBoost is on its last version on every package but not its own dependencies as for example AsmJit. Is this the right behavior? How can i express to have not only my dependency but also the dependencies of my dependencies in its bleedingEdge version?





Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Pharo-dev] Metacello doubt

philippeback
While we are at it, is there any documentation for the MetacelloToolbox?

Couldn't find... Saw Sean's thing but nothing else.

Would be great!

TIA
Phil

---
Philippe Back
Dramatic Performance Improvements
Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027
Blog: http://philippeback.be | Twitter: @philippeback

High Octane SPRL
rue cour Boisacq 101 | 1301 Bierges | Belgium

Featured on the Software Process and Measurement Cast
Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller
 



On Wed, Jun 26, 2013 at 9:21 PM, Dale K. Henrichs <[hidden email]> wrote:
Guido,

If the maintainer of a configuration would like to support bleeding edge loads that propagate through the dependent projects then they should specify which baseline version to use for each dependent project. For Native Boost the entry for AsmJit in the #baseline13: method could be changed to:

        project: 'AsmJit'
          with: [
              spec
                className: 'ConfigurationOfAsmJit';
"==>"        versionString: #bleedingEdge;
                repository: 'http://www.smalltalkhub.com/mc/Pharo/AsmJit/main' ];

Then the bleedingEdge load would be propagated through to the dependents ... but then you'd want the AsmJit configuration modified as well:)

Dale


From: "Guido Chari" <[hidden email]>
To: [hidden email]
Sent: Wednesday, June 26, 2013 7:27:19 AM
Subject: [Pharo-dev] Metacello doubt

I have a question since i'm trying to create some jenkins job for the first time. Sorry if this was already discussed...

I have a dependency with for example NativeBoost. And i want NativeBoost in its bleedingEdge version. If I "loadBleedingEdge" NativeBoost is on its last version on every package but not its own dependencies as for example AsmJit. Is this the right behavior? How can i express to have not only my dependency but also the dependencies of my dependencies in its bleedingEdge version?






Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Pharo-dev] Metacello doubt

Guido Chari
In reply to this post by Dale Henrichs-3
I understood. Thanks for the answer Dale. The drawback in this case is to specify a particular dependency to AsmJit in my configuration. Also, perhaps is the right way since i realized i have a particular dependency on it.

But this discussion makes me thing a little and so i have a new question.

Form what I (mis) undestand from Metacello, when asking for a bleedingEdge version it loads only the baseline that specifies packages and then last version of every package specified there. 

As in the projects referenced on the baseline there is no need for specifying a version, and that's the case of nativeBoost configuration, wouldn't it be interesting to have some behavior (i mean i new method for loading like loadDeepSymbolic:) that not only load the symbolicVersion of the package asked, but also propagate that symbolicVersion (bleedingEdge in this case) to all the dependencies that don't specify a concrete version?

Guido.


2013/6/26 Dale K. Henrichs <[hidden email]>
Guido,

If the maintainer of a configuration would like to support bleeding edge loads that propagate through the dependent projects then they should specify which baseline version to use for each dependent project. For Native Boost the entry for AsmJit in the #baseline13: method could be changed to:

        project: 'AsmJit'
          with: [
              spec
                className: 'ConfigurationOfAsmJit';
"==>"        versionString: #bleedingEdge;
                repository: 'http://www.smalltalkhub.com/mc/Pharo/AsmJit/main' ];

Then the bleedingEdge load would be propagated through to the dependents ... but then you'd want the AsmJit configuration modified as well:)

Dale


From: "Guido Chari" <[hidden email]>
To: [hidden email]
Sent: Wednesday, June 26, 2013 7:27:19 AM
Subject: [Pharo-dev] Metacello doubt


I have a question since i'm trying to create some jenkins job for the first time. Sorry if this was already discussed...

I have a dependency with for example NativeBoost. And i want NativeBoost in its bleedingEdge version. If I "loadBleedingEdge" NativeBoost is on its last version on every package but not its own dependencies as for example AsmJit. Is this the right behavior? How can i express to have not only my dependency but also the dependencies of my dependencies in its bleedingEdge version?






Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Pharo-dev] Metacello doubt

Dale Henrichs-3
In reply to this post by philippeback
Phil,

Check out the System Help ... the API is documented under Metacello>>MetacelloToolBox ... under PrfStef>>Browse tutorials>>Inside Metacello Toolbox there are 5-6 lessons there are other Metacello tutorials there as well ...

Dale


From: [hidden email]
To: "Pharo Development List" <[hidden email]>
Sent: Wednesday, June 26, 2013 1:45:36 PM
Subject: Re: [Pharo-dev] Metacello doubt

While we are at it, is there any documentation for the MetacelloToolbox?

Couldn't find... Saw Sean's thing but nothing else.

Would be great!

TIA
Phil

---
Philippe Back
Dramatic Performance Improvements
Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027
Blog: http://philippeback.be | Twitter: @philippeback

High Octane SPRL
rue cour Boisacq 101 | 1301 Bierges | Belgium

Featured on the Software Process and Measurement Cast
Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller
 



On Wed, Jun 26, 2013 at 9:21 PM, Dale K. Henrichs <[hidden email]> wrote:
Guido,

If the maintainer of a configuration would like to support bleeding edge loads that propagate through the dependent projects then they should specify which baseline version to use for each dependent project. For Native Boost the entry for AsmJit in the #baseline13: method could be changed to:

        project: 'AsmJit'
          with: [
              spec
                className: 'ConfigurationOfAsmJit';
"==>"        versionString: #bleedingEdge;
                repository: 'http://www.smalltalkhub.com/mc/Pharo/AsmJit/main' ];

Then the bleedingEdge load would be propagated through to the dependents ... but then you'd want the AsmJit configuration modified as well:)

Dale


From: "Guido Chari" <[hidden email]>
To: [hidden email]
Sent: Wednesday, June 26, 2013 7:27:19 AM
Subject: [Pharo-dev] Metacello doubt

I have a question since i'm trying to create some jenkins job for the first time. Sorry if this was already discussed...

I have a dependency with for example NativeBoost. And i want NativeBoost in its bleedingEdge version. If I "loadBleedingEdge" NativeBoost is on its last version on every package but not its own dependencies as for example AsmJit. Is this the right behavior? How can i express to have not only my dependency but also the dependencies of my dependencies in its bleedingEdge version?







Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Pharo-dev] Metacello doubt

Dale Henrichs-3
In reply to this post by Guido Chari



From: "Guido Chari" <[hidden email]>
To: "Pharo Development List" <[hidden email]>
Sent: Wednesday, June 26, 2013 2:49:09 PM
Subject: Re: [Pharo-dev] Metacello doubt

I understood. Thanks for the answer Dale. The drawback in this case is to specify a particular dependency to AsmJit in my configuration. Also, perhaps is the right way since i realized i have a particular dependency on it.

But this discussion makes me thing a little and so i have a new question.

Form what I (mis) undestand from Metacello, when asking for a bleedingEdge version it loads only the baseline that specifies packages and then last version of every package specified there. 

As in the projects referenced on the baseline there is no need for specifying a version, and that's the case of nativeBoost configuration, wouldn't it be interesting to have some behavior (i mean i new method for loading like loadDeepSymbolic:) that not only load the symbolicVersion of the package asked, but also propagate that symbolicVersion (bleedingEdge in this case) to all the dependencies that don't specify a concrete version?

Guido.

Guido,

With the Metacello Scripting API[1] I've taken a slightly different tack, but I think that it gets you to the same place.

I am a big fan of deterministic loads, but I know that from a practical point of view developers need to have a certain amount of control over exactly what gets loaded into their DEVELOPMENT environments and they need to be able to exert this control without having to resort to editing configurations to match their specific requirements.

I have accomplished this by arranging for a Notification to be signalled whenever a project is referenced during a load. The developer can use one or more of the  onUpgrade:, onDowngrade: and onConflict: clauses in their load scripts to exert fine control over what happens on a project by project basis ...

For your specific use case, I would think that you would want to use the `lock` command[2] and specify that you want to `lock` the projects (NativeBoost and AsmJit) to the #bleedingEdge version. I don't recall if I've got test cases for symbolic versions, but if you are seriously interested in taking the Scripting API for a spin, I'd be willing to write some additional tests using the #bleedingEdge symbolic version (if not already covered) and validate this use case...

I am entering a phase where I will be doing some work on getting FileTree and Metacello up to snuff for Pharo3.0 so this would be a good time for me to add some test cases in anticipation of having some interested users ...

I haven't released the Scripting API, because I need to have real users with real use cases take the API for a spin and validate the API. The Scripting API can be loaded into any version of Pharo/Squeak/GemStone and I think the Scripting API is (or will be) available in Pharo3.0.

I'm looking forward to getting feedback as to how the API stands up to real use ...

So let me know if you are interested in being another Scripting API guinea pig:)

Dale

[1] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUserGuide.md
[2] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUserGuide.md#locking
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Pharo-dev] Metacello doubt

Igor Stasenko
Just adding some comments:
 - i avoid using loading bleeding edge
because it has problems which only humans can solve:
  - if there are two different branches, not yet merged it may load
not one that you want
  - even if dependencies is ok, it doesn't means that if you load two
latest versions of two packages,
they will work

so, what i do, is loading a known working config, and then go to
monticello and manually picking and loading updated packages.

On 27 June 2013 01:27, Dale K. Henrichs
<[hidden email]> wrote:

>
>
> ________________________________
>
> From: "Guido Chari" <[hidden email]>
>
> To: "Pharo Development List" <[hidden email]>
> Sent: Wednesday, June 26, 2013 2:49:09 PM
> Subject: Re: [Pharo-dev] Metacello doubt
>
> I understood. Thanks for the answer Dale. The drawback in this case is to
> specify a particular dependency to AsmJit in my configuration. Also, perhaps
> is the right way since i realized i have a particular dependency on it.
>
> But this discussion makes me thing a little and so i have a new question.
>
> Form what I (mis) undestand from Metacello, when asking for a bleedingEdge
> version it loads only the baseline that specifies packages and then last
> version of every package specified there.
>
> As in the projects referenced on the baseline there is no need for
> specifying a version, and that's the case of nativeBoost configuration,
> wouldn't it be interesting to have some behavior (i mean i new method for
> loading like loadDeepSymbolic:) that not only load the symbolicVersion of
> the package asked, but also propagate that symbolicVersion (bleedingEdge in
> this case) to all the dependencies that don't specify a concrete version?
>
> Guido.
>
> Guido,
>
> With the Metacello Scripting API[1] I've taken a slightly different tack,
> but I think that it gets you to the same place.
>
> I am a big fan of deterministic loads, but I know that from a practical
> point of view developers need to have a certain amount of control over
> exactly what gets loaded into their DEVELOPMENT environments and they need
> to be able to exert this control without having to resort to editing
> configurations to match their specific requirements.
>
> I have accomplished this by arranging for a Notification to be signalled
> whenever a project is referenced during a load. The developer can use one or
> more of the  onUpgrade:, onDowngrade: and onConflict: clauses in their load
> scripts to exert fine control over what happens on a project by project
> basis ...
>
> For your specific use case, I would think that you would want to use the
> `lock` command[2] and specify that you want to `lock` the projects
> (NativeBoost and AsmJit) to the #bleedingEdge version. I don't recall if
> I've got test cases for symbolic versions, but if you are seriously
> interested in taking the Scripting API for a spin, I'd be willing to write
> some additional tests using the #bleedingEdge symbolic version (if not
> already covered) and validate this use case...
>
> I am entering a phase where I will be doing some work on getting FileTree
> and Metacello up to snuff for Pharo3.0 so this would be a good time for me
> to add some test cases in anticipation of having some interested users ...
>
> I haven't released the Scripting API, because I need to have real users with
> real use cases take the API for a spin and validate the API. The Scripting
> API can be loaded into any version of Pharo/Squeak/GemStone and I think the
> Scripting API is (or will be) available in Pharo3.0.
>
> I'm looking forward to getting feedback as to how the API stands up to real
> use ...
>
> So let me know if you are interested in being another Scripting API guinea
> pig:)
>
> Dale
>
> [1]
> https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUserGuide.md
> [2]
> https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUserGuide.md#locking



--
Best regards,
Igor Stasenko.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Pharo-dev] Metacello doubt

Dale Henrichs-3

----- Original Message -----
| From: "Igor Stasenko" <[hidden email]>
| To: "Pharo Development List" <[hidden email]>
| Sent: Thursday, June 27, 2013 4:26:14 AM
| Subject: Re: [Pharo-dev] Metacello doubt
|
| Just adding some comments:
|  - i avoid using loading bleeding edge
| because it has problems which only humans can solve:
|   - if there are two different branches, not yet merged it may load
| not one that you want
|   - even if dependencies is ok, it doesn't means that if you load two
| latest versions of two packages,
| they will work
|
| so, what i do, is loading a known working config, and then go to
| monticello and manually picking and loading updated packages.
|

But once the human has solved the problem, the solution should be encoded in a script that can be used by others to solve the same problem ...

It's the manual bits that I'm trying to address with the Scripting API ... if you know you want to deviate from the standard load directives, you should be able to construct a load expression that allows you to specify your deviations so you can do your next build without requiring manual intervention...

Dale

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Pharo-dev] Metacello doubt

Guido Chari
In reply to this post by Igor Stasenko
The problem is that my use case is a jenkins job. I want to have something that is the more automatically as possible.

On the other hand, i like tools that support the user to be as free as possible. More if we are taking about tools for developers. In this case, i guess its not bad to have metacello allowing for developers to automatically load last version of every package. I think i have a clear use case here where i have a need that could be perhaps tackled with Metacello and is hard to tackle other way.


2013/6/27 Igor Stasenko <[hidden email]>
Just adding some comments:
 - i avoid using loading bleeding edge
because it has problems which only humans can solve:
  - if there are two different branches, not yet merged it may load
not one that you want
  - even if dependencies is ok, it doesn't means that if you load two
latest versions of two packages,
they will work

so, what i do, is loading a known working config, and then go to
monticello and manually picking and loading updated packages.

On 27 June 2013 01:27, Dale K. Henrichs
<[hidden email]> wrote:
>
>
> ________________________________
>
> From: "Guido Chari" <[hidden email]>
>
> To: "Pharo Development List" <[hidden email]>
> Sent: Wednesday, June 26, 2013 2:49:09 PM
> Subject: Re: [Pharo-dev] Metacello doubt
>
> I understood. Thanks for the answer Dale. The drawback in this case is to
> specify a particular dependency to AsmJit in my configuration. Also, perhaps
> is the right way since i realized i have a particular dependency on it.
>
> But this discussion makes me thing a little and so i have a new question.
>
> Form what I (mis) undestand from Metacello, when asking for a bleedingEdge
> version it loads only the baseline that specifies packages and then last
> version of every package specified there.
>
> As in the projects referenced on the baseline there is no need for
> specifying a version, and that's the case of nativeBoost configuration,
> wouldn't it be interesting to have some behavior (i mean i new method for
> loading like loadDeepSymbolic:) that not only load the symbolicVersion of
> the package asked, but also propagate that symbolicVersion (bleedingEdge in
> this case) to all the dependencies that don't specify a concrete version?
>
> Guido.
>
> Guido,
>
> With the Metacello Scripting API[1] I've taken a slightly different tack,
> but I think that it gets you to the same place.
>
> I am a big fan of deterministic loads, but I know that from a practical
> point of view developers need to have a certain amount of control over
> exactly what gets loaded into their DEVELOPMENT environments and they need
> to be able to exert this control without having to resort to editing
> configurations to match their specific requirements.
>
> I have accomplished this by arranging for a Notification to be signalled
> whenever a project is referenced during a load. The developer can use one or
> more of the  onUpgrade:, onDowngrade: and onConflict: clauses in their load
> scripts to exert fine control over what happens on a project by project
> basis ...
>
> For your specific use case, I would think that you would want to use the
> `lock` command[2] and specify that you want to `lock` the projects
> (NativeBoost and AsmJit) to the #bleedingEdge version. I don't recall if
> I've got test cases for symbolic versions, but if you are seriously
> interested in taking the Scripting API for a spin, I'd be willing to write
> some additional tests using the #bleedingEdge symbolic version (if not
> already covered) and validate this use case...
>
> I am entering a phase where I will be doing some work on getting FileTree
> and Metacello up to snuff for Pharo3.0 so this would be a good time for me
> to add some test cases in anticipation of having some interested users ...
>
> I haven't released the Scripting API, because I need to have real users with
> real use cases take the API for a spin and validate the API. The Scripting
> API can be loaded into any version of Pharo/Squeak/GemStone and I think the
> Scripting API is (or will be) available in Pharo3.0.
>
> I'm looking forward to getting feedback as to how the API stands up to real
> use ...
>
> So let me know if you are interested in being another Scripting API guinea
> pig:)
>
> Dale
>
> [1]
> https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUserGuide.md
> [2]
> https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUserGuide.md#locking



--
Best regards,
Igor Stasenko.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Pharo-dev] Metacello doubt

Guido Chari
In reply to this post by Dale Henrichs-3
I'm in.


2013/6/26 Dale K. Henrichs <[hidden email]>



From: "Guido Chari" <[hidden email]>
To: "Pharo Development List" <[hidden email]>
Sent: Wednesday, June 26, 2013 2:49:09 PM

Subject: Re: [Pharo-dev] Metacello doubt

I understood. Thanks for the answer Dale. The drawback in this case is to specify a particular dependency to AsmJit in my configuration. Also, perhaps is the right way since i realized i have a particular dependency on it.

But this discussion makes me thing a little and so i have a new question.

Form what I (mis) undestand from Metacello, when asking for a bleedingEdge version it loads only the baseline that specifies packages and then last version of every package specified there. 

As in the projects referenced on the baseline there is no need for specifying a version, and that's the case of nativeBoost configuration, wouldn't it be interesting to have some behavior (i mean i new method for loading like loadDeepSymbolic:) that not only load the symbolicVersion of the package asked, but also propagate that symbolicVersion (bleedingEdge in this case) to all the dependencies that don't specify a concrete version?

Guido.

Guido,

With the Metacello Scripting API[1] I've taken a slightly different tack, but I think that it gets you to the same place.

I am a big fan of deterministic loads, but I know that from a practical point of view developers need to have a certain amount of control over exactly what gets loaded into their DEVELOPMENT environments and they need to be able to exert this control without having to resort to editing configurations to match their specific requirements.

I have accomplished this by arranging for a Notification to be signalled whenever a project is referenced during a load. The developer can use one or more of the  onUpgrade:, onDowngrade: and onConflict: clauses in their load scripts to exert fine control over what happens on a project by project basis ...

For your specific use case, I would think that you would want to use the `lock` command[2] and specify that you want to `lock` the projects (NativeBoost and AsmJit) to the #bleedingEdge version. I don't recall if I've got test cases for symbolic versions, but if you are seriously interested in taking the Scripting API for a spin, I'd be willing to write some additional tests using the #bleedingEdge symbolic version (if not already covered) and validate this use case...

I am entering a phase where I will be doing some work on getting FileTree and Metacello up to snuff for Pharo3.0 so this would be a good time for me to add some test cases in anticipation of having some interested users ...

I haven't released the Scripting API, because I need to have real users with real use cases take the API for a spin and validate the API. The Scripting API can be loaded into any version of Pharo/Squeak/GemStone and I think the Scripting API is (or will be) available in Pharo3.0.

I'm looking forward to getting feedback as to how the API stands up to real use ...

So let me know if you are interested in being another Scripting API guinea pig:)

Dale

[1] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUserGuide.md
[2] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUserGuide.md#locking

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Pharo-dev] Metacello doubt

Dale Henrichs-3
Allright ... I'll add a test case covering #bleedingEdge loads (perhaps not today...) and let you know if it's already functional or not ... if not I'll plan on getting it supported ...

Dale


From: "Guido Chari" <[hidden email]>
To: "Pharo Development List" <[hidden email]>
Sent: Thursday, June 27, 2013 10:23:33 AM
Subject: Re: [Pharo-dev] Metacello doubt

I'm in.


2013/6/26 Dale K. Henrichs <[hidden email]>



From: "Guido Chari" <[hidden email]>
To: "Pharo Development List" <[hidden email]>
Sent: Wednesday, June 26, 2013 2:49:09 PM

Subject: Re: [Pharo-dev] Metacello doubt

I understood. Thanks for the answer Dale. The drawback in this case is to specify a particular dependency to AsmJit in my configuration. Also, perhaps is the right way since i realized i have a particular dependency on it.

But this discussion makes me thing a little and so i have a new question.

Form what I (mis) undestand from Metacello, when asking for a bleedingEdge version it loads only the baseline that specifies packages and then last version of every package specified there. 

As in the projects referenced on the baseline there is no need for specifying a version, and that's the case of nativeBoost configuration, wouldn't it be interesting to have some behavior (i mean i new method for loading like loadDeepSymbolic:) that not only load the symbolicVersion of the package asked, but also propagate that symbolicVersion (bleedingEdge in this case) to all the dependencies that don't specify a concrete version?

Guido.

Guido,

With the Metacello Scripting API[1] I've taken a slightly different tack, but I think that it gets you to the same place.

I am a big fan of deterministic loads, but I know that from a practical point of view developers need to have a certain amount of control over exactly what gets loaded into their DEVELOPMENT environments and they need to be able to exert this control without having to resort to editing configurations to match their specific requirements.

I have accomplished this by arranging for a Notification to be signalled whenever a project is referenced during a load. The developer can use one or more of the  onUpgrade:, onDowngrade: and onConflict: clauses in their load scripts to exert fine control over what happens on a project by project basis ...

For your specific use case, I would think that you would want to use the `lock` command[2] and specify that you want to `lock` the projects (NativeBoost and AsmJit) to the #bleedingEdge version. I don't recall if I've got test cases for symbolic versions, but if you are seriously interested in taking the Scripting API for a spin, I'd be willing to write some additional tests using the #bleedingEdge symbolic version (if not already covered) and validate this use case...

I am entering a phase where I will be doing some work on getting FileTree and Metacello up to snuff for Pharo3.0 so this would be a good time for me to add some test cases in anticipation of having some interested users ...

I haven't released the Scripting API, because I need to have real users with real use cases take the API for a spin and validate the API. The Scripting API can be loaded into any version of Pharo/Squeak/GemStone and I think the Scripting API is (or will be) available in Pharo3.0.

I'm looking forward to getting feedback as to how the API stands up to real use ...

So let me know if you are interested in being another Scripting API guinea pig:)

Dale

[1] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUserGuide.md
[2] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUserGuide.md#locking


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Pharo-dev] Metacello doubt

Igor Stasenko
In reply to this post by Dale Henrichs-3
On 27 June 2013 15:43, Dale K. Henrichs
<[hidden email]> wrote:

>
> ----- Original Message -----
> | From: "Igor Stasenko" <[hidden email]>
> | To: "Pharo Development List" <[hidden email]>
> | Sent: Thursday, June 27, 2013 4:26:14 AM
> | Subject: Re: [Pharo-dev] Metacello doubt
> |
> | Just adding some comments:
> |  - i avoid using loading bleeding edge
> | because it has problems which only humans can solve:
> |   - if there are two different branches, not yet merged it may load
> | not one that you want
> |   - even if dependencies is ok, it doesn't means that if you load two
> | latest versions of two packages,
> | they will work
> |
> | so, what i do, is loading a known working config, and then go to
> | monticello and manually picking and loading updated packages.
> |
>
> But once the human has solved the problem, the solution should be encoded in a script that can be used by others to solve the same problem ...
>
> It's the manual bits that I'm trying to address with the Scripting API ... if you know you want to deviate from the standard load directives, you should be able to construct a load expression that allows you to specify your deviations so you can do your next build without requiring manual intervention...
>

Well, the "bleeding edge" called this way exactly for reasons that it
is unsafe/unpredictable
and hardly formalizeable.
I don't see what can be done there: trying to predict a developer's
next move is not something you can do
with software :)
As i said, if there at least two persons working on project , each in
his own branch, a term "bleeding edge" will mean
something different for each of them. Only when one person takes an
effort to merge and update config, you'll have new development
version, but before that, if they will commit often without merging,
the bleeding edge will jump between one branch and another, and i do
not see how that can be useful to anyone.

> Dale


--
Best regards,
Igor Stasenko.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Pharo-dev] Metacello doubt

Dale Henrichs-3


----- Original Message -----
| From: "Igor Stasenko" <[hidden email]>
| To: "Pharo Development List" <[hidden email]>
| Sent: Thursday, June 27, 2013 11:19:03 AM
| Subject: Re: [Pharo-dev] Metacello doubt
|
| On 27 June 2013 15:43, Dale K. Henrichs
| <[hidden email]> wrote:
| >
| > ----- Original Message -----
| > | From: "Igor Stasenko" <[hidden email]>
| > | To: "Pharo Development List" <[hidden email]>
| > | Sent: Thursday, June 27, 2013 4:26:14 AM
| > | Subject: Re: [Pharo-dev] Metacello doubt
| > |
| > | Just adding some comments:
| > |  - i avoid using loading bleeding edge
| > | because it has problems which only humans can solve:
| > |   - if there are two different branches, not yet merged it may
| > |   load
| > | not one that you want
| > |   - even if dependencies is ok, it doesn't means that if you load
| > |   two
| > | latest versions of two packages,
| > | they will work
| > |
| > | so, what i do, is loading a known working config, and then go to
| > | monticello and manually picking and loading updated packages.
| > |
| >
| > But once the human has solved the problem, the solution should be
| > encoded in a script that can be used by others to solve the same
| > problem ...
| >
| > It's the manual bits that I'm trying to address with the Scripting
| > API ... if you know you want to deviate from the standard load
| > directives, you should be able to construct a load expression that
| > allows you to specify your deviations so you can do your next
| > build without requiring manual intervention...
| >
|
| Well, the "bleeding edge" called this way exactly for reasons that it
| is unsafe/unpredictable
| and hardly formalizeable.

You are putting too much emphasis of the "what" at the expense of "why"...

In Metacello #bleedingEdge is a version like any other version. The statement "if you know you want to deviate from the standard load directives" applies to whether you want to "deviate" by loading the #bleedingEdge version of a project or to "deviate" by loading the #stable version of a project, the mechanism in the Scripting API is exactly the same.


| I don't see what can be done there: trying to predict a developer's
| next move is not something you can do
| with software :)

The point is not to predict the developers needs ... the point is to allow the developer to express how he wants to deviate, without forcing him into manual operations... and this is something you can do in software:)

| As i said, if there at least two persons working on project , each in
| his own branch, a term "bleeding edge" will mean
| something different for each of them. Only when one person takes an
| effort to merge and update config, you'll have new development
| version, but before that, if they will commit often without merging,
| the bleeding edge will jump between one branch and another, and i do
| not see how that can be useful to anyone.

Your comments are specific to the #bleedingEdge version ... as I said earlier, the mechanism that I have described does not apply to only the #bleedingEdge case, but to all versions ...

When I said that I would "add test cases for the #bleedingEdge use case," I was actually thinking that I wasn't sure that symbolic versions would work as _I_ expected, since I don't recall adding any tests involving _symbolic versions ...  

I generally don't want to add features to Metacello that are specifically tied to support a narrow range of  use cases, unless I can generalize the feature to cover a wide range. I also don't want to forbid certain use cases just because I don't think they are useful.

The Scripting API was invented to give developers explicit control over what gets loaded by Metacello, because the vanilla load of a project and it's dependents is not always what a developers needs ...

Dale

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Pharo-dev] Metacello doubt

philippeback
In reply to this post by Dale Henrichs-3
I loaded ConfigurationOfProfStef but there is no MetacelloToolbox documentation in there.

What do I miss?

Phil

---
Philippe Back
Dramatic Performance Improvements
Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027
Blog: http://philippeback.be | Twitter: @philippeback

High Octane SPRL
rue cour Boisacq 101 | 1301 Bierges | Belgium

Featured on the Software Process and Measurement Cast
Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller
 



On Wed, Jun 26, 2013 at 11:56 PM, Dale K. Henrichs <[hidden email]> wrote:
Phil,

Check out the System Help ... the API is documented under Metacello>>MetacelloToolBox ... under PrfStef>>Browse tutorials>>Inside Metacello Toolbox there are 5-6 lessons there are other Metacello tutorials there as well ...

Dale


From: [hidden email]
To: "Pharo Development List" <[hidden email]>
Sent: Wednesday, June 26, 2013 1:45:36 PM
Subject: Re: [Pharo-dev] Metacello doubt

While we are at it, is there any documentation for the MetacelloToolbox?

Couldn't find... Saw Sean's thing but nothing else.

Would be great!

TIA
Phil

---
Philippe Back
Dramatic Performance Improvements
Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027
Blog: http://philippeback.be | Twitter: @philippeback

High Octane SPRL
rue cour Boisacq 101 | 1301 Bierges | Belgium

Featured on the Software Process and Measurement Cast
Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller
 



On Wed, Jun 26, 2013 at 9:21 PM, Dale K. Henrichs <[hidden email]> wrote:
Guido,

If the maintainer of a configuration would like to support bleeding edge loads that propagate through the dependent projects then they should specify which baseline version to use for each dependent project. For Native Boost the entry for AsmJit in the #baseline13: method could be changed to:

        project: 'AsmJit'
          with: [
              spec
                className: 'ConfigurationOfAsmJit';
"==>"        versionString: #bleedingEdge;
                repository: 'http://www.smalltalkhub.com/mc/Pharo/AsmJit/main' ];

Then the bleedingEdge load would be propagated through to the dependents ... but then you'd want the AsmJit configuration modified as well:)

Dale


From: "Guido Chari" <[hidden email]>
To: [hidden email]
Sent: Wednesday, June 26, 2013 7:27:19 AM
Subject: [Pharo-dev] Metacello doubt

I have a question since i'm trying to create some jenkins job for the first time. Sorry if this was already discussed...

I have a dependency with for example NativeBoost. And i want NativeBoost in its bleedingEdge version. If I "loadBleedingEdge" NativeBoost is on its last version on every package but not its own dependencies as for example AsmJit. Is this the right behavior? How can i express to have not only my dependency but also the dependencies of my dependencies in its bleedingEdge version?








Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Pharo-dev] Metacello doubt

Dale Henrichs-3
Ah, at one point in time the tutorial was loaded by default ... sorry about that. to get the Metacello tutorial execute:

  ConfigurationOfMetacello project currentVersion load: 'Tutorial'

Then you can find the Metacello documentation under the Help menu in the Help Browser ...

Dale

From: [hidden email]
To: "Pharo Development List" <[hidden email]>
Sent: Friday, June 28, 2013 6:48:59 AM
Subject: Re: [Pharo-dev] Metacello doubt

I loaded ConfigurationOfProfStef but there is no MetacelloToolbox documentation in there.

What do I miss?

Phil

---
Philippe Back
Dramatic Performance Improvements
Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027
Blog: http://philippeback.be | Twitter: @philippeback

High Octane SPRL
rue cour Boisacq 101 | 1301 Bierges | Belgium

Featured on the Software Process and Measurement Cast
Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller
 



On Wed, Jun 26, 2013 at 11:56 PM, Dale K. Henrichs <[hidden email]> wrote:
Phil,

Check out the System Help ... the API is documented under Metacello>>MetacelloToolBox ... under PrfStef>>Browse tutorials>>Inside Metacello Toolbox there are 5-6 lessons there are other Metacello tutorials there as well ...

Dale


From: [hidden email]
To: "Pharo Development List" <[hidden email]>
Sent: Wednesday, June 26, 2013 1:45:36 PM
Subject: Re: [Pharo-dev] Metacello doubt

While we are at it, is there any documentation for the MetacelloToolbox?

Couldn't find... Saw Sean's thing but nothing else.

Would be great!

TIA
Phil

---
Philippe Back
Dramatic Performance Improvements
Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027
Blog: http://philippeback.be | Twitter: @philippeback

High Octane SPRL
rue cour Boisacq 101 | 1301 Bierges | Belgium

Featured on the Software Process and Measurement Cast
Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller
 



On Wed, Jun 26, 2013 at 9:21 PM, Dale K. Henrichs <[hidden email]> wrote:
Guido,

If the maintainer of a configuration would like to support bleeding edge loads that propagate through the dependent projects then they should specify which baseline version to use for each dependent project. For Native Boost the entry for AsmJit in the #baseline13: method could be changed to:

        project: 'AsmJit'
          with: [
              spec
                className: 'ConfigurationOfAsmJit';
"==>"        versionString: #bleedingEdge;
                repository: 'http://www.smalltalkhub.com/mc/Pharo/AsmJit/main' ];

Then the bleedingEdge load would be propagated through to the dependents ... but then you'd want the AsmJit configuration modified as well:)

Dale


From: "Guido Chari" <[hidden email]>
To: [hidden email]
Sent: Wednesday, June 26, 2013 7:27:19 AM
Subject: [Pharo-dev] Metacello doubt

I have a question since i'm trying to create some jenkins job for the first time. Sorry if this was already discussed...

I have a dependency with for example NativeBoost. And i want NativeBoost in its bleedingEdge version. If I "loadBleedingEdge" NativeBoost is on its last version on every package but not its own dependencies as for example AsmJit. Is this the right behavior? How can i express to have not only my dependency but also the dependencies of my dependencies in its bleedingEdge version?









Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Pharo-dev] Metacello doubt

philippeback
Much better indeed!

Now, it would be useful to have the same in HTML format on the web as this is really not super easy to find. (I am often looking that what is on pages like https://code.google.com/p/metacello/wiki/CreateMetacelloConfiguration)

Thanks!
Phil

---
Philippe Back
Dramatic Performance Improvements
Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027
Blog: http://philippeback.be | Twitter: @philippeback

High Octane SPRL
rue cour Boisacq 101 | 1301 Bierges | Belgium

Featured on the Software Process and Measurement Cast
Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller
 



On Fri, Jun 28, 2013 at 3:55 PM, Dale K. Henrichs <[hidden email]> wrote:
Ah, at one point in time the tutorial was loaded by default ... sorry about that. to get the Metacello tutorial execute:

  ConfigurationOfMetacello project currentVersion load: 'Tutorial'

Then you can find the Metacello documentation under the Help menu in the Help Browser ...

Dale

From: [hidden email]
To: "Pharo Development List" <[hidden email]>
Sent: Friday, June 28, 2013 6:48:59 AM
Subject: Re: [Pharo-dev] Metacello doubt

I loaded ConfigurationOfProfStef but there is no MetacelloToolbox documentation in there.

What do I miss?

Phil

---
Philippe Back
Dramatic Performance Improvements
Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027
Blog: http://philippeback.be | Twitter: @philippeback

High Octane SPRL
rue cour Boisacq 101 | 1301 Bierges | Belgium

Featured on the Software Process and Measurement Cast
Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller
 



On Wed, Jun 26, 2013 at 11:56 PM, Dale K. Henrichs <[hidden email]> wrote:
Phil,

Check out the System Help ... the API is documented under Metacello>>MetacelloToolBox ... under PrfStef>>Browse tutorials>>Inside Metacello Toolbox there are 5-6 lessons there are other Metacello tutorials there as well ...

Dale


From: [hidden email]
To: "Pharo Development List" <[hidden email]>
Sent: Wednesday, June 26, 2013 1:45:36 PM
Subject: Re: [Pharo-dev] Metacello doubt

While we are at it, is there any documentation for the MetacelloToolbox?

Couldn't find... Saw Sean's thing but nothing else.

Would be great!

TIA
Phil

---
Philippe Back
Dramatic Performance Improvements
Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027
Blog: http://philippeback.be | Twitter: @philippeback

High Octane SPRL
rue cour Boisacq 101 | 1301 Bierges | Belgium

Featured on the Software Process and Measurement Cast
Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller
 



On Wed, Jun 26, 2013 at 9:21 PM, Dale K. Henrichs <[hidden email]> wrote:
Guido,

If the maintainer of a configuration would like to support bleeding edge loads that propagate through the dependent projects then they should specify which baseline version to use for each dependent project. For Native Boost the entry for AsmJit in the #baseline13: method could be changed to:

        project: 'AsmJit'
          with: [
              spec
                className: 'ConfigurationOfAsmJit';
"==>"        versionString: #bleedingEdge;
                repository: 'http://www.smalltalkhub.com/mc/Pharo/AsmJit/main' ];

Then the bleedingEdge load would be propagated through to the dependents ... but then you'd want the AsmJit configuration modified as well:)

Dale


From: "Guido Chari" <[hidden email]>
To: [hidden email]
Sent: Wednesday, June 26, 2013 7:27:19 AM
Subject: [Pharo-dev] Metacello doubt

I have a question since i'm trying to create some jenkins job for the first time. Sorry if this was already discussed...

I have a dependency with for example NativeBoost. And i want NativeBoost in its bleedingEdge version. If I "loadBleedingEdge" NativeBoost is on its last version on every package but not its own dependencies as for example AsmJit. Is this the right behavior? How can i express to have not only my dependency but also the dependencies of my dependencies in its bleedingEdge version?










Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Pharo-dev] Metacello doubt

Dale Henrichs-3
In reply to this post by Guido Chari
Guido,

I created a test case and it turns out that there _is_ a bug in the bypass lock logic[1] . I'm going to push out a new version of the Metacello Preview (1.0.0-beta.32.8) in the next day or so and the bugfix for Issue #174 will _not_ be included in that release ...

Dale

[1] https://github.com/dalehenrich/metacello-work/issues/174


From: "Guido Chari" <[hidden email]>
To: "Pharo Development List" <[hidden email]>
Sent: Thursday, June 27, 2013 10:23:33 AM
Subject: Re: [Pharo-dev] Metacello doubt

I'm in.


2013/6/26 Dale K. Henrichs <[hidden email]>



From: "Guido Chari" <[hidden email]>
To: "Pharo Development List" <[hidden email]>
Sent: Wednesday, June 26, 2013 2:49:09 PM

Subject: Re: [Pharo-dev] Metacello doubt

I understood. Thanks for the answer Dale. The drawback in this case is to specify a particular dependency to AsmJit in my configuration. Also, perhaps is the right way since i realized i have a particular dependency on it.

But this discussion makes me thing a little and so i have a new question.

Form what I (mis) undestand from Metacello, when asking for a bleedingEdge version it loads only the baseline that specifies packages and then last version of every package specified there. 

As in the projects referenced on the baseline there is no need for specifying a version, and that's the case of nativeBoost configuration, wouldn't it be interesting to have some behavior (i mean i new method for loading like loadDeepSymbolic:) that not only load the symbolicVersion of the package asked, but also propagate that symbolicVersion (bleedingEdge in this case) to all the dependencies that don't specify a concrete version?

Guido.

Guido,

With the Metacello Scripting API[1] I've taken a slightly different tack, but I think that it gets you to the same place.

I am a big fan of deterministic loads, but I know that from a practical point of view developers need to have a certain amount of control over exactly what gets loaded into their DEVELOPMENT environments and they need to be able to exert this control without having to resort to editing configurations to match their specific requirements.

I have accomplished this by arranging for a Notification to be signalled whenever a project is referenced during a load. The developer can use one or more of the  onUpgrade:, onDowngrade: and onConflict: clauses in their load scripts to exert fine control over what happens on a project by project basis ...

For your specific use case, I would think that you would want to use the `lock` command[2] and specify that you want to `lock` the projects (NativeBoost and AsmJit) to the #bleedingEdge version. I don't recall if I've got test cases for symbolic versions, but if you are seriously interested in taking the Scripting API for a spin, I'd be willing to write some additional tests using the #bleedingEdge symbolic version (if not already covered) and validate this use case...

I am entering a phase where I will be doing some work on getting FileTree and Metacello up to snuff for Pharo3.0 so this would be a good time for me to add some test cases in anticipation of having some interested users ...

I haven't released the Scripting API, because I need to have real users with real use cases take the API for a spin and validate the API. The Scripting API can be loaded into any version of Pharo/Squeak/GemStone and I think the Scripting API is (or will be) available in Pharo3.0.

I'm looking forward to getting feedback as to how the API stands up to real use ...

So let me know if you are interested in being another Scripting API guinea pig:)

Dale

[1] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUserGuide.md
[2] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUserGuide.md#locking


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Pharo-dev] Metacello doubt

Guido Chari
Ok, i will follow the issue on github. Thanks!


2013/7/1 Dale K. Henrichs <[hidden email]>
Guido,

I created a test case and it turns out that there _is_ a bug in the bypass lock logic[1] . I'm going to push out a new version of the Metacello Preview (1.0.0-beta.32.8) in the next day or so and the bugfix for Issue #174 will _not_ be included in that release ...

Dale

[1] https://github.com/dalehenrich/metacello-work/issues/174


From: "Guido Chari" <[hidden email]>
To: "Pharo Development List" <[hidden email]>
Sent: Thursday, June 27, 2013 10:23:33 AM
Subject: Re: [Pharo-dev] Metacello doubt

I'm in.


2013/6/26 Dale K. Henrichs <[hidden email]>



From: "Guido Chari" <[hidden email]>
To: "Pharo Development List" <[hidden email]>
Sent: Wednesday, June 26, 2013 2:49:09 PM

Subject: Re: [Pharo-dev] Metacello doubt

I understood. Thanks for the answer Dale. The drawback in this case is to specify a particular dependency to AsmJit in my configuration. Also, perhaps is the right way since i realized i have a particular dependency on it.

But this discussion makes me thing a little and so i have a new question.

Form what I (mis) undestand from Metacello, when asking for a bleedingEdge version it loads only the baseline that specifies packages and then last version of every package specified there. 

As in the projects referenced on the baseline there is no need for specifying a version, and that's the case of nativeBoost configuration, wouldn't it be interesting to have some behavior (i mean i new method for loading like loadDeepSymbolic:) that not only load the symbolicVersion of the package asked, but also propagate that symbolicVersion (bleedingEdge in this case) to all the dependencies that don't specify a concrete version?

Guido.

Guido,

With the Metacello Scripting API[1] I've taken a slightly different tack, but I think that it gets you to the same place.

I am a big fan of deterministic loads, but I know that from a practical point of view developers need to have a certain amount of control over exactly what gets loaded into their DEVELOPMENT environments and they need to be able to exert this control without having to resort to editing configurations to match their specific requirements.

I have accomplished this by arranging for a Notification to be signalled whenever a project is referenced during a load. The developer can use one or more of the  onUpgrade:, onDowngrade: and onConflict: clauses in their load scripts to exert fine control over what happens on a project by project basis ...

For your specific use case, I would think that you would want to use the `lock` command[2] and specify that you want to `lock` the projects (NativeBoost and AsmJit) to the #bleedingEdge version. I don't recall if I've got test cases for symbolic versions, but if you are seriously interested in taking the Scripting API for a spin, I'd be willing to write some additional tests using the #bleedingEdge symbolic version (if not already covered) and validate this use case...

I am entering a phase where I will be doing some work on getting FileTree and Metacello up to snuff for Pharo3.0 so this would be a good time for me to add some test cases in anticipation of having some interested users ...

I haven't released the Scripting API, because I need to have real users with real use cases take the API for a spin and validate the API. The Scripting API can be loaded into any version of Pharo/Squeak/GemStone and I think the Scripting API is (or will be) available in Pharo3.0.

I'm looking forward to getting feedback as to how the API stands up to real use ...

So let me know if you are interested in being another Scripting API guinea pig:)

Dale

[1] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUserGuide.md
[2] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUserGuide.md#locking



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Pharo-dev] Metacello doubt

Dale Henrichs-3
Guido,

I've just released Metacello Preview 1.0.0-beta.32.8[1] that includes a bugfix for your issue. Let me know if you need more information.

Dale

[1] http://gemstonesoup.wordpress.com/2013/07/17/metacello-preview-1-0-0-beta-32-8-composed/


From: "Guido Chari" <[hidden email]>
To: "Pharo Development List" <[hidden email]>
Sent: Tuesday, July 2, 2013 12:42:40 PM
Subject: Re: [Pharo-dev] Metacello doubt

Ok, i will follow the issue on github. Thanks!


2013/7/1 Dale K. Henrichs <[hidden email]>
Guido,

I created a test case and it turns out that there _is_ a bug in the bypass lock logic[1] . I'm going to push out a new version of the Metacello Preview (1.0.0-beta.32.8) in the next day or so and the bugfix for Issue #174 will _not_ be included in that release ...

Dale

[1] https://github.com/dalehenrich/metacello-work/issues/174


From: "Guido Chari" <[hidden email]>
To: "Pharo Development List" <[hidden email]>
Sent: Thursday, June 27, 2013 10:23:33 AM
Subject: Re: [Pharo-dev] Metacello doubt

I'm in.


2013/6/26 Dale K. Henrichs <[hidden email]>



From: "Guido Chari" <[hidden email]>
To: "Pharo Development List" <[hidden email]>
Sent: Wednesday, June 26, 2013 2:49:09 PM

Subject: Re: [Pharo-dev] Metacello doubt

I understood. Thanks for the answer Dale. The drawback in this case is to specify a particular dependency to AsmJit in my configuration. Also, perhaps is the right way since i realized i have a particular dependency on it.

But this discussion makes me thing a little and so i have a new question.

Form what I (mis) undestand from Metacello, when asking for a bleedingEdge version it loads only the baseline that specifies packages and then last version of every package specified there. 

As in the projects referenced on the baseline there is no need for specifying a version, and that's the case of nativeBoost configuration, wouldn't it be interesting to have some behavior (i mean i new method for loading like loadDeepSymbolic:) that not only load the symbolicVersion of the package asked, but also propagate that symbolicVersion (bleedingEdge in this case) to all the dependencies that don't specify a concrete version?

Guido.

Guido,

With the Metacello Scripting API[1] I've taken a slightly different tack, but I think that it gets you to the same place.

I am a big fan of deterministic loads, but I know that from a practical point of view developers need to have a certain amount of control over exactly what gets loaded into their DEVELOPMENT environments and they need to be able to exert this control without having to resort to editing configurations to match their specific requirements.

I have accomplished this by arranging for a Notification to be signalled whenever a project is referenced during a load. The developer can use one or more of the  onUpgrade:, onDowngrade: and onConflict: clauses in their load scripts to exert fine control over what happens on a project by project basis ...

For your specific use case, I would think that you would want to use the `lock` command[2] and specify that you want to `lock` the projects (NativeBoost and AsmJit) to the #bleedingEdge version. I don't recall if I've got test cases for symbolic versions, but if you are seriously interested in taking the Scripting API for a spin, I'd be willing to write some additional tests using the #bleedingEdge symbolic version (if not already covered) and validate this use case...

I am entering a phase where I will be doing some work on getting FileTree and Metacello up to snuff for Pharo3.0 so this would be a good time for me to add some test cases in anticipation of having some interested users ...

I haven't released the Scripting API, because I need to have real users with real use cases take the API for a spin and validate the API. The Scripting API can be loaded into any version of Pharo/Squeak/GemStone and I think the Scripting API is (or will be) available in Pharo3.0.

I'm looking forward to getting feedback as to how the API stands up to real use ...

So let me know if you are interested in being another Scripting API guinea pig:)

Dale

[1] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUserGuide.md
[2] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUserGuide.md#locking




12
Loading...