htex --> (ht, pht, help, bitmaps)

[Ralf Hemmecke]

Hello,

I'd like to make public my work on the integration of the original
(NAGcdrom) .htex sources of the documentation into the normal build
process of fricas. It's branch "htexdoc" in my githup repo.

https://github.com/hemmecke/fricas/tree/htexdoc

The patches are not yet cleaned up, but that shouldn't prevent you from
compilation (configure && make && make install). I'd like to get
feedback about broken links in the resulting HyperDoc window.

There are still broken links (see below), but at least the one I found
is already broken in 1.2.0. The original glossary seems to live in
ug22.htex, but I haven't found a script to generate the glossary
properly from that file.

I've already syncronized the .htex files with the modifications that
Waldek has done to the .ht files in FriCAS. Comparison of the generated
share/hypertex/pages directory in the install directory with version
1.2.0 should show you that there are only minor differences.

Done:
- remove .ht files that can be generated from .htex files
(some of the .ht files are original sources)
- generate .input files and run through AXIOMsys to produce output
for the commands in the documentation
- generate bitmap files
- generate .help files for the system commands (")read", ")history",
")cd", etc.
- The build can run in parallel.

Missing:
- Glossary generation (currently gloss.ht is still in use)
- .help files for the examples
- .tex files of the Axiom book
- I have temporarily created two "What's New" entries.
a) Link to chapter 15 which is related to old Axiom News
b) the release notes
That must, of course, be cleaned up.

Ralf

=================== broken link ============================
In HyperDoc click

Reference > Axiom Book > 2. Using Types and Modes > 2.7. Conversion

Clicking now on the first word "Conversion" leads to a non-existing page.

The source is "\spadglossSee{Conversion}{conversion}" in ug02.htex which
obviously points to the glossary.

[Waldek Hebisch]

>
> Hello,
>
> I'd like to make public my work on the integration of the original
> (NAGcdrom) .htex sources of the documentation into the normal build
> process of fricas. It's branch "htexdoc" in my githup repo.
>
> https://github.com/hemmecke/fricas/tree/htexdoc
>
> The patches are not yet cleaned up, but that shouldn't prevent you from
> compilation (configure && make && make install). I'd like to get
> feedback about broken links in the resulting HyperDoc window.
>

How one can fetch it? Git clone on the link above does not
work and in clone of 'fricas' respostory I was unable to find
any branch.


--
Waldek Hebisch
heb...@math.uni.wroc.pl

[Ralf Hemmecke]

>> https://github.com/hemmecke/fricas/tree/htexdoc

> How one can fetch it? Git clone on the link above does not
> work and in clone of 'fricas' respostory I was unable to find
> any branch.

git clone -b htexdoc git://github.com/hemmecke/fricas.git

or (if you have an older version of git)

git clone git://github.com/hemmecke/fricas.git
cd fricas
git checkout htexdoc

After that

$ git log -1

should give

commit 78a1fb02794a78dd35bdd421ff164a9187473caf
Author: Ralf Hemmecke <ra...@hemmecke.org>
Date: Tue Apr 30 23:32:24 2013 +0200

include ug21.htex

if you get anything else then you are at the wrong position.

Try "gitk --all" then to see all branches.

Ralf

[Waldek Hebisch]

I tried now the branch. On my home machine it seem to work OK.
However, I have noticed that you unconditionaly build graphic
examples. This is fine for testing. But it hangs when there
is no access to X server, so clearly is unacceptable for
release. One possibility is to use current solution: build
graphic pages only from separate Makefile target. Another
possibility is to have only 'data' files in generated pages,
but no bitmaps. I am not sure how hard this would be, but
in principle all ingredients are there: graphic viewer gets
content of 'data' file from AXIOMsys and uses it to draw images
and generate bitmap files.

Another things: you run build of .ht files in the 'target'
subtree. Please do not: normally things should be build in
src subtree and copied to 'target' subtree.

Another smaller point: you put viewports and pages in the
same directory. I think that puting viewports in separate
place (which is the current setup) is better.

--
Waldek Hebisch
heb...@math.uni.wroc.pl

[Ralf Hemmecke]

On 05/29/2013 03:00 AM, Waldek Hebisch wrote:
> I tried now the branch. On my home machine it seem to work OK.
> However, I have noticed that you unconditionaly build graphic
> examples. This is fine for testing. But it hangs when there
> is no access to X server, so clearly is unacceptable for
> release.

Sure, the current state is for showing that the translation works. Now
comes the part with integrating it with all features into the FriCAS
build system.

> One possibility is to use current solution: build
> graphic pages only from separate Makefile target. Another
> possibility is to have only 'data' files in generated pages,
> but no bitmaps. I am not sure how hard this would be, but
> in principle all ingredients are there: graphic viewer gets
> content of 'data' file from AXIOMsys and uses it to draw images
> and generate bitmap files.

Looks like this would take several iterations of discussions.
There are two points.

1) I haven't yet tried your suggestion with
xvfb-run --server-args="-screen 0 1024x768x24" --auto-servernum -n 0
make gphts
but it is definitely something that I want to include (conditionally). I
really don't like windows popping up my screen during build.

2) Actually, conditionally building the graphics should not be done. All
the documentation files are static. So in a distribution I would rather
bundle all of them together. If someone really wants to build from the
SVN sources, I'd count this person as a developer who would know how to
deal with X.
But, of course, I shouldn't yet change the current features too drastically.

> Another things: you run build of .ht files in the 'target'
> subtree. Please do not: normally things should be build in
> src subtree and copied to 'target' subtree.

Honestly, the build system is still much too complicated. There is a
build and a target directory. That's really uncommon. Everything could
be built in place. There is the concept of vpath builds where the build
is done outside the source tree. And using "make DESTDIR=... install"
should also work properly.

You seem to want "target" as an exact copy of the installation-dir-to-be
with no extra files. Why? If it is just for running FriCAS from the
target directory, it doesn'ts hurt if there are junk files.

> Another smaller point: you put viewports and pages in the
> same directory. I think that puting viewports in separate
> place (which is the current setup) is better.

Why? It's all generated anyway. In fact, I don't see a reason for this
extra "pages" subdirectory. Wouldn't it make sense to put everything
connected to hyperdoc, i.e. the .ht, .pht, .bitmap and *.VIEW files/dirs
right under share/hyperdoc instead of share/hypertex/pages?
Why would there be need for more subdirectories in a generated tree?
I faintly remember that the "hypertex/pages" part is hardcoded in some
places, that was the only reason why I haven't made it more flat.

Anyway, I don't care so much, because in the long run, most of this
documentation should be generated into HTML pages.

Ralf

[Waldek Hebisch]

>
> On 05/29/2013 03:00 AM, Waldek Hebisch wrote:
>
> > Another things: you run build of .ht files in the 'target'
> > subtree. Please do not: normally things should be build in
> > src subtree and copied to 'target' subtree.
>
> Honestly, the build system is still much too complicated. There is a
> build and a target directory. That's really uncommon. Everything could
> be built in place. There is the concept of vpath builds where the build
> is done outside the source tree. And using "make DESTDIR=... install"
> should also work properly.
>
> You seem to want "target" as an exact copy of the installation-dir-to-be
> with no extra files. Why? If it is just for running FriCAS from the
> target directory, it doesn'ts hurt if there are junk files.

I want build to take place in 'src' subtree. You wrote that build
is complicated. But actually there are simple rules: normally
build works in a directory parallel to source directory, Makefile
and its results are there. We need 'target' subtree because we
run parts of system during build and we overwrite some of them.
IME trying to do everyting in 'target' whould cause serious
difficulties with debugging build problems. Doing _part_
of build in 'target' directly would cause no problem, but _that_
would be unnecessary complication. We run 'htadd' in the
target tree but this is probably the only build command
run inside 'target' tree.

> > Another smaller point: you put viewports and pages in the
> > same directory. I think that puting viewports in separate
> > place (which is the current setup) is better.
>
> Why? It's all generated anyway. In fact, I don't see a reason for this
> extra "pages" subdirectory. Wouldn't it make sense to put everything
> connected to hyperdoc, i.e. the .ht, .pht, .bitmap and *.VIEW files/dirs
> right under share/hyperdoc instead of share/hypertex/pages?
> Why would there be need for more subdirectories in a generated tree?
> I faintly remember that the "hypertex/pages" part is hardcoded in some
> places, that was the only reason why I haven't made it more flat.

Let me put it that way: when I want to see a page there is good
chance that I will want to see another page, but quite low that
will want to see a viewport. Given that we have many pages
and viewports keeping them separate makes things more managable.

Put it differently: when tree structured filesystem was invented
it was significant step forward compared to flat filesystem.
While you may wish something better than tree structured filesystem,
when the choice is between tree and flat structure tree is
typically much better.

--
Waldek Hebisch
heb...@math.uni.wroc.pl

[Ralf Hemmecke]

> I want build to take place in 'src' subtree.

Looks like we have different views on how a build should work. I will
not argue much since you are the main developer, but for me it should be
possible to put a fricas checkout on a read-only medium and then start
the build from some directory outside this checkout. This is the
standard way I build fricas. My source tree is never written.

But it should equally well be possible to build directly inside the
checkout directory.

> We need 'target' subtree because we run parts of system during build
> and we overwrite some of them.

Right, I guess you mean bootstrapping algebra. For that it's OK, but
otherwise "target" is unnecessary. Furthermore, there also appears a
"build" directory, which only is filled only like this:

find build -type f
build/x86_64-unknown-linux/bin/interpsys
build/x86_64-unknown-linux/bin/bootsys
build/x86_64-unknown-linux/bin/lisp
build/scripts/document

We could probably generate those things to some other place and forget
about "build".

For all other parts (except the bootstrapping) the build system should
more follow the standard autotools way.

> IME trying to do everyting in 'target' whould cause serious
> difficulties with debugging build problems.

Well, maybe. I'll address this some time later, I really want automake
and will some day come up with a patch. But it's not urgent.

> Doing _part_ of build in 'target' directly would cause no problem,
> but _that_ would be unnecessary complication. We run 'htadd' in the
> target tree but this is probably the only build command run inside
> 'target' tree.

What I don't understand is, that there is a separate "target" tree, but
actually it would be completely OK to say

git checkout g...@github.com:hemmecke/fricas-svn.git fricas
mkdir fricas-build
cd fricas-build
../fricas/configure --prefix=/some/nice/directory
make
make install

That actually works already today, but the fricas-build/target directory
has no corresponding source directory in the fricas tree. In fact
"target" is more like an installed directory.

> Let me put it that way: when I want to see a page there is good
> chance that I will want to see another page, but quite low that will
> want to see a viewport.

If you want to see a page you look into "target"? Not inside the
installed tree or the very source tree?

I might agree that the installed tree should look manageable, but the
(temporarily generated) build tree is not something I care much about.
Of course, I'll move viewport as to meet your suggestion, but the
installed tree is what counts, not "target".

> when tree structured filesystem was invented ...

Don't think that I'm a fan of flat filesystems. ;-)

Ralf

[Waldek Hebisch]

Ralf Hemmecke wrote:
>
> > I want build to take place in 'src' subtree.
>
> Looks like we have different views on how a build should work. I will
> not argue much since you are the main developer, but for me it should be
> possible to put a fricas checkout on a read-only medium and then start
> the build from some directory outside this checkout. This is the
> standard way I build fricas. My source tree is never written.

I should write "'src' subtree of build directory". I normally
build outside of source tree. I build inside source tree only
to check that it actially works. My point was that the 'src'
subtree of build directory should have structure parallel to
source tree.

> > We need 'target' subtree because we run parts of system during build
> > and we overwrite some of them.
>
> Right, I guess you mean bootstrapping algebra. For that it's OK, but
> otherwise "target" is unnecessary. Furthermore, there also appears a
> "build" directory, which only is filled only like this:
>
> find build -type f
> build/x86_64-unknown-linux/bin/interpsys
> build/x86_64-unknown-linux/bin/bootsys
> build/x86_64-unknown-linux/bin/lisp
> build/scripts/document
>
> We could probably generate those things to some other place and forget
> about "build".

'build' is for things that we need to run during build but which
do not go int the final system.

>
> For all other parts (except the bootstrapping) the build system should
> more follow the standard autotools way.

build/src distinction is a standard way: it is intended to
support cross-compilation.

> > IME trying to do everyting in 'target' whould cause serious
> > difficulties with debugging build problems.
>
> Well, maybe. I'll address this some time later, I really want automake
> and will some day come up with a patch. But it's not urgent.
>
> > Doing _part_ of build in 'target' directly would cause no problem,
> > but _that_ would be unnecessary complication. We run 'htadd' in the
> > target tree but this is probably the only build command run inside
> > 'target' tree.
>
> What I don't understand is, that there is a separate "target" tree, but
> actually it would be completely OK to say
>
> git checkout g...@github.com:hemmecke/fricas-svn.git fricas
> mkdir fricas-build
> cd fricas-build
> ../fricas/configure --prefix=/some/nice/directory
> make
> make install
>
> That actually works already today, but the fricas-build/target directory
> has no corresponding source directory in the fricas tree. In fact
> "target" is more like an installed directory.

To some degree yes: you should be able to run FriCAS from the
target tree. In fact I do almost all testing without actually
installing FriCAS. Of course for such testing to be valid
'target' tree should have structure identical to the installed
tree.

>
> > Let me put it that way: when I want to see a page there is good
> > chance that I will want to see another page, but quite low that will
> > want to see a viewport.
>
> If you want to see a page you look into "target"? Not inside the
> installed tree or the very source tree?

Target should be like installed tree, so argument applies to both.
Of course when I want to see source I go to source tree. When
I need to check 'target' I look into 'target'.

> I might agree that the installed tree should look manageable, but the
> (temporarily generated) build tree is not something I care much about.
> Of course, I'll move viewport as to meet your suggestion, but the
> installed tree is what counts, not "target".

Of course since viewport are created together with pages they
will be in the same place in 'src' part of build tree. But,
as I wrote, 'target' should be like installed tree.

--
Waldek Hebisch
heb...@math.uni.wroc.pl

[Ralf Hemmecke]

> To some degree yes: you should be able to run FriCAS from the
> target tree. In fact I do almost all testing without actually
> installing FriCAS.

May I question this? What would be the big difference to saying

/path/to/configure --prefix=/install/path
make
make install

without a "target" directory during "make" time?

Basically "make install" would create the "target" directory in any
place you like. And if DESTDIR would work (which I currently don't know)
one could even have different installs without the --prefix to the
configure script.

Ralf

[Waldek Hebisch]

Ralf Hemmecke wrote:
>
> > To some degree yes: you should be able to run FriCAS from the
> > target tree. In fact I do almost all testing without actually
> > installing FriCAS.
>
> May I question this? What would be the big difference to saying
>
> /path/to/configure --prefix=/install/path
> make
> make install
>
> without a "target" directory during "make" time?

The point is that we need 'target' tree anyway so 'make install'
is just pure overhead.

> Basically "make install" would create the "target" directory in any
> place you like. And if DESTDIR would work (which I currently don't know)
> one could even have different installs without the --prefix to the
> configure script.

DESTDIR works.

--
Waldek Hebisch
heb...@math.uni.wroc.pl

[Ralf Hemmecke]

>> Another smaller point: you put viewports and pages in the
>> same directory. I think that puting viewports in separate
>> place (which is the current setup) is better.

I've just went over src/hyper/Makefile.in. Right, I build the *.VIEW/*
files under the hypertex/pages directory. But then I have a target that
copies them into the viewports directory. Do you rather want me to use
mv instead of cp?

https://github.com/hemmecke/fricas/blob/htexdoc/src/hyper/Makefile.in#L375

If I change according to your request and build inside the source tree
and then copy everthing to target, I guess then cp should be OK, right?

I still have the suspicion that "target" is considered like a local
install dir.

Ralf

[Ralf Hemmecke]

I've now changed src/hyper/Makefile.in to build inside src and in a
second step copy everything to the "target" directory.

Either go to your git clone and say

git checkout htexdoc
git pull origin htexdoc

or freshly clone as described here.

https://groups.google.com/d/msg/fricas-devel/PI7x8hbfhDw/u-wgmiPOTcQJ

If I find time in the weekend, I'm going to make the build (ehm,
configure.ac) depending on whether there is X available or not.

Maybe in the meantime someone could already check whether the contents
looks fine. Not true at the moment since there are two "What's New"
entries on the first page, but I didn't know which one to take. Patches
are welcome.

Ralf

# git log -1
commit 08d7c7379d8fc148a2c385de2470fbd1b3fc5ff9
Author: Ralf Hemmecke <ra...@hemmecke.org>
Date: Sun Jun 2 23:08:52 2013 +0200

build in src, later copy to target

[Waldek Hebisch]

Ralf Hemmecke wrote:
>
> I've now changed src/hyper/Makefile.in to build inside src and in a
> second step copy everything to the "target" directory.
>

Good.

> If I find time in the weekend, I'm going to make the build (ehm,
> configure.ac) depending on whether there is X available or not.

I admit that I looked at this possibility in the past and
rejected the idea. One reason is that more deterministic
build is better than one which changes depending on
environment. Second (and more important) is that generation
of images takes over the screen effectively inhibiting
any other use of the machine. I feel that having to
invoke extra target during build is small price to pay
for control over unpleasent aspects.

I would rather work on eliminating need for X during
documentation build.

--
Waldek Hebisch
heb...@math.uni.wroc.pl

[Ralf Hemmecke]

Of course I can make a separate target that can be made or not depending
on a configure parameter.

> I would rather work on eliminating need for X during
> documentation build.

Yes, that would be good. But I have no idea how.

Would xvfb be of any help? I haven't yet looked into that part.
I thought that some of that graphic processes that are started through
sman actually need X to produce the pictures, i.e. I thought X is an
integral part of the process that cannot easily be removed.

Ralf

[Waldek Hebisch]

Ralf Hemmecke wrote:
>
> > I would rather work on eliminating need for X during
> > documentation build.
>
> Yes, that would be good. But I have no idea how.
>
> Would xvfb be of any help? I haven't yet looked into that part.
> I thought that some of that graphic processes that are started through
> sman actually need X to produce the pictures, i.e. I thought X is an
> integral part of the process that cannot easily be removed.

Bitmap images are produced by displaying them and getting back
the resulting bitmap from the X server. So, if you want
bitmap images then removing X is a substantial effort.
However, we have '.data' files which a vector type description
of the image. Our image viewer can display image having
only '.data' file. So we could generate only '.data' files
during documentation build and modify HyperDoc so that it
could display images from '.data' files. Skipping bitmaps
during documentation build should be easy. More work
is needed so that HyperDoc can work from '.data' files.
However, we have code to display '.data' files, we just
need to link it to HyperDoc.

--
Waldek Hebisch
heb...@math.uni.wroc.pl

[Ralf Hemmecke]

> Bitmap images are produced by displaying them and getting back the
> resulting bitmap from the X server. So, if you want bitmap images
> then removing X is a substantial effort.

I don't need bitmaps. Not now. I don't yet know whether they would be
necessary for the printed book version, but that's not my concern at the
moment.

> However, we have '.data' files which a vector type description of the
> image. Our image viewer can display image having only '.data' file.

I didn't know.

> More work is needed so that HyperDoc can work from '.data' files.
> However, we have code to display '.data' files, we just need to link
> it to HyperDoc.

Would you have a pointer. Is viewing of .data files somewhere used so
that I could perhaps replace the calls to showing bitmaps by showing .data?

Ralf

[Waldek Hebisch]

Ralf Hemmecke wrote:
>
> > More work is needed so that HyperDoc can work from '.data' files.
> > However, we have code to display '.data' files, we just need to link
> > it to HyperDoc.
>
> Would you have a pointer. Is viewing of .data files somewhere used so
> that I could perhaps replace the calls to showing bitmaps by showing .data?
>

The viewAlone program works from '.data' files. Actually, when
one uses 'draw' command image data flows from AXIOMsys to
image viewer in essentially the same format (but with no
need to read/write it to disc).

--
Waldek Hebisch
heb...@math.uni.wroc.pl

[Ralf Hemmecke]

> The viewAlone program works from '.data' files.

Well, actually there are no .data files, you probably meant
viewports/AssortedGraphicsExamplePage3.VIEW/data.

Apart from image.bm and image.xpm I also see a graph0 file.
Do you happen to know something about these graph0 files?

Ralf

[Ralf Hemmecke]

> Apart from image.bm and image.xpm I also see a graph0 file.
> Do you happen to know something about these graph0 files?

https://github.com/hemmecke/fricas-svn/blob/master/src/graph/fileformats.pamphlet

Looks like data is meta information for up to 9 graphs whose data is in
graph0 till graph8.

How to convince hyperdoc to translate these data into an inline image is
another question.

Anyway, eventually, I'd like to have the documentation in HTML format,
so I anyway need some process to convert into a common picture format,
but hopefully this wouldn't involve X.

Ralf

[Ralf Hemmecke]

For the moment, I have decided to leave the need of X in place.

I've pushed two new commits.
https://github.com/hemmecke/fricas/commits/htexdoc

The first patch separates the image generation from the normal HyperDoc
build. Image generation can be done in a second step via

cd src/hyper; make MAYBE_VIEWPORTS=viewports

The second patch tries to hide the popping up windows via xvfb-run.

Unfortunately, the patch "check for xvfb-run and use it via XVFB" works
from the configure&&make point of view, but does not give the expected
result. I get black images in HyperDoc. Does someone know what the issue
with xvfb-run is here?

Ralf

PS:
Since I have rebased all my patches on top of master, you'd have to
either clone freshly via

git clone -b htexdoc git://github.com/hemmecke/fricas.git

or if in an already existing clone where I assume that "origin" points
to "git://github.com/hemmecke/fricas.git" (git remote -v).

git fetch origin
# maybe you want to stash your own modifications away
git stash
git checkout htexdoc
git reset --hard origin/htexdoc

[Ralf Hemmecke]

Unfortunately, the patch "check for xvfb-run and use it via XVFB" works
from the configure&&make point of view, but does not give the expected
result. I get black images in HyperDoc. Does someone know what the issue
with xvfb-run is here?

I think I've got a hint on why I get black images. I build fricas via "make -j8". If I build in the src/hyper directory with xvfb-run and no concurrent processes, the images are as they should be.

Still I need help to let the generation properly run in parallel. Any ideas?

Thanks
Ralf

[Ralf Hemmecke]

> I think I've got a hint on why I get black images. I build fricas via "make
> -j8". If I build in the src/hyper directory with xvfb-run and no concurrent
> processes, the images are as they should be.
>
> Still I need help to let the generation properly run in parallel. Any ideas?

It seems to work to start several xvfb-run processes. I've just pushed

$ git log -1
commit 2eb8343b407f97b8d510df07b960cdbe89bdf84e
Author: Ralf Hemmecke <ra...@hemmecke.org>
Date: Mon Jun 10 23:56:35 2013 +0200

XVFB runs concurrently

https://github.com/hemmecke/fricas/commits/htexdoc

Still missing: mobius.VIEW and going over the initial HyperDoc page (two
times "What's new").

Ralf

[Waldek Hebisch]

Ralf Hemmecke wrote:
> In HyperDoc click
>
> Reference > Axiom Book > 2. Using Types and Modes > 2.7. Conversion
>
> Clicking now on the first word "Conversion" leads to a non-existing page.
>
> The source is "\spadglossSee{Conversion}{conversion}" in ug02.htex which
> obviously points to the glossary.

The problem is due to missing 'glosskey.text' and 'glossdef.text'
files. AFAICS we lost them during transition from wh-sandbox
to FriCAS. 'glosskey.text' and 'glossdef.text' may be generated
from 'src/share/algebra/gloss.text' by the 'buildGloss' function
in 'src/interp/br-data.boot'. However, currently 'buildGloss'
is unused and 'src/share/algebra/gloss.text' looks like a
generated file (but ATM I do not know how it was generated).
Moreover, 'buildGloss' also creates 'gloss.ht', but it looks
fishy because I see no other source of text contained in
'gloss.ht' and 'gloss.text'...

--
Waldek Hebisch
heb...@math.uni.wroc.pl

[Ralf Hemmecke]

Except glossdef.text, these files are in fricas since the beginning.

https://github.com/hemmecke/fricas-svn/blob/master/src/hyper/pages/gloss.ht
(last modified in r1302)
https://github.com/hemmecke/fricas-svn/blob/master/src/share/algebra/gloss.text
(last modified in r22)
https://github.com/hemmecke/fricas-svn/blob/master/src/share/algebra/glosskey.text
(last modified in r22)

Furthermore, the search field at the very bottom of the
Reference->Glossary page doesn't seem to work. But looking at the code
in ht-root.boot (the only place where I've found the use of
glossdef.text) seems to indicate that the missing glossdef.text could be
the reason for the non-functioning search.

glossdef.text is at least on the original NAGcdrom, so could be taken
from there if needed.

However, it's interesting information that these files have been
generated. I don't find it important enough to resurrect the generation
of these files before the release, but I've made an entry into my TODO
list. Only if I can find a quick fix it can go into the release.

The interesting thing is this one:

https://github.com/hemmecke/fricas/blob/htexdoc/src/htex/ug22.htex#L35
% DO NOT EDIT THIS FILE. This was created by gloss.awk
% from gloss.ht.

Up to now I thought that the .htex files are the original sources. That
doesn't seem to be always the case. :-(

That brings me to the question of unused .htex files. Since originally I
also planned to generate the book, I included all of them from NAGcdrom.
In src/hyper/Makefile.in I have a variable

NON_HD_CHAPTERS = ${EXAMPLES_CHAPTER} 17 18 19 20 22

that is responsible for excluding these chapters from the hyperdoc
generation.

Since ug22 is anyway generated from gloss.ht and ug17-20 describe
categories/domains/packages/operations and thus can potentially also be
generated from the information in the algebra directory, I now tend not
to include them into my final patch for inclusion into FriCAS.

Ralf

[Ralf Hemmecke]

I claim that I am basically finished with re-establishing the build of
the hyperdoc documentation from the .htex files.

I've basically split into just two patches. The first one basically
brings everything in place whereas the second one moves the releaseNotes
and "Changes to Spad language" into ug15.htex.

https://github.com/hemmecke/fricas/commits/htexdoc

I have incorporated the relevant .htex files from NAGcdrom and removed
the corresponding .ht files.

Some of the .help files will be generated and some where simply copied
from NAGcdrom.

The glossary (gloss.ht, glossdef.text, glosskey.text) is regenerated
from gloss.text.

The viewports are generated. The special mobius stuff has been replaced
by a saddle picture that is anyway generated during the viewport generation.

I've changed the configure.ac file to test whether the xvfb-run program
is available. If it is, the viewports will be built automatically. If it
isn't, then viewports build is delayed until one explicitly calls

cd src/hyper; make MAYBE_VIEWPORTS=viewports

This will (as was before) pop up windows and makes working on the
machine nearly impossible for a while. One can, of course, add "-j 8"
to run the build process in parallel.

Actually, the input files

https://github.com/hemmecke/fricas/blob/f5f5030f8938f18cba6c9a17e234f405f9055563/src/hyper/Makefile.in#L296

UG_EXTRA_INPUT = arrows bouquet matrix newton ribbon vectors

could all be generated from ug15.htex, but I haven't bothered, because
they already exist in .input.pamphlet form.

I hope you like it.

Ralf

PS:
Maybe I should add the content of this mail into the commit message. ;-)

PS2:

As usual

git clone -b htexdoc git://github.com/hemmecke/fricas.git

or (in an existing clone) do

[Waldek Hebisch]

Ralf Hemmecke wrote:
>
> I claim that I am basically finished with re-establishing the build of
> the hyperdoc documentation from the .htex files.
>
> I've basically split into just two patches. The first one basically
> brings everything in place whereas the second one moves the releaseNotes
> and "Changes to Spad language" into ug15.htex.
>
> https://github.com/hemmecke/fricas/commits/htexdoc
>
> I have incorporated the relevant .htex files from NAGcdrom and removed
> the corresponding .ht files.
>
> Some of the .help files will be generated and some where simply copied
> from NAGcdrom.
>
> The glossary (gloss.ht, glossdef.text, glosskey.text) is regenerated
> from gloss.text.
>
> The viewports are generated. The special mobius stuff has been replaced
> by a saddle picture that is anyway generated during the viewport generation.

What problem do you have with mobius picture?

> I've changed the configure.ac file to test whether the xvfb-run program
> is available. If it is, the viewports will be built automatically. If it
> isn't, then viewports build is delayed until one explicitly calls
>
> cd src/hyper; make MAYBE_VIEWPORTS=viewports
>
> This will (as was before) pop up windows and makes working on the
> machine nearly impossible for a while. One can, of course, add "-j 8"
> to run the build process in parallel.
>
> Actually, the input files
>
> https://github.com/hemmecke/fricas/blob/f5f5030f8938f18cba6c9a17e234f405f9055563/src/hyper/Makefile.in#L296
>
> UG_EXTRA_INPUT = arrows bouquet matrix newton ribbon vectors
>
> could all be generated from ug15.htex, but I haven't bothered, because
> they already exist in .input.pamphlet form.
>
> I hope you like it.

In general it looks good. However I do not like generating .ht files
in 'src/hyper' directory. 'src/hyper' is for building HyperDoc,
building HyperDoc pages beside using HyperDoc programs has nothing
to do with building HyperDoc. That is why I created the 'src/paste'
directory. If you do not like 'src/paste' use 'src/htex' or create
different subdirectory, but please do not use 'src/hyper'.

Rule for 'gloss.ht' is unnecessarly complicated, see patch in
attachenent for simpler rule. Also, it would be good to
avoid copy of 'gloss.text', this can be done by adding
pathname argument to 'buildGloss'.

>
> PS:
> Maybe I should add the content of this mail into the commit message. ;-)

I prefer to keep commit messages short (basically one short sentence)
because from time to time I go trough all messages (or all messages
in some period, or all messages affecting given file) to find a
particular commit. Longer messages mean that reading them will
take more time... Also, longer messages complicate
automatic formatting and consequently make list of commits harder
to read. Slightly longer messages are apropriate
in ChangeLog, but again being concise is a virtue.


--
Waldek Hebisch
heb...@math.uni.wroc.pl

[Ralf Hemmecke]

Thanks for looking over the code.

> What problem do you have with mobius picture?

Not really a problem. But, look at the generated picture. It looks ugly.
I like the saddle much more. And just using an already generated picture
avoids the need to add Makefile rules to generate mobius. In fact, in
the place where mobius was used, the actual content of the picture is
completely irrelevant.

> In general it looks good. However I do not like generating .ht files
> in 'src/hyper' directory. 'src/hyper' is for building HyperDoc,
> building HyperDoc pages beside using HyperDoc programs has nothing
> to do with building HyperDoc. That is why I created the 'src/paste'
> directory. If you do not like 'src/paste' use 'src/htex' or create
> different subdirectory, but please do not use 'src/hyper'.

Well. You should have made a hint much earlier. But OK, should be
manageable to move to a separate subdir.

> Rule for 'gloss.ht' is unnecessarly complicated, see patch in
> attachenent for simpler rule. Also, it would be good to
> avoid copy of 'gloss.text', this can be done by adding
> pathname argument to 'buildGloss'.

Thank you. That was exactly what I was asking for.

>> Maybe I should add the content of this mail into the commit message. ;-)

> I prefer to keep commit messages short (basically one short sentence)
> because from time to time I go trough all messages (or all messages
> in some period, or all messages affecting given file) to find a
> particular commit. Longer messages mean that reading them will
> take more time... Also, longer messages complicate
> automatic formatting and consequently make list of commits harder
> to read. Slightly longer messages are apropriate
> in ChangeLog, but again being concise is a virtue.

That is perhaps why in git they have the following rule.

http://doc.norang.ca/git-howto.html

And there is "git log --oneline". So I actually see not a big problem
with long commit messages. Quite the contrary. And with "git log --grep"
one can easily search through commit messages.
http://gitster.livejournal.com/30195.html

Ralf

[Ralf Hemmecke]

> In general it looks good. However I do not like generating .ht files
> in 'src/hyper' directory. 'src/hyper' is for building HyperDoc,
> building HyperDoc pages beside using HyperDoc programs has nothing
> to do with building HyperDoc. That is why I created the 'src/paste'
> directory. If you do not like 'src/paste' use 'src/htex' or create
> different subdirectory, but please do not use 'src/hyper'.

Sleeping over it, it's not exactly clear what your idea of the directory
structure is.

In trunk there is

src/hyper/bitmaps and src/hyper/pages

That you didn't seem to be addressing.

I've made everything inside src/hyper, because all this is related to
hyperdoc, either with the program or with the actual documentation.

The reason why I've created src/htex was that the .htex files are also
used to generate the book and that didn't make sense to me to plan
putting the code for generating the book inside src/hyper.

In fact, now since you are unhappy with the documentation in src/hyper,
I'll create src/doc/htex, src/doc/ht, src/doc/bitmaps and move the
generation of the hyperdoc pages into src/doc. Furthermore, I plan to
also create the latex version of the AXIOM book inside src/doc.

What do you think about this structure?

Ralf

[Waldek Hebisch]

>
> > In general it looks good. However I do not like generating .ht files
> > in 'src/hyper' directory. 'src/hyper' is for building HyperDoc,
> > building HyperDoc pages beside using HyperDoc programs has nothing
> > to do with building HyperDoc. That is why I created the 'src/paste'
> > directory. If you do not like 'src/paste' use 'src/htex' or create
> > different subdirectory, but please do not use 'src/hyper'.
>
> Sleeping over it, it's not exactly clear what your idea of the directory
> structure is.

General structure is that we have build directory which I will
call build_dir and source directory which I will call src_dir.
Normally build_dir and src_dir are different, but they are
allowed to coincide to support 'in tree' build. Structure
of build_dir is supposed to parallel structure of src_dir.
So typical case is that say sources of interpsys are in
src_dir/src/interp and interpsys is build in
build_dir/src/interp. In particular, things in build_dir/foo
are created by build_dir/foo/Makefile which in turn
is created by configure from src_dir/foo/Makefile.in.
Concerning dividing things into directories/files I am
trying to keep to following rules:

- do not move things around, unless new arrangenent
is clearly better (that is gain from change should
be big enough to compensate for disruption due to
change)
- keep things divided into logically connected parts
of managable size. Big directory/file may be split
just for size reasons even if othewise would be a
single unit. Tiny loosely related parts are not
split into separate units to avoid creating too
many parts.

>
> In trunk there is
>
> src/hyper/bitmaps and src/hyper/pages
>
> That you didn't seem to be addressing.

Well, they should be moved to better places.

> I've made everything inside src/hyper, because all this is related to
> hyperdoc, either with the program or with the actual documentation.
>
> The reason why I've created src/htex was that the .htex files are also
> used to generate the book and that didn't make sense to me to plan
> putting the code for generating the book inside src/hyper.
>
> In fact, now since you are unhappy with the documentation in src/hyper,
> I'll create src/doc/htex, src/doc/ht, src/doc/bitmaps and move the
> generation of the hyperdoc pages into src/doc. Furthermore, I plan to
> also create the latex version of the AXIOM book inside src/doc.
>
> What do you think about this structure?

I am affraid that putting generation of everthing is src/doc
is not a good idea. I would prefer generation of .ht pages
to be in separate directory from generating .pht-s and
viewports. Basically they use separate rules and each
involves large number of files, so IMHO keeping them
separte would more managable. But this is not very strong opinion.

So I would probably put generation of .ht pages into 'src/doc/ht'
or maybe 'src/doc/gen_ht' and the .pht part and viewports into
'src/doc/paste'. If that is problematic for you, then I think
that generating everything in something like 'src/doc/gen_ht'
is better than plain 'src/doc' (the idea is that AXIOM book
and possible other things can go into different subdirectories
of 'src/doc'.

One extra thing: I would like to keep current practice of bundling
generated .pht-s and viewports with release tarball. More
precisely, I think it is important to bundle graphic .pht
pages and viewports. But given that the simplest thing to
do is to bundle all generated .ht and .pht pages.
With directory arrangement in trunk this is relatively easy
and there is reasonably clear distiction between real
sources and generated files bundled into release tarball
(the generated files are in src/paste). And generation
of release tarball can be done by a simple script
(see src/scripts/mkdist.sh). From this point of view
generated '.ht' files should be in different subdirectory
from '.ht' files which are sources.

BTW: I noticed curious thing: on my build machine real
time for 'make all-input' after build in the htdoc branch
seem to be 20s larger (that 120s versus 100s) than real time in
trunk. CPU times seem to almost identical. I am not sure
if this means anything, but this happened twice, so it does
not look like random fluctuation due to sudden increase
in machine load.

--
Waldek Hebisch
heb...@math.uni.wroc.pl

[Ralf Hemmecke]

> Structure of build_dir is supposed to parallel structure of src_dir.

Well, that's the idea and one of the reasons that makes the "target"
directory inside build_dir somewhat superfluous.

> I am affraid that putting generation of everthing is src/doc is not
> a good idea.

Wait a minute. I said, I'll create bitmaps, htex, and ht subdirectories
under src/doc. These are source files. To where I generate I didn't mention.

But yes, the idea was to generate all the files inside src/doc.
I really don't know why you care so much. Isn't the "target"
subdirectory something you finally care about? From what I see in the
toplevel Makefile, installation basically works by copying over the
"target" subdir to the installation location. If you need "target" for
the algebra bootstrap, that's fine, but for most other things I consider
it useless. All the Makefile targets that I have created that start with
"copy-" would actually be targets that should be executed at "make
install" time.

> I would prefer generation of .ht pages to be in separate directory
> from generating .pht-s and viewports. Basically they use separate
> rules and each involves large number of files, so IMHO keeping them
> separte would more managable. But this is not very strong opinion.

Generating them into separate subdirs makes the Makefile rules slightly
more complicated. And actually nobody but a machine must manage these
generated files. And if there is need for debugging, they are easily
distinguishable by their file extension.

> If that is problematic for you, then I think that generating
> everything in something like 'src/doc/gen_ht' is better than plain
> 'src/doc' (the idea is that AXIOM book and possible other things can
> go into different subdirectories of 'src/doc'.

I'll think about that, but out-of-source build already separates sources
from generated files. I don't see a strong reason to create other subdirs.

> One extra thing: I would like to keep current practice of bundling
> generated .pht-s and viewports with release tarball. More
> precisely, I think it is important to bundle graphic .pht pages and
> viewports. But given that the simplest thing to do is to bundle all
> generated .ht and .pht pages. With directory arrangement in trunk
> this is relatively easy and there is reasonably clear distiction
> between real sources and generated files bundled into release tarball
> (the generated files are in src/paste). And generation of release
> tarball can be done by a simple script (see src/scripts/mkdist.sh).
> From this point of view generated '.ht' files should be in different
> subdirectory from '.ht' files which are sources.

All we want is "make dist" which would put the respective files into a
predefined location.

> BTW: I noticed curious thing: on my build machine real time for
> 'make all-input' after build in the htdoc branch seem to be 20s
> larger (that 120s versus 100s) than real time in trunk.

I haven't measured that myself, but note that there is the generation of
the .ht files from .htex and a generation of some of the .help files.
But what exactly means "'make all-input' after build"? I thought that
I've stamped everything so that a remake should cost almost no time.

Ralf

[Waldek Hebisch]

Ralf Hemmecke wrote:
>
> > Structure of build_dir is supposed to parallel structure of src_dir.
>
> Well, that's the idea and one of the reasons that makes the "target"
> directory inside build_dir somewhat superfluous.
>
> > I am affraid that putting generation of everthing is src/doc is not
> > a good idea.
>
> Wait a minute. I said, I'll create bitmaps, htex, and ht subdirectories
> under src/doc. These are source files. To where I generate I didn't mention.
>
> But yes, the idea was to generate all the files inside src/doc.
> I really don't know why you care so much. Isn't the "target"
> subdirectory something you finally care about?

1) I had to many times to look at intermediate trash in build
directories (not only in FriCAS). So I care if things
are easy to find or not.
2) You may consider the patch as "final solution", but in
practice problems show up and require changes. So I
want things to be manageable.

> From what I see in the
> toplevel Makefile, installation basically works by copying over the
> "target" subdir to the installation location. If you need "target" for
> the algebra bootstrap, that's fine, but for most other things I consider
> it useless. All the Makefile targets that I have created that start with
> "copy-" would actually be targets that should be executed at "make
> install" time.
>
> > I would prefer generation of .ht pages to be in separate directory
> > from generating .pht-s and viewports. Basically they use separate
> > rules and each involves large number of files, so IMHO keeping them
> > separte would more managable. But this is not very strong opinion.
>
> Generating them into separate subdirs makes the Makefile rules slightly
> more complicated. And actually nobody but a machine must manage these
> generated files. And if there is need for debugging, they are easily
> distinguishable by their file extension.

I am affraid we are miscomunicating. This is software, everything
is doable with enough effort. The point is to make developement
as smooth as possible. Current FriCAS is far from ideal.
But I would like to avoid regressing. Size of directories may
look like a small thing. But IME both complicated hierarchies
with tiny directories and big "universal" directories are
problematic. The problems are not big, but the cost of
more managable organization is usually small. Again, while
problems due to big directories are small they cause
distraction exactly at time when distractions are highly
undesirable (during debugging).

> > If that is problematic for you, then I think that generating
> > everything in something like 'src/doc/gen_ht' is better than plain
> > 'src/doc' (the idea is that AXIOM book and possible other things can
> > go into different subdirectories of 'src/doc'.
>
> I'll think about that, but out-of-source build already separates sources
> from generated files. I don't see a strong reason to create other subdirs.
>
> > One extra thing: I would like to keep current practice of bundling
> > generated .pht-s and viewports with release tarball. More
> > precisely, I think it is important to bundle graphic .pht pages and
> > viewports. But given that the simplest thing to do is to bundle all
> > generated .ht and .pht pages. With directory arrangement in trunk
> > this is relatively easy and there is reasonably clear distiction
> > between real sources and generated files bundled into release tarball
> > (the generated files are in src/paste). And generation of release
> > tarball can be done by a simple script (see src/scripts/mkdist.sh).
> > From this point of view generated '.ht' files should be in different
> > subdirectory from '.ht' files which are sources.
>
> All we want is "make dist" which would put the respective files into a
> predefined location.

This is a possibility. But 'mkdist.sh' takes parameters and hence
can do more then generating releases. In principle 'make' can
do the same, but 'make' is rather weak as a programming language.
So I found using a separate script simpler.

> > BTW: I noticed curious thing: on my build machine real time for
> > 'make all-input' after build in the htdoc branch seem to be 20s
> > larger (that 120s versus 100s) than real time in trunk.
>
> I haven't measured that myself, but note that there is the generation of
> the .ht files from .htex and a generation of some of the .help files.
> But what exactly means "'make all-input' after build"? I thought that
> I've stamped everything so that a remake should cost almost no time.
>
> Ralf
>

> --
> 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 fricas-devel...@googlegroups.com.
> To post to this group, send email to fricas...@googlegroups.com.
> Visit this group at http://groups.google.com/group/fricas-devel.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>


--
Waldek Hebisch
heb...@math.uni.wroc.pl

[Waldek Hebisch]

Ralf Hemmecke wrote:
>
> > BTW: I noticed curious thing: on my build machine real time for
> > 'make all-input' after build in the htdoc branch seem to be 20s
> > larger (that 120s versus 100s) than real time in trunk.
>
> I haven't measured that myself, but note that there is the generation of
> the .ht files from .htex and a generation of some of the .help files.
> But what exactly means "'make all-input' after build"? I thought that
> I've stamped everything so that a remake should cost almost no time.

On the test machine I am doing build as follows:

time make -j 10 > mlogg 2>&1 && time make all-input > tst_logg 2>&1

Two times are reported: time for build and time for 'make all-input'.
I see only increase in _real_ time for 'make all-input'.

--
Waldek Hebisch
heb...@math.uni.wroc.pl

[Ralf Hemmecke]

> On the test machine I am doing build as follows:
>
> time make -j 10 > mlogg 2>&1 && time make all-input > tst_logg 2>&1
>
> Two times are reported: time for build and time for 'make all-input'.
> I see only increase in _real_ time for 'make all-input'.

Let me first understand what your reason is for doing "make all-input"
after a full build?

We have

all: all-ax all-contrib
all-contrib: all-src
all-input: all-src

so ideally "make all-input" shouldn't remake anything.

Am I missing something?

Ralf

[Waldek Hebisch]

Ralf Hemmecke wrote:
>
> > On the test machine I am doing build as follows:
> >
> > time make -j 10 > mlogg 2>&1 && time make all-input > tst_logg 2>&1
> >
> > Two times are reported: time for build and time for 'make all-input'.
> > I see only increase in _real_ time for 'make all-input'.
>
> Let me first understand what your reason is for doing "make all-input"
> after a full build?

Build in parallel, test serialy.

> We have
>
> all: all-ax all-contrib
> all-contrib: all-src
> all-input: all-src
>
> so ideally "make all-input" shouldn't remake anything.
>

Yes ideally "make all-input" shouldn't remake anything, but
there is some possibility for bugs. "make all-input" needs
to recompute dependencies, if that got more complicated,
then it may take more time. There may be queued disk
I/O in system buffers... Speculation is of little use,
one needs to meausre and experiment to find what (if any)
is going on.

--
Waldek Hebisch
heb...@math.uni.wroc.pl

[Ralf Hemmecke]

> time make -j 10 > mlogg 2>&1 && time make all-input > tst_logg 2>&1

Waldek, can you give the exact setup. When I currently compile trunk
(r1567) (noweb already installed, no libaxiom.al build, not making gpht
(neither copying nor building)) I get for the above command:

-j10 all-input
real 4:16 2:05
user 18:51 1:49
sys 1:11 0:10

With my current htexdoc branch (xvfb-run included, i.e graphics will be
made)

real 5m16.146s
user 19m12.852s
sys 1m17.616s

real 2m26.164s
user 1m53.332s
sys 0m11.464s

I'm currently trying to add "make dist" and realized already that
remaking inside src/doc needlessly build some files again. That's about
to be removed in a future patch.

Ralf

[Waldek Hebisch]

>
> > time make -j 10 > mlogg 2>&1 && time make all-input > tst_logg 2>&1
>
> Waldek, can you give the exact setup.

I tried on quad core Core i7 running Debian 6.0 using sbcl 1.1.6.
Configure command line was:

../rhx3/fricas/configure --with-lisp=/mnt/lv0/fricas/usr/bin/sbcl --enable-gmp > clogg 2>&1

for htexdoc branch and similar for trunk. No xvfb-run installed.

> When I currently compile trunk
> (r1567) (noweb already installed, no libaxiom.al build, not making gpht
> (neither copying nor building)) I get for the above command:
>
> -j10 all-input
> real 4:16 2:05
> user 18:51 1:49
> sys 1:11 0:10
>
> With my current htexdoc branch (xvfb-run included, i.e graphics will be
> made)
>
> real 5m16.146s
> user 19m12.852s
> sys 1m17.616s
>
> real 2m26.164s
> user 1m53.332s
> sys 0m11.464s
>

That is similar to my results:

trunk htexdoc
build all-input build all-input
real 3m36.074s 1m40.605s 3m39.047s 1m59.044s
user 15m26.018s 1m32.530s 15m30.198s 1m33.482s
sys 1m4.736s 0m7.552s 1m5.604s 0m7.964s


Note that system and user time for all-input is almost the same, but
there is almost 20% difference in real time. For build differences
are small enough to ignore (you got longer build time but that is
understandable, since in htex branch you generate graphic output).
However, for 'all-input' the difference is strange and large
enough to ask for explanation.
--
Waldek Hebisch
heb...@math.uni.wroc.pl

[Ralf Hemmecke]

> That is similar to my results:
>
> trunk htexdoc
> build all-input build all-input
> real 3m36.074s 1m40.605s 3m39.047s 1m59.044s
> user 15m26.018s 1m32.530s 15m30.198s 1m33.482s
> sys 1m4.736s 0m7.552s 1m5.604s 0m7.964s
>
>
> Note that system and user time for all-input is almost the same, but
> there is almost 20% difference in real time. For build differences
> are small enough to ignore (you got longer build time but that is
> understandable, since in htex branch you generate graphic output).
> However, for 'all-input' the difference is strange and large
> enough to ask for explanation.

Interesting, you must have a somewhat faster i7 than me. Anyway, after
my revision, all-input does not spend much time inside src/doc, because
remake there, does not rebuild anything.

I've rebased my patches on top of trunk@1567.

0b7f059 fix htexdoc
b2da98f add releaseNotes and "Changes to Spad" into ug15
5b44d1d re-establish HyperDoc content from .htex sources
ad4a464 Turn on outline after graphic reset.

I've currently left the "fix htexdoc" commit separate, so that you see,
what I've modified. Eventually it will be merged with the "re-establish
HyperDoc content from .htex sources" patch.

https://github.com/hemmecke/fricas/commit/0b7f05977fb412aa6ca4812b1767b740923c6db4

Ralf

=================================================

trex:~/scratch/build/fricas-master>time make -j 10 > mlogg 2>&1 && time

make all-input > tst_logg 2>&1

real 4m24.921s
user 19m0.772s
sys 1m13.536s

real 2m8.512s
user 1m53.088s
sys 0m10.024s

trex:~/scratch/build/fricas-htexdoc>time make -j 10 > mlogg 2>&1 && time

make all-input > tst_logg 2>&1

real 5m7.104s
user 19m13.512s
sys 1m17.268s

real 2m6.374s
user 1m50.656s
sys 0m10.088s