Hi Werner
2015-01-28 21:11 GMT-03:00 Werner Kassens <[email protected]>:
> 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').
Thank you for the tip. But that also means now I should change my
configurations to stay updated because you (doesn't matter who) just
couldn't resist copying all NumericalMethods packages to your own
repository.
This is like if I get 5 mathematicians, fork SciSmalltalk, push cool new
features, and then make all you loose them if you don't update. And I could
do it for fun 1000 times. You get the idea.
But I am not against SciSmalltalk, I don't like forks without a good reason.
> "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.
I am saying there should be one version.
> 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.
>
Then the project is badly organized?
Because Metacello supposedly should help things to become easier.
> 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?
>
What's done is done. I doubt you could retract your changes.
I don't like this situation but it seems to be the Smalltalk way.
Hernán
> werner
>
>
