Martin Baker wrote:
>
> It did crash on my old computer when trying to open an xwindow. I just
> tried it on my new computer and it just gives this error (and fails to
> open xwindow and puts some funny patterns in the grey box it opens).
>
> (1) -> XIO: fatal IO error 11 (Resource temporarily unavailable) on X
> server ":0"
> after 16551 requests (16551 known processed) with 0 events remaining.
>
>
> I expect others may see different results, perhaps it will work on other
> peoples computer.
>
> I get this by going to:
> topics -> graphics -> new framework -> example 1
> and then go though the page clicking on the down buttons.
>
> This page did once work (I know because I wrote it).
As I wrote the page had problems. After fixing them I was
able to reproduce the crash. Actually, instead of clicking
on the down buttons I had to click on the command (I suspect
that you accidentaly clicked on a command). The crash was
due to buffer overflow in 'hypertex' program and is fixed now.
> My point is that this stuff is very difficult to write (and test on
> various platforms) and then, even when it works, it is likely to get
> broken by some apparently unrelated change. This is always going to be
> time consuming and distract developers away from working on the core
> mathematical functionality. I personally would rather spend my time
> producing static documentation.
Well, once I was able to reproduce the crash fixing was relatively
easy. Concerning "broken by some apparently unrelated change":
the page had problem from the very begining. AFAICS we both
tested it after compiling scene framework, when it worked OK.
But compilation automatically exposes compiled domains.
In normal use it would not work. Buffer overflow was there
probably 20 years. The crash was triggered by checking in
glibc -- without that probablity of visible effect of the
overflow would be lower. So the "unrelated change" was
extra checking in glibc. Note that more external tools
means more breakage of similar sort.
Concerning developement effort, of course doing nothing means
least effort. You may think: write once and then use it.
But both FriCAS and external world changes. We need to
catch examples that used to work, but fail now. Of course,
we want to maintain compatibility, so old code mostly
should work. But some code accidentaly exploits bugs,
there are valid changes that can make examples pointless
(example insted of producing intended failure may give
sensible result). And some bad constructs are eliminated.
Checking that examples work as intended requires some
effort. For non-graphic pages this effort is quite small
because we documentation build produces text files which
we can compare with previous results. Graphic pages
(and your Scene example is inside graphic page) are more
problematic, because building them requires manual action.
The point is that for example code we need some framework
for checking that it works and indentifying parts that
need updating. For non-graphic examples HyperDoc
performs this function reasonably well.
HyperDoc is limited and extending it would require effort.
But keeping it to work is relatively easy. Most problems
were in browser part, but this part is hardest to replace
by static documentation: browser provides several views
of functions and domains. Without accurate information
from browser working with FriCAS is much harder. While
the list of functions and domains changes slowely, it
would take considerable effort to keep it up to date.
You wrote that HyperDoc was failed experiment. When you
consider HyperDoc as viewer for static documentation it
indeed is unimpressive. But browser functionality is
quite useful. Note that important part of browser is
incuded in AXIOMsys. The presentation part is in
'hypertex' program and in principle could be replaced
by Texmacs or web browser. Also, I feel that '++'
documentation comments are a succes: vast majority
of functions has such comments, they are useful and
relatively easy to maintain. Part of the succes is
convention that they are quite short. While writing
good short description takes some effort, it is easier
than producing good long text. Also, short description
means that reader spents less effort reading them,
so most of the time they are more useful than longer
ones.
> I don't even think HyperDoc would impress potential new users of FriCAS.
> I think you would get more new recruits by having high quantity and
> comprehensive static web pages.
We can have both. Due to Ralf work most HyperDoc pages are in
.htex files and it should take relatively small effort to produce
web pages from them.
--
Waldek Hebisch
[email protected]
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
