Hi Hernán,
>We have to get better at communication. It doesn't work if all of us
fork libraries.
i guess i disagree, the occasional fork <g> can be freshening.
>But I don't want to be forced to load the whole SciSmalltalk to use 3
methods in NumericalMethods.
that's not really necessary. assuming that you want to also use the
dhb-extensions, you can eg do something like:
(ConfigurationOfSciSmalltalk project version:#stable)load:
#('Math-DHB-NumericalExtensions' 'Math-Tests-DHB-Numerical'). "a
MetacelloFetchingMCSpecLoader(linear load :
linear load : 0.16 [ConfigurationOfSciSmalltalk]
linear load : 1.0 [ConfigurationOfArbitraryPrecisionFloat]
load : ArbitraryPrecisionFloat-nice.38
load : ArbitraryPrecisionFloatTests-nice.16
load : ExtendedNumberParser-nice.1
load : Math-DHB-Numerical-wernerkassens.30
load : Math-Tests-DHB-Numerical-wernerkassens.9
load : Math-DHB-NumericalExtensions-WernerKassens.5)"
this loads additionally ArbitraryPrecisionFloat, but this is, i'd say,
an unimportant bug in the config, that should get repaired occasionally.
and ArbitraryPrecisionFloat is not that big. it's not really a problem.
>Can you import the ConfigurationOfNumericalMethod from a common
repository in SciSmalltalk?
there could eventually be a little difficulty. you cant load both
versions. of course one could work around that problem in the config, but
1. the config of scismalltalk is already complicated enough, that hardly
anyone changing it can get things right there at their first attempt.
2.it would also complicate the _use_ of the config for the user, a big
drawback imo.
of course one could simply throw away the fork. but then one would need
to throw away also some other packages.
a third possibility would be to put all changes in the fork in an extra
package that can be loaded on top of the original dhb. but that looks
like a sizable enough task, that i at least will not do it.
what do you think?
werner
