Ondrej,
>And with this perspective, I think (again just my opinion) that even
>if you want to optimize the project over 30 years, the strategy is
>wrong too, because it's imho essential that people join the
>development. I think the best strategy is to optimize for the needs
>and opinions of poten
Ondrej,
>So one should then ask - do I want to create a project that most of the
>people would agree with the course of development (strategy of fixing
>bugs)? Or do I want to create a project that most people disagree with
>the strategy, but maybe in 30 years there is some chance that axiom
>w
Ondrej,
>because my personal opinion is, that many people want to know the
>strategy behind the project. Also, I think, but maybe I am wrong, that
>most people prefer the "fix it now, instead of tomorrow" strategy.
Yes, they do prefer that strategy. But they don't support it.
How many diff-Naur
Ondrej,
>I think this should be written on the front page of the axiom project,
It is all over the project. What would be the point of literate
documentation, indeed, of using noweb at all, if you didn't plan
to do literate programming? You'll find very few files in Axiom
that are not literate do
On Jan 21, 2008 9:30 PM, root <[EMAIL PROTECTED]> wrote:
> >>Suppose you have software A which has very few documentation and it has
> >>a bug B.
> >>
> >>You can produce from that two systems A1 and A2.
> >>
> >>A1: Fix the bug today. Fix the documentation in 1 year.
> >>A2: Fix the bug together w
>>Suppose you have software A which has very few documentation and it has
>>a bug B.
>>
>>You can produce from that two systems A1 and A2.
>>
>>A1: Fix the bug today. Fix the documentation in 1 year.
>>A2: Fix the bug together with the documentation in 1 year.
>>A3: Fix the bug today. Fix or don't
>> Take, for instance, bug 370. There the original bug fix was to change the
>> algebra code from (something like)
>>
>> f(a+b)
>>
>> to
>>
>> c:=a+b
>> f(c)
>>
>> When I went to apply this patch it didn't look right. But there was no
>> documentation about what the patch was intended to
root <[EMAIL PROTECTED]> writes:
> Take, for instance, bug 370. There the original bug fix was to change the
> algebra code from (something like)
>
> f(a+b)
>
> to
>
> c:=a+b
> f(c)
>
> When I went to apply this patch it didn't look right. But there was no
> documentation about what the
>I know that documentation is one of the most important things for the
>Axiom project, but your approach to fixing bugs is just strange.
My approach to code development in Axiom is strange. But I'm fighting
against the "get it done" crowd and trying to go for "get it right"
and "get it documented
Hi Tim,
I know that documentation is one of the most important things for the
Axiom project, but your approach to fixing bugs is just strange.
Suppose you have software A which has very few documentation and it has
a bug B.
You can produce from that two systems A1 and A2.
A1: Fix the bug t
If you'd like to see bug fixes applied to Axiom please submit a
diff-Naur patch against silver.
Bugs are being fixed. Look for patches that have trailing numbers
in the title. One of the numbers is the Axiom bug number and, if
there is a corresponding published bug, there is a second number
corre
see subject,
there remain 114 open items in categories Axiom
Compiler/Library/Interpreter/Documentation/User Interface, not counting
wishlist items.
Sorting by Category, one sees immediately a few bugs, namely #149, 145, 129,
36, 321, 320 which should probably be "fixed in FriCAS" (and maybe else
12 matches
Mail list logo
