axiom-developer
[Top][All Lists]
Advanced

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

[Axiom-developer] Re: successfully built axiomUI on Fedora 3 x86-64


From: Kai Kaminski
Subject: [Axiom-developer] Re: successfully built axiomUI on Fedora 3 x86-64
Date: Tue, 06 Sep 2005 00:25:51 +0200

Bill Page <address@hidden> writes:
> Thanks for your lastest tla axiom-GUI--1--patch-2. Below I have
> included an additional patch to use the $AXIOM variable instead
> of hardcoding paths or depending on implicit paths. This is
> consistent with the approach used in the current Axiom build.
>
> With your tla patch-2 and this patch I successfully built axiomUI
> web-gui on my Fedora Core 3 x86-64 system.
It's good to hear that.

> This is what I noticed so far:
>
> 1) All intermediate and binary files are created in the
>    'src/web-gui' directory. As a minimum, to be (more or less)
>    compatible with the Axiom build intermediate files should
>    go into directory 'int/web-gui' and the binaries/executables
>    should go into 'mnt/bin'
I know. I was hoping to do this better, but Make is a complicated
beast and I haven't used it in years. When I saw the deadline flying
past I just stopped working on it.

> 2) run-axiom-ui.sh does not have executable flag. It needs
>
>    chmod a+x run-axiom-ui.sh
I usually do not to set the executable flag for shell scripts of this
kind. Since the directory where run-axiom-ui.sh resides is not in my
path anyway, I'd have to use ./run-axiom-ui, which isn't better than
sh run-axiom-ui.sh. But I really don't mind, so I'll change it.

> 3) Running
>
>    ./run-axiom-ui.sh
>
>    produces no initial startup message. Something re-assuring
>    and informative like:
>
>    "Waiting for browser http:/127.0.0.1:5050"
>
>    would be nice :)
True, that was the evil deadline again. I'll fix that.

> 5) How can I exit cleanly from the run-axiom-ui.sh process?
>    Perhaps it should catch the ^C and kill signals and do
>    something nice.
Press Ctrl-C once (or maybe twice should drop you to the debugger. If
you just want to quit you can press Ctrl-D twice. I agree that this
isn't very user-friendly and I'll fix it.

> 6) On linux at least maybe we should setup an inetd service to
>    start run-axiom-ui.sh automatically on port 5050 so that this
>    is transparent to the user? Can you think of any other way
>    that we can make it unnecessary for the user to start two
>    processes? Should run-axiom-ui start the browser session for
>    the user?
I'm not sure what the best way is to do this. Maybe a shell script
that starts the web-gui as well as the browser is the way to go. So
far I didn't bother with this since the web-gui is not ready for
end-users anyway. And developers might actually hate it if
run-axiom-ui.sh always starts a browser automatically, since they
might want to start a different browser each time or use other tools
like netcat to connect to the web-gui. I'll add a second shell script,
so that there is one for developers and one for users.

> 7) Of course since this is 'alpha' version there are many easy
>    to find problems with output. The graphics output seems
>    especially fragile. The examples you give work fine but if
>    one deviates slightly it is possible to produce a mess.
>    E.g.
>
>      draw(1/sin(x),x=0..2*%pi)
The problem here is that Axiom prints denormalized (?) floats, which
leads to a floating point underflow on the Clisp side. The easy way to
fix this is to use Clisp's long floats (which allow a much greater
range than IEEE double float), but since in the future other GUIs in
other languages might get written, it's probably better to treat this
problem on the Axiom side. I'll look into this, but I'll need some
time. 

> Perhaps I should set up some AxiomUI categories on IssueTracker to
> help keep track of these problems?
I think it's a bit too early for that. Right now there are so many
problems that writing them all down wouldn't do much good. I don't
intend to abandon this project, so if there is a bug, just send me an
email.

> Now that SOC is over, what is the best way for us to ensure that
> the project development continues? Will you be able to continue to
> be involved? If so, would to be willing to continue to take the
> lead?
Yes, of course. I'm currently thinking about what the best way is to
proceed. There are quite a few things about the web-gui that I don't
like very much, which I did to meet the SoC deadline. Now that the SoC
is over, I hope to correct these problems.

There is only one real problem right now. As you know my own Linux box
died during the Summer of Code and I'll have to give the replacement
back at the end of this week. Then I'll have to leave town for a
week. After that I'll probably put some effort into the OS X port,
unless I manage to get my hands on another Linux box. We'll see.

Thanks for the patch,
Kai




reply via email to

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