Package depending on the OS ?

Dale: I remember and understood perfectly the Metacello feature of having a platform specific package. Like MyApp-Pharo, MySpp-Gemstone....etc.
Then I also understood the project properties and the conditional loading.

Now, what I wonder is if it could be a good idea to have some feature to load specific platform packages what where the platform is actually the OS, but not the Smalltalk dialect. Maybe even the same functionality, but instead of asking the dialect, asking the OS. Thus, when loading, it will only load the package of that OS.

I am not hurry at all and I even don't need it right now. It can be 1.1, 1.2 o even 2.0 if you want. Just wanted to discuss the idea.

Cheers

Mariano

Mariano,

I think that this would be a good idea ... as soon as we have a concrete need I think we should add it ... it won't require a change in the api...

Dale
 
----- "Mariano Martinez Peck" <[hidden email]> wrote:

| Dale: I remember and understood perfectly the Metacello feature of
| having a
| platform specific package. Like MyApp-Pharo, MySpp-Gemstone....etc.
| Then I also understood the project properties and the conditional
| loading.
|
| Now, what I wonder is if it could be a good idea to have some feature
| to
| load specific platform packages what where the platform is actually
| the OS,
| but not the Smalltalk dialect. Maybe even the same functionality, but
| instead of asking the dialect, asking the OS. Thus, when loading, it
| will
| only load the package of that OS.
|
| I am not hurry at all and I even don't need it right now. It can be
| 1.1, 1.2
| o even 2.0 if you want. Just wanted to discuss the idea.
|
| Cheers
|
| Mariano

This question has more in it ...

What about a package that is only known to work from Pharo 1.1 onwards
and not in Pharo 1.0.

Or in Squeak trunk and Squeak 3.8 but not in Squeak 3.7.

We already have a notation for #requires: but used for package
dependencies.

Here we cross the border to non-packaged base systems, how can we
define a specific version/build nr/image
version as prerequisites?

On 24 févr. 2010, at 11:17, Torsten Bergmann wrote:


I think what you describe is related to embedded configurations in configuration.

ConfigurationOfMoose 4.0 depends on ConfigurationOfMondrian 2.0 for example
Then ConfigurationOfMoose 4.1 will depend on ConfigurationOfMondrian 2.4 ....

The same thing with ConfigurationOfPharo should work, right? The strange thing perhaps is that you have to explicitly declare Pharo as a dependency of your project, but it should not be a problem.


--
 Simon

Simon,

I think it's a slightly different question, because the core isn't managed by Metacello.

I think a simple example would be to look at how Utilitilies class>>authorInitials has migrated to Author>>fullName. This is a simple problem with a number of possible solutions, one of which would be to load a different package (you really are running on a different "platform").

So the question is can you distinguish Pharo 1.0 from Pharo 1.1 and the answer is yes. For GemStone I've found that I've needed to distinguish between versions 2.x, 2.3.x, 2.4.x and 3.x.

There is a platform class for each of the three platforms: MetacelloSqueakPlatform, MetacelloPharoPlatform, and MetacelloGemStonePlatform. MetacelloPlatform class>>current arranges to point to an instance of the appropriate platform class. The message #defaultPlatformAttributes is sent to that instance.

Right now on Pharo, the method is implemented to return:

  #(#squeakCommon #pharo )

On GemStone, the method is implemented as:

  | stoneVersionAtts |
  (stoneVersionAtts := self stoneVersionAttributes) ifNil: [^ #( #gemstone )].
  ^ stoneVersionAtts

and #stoneVersionAttrivutes is implemented as:

  stoneVersionAttribute isSymbol ifTrue: [ stoneVersionAttribute := nil ].
  stoneVersionAttribute ifNil: [ | gsVersion |
    stoneVersionAttribute := ((gsVersion := System stoneVersionAt: 'gsVersion') beginsWith: '2.')
      ifTrue: [
        (gsVersion beginsWith: '2.3')
          ifTrue: [ #( #gemstone #'gs2.x' #'gs2.3.x' ) ]
          ifFalse: [
            (gsVersion beginsWith: '2.4')
              ifTrue: [ #( #gemstone #'gs2.x' #'gs2.4.x' ) ]
              ifFalse: [ #( #gemstone #'gs2.x' ) ]]]
      ifFalse: [#( #gemstone #'gs3.x' )]].
  ^ stoneVersionAttribute

stoneVersionAttribute is an IV, so the calculation only needs to be done once.

A similare method could be written for Pharo (and Squeak) to allow differentiation across platform versions.

The platform version attributes can be used in a for:do:, just like #squeak, #pharo, etc.

If finer-grained versions are needed it still is possible for a particular project to add it's an attribute in the ConfigurationOf (see ConfigurationOfGemTools>>project and the logic for creating the #'pharo1.0Beta' attribute).

If this doesn't cover the playing field, then we can discuss additional alternatives.

Dale

----- "Simon Denier" <[hidden email]> wrote:

| On 24 févr. 2010, at 11:17, Torsten Bergmann wrote:
|
| > This question has more in it ...
| >
| > What about a package that is only known to work from Pharo 1.1
| onwards
| > and not in Pharo 1.0.
| >
| > Or in Squeak trunk and Squeak 3.8 but not in Squeak 3.7.
| >
| > We already have a notation for #requires: but used for package
| > dependencies.
| >
| > Here we cross the border to non-packaged base systems, how can we
| > define a specific version/build nr/image
| > version as prerequisites?
|
|
| I think what you describe is related to embedded configurations in
| configuration.
|
| ConfigurationOfMoose 4.0 depends on ConfigurationOfMondrian 2.0 for
| example
| Then ConfigurationOfMoose 4.1 will depend on ConfigurationOfMondrian
| 2.4 ....
|
| The same thing with ConfigurationOfPharo should work, right? The
| strange thing perhaps is that you have to explicitly declare Pharo as
| a dependency of your project, but it should not be a problem.
|
|
| --
|  Simon

> I think a simple example would be to look at how Utilitilies class>>authorInitials has migrated to Author>>fullName. This is a simple problem with a number of possible solutions, one of which would be to load a differentpackage(you really are running on a different "platform").
>
> So the question is can you distinguish Pharo 1.0 from Pharo 1.1 and the answer is yes. For GemStone I've found that I've needed to distinguish between versions 2.x, 2.3.x, 2.4.x and 3.x.
I think this will be really important down the road to avoid the mess
with Squeak now where you have to load packages with little
documentation that are X years old, and cross your fingers to see if
it will run on your version.

You can easily get Pharo's version:
SystemVersion current majorMinorVersion. "e.g. 'Pharo-1.0'"

> A similare method could be written for Pharo (and Squeak) to allow differentiation across platform versions.
I'd be happy to write it.  Is the above format definitely how it's
going to look e.g. #'ph[number].x' ...  I'd prefer to spell the name
out fully for clarity (and possible expanding forks/names down the
line)

Brainstorming: it seems like ranges could be useful too, like
pharo1.0-1.7

Sean


--
Subscription settings: http://groups.google.com/group/metacello/subscribe?hl=en

Sean,

I'm waiting for the time when we have a clear requirement, before inserting this into Metacello itself. Individual Configurations can be written with methods that adjust for version ...

I would think that at the point that a number of projects find themsevles needing to differentiate then we can add the capability. Until then I think that it would be useful to explore the possibilities - I've created http://code.google.com/p/metacello/issues/detail?id=71 to record specific algorithms and ideas so when the time comes to really solve the problem, we'll have a number of different approaches to choose from (hopefully).

Dale
----- "Sean DeNigris" <[hidden email]> wrote:

| > I think a simple example would be to look at how Utilitilies
| class>>authorInitials has migrated to Author>>fullName. This is a
| simple problem with a number of possible solutions, one of which would
| be to load a differentpackage(you really are running on a different
| "platform").
| >
| > So the question is can you distinguish Pharo 1.0 from Pharo 1.1 and
| the answer is yes. For GemStone I've found that I've needed to
| distinguish between versions 2.x, 2.3.x, 2.4.x and 3.x.
| I think this will be really important down the road to avoid the mess
| with Squeak now where you have to load packages with little
| documentation that are X years old, and cross your fingers to see if
| it will run on your version.
|
| You can easily get Pharo's version:
| SystemVersion current majorMinorVersion. "e.g. 'Pharo-1.0'"
|
| > A similare method could be written for Pharo (and Squeak) to allow
| differentiation across platform versions.
| I'd be happy to write it.  Is the above format definitely how it's
| going to look e.g. #'ph[number].x' ...  I'd prefer to spell the name
| out fully for clarity (and possible expanding forks/names down the
| line)
|
| Brainstorming: it seems like ranges could be useful too, like
| pharo1.0-1.7
|
| Sean
|
|
| --
| Subscription settings:
| http://groups.google.com/group/metacello/subscribe?hl=en

> I would think that at the point that a number of projects find themsevles needing to differentiate then we can add the capability. Until then I think that it would be useful to explore the possibilities - I've createdhttp://code.google.com/p/metacello/issues/detail?id=71to record specific algorithms and ideas so when the time comes to really solve the problem, we'll have a number of different approaches to choose from (hopefully).

k, sounds good.   thx.


--
Subscription settings: http://groups.google.com/group/metacello/subscribe?hl=en

> Individual Configurations can be written with methods that adjust for version ...

Would that be through preLoadDoIt?


--
Subscription settings: http://groups.google.com/group/metacello/subscribe?hl=en

This is what's driving my questions (I need to install differently
between Pharo 1.0 and 1.1)...

I have:
  1. SSpec - which holds all the #common code (I'll eventually split
it up into core/tests/etc, but it exists as one big package right now)
  2. SSpec-Platform
    a. SSpec-Platform.pharo
    b. SSpec-Platform.squeak

Everything works like a charm on Pharo 1.1 and Squeak 4.1.

So... the only piece left is what to do on Pharo 1.0, since the code
that broke the package (pragma world menu) didn't come along until
1.1.

What needs to happen is that Pharo 1.0 uses the same code as Squeak.

How would I accomplish that?

Thanks!
Sean


--
Subscription settings: http://groups.google.com/group/metacello/subscribe?hl=en

No ideas?  This problem is nagging on a few different projects.

Thanks.
Sean

Sean,

Sorry for not getting back to you earlier. Take a look a ConfigurationOfGemTools>>project. In that method I created a #'pharo1.0Beta' attribute by looking at the SystemVersion current version...

Dale
----- "Sean DeNigris" <[hidden email]> wrote:

| This is what's driving my questions (I need to install differently
| between Pharo 1.0 and 1.1)...
|
| I have:
|   1. SSpec - which holds all the #common code (I'll eventually split
| it up into core/tests/etc, but it exists as one big package right
| now)
|   2. SSpec-Platform
|     a. SSpec-Platform.pharo
|     b. SSpec-Platform.squeak
|
| Everything works like a charm on Pharo 1.1 and Squeak 4.1.
|
| So... the only piece left is what to do on Pharo 1.0, since the code
| that broke the package (pragma world menu) didn't come along until
| 1.1.
|
| What needs to happen is that Pharo 1.0 uses the same code as Squeak.
|
| How would I accomplish that?
|
| Thanks!
| Sean
|
|
| --
| Subscription settings:
| http://groups.google.com/group/metacello/subscribe?hl=en

On Apr 29, 6:14 pm, Dale Henrichs <[hidden email]> wrote:
> Take a look a ConfigurationOfGemTools>>project. In that method I created a #'pharo1.0Beta' attribute by looking at the SystemVersion current version...

This looks like exactly what I need - thanks a lot!

Sean

On Apr 21, 12:25 pm, Dale Henrichs <[hidden email]> wrote:
> I'm waiting for the time when we have a clear requirement, before inserting this into Metacello itself. Individual Configurations can be written with methods that adjust for version ...

I think I've encountered a requirement, but from the user end:
Metacello Configurations definitely simplify dependency management.
When it works, it's awesome!  Where I am hitting the wall is managing
compatibility with different flavors of Squeak.  Let me recount my
latest experience...

> I want to install ExternalWebBrowser.
> Oh good, there is a ConfigurationOf... in the SqS MetacelloRepository
> Let me make sure it works and then I'll add it to my ImageSetup script
> Results
>     Pharo 1.1 trunk update 11364: ExternalWebBrowserMacOS class>>isApplescriptAvailable references SMSqueakMap, which was removed from Pharo.  Ugh, okay, I'll manually install Applescript via Gofer and Monticello, then restart
>     Pharo 1.0: same problem
>     Squeak 4.1 trunk update 10145: MetacelloMCProjectSpec's instance variable 'className' is nil; when asSymbol is called on it, DNU asSymbol
>     Squeak 4.1 official release: same problem

So my question is - what platform does this config target?  It failed
for all the current Squeak and Pharo images!

As a user, I would like to either:
* have a specific place (depending on my platform) to find the correct
config
* or, even easier (and I suspect much less duplication, since many
configs may work with multiple platforms), a way to mark
ConfigurationsOf as working with particular platforms.  Then, you
could at least issue a warning, like SqMap, that 'the Config was not
approved for this platform, do you want to continue.'  If this info
was built into the Metacello model, one might even be able to query
the MetacelloRepository for configs approved for the current platform.

The way it is now, I think I spent more time above than manually
resolving the dependencies.
What are your experiences with this issue, if any?

Thanks.
Sean

Thanks for the response (comments inline)

On May 15, 9:55 am, Mariano Martinez Peck <[hidden email]>
wrote:
> First, this is not up to Metacello. I mean, Metacello WILL NOT help to make
> your software cross-platfrom. YOU will have to do that. Of course, you can
> try to use tools such as Grease or Sport.

Yes, sure.  I'm saying that it should be obvious from looking at a
ConfigurationOfXxx what platforms/versions it works on (e.g. possibly
based on where it is located, which is not a Metacello library issue
per se, or maybe as part of the model).

> What Metacello provides you is a way to easily manage packages that depends
> on the platform. Thus, if you have your package MyApp-Platform-Squeak and
> MyApp-PlatformPharo Metacello will help you to load the correct package in
> each platfrom. But again, YOU have to provide the different platform
> packages.
>
> You are not resolving dependencies, you are resolving portability problem
> across dialects.

Yes again - I'm so glad we agree ;-)  What I'm suggesting is extending
the platform-management from 'which forks?' to 'which versions of
which forks?'  As it stands, I have the platform packages all cooked
up, and I can put them into the config through the project hack a la
ConfigurationOfGemTools, but there is no way in the spec model for a
user to tell if my Config should work on e.g. Pharo 1.1 specifically.
And, if a user has to overcome 'why didn't this Config work on my
platform' errors, at least in my last experience, it overwhelms the
cool dependency-resolving that Metacello provides.

And, as a developer, when I encountered the errors with
ExternalWebBrowser, because I did not know what platform version it
was supposed to work on, it was not obvious how to contribute a fix to
the community - especially if Pharo 1.0, Pharo trunk, Squeak 4.1, and
Squeak trunk, etc. all need different platform-specific pieces -
unless I knew about the ConfigurationOfGemTools approach.  Let's make
this a part of the model and empower the community to write and port
code cross-platform!

Sean

Sean,

The only difficulty I see in trying to do an across the board inclusion of platform versions in the attributes is that it's isn't clear which level of granularity is appropriate.

Should the standard versions be:

  Pharo1.0
  Pharo1.1
  Pharo1.1.1

or should the granularity be finer than that and include the build number...

In GemStone I found that I needed to do things like:

  2.3.x
  2.4.x

to cover intermediate releases...it wasn't necessary (so far) to go any farther, but that doesn't mean that a particular project won't have dependencies upon 2.3.1.

I think that as Pharo1.1 goes into development that we will see patterns emerge for Pharo that will end up being covered in the "standard attributes"

Dale
----- "Sean DeNigris" <[hidden email]> wrote:

| Thanks for the response (comments inline)
|
| On May 15, 9:55 am, Mariano Martinez Peck <[hidden email]>
| wrote:
| > First, this is not up to Metacello. I mean, Metacello WILL NOT help
| to make
| > your software cross-platfrom. YOU will have to do that. Of course,
| you can
| > try to use tools such as Grease or Sport.
|
| Yes, sure.  I'm saying that it should be obvious from looking at a
| ConfigurationOfXxx what platforms/versions it works on (e.g. possibly
| based on where it is located, which is not a Metacello library issue
| per se, or maybe as part of the model).
|
| > What Metacello provides you is a way to easily manage packages that
| depends
| > on the platform. Thus, if you have your package
| MyApp-Platform-Squeak and
| > MyApp-PlatformPharo Metacello will help you to load the correct
| package in
| > each platfrom. But again, YOU have to provide the different
| platform
| > packages.
| >
| > You are not resolving dependencies, you are resolving portability
| problem
| > across dialects.
|
| Yes again - I'm so glad we agree ;-)  What I'm suggesting is
| extending
| the platform-management from 'which forks?' to 'which versions of
| which forks?'  As it stands, I have the platform packages all cooked
| up, and I can put them into the config through the project hack a la
| ConfigurationOfGemTools, but there is no way in the spec model for a
| user to tell if my Config should work on e.g. Pharo 1.1 specifically.
| And, if a user has to overcome 'why didn't this Config work on my
| platform' errors, at least in my last experience, it overwhelms the
| cool dependency-resolving that Metacello provides.
|
| And, as a developer, when I encountered the errors with
| ExternalWebBrowser, because I did not know what platform version it
| was supposed to work on, it was not obvious how to contribute a fix
| to
| the community - especially if Pharo 1.0, Pharo trunk, Squeak 4.1, and
| Squeak trunk, etc. all need different platform-specific pieces -
| unless I knew about the ConfigurationOfGemTools approach.  Let's make
| this a part of the model and empower the community to write and port
| code cross-platform!
|
| Sean

> The only difficulty I see in trying to do an across the board inclusion of platform versions in the attributes is that it's isn't clear which level of granularity is appropriate.
>
> Should the standard versions be:
>
>   Pharo1.0
>   Pharo1.1
>   Pharo1.1.1
>
> or should the granularity be finer than that and include the build number...

This may be totally out of nowhere, but could for:do: take a block?
In other words, instead of being restricted to for: #squeak do:, one
could say:

for: [ spec squeak version: '4.0' to: '4.1' ] do: [...]

Another thought is allow a simple regex - maybe use 'x' as 'anything
for this part of the version'

Just brainstorming...

Sean

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

Hi Sean

You can do:

for: #( #'squeak4.1.x' #'squeak4.2.x' #'squeak4.3.x' ) do: [..]

it's rather verbose but works! :)

Best regards
        -Tobias


>
> --
> You received this message because you are subscribed to the Google Groups "Metacello" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.