axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Axiom-developer] Re: noweb "bug" (was: article "standard" header/footer


From: root
Subject: [Axiom-developer] Re: noweb "bug" (was: article "standard" header/footer)
Date: Tue, 13 Dec 2005 20:17:25 -0500

re: noweb bug

   i don't agree with Norman. *I* consider it a bug.
   especially so since Ralf fixed the same "feature" independently.
   noweb does the wrong thing with certain non-chunks.
   if the chunk isn't in the hashtable complain and continue.

   i diagnosed the bug, fixed it, and sent off a diff -Naur patch.
   which is exactly the way open source is supposed to work.
   Norman disagreed with my patch and rejected it. that's his call.
   which is exactly the way open source is supposed to work.
   but we still NEED the patch. Axiom won't build without it.
   so we get the UNMODIFIED sources, apply the patch, and build.

re: awk

   since i don't write awk (but you do) i find the awk script unreadable.
   it really ought to be documented. we had this discussion before when
   you wrote awk scripts into the makefile. awk is linenoise to me and
   i hate having to learn a whole new language to maintain 8 lines of code.

   this may be an acceptable way to fix the "feature" but i'm unclear
   when and how to apply awk/gawk/nawk scripts to noweb. i looked at
   the filtering thing but since it is all in awk/nawk/gawk it made no 
   sense. if it was so clear why didn't Ralf apply Norman's awk code?
  
   does this work with awk/nawk/gawk? all three? already i have to 
   customize the build scripts because of this trivial feature. it's
   the ONLY shell variable besides AXIOM that needs to be set before
   the system build begins. bug #1 on MACOSX is the lack of nawk/gawk.

re: gcl

   if it helps, think of it as automating a cvs get for the version we want.
   we get the UNMODIFIED sources and apply axiom-specific patches.
   we'll still need a patch mechanism otherwise the browser, sman, and
   graphics are broken. yet the axiom lisp patches will *never* be part
   of EVERY lisp distribution, not even part of GCL.

   an alternative is to modify GCL to support UFFI (Universal Foreign
   Function Interface) and modify Axiom to use it. I looked at this
   path and it is a lot of work. When Axiom goes ANSI it'll have to
   be done but that's still a long way in the future and GCL may have
   UFFI by then. Only a few other common lisps support UFFI so far.

re: forking

   you seem to feel that maintaining axiom-specific patches to standard 
   distributions (we use the standard tgz files as a base) is equivalent
   to forking a distibution. my definition of forking differs. in my
   view we are not forking. we are fixing axiom-specific bugs. we don't
   claim to distribute common lisp or GCL or noweb or anything but Axiom.
   we don't even claim that OUR version of noweb works for anyone else.
   we don't distribute a patched version on websites, we don't advertise
   that ours is better/faster/sexier. we're not trying to compete.

   GCL and noweb sources in axiom are EXACTLY as distributed and could
   (in a more perfect world) be fetched from CVS automatically. that's
   hardly a fork. GCL and noweb need source-level patches to work.



re: advocacy

  ok. you're advocating a change. that's good. but advocacy is volunteering
     - check out a --patch-46 copy of the system, 
     - make the changes, 
     - document the changes,
     - test them,
     - test the whole system build,
     - "diff -Naur old new" to create the patches
     - mail the patches to me, one set for noweb, one set for gcl. 
     - i'll apply them and test them
     - we'll discuss the results
     - i'll add them to the main sources

  sending documented, running, and debugged code that "just works" goes
  a long way toward winning the argument. complaining that i'm doing
  it wrong and expecting me to do the work isn't nearly as effective.
  at best if i agree with you i'm likely to add it to an already
  overlong queue. if i disagree with you and your code works it is
  much more likely to be included (witness the awk script already
  in the Makefile).

re: fixing working code

  the system build works. i can see hundreds of things in Axiom that
  need fixing but GCL and noweb aren't on that list (at least for me).
  basic functionality in Axiom is still broken (like ")cd" or ")hd") 
  and are MUCH higher on the todo list. 

  i'd much prefer that you try to tackle something like the Hyperdoc
  browser since you're advocating redoing the front end to use firefox.
  why not take the lead on Volume 8: Hyperdoc? it needs to be documented
  and we need to understand it so we can redesign/rewrite it. you have
  more ideas in that direction than anyone else.

t




reply via email to

[Prev in Thread] Current Thread [Next in Thread]