Smalltalk › Frameworks & Tools › SciSmalltalk

entanglements

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

6 messages Options

werner kassens-2

entanglements

Hi,
i think i understand why the extensions were constructed and mixed up the way they are, but otoh this resulted in some unfortunate mix-ups of dependencies. of course these dependencies could be modeled in config but this would result in a very complicated, completely ununderstandable config. the way things are at the moment, is not really correct either. as an example suppose somebody wants to program a database and <g> for some strange reason he decides to use complexNumbers as a key. so he does a '(ConfigurationOfSciSmalltalk project version: #stable) load:'Math-Complex',which would work for a moment. then he finds the method isComplex and uses it in his program. this could result in an Error since Number>>isComplex is defined (i think) in Math-ComplexExtensions. of course simply adding a 'spec requires:' in the config wouldnt work, since then metacello would find an infinite loop. there are other more complicated remedies one could do in the config, but im relatively certain that i could construct more complicated scenarios where this wouldnt work either and i want to spare you this nonsense.

at the moment complex, quaternion and dhb are dependent on each other. iow if somebody would ask me how to load complex, i would advise him <g> to load the complete development version of scismalltalk and then remove what he doesnt need. perhaps one could disentangle these things a little bit by putting those extensions back into the packages, were they originally resided? btw i just made Math-Tests-Random independent of Math-DHB-Numerical.

werner

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

Nicolas Cellier

Re: entanglements

I agree, and already wrote about it https://github.com/SergeStinckwich/SciSmalltalk/issues/15 a few days ago

There is no point in separating messages like (#i #i: #asComplex) from Math-Complex because the Math-Complex kernel require them.

So the first thing to do would be to re-integrate those messages in Math-Complex package.
Also, that would reduce un-necessary differences with http://www.squeaksource.com/Complex from which Sci-Smalltalk forked.

2014-04-27 19:11 GMT+02:00 werner kassens <[hidden email]>:

Hi,
i think i understand why the extensions were constructed and mixed up the way they are, but otoh this resulted in some unfortunate mix-ups of dependencies. of course these dependencies could be modeled in config but this would result in a very complicated, completely ununderstandable config. the way things are at the moment, is not really correct either. as an example suppose somebody wants to program a database and <g> for some strange reason he decides to use complexNumbers as a key. so he does a '(ConfigurationOfSciSmalltalk project version: #stable) load:'Math-Complex',which would work for a moment. then he finds the method isComplex and uses it in his program. this could result in an Error since Number>>isComplex is defined (i think) in Math-ComplexExtensions. of course simply adding a 'spec requires:' in the config wouldnt work, since then metacello would find an infinite loop. there are other more complicated remedies one could do in the config, but im relatively certain that i could construct more complicated scenarios where this wouldnt work either and i want to spare you this nonsense.

at the moment complex, quaternion and dhb are dependent on each other. iow if somebody would ask me how to load complex, i would advise him <g> to load the complete development version of scismalltalk and then remove what he doesnt need. perhaps one could disentangle these things a little bit by putting those extensions back into the packages, were they originally resided? btw i just made Math-Tests-Random independent of Math-DHB-Numerical.

werner

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

SergeStinckwich

Re: entanglements

On Mon, Apr 28, 2014 at 2:34 PM, Nicolas Cellier
<[hidden email]> wrote:
> I agree, and already wrote about it
> https://github.com/SergeStinckwich/SciSmalltalk/issues/15 a few days ago
> There is no point in separating messages like (#i #i: #asComplex) from
> Math-Complex because the Math-Complex kernel require them.
> So the first thing to do would be to re-integrate those messages in
> Math-Complex package.
> Also, that would reduce un-necessary differences with
> http://www.squeaksource.com/Complex from which Sci-Smalltalk forked.

We should not have two different versions.

Nicolas, what do you prefer :

1) adding the Complex package as a dependancy of SciSmalltalk
2) moving the Complex package in the SciSmalltalk repository.

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.

Nicolas Cellier

Re: entanglements

2014-04-28 14:45 GMT+02:00 Serge Stinckwich <[hidden email]>:

On Mon, Apr 28, 2014 at 2:34 PM, Nicolas Cellier
<[hidden email]> wrote:
> I agree, and already wrote about it
> https://github.com/SergeStinckwich/SciSmalltalk/issues/15 a few days ago
> There is no point in separating messages like (#i #i: #asComplex) from
> Math-Complex because the Math-Complex kernel require them.
> So the first thing to do would be to re-integrate those messages in
> Math-Complex package.
> Also, that would reduce un-necessary differences with
> http://www.squeaksource.com/Complex from which Sci-Smalltalk forked.

We should not have two different versions.

Nicolas, what do you prefer :

1) adding the Complex package as a dependancy of SciSmalltalk
2) moving the Complex package in the SciSmalltalk repository.

Regards,
--

I think it's better to have all grouped in SciSmalltalk for the moment.

I can maintain the squeaksource one in parallel, it is still in use for things like Smallapack.

But having the least differences as possible would be nice.

cheers

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.

werner kassens-2

Re: entanglements

On Monday, April 28, 2014 8:50:15 PM UTC+2, Nicolas Cellier wrote:

I think it's better to have all grouped in SciSmalltalk for the moment.
I can maintain the squeaksource one in parallel, it is still in use for things like Smallapack.

But having the least differences as possible would be nice.

Hi Nicolas,
will you correct Complex and Quaternion by yourself or would you prefer if i do that?
werner

Nicolas Cellier

Re: entanglements

On Tuesday, April 29, 2014 8:17:07 AM UTC+2, werner kassens wrote:

On Monday, April 28, 2014 8:50:15 PM UTC+2, Nicolas Cellier wrote:
I think it's better to have all grouped in SciSmalltalk for the moment.
I can maintain the squeaksource one in parallel, it is still in use for things like Smallapack.

But having the least differences as possible would be nice.

Hi Nicolas,
will you correct Complex and Quaternion by yourself or would you prefer if i do that?
werner

I can do it, I'll give it a try.