asymptote-developers — For discussion of Asymptote development

[Asymptote-developers] Not able to compile the code for 3D crystal strcuture drawing

[Nitin B. . <nit...@ph...>]

I am trying to compile asymptode code from the link
https://tex.stackexchange.com/questions/141363/draw-realistic-3d-crystal-structures-diamond

But it returns me the error material function is not defined. I search the
asymptote manual and found reference to material structure on pg 133
and 134.

How to go about compiling this?
Basically I am looking for stick and ball model routine for drawing crystal
structures. Above link provides the solution but I am not able to compile
it.

Kindly guide in this matter.
Regards,
NB

-- 
Nitin Bijewar
Assistant Professor,
Department of Physics,
University of Mumbai,

http://mu.ac.in/portal/distance-open-learning/faculty/department-of-physics/
email: nit...@gm...


*"Three things are necessary to make every man great, every nation great,*

*1. conviction of power of goodness*

*2.Absence of jealousy and suspicion*
*3. Helping those who try to be and do good".....Swami Vivekananda*

[Asymptote-developers] asymptote-2.32: make asymptote.pdf in doc/ fails

[Andrey G. G. <A.G...@in...>]

make asymptote.pdf
<skipped>
../asy -dir ../base -config "" -render=0 -f pdf -noprc axis3.asy
../base/plain_Label.asy: 670.23: reading array of length 4 with 
out-of-bounds index 4
Makefile:41: recipe for target 'axis3.pdf' failed
make: *** [axis3.pdf] Error 1

Andrey

[Asymptote-developers] Hyperbolic geometry macros version 0.76

[Raoul <ra...@bl...>]

Hi *,

Again, after a long time I did a huge update to
my asymptote macros for hyperbolic geometry.

There are now:

-> Angle-calculation between two lines and "between" three points.
-> Finished invalidity framework for invalid objects. (eg non-existing intersectionpoints)
-> A much improved intersection calculation for {line, segment, ray, circle}<->{line, segment, ray, circle} intersections
-> Hyperbolic circles given by center and one point on the circle.
-> Many new boolen methods for checking properties (eg is_on_segment(segment, point) )
-> New measuring methods for triangles calculating size of angles, sides, area.

With these improvements the software is now ready for many (basic)
compass and straightedge constructions in the poincare unitdisk.

There are some nice new demos[1]. I compiled a page[2] with some sample constructions
well known from euclidean geometry too.

[1]: http://raoul.koalatux.ch/sites/hyperbolic_geometry/hyperbolic_demos.html
[2]: http://raoul.koalatux.ch/sites/hyperbolic_geometry/hyperbolic_constructions.html

You can get the released version 0.76 from the usual place[3] or
check out my git repository[4,5]. There is no 0.76 branch and further
development will take place in the master branch.

[3]: http://raoul.koalatux.ch/sites/hyperbolic_geometry/hyperbolic_geometry.html
[4]: (git) http://git.koalatux.ch/raoul/hyperbolic_geometry.git/
[5]: (overwiev) http://git.koalatux.ch/?p=raoul/hyperbolic_geometry.git;a=summary


-- Greetings

Re: [Asymptote-developers] ConTeXt support

[John B. <bo...@ma...>]

First of all, I would like to move all further discussion on this list
to the Asymptote Forum:

http://sourceforge.net/forum/forum.php?forum_id=409349

We plan to shut down this mailing list very soon (for the reasons mentioned
in my latest forum post).

> somebody on the ConTeXt mailing list is asking about ConTeXt support
> in Asymptote (that is: he would like to use ConTeXt for processing
> labels instead of tex/pdftex/latex/pdflatex/xelatex).

Great to hear! Several years ago I was encouraged by the ConTeXt community
to add the necessary hooks (routines like beginlabel in settings.cc) to
support arbitrary TeX engines. I was assured that the ConTeXt community
would then fill in these hooks, but that unfortunately never happened;
it seems that the ConTeXt community is very small. So that is where we are
stuck.

> I would like to ask:
> 
> - How does development work in your community? If we would like such a
> feature to be added: what would you expect us to do? Send in the
> request and help you with details and a list of requirements of
> ConTeXt support? Code everything and send you patches?

We would prefer patches in this case since we don't know anything about
ConTeXt.

> - What's your estimated amount of work that's needed to adapt
> Asymptote? How deeply is LaTeX hardcoded in it? (When I took a look at
> the source code of LyX I gave up straight away; asymptote somehow
> looks doable, but I didn't have a closer look.)

Just fill in the hooks and follow what we did to support the pdflatex engine.

> - How does Asymptote deal with labels after they are processed by some
> TeX engine? Is it OK if ConTeXt generates just PDF or are DVI/(E)PS
> files a necessary requirement?

In 2D, Asymptote prepares a TeX/LaTeX file that is then typeset by the 
appropriate tex engine to produce the final DVI/EPS or PDF file.
In 3D, Asymptote extracts the fonts from the generated postscript code.
(Here it might be better if we overload the Poscript "/fill" operator
instead of the "/v" procedure; we can help with that).

> ConTeXt works with three engines: pdftex, xetex and luatex. All the
> three generate PDF files, though, if really really really needed,
> pdftex could (conditionally and most probably buggy) generate dvi
> files. The commands to compile TeX files with the three engines
> mentioned is "texexec", "texexec --xtx" and "context" consequtively.

There's no need to create DVI file; the pdflatex texengine doesn't create a
DVI file either. In 3D, you'll probably want to use ghostscript with the
epswrite driver to convert PDF to EPS (unless you want to parse PDF
directly :-).

> Unrelated:
> 
> - Is there any effort going on to include Asymptote in TeX Live? It
> would simplify life a lot if Asymptote was part of TL.

Sure, we are open to that, if it helps. Are you talking about just asymptote.sty
or the actual Asymptote program? I don't think it was ready for that until
now, since we have been make new releases every week or two. But the 3D
support finally seems to have stabilized now.

Probably the simplest solution is to mirror Asymptote from the main
sourceforge site.

> > - I have no idea how to compile Asymptote. What's the best place to
> ask such questions? That's probably the form on the website, but if
> anyone has a clue what's going on, please let me know. I'm trying to
> compile on Mac OS X with --prefix=/opt/local (I have macports
> installed).
> 
> Creating main.d
> g++ -Wall -ansi -DHAVE_CONFIG_H -D_FILE_OFFSET_BITS=64 -DUSEGC  -g -O3
>  -I . -I/opt/local/include/gc -I/usr/include/gc -o runtime.o -c
> runtime.cc
> runtime.in: In function 'void run::store_history(HISTORY_STATE*)':
> runtime.in:613: error: 'struct HISTORY_STATE' has no member named 'entries'
> runtime.in:613: error: 'struct HISTORY_STATE' has no member named 'entries'
> runtime.in: In function 'void run::cleanup()':
> ...
> 

You must have a very old copy of the GNU readline library (configure tries
to detect this, by the way). Just upgrade it and you'll be fine. The latest
version is 6.0, but 5.2 works fine as well. From the manual:

"Note that many MacOS X (and FreeBSD) systems inexplicably ship
with an extremely old GNU readline version (4.1,
dated 21 March 2000). For full interactive functionality,
readline version 4.2 or later (16 April 2001) is required."

-- John

Re: [Asymptote-developers] ConTeXt support

[Michail V. <ma...@ia...>]

Dear Mojca, John and All,

On Sun, 19 Apr 2009, Mojca Miklavec wrote:

> - What's your estimated amount of work that's needed to adapt
> Asymptote? How deeply is LaTeX hardcoded in it? (When I took a look at
> the source code of LyX I gave up straight away; asymptote somehow
> looks doable, but I didn't have a closer look.)
>
> - How does Asymptote deal with labels after they are processed by some
> TeX engine? Is it OK if ConTeXt generates just PDF or are DVI/(E)PS
> files a necessary requirement?

As far as I do not understand, 2D label mechanism involves interplay
of Asymptote and TeX engine unintelligible to me (both TeX the language 
and TeX the program are beyond my understanding). On the other hand,
3D labels are produced by processing the label with an external engine
producing a EPS file, which is later run through ghostscript with
some operators redefined so that it prints information on the lines and 
curves the output consists of. This later stage is now tailored to 
processing dvips output, but that seems to be easy to fix: EPDF or
EPS output of the external typesetter is to be  processed by epswrite 
ghostscript device, that reduces everything to lines and curves.
If we take epswrite output, redefine "fill", "eofill", "stroke" to print
information on the path in the way it is now done for "show" and run it 
thru ghostscript again we will get the same info Asymptote gets now.
This set of curves can (with hopefully small changes in Asymptote) be used
for 2D labels (or may be include the EPS/EPDF directly?).

That gives a strudy system, decouples Asymptote from LaTeX, allows for 
exotic typesetters like groff, but may slightly harm quality of 2D labels
due to losses in the process of conversion to Asymptote curves and for 
sure will increase run time due to spawing typesetter process and 
ghostscript for any label.
But it may be possible to typeset and ghostscript all labels in one batch 
run.

> - Is there any effort going on to include Asymptote in TeX Live? It
> would simplify life a lot if Asymptote was part of TL.

There seems to be a feud between grand wizzards of Asymptote and TeXLive

http://groups.google.com/group/comp.text.tex/browse_thread/thread/37143f0885a4d884?hl=en#

        Sincerely, Michail

[Asymptote-developers] ConTeXt support

[Mojca M. <moj...@gm...>]

Hello,

somebody on the ConTeXt mailing list is asking about ConTeXt support
in Asymptote (that is: he would like to use ConTeXt for processing
labels instead of tex/pdftex/latex/pdflatex/xelatex).

I would like to ask:

- How does development work in your community? If we would like such a
feature to be added: what would you expect us to do? Send in the
request and help you with details and a list of requirements of
ConTeXt support? Code everything and send you patches?

- What's your estimated amount of work that's needed to adapt
Asymptote? How deeply is LaTeX hardcoded in it? (When I took a look at
the source code of LyX I gave up straight away; asymptote somehow
looks doable, but I didn't have a closer look.)

- How does Asymptote deal with labels after they are processed by some
TeX engine? Is it OK if ConTeXt generates just PDF or are DVI/(E)PS
files a necessary requirement?

ConTeXt works with three engines: pdftex, xetex and luatex. All the
three generate PDF files, though, if really really really needed,
pdftex could (conditionally and most probably buggy) generate dvi
files. The commands to compile TeX files with the three engines
mentioned is "texexec", "texexec --xtx" and "context" consequtively.

I'm not using Asymptote yet, but I'm ready to help.

Unrelated:

- Is there any effort going on to include Asymptote in TeX Live? It
would simplify life a lot if Asymptote was part of TL.

- I have no idea how to compile Asymptote. What's the best place to
ask such questions? That's probably the form on the website, but if
anyone has a clue what's going on, please let me know. I'm trying to
compile on Mac OS X with --prefix=/opt/local (I have macports
installed).

Creating main.d
g++ -Wall -ansi -DHAVE_CONFIG_H -D_FILE_OFFSET_BITS=64 -DUSEGC  -g -O3
 -I . -I/opt/local/include/gc -I/usr/include/gc -o runtime.o -c
runtime.cc
runtime.in: In function ‘void run::store_history(HISTORY_STATE*)’:
runtime.in:613: error: ‘struct HISTORY_STATE’ has no member named ‘entries’
runtime.in:613: error: ‘struct HISTORY_STATE’ has no member named ‘entries’
runtime.in: In function ‘void run::cleanup()’:
...

Thanks a lot,
    Mojca

Re: [Asymptote-developers] : Hyperbolic geometry

[raoul <ra...@bl...>]

Hi all,

I attached the main code, some tests and demos.

But be warned once again: the code is a big mess at the moment.
There are lots of things missing and even more bugs.

Until now, it's capable of drawing points and lines properly.
The code for triangles fails with most point-constellations.

For the near future (hopefully until end Q1 2008) I'would like to
implement all things, the NonEuclid software can do in the S1 Plane.


-- Raoul

Re: [Asymptote-developers] Hyperbolic geometry

[Andy H. <an...@ma...>]

It sounds interesting.  Please post the module and some examples.

Andy.

On Sun, 25 Nov 2007, Raoul wrote:

> Hi all,
> 
> Recently I did some coding for an asy package to easy hyperbolic geometry drawings.
> It's far from being finished, but it works for some simple things like points and lines.
> 
> If you are interested, I could poste some samples and/or sources.
> 
> 
> Greetings, Raoul
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Asymptote-developers mailing list
> Asy...@li...
> https://lists.sourceforge.net/lists/listinfo/asymptote-developers
> 

[Asymptote-developers] Hyperbolic geometry

[Raoul <ra...@bl...>]

Hi all,

Recently I did some coding for an asy package to easy hyperbolic geometry drawings.
It's far from being finished, but it works for some simple things like points and lines.

If you are interested, I could poste some samples and/or sources.


Greetings, Raoul

Re: [Asymptote-developers] autotoolization

[Gregg R. <de...@mo...>]

On 3 Sep 2007 22:02:15 -0600, John Bowman <bo...@ma...> wrote:

> On my IBM T60 dual core processor under FC6 (g++ 4.1.2), building with the
> system Boehm GC slows asy down by 30% relative to using the default
> single-threaded non-shared gc-7.0.

What's the version of the system gc?

> In my opinion the increased performance of a locally installed gc-7.0 justifies
> the slight nuisance of downloading an extra tar ball. I think the procedure is
> clearly explained in the documentation and by the configure script.

I guess it's mostly an aesthetic thing for me.  "Locally installed"
need not mean "installed within the source tree of my application".
My personal preference is to install versions of Boehm in /usr/local
and just link to the version I want.

Really what needs to be done is for the Boehm package to install with
version id - "libgc-7.0.a" or the like - and then use links to create
libgc et al.

> the appropriate configure options. But using an old unknown system version
> of gc is too much of an unknown for us to make this the default, given the

"Unknown" being the key word.  But the idea is to probe the system
version and use it if acceptable.  No point in forcing the user to
download and compile a copy of 7.0 if it's already installed as the
system gc.  To /require/ a particular version you'd just have to
change the config warning to an error.

BTW, the Boehm package is now using pkg-config, so the autoconf pkg I
wrote to discover the version is unnecessary in principle.
Unfortunately, they use a hyphen in the .pc filename, which means
autotools choke on it!

> Interestingly, though, when I tried doing a local build of gc-7.0 with
> GCOPTIONS=""
> and linking with pthreads, I noticed no difference in speed relative to
> default single-threaded build.

That's interesting.  I wonder why.

-gregg

Re: [Asymptote-developers] autotoolization

[John B. <bo...@ma...>]

> On 20 Aug 2007 09:30:36 +0200, John Bowman <bo...@ma...> wrote:
> > There is a good reasons for having Asymptote build a single-threaded
> > version of gc. From the manual:
> >
> Yes, I saw that; but that's a reason to _use_ a single threaded gc;
> it's not a reason for Asymptote to assume responsibility to _build_
> the gc.  If the user has already built and installed a single-threaded
> gc, for example, it would be pointless and presumptuous to repeat the
> exercise in a client source tree. After all, it's an optional package,
> and Asymptote doesn't build fftw/gsl.  Better to put the user in
> control.
> 
> Note that I made a note in the INSTALL file about pros/cons of
> different memory management configs; "single threaded is faster" might
> be sufficient, but a little more detail would be nice too - is it
> faster on all platforms?  Even on multi-core machines? etc. - one
> would think a multithreaded version would be faster, after all.

On my IBM T60 dual core processor under FC6 (g++ 4.1.2), building with the
system Boehm GC slows asy down by 30% relative to using the default
single-threaded non-shared gc-7.0.

In my opinion the increased performance of a locally installed gc-7.0 justifies
the slight nuisance of downloading an extra tar ball. I think the procedure is
clearly explained in the documentation and by the configure script. 

Moreover, we test releases carefully only against the version of gc the
release was built for. These gc releases tend to come out about every six
months and most system versions of gc are very much older than that. 

Of course, if the user wants, he or she may override these defaults with
the appropriate configure options. But using an old unknown system version
of gc is too much of an unknown for us to make this the default, given the
delicate nature of garbage collection in the first place (especially on 32
bit machines). That would add one more set of unknowns for us to first sort
out when addressing reports of memory leaks and segmentation faults.

Interestingly, though, when I tried doing a local build of gc-7.0 with
GCOPTIONS=""
and linking with pthreads, I noticed no difference in speed relative to
default single-threaded build.

-- John

Re: [Asymptote-developers] boehm autoconf

[Gregg R. <de...@mo...>]

On 8/21/07, Gregg Reynolds <de...@mo...> wrote:
>
> AC_BOEHM(7.0)
>

Make that AX_BOEHM(7.0), or ASY_BOEHM if you prefer.

A new version has been uploaded with minor changes.  Open questions:

  - checking for mult- v. single-threaded build is naive, since lots
of threading libraries are supported.  I'm not sure GC_thr_init is a
reliable feature test.

  - is it even worth it checking for build type?  I think so; it's
already helped me keep track of different versions and build types.
Of course, a beohm-config administrative program packaged with the
distrib would be nicer.

-gregg

[Asymptote-developers] boehm autoconf

[Gregg R. <de...@mo...>]

I turned the autoconf code fragment I posted as a patch recently and
turned it into AC_BOEHM(VERSION).  Rather than clutter the patch queue
with something that isn't really a patch, I posted it on the wiki page
at http://asymptote.wikidot.com/config:boehm.  You have to click on
the "files" button at the bottom of the page to get at the files.

I think you'll probably agree that

AC_BOEHM(7.0)

is fairly clean and simple.

-gregg

Re: [Asymptote-developers] autotool files

[Gregg R. <de...@mo...>]

On 8/20/07, Peter Ansell <pan...@ya...> wrote:
> At least in the way that boehm-gc is configured this seems to be a step in the wrong direction. Why is AC_CHECK_HEADER not good enough? You may have some interesting ideas, but moving away from a clean
....
"clean" v. "not so nice"?  De gustibus non disputandem.  All autotools
stuff looks ugly to me.

The only reason for the code I wrote is to check the version.  Can't
do that with headers, and the reason for checking the version is
because the Asymptote currently insists on its preferred version of
the GC.  The code checking for C++ support, it turns out, is no longer
necessary.

The right thing to do is probably to put the code into an AC_ feature
check and add it to http://autoconf-archive.cryp.to/.  Then it
collapses to a single feature test, probably one line in configure.ac.

Since GC is optional, --with-FOO is necessary.

My own preference is that while the documentation of a pkg like
Asymptote may explain the pros/cons of a particular configuration, and
may even *strongly recommend* a recent version, in the end it's the
user's call, and the user is free to say "none of your business".   So
my feeling is Asymptote should just use whatever I have installed.  On
the other hand, I also think it's a Good Thing to help the user
understand the implications of particular configurations, so I think
checking the version of the GC - which the user may not be capable of,
think of a user on a multi-user system - and emitting an FYI message
is appropriate.  I meant to add a check on the version number, and
emit a message like "Your version is outdated; an upgrade to the
latest version is highly recommended.  See the INSTALL file for
details".  Something like that, anyway, brief and to the point.  I
meant to, but forgot. ;)

The other reason for the code is to get rid of the stuff that builds the GC.

-gregg

Re: [Asymptote-developers] autotool files

[Peter A. <pan...@ya...>]

At least in the way that boehm-gc is configured this seems to be a step in =
the wrong direction. Why is AC_CHECK_HEADER not good enough? You may have s=
ome interesting ideas, but moving away from a clean =0A=0AOPTIONS=3D"-D_FIL=
E_OFFSET_BITS=3D64 "=0AGCLIB=3D=0AGCPPLIB=3D=0AGCNAME=3D"Boehm Garbage Coll=
ector"=0AGCOPTIONS=3D"--disable-threads --disable-shared --enable-cplusplus=
 "=0Aif test "x$ac_cv_use_gc" !=3D "xno" ; then=0A   OPTIONS=3D$OPTIONS"-DU=
SEGC "=0A   case $ac_cv_use_gc in=0A   system|*[[\\/]]*)=0A      if test "x=
$ac_cv_use_gc" =3D "xsystem"=0A      then INCL=3D"-I$prefix/include/gc" =0A=
      else INCL=3D"-I$ac_cv_use_gc/include/gc"=0A      fi=0A      AC_CHECK_=
HEADER(gc.h,=0A    AC_CHECK_LIB([gc],[GC_malloc],[=0A      LIBS=3D$LIBS"-lg=
c "=0A      AC_MSG_NOTICE([enabling system $GCNAME])],[=0A    AC_MSG_ERROR(=
$GCNAME library not found)]),=0A      AC_MSG_ERROR($GCNAME header file not =
found))=0A      ;;=0A   *)=0A      GCDIR=3D$ac_cv_use_gc=0A      AC_MSG_NOT=
ICE([enabling the $GCNAME $GCDIR])=0A      GCLIB=3D"\$(GC)/.libs/libgc.a"=
=0A      INCL=3D"-I\$(GC)/include"=0A      ;;=0A   esac=0Aelse=0A   GCDIR=
=3D=0A   AC_MSG_NOTICE([disabling the $GCNAME])=0Afi=0A=0A=0Ato a not so ni=
ce=0A=0AAC_ARG_WITH([boehm-gc],=0A    [AS_HELP_STRING([--without-boehm-gc],=
=0A        [disable support for boehm garbage collector])=0A    ],=0A    []=
,=0A    [with_boehm_gc=3Dyes]=0A)=0A=0AAS_CASE(=0A  ["x$with_boehm_gc"],=0A=
  [[xyes]],=0A  [=0AX_LIBS=3D$LIBS=0ALIBS+=3D-lgc=0AX_LDFLAGS=3D$LDFLAGS=0A=
LDFLAGS+=3D-L/usr/local/lib=0A  AC_MSG_CHECKING([for boehm gc in default in=
stall dirs])=0A   AC_RUN_IFELSE(=0A    [AC_LANG_PROGRAM(=0A[[=0A#include <s=
tdio.h>=0A#include <gc.h>=0Aextern unsigned GC_version;=0A]],=0A[[=0AFILE* =
fp;=0Aif (fp =3D fopen("conftest.out", "w"))=0A   ;=0Aelse return -1;=0A=0A=
if (fprintf(fp, "%d.%x", GC_version>>16, (GC_version & 0x00FFFF)>>8) > 0)=
=0A   return 0;=0Aelse return -1;=0A]])],=0A[=0Abv=3D`cat conftest.out`; AC=
_MSG_RESULT(version $bv)=0A],=0A[=0ALIBS=3D$X_LIBS=0ALDFLAGS=3D$X_LDFLAGS=
=0A  AC_MSG_RESULT([Cannot discover Boehm version])=0A  AC_MSG_ERROR([See t=
he "Memory Management" section of README for remedies.])=0A]=0A)=0A  ]=0A  =
[AC_MSG_CHECKING([for c++ support in boehm gc])=0A   AC_RUN_IFELSE(=0A[AC_L=
ANG_PROGRAM(=0A[[=0A#include <iostream>=0A#include <gc.h>=0A#include <gc/gc=
_allocator.h>=0A#include <gc/gc_cpp.h>=0A]],=0A[[=0A  GC_INIT();=0A  gc_all=
ocator<int> mygc;=0A  std::cout << "ok";=0A  return 0;=0A]])=0A],=0A[AC_MSG=
_RESULT([])],=0A[=0ALIBS=3D$X_LIBS=0ALDFLAGS=3D$X_LDFLAGS=0AAC_MSG_RESULT([=
not found])=0AAC_MSG_ERROR([See the "Memory Management" section of README f=
or remedies.])=0A]=0A)=0A],=0A  [xno], [AC_MSG_NOTICE([Disabling Garbage Co=
llection; using standard C++ memory managment])],=0A=0A  [=0AX_LIBS=3D$LIBS=
=0ALIBS+=3D-lgc=0AX_LDFLAGS=3D$LDFLAGS=0ABGCDIR=3D`(cd $with_boehm_gc; pwd)=
`=0ALDFLAGS+=3D-L$BGCDIR=0AAC_MSG_CHECKING([for boehm gc at $BGCDIR])=0A   =
AC_RUN_IFELSE(=0A    [AC_LANG_PROGRAM(=0A[[=0A#include <stdio.h>=0A#include=
 <gc.h>=0Aextern unsigned GC_version;=0A]],=0A[[=0AFILE* fp;=0Aif (fp =3D f=
open("conftest.out", "w"))=0A   ;=0Aelse return -1;=0A=0Aif (fprintf(fp, "%=
d.%x", GC_version>>16, (GC_version & 0x00FFFF)>>8) > 0)=0A   return 0;=0Ael=
se return -1;=0A]])],=0A[bv=3D`cat conftest.out`; AC_MSG_RESULT(version $bv=
)],=0A[=0ALIBS=3D$X_LIBS=0ALDFLAGS=3D$X_LDFLAGS=0A  AC_MSG_RESULT([Cannot d=
iscover Boehm version at $BGCDIR])=0A  AC_MSG_ERROR([See the "Memory Manage=
ment" section of README for remedies.])=0A])]=0A)=0A=0ADo you even use vers=
ion other than to output it using the file? On a note that would particular=
ly concern me as I was involved in the process of making asymptote-1.33 com=
pile on Gentoo is that I only had to patch one extra line to what was previ=
ously patched=0A=0Ahttp://bugs.gentoo.org/attachment.cgi?id=3D128499&action=
=3Dview=0A=0AAC_CHECK_HEADER(gc.h,=0A=0Abecame=0A=0AAC_CHECK_HEADER(gc/gc.h=
,=0A=0A=0AWith this version it is necessary to patch multiple lines due to =
the insistence on manually creating files which autoconf is able to make ni=
cely on its own. You really need to justify the extra complexity that you a=
re introducing.=0A=0APeter Ansell=0A=0A----- Original Message ----=0AFrom: =
Gregg Reynolds <de...@mo...>=0ATo: asy...@li...urcef=
orge.net=0ASent: Tuesday, 21 August, 2007 12:22:31 AM=0ASubject: [Asymptote=
-developers] autotool files=0A=0AI uploaded some files to http://asymptote.=
wikidot.com/config.  This is=0Ajust to make something available for your in=
spection, it's not a=0Acomplete patch.  I have to clean up my source tree b=
efore I can make a=0Aclean patch.=0A=0AThe main thing to notice is the migr=
ation of config values from=0Asettings.cc to configure.ac.  But I've also a=
ltered the configuration=0Aload logic, which is spread across several files=
.  Also there are=0Avarious minor name changes, e.g. setPath -> init_ModSea=
rchPath.=0A=0ASee the ChangeLog file for a summary.  It's incomplete, but n=
ot by much.=0A=0A-gregg=0A=0A----------------------------------------------=
---------------------------=0AThis SF.net email is sponsored by: Splunk Inc=
.=0AStill grepping through log files to find problems?  Stop.=0ANow Search =
log events and configuration files using AJAX and a browser.=0ADownload you=
r FREE copy of Splunk now >>  http://get.splunk.com/=0A____________________=
___________________________=0AAsymptote-developers mailing list=0AAsymptote=
-de...@li...=0Ahttps://lists.sourceforge.net/lists/lis=
tinfo/asymptote-developers=0A=0A=0A=0A=0A=0A=0A      ______________________=
______________________________________________________________=0AGet the Wo=
rld's number 1 free email service.=0Ahttp://mail.yahoo.com.au=0A

[Asymptote-developers] autotool files

[Gregg R. <de...@mo...>]

I uploaded some files to http://asymptote.wikidot.com/config.  This is
just to make something available for your inspection, it's not a
complete patch.  I have to clean up my source tree before I can make a
clean patch.

The main thing to notice is the migration of config values from
settings.cc to configure.ac.  But I've also altered the configuration
load logic, which is spread across several files.  Also there are
various minor name changes, e.g. setPath -> init_ModSearchPath.

See the ChangeLog file for a summary.  It's incomplete, but not by much.

-gregg

Re: [Asymptote-developers] autotoolization

[Gregg R. <de...@mo...>]

On 20 Aug 2007 09:35:16 +0200, John Bowman <bo...@ma...> wrote:
> P.S. Incidentally, the --enable-cplusplus BoehmGC configuration option is
> no longer required, due to recent improvements. I will probably remove that
> soon.

I suspected as much, since I couldn't get a c++ feature test to choke
on a gc compiled with --disable-cplusplus.

-g

Re: [Asymptote-developers] autotoolization

[Gregg R. <de...@mo...>]

On 20 Aug 2007 09:30:36 +0200, John Bowman <bo...@ma...> wrote:
> There is a good reasons for having Asymptote build a single-threaded
> version of gc. From the manual:
>
Yes, I saw that; but that's a reason to _use_ a single threaded gc;
it's not a reason for Asymptote to assume responsibility to _build_
the gc.  If the user has already built and installed a single-threaded
gc, for example, it would be pointless and presumptuous to repeat the
exercise in a client source tree. After all, it's an optional package,
and Asymptote doesn't build fftw/gsl.  Better to put the user in
control.

Note that I made a note in the INSTALL file about pros/cons of
different memory management configs; "single threaded is faster" might
be sufficient, but a little more detail would be nice too - is it
faster on all platforms?  Even on multi-core machines? etc. - one
would think a multithreaded version would be faster, after all.

-g

Re: [Asymptote-developers] autotoolization

[John B. <bo...@ma...>]

P.S. Incidentally, the --enable-cplusplus BoehmGC configuration option is
no longer required, due to recent improvements. I will probably remove that
soon.

Re: [Asymptote-developers] autotoolization

[John B. <bo...@ma...>]

There is a good reasons for having Asymptote build a single-threaded
version of gc. From the manual:

The above steps will compile an optimized single-threaded static
version of the Boehm garbage collector
(@url{http://www.hpl.hp.com/personal/Hans_Boehm/gc/}).
Alternatively, one can request use of a (presumably multithreaded and therefore
slower) system version of the Boehm garbage collector by configuring
instead with @code{./configure --enable-gc=system} (provided
that your system has the @code{libgc} and @code{libgccpp}
libraries). One can disable use of the garbage collector by configuring
with @code{./configure --disable-gc}

[Asymptote-developers] autotoolization

[Gregg R. <de...@mo...>]

Hi,

I mentioned some work on config/build stuff a few weeks ago on the
Help list.  I think the way to do this is for me to break the work
into discrete pieces, so it's be easier for the maintainers to
understand and test.

So I just uploaded piece number one to the "Patches" on the "Trackers"
tab on the sourceforge site.  It's a revision of the autoconf code for
handling the Boehm garbage collector.  It checks the version number of
libgc.a, and tests for c++ support.  Also supports --without-boehm-gc,
and --with-boehm-gc=/path/to/gc.  No option expressed means
--with-boehm-gc=yes, and searchs the Asymptote default install
directories.

It does away with building the GC, on grounds that that is not
Asymptote's job.  The Boehm GC is becoming quite common, so it's
better to treat it just like any other external package.  The INSTALL
file contains some rudimentary instructions for working with the GC.
'configure'-time error messages direct the user to the INSTALL file,
eliminating clutter in configure.ac.

I've only tested it on one Windows (cygwin) machine: Win2K, cygwin dll
1.5.24, gcc 3.4.4, autoconf 2.61, automake 1.10.

BUGS:  Just now realized I forgot to insert the warning message for
outdated gc versions.  That's an easy change, though.  The test for
c++ support needs to be checked by somebody more familiar with the GC
- I'm not certain my code properly tests a feature only available in
an --enable-cplusplus build.

To link against the gc dir within an existing Asy source tree, do either

  $ ./configure LIBS=-Lgc6.8 LDFLAGS=-lgc

or

  $ ./configure --with-boehm-gc=gc6.8

Sincerely,

Gregg

[Asymptote-developers] New list

[John B. <bo...@ma...>]

This list is intended for developer discussions of the Asymptote kernel.

-- John