Waldek Hebisch <[EMAIL PROTECTED]> writes: > 1) Split chunks: Spad contains no end markers, so to know that for > example function definition is complete one has to see _next_ > function or end of file. With current Spad usage normally (except > for guessing package) also end of chunk means that give construct > is complete. Widespread use of split chunks would break this > useful property.
I agree mostly. Only, in my opinion the right way to change is to change the SPAD parser to Aldor syntax. Meanwhile, I'd like to localise splits as much as possible. I'm quite happy with the situation in trigcat now, especially after your suggestion to keep list of exports togehter. > 2) Category definitions should be relatively stable, while new > tests may be added at any time. If tests are kept together > with algebra adding tests can break build process (say due to > wrong noweb markers). In practice it means that before > commiting a test one has to do full rebuild. With separate > tests it is enough to just re-run tests. Yes. Locally one can simply modify, say TEST-FUNCAT.input, until tests "work". To commit, one has to rebuild. I think a full rebuild should not be necessary, but in my experience, it is a good thing to do anyway. And build time will decrease in future anyway, I'd guss. > It also makes harder to track changes to categories. Don't understand this one. > 3) In practice we test domains and packages: while some functions > are implemented in categories we can test them only via domains. > Also, good test _should_ depend on implementation: we should test > for known/suspected weak spots of implementation, we should aim > for full coverage... Putting tests in categories moves > implemention information into wrong place. I'm quite sure that this is not true. Tests should *not* know about implementation, because otherwise I'll possibly unconsciously test only things that work anyway. (Happened to me once...) > Point 3) may suggest that test should go into domain/packages. > This has some merits, but with our current machinery we still > have problems 1) and to some degree 2). No, certainly not. (except for packages and operations that are not "categorical") > So, I would put tests in input subdirectory, either in a > sparate file or in some existing file (AFAICS > elemfun.input.pamphlet would be the correct file). I *really* want to have docstring and test close to each other. > Now for FriCAS I would like to ensure "forward progress". To > explain this: there are two dangers for the project. One is > that changes made by project members either go backwards or > cancel each other. The other is that real work is blocked > by discussions or excessive control. Yes, I agree. > Concerning trigcat, some parts of change looks undesirable (as > explained above), other are positive. If change is limited to > trigcat, then probably this is not worth long discussion -- > just go on. > OTOH, if you plan more changes of this sort I would ask you to > reconsider. Hm, yes, I plan more changes of this sort. I see two possible compromises: 1) we have a branch, where I structure files as I currently envision. trunk contains the input file already extracted in src/input. 2) I commit this change, and we rediscuss before the next change (which will possibly be power series, and will probably *not* happen in near future.) In case of (1), please set up a branch. I'm extremely grateful for your way of cooperation! Martin --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~----------~----~----~----~------~----~------~--~---
