Hi John,
down at Debian we got a bug report concerning a core dump in the following code:

        var casts = quote {
                public TWrap operator cast(TInner value)
                {
                        var obj = new TWrap;
                        obj.value = value;
                        return obj;
                }
                public TInner operator cast(TWrap obj)
                {
                        return obj.value;
                }
        };

        void define_wrapper(string type)
        {
                string wrapper = 'A' + type;
                string prog = 'public struct ' + wrapper + '{ ' + type + ' value; };';
                eval(prog, true);
                eval('typedef ' + wrapper + ' TWrap', true);
                eval('typedef ' + type + ' TInner', true);
                eval(casts, true);
        }
        define_wrapper('int');
        define_wrapper('real');

The backtrace is as follows:

(gdb) bt
#0  0x00007f99a2fb16a0 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007f99a2fb2cf7 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007f99a2fa9fca in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#3  0x00007f99a2faa042 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
#4  0x00005595e2d66ef0 in absyntax::exp::transAsType (this=0x2, e=..., target=0x5595e53bd200) at exp.cc:43
#5  0x00005595e2d5bc83 in absyntax::initializeVar (pos=..., e=..., v=0x5595e4ccbc00, init=0x2) at dec.cc:462
#6  0x00005595e2d5bf85 in absyntax::createVarOutOfOrder (pos=..., e=..., r=0x0, id=..., t=0x0, init=0x5595e4c5ecc0) at dec.cc:513
#7  0x00005595e2d5c072 in absyntax::decid::transAsField (this=0x5595e4c5ec00, e=..., r=0x0, base=0x5595e30b91c0 <types::pInferred>) at dec.cc:541
#8  0x00005595e2d59843 in absyntax::decidlist::transAsField (this=0x2, e=..., r=0x0, base=0x5595e30b91c0 <types::pInferred>) at dec.cc:571
#9  0x00005595e2d5e5c4 in absyntax::runnable::markTrans (e=..., this=<optimized out>) at dec.h:149
#10 absyntax::block::trans (this=0x5595e5281b90, e=...) at dec.cc:154
#11 0x00005595e2d9ced9 in absyntax::fundef::baseTrans (this=0x5595e4eec9a8, e=..., ft=0x5595e4ccbd20) at fundec.cc:254
#12 0x00005595e2d5bc83 in absyntax::initializeVar (pos=..., e=..., v=0x5595e4ccbcc0, init=0x2) at dec.cc:462
#13 0x00005595e2d9c7dd in absyntax::fundec::transAsField (this=0x5595e4eec980, e=..., r=0x0) at fundec.cc:315
#14 0x00005595e2d5df3d in absyntax::modifiedRunnable::transAsField (this=0x5595e4c5edc0, e=..., r=0x0) at dec.cc:328
#15 0x00005595e2d5e5c4 in absyntax::runnable::markTrans (e=..., this=<optimized out>) at dec.h:149
#16 absyntax::block::trans (this=0x5595e5281c80, e=...) at dec.cc:154
#17 0x00005595e2d5b334 in absyntax::runnable::markTrans (e=..., this=<optimized out>) at dec.h:149
#18 absyntax::runnable::transAsCodelet (this=0x5595e5281c80, e=...) at dec.cc:133
#19 0x00005595e2da603f in runRunnable (r=0x5595e5281c80, e=..., s=..., tm=TRANS_NORMAL) at process.cc:162
#20 0x00005595e2dac38a in itree::run (this=0x5595e4c57920, e=..., s=..., tm=TRANS_NORMAL) at process.cc:311
#21 0x00005595e2da72da in runCodeEmbedded (code=0x5595e5285280, e=..., s=...) at process.cc:897
#22 0x00005595e2d752a7 in vm::stack::runWithOrWithoutClosure (this=0x2, l=0xd, vars=0x0, parent=0x5595e53cbc88) at stack.cc:455
#23 0x00005595e2d751ae in vm::stack::runWithOrWithoutClosure (this=0x2, l=0x30, vars=0x0, parent=0x5595e4c79780) at stack.cc:513
#24 0x00005595e2d751ae in vm::stack::runWithOrWithoutClosure (this=0x2, l=0x2, vars=0x0, parent=0x5595e54cf890) at stack.cc:513
#25 0x00005595e2da60b0 in runRunnable (r=0x5595e53861e0, e=..., s=..., tm=TRANS_INTERACTIVE) at process.cc:168
#26 0x00005595e2dac38a in itree::run (this=0x5595e53ff140, e=..., s=..., tm=TRANS_NORMAL) at process.cc:311
#27 0x00005595e2dab6c0 in icore::doRun (this=0x2, purge=80, tm=TRANS_INTERACTIVE) at process.cc:234
#28 0x00005595e2da400d in icore::process (purge=<optimized out>, this=<optimized out>) at process.cc:257
#29 ifile::process (purge=<optimized out>, this=<optimized out>) at process.cc:396
#30 processFile (filename=<error reading variable: Cannot access memory at address 0xa>, purge=80) at process.cc:877
#31 0x00005595e2deece0 in asymain (A=0x2) at main.cc:135
#32 0x00005595e2b5c9d7 in main (argc=2, argv=0x7ffc064a5b70) at main.cc:215
(gdb) 

All the best

Norbert

This has been reported by Karl Berry about a problem in Makefile.in, about the line

if test ! -e revision.cc -o "$(revision)" != "$(last)"; then \

See also #21.

There's another, more difficult, problem. The expansion of that line is:

if test ! -e revision.cc -o "2.37" != "\1"; then \

That \1 is clearly not intended. It comes from:

last = $(shell cat revision.cc | sed -e 's/.*\"\(.*\)\";/\\1/')

which is trying to pick out the revision number from revision.cc:
const char *REVISION="2.37";

1. It would be better to use := than = on $(shell) lines. That way the
   shell run only happens once, which is much simpler for expansion and
   debugging.

2. I'm not sure that will solve the problem, though. What works for me
   to use \1 instead of \\1, but I can imagine that some shells would not
   be happy with that either. In which case I'm left with changing
   revision.cc to look like:

const char *REVISION= "2.37";

And then use something like
last := $(shell awk '{print $$NF}' | sed 's/";//g')

There should definitely be no need to -quote the " in this context.

3. Another alternative, simpler in some ways, would be not to expect
   users to run this complicated version target at all. After all, a
   person simply compiling unmodified source never expects, or wants, to
   change the version. They expect to compile what you give them. I.e.,
   remove version as a dependency for asy (and probably do other things).

Currently, operators followed by an equals sign always act on the right. For instance, a /= b; is equivalent to a = a / b;, with the b on the right. This is essential for some operators (-, /, %) and fine for others (+, ^), but it's the wrong thing to do for the * operator because when * is noncommutative, the action is generally on the left. For instance, the following line ought to work but currently doesn't:

currentpicture *= shift((-5,0));

Hi,

I find this filltype impact on dot function confusing and think that fix should be implemented.

There are two options:

1. Ignore filltype's drawpen in dot call (so it doesn't get rendered at all, zoom the attached output of the given example in order to see where it's rendered). This would somewhat preserve current behavior of dot function.
2. Respect explicitly given filltype's drawpen (if not nullpen) and use it instead of pen p (it would mean both dots are drawn yellow in the given example).

I can provide fix and pull request for any but let's decide first.

Kind regards, Ivan

size(20mm, 0);
dotfactor = 20;
defaultpen(miterjoin);
dot((0, 0), FillDraw(red, yellow));
dot((0.2, 0), Draw(yellow));
shipout(bbox(0, FillDraw(blue, blue)));

Hi

The TeXHead2 from three.asy looks rather ugly when rendered to PDF. Other outputs like .svg and .eps are fine though, as are .pdfs generated from .eps with epstopdf.

I attached a testfile, with a pdf and an eps rendering.
I'm using asymptote-2.41 and ghostscript-9.21 with Gentoo Linux.

Edit: Other ArrowHeads2 are affected too, not only TeXHead2
Edit2: Additionally, it seems that ArrowHeads3 (like DefaultHead3) aren't rotated properly in .eps-output

When used from tex files, my tests work ok. But when I try to run some more general tests I'm getting no "subject" on the kleinbottle testfiles I grabbed from Charles Staats' tutorial. I mean that although the background (transparent on the minimal version using render=0, white on the other) is present, the drawn bottle is missing. This is true for both png and pdf output but it worked ok in 2.41 (I've just tested the pngs in that to be certain).

The source file can be found at http://www.linuxfromscratch.org/~ken/other/kleinbottle.asy (apparently I cannot attach a source file to an issue)

Conversely, my variants of the 'torus' image from the same source work fine.

The following example illustrates that something is wrong with Asymptote's rendering of transparency in 3D:

The example consists of two greenish spheres behind an orange plane, which is partially transparent (orange+opacity(0.8)). The left sphere was intended to be partially transparent as well, its vertices are shaded with a gradient that includes a tiny bit of transparency (…+opacity(0.99)). The right sphere is almost the same, except that it is fully opaque (…+opacity(1)). Clearly, the rendering of the sphere on the left is wrong, the green color should not be able to cut through the orange plane.

This example is for demonstration of the issue. My actual use case consists of solid where I have chosen the vertex colors to be partially transparent, so that one can look "behind" the solid as well. One example of this would be a partially transparent globe where one can partially see the continents on the side that does not face the camera.

The version of Asymptote that I am using is

$ asy --version
Asymptote version 2.23 [(C) 2004 Andy Hammerlindl, John C. Bowman, Tom Prince]

The complete .asy file for generating the picture:

settings.outformat = "png";
settings.render = 16;

import three;
import palette;
import graph3;
size(5cm,0);

currentprojection = perspective((-0.8,1,1.5));

void setcolor(surface s, pen p) {
  s.colors( palette(s.map(xpart), Gradient(p,p) ) );
}

draw( box((-2,-2,-1),(2,2,1)), black );

surface s;
s = shift(-1Z) * surface( box((-2,-2), (2,2)) );
setcolor(s, blue);
draw(s);

s = shift(1Z) * surface( box((-2,-2), (2,2)) );
setcolor(s, orange+opacity(0.8));
draw(s);

// sphere
surface mkSphere(pen[] cs) {
  triple f(pair z)   { return expi(z.x,z.y); }
  real   g(triple v) {
    real z = zpart(v);
    return (z*z*z);
  }
  surface s = surface(f,(0,0),(pi,2pi),41,Spline);
  s.colors( palette(s.map(g), cs ) );
  return s;
}

surface s = shift(0.5X+0.5Y) * mkSphere( Gradient(green+opacity(0.99), 0.9*white, green) );
draw(s);

surface s = shift(-0.5X-0.5Y) *  mkSphere( Gradient(green+opacity(1), 0.9*white, green) );
draw(s);

gsl.cc: In function ‘void trans::gen_rungsl_venv(trans::venv&)’:
gsl.cc:1091:67: error: no matching function for call to ‘addGSLDOUBLE3Func(sym::symbol&, sym::symbol&, sym::symbol&, sym::symbol&)’
addGSLDOUBLE3Func<gsl_sf_ellint_D>(SYM(D),SYM(phi),SYM(k),SYM(n));
^
The obvious workaround is to use --disable-gsl, that works fine.+

Hello,

It seems that asy passes an invalid option --libgs to dvisvgm to produce SVG output:

$ asy -version
Asymptote version 2.37 [(C) 2004 Andy Hammerlindl, John C. Bowman, Tom Prince]
$ dvisvgm --version
dvisvgm 2.0.4
$  asy -f 'svg' -o '/tmp/t.svg' test.asy -v -v -v
[...]
dvisvgm -n --verbosity=3 --libgs=/usr/lib/libgs.so -o/tmp/t.svg --bbox=56.4094bp 53.8583bp 164.409bp 216.108bp /tmp/t_.dvi
unknown option --libgs
/usr/share/asymptote/plain_shipout.asy: 87.10: runtime: shipout failed

Howdy,

With asy 2.38 some of my images in a test file come out full page rather than properly cropped so multiple inages can't appear on a single typeset document. I enclose an example. Running asy on the enclosed asymptotemktest-6.asy (after unzipping) gives me the enclosed pdf file.

asymtotemktest-6.pdf
asymtotemktest-6.asy.zip

The code:

import three;
currentprojection=perspective(-2,5,1);

size(10cm);

surface s=surface((0,0,0)--(3,0,0)--(1.5,3*sqrt(3)/2,0)--cycle,
                  new triple[] {(1.5,sqrt(3)/2,2)});

draw(s,red, meshpen=blue);

I ran this using C-c C-c in Aquamacs (Xemacs for Mac OS X). The result was the following:

asy -V -wait "BezierTriangle"
/usr/local/share/asymptote/three_surface.asy: 70.29: reading array of length 1 with out-of-bounds index 3

Compilation finished at Wed Feb  3 19:25:48

after installing all the required dependencies, if i issue 'make all', the compilation halts midway. If, instead, I call just 'make', compilation proceeds with success. This I checked with 'make check', and the results were all OK.
After this, if I call 'make install', it halts in the same asy shell as before. But when calling asy from a new terminal runs just fine.
After calling 'make install', terminal output of the last few statements before halting is as follows:

(/usr/share/texlive/texmf-dist/tex/latex/graphics/dvipsnam.def)) (./diatom_.aux) <diatom_0.eps>)
Runaway argument?
{\vphantom {$10^4$}\definecolor {ASYcolor}{gray}{0.000000}\color {ASY\ETC.
! File ended while scanning use of \ASYalign.
<inserted text> 
                \par 
<*> \scrollmode\input diatom_.tex


*
(Please type a command or say `\end')
*

It would be nice if xasy was properly ported to Python 3.

I spent a few hours debugging xasy against Python 3 and here's where I'm stuck:

The function def updateCode(self,mag=1.0) from xasy2asy calls
self.asyCode += self.makeNodeStr(self.controlSet[count][0])

The problem is that self.controlSet is a list of map objects and Python 3 is no longer happy about it:

TypeError: 'map' object is not subscriptable

My first naive approach was the following:

cs = list(self.controlSet[count])
for node in self.nodeSet[1:]:
  self.asyCode += "..controls"
  cs = list(self.controlSet[count])
  self.asyCode += self.makeNodeStr(cs[0])
  self.asyCode += "and"
  self.asyCode += self.makeNodeStr(cs[1])
  self.asyCode += ".." + self.makeNodeStr(node) + "\n"
  count += 1

The problem is that list(map(...)) somehow deletes the contents of map, so that one can only access those variables once. See also http://www.artima.com/weblogs/viewpost.jsp?thread=98196. Do you know how to convert maps into proper array entries?

The libraries ffwt and gsl come with lib/pkgconfig/fftw3.pc and lib/pkgconfig/gsl.pc.
It would be nice if configure.ac would try to consult pkg-config to find them.

I would like to see functional mouse-scrolling events, for example in colour picker, but it would be very useful elsewhere as well:

Here's a minimal "proof-of-concept" for Mac OS X only; it would be nice to do a global binding though:

diff --git a/GUI/xasyColorPicker.py b/GUI/xasyColorPicker.py
index 4ba1584..117b592 100755
--- a/GUI/xasyColorPicker.py
+++ b/GUI/xasyColorPicker.py
@@ -219,7 +219,13 @@ class xasyColorDlg(Toplevel):
     Button(self,text="Cancel",command=self.cancel).grid(row=4,column=2,sticky=E+W,padx=5,pady=5)
     self.pframe.grid(row=1,column=0,columnspan=3,padx=10,pady=10)
     self.bind("<Return>",self.closeUp)
+    self.bind("<MouseWheel>", self.onMouseWheel)
     self.setColor(color)
+  def onMouseWheel(self, event):
+    # TODO: implement OS-specific behaviour
+    # http://stackoverflow.com/questions/17355902/python-tkinter-binding-mousewheel-to-scrollbar
+    # for OSX:
+    self.colorList.yview_scroll(-event.delta, "units")
   def closeUp(self,event):
     """Close the dialog forcibly"""
     self.destroy()

Some more info that I liked:

• http://stackoverflow.com/questions/17355902/python-tkinter-binding-mousewheel-to-scrollbar

Hello. I'm having a segfault occur with Asymptote 2.35 and Ghostscript 9.16 on a Kubuntu Trusty 64 bit system with both Asy and GS packages backported as is from Debian Sid, whereas with Asymptote 2.15 and GS 9.10 which come default with Kubuntu Trusty there are no problems. Please observe the following transcript and kindly advise as to how this can be fixed. Thanks.

$ apt-cache policy asymptote ghostscript | grep -B1 Installed
asymptote:
Installed: 2.35-2
--
ghostscript:
Installed: 9.16~dfsg-2
$ cat temp.asy
import three;
size(100,0);
path3 g=(1,0,0)..(0,1,1)..(-1,0,0)..(0,-1,1)..cycle;
draw(g);
draw(((-1,-1,0)--(1,-1,0)--(1,1,0)--(-1,1,0)--cycle));
dot(g,red);
$ asy -f pdf -noprc temp.asy
/usr/share/asymptote/three.asy: 2905.13: runtime: Stack overflow or segmentation fault: rerun with -nothreads
Aborted (core dumped)
$ asy -f pdf -noprc temp.asy -nothreads
/usr/share/asymptote/three.asy: 2905.13: runtime: Segmentation fault
$ asy -vvv -f pdf -noprc temp.asy -nothreads
Using configuration directory /home/samjnaa/.asy
Welcome to Asymptote version 2.35
cd /home/samjnaa
Processing temp
Loading plain from /usr/share/asymptote/plain.asy
Including plain_constants from /usr/share/asymptote/plain_constants.asy
Loading version from /usr/share/asymptote/version.asy
Including plain_strings from /usr/share/asymptote/plain_strings.asy
Including plain_pens from /usr/share/asymptote/plain_pens.asy
Including plain_paths from /usr/share/asymptote/plain_paths.asy
Including plain_filldraw from /usr/share/asymptote/plain_filldraw.asy
Including plain_margins from /usr/share/asymptote/plain_margins.asy
Including plain_picture from /usr/share/asymptote/plain_picture.asy
Loading plain_scaling from /usr/share/asymptote/plain_scaling.asy
Loading simplex from /usr/share/asymptote/simplex.asy
Loading plain_bounds from /usr/share/asymptote/plain_bounds.asy
Including plain_scaling from /usr/share/asymptote/plain_scaling.asy
Including plain_prethree from /usr/share/asymptote/plain_prethree.asy
Including plain_Label from /usr/share/asymptote/plain_Label.asy
Including plain_shipout from /usr/share/asymptote/plain_shipout.asy
Including plain_xasy from /usr/share/asymptote/plain_xasy.asy
Including plain_arcs from /usr/share/asymptote/plain_arcs.asy
Including plain_boxes from /usr/share/asymptote/plain_boxes.asy
Including plain_markers from /usr/share/asymptote/plain_markers.asy
Including plain_arrows from /usr/share/asymptote/plain_arrows.asy
Including plain_debugger from /usr/share/asymptote/plain_debugger.asy
Loading temp.asy from temp.asy
Loading three from /usr/share/asymptote/three.asy
Loading math from /usr/share/asymptote/math.asy
Loading embed from /usr/share/asymptote/embed.asy
Including three_light from /usr/share/asymptote/three_light.asy
Including three_surface from /usr/share/asymptote/three_surface.asy
Loading bezulate from /usr/share/asymptote/bezulate.asy
Loading interpolate from /usr/share/asymptote/interpolate.asy
Loading graph_splinetype from /usr/share/asymptote/graph_splinetype.asy
Including three_margins from /usr/share/asymptote/three_margins.asy
Including three_tube from /usr/share/asymptote/three_tube.asy
Including three_arrows from /usr/share/asymptote/three_arrows.asy
adjusting camera to (5.05146433627626,4.00006521093411,1.82827831658818)
adjusting target to (0.0514643362762574,6.5210934107533e-05,0.328278316588184)
/usr/share/asymptote/three.asy: 2905.13: runtime: Segmentation fault

After downgrading packages:

$ apt-cache policy asymptote ghostscript | grep -B1 Installed
asymptote:
Installed: 2.15-2build2
--
ghostscript:
Installed: 9.10~dfsg-0ubuntu10.4
$ asy -f pdf -noprc temp.asy
$ ls temp.pdf
temp.pdf

Current situation:

> int[] a = {1,2};
> a.cyclic = true;
> a   
0:  1
1:  2
> a.cyclic
true 
> reverse(a).cyclic
false 

It seems more consistent that if a is cyclic, then reverse(a) ought to be cyclic as well.

I'm a newbie, just installed asymptote.
I wanted to correctly link psview to asymptote.
I presumed config.asy must be there somewhere on the hdd.
I did a full search, nothing found.
After more searching on the web, i realized the file must be created by me.

This bit of info should be in the docs,
ideally both near psview installation information,
and in configuration file section.

It would save time and frustration.

I don't know if it is a bug or a feature request but asyptote does not seem to be ready to handly otf fonts via lualatex (as reported). Is it mandatory to produce a dvi file then converted by dvips? Should luatex be used in pdf output mode?

Thanks.

Here's one simple example:

Welcome to Asymptote version 2.36-19 (to view the manual, type help)
> import three;
> patch plane = patch(O -- (0,1,1) -- (1,1,2) -- (1,0,1) -- cycle);
> path3 line = (0,0,-1e-5) -- (1,1,2);
> cputime();
0.08u 0.01s 0.14U 0.03S 
> cputime();
0.00u 0.00s 0.14U 0.03S 
> real[][] isections = intersections(line, plane);
> cputime()
46.06u 0.04s 46.20U 0.07S 
> isections.length
1

Intersecting a line with a plane should not take 46 seconds, even if the line is nearly parallel to the plane. Here's a somewhat more complex example:

import three;
triple[][] P = {{(-0.866025403784439,0.5,0), (-0.866025403784439,0.5,-0.552284749830793), (-1.25375818409268,0.723857625084604,-1), (-1.73205080756888,1,-1)},
        {(-0.953793735509369,0.347980790156861,0), (-0.968163779838173,0.352863275764704,-0.552284749830793), (-1.39026076109554,0.506984178095615,-1), (-1.90758747101874,0.695961580313722,-1)},
        {(-1,0.175536663449861,0), (-1.01488606624617,0.17849332904426,-0.552284749830793), (-1.45749322604123,0.256069203000192,-1), (-2,0.351073326899723,-1)},
        {(-1,2.77555756156289e-16,0), (-1,2.77555756156289e-16,-0.552284749830793), (-1.44771525016921,4.01821700959705e-16,-1), (-2,5.55111512312578e-16,-1)}};
path3 line = (-1.61075487116513,4.47074286248665e-16,-0.921415042944955)--(500,400,200);
write(cputime());
intersections(line, P);
write(cputime());

The resulting output:

0.08u 0.02s 0.15U 0.03S 
32.66u 0.03s 32.81U 0.06S

In other words, this intersection took over 32 seconds to compute.

Possible strategy for fixing: in the final intersections function in path3.cc, before computing bounding boxes, apply a rotation (to both the path and the patch) so that three of the patches four corners lie in a plane parallel to the xy-plane. When the patch subdivision gets small enough, the patches will be nearly planar, and applying the suggested rotation can drastically reduce the volume of the bounding box (and hopefully also the extraneous path segments it catches).

Another suggestion, specifically targeted at the second example, is to keep halving the path3 until both halves intersect the bounding box of the patch. (Then put those two halves back together?) The idea is to make sure that extremely long path segments get cut down to size in the very first step; I don't know how well it would really work.

Under Arch Linux I get a conflicting declaration

/usr/include/unistd.h:463:12: Fehler: in Konflikt stehende Deklaration für C-Funktion »int usleep(__useconds_t)«
extern int usleep (__useconds_t __useconds);
^~~~~~
glrender.cc:9:16: Anmerkung: vorherige Deklaration von »int usleep(int)«
extern "C" int usleep(int);

When use option -tex xelatex with -f svg, will not use dvisvgm to genarate svg file, and the file output cannot be displayed in browser.

This is a comment on style, but I think it's an important one.

In some of the built-in modules, constants are made restricted. Examples include bool3 default and transform3 identity4. Unfortunately, this does not have the apparently intended effect of preventing code outside the module from modifying the variable value. For instance, external code is forbidden from saying default = (bool3)false but not from saying default.set = true, which amounts to the same thing and has who-knows-what unforeseen consequences. Such modifications can be made accidentally and give rise to unexpected behavior; see for instance https://sourceforge.net/p/asymptote/bugs/189/.

I suggest that the following rule of thumb be used: A variable x should not be declared restricted except in the following circumstances:

• The variable x is a built-in or function type (and hence cannot be modified without an x= assignment).
• The variable x is of an immutable type; i.e., all instance fields are either restricted or private, and are modified only when the object is created. [NOTE: any restricted fields should themselves follow these guidelines.]

Exceptions can be made whenever the important thing is actually to keep the same object, rather than to prevent that object from being changed. But I expect this is fairly infrequent.

Proposed solution: Go through every instance of restricted in the existing codebase (I count 163 instances using grep 'restricted' * | wc -l) and determine if it can be made to conform to these guidelines. In some cases it probably can't without breaking existing code (e.g., restricted surface unitsphere), but I suspect that making bool3 types immutable and identity4 private are both positive changes that won't break much; and whatever they break are positive changes that can easily be fixed.

I am willing to make these changes myself, but I don't want to start without approval from a project owner.

I get the below error when compiling on my centos 7 system:

/usr/include/c++/4.8.2/bits/hashtable.h:727:6: error: no matching function for call to ‘gc_allocator<std::__detail::_Hash_node<std::pair<const sym::symbol, trans::venv::namevalue>, true> >::construct(std::_Hashtable<sym::symbol, std::pair<const sym::symbol, trans::venv::namevalue>, gc_allocator<std::pair<const sym::symbol, trans::venv::namevalue> >, std::__detail::_Select1st, trans::venv::nameeq, trans::venv::namehash, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<true, false, true> >::__node_type*&, const std::piecewise_construct_t&, std::tuple<const sym::symbol&>, std::tuple<>)’ _M_node_allocator().construct(__n, std::forward<_Args>(__args)...); ^ /usr/include/c++/4.8.2/bits/hashtable.h:727:6: note: candidate is: In file included from memory.h:86:0, from common.h:35, from entry.h:15, from entry.cc:15: gc-7.6.0/include/gc_allocator.h:142:8: note: void gc_allocator<GC_Tp>::construct(gc_allocator<GC_Tp>::pointer, const GC_Tp&) [with GC_Tp = std::__detail::_Hash_node<std::pair<const sym::symbol, trans::venv::namevalue>, true>; gc_allocator<GC_Tp>::pointer = std::__detail::_Hash_node<std::pair<const sym::symbol, trans::venv::namevalue>, true>*] void construct(pointer __p, const GC_Tp& __val) { new(__p) GC_Tp(__val); } ^ gc-7.6.0/include/gc_allocator.h:142:8: note: candidate expects 2 arguments, 4 provided gmake: *** [entry.o] Error 1

If I set

export CC=/path/to/my/compiler/gcc
export CXX=/path/to/my/compiler/g++

those settings get ignored during configuration/compilation of GC and in on one particular setup that I use this leads to an error (and completely wrong behaviour).

The following patch helped:

--- a/Makefile.in
+++ b/Makefile.in
@@ -160,7 +160,7 @@
          mv gc-7.2 gc-7.2d; \
        fi
        cd $(GC) && \
-       ./configure $(GCOPTIONS); \
+       ./configure CC="$(CC)" CXX="$(CXX)" $(GCOPTIONS); \
        $(MAKE) check

 $(GCPPLIB): $(GCLIB)

but most likely CFLAGS, CXXFLAGS, LDFLAGS, CPPFLAGS etc. would also be needed.

I suspect this is also the reason why universal build fails on MacPorts.

I ran into this using asymptote with emacs org-babel, but can reproduce is directly. Basically, when I include the ".pdf" extension in the output file name when processing a script which includes an eps file, I get a "shipout error" from pdftex.

The attached zip file includes two .asy scripts, and a shell script that demonstrates the error. "diag.asy" creates an eps file, which is used in "test.asy". "test.sh" invokes:

asy -f pdf -o test.pdf -tex pdflatex test.asy

which generates the error. If instead I invoke:

asy -f pdf -o test -tex pdflatex test.asy

(without the ".pdf" extension) the command runs successfully.

asy-test.zip

Under Mac OS X it is desirable to use Command-S rather than Ctrl-S to save a file, similar for other actions.

Just as a proof of concept I tried the following:

    # this should be implemented properly with some hash table or some other kind of mapping
    # below is just an improvised version
    accelerators = ["Ctrl+N", "Ctrl+O", "Ctrl+S"]
    if platform.system() == "Darwin":
        accelerators = ["Command+N", "Command+O", "Command+S"]

    #the file menu
    self.fileMenu = Menu(self.mainMenu,tearoff=0)
    self.fileMenu.add_command(label="New",command=self.fileNewCmd,accelerator=accelerators[0],underline=0)
    self.fileMenu.add_command(label="Open",command=self.fileOpenCmd,accelerator=accelerators[1],underline=0)
    self.fileMenu.add_separator()
    self.fileMenu.add_command(label="Save",command=self.fileSaveCmd,accelerator=accelerators[2],underline=0)
    self.fileMenu.add_command(label="Save As",command=self.fileSaveAsCmd,underline=5)
    self.fileMenu.add_separator()

and

  # again, this would need a better implementation, but just to get the idea what is needed
  def bindGlobalEvents(self):
    #global bindings
    if platform.system() == "Darwin":
        self.parent.bind_all("<Command-z>",lambda q:self.editUndoCmd())# z -> no shift
        self.parent.bind_all("<Command-Z>",lambda q:self.editRedoCmd())# Z -> with shift
        self.parent.bind_all("<Command-o>",lambda q:self.fileOpenCmd())
        self.parent.bind_all("<Command-n>",lambda q:self.fileNewCmd())
        self.parent.bind_all("<Command-s>",lambda q:self.fileSaveCmd())
        # self.parent.bind_all("<Command-q>",lambda q:self.fileExitCmd()) # already default
    else:
        self.parent.bind_all("<Control-z>",lambda q:self.editUndoCmd())# z -> no shift
        self.parent.bind_all("<Control-Z>",lambda q:self.editRedoCmd())# Z -> with shift
        self.parent.bind_all("<Control-o>",lambda q:self.fileOpenCmd())
        self.parent.bind_all("<Control-n>",lambda q:self.fileNewCmd())
        self.parent.bind_all("<Control-s>",lambda q:self.fileSaveCmd())
        self.parent.bind_all("<Control-q>",lambda q:self.fileExitCmd())
    self.parent.bind_all("<F1>",lambda q:self.helpHelpCmd())

After some cleanup and proper coverage this would be a nice addition for OS X users. I don't know what is desired on Linux though.

Post from https://sourceforge.net/p/asymptote/discussion/409349/thread/f2e59550/
Operating system: Windows 10
TeX Distribution: Miktex
Asymptote Version: 2.38

When using asymptote in python (through the asymptote.py package), either no output is produced or error message is given.
My code (from this link: http://asymptote.sourceforge.net/doc/Interactive-mode.html):

from asymptote import *
g=asy()
g.size(200)
g.draw("unitcircle")
g.send("draw(unitsquare)")
g.fill("unitsquare, blue")
g.clip("unitcircle")
g.label("\"$O$\", (0,0), SW")

The asymptote.py file is in C:\Python27\Lib\site-packages\asymptote.py. It contains the following (unedited from default) lines:

    # Python module to feed Asymptote with commands
    # (modified from gnuplot.py)
from subprocess import *
class asy:
    def __init__(self):
        self.session = Popen(["asy", "-quiet", "-interactive"],stdin=PIPE)
        self.help()
    def send(self, cmd):
        self.session.stdin.write(cmd+'\n')
        self.session.stdin.flush()
    def size(self, size):
        self.send("size(%d);" % size)
    def draw(self, str):
        self.send("draw(%s);" % str)
    def fill(self, str):
        self.send("fill(%s);" % str)
    def clip(self, str):
        self.send("clip(%s);" % str)
    def label(self, str):
        self.send("label(%s);" % str)
    def shipout(self, str):
        self.send("shipout(\"%s\");" % str)
    def erase(self):
        self.send("erase();")
    def help(self):
        print "Asymptote session is open.  Available methods are:"
        print "    help(), size(int), draw(str), fill(str), clip(str), label(str), shipout(str), send(str), erase()"
    def __del__(self):
        print "closing Asymptote session..."
        self.send('quit');
        self.session.stdin.close();
        self.session.wait()

if __name__=="__main__":
    g = asy()
    g.size(200)
    g.draw("unitcircle")
    g.send("draw(unitsquare)")
    g.fill("unitsquare, blue")
    g.clip("unitcircle")
    g.label("\"$O$\", (0,0), SW")
    raw_input("press ENTER to continue")
    g.erase()
    del g

When I execute my program in pycharm, it usually gives the error
-: 4.1: syntax error
error: could not load module '-'
If I am executing line by line from the console, the asymptote window opens, but as I execute my commands, no output is given.
How can I fix this?

asymptote-2.41 issue:

Trying to run a very simple test file with a "settings.render" larger than 0 and command line option "-offscreen" yields "freeglut ERROR: Function called without first calling 'glutInit'."

settings.outformat = "png";
settings.render=8;
settings.prc = false;
size(5cm,0);
import three;
currentprojection=orthographic(5,4,2);
draw(unitcube,magenta);

Inserting init() after init_osmesa() in line 1443 of glrender.cc solved the problem. But I'm not sure if this has any other side effects.

I'm using Asymptote to generate a flowchart within a LaTeX document. The flowchart contains maths equations, parts of which need to be in bold font. Numerous calls of the LaTeX package bold \bm{...} causes asy to hang here:

------------
Run number 1 of rule 'cusdep asy tex asy/text-1'
------------
For rule 'cusdep asy tex asy/text-1', running '&do_cusdep( asy )' ...

The problem is found on both Mac OS X and Ubuntu.
asy version 2.41
TeX 3.14159265
latexmk 4.52c

The problem can be reproduced by combining the following .asy and .tex code

dia.asy:

import flowchart;

for(int i=0; i < 17; ++i) {
block test=roundrectangle("$\bm{F}=\bm{F}_{i-1}+\Delta\bm{F}$", (0,-i*30));
draw(test);
};

LaTeX:

\documentclass[fleqn]{article}

\usepackage{amsmath}

\usepackage{bm}
\usepackage[inline]{asymptote}
\def\asydir{asy}

\begin{document}

Flowchart test document.

\begin{figure}[ht]
  \centering
  \asyinclude[]{dia.asy}
  \label{fig:Flowchart}
\end{figure}

\end{document}

Changing the dia.asy file iterations to i < 16, will then compile the PDF with the \bm{...} package.

My current work-around is to avoid using the \bm{...} package and instead use \mathbf{...}. Unfortunately it means the maths characters are just bold and not in italics.

This is just a heads-up, in a place where (I hope) google will find it.

I am seeing two specific problems on (x86_64) gcc-6.1 linux (LFS/BLFS-svn versions):

1. With the texlive 2016 binary a 2D test I created last month now puts the heading line of text onto a first page, with the drawing at the same height (i.e. at the top) of the second page. With the same binary on a gcc-5.3 system it all continues to occupy one page, and also just one page on a wholly from-source 2016 build. I'll attach the old version, renamed from .tex to .txt because github won't let me attach a .tex file.
   triangles.txt
2. For 3D tests, at least for those using non-zero values of render and therefore requiring freeglut, both the binary and from-source versions of asy on gcc-6.1 fail to build (missing PDF when I run pdflatex after asy). The only message in the log is: /opt/texlive/2016/texmf-dist/asymptote/three.asy: 2905.13: runtime:

When I changed my search terms to drop gcc-6.1, google found several matches in recent years (broken glut, bad ghostscript), usually with some form of error message. So, I started adding flags to my asy invocation, and I established that adding '-V' the test now completes correctly.

My reading of the docs suggested this invokes gsview, which I do not have, but for use in TeX it is not a problem.

I also have some separate non-TeX asy tests to produce eps, png or pdf files based on the Staats tutorial. Again, the 3D versions with non-zero render values now need -V in the invocation on gcc-6.1 systems. That is double-edged : I can rotate the images (nice, very nice - I didn't know about that) but the new image is no-longer written. For my use-case (just testing things work, and mostly as part of texlive) that is not a problem.

Log-Log scaling on currentpicture works for me as expected, but not on any other picture. E.g. this minimal example works as expected:
import graph;
scale(Log,Log);
size(200,IgnoreAspect);
real f (real x) {return x^2;}
draw(graph( f, 1, 16 ) );
xaxis("$x$",BottomTop,RightTicks);
yaxis("$y$",LeftRight,LeftTicks);

but the following code (which should given identical output) does not: log scale isn't applied, and the axis ticks are wrong:
import graph;
picture pic;
scale(pic,Log,Log);
size(pic,200,IgnoreAspect);
real f (real x) {return x^2;}
draw(pic, graph( f, 1, 16 ) );
xaxis(pic,"$x$",BottomTop,RightTicks);
yaxis(pic,"$y$",LeftRight,LeftTicks);
shipout(pic);

I need to get this working so I can draw multiple graphs on one picture. Have I done something subtly wrong here?

Hey there,

I'm having some trouble with the 3D content (the three module and graph3d, specifically) and as best as I can tell, the error does not seem to be located between keyboard and chair (apologies if so). Specifically,

size(5cm);
import three;
draw(unitsphere);

gets me into trouble. When I create a file with the above content and run asy on it, I get the following output on my terminal, and no output file is produced:

/usr/share/asymptote/three.asy: 2905.13: runtime: ⏎ 

Asymptote's exit status is 0. Running with -keep and/or -keepaux does not yield any additional files either; the only file is and remains the .asy file itself. Line 2905 in three.asy is the start of the shipout3 routine.

Running the above commands in an interactive asymptote session results in an error in plain.asy instead, but again on a line related to shipout(), if I'm not misinterpreting the results:

/usr/share/asymptote/plain.asy: 50.39: Singular matrix
> terminate called after throwing an instance of 'handled_error'
fish: “asy” terminated by signal SIGABRT (Abort)

After that, I'm dropped out of Asymptote into my shell again (fish, in this case). When running in Bash, I get an Aborted (core dumped) error message instead. Exit status of Asymptote is 134.

I'm running Arch Linux (4.9.70-1-lts kernel) and have tried the Asymptote version from the official repos (2.41-2), the AUR package (which pulls from github), and compiling and installing the master branch from github manually (just to be on the safe side). All three attempts have had the same result.

I have come across this thread in my search too (as well as some older issues mentioning segfaults, none of which I have been able to use to solve my problem yet): https://sourceforge.net/p/asymptote/discussion/409349/thread/6d0a0979/

Based on that, I compiled a checkout of the current master branch from github without sigsegv as the user in this thread did, but unlike for them, this did not change anything for me (though the user who said this solved their issue is not the OP of that thread).

The example code posted by OP in that thread results in the same behavior on my machine as my own minimal example above. It errors out when calling the draw command in the example, on line 2905 in three.asy when trying to compile the drawing as a file and on line 50 of plain.asy when running the commands interactively.

Other than that, Asymptote has been working splendidly. I have had no issues with anything two-dimensional.

If you need any more information, let me know.

This example file:

\documentclass{article}
\usepackage{asymptote}
\begin{document}
\begin{asy}
size(1cm);
draw(unitsquare);
\end{asy}
\end{document}

does not compile with lualatex. It works fine with pdflatex. The error message is:

! error:  (file "bug-1".pdf) (pdf backend): cannot find image file '"bug-1".pdf'
!  ==> Fatal error occurred, no output PDF file produced!

It happens on the second run of lualatex, after processing the .asy file with asy.

The problem seems to be on line 309 of asymptote.sty: \includegraphics[hiresbb]{"\AsyFile".pdf} which adds extra quotes.

I'm not sure how quoting should be done, but this thread:
https://www.tug.org/pipermail/luatex/2016-March/005793.html
might be related and suggests that luatex is stricter than pdflatex but not buggy (w.r.t. quoted filenames).

While trying to prepare an update for asymptote in pkgsrc to the 2.35 release, I am hitting an overflow in https://github.com/vectorgraphics/asymptote/blob/master/base/plain_Label.asy#L670. The build finishes with an additional check of i < g.length.

I'm not sure that is correct. We still have a (local) patch for dealing with TEXMFLOCAL having more than one component, I don't know if that is related.

It is not clear to me if this is a compiler issue or an asymptote issue, but when I try to build asymptote 2.41 for Fedora 28 (using gcc 8.0.1), the build succeeds, but asy dumps core during make all:

• make all
  ../asy -dir ../base -config "" -render=0 -h 2>&1 | grep -iv Asymptote > options
  ../asy -dir ../base -config "" -render=0 -f pdf -noprc Hobbycontrol.asy
  ../asy -dir ../base -config "" -render=0 -f pdf -noprc binarytreetest.asy
  ../asy -dir ../base -config "" -render=0 -f pdf -noprc quartercircle.asy
  ../asy -dir ../base -config "" -render=0 -f pdf -noprc leastsquares.asy
  ../asy -dir ../base -config "" -render=0 -f pdf -noprc logo.asy
  ../asy -dir ../base -config "" -render=0 -f pdf -noprc join3.asy
  ../asy -dir ../base -config "" -render=0 -f pdf -noprc helix.asy
  ../asy -dir ../base -config "" -render=0 -f pdf -noprc loggrid.asy
  ../asy -dir ../base -config "" -render=0 -f pdf -noprc beziercurve.asy
  ../asy -dir ../base -config "" -render=0 -f pdf -noprc log2graph.asy
  ../asy -dir ../base -config "" -render=0 -f pdf -noprc monthaxis.asy
  ../asy -dir ../base -config "" -render=0 -f pdf -noprc exp.asy
  ../asy -dir ../base -config "" -render=0 -f pdf -noprc loggraph.asy
  ../asy -dir ../base -config "" -render=0 -f pdf -noprc cube.asy
  ../asy -dir ../base -config "" -render=0 -f pdf -noprc errorbars.asy
  ../asy -dir ../base -config "" -render=0 -f pdf -noprc generalaxis.asy
  ../asy -dir ../base -config "" -render=0 -f pdf -noprc tile.asy
  ../asy -dir ../base -config "" -render=0 -f pdf -noprc shadedtiling.asy
  ../asy -dir ../base -config "" -render=0 -f pdf -noprc lineargraph.asy
  ../asy -dir ../base -config "" -render=0 -f pdf -noprc secondaryaxis.asy
  make: *** [Makefile:42: secondaryaxis.pdf] Aborted (core dumped)

gdb backtrace looks like this:

Core was generated by `../asy -dir ../base -config  -render=0 -f pdf -noprc secondaryaxis.asy'.
Program terminated with signal SIGABRT, Aborted.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50	  return ret;
[Current thread is 1 (Thread 0x7efefef8f880 (LWP 7110))]
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007efefb126591 in __GI_abort () at abort.c:79
#2  0x0000562977da26c8 in std::__replacement_assert (
    __file=0x2 <error: Cannot access memory at address 0x2>, __line=-1874640560, __function=0x0, 
    __condition=0x0) at /usr/include/c++/8/x86_64-redhat-linux/bits/c++config.h:2389
#3  0x0000562977fcd5ff in std::__cxx11::basic_string<char, std::char_traits<char>, gc_allocator<char> >::operator[] (__pos=<optimized out>, this=<optimized out>) at /usr/include/c++/8/bits/char_traits.h:285
#4  camp::ifile::Read(std::__cxx11::basic_string<char, std::char_traits<char>, gc_allocator<char> >&) ()
    at fileio.cc:149
#5  0x0000562977eb0269 in camp::file::read<std::__cxx11::basic_string<char, std::char_traits<char>, gc_allocator<char> > > (this=0x562979832bb0, val="") at /usr/include/c++/8/bits/char_traits.h:285
#6  0x0000562977eb1ccc in run::readArray<std::__cxx11::basic_string<char, std::char_traits<char>, gc_allocator<char> > > (s=0x2, nx=0, ny=-1, nz=-1) at castop.h:109
#7  0x0000562977fb4127 in vm::stack::runWithOrWithoutClosure(vm::lambda*, vm::frame*, vm::frame*) ()
    at stack.cc:455
#8  0x0000562977fe8157 in runRunnable(absyntax::runnable*, trans::coenv&, vm::interactiveStack&, transMode) () at process.cc:168
#9  0x0000562977fefc9e in itree::run (this=0x56297947cd60, e=..., s=..., tm=TRANS_NORMAL)
    at process.cc:311
#10 0x0000562977fec9c7 in icore::doRun (this=0x7fff9043d000, purge=80, tm=TRANS_INTERACTIVE)
    at process.cc:234
#11 0x0000562977fe7991 in icore::process (purge=<optimized out>, this=<optimized out>) at process.cc:257
#12 ifile::process (purge=<optimized out>, this=<optimized out>) at process.cc:396
#13 processFile(std::__cxx11::basic_string<char, std::char_traits<char>, gc_allocator<char> > const&, bool) () at process.cc:877
#14 0x00005629780347df in asymain(void*) () at /usr/include/c++/8/bits/char_traits.h:320
#15 0x0000562977d87dcb in main () at main.cc:215
#16 0x00007efefb1281bb in __libc_start_main (main=0x562977d87d50 <main>, argc=10, argv=0x7fff9043d308, 
    init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff9043d2f8)
    at ../csu/libc-start.c:308
#17 0x0000562977d87f7a in _start () at drawpath.cc:165
(gdb) 

Under some circumstances, path3 does not render properly. A minimal example is included. The red dots depict where the path (black line) should be rendered. They differ quite dramatically. The problem occurs in OpenGL view (asy -V) as well as in rendering to eps.

Asymptote versions: 2.38, 2.39-26
OS: arch linux
glibc 2.24-2

minimal.asy.txt

When trying to build asymptote version 2.39, on mac OS X, without OpenGL support, the following error is produced:

clang++ -Wall -DHAVE_CONFIG_H -D_FILE_OFFSET_BITS=64 -DUSEGC  -D_THREAD_SAFE -pthread -DFFTWPP_SINGLE_THREAD  -g -O2 -g -O3 -ansi   -I. -I/nix/store/6mgacccigzqvb3q0rq6r667arxq0xpng-asymptote-2.39/include/gc -I/usr/include/gc -o beziertriangle.o -c beziertriangle.cc
In file included from beziertriangle.cc:8:
./drawsurface.h:36:3: error: unknown type name 'BezierCurve'
  BezierCurve R;
  ^
./drawsurface.h:142:3: error: unknown type name 'BezierCurve'
  BezierCurve R;
  ^
2 errors generated.

On the same build environment, version 2.38 builds fine (and works!).

I think the problem is related to commit 1d32440, by @johncbowman.

It would be helpful to have an option to disable sigsegv for cases when asy is compiled on a computer with sigsegv installed for another computer without it.

Perhaps an option like --without-sigsegv or --disable-sigsegv would do.

Just a note that trying to build 2.39 on gcc-6.3.0 without setting any flags, the build fails:
(sorry about the formatting)

g++ -Wall -DHAVE_CONFIG_H -D_FILE_OFFSET_BITS=64 -DUSEGC -pthread -DFFTWPP_SINGLE_THREAD -g -O2 -g
-O3 -ansi -fno-var-tracking -I. -I/opt/texlive/2016/include/gc -I/usr/include/gc -o camperror.o -c
camperror.cc
In file included from /usr/include/c++/6.3.0/unordered_map:35:0,
from memory.h:22,
from common.h:35,
from camperror.h:16,
from camperror.cc:14:
/usr/include/c++/6.3.0/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and
library support for the ISO C++ 2011 standard. This support must be enabled with the -std=c++11 or
-std=gnu++11 compiler options.

That was a surprise because I had already built and installed it, now I just wanted top get space and time measurements for an out-of-the-box build. My own builds use CFLAGS and CXXFLAGS of '-g -O2', mostly to save space by omitting debug symbols, plus I've never been keen on general -O3 use going back to when I had much slower hardware.

Changing CXXFLAGS to '-O2' removed the first -g, but the second and the -O3 were still present and the build failed. So the fix to build with gcc-6.3.0 is to export CFLAGS='-g -O2'. Probably won't affect many people.

Hi!

Almost a year ago I asked about the details of perpendicularmark function on Forum.

Since no one replied there, I got in contact with Philippe Ivaldi, and here is the excerpt from it:

I understand that perpfactor linearly scales the size of the mark,
while 'sqrt(1 + linewidth(p)) - 1' stands for some kind of margin. At
the first look, I couldn't get the logic behind 'sqrt(1 + x) - 1'
expression, but then I realized it must be like this: sqrt(1 + x) - 1
~ 1 + x/2 - 1 = x/2 => 'half of linewidth'.
If that is correct, was there any particular reason for not using just linewidth(p)/2?

Hi Ivan,
Thank you for the interest you port to this module.
I can't give you a good feedback to yours proposals because I coded this
module nine years ago and stop using Asymptote after this date.
For question iii, I don't really remember why I used sqrt(1 + linewidth(p)) - 1
instead of linewidth(p)/2…
Perhaps for a kind of offset when linewidth(p) increase ?
Do your best :)

So, I doubt that "sqrt(1 + x) - 1" actually stands for approximation of "x / 2", and started to test it and compare it with possible changes/improvements...

Here is the latest what I have:

import geometry;

unitsize(20mm);

void perpendicularmark_new(picture pic = currentpicture, point z,
                       explicit pair align,
                       explicit pair dir = E, real size = 0,
                       pen p = currentpen,
                       margin margin = NoMargin,
                       filltype filltype = NoFill)
{/*<asyxml></code><documentation>Draw a perpendicular symbol at z aligned in the direction align
   relative to the path z--z + dir.
   dir(45 + n * 90), where n in N*, are common values for 'align'.</documentation></function></asyxml>*/
  p = squarecap + miterjoin + p;
  if(size == 0) size = perpfactor * 3mm + linewidth(p) / 2;
  frame apic;
  pair d1 = size * align * unit(dir) * dir(-45);
  pair d2 = I * d1;
  path g = d1--d1 + d2--d2;
  g = margin(g, p).g;
  draw(apic, g, p);
  if(filltype != NoFill) filltype.fill(apic, (relpoint(g, 0) - relpoint(g, 0.5)+
                                             relpoint(g, 1))--g--cycle, p + solid);
  add(pic, apic, locate(z));
}


real opacity_level = 0.4;

real s = 0.4;
for (int i = 0; i < 15; ++i) {
  dot((i, 0), UnFill);
  perpendicularmark((point) (i, 0), NE, red + linewidth((1 + s)^i * linewidth()) + opacity(0.4));
  perpendicularmark_new((point) (i, 0), NE, green + linewidth((1 + s)^i * linewidth()) + opacity(0.4));
  if (i == 0) continue; // do not draw twice
  dot((-i, 0), UnFill);
  perpendicularmark((point) (-i, 0), NE, red + linewidth((1 - s)^i * linewidth()) + opacity(0.4));
  perpendicularmark_new((point) (-i, 0), NE, green + linewidth((1 - s)^i * linewidth()) + opacity(0.4));
}

test_perp.pdf

You can see what happens in "thick region" corresponding to red color:

• Inner "empty square" gets smaller and smaller...
• ...and once it disappear, things get bad onwards.

One might say that is veeery thick and no one will do something like that, but it would be convenient to have both clean code and proper geometric explanation for something implemented.

On the other hand, upper implementation (corresponding to green color) keeps that "empty square" of constant size (independent of pen), and does not have issues in "thick region".

I am about to submit Pull request fixing this issue in 15 minutes so you can take it under consideration.

Kind regards, Ivan

For other file names, Fig.asy,Pic.asy,Fig2.asy,Pic1.asy, e.t.c, After compiling *asy .asy, it will give *.eps. For Fig1.asy, it fails.

Hi!!!

If I want do draw a graph in log scale (regardless if it’s in x or y direction) and draw the axis it will not respect any label format.

This is a simple code to illustrate the problem in case of log scale in the y direction:

include graph;

size(10cm,7cm,false);
scale(Linear,Log);

dot((0,-1));
dot((20,log10(20)));

ticks myticks = Ticks(format = "$A = %.4g$");
xaxis("$x$",BottomTop,myticks);
yaxis("$y$",LeftRight,myticks);`

Now the "A = NUMBER" appears in the x axis but not in the y axis. The exact opposite is accomplished if the line:
scale(Linear,Log);
is changed by:
scale(Log,Linear);

Thank you! Cheers,

Contrary to what the documentation on p. 164 says, Asymptote executable ignores any value for the command-line option -prc. Here is a transcript:

C:\Program Files (x86)\Asymptote\asy.exe" -f pdf -prc false -render 0 pr.asy 
error: could not load module 'false'

And the same for the value true:

C:\Program Files (x86)\Asymptote\asy.exe" -f pdf -prc true -render 0 pr.asy 
error: could not load module 'true'

I am running Asymptote 2.41 on Windows 10.

Thank you.

When a label is put into picture and then a scale is applied on that picture, the label does not scale the right way.

Minimal Reproducer:

picture pic;
label(pic, Label("G"), (0,0));
shipout("pic", yscale(-1) * bpic);

Suggested patch:

diff --git a/base/plain_Label.asy b/base/plain_Label.asy
index 1e424ab1..96861218 100644
--- a/base/plain_Label.asy
+++ b/base/plain_Label.asy
@@ -294,7 +294,7 @@ struct Label {
     align=length(align)*unit(rotation(t)*align);
     pair S=t*position+align*labelmargin(p0)+shift(T)*0;
     if(settings.tex != "none")
-      label(f,s,size,embed(t)*shiftless(T),S,align,p0);
+      label(f,s,size,t*shiftless(T),S,align,p0);
     else
       fill(f,align(texpath(s,p0),S,align,p0),p0);
   }

perl-5.26 no longer has . in @inc. The following patch should be applied:

diff -r -U2 asymptote-2.41.orig/doc/FAQ/bfnnconv.pl asymptote-2.41/doc/FAQ/bfnnconv.pl
--- asymptote-2.41.orig/doc/FAQ/bfnnconv.pl 2017-03-22 14:56:46.000000000 +0700
+++ asymptote-2.41/doc/FAQ/bfnnconv.pl 2017-10-31 23:44:05.511045390 +0700
@@ -62,5 +62,5 @@
open(U,">$prefix.xrefdb-new");

-for $x (@outputs) { require("m-$x.pl"); }
+for $x (@outputs) { require("./m-$x.pl"); }

&call('init');

Hello,

I'm new to Asymptote and I like it quite a bit so far, but I'm having some trouble producing simple 3d graphics.

I've observed the following issue with asymptote from the Arch Linux repository, and now also from github master.

I have the simple script from the tutorial:

hello3d.asy

settings.outformat = "pdf";
settings.prc = false;
unitsize(3cm);
import three;

draw((0,0,0)--(2,0,0), blue); //x-axis
draw((0,0,0)--(0,2,0), green); //y-axis
draw((0,0,0)--(0,0,2), red); //z-axis

draw(unitsphere);

Here is the output of asy hello3d:
hello3d.pdf

However, if I set unitsize(1cm), I get:
hello3d.pdf

The two issues I'm observing:

• The black rectangles over the image
• The image seems pixelated, though it should be a vector output?

Any insight into either of these issues would be much appreciated.

Thanks!
Oliver

can not compile asymptote on Alpine Linux

g++ -Wall -DHAVE_CONFIG_H -D_FILE_OFFSET_BITS=64 -DUSEGC   -DFFTWPP_SINGLE_THREAD  -std=c++11 -g -O3 -fno-var-tracking -I. -I/usr/local/include/gc -I/usr/include/gc -o main.o -c main.cc
In file included from main.cc:37:0:
fpu.h: In function 'void fpu_trap(bool)':
fpu.h:30:43: error: 'feenableexcept' was not declared in this scope
   if(trap) feenableexcept(fpu_exceptions());
                                           ^
fpu.h:31:40: error: 'fedisableexcept' was not declared in this scope
   else fedisableexcept(fpu_exceptions());
                                        ^
make: *** [Makefile:318: main.o] Error 1

Hello

A colleague has observed that the following simple example gives an error
during the asymptote compilation.
%%%%%%%%%%%%%%%
\documentclass{article}
\usepackage{asymptote}
\begin{document}
\begin{asy}
import three ;
draw(unitcube);
label("$A$",(0,0,0),S) ;
\end{asy}
\end{document}
%%%%%%%%%%%%%%%

Without label("$A$',(0,0,0),S) everything is fine. But with label the command asy name-1.asy produces
%%%%%%%%%%%%%%
! I can't write on file `.aux'.
\document ...ate \openout @mainaux \jobname .aux
\immediate \write @Mainau...
l.15 \begin{document}

(Press Enter to retry, or Control-D to exit; default file extension is `.tex')
Please type another output file name
! Emergency stop.
\document ...ate \openout @mainaux \jobname .aux
\immediate \write @Mainau...
l.15 \begin{document}

! ==> Fatal error occurred, no output PDF file produced!
Transcript written on .log.
/usr/local/share/asymptote/plain_Label.asy: 655.6: texpath failed
%%%%%%%%%%%%%%

It seems that the command texpreamble("\input pdftex.def"); (defined in plain.asy) is the origin of the error. With texpreamble("\input pdftex.def"); the couple asymptote/pdflatex is trying to compile the file .tex ?
If I comment texpreamble("\input pdftex.def"); everything is fine, but we can have another strange behavior.

I tested today under Linux 64 bits, Debian Sid, Texlive 2016 up to date and Asymptote SVN up to date.

Thanks for advance.
O.G.

I'm trying to create a 3d image using ConTeXt to process the labels, but the labels aren't showing up in the PDF. Here's a simple example:

import three;

unitsize(1cm);

draw(O -- X, L=Label("X", position=EndPoint));
draw(O -- Y, L=Label("Y", position=EndPoint));
draw(O -- Z, L=Label("Z", position=EndPoint));

And here's the command I'm using:

asy -tex context -outformat pdf -outname test.pdf test.asy

If I use the same 3d example, but use -tex pdftex in the command, the labels appear as expected.

If I instead try a 2d example (below), and continue to use -tex context, the labels also appear as expected.

unitsize(1cm);

draw((0, 0) -- E, L=Label("X", position=EndPoint));
draw((0, 0) -- N, L=Label("Y", position=EndPoint));