Smalltalk › Frameworks & Tools › SciSmalltalk

configuration inconsistency

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

11 messages Options

werner kassens-2

configuration inconsistency

Hi,
there is a little incompatibility in the config now. StatPseudoCollections loads DHB-hfm which is incompatibel with Math-DHB-Numerical. as an example load into a SciSmalltalk image without StatPseudoCollections this:
(ConfigurationOfSciSmalltalk project version:'0.15')load:'StatPseudoCollections'.
then do this:
s :=DhbSymmetricMatrix rows: #((1 2 3)(2 1 4)(3 4 0)).
" a DhbVector(1 2 3)
a DhbVector(2 1 4)
a DhbVector(3 4 0)"
s2 :=DhbSymmetricMatrix rows: #((1 2 0)(2 1 4)(0 4 0)).
" a DhbVector(1 2 0)
a DhbVector(2 1 4)
a DhbVector(0 4 0)"
r:=s*s2.
" a DhbVector(5 16 8)
a DhbVector(4 21 4)
a DhbVector(11 10 16)"
r transpose.
" a DhbVector(5 16 8)
a DhbVector(4 21 4)
a DhbVector(11 10 16)"
that transpose is very obviously wrong! this does not happen if one uses Math-DHB-Numerical or DHB separately, it happens only if _some methods in math-dhb are overwritten by dhb.
i see two obvious solutions:
Oh, you could probably use Math-DHB-Numerical instead of DHB in your config, or alternatively we could substitute Math-DHB-Numerical by DHB, in wich case we should also delete Math-FunctionFit and very probably Math-DHB-wk as they both rely on Math-DHB-Numerical since there are some finer bugs in DHB that both packages dont like, the explanation of which i will spare you (and me) here, since they are somewhat complicated and would make this message really long<g>. (should it be desired i will of course explain these bugs, but that could become a long message; or one could just use the math-tests-dhb-numerical with dhb-hfm)
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: configuration inconsistency

On Tue, Sep 30, 2014 at 11:06 PM, werner kassens <[hidden email]> wrote:

> Hi,
> there is a little incompatibility in the config now. StatPseudoCollections
> loads DHB-hfm which is incompatibel with Math-DHB-Numerical. as an example
> load into a SciSmalltalk image without StatPseudoCollections this:
> (ConfigurationOfSciSmalltalk project
> version:'0.15')load:'StatPseudoCollections'.
> then do this:
> s :=DhbSymmetricMatrix rows: #((1 2 3)(2 1 4)(3 4 0)).
> " a DhbVector(1 2 3)
> a DhbVector(2 1 4)
> a DhbVector(3 4 0)"
> s2 :=DhbSymmetricMatrix rows: #((1 2 0)(2 1 4)(0 4 0)).
> " a DhbVector(1 2 0)
> a DhbVector(2 1 4)
> a DhbVector(0 4 0)"
> r:=s*s2.
> " a DhbVector(5 16 8)
> a DhbVector(4 21 4)
> a DhbVector(11 10 16)"
> r transpose.
> " a DhbVector(5 16 8)
> a DhbVector(4 21 4)
> a DhbVector(11 10 16)"
> that transpose is very obviously wrong! this does not happen if one uses
> Math-DHB-Numerical or DHB separately, it happens only if _some methods in
> math-dhb are overwritten by dhb.
> i see two obvious solutions:
> Oh, you could probably use Math-DHB-Numerical instead of DHB in your
> config, or alternatively we could substitute Math-DHB-Numerical by DHB, in
> wich case we should also delete Math-FunctionFit and very probably
> Math-DHB-wk as they both rely on Math-DHB-Numerical since there are some
> finer bugs in DHB that both packages dont like, the explanation of which i
> will spare you (and me) here, since they are somewhat complicated and would
> make this message really long<g>. (should it be desired i will of course
> explain these bugs, but that could become a long message; or one could just
> use the math-tests-dhb-numerical with dhb-hfm)

Thank you for the report Werner.

I think that is not a good idea if everyone modify the
ConfigurationOfSciSmalltalk stable version.
We should do it only for release purpose when the tests are green on
the development version.

Thank you Ho for your contribution, but I think this is simple to
upload your code in the SciSmalltalk instead of your own repo.
If the code is available on another repository, there is no way to
modify the code for the core maintainers of SciSmalltalk (or we should
ask a write access to your repo).

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.

werner kassens-2

Re: configuration inconsistency

Hi,
the config is not in the best state. probably out of politeness Oh did not change the development version to the new baseline. but, if one would modify the development version accordingly, nothing would change as in this form the new baseline would not load StatPseudoCollections. if one wants to correct that, one has essentially two possibilities depending on in which group at which position one puts StatPseudoCollections:
assumed one puts StatPseudoCollections last, you'll have red tests in math-dhb-numerical, since it will be partly overwritten by dhb-hfm. trying to repair that in math-dhb-numerical does not make any sense at all. as i already said, the most clever solution would then be to use dhb-hfm directly.
assumed one puts StatPseudoCollections first, then all tests will stay green, since then dhb-hfm will be overwritten by math-dhb-numerical and there are not too many tests in StatPseudoCollections that show the problems there, but you'll have other more hidden problems:
1. nothing in the config would signal that this sequence of loading is necessary, and i wouldnt rely on the silent assumption that this will always be the case in the future.
2. - excuse me if i state the obvious - but a config is not only used to load a complete project but also to load singular packages with their dependencies. if somebody downloads math-dhb-numerical, does some programming with it, then loads StatPseudoCollections, the result will almost surely be that his program will produce strange numbers if matrices are used anywhere (and they are used a lot in dhb).
3. another possible scenario where this reverse sequence of loading can happen: lets say an old SciSmalltalk image is updated to a new version.
4. in the above scenarios, most methods of math-dhb-numerical are then in dhb-hfm. if somebody wants to correct a bug in math-dhb-numerical (<g> perhaps produced by this mixups), he changes dhb-hfm instead. this can lead to all kinds of problem-scenarios, that could eventually be difficult to sort out.
5. StatPseudoCollections would need some work and perhaps a few more tests. as a simple example, if you run the critics-browser on daliot you see 18 messages sent but not implemented, iow those messages would just produce a dnu. and i dont understand why a scientific library would need many of the implemented but unused messages. and even when they are used it would often be more efficient to use standard pharo messages instead.

btw i would agree, that it looks rather idiotic to think about such a simple thing in such a lengthy way <g>, but then it rains outside. nevertheless i'd appreciate some feedback (hi Oh, should you be on holidays, i <friendly grin> understand your non-reaction, i also dont write emails when i'm on holiday, people just have to wait a bit in that case. but let me say that i'd be interested in your opinion).

ha,<g> the raining seems to stop!

werner

werner kassens-2

Re: configuration inconsistency

Hi,
btw no matter in which sequence statpseudocollections will be loaded, it will reintroduce the two methods, that can eventually produce the old problems described in the wiki: conflicts with existing packages.
werner

On Sat, Oct 11, 2014 at 12:51 PM, werner kassens <[hidden email]> wrote:

Hi,
the config is not in the best state. probably out of politeness Oh did not change the development version to the new baseline. but, if one would modify the development version accordingly, nothing would change as in this form the new baseline would not load StatPseudoCollections. if one wants to correct that, one has essentially two possibilities depending on in which group at which position one puts StatPseudoCollections:
assumed one puts StatPseudoCollections last, you'll have red tests in math-dhb-numerical, since it will be partly overwritten by dhb-hfm. trying to repair that in math-dhb-numerical does not make any sense at all. as i already said, the most clever solution would then be to use dhb-hfm directly.
assumed one puts StatPseudoCollections first, then all tests will stay green, since then dhb-hfm will be overwritten by math-dhb-numerical and there are not too many tests in StatPseudoCollections that show the problems there, but you'll have other more hidden problems:
1. nothing in the config would signal that this sequence of loading is necessary, and i wouldnt rely on the silent assumption that this will always be the case in the future.
2. - excuse me if i state the obvious - but a config is not only used to load a complete project but also to load singular packages with their dependencies. if somebody downloads math-dhb-numerical, does some programming with it, then loads StatPseudoCollections, the result will almost surely be that his program will produce strange numbers if matrices are used anywhere (and they are used a lot in dhb).
3. another possible scenario where this reverse sequence of loading can happen: lets say an old SciSmalltalk image is updated to a new version.
4. in the above scenarios, most methods of math-dhb-numerical are then in dhb-hfm. if somebody wants to correct a bug in math-dhb-numerical (<g> perhaps produced by this mixups), he changes dhb-hfm instead. this can lead to all kinds of problem-scenarios, that could eventually be difficult to sort out.
5. StatPseudoCollections would need some work and perhaps a few more tests. as a simple example, if you run the critics-browser on daliot you see 18 messages sent but not implemented, iow those messages would just produce a dnu. and i dont understand why a scientific library would need many of the implemented but unused messages. and even when they are used it would often be more efficient to use standard pharo messages instead.

btw i would agree, that it looks rather idiotic to think about such a simple thing in such a lengthy way <g>, but then it rains outside. nevertheless i'd appreciate some feedback (hi Oh, should you be on holidays, i <friendly grin> understand your non-reaction, i also dont write emails when i'm on holiday, people just have to wait a bit in that case. but let me say that i'd be interested in your opinion).

ha,<g> the raining seems to stop!

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: configuration inconsistency

In reply to this post by werner kassens-2

Werner, I'm a bit confused.
What should we do now to solve this ?

HwaJong Oh apparently you are not the mailing-list ?

Regards,

On Sat, Oct 11, 2014 at 12:51 PM, werner kassens <[hidden email]> wrote:

> Hi,
> the config is not in the best state. probably out of politeness Oh did not
> change the development version to the new baseline. but, if one would modify
> the development version accordingly, nothing would change as in this form
> the new baseline would not load StatPseudoCollections. if one wants to
> correct that, one has essentially two possibilities depending on in which
> group at which position one puts StatPseudoCollections:
> assumed one puts StatPseudoCollections last, you'll have red tests in
> math-dhb-numerical, since it will be partly overwritten by dhb-hfm. trying
> to repair that in math-dhb-numerical does not make any sense at all. as i
> already said, the most clever solution would then be to use dhb-hfm
> directly.
> assumed one puts StatPseudoCollections first, then all tests will stay
> green, since then dhb-hfm will be overwritten by math-dhb-numerical and
> there are not too many tests in StatPseudoCollections that show the problems
> there, but you'll have other more hidden problems:
> 1. nothing in the config would signal that this sequence of loading is
> necessary, and i wouldnt rely on the silent assumption that this will always
> be the case in the future.
> 2. - excuse me if i state the obvious - but a config is not only used to
> load a complete project but also to load singular packages with their
> dependencies. if somebody downloads math-dhb-numerical, does some
> programming with it, then loads StatPseudoCollections, the result will
> almost surely be that his program will produce strange numbers if matrices
> are used anywhere (and they are used a lot in dhb).
> 3. another possible scenario where this reverse sequence of loading can
> happen: lets say an old SciSmalltalk image is updated to a new version.
> 4. in the above scenarios, most methods of math-dhb-numerical are then in
> dhb-hfm. if somebody wants to correct a bug in math-dhb-numerical (<g>
> perhaps produced by this mixups), he changes dhb-hfm instead. this can lead
> to all kinds of problem-scenarios, that could eventually be difficult to
> sort out.
> 5. StatPseudoCollections would need some work and perhaps a few more tests.
> as a simple example, if you run the critics-browser on daliot you see 18
> messages sent but not implemented, iow those messages would just produce a
> dnu. and i dont understand why a scientific library would need many of the
> implemented but unused messages. and even when they are used it would often
> be more efficient to use standard pharo messages instead.
>
> btw i would agree, that it looks rather idiotic to think about such a simple
> thing in such a lengthy way <g>, but then it rains outside. nevertheless i'd
> appreciate some feedback (hi Oh, should you be on holidays, i <friendly
> grin> understand your non-reaction, i also dont write emails when i'm on
> holiday, people just have to wait a bit in that case. but let me say that
> i'd be interested in your opinion).
>
> ha,<g> the raining seems to stop!
>
> 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.

--
Serge Stinckwich
UCBN & UMI UMMISCO 209 (IRD/UPMC)
Help fight Ebola by joining the Computing for Ebola Challenge
http://bit.ly/1oEdBag

--
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: configuration inconsistency

I removed baseline 12 and version 15 until problems are fixed.

On Mon, Nov 17, 2014 at 5:39 PM, Serge Stinckwich
<[hidden email]> wrote:

> Werner, I'm a bit confused.
> What should we do now to solve this ?
>
> HwaJong Oh apparently you are not the mailing-list ?
>
> Regards,
>
> On Sat, Oct 11, 2014 at 12:51 PM, werner kassens <[hidden email]> wrote:
>> Hi,
>> the config is not in the best state. probably out of politeness Oh did not
>> change the development version to the new baseline. but, if one would modify
>> the development version accordingly, nothing would change as in this form
>> the new baseline would not load StatPseudoCollections. if one wants to
>> correct that, one has essentially two possibilities depending on in which
>> group at which position one puts StatPseudoCollections:
>> assumed one puts StatPseudoCollections last, you'll have red tests in
>> math-dhb-numerical, since it will be partly overwritten by dhb-hfm. trying
>> to repair that in math-dhb-numerical does not make any sense at all. as i
>> already said, the most clever solution would then be to use dhb-hfm
>> directly.
>> assumed one puts StatPseudoCollections first, then all tests will stay
>> green, since then dhb-hfm will be overwritten by math-dhb-numerical and
>> there are not too many tests in StatPseudoCollections that show the problems
>> there, but you'll have other more hidden problems:
>> 1. nothing in the config would signal that this sequence of loading is
>> necessary, and i wouldnt rely on the silent assumption that this will always
>> be the case in the future.
>> 2. - excuse me if i state the obvious - but a config is not only used to
>> load a complete project but also to load singular packages with their
>> dependencies. if somebody downloads math-dhb-numerical, does some
>> programming with it, then loads StatPseudoCollections, the result will
>> almost surely be that his program will produce strange numbers if matrices
>> are used anywhere (and they are used a lot in dhb).
>> 3. another possible scenario where this reverse sequence of loading can
>> happen: lets say an old SciSmalltalk image is updated to a new version.
>> 4. in the above scenarios, most methods of math-dhb-numerical are then in
>> dhb-hfm. if somebody wants to correct a bug in math-dhb-numerical (<g>
>> perhaps produced by this mixups), he changes dhb-hfm instead. this can lead
>> to all kinds of problem-scenarios, that could eventually be difficult to
>> sort out.
>> 5. StatPseudoCollections would need some work and perhaps a few more tests.
>> as a simple example, if you run the critics-browser on daliot you see 18
>> messages sent but not implemented, iow those messages would just produce a
>> dnu. and i dont understand why a scientific library would need many of the
>> implemented but unused messages. and even when they are used it would often
>> be more efficient to use standard pharo messages instead.
>>
>> btw i would agree, that it looks rather idiotic to think about such a simple
>> thing in such a lengthy way <g>, but then it rains outside. nevertheless i'd
>> appreciate some feedback (hi Oh, should you be on holidays, i <friendly
>> grin> understand your non-reaction, i also dont write emails when i'm on
>> holiday, people just have to wait a bit in that case. but let me say that
>> i'd be interested in your opinion).
>>
>> ha,<g> the raining seems to stop!
>>
>> 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.
>
>
>
> --
> Serge Stinckwich
> UCBN & UMI UMMISCO 209 (IRD/UPMC)
> Help fight Ebola by joining the Computing for Ebola Challenge
> http://bit.ly/1oEdBag

HwaJong Oh

Re: configuration inconsistency

In reply to this post by SergeStinckwich

Sorry for not responding for so long. I wasn't paying attention to this mailing-list. Deep appologies.

I've read the issues and working on it.

Best Regards,

HwaJong Oh

2014년 11월 18일 화요일 오전 1시 39분 44초 UTC+9, Serge Stinckwich 님의 말:

Werner, I'm a bit confused.
What should we do now to solve this ?

HwaJong Oh apparently you are not the mailing-list ?

Regards,

On Sat, Oct 11, 2014 at 12:51 PM, werner kassens <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="cewJq3eL2aMJ" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">werne...@...> wrote:

> Hi,
> the config is not in the best state. probably out of politeness Oh did not
> change the development version to the new baseline. but, if one would modify
> the development version accordingly, nothing would change as in this form
> the new baseline would not load StatPseudoCollections. if one wants to
> correct that, one has essentially two possibilities depending on in which
> group at which position one puts StatPseudoCollections:
> assumed one puts StatPseudoCollections last, you'll have red tests in
> math-dhb-numerical, since it will be partly overwritten by dhb-hfm. trying
> to repair that in math-dhb-numerical does not make any sense at all. as i
> already said, the most clever solution would then be to use dhb-hfm
> directly.
> assumed one puts StatPseudoCollections first, then all tests will stay
> green, since then dhb-hfm will be overwritten by math-dhb-numerical and
> there are not too many tests in StatPseudoCollections that show the problems
> there, but you'll have other more hidden problems:
> 1. nothing in the config would signal that this sequence of loading is
> necessary, and i wouldnt rely on the silent assumption that this will always
> be the case in the future.
> 2. - excuse me if i state the obvious - but a config is not only used to
> load a complete project but also to load singular packages with their
> dependencies. if somebody downloads math-dhb-numerical, does some
> programming with it, then loads StatPseudoCollections, the result will
> almost surely be that his program will produce strange numbers if matrices
> are used anywhere (and they are used a lot in dhb).
> 3. another possible scenario where this reverse sequence of loading can
> happen: lets say an old SciSmalltalk image is updated to a new version.
> 4. in the above scenarios, most methods of math-dhb-numerical are then in
> dhb-hfm. if somebody wants to correct a bug in math-dhb-numerical (<g>
> perhaps produced by this mixups), he changes dhb-hfm instead. this can lead
> to all kinds of problem-scenarios, that could eventually be difficult to
> sort out.
> 5. StatPseudoCollections would need some work and perhaps a few more tests.
> as a simple example, if you run the critics-browser on daliot you see 18
> messages sent but not implemented, iow those messages would just produce a
> dnu. and i dont understand why a scientific library would need many of the
> implemented but unused messages. and even when they are used it would often
> be more efficient to use standard pharo messages instead.
>
> btw i would agree, that it looks rather idiotic to think about such a simple
> thing in such a lengthy way <g>, but then it rains outside. nevertheless i'd
> appreciate some feedback (hi Oh, should you be on holidays, i <friendly
> grin> understand your non-reaction, i also dont write emails when i'm on
> holiday, people just have to wait a bit in that case. but let me say that
> i'd be interested in your opinion).
>
> ha,<g> the raining seems to stop!
>
> 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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="cewJq3eL2aMJ" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">scismalltalk...@googlegroups.com.
> For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" onmousedown="this.href='https://groups.google.com/d/optout';return true;" onclick="this.href='https://groups.google.com/d/optout';return true;">https://groups.google.com/d/optout.

--
Serge Stinckwich
UCBN & UMI UMMISCO 209 (IRD/UPMC)
Help fight Ebola by joining the Computing for Ebola Challenge
<a href="http://bit.ly/1oEdBag" target="_blank" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2Fbit.ly%2F1oEdBag\46sa\75D\46sntz\0751\46usg\75AFQjCNGuUHhHv3eCFceghapVn0bzsUpiww';return true;" onclick="this.href='http://www.google.com/url?q\75http%3A%2F%2Fbit.ly%2F1oEdBag\46sa\75D\46sntz\0751\46usg\75AFQjCNGuUHhHv3eCFceghapVn0bzsUpiww';return true;">http://bit.ly/1oEdBag

HwaJong Oh

Re: configuration inconsistency

In reply to this post by werner kassens-2

If I'm remembering correctly, there is one stupid reason StatPseudoCollections is requiring Dhb, that is to use #removeAtIndex: method. StatPseudoCollections and its prerequisit packages were implementation its own #removeAtIndex: but later found out it is colliding with Dhb's implementation. So, I decided to _use_ Dhb.

I wasn't very happy to use relatively large package just because of that tiny reason but Dhb's #removeAtIndex: seem efficient utilizing characteristics of OrderedCollection so it seem better than mine. So, I decided to user Dhb.

If I work around not to use #removeAtIndex, the problem can be solved nicely.

Best Regards,

HwaJong Oh

2014년 10월 11일 토요일 오후 7시 51분 21초 UTC+9, werner kassens 님의 말:

Hi,
the config is not in the best state. probably out of politeness Oh did not change the development version to the new baseline. but, if one would modify the development version accordingly, nothing would change as in this form the new baseline would not load StatPseudoCollections. if one wants to correct that, one has essentially two possibilities depending on in which group at which position one puts StatPseudoCollections:
assumed one puts StatPseudoCollections last, you'll have red tests in math-dhb-numerical, since it will be partly overwritten by dhb-hfm. trying to repair that in math-dhb-numerical does not make any sense at all. as i already said, the most clever solution would then be to use dhb-hfm directly.
assumed one puts StatPseudoCollections first, then all tests will stay green, since then dhb-hfm will be overwritten by math-dhb-numerical and there are not too many tests in StatPseudoCollections that show the problems there, but you'll have other more hidden problems:
1. nothing in the config would signal that this sequence of loading is necessary, and i wouldnt rely on the silent assumption that this will always be the case in the future.
2. - excuse me if i state the obvious - but a config is not only used to load a complete project but also to load singular packages with their dependencies. if somebody downloads math-dhb-numerical, does some programming with it, then loads StatPseudoCollections, the result will almost surely be that his program will produce strange numbers if matrices are used anywhere (and they are used a lot in dhb).
3. another possible scenario where this reverse sequence of loading can happen: lets say an old SciSmalltalk image is updated to a new version.
4. in the above scenarios, most methods of math-dhb-numerical are then in dhb-hfm. if somebody wants to correct a bug in math-dhb-numerical (<g> perhaps produced by this mixups), he changes dhb-hfm instead. this can lead to all kinds of problem-scenarios, that could eventually be difficult to sort out.
5. StatPseudoCollections would need some work and perhaps a few more tests. as a simple example, if you run the critics-browser on daliot you see 18 messages sent but not implemented, iow those messages would just produce a dnu. and i dont understand why a scientific library would need many of the implemented but unused messages. and even when they are used it would often be more efficient to use standard pharo messages instead.

btw i would agree, that it looks rather idiotic to think about such a simple thing in such a lengthy way <g>, but then it rains outside. nevertheless i'd appreciate some feedback (hi Oh, should you be on holidays, i <friendly grin> understand your non-reaction, i also dont write emails when i'm on holiday, people just have to wait a bit in that case. but let me say that i'd be interested in your opinion).

ha,<g> the raining seems to stop!

werner

HwaJong Oh

Re: configuration inconsistency

Reporting:

I've updated ConfigurationOfSciSmalltalk.

install by running

ConfigurationOfSciSmalltalk project lastVersion load: 'StatPseudoCollections'.

I got test result of 576 run, 576 passes, (both my tests and Math- tests)

I took care to put it as a development version, not to affect the stable version.

Best Regards,

HwaJong

SergeStinckwich

Re: configuration inconsistency

On Tue, Nov 18, 2014 at 12:48 PM, Hwa Jong Oh <[hidden email]> wrote:

> Reporting:
>
> I've updated ConfigurationOfSciSmalltalk.
>
> install by running
>
> ConfigurationOfSciSmalltalk project lastVersion load:
> 'StatPseudoCollections'.
>
> I got test result of 576 run, 576 passes, (both my tests and Math- tests)
>
> I took care to put it as a development version, not to affect the stable
> version.

Thank you HwaJong for taking care of that.

There is currently two concerns with your code:
- tests are not in a separated packages. Could you modify the name of
your packages as Math-X and Math-Tests-X so you tests can be run
automatically from the CI server ?
- I don't understand the name CodeBook ?

Regards,
--
Serge Stinckwich
UCBN & UMI UMMISCO 209 (IRD/UPMC)
Help fight Ebola by joining the Computing for Ebola Challenge
http://bit.ly/1oEdBag

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

HwaJong Oh

Re: configuration inconsistency

2014년 11월 18일 화요일 오후 9시 5분 19초 UTC+9, Serge Stinckwich 님의 말:

On Tue, Nov 18, 2014 at 12:48 PM, Hwa Jong Oh <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="67WfxD5eCd4J" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">dali...@...> wrote:

> Reporting:
>
> I've updated ConfigurationOfSciSmalltalk.
>
> install by running
>
> ConfigurationOfSciSmalltalk project lastVersion load:
> 'StatPseudoCollections'.
>
> I got test result of 576 run, 576 passes, (both my tests and Math- tests)
>
> I took care to put it as a development version, not to affect the stable
> version.

Thank you HwaJong for taking care of that.

There is currently two concerns with your code:
- tests are not in a separated packages. Could you modify the name of
your packages as Math-X and Math-Tests-X so you tests can be run
automatically from the CI server ?
- I don't understand the name CodeBook ?

CodeBook is a numerical system, digits of which are not bounded to Numbers.

print-it following lines to grasp what it is.

CodeBook of: {0. 1} length: 3.

CodeBook of: {'zero'. 'one'} length: 3.

CodeBook of: {0. 'one'. 2. 'three'} length: 3.

CodeBook of: {0. 'one'. 2. 'three'} length: 2.

CodeBook of: {0. 'one'. 2. 'three'} length: 1.

I'm not sure what made me to name it CodeBook. But, I guess Code comes from the code when we say BCD or gray code.

The Book means collection or set. Thus, CodeBook. I hope someone come up with better name than this.

Regards,

HwaJong Oh