doyencd-developer — Developers discussion list

[Doyencd-developer] doyen progress?

[<da...@ax...>]

What's the state of the state? Is there new documentation?
Is there a CD image somewhere?

I'm leaving for Pittsburgh on thursday and will be in a business
meeting in Washington next week (the week of the 4th). I'll be
moving the week of the 11th. I hope to be able to read/write email
occasionally but my whole compile farm will be shut down and boxed.

t

[Doyencd-developer] news?

[<da...@ax...>]

any news? any new documentation? --t

[Doyencd-developer] fear mongering

[<da...@ax...>]

> Tim, I really think you are just "fear mongering"! In fact most
> of the things you mention are already possible in a browser
> like Mozilla very little or no any additional Javascript coding.

ok. perhaps i don't know enough about the subject and the recent
advances in browsers so i'll go relearn some javascript in mozilla
before continuing on this thread. i'll try to get axiom to start
mozilla and draw a graph in a page (the graphics functionality)
and see what works. 

t

[Doyencd-developer] RE: axiom, browsers, and crystal

[Page, B. <Bil...@dr...>]

On Monday, June 20, 2005 11:48 PM Tim Daly wrote:

> i agree standards are a *good thing*(TM) but standards come
> after practice, not before.

On the contrary, many standards have value even though they
may never be put into practice. Standards (should) drive design.
But standards are meant to be broken (and then fixed, again
and again).

> when they come before practice they are generally large,
> expensive, and overbuilt (e.g. XML)

In what sense do you think XML is expensive or overbuilt? The
syntax of XML consists of just three production rules.

  xml :== tag [ xml | value ] /tag
  tag :== <name [att]>
  att := name=value

where [ ] means optional and | means alternative. The rest is just
semantics and that gets complicated no matter what language you
choose.

> i agree that browsers are a good thing. they are platform
> independent, use standards, and allow marvelous things to happen.
> or not. in particular they explicitly do not allow themselves to
> be used as a useful front-end for local programs.

Have you used a Linux desktop lately? If you have, chances are you
have probably already used a browser as a front-end for local
programs and not even known it. Web browser front-ends are also
becoming very popular for embedded applications like network routers,
printer configuration. One of the most popular web browser front-ends

http://www.webmin.com

provides a complete system management interface for Linux servers.

> ...

think about what we want. we want a portable front-end to axiom
that we can extend in various ways to do truly cool NEW things.

Agreed.

> we want the end user of axiom (the spad programmer) to be able
> to make the front-end do truly cool NEW things.

I am not sure that "spad programmer" is a good description of
the Axiom end user since I expect many people will use Axiom
without programming in spad. But I agree that the gui front-end
needs to be easily accessible to the more ambitious Axiom
programmer.

> we want our documentation (pamphlets) to be magic drag-and-drop,
> clip and execute, inline moving graphics, managing multiple
> programs like axiom, our graphics, ACL2, and other tools.

Agreed.

> We want to be able to save state back into a representation
> that axiom and the front-end can both use.

I think the separation between the front-end state and axiom
state is undesirable. State is something that Axiom should
manage. The front-end just needs to be able to render that
state accurately in a variety of visual/audio/tactile ways.

> ...
> yes, you can do some of those tricks with acres of javascript,
> special certificates, plugins, cookies, and other hacks. but
> think of all of the code you have to write in javascript, html,
> xml, C, etc. it will only get MUCH worse as you try to write
> javascript to read the semantic network problem data structure
> and render the appropriate html.

Tim, I really think you are just "fear mongering"! In fact most
of the things you mention are already possible in a browser
like Mozilla very little or no any additional JavaScript coding.
JavaScript is mostly required just to provide the glue.

> javascript is a horrible language and we have two great languages
> (spad and lisp).

I am not at all fond of Java in general. JavaScript is just a
dialect of Java specialized for the browser API. I don't think
that it is any worse than Java in general. And Java has been
touted as a kind of "lisp for C programmers"... well, I wouldn't
have exactly said that, but it can't be that bad given the effort
spent on it's development and the amount of open source code that
is available in java.

> i'd agree with your approach if we could do something like graph
> the algebra hierarchy without a ton of java and a plugin or draw 
> a graph on a tab from lisp. 

Well, as you know TouchGraph (a Java application integrated with
the MathAction website) can already do a credible job of graphing
and navigating a complex network.

Kai has demonstrated that drawing a graph using SVG on a browser
can be done with a few hundred lines of GCL lisp code.

> ...

Sigh. The debate wears thin ... :)

Regards,
Bill Page.

[Doyencd-developer] RE: [Axiom-developer] axiom, browsers, and crystal

[Page, B. <Bil...@dr...>]

On Tuesday, June 21, 2005 12:17 AM Tim Daly wrote:

> i am trying to avoid 1.2 million lines of javascript with browser
> dependent ifdefs.  we already have that problem with C.

I agree. For desktop use we can easily standardize on one browser.
I recommend Mozilla's FireFox. Except for jsMath which is provided
by another project, I don't expect a browser-based interface to
Axiom to require more than a few hunderd lines of JavaScript.

> instead of trying to work "on top" of the browser, which limits our
> abilities to the current available set, i'm trying to think of it
> as a large library of code we can exploit in new ways.

Because of the DOM api and extensions, it is possible to work with
the browser "as a large library of code" without having to get
inside.

> and the careful choice of a lisp available API would make the
> browser more useful as a front end and be less maintenance in
> the long run.

As pointed out in another email, it is possible that a lisp API
for the Mozilla browser will be implemented by other developers.
If it exists we could in principle use it instead of JavaScript.
I would expect it to be some time before it was a stable as the
current JavaScript API.

> we want to do everything the browser does (because people use
> them) but locally we want to do so much more. restricting ourselves
> to require a network and vanilla browser code severely limits the
> possible creative choices.

For desktop use no network is required.

I would not characterize Mozilla as simply a "vanilla browser". It
has a lot of provisions for plug-ins and extensions.

For access to a Doyen-like server over the web, I think we may
have to be more flexible with the choice of browser.

Regards,
Bill Page.

[Doyencd-developer] Re: axiom, browsers, and crystal

[Bob M. <bob...@mc...>]

da...@ax... [da...@ax...] wrote:
> i am trying to avoid 1.2 million lines of javascript with browser
> dependent ifdefs. we already have that problem with C. instead of
> trying to work "on top" of the browser, which limits our abilities
> to the current available set, i'm trying to think of it as a large 
> library of code we can exploit in new ways. and the careful choice
> of a lisp available API would make the browser more useful as a
> front end and be less maintenance in the long run.

No browser-dependent code.  Pick a browser.  Sorry folks, no
IE/Opera/Safari.  Mozilla is free and people who want to use Axiom will
have to install it.

> we want to do everything the browser does (because people use them)
> but locally we want to do so much more. restricting ourselves to 
> require a network and vanilla browser code severely limits the possible
> creative choices.

Not vanilla.  I don't want to have anything to do with browser detection
or making it work in more than one browser.

The ability to independently address parts of the document is very
powerful.  In essence, the browser provides interaction with output math
for us.  We can attach javascript to MathML and know which element the
user clicked on after he clicked the "simplify" button.  We can have a
"show integers" button that will turn the variable "i" red.  We can
"hide output".  We can have mouse-overs indicate the domain of the
object under the mouse cursor.

All of the important user-interaction fundamentals are there.  The
entire mozilla API is accessible from javascript.  Output rendering is
there (jsMath or MathML).  Input editing is there.  Documentation in the
form of hyperlinks and mouse-overs is there.

It seems to me that the options are:
1) Build the math into the browser
2) Build the browser into the math

If a new C++ application is created which embeds the necessary mozilla
components, it will still require javascript ties to user interface
elements.  One step at a time... ;)

--
Cheers,
Bob McElrath [Univ. of California at Davis, Department of Physics]

    "One of the best ways to get yourself a reputation as a dangerous citizen
    these days is to go about repeating the very phrases which our founding
    fathers used in the great struggle for independence." --Charles A. Beard

[Doyencd-developer] axiom, browsers, and crystal

[<da...@ax...>]

i'm currently working on making the ISSAC Proceeding CD so i can't 
check out your references at the moment but i will as soon as i can.

i did want to respond to your comment that you didn't think discussion
was useful and that we need running code....

i think the focus on running code is great and i'm a great believer
in "making it work" but in this case i'm trying to raise the discussion
and our eyesight toward the 30 year horizon. 

i am trying to avoid 1.2 million lines of javascript with browser
dependent ifdefs. we already have that problem with C. instead of
trying to work "on top" of the browser, which limits our abilities
to the current available set, i'm trying to think of it as a large 
library of code we can exploit in new ways. and the careful choice
of a lisp available API would make the browser more useful as a
front end and be less maintenance in the long run.

we want to do everything the browser does (because people use them)
but locally we want to do so much more. restricting ourselves to 
require a network and vanilla browser code severely limits the possible
creative choices.

i want people to see axiom do things and get excited about doing more.
so far there is very little i've seen "on the net" that gives me that feel.
i want what i call the "knoppix" reaction.... klaus knopper modified a
standard distribution, made it bootable, and as a result i'm now trying
to build the doyen project. 

anyway, we need to think about the 30 year horizon and what we want when
get there. thus, the discussion.


back to the grind...

t

[Doyencd-developer] axiom, browsers, and crystal

[<da...@ax...>]

we're debating, not disagreeing. although you're clearly wrong :-)

i agree standards are a *good thing*(TM) but standards come after practice,
not before. when they come before practice they are generally large,
expensive, and overbuilt (e.g. XML)

i agree that browsers are a good thing. they are platform independent,
use standards, and allow marvelous things to happen. or not. in particular
they explicitly do not allow themselves to be used as a useful front-end
for local programs.

i agree that we don't want to re-invent the world and that we want to
follow standard practice. However i disagree that we should work solely
within standards.

what i see us doing is using cheesey work-around languages like javascript
and badly designed data structures like DOM. we're going to end up with
  (a) a program that is "more of the same"
  (b) is in a hard to maintain language that isn't very portable
  (c) hamstrung by the standard-per-browser problem
  (d) encoding our information in latex -> XML -> javascript hacks
  (e) unable to "really communicate" with the user thru the browser
  (f) bending the world to fit the doorway
  (g) unable to start local programs, save state, really interact

think about what we want. we want a portable front-end to axiom that
we can extend in various ways to do truly cool NEW things. we want the
end user of axiom (the spad programmer) to be able to make the front-end
do truly cool NEW things. we want our documentation (pamphlets) to be magic
drag-and-drop, clip and execute, inline moving graphics, managing multiple
programs like axiom, our graphics, ACL2, and other tools. We want to be
able to save state back into a representation that axiom and the front-end
can both use.

current browser technology won't allow us to "extend" it in various ways
(such as making one of the tabs be an axiom shell session). it won't 
read and write pamphlet files (inline latex, inline chunks). it won't
allow drag-and-drop of pamphlets. it can't start or manage local programs.
it can't handle giving up screen real estate as canvas areas. it can't
write to the file system, etc.

yes, you can do some of those tricks with acres of javascript, special
certificates, plugins, cookies, and other hacks. but think of all of
the code you have to write in javascript, html, xml, C, etc. it will
only get MUCH worse as you try to write javascript to read the semantic
network problem data structure and render the appropriate html. javascript
is a horrible language and we have two great languages (spad and lisp).

i'd agree with your approach if we could do something like graph the
algebra hierarchy without a ton of java and a plugin or draw a graph
on a tab from lisp. 

i can almost envision the C code necessary to start axiom (or some other
program) from the browser, hand it the screen area of a tabbed pane, and
present an API from the browser code to draw. if it is 1000 lines i'd
be astonished. all the cross-platform work is already done.

use the browser, keep the standards. but extend the tool to do what you want.
i don't change GCL, i simply extend it to be useful. 
i don't change noweb. i simply add functionality i need.
we won't change the browser, we just need to extend it to be useful.

think of the browser as having solved the cross-platform problem and as
a large library of useful code. now we want to make it sing and dance
to our new ways of thinking. we still do what a browser does (we have
the same base code) but we do so much more.

t

[Doyencd-developer] copy of note to axiom-developer mailing list

[<da...@ax...>]

From: da...@ax...
Date: Mon, 20 Jun 2005 18:35:08 -0500
To: bil...@sy..., kai...@gm..., ca...@en...,
   mar...@un...
Subject: axiom, browsers, and crystal

taking this discussion away from the short term summer of code 
so we can think about the bigger issues.....

in the long term (the 30 year horizon) it seems clear that some
sort of browser-like capabilities are assumed. the limitations we
have now seems to be things like:

*  the syntax of the web page does not have a semantic model

we're trying to build a research science platform, not a display GUI object.
we'd like the GUI piece of the system to have a clean, programmable semantics
so we can reason about user actions. we want to reflect user actions (say
handwriting, gestures, clicks, eye-gazes) and system state (say branch cut
crossings, solid model data structure stresses, hill climbing search progress,
as subtle changes to the screen. 

Think of a search space program that does hill climbing (or root finding, 
or ...) that presents it's current state on the system. The user gaze
shifts to various areas and the gaze tracking hardware gives us a vector
for a direction to explore.

*  the DOM model is hierarchical

the DOM is a Document Object Model. it's basically a hierarchical data
structure and it suffers from the same problems that databases used to
suffer, that is, the hierarchy. Hierarchical databases ruled the day
until new theory came around and the world went relational (I know most
of you don't remember it but there was a HUGE fight about this. I attended
a committee meeting about this at a database conference and the major
objection was there would never be enough horsepower or memory to handle
relational searches... beware the future).

*  the DOM model is not really math-aware

i'd envision the DOM being a surface-level representation of the actual
data structures used. the DOM would be available in one of the facets
of the crystal, possibly to support old browsers. there are much more
useful and efficient data structures for representing problem spaces,
state spaces, and system state.

*  the browser cannot interact with the filesystem
*  the browser pages cannot be drawn upon
*  the browser pages are "paper-like"

the browser is a dumb tool at the moment. we need to break out of the
mold, pick a particular browser, and make our own version of it. our
version can be modified to do read/write of the file system, handle
socket connections, present tabbed pages or sub-areas as an active
canvas so Axiom can write graphics or text to them in real time, present
a section of the screen as command-line I/O, show axiom state in special
tabs, allow the browser to start axiom, let it speak lisp, etc.

in short, we need to stop struggling with the limits of current browser
technology, take a standard browser and extend it to our purposes. in
fact, i expect we could do what we do with GCL: package our own version
from a tgz file and add patches to do what axiom needs.

in the 30 year horizon we need something that is useful, impressive,
and reasonably modern. today's tools just hint at what will be common.
we need to listen to the hints, anticipate the needs, and get out in front.
the term i've been using is a "crystal" which is an object with many facets
that "floats" around a central problem description in its own representation.

we need to think about the researcher's problem space in a much deeper
form than current systems do (including Axiom). in the long term we want
to be at the center of the tool set that researchers use to solve problems.

research is long-term, detail-tedious, and takes a lot of work to build
up a big picture. we want to be able to capture problem state, suggest
relevant papers, perform proofs in the background, do speculative 
computations for possible suggestions, pre-generate literate pamphlets
with references and code, etc. we want to draw a wide range of tools
together (math language, graphics, 3D models (organic, engineering, etc),
full-text searches, collaborative tools, etc).


related to the current suggestions i think we are limiting ourselves too
much and creating too tight a straight-jacket by trying to work within
the limits of current browsers and MMA-like worksheets.

choose a browser, get the source, add it to axiom, and extend it in various
ways so we can experiment with ideas. just making it possible for the browser
to read/write the filesystem and present a "canvas" area to axiom puts us
far ahead of the world. it's not ideal but it works.

t

[Doyencd-developer] livecd.iso

[<da...@ax...>]

*,

I booted the fedora livecd.
Works fine.

Is Axiom or the wiki software on here?

Tim

[Doyencd-developer] status

[<da...@ax...>]

What's the current state?
Can I use the CVS to download the files and instructions?

t

[Doyencd-developer] Re: wiki

[Michael S. <ms...@MI...>]

Tim,

The wiki that I put together is not running on a Doyen disk. It is a test
server wiki for us to use running on a machine in the room. Wilken, Jose,
and I have had a bunch of discussions lately as to what the purpose of the
local wiki is. Since I've found you on email, let me ask you:

We understand that the goal is to tangle and weave a pamphlet file on the
local disk. We see that we wil have the .pamphlet files on a server wiki,
then we will "drag and drop" the file onto the local disk. Then, we need a
script that will automatically run, tangling and weaving the file. It will
open the latex documentation in one window and run the code in another.
Our question is where the local wiki has to come in. We see this as
completely doable with apache and a few shell scripts.

What do you think?

-- Michael

------------------------

Michael Shaw
MIT, Class of 2007
Email: MS...@MI...
Cell: (917) 841 -- 8863

On Mon, 13 Jun 2005 da...@ax... wrote:

> Michael,
>
> Is your wiki code running on a bootable CD?
> If so, there must be more to the instructions than just the zwiki piece.
> It's important that you document how you made this work.
>
> Also, upload the tgz file for the zope and zwiki parts so we can keep
> track of which versions we used. We should be able to get all the parts
> from the CVS.
>
> The next step is to contact Bill Page (bil...@sy...) to
> see what code he adds to the zope/zwiki chain.
>
> The primary idea is that someone should be able to drag and drop a
> "pamphlet" page from the axiom wiki to the doyen wiki and have the
> code automatically added to the system.
>
> This has several parts.
>   *) (code theft) we need to understand how Bill created the
>      \begin{axiom}..\end{axiom} technique and make that work locally.
>      Currently we are just using a page that Jose put together but
>      we need to inline the axiom in latex pages
>   *) (autoweb) we need to take a simple pamphlet file with source code,
>      automatically do the tangle and weave.
>   *) (tangle) we need to compile the tangled code and add it to the
>      axiom system.
>   *) (weave) we need to latex the weaved code and add it to the
>      axiom documentation.
>   *) (drag) we need a drag-and-drop kind of mechanism, initially using just
>      a button that ends up invoking wget or some such tool and then
>      applying the previous integration techniques.
>
> t
>
>
>

[Doyencd-developer] RE: doyencd

[Bill P. <bil...@sy...>]

Tim,

On June 13, 2005 2:31 PM I wrote:

> Now, step 4) I am much less sure about. It sounds like the
> hard part to me. If you have ideas about how you are actually
> thinking of doing this, then I am quite interested to discuss
> it. I don't know on any other web-based software that has
> such as "drag and drop" kind of interface.

Now that I think twice about this, I realize that there may
be some not so obvious features of ZWiki that might make this
easier. For example, if you include /src at the end of a
MathAction url, then the "source" text contents of a page
is delivered to you instead of the rendered HTML code. Try
this:

http://page.axiom-developer.org/zope/mathaction/167InfiniteFloatsDomain/
src

Now, *if* there was some "Import" function on the Axiom-wiki
running locally on you laptop, it could use such as "src"
url to retrieve the source contents of a remote page and
clone it locally. This can be easily done with a scripting
command such as 'curl' and a filter to rewrite any absolute
url references.

I could even imagine including this as a standard generic
feature on Zwiki, although normally wiki's assume they
live in a web-enabled environment and such linking is
usually preferred over cloning pages from another site.
Still, in a "research-oriented" wiki like MathAction, the
content is not just a nice web page, but usually includes
complex "work in progress" like mathematics and Axiom
programs. It is conceivable in this case there might be
a number of co-operating private (individual) or semi-private
(per research group) wiki web sites and such a "publishing
and distribution" model might make sense.

Discovering the format of the source, i.e. 'page type' might
also be a little difficult. By default on MathAction right now,
the page type is "Structured Text + LaTeX" which includes the
possibility of \begin{axiom} and \begin{reduce} environments.
But other types are possible such as "HTML + LaTeX" or just
"plain text" (no embedded LaTeX and no axiom).

It has always been our intention some day to have "pamphlet"
as a possible page type on MathAction. I did some work on
implementing this, but it is not complete.

When a new page is saved on MathAction, any contained Axiom
code is executed, including compiling library code so making
the link with Axiom work is simple. The harder part might be
if there were a series of such pages that needed to be imported.
Then one would have to crawl the links. But that is not so hard
to do. On the other hand if some pages contained Axiom code
that depended on other Axiom code being compiled first, getting
these dendencies right and saving the pages in the right order
might be more challenging.

Perhaps one should have a way to code these dependencies
explicitly in the source of the page. You could of course
look for embedded ')library' commands for references to
required library routines, but this information is not
suffient because we don't have anyway to know which other
page on the wiki might contain the source for a given library
routine.

Regards,
Bill Page.

-----Original Message-----
From: da...@ax... [mailto:da...@ax...] 
Sent: June 13, 2005 2:18 PM
To: bil...@sy...
Cc: da...@ax...; doy...@li...
Subject: doyencd

...

  4) implement drag-and-drop from the axiom-wiki to doyen-wiki

If you are in the audience for a talk at the physics conference you
should be able to boot the doyen CD, visit the physics wiki (a
sub-wiki of mathaction?)  and drag-and-drop the speakers paper, which
includes his code, onto your laptop. If this works then every paper
can include code and everyone can get code that is guaranteed to work.

[Doyencd-developer] RE: doyencd

[Bill P. <bil...@sy...>]

Tim,

Yes, of course I am aware of Doyen. I just had no idea who was
doing what. Yes we did talk about this at the Axiom conference
in NYC.

I am not sure I understand your step 3) below. Do you mean
have something equivalent to MathAction on a bootable CD?
That should be a "piece of cake" all you need is to install
Python + PIL, tex, ghostscript, Zope, ZWiki, LatexWiki and
20 or 30 lines of Python code from the MathAction site... :)

Now, step 4) I am much less sure about. It sounds like the
hard part to me. If you have ideas about how you are actually
thinking of doing this, then I am quite interested to discuss
it. I don't know on any other web-based software that has
such as "drag and drop" kind of interface.

Regards,
Bill Page.


-----Original Message-----
From: da...@ax... [mailto:da...@ax...] 
Sent: June 13, 2005 2:18 PM
To: bil...@sy...
Cc: da...@ax...; doy...@li...
Subject: doyencd


Bill,

My apologies. I thought we'd talked about the doyen project.

There are 3 students at City College who are working on
making a Live CD (aka Knoppix) that includes a range of computer
algebra systems and a wiki. It is a 4 layered problem.
   
  1) make a live cd
  2) add computer algebra software
  3) make a axiom-like wiki that uses the software
  4) implement drag-and-drop from the axiom-wiki to doyen-wiki

You can see more details at daly.axiom-developer.org/doyen

We've got the first two parts working and now we need to clone the
axiom-wiki technology. 

We am working with RedHat on this project and we want them to distribute
free doyen CDs at various science conferences. The initial build is
going to be computer algebra but once we get the concept working we
plan to do one for physics later this summer. Then RedHat can go to
a physics conference and give out the doyen CDs. 

If you are in the audience for a talk at the physics conference you
should be able to boot the doyen CD, visit the physics wiki (a
sub-wiki of mathaction?)  and drag-and-drop the speakers paper, which
includes his code, onto your laptop. If this works then every paper
can include code and everyone can get code that is guaranteed to work.

Doyen is a general science platform.

t

[Doyencd-developer] doyencd

[<da...@ax...>]

Bill,

My apologies. I thought we'd talked about the doyen project.

There are 3 students at City College who are working on
making a Live CD (aka Knoppix) that includes a range of computer
algebra systems and a wiki. It is a 4 layered problem.
   
  1) make a live cd
  2) add computer algebra software
  3) make a axiom-like wiki that uses the software
  4) implement drag-and-drop from the axiom-wiki to doyen-wiki

You can see more details at daly.axiom-developer.org/doyen

We've got the first two parts working and now we need to clone the
axiom-wiki technology. 

We am working with RedHat on this project and we want them to distribute
free doyen CDs at various science conferences. The initial build is
going to be computer algebra but once we get the concept working we
plan to do one for physics later this summer. Then RedHat can go to
a physics conference and give out the doyen CDs. 

If you are in the audience for a talk at the physics conference you
should be able to boot the doyen CD, visit the physics wiki (a
sub-wiki of mathaction?)  and drag-and-drop the speakers paper, which
includes his code, onto your laptop. If this works then every paper
can include code and everyone can get code that is guaranteed to work.

Doyen is a general science platform.

t

[Doyencd-developer] wiki

[<da...@ax...>]

Jose,

Suppose you have a local wiki and a remote wiki.
Suppose both sites are capable of running axiom from the wiki.

Now suppose that we write a paper that includes a new algorithm
which we will call CFLOAT (cached infinite floating point numbers).

So the paper looks like:

\begin{document}
\section{theory}
This is the theory of CachedFloats which will do infinite precision
floating point computation with post-facto expansions.

\section{implementation}
\section{examples}
\end{document}

Since this is a latex document we can show it in the wiki web page
(the axiom wiki supports latex in pages). Thus if we drag this page
off the host wiki web page onto our local wiki web page, which has
the same technology, we should be able to see the formatted page.

In particular, Bill Page has a working extension that allows inline
axiom in a latex environment \begin{axiom}...\end{axiom} so we need
to steal this technology and get it working. So now the paper looks
like:


\begin{document}
\section{theory}
This is the theory of CachedFloats which will do infinite precision
floating point computation with post-facto expansions.

\section{implementation}
\section{examples}
\begin{axiom}
  x:CFLOAT:=1.0
  y:CFLOAT:=3.0
  z:CFLOAT:=x/y
\end{axiom}
\end{document}

so these expressions will be automatically executed and placed in the 
page with fancy output format. This would all work now except that
there is no CFLOAT domain to define this new type. So we have to
create a type called CFLOAT. This is axiom code and since the 
pamphlet is a literate program it will also occur inline thus:

\begin{document}

\section{theory}
This is the theory of CachedFloats which will do infinite precision
floating point computation with post-facto expansions.

\section{implementation}
This is the CachedFloat implementation code and it works.
<<*>>=
)abbrev CFLOAT CachedFloat
CachedFloat() == 
....

@

\section{examples}
\begin{axiom}
  x:CFLOAT:=1.0
  y:CFLOAT:=3.0
  z:CFLOAT:=x/y
\end{axiom}

\end{document}


So when we drag and drop the paper 3 things have to happen:

  1) tangle cfloat.spad.pamphlet >cfloat.spad
     compile cfloat.spad
     add it to axiom

     this extracts the axiom algera code, puts it into the library,
     and loads it into axiom next time it starts.

  2) weave cfloat.spad >cfloat.tex
     latex cfloat.tex
     copy cfloat.dvi to the axiom doc directory

     this extracts the documentation and adds it to axiom's doc pile.

  3) create the local wiki page

     this formats the document using Bill's technology into a web browser.
     when the \begin{axiom} is executed then axiom will start.
     the newly started axiom should include the new algebra code
     the \begin{axiom}..\end{axiom} block starts axiom, captures the
     output, and formats it to the screen.

You can assume this technology only works for pamphlet files as we
are trying to promote the use of literate programming.

We need to think this machinery thru carefully so that it works for
other systems (yacas, magnus, etc). So there is a part that does the
main steps in a generic manner and a part that does the specific steps
for the target system. These two parts should be clearly separated so
we can rewrite the Magnus-specific parts, Yacas-specific parts, etc.

Needless to say you need to document this and the ideal way to do it
would be to write a pamphlet explaining how this technology works that
includes some examples. Then someone could drag-and-drop your pamphlet
onto a system and know both HOW it works and THAT it works.

t

[Doyencd-developer] RE: wiki

[Bill P. <bil...@sy...>]

On June 13, 2005 12:12 PM Tim Daly wrote:

> Michael,
>
> Is your wiki code running on a bootable CD?
> If so, there must be more to the instructions than just
> the zwiki piece. It's important that you document how you
> made this work.
>
> Also, upload the tgz file for the zope and zwiki parts so
> we can keep track of which versions we used. We should be
> able to get all the parts from the CVS.
>
> The next step is to contact Bill Page (bil...@sy...)
> to see what code he adds to the zope/zwiki chain.

I don't know what this is all about but see:

http://page.axiom-developer.org/zope/mathaction/InstallingMathAction

for information on the Python code that is added to LatexWiki
for the Axiom and Reduce integration.

> ...

Regards,
Bill Page.

[Doyencd-developer] wiki

[<da...@ax...>]

Michael,

Is your wiki code running on a bootable CD?
If so, there must be more to the instructions than just the zwiki piece.
It's important that you document how you made this work.

Also, upload the tgz file for the zope and zwiki parts so we can keep
track of which versions we used. We should be able to get all the parts
from the CVS.

The next step is to contact Bill Page (bil...@sy...) to
see what code he adds to the zope/zwiki chain. 

The primary idea is that someone should be able to drag and drop a
"pamphlet" page from the axiom wiki to the doyen wiki and have the
code automatically added to the system.

This has several parts. 
  *) (code theft) we need to understand how Bill created the 
     \begin{axiom}..\end{axiom} technique and make that work locally.
     Currently we are just using a page that Jose put together but
     we need to inline the axiom in latex pages
  *) (autoweb) we need to take a simple pamphlet file with source code,
     automatically do the tangle and weave.
  *) (tangle) we need to compile the tangled code and add it to the
     axiom system.
  *) (weave) we need to latex the weaved code and add it to the
     axiom documentation.
  *) (drag) we need a drag-and-drop kind of mechanism, initially using just
     a button that ends up invoking wget or some such tool and then
     applying the previous integration techniques.

t

[Doyencd-developer] Re: da Wiki

[Michael S. <ms...@MI...>]

Tim,

I'm using ZWiki piled on top of zope, and, no not uploaded yet. I'm trying
to figure out what I want to upload because so much was specific to the
Linux on that box, which is just a test case. Once we start modifying the
initial wiki package, I'll have detailed instructions put together.

Right now, the instructions are "Go to zwiki.org and follow zwiki
installation instructions."

But since I have you, what are your opinions on the use of the wiki?
Where should I go from here?

-- Michael

------------------------

Michael Shaw
MIT, Class of 2007
Email: MS...@MI...
Cell: (917) 841 -- 8863

On Mon, 13 Jun 2005 da...@ax... wrote:

> excellent.
>
> which wiki did you use?
> where are the instructions?
> have you uploaded the files into the CVS?
>
> t
>
>
>

[Doyencd-developer] da Wiki

[<da...@ax...>]

excellent.

which wiki did you use?
where are the instructions?
have you uploaded the files into the CVS?

t

[Doyencd-developer] Re: axiom cd.

[Nobuki T. <tak...@ma...>]

Dear Tim;
thank you very much for letting me know very interesting project.
>>http://daly.axiom-developer.org/doyen

I would like to invite you to submit a presentation to
ASCM 2005 (http://newton.kias.re.kr/ASCM2005/)
or
ICMS 2006 (http://www.mathsoftware.org)
A lot of people will be interested in it.

Best Regards, Nobuki

[Doyencd-developer] Fedora Livecd Status + Documentation

[Wilken R. <wri...@gm...>]

After building multiple live cds I have begun to notice that my build=20
process has many flaws. For starters I noticed that when trying to build a=
=20
livecd there is the Fedora Core Version problem, which tends to have=20
different problem via yum when resolving dependencies. Also an out of space=
=20
error kept appearing when trying to install various applications=20
(tetex,Octave, Latex, Emacs) and so on. So I began to build a fedora livecd=
=20
that could be used to build other livecd, the overall goal of course was to=
=20
build a base cd that could be used for doyen cd development. However with=
=20
the new cd I came across some new errors. Namely very minimal hardware=20
support on the Fedora barebone cd which seems to brings up the issues of=20
loading the proper drivers for any particular machine, especially the=20
drivers needed to bring up the Ethernet card thus not allowing for the=20
dhclient to work properly.=20

So after trying this method for a few days I began to look at the linux4all=
=20
workstation livecd that is available. I noticed that most of the work that =
I=20
was trying to do has already been addressed (dhcp, hardware support, gui).=
=20
The latter lend me to begin trying to remaster the cd with new applications=
.=20
Trying to use the build process from above I came across the same errors=20
dealing with not enough space on device. So I have decided to try a=20
different approach. I have begun to build the cd in a way that is similar t=
o=20
that of the doyen knoppix cd. The build process has not yet been completed=
=20
and will be completed, I am currently working on remastering the workstatio=
n=20
version of the Fedora workstation.=20

So for the mean time I have added redhatbuild.pamplet to CVS that would=20
allow for building a new copy of the fedora livecd provided by linux4all.=
=20
This documentation is the base for all other future builds and release. I=
=20
intend to follow the same procedure with the workstation template but with=
=20
added steps.=20

wrivera

[Doyencd-developer] steps.pamphlet

[<da...@ax...>]

steps.pamphlet is in the doyencd CVS.

You all have read/write access to the CVS.

t

[Doyencd-developer] Fedora Livecd Status

[Wilken R. <wri...@gm...>]

At the moment I have currently built a Fedora livecd with dhcp capabilities=
=20
and a working yum configuration. Allowing the user to bring up his/her=20
network and install various applications. However there seems to be a=20
problem with yum on different versions of Fedora Core. The problems will be=
=20
listed in the up coming documentation.=20

To avoid platform errors, I have begun to build a Fedora livecd that would=
=20
allow us to mimic the build procedure that we used for Doyen on the Knoppix=
=20
based livecd. Thus allowing for us to use a base Fedora livecd to build=20
other livecd, which pretty much follows the same build procedure that is=20
provided by linux4all with a few modifications.=20

I will have some documentation and files to be put on sourceforge by late=
=20
Tuesday evening.=20

wrivera

[Doyencd-developer] Kepler Project

[<da...@ax...>]

*,

Check out http://planetmath.org

A long term strategy is to get associated with PlanetMath.
They use Latex in all articles. We could post articles
that include source code as well as a doyen CD pointer.

t