Migration suggestions

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Migration suggestions

stepharo
I was wondering what is a good strategy to migrate.
We have normally a stable version of sci. I would like to avoid to have
PM classes within the sci repo.


May be I could copy all the packages in the new repo and only there
start to rename classes and create new packages.
My goal is that students in two weeks can look at the random generators
that we nicely accumulated over the years and also the distributions. So
I would like start from these.

So I will have to think. Any idea about a good strategy?

I'm eager to play with Cargo the new package system to see because I
would like to avoid to have
to manage a large configuration and at the same time I would love to
have multiple configurations to avoid to have

So may be I should do
     ConfigOfPolymath

             ConfigOfPolymathCore

             ConfigOfPolymathAccuracy

             ConfigOfPolymathODE

and each of them should have several packages ....

What do you think?

Stef

--
You received this message because you are subscribed to the Google Groups "SciSmalltalk" 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.
Reply | Threaded
Open this post in threaded view
|

Re: Migration suggestions

SergeStinckwich
On Tue, Mar 15, 2016 at 5:21 PM, stepharo <[hidden email]> wrote:
> I was wondering what is a good strategy to migrate.
> We have normally a stable version of sci. I would like to avoid to have PM
> classes within the sci repo.

Yes we should avoid to mix both classes.

> May be I could copy all the packages in the new repo and only there start to
> rename classes and create new packages.

yes I think so.

> My goal is that students in two weeks can look at the random generators that
> we nicely accumulated over the years and also the distributions. So I would
> like start from these.
 :-)

> So I will have to think. Any idea about a good strategy?
>
> I'm eager to play with Cargo the new package system to see because I would
> like to avoid to have
> to manage a large configuration and at the same time I would love to have
> multiple configurations to avoid to have

I dunno what is Cargo.

> So may be I should do
>     ConfigOfPolymath
>
>             ConfigOfPolymathCore
>
>             ConfigOfPolymathAccuracy
>
>             ConfigOfPolymathODE
>
> and each of them should have several packages ....
>
> What do you think?

I dunno, this will be the policy of Cargo in the future if I have
understand what you say ?

Regards,
--
Serge Stinckwich
UCBN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
http://www.doesnotunderstand.org/

--
You received this message because you are subscribed to the Google Groups "SciSmalltalk" 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.
Reply | Threaded
Open this post in threaded view
|

Re: Migration suggestions

stepharo


Le 15/3/16 18:39, Serge Stinckwich a écrit :

> On Tue, Mar 15, 2016 at 5:21 PM, stepharo <[hidden email]> wrote:
>> I was wondering what is a good strategy to migrate.
>> We have normally a stable version of sci. I would like to avoid to have PM
>> classes within the sci repo.
> Yes we should avoid to mix both classes.
>
>> May be I could copy all the packages in the new repo and only there start to
>> rename classes and create new packages.
> yes I think so.
>
>> My goal is that students in two weeks can look at the random generators that
>> we nicely accumulated over the years and also the distributions. So I would
>> like start from these.
>   :-)
>
>> So I will have to think. Any idea about a good strategy?
>>
>> I'm eager to play with Cargo the new package system to see because I would
>> like to avoid to have
>> to manage a large configuration and at the same time I would love to have
>> multiple configurations to avoid to have
> I dunno what is Cargo.
The idea is that each package will have its own dependencies definition.
Now since this is not ready I will use Configurations but I would like
to see how I can avoid to have one configuration with 51 packages
because this is heavy.
Anyway I should start and see.

>
>> So may be I should do
>>      ConfigOfPolymath
>>
>>              ConfigOfPolymathCore
>>
>>              ConfigOfPolymathAccuracy
>>
>>              ConfigOfPolymathODE
>>
>> and each of them should have several packages ....
>>
>> What do you think?
> I dunno, this will be the policy of Cargo in the future if I have
> understand what you say ?
>
> Regards,

--
You received this message because you are subscribed to the Google Groups "SciSmalltalk" 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.