Application: Asymptote
Category: Graphics & Pictures
Description: From the publisher's website:
Asymptote is a powerful descriptive vector graphics language that provides a natural coordinate-based framework for technical drawing. Labels and equations are typeset with LaTeX, for high-quality PostScript output.
A major advantage of Asymptote over other graphics packages is that it is a programming language, as opposed to just a graphics program.
Features of Asymptote:
- provides a portable standard for typesetting mathematical figures, just as TeX/LaTeX has become the standard for typesetting equations;
- generates high-quality PostScript, PDF, SVG, or 3D PRC vector graphics;
- embeds 3D vector PRC graphics within PDF files;
- inspired by MetaPost, with a much cleaner, powerful C++-like programming syntax and IEEE floating-point numerics;
- runs on all major platforms (UNIX, MacOS, Microsoft Windows);
- mathematically oriented (e.g. rotation of vectors by complex multiplication);
- LaTeX typesetting of labels (for document consistency);
- uses simplex method and deferred drawing to solve overall size constraint issues between fixed-sized objects (labels and arrowheads) and objects that should scale with figure size;
- fully generalizes MetaPost path construction algorithms to three dimensions;
- compiles commands into virtual machine code for speed without sacrificing portability;
- high-level graphics commands are implemented in the Asymptote language itself, allowing them to be easily tailored to specific applications.
Download Asymptote Portable 2.38 Dev Test 1 (5.49MB download / 29.9MB installed)
(MD5: d0b2e37d4508c879bfce8488c2e35c0e)
Note: All releases rely on the following programs:
- Ghostscript Portable (optional, but recommended)
- MiKTeX (optional, for background TeX processing)
Note: Previous versions of this application also included the xasy GUI for Asymptote as an optional install for standalone usage. It is distributed with normal installations as pure Python code but has been converted using py2exe with a dependency on Python Imaging Library (PIL) in order for portable use. No code was changed in the compiled xasy and the source Python files have been removed.
Optional: For programs who reference Asymptote externally: calling AsymptotePortable.exe will deal with the necessary configuration files along with calling the commandline-only asy.exe.
Release Notes:
See all release notes at the SourceForge project page
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
see DT splash screen briefly, then nothing (in part., no command prompt, as with installed version); no Asymptote.exe or AsymptotePortable.exe showing as a process in TaskManager
Are you launching it via AsymptotePortable.exe or from an external program that calls it? And that failing, I may have already figured out the dependency that /might/ be necessary for the GUI... (xasy is based on Python and, even though it is compiled for windows, may still rely on the python binary to run). Of note, though, is that xasy is seriously buggy, and is only included for the time being because I figured it was useful. I may end up making this a CommonFiles plugin if that doesn't clear up and just put xasy as its own package.
have launched from Win Explorer w/ a double click & from PA.c menu; same result
I tried launching it to see if it called python anywhere along the way and it didn't show in the task manager, so I possibly ruled that out for the moment. Can you try launching App\asy\xasy.exe by itself? (Note: this will leave a folder in %USERPROFILE%\.asy)
re-tried App\asy\xasy alone from Win Explorer as a double check; same result: nada; FYI, this box is polluted; in part., it has Asymptote installed, but I should get execution in any case; as previously noted, there is no Asymptote.exe, AsymptotePortable.exe or xasy.exe in TaskManager for any of the launching permutations
Well, for now I'll add a note above to avoid using the standalone but keep it around if other programs use it... I'll have to try it in a cleaner environment to see what the issue could be.
in sterile XP-SP3 environment, after exec'ing AsymptotePortable, one sees the flash screen & (very) briefly a command prompt window, then nothing; none of asy.exe, xasy.exe, & AymptotePortable.exe is a listed process in TaskManager.
I looked it up and ran across a helpful page that shows that I might need to add things to config.asy (or use environment variables instead...) that make sure that Asymptote knows where things are. It might also put an artificial requirement of having MiKTeX Portable installed for full usage (which I do not prefer for standalone processing).
http://tex.stackexchange.com/questions/83035/using-asymptote-with-miktex
(the batch file stuff therein looks irrelevant to me)
per this page, there are .sty files for Asymptote in its own directory but LaTeX cannot know to look there; adding to MikTeX path would be irrelevant since they are in the wrong place for TeX Dir. Structure (TDS); LaTeX can be apprised of them in 2 ways:
(1) the user always remembers to copy these .sty files to the dir containing the TeX documment; or,
(2) they are copied (& then forgotten) into a subdir of tex\latex, say tex\latex\Asymptote, of a TDS-compliant structure rooted as a local texmf directory Local_Texmf, say, that is **Not** part of MikTeX but which is also on the USB [1]; one adds the dir Local_Texmf as a root to MikTeXPortable, per my description "Usage Note: local tex trees" in "https://portableapps.com/node/36247". Anyhoo, that, along w/ the config/env.var. need, is my take-away from this particular stackexchange page. Have not tested the advice on that page, however, & my interp. may be off.
Note(s):
[1] Situating Local_Texmf as a sibling of MikTeXPortable (under CommonFiles for plugin case, else under PortableApps) may be better than my earlier post's idea of putting it under MikTeXPortable\Data, so that emptiness of Data, when needed, can be retained as a sentinel for a DefaultData load in order to preserve future MikTexPortable organizational options.
The biggest help in that is adding the app directory and Ghostscript to PATH. I'm going to do some internal testing (by blanking out PATH) and see if I can make it work properly. Thanks again.
I looked into it and I can't figure out why xasy is being such an issue still. Before I package another version, please replace the launcher.ini file with the code below and see if it works:
Made a mistake! Not forward slashes for any of it!
exec'ing AsymptotePortable.exe standalone from sterile env.; in part., no cygwin installation, or gsview, or MikTeX, or Asymptote, etc.:
one gets a cygwin warning that an MS-DOS style path 'C:/...' is detected & that the preferred POSIX alternative is '/cygdrive/c/....'; there then follows info from cygwin about cygwin env. var. to set in order to disable the warning.
command line (CL) window appears & stays in place (the CL window has the cygwin warning) with a 'Welcome to Asymptote...' message & command prompt. Both asy.exe & AsypmptotePortable.exe are in TaskManager; xasy.exe is not
I noticed that you included the cygwin dll; is this (cygwinb dll) a mandated part of a standard Asymptote Win installation?
As far as I know, it's in there by default. I got the same errors on run, but I wanted to make sure that the program even launched. xasy.exe wasn't meant to run this time around because I'm thinking of removing it completely or abstracting it to another portable package if I can't get it to work properly; it's just too unstable for normal use (from my own testing).
unheard of on std Win install (ubiquitous on cygwin installs); I would expect that the cygwin dll & the cygwin registry entries are for cygwin installs on a Win box only, included for completeness but not expected.
It seems like it's in there because of pretty weirdly unknown reasons. I'm going to do a quick build from source myself to see if it's included there too. If it is, then I can't remove it without the whole program not running. Also, you should be able to put "CYGWIN=nodosfilewarning" under environment and have it suppress the warning, but I couldn't get that to function properly.
Update: Yeah, that's just the way that the Asymptote devs had it build. I can't change that, unfortunately. I'm still looking to take out xasy though... so the next package is most likely going to be smaller.
Updated to 2.24 Dev Test 2. See release notes for details.
This post is Not about xasy, which has separate issues.
Conclusions:
(i) the env. var. ASYMPTOTE_GS must be set in the launcher;
(ii) command-line globbing not working properly from the launcher as configured; do not know if custom code is nec. to fix; such globbing is nec. for 'AsympotePortable' to be a stand-in for 'asy' in a ToolChain (e.g., TeXStudio) unless raw batch file commands can be processed (e.g., by TeXStudio) or a batch file itself is included in, say, a separate App\batch directory for the invoking app (e.g., TexStudio).
(iii) Most seriously, even with the corrections of (i) and (ii), AsymptotePortable, though exec'ing, is **doing nothing** with the ".asy" files produced by, e.g., pdflatex; am currently unable to fathom a fix; good luck.
Environment: sterile XP-SP3 VM using DT2.
(1)The test file
"Asymptote_LaTeX_Sample.tex" is identical to the file "latexusage.tex: referenced on the AOPS site and included in the dir App\asy\examples with the exception that the tex line (sans quotes)
"%\usepackage[inline]{asymptote}"
is uncommented to become
"\usepackage[inline]{asymptote}"
and that the line
"\usepackage{asymptote}"
is commented out to become
"%\usepackage{asymptote}".
This TeX file has Asympote code for 3 figures in 3 "\begin{asy}...\end[asy}" blocks with surrounding/separating textual material described in the LaTex;
fyi, the dir containing the TeX file also has copies of the 3 ".sty" files in the App\asy directory.
(2)Addition made to the Environment section of the launcher:
ASYMPTOTE_GS=%PAL:PortableAppsDir:ForwardSlash%/CommonFiles/Ghostscript/gswin32c.exe
Comment:
Ghostscript location must be known to Asymptote; not including it is an **error**; this has been confirmed with separate batch experiments not a part of this post.
(3)Batch file executed for emulating a Asymptote build script in, say, TeXStudio (batch file location=same dir as TeX file):
rem name of tex file:
set name=Asymptote_LaTeX_Sample
rem prelimary env. vars. for locations
set PAL_PortableAppsDir=P:\PortableApps
rem "PAL:..." for an env. var. name does not work in batch; "PAL_..." used instead.
set MikTeX_bin=%PAL_PortableAppsDir%\MiKTeXPortable\App\MiKTeX\miktex\bin
set Asymptote_bin=%PAL_PortableAppsDir%\AsymptotePortable\App\asy
set AsymptotePortable_dir=%PAL_PortableAppsDir%\AsymptotePortable
set path=%MikTeX_bin%;%AsymptotePortable_dir%;%path%
rem next 3 batch lines emulate a build script for Asymptote in, say, TeXStudio;
rem these 3 lines are essentially verbatim from the AOPS site substituting "AsymptotePortable.exe" for "asy" :
pdflatex %name%
AsymptotePortable.exe %name%-*.asy
pdflatex %name%
(3)Results:
(a)Only **one** execution (as noticed by the splash screen(s)) of AsymptotePortable was found, when there should be 3, one execution for each of the 3 ".asy" files generated by the 1st pdflatex invocation (yes, all 3 ".asy" files were produced).
(b)A single pdf was produced when there should be 4++: 1 for the final pdf +1 for each of the 3 figures+intermediate pdfs on the figures.
(c)That single pdf has **No** figures included. Only the surrounding/separating textual material appears.
(4)Suspected poor Launcher command-line globbing corrected with batch script:
The launcher's possible limitations on command line globbing in the line
"AsymptotePortable.exe %name%-*.asy" was suspected, so that batch line was replaced by a batch for-loop:
"for %%i in (%name%-*.asy) do ( AsymptotePortable.exe %%i )".
The Results:
(a)This time there were 3 invocations of AsymptotePortable.exe. So the globbing issue was corrected by the batch for-loop.
(b)Same as above: 1 pdf when 4++ pdfs should appear (3 ".asy" files produced).
(c)Same as above: No figures in the pdf produced.
**In other words, the AsymptotePortable invocations Do Nothing.**
With corrections (i)-(ii) noted supra, the ingredients for proper exec. of AsymptotePortable are all there, but the execution results--or, rather, lack of same--are not there; mysteriously, a batch with same path, env. vars. Does produce correct results.
(1)The proper 4++ pdfs are produced, amongst which is the pdf named after the TeX file containing all figures as well as text, properly formtted, etc. Environment is sterile XP-SP3 VM;
(2)(a)identical batch file works producing proper output on a polluted Win7 having Asymptote installed;
(b)only difference is faster exec. in the sterile XP VM env. even tho' the VM is alloted much less RAM (1 GB) than exists on the Win7 test box (6GB);
(c)thought that the existence of the "%userprofile%\.asy" directory might be degradation issue, so re-exec'd the batch file after moving that '...\.asy ' dir; identical results: beautiful output but slower exec. time than in sterile XP env.
(3)The contents of the batch file (located in the dir of the TeX file) between the "**Begin**" and the "**End**":
**Begin**
set PAL_PortableAppsDir=P:\PortableApps
:: name of tex file:
set name=Asymptote_LaTeX_Sample
:: name of TeX file is %name%.tex
:: customize these settings
set MikTeX_bin=%PAL_PortableAppsDir%\MiKTeXPortable\App\MiKTeX\miktex\bin
set Asymptote_bin=%PAL_PortableAppsDir%\AsymptotePortable\App\asy
set Ghostscript_bin=%PAL_PortableAppsDir%\CommonFiles\Ghostscript\bin
set AsymptotePortable_dir=%PAL_PortableAppsDir%\AsymptotePortable
set path=%MikTeX_bin%;%Asymptote_bin%;%path%
set ASYMPTOTE_GS=%Ghostscript_bin%\gswin32c.exe
set ASYMPTOTE_HOME=%PAL_PortableAppsDir%\AsymptotePortable\Data\configs
set ASYMPTOTE_PSVIEWER=%PAL_PortableAppsDir%\GSviewPortable\GSviewPortable.exe
set ASYMPTOTE_DIR=%PAL_PortableAppsDir%\AsymptotePortable\App\asy
set ASYMPTOTE_CONFIG=%PAL_PortableAppsDir%\AsymptotePortable\Data\configs\config.asy
set CYGWIN=nodosfilewarning
:: execute:
pdflatex %name%
asy %name%-*.asy
pdflatex %name%
**End**
Thank you again for your extremely thorough testing; I don't currently have time for anything that in-depth. Okay, so I was able to gather the following from your comments:
1) ASYMPTOTE_GS has to be set for things to work properly
2) The App\asy directory should be included in PATH as well because it adds the necessary .sty files (this is extrapolation on my part)
3) If I cannot find a way to use AsymptotePortable as a runtime, then anything calling it should call the actual binary and then take care of the extra folder left behind.
I will try things like explicitly allowing for multiple portable versions and see what is going on. Thanks again.
(1)globbing
suppose in the prior batch scripts that the name is set to 'MyExample' (so the TeX file is 'MyExample.tex'); after pdlatex runs, there are 3 ".asy" files in the dir having MyExample.tex, named:
MyExample-1.asy
MyExample-2.asy
MyExample-3.asy
the Win batch/cmd executive expands the line
"AsymptotePortable.exe %name%-*.asy"
into
"AsymptotePortable.exe MyExample-1.asy MyExample-2.asy MyExample-3.asy"
but what is getting exec'd is merely
"AsymptotePortable.exe MyExample-1.asy"
So the launcher must be adjusted (custom code?) for this globbing, since it's an integral part of the usage of Asymptote for TeX files with more than one figure.
(2)copies of the ".sty" files must In Any Instance be in the directory containing the tex file (or in a Local Texmf directory--see my prior posts on same elsewhere); the path spec. is irrelevant to them; if they are are on the path but not in that directory (or a Local Texmf), the script will fail.
(3)App\asy Must Be on the path for its binaries; this has been tested by batch script; Asymptote will ignore any dlls,exes, etc. that are in it otherwise
I think I figured out the real problem in all of this... because of WorkingDirectory being set to %PAL:AppDir%\asy from when xasy was in there, it's messing up where the outputted PDF files go... I'll be testing to see if I can just get rid of that line. I checked inside the asy folder and all of the outputted pdf files were sitting there.
After testing on the exact same file you did, this is, in fact, the problem. I will be commenting out WorkingDirectory for use with xasy only (until I get rid of it completely).
since
launcher's notion of 'Working Directory'== Win's notion of Current Directory
my App/asy directory has intermediate stuff all over it
good catch
I had a testing copy of AsymptotePortable and I noticed that in the tree view on the lefthand side there were items being added. I found all of the output files right where they shouldn't be... Look for the newest update soon.
it must be set (see my batch script), otherwise figures don't get labelled and pdfs don't get put together
I remembered to add that for the upcoming version. The big issue was WorkingDirectory, however.
In a future update, I'll be adding the asymptote LaTeX styles to MiKTeX by default so that there are minimal issues going forward. This shouldn't be a problem license-wise since Asymptote is just as open source as MiKTeX.
my reading is that these ".sty" files go in a Local Texmf TDS-compliant tree, not Miktex; the AOPS instructs to make insertion in MiTeX, I know; but, for security reasons [1], MikTeX is obligated to neither maintain nor keep from Deleting any packages, classes, styles, etc. that are not in its repository; see
"http://tex.stackexchange.com/questions/69483/create-a-local-texmf-tree-i..."
Note(s):
[1] per reference cited, Miktex tree insertions were OK with Miktex in older versions, whioch may be the logic behind the AOPS instructions (ie, AOPS instructions are based on older MIktex).
Updated to 2.24 Dev Test 3. See release notes for details.
(1)typo
"ASYMPTOTE_GS=%PAL_..." shoudl be "ASYMPTOTE_GS=%PAL:...";
I had to use the '...PAL_' rather than '...PAL:' version in batch script since batch dislikes colons in env. var. names, tho', apparently, the Win api is fine with them;
(2)corrected typo, exec'd batch script [1] to test;
good news: App/asy has no intermediate stuff now
(3)bad news: Results still same;
the ".asy" files from pdflatex are not expanded into ".tex" files as they should be;
one pdf on output;
it has no figures
Note(s):
[1] the batch file used for testing (loc'd in the TeX file's dir):
set PAL_PortableAppsDir=P:\PortableApps
:: name of tex file:
set name=Asymptote_LaTeX_Sample
:: name of TeX file is %name%.tex
set MikTeX_bin=%PAL_PortableAppsDir%\MiKTeXPortable\App\MiKTeX\miktex\bin
set path=%MikTeX_bin%;%path%
:: execute:
pdflatex %name%
AsymptotePortable.exe %name%-*.asy
pdflatex %name%
I blindly copied the ghostscript path... I'll take a look at your comments and repost Dev Test 3 soonish.
Also, I tested the change in TeXstudio and it processed properly (compile, Asymptote, compile) into an output PDF. It called AsymptotePortable.exe for all calls to Asymptote and compiled the PDF correctly. I'm not quite sure how the batchfile you're using differs but again, I'll be looking it over for checks.
I got 1 pdf with No Figures using AsymptotePortable.exe when there should be >4 (5 to be precise, for this tex file) pdfs in the dir;
by contrast, after proper execution from a batch script of asy.exe per prior post (Not exec. of AsymptotePortable.exe) when the TeX file was named 'Asymptote_LaTeX_Sample.tex', I got the following 5 pdfs in the dir containing the TeX file:
Asymptote_LaTeX_Sample-1_0.pdf
Asymptote_LaTeX_Sample-2+0_0.pdf
Asymptote_LaTeX_Sample-2_0.pdf
Asymptote_LaTeX_Sample-3_0.pdf
Asymptote_LaTeX_Sample.pdf
[1]The last-listed of these has all figures and labels; it is the final output. The others have missing labels,etc. and relate to the 3 Asymptote figures.
fyi, the name of the single, erroneous, **No Figures** pdf produced by AsymptotePortable.exe from the same tex file was also 'Asymptote_LaTeX_Sample.pdf'.
Note(s):
[1] all intermediate files produced relating to the 3 Asymptote figures are listed below:
Asymptote_LaTeX_Sample-1.asy
Asymptote_LaTeX_Sample-1.pre
Asymptote_LaTeX_Sample-1.tex
Asymptote_LaTeX_Sample-1_0.pdf
Asymptote_LaTeX_Sample-2+0.prc
Asymptote_LaTeX_Sample-2+0.tex
Asymptote_LaTeX_Sample-2+0_0.pdf
Asymptote_LaTeX_Sample-2.asy
Asymptote_LaTeX_Sample-2.pre
Asymptote_LaTeX_Sample-2.tex
Asymptote_LaTeX_Sample-2_.out
Asymptote_LaTeX_Sample-2_0.pdf
Asymptote_LaTeX_Sample-3.asy
Asymptote_LaTeX_Sample-3.pre
Asymptote_LaTeX_Sample-3.tex
Asymptote_LaTeX_Sample-3_0.pdf
The PDF was filled with the three appropriate figures with labels, etc. I'll check using a locked down PATH and then try variations of your batch file to figure it out.
this is the batch file (path incorrect in transcription of a prior post); fyi Exactly this was re-exec'd with same **No Figures** results; environment for all executions (asy.exe w/ 5 proper pdfs or AsymptotePortable.exe getting only 1 No Figures pdf) was Sterile XP-SP3 VM:
set PAL_PortableAppsDir=P:\PortableApps
:: name of tex file:
set name=Asymptote_LaTeX_Sample
:: name of TeX file is %name%.tex
set MikTeX_bin=%PAL_PortableAppsDir%\MiKTeXPortable\App\MiKTeX\miktex\bin
set path=%MikTeX_bin%;%PAL_PortableAppsDir%\AsymptotePortable;%path%
:: execute:
pdflatex %name%
AsymptotePortable.exe %name%-*.asy
pdflatex %name%
In TeXstudio, the command for asymptote is '"AsymptotePortable.exe" ?m*.asy' (without the outer quotes) which I don't distinctly recognize as being regex. I tested the updated (unreleased) version with all local PATH removed against latexusage.tex and did the same Compile -> Asymptote -> Compile that I did last time and I still got the proper results. I am currently trying out your batch file to figure out where it is different, but it seems like what I would consider "normal" usage results in proper outputs.
variants tried
"AsymptotePortable.exe" ?m*.asy
and
AsymptotePortable.exe ?m*.asy
in lieu of
AsymptotePortable.exe %name%-*.asy
in the batch file listed above;
same 1 pdf No Figures result;
it's a very odd-looking command for TeXStudio to use isn't it? certainly not regex--or expected regex anyway;
anyhoo, does not work in batch on sterile XP
it's too close to Halloween; one of us has a gremlin
When running your batch file, it complains that it can't overwrite latexusage.pdf and for some reason just quits when it can't. If I have the first latexusage.pdf deleted before the second run of pdflatex, it outputs just like it should. There is something that TeXstudio takes care of that the batchfile doesn't, though I'm not sure where in the toolchain it does.
I've always manually cleaned the dir of old intermediate stuff prior to exec to ensure that what I'm looking at is what was produced by the latest run
I cleaned it out too, but just running your batchfile in the same environment as TeXstudio runs its commands results in an empty PDF compared to a 120kb PDF with charts. I don't know what could cause it, but the batchfile does not emulate actual usage enough, somehow.
Ah, I think I got it. When I run your batchfile, it runs AsymptotePortable.exe on the files like it should, but then continues execution with the rest of the batchfile, essentially running pdflatex on a possibly incomplete .tex file and dependencies.
I don't think so; the tex files for the figures have not been produced by AsymptotePortable.exe; w/ correct batch script--the one calling asy.exe--a a separate tex file is produced for each of the Asymptote figures by the call to asy.exe
Use this batchfile to see how it just kind of skips to the next command regardless:
made that change; yes, it pauses for the "press any key...' but otherwise all aspects of the exec. are identical; no skipping
same result (used my dir for PA & tex file name, of course)
It must be a strange thing with Windows 8 then... The pause runs while the Asymptote window is still up processing the files on my computer and doesn't wait to run the pause like it should.
Either way, it works in TeXstudio. I will test in the other major applications when I can.
the batch file is, apart from setting up env. vars., the 3-liner from AOPS:
http://asymptote.sourceforge.net/doc/LaTeX-usage.html
The problem isn't the code, it's how batchfiles are handled by the system. Try running each of the lines of your batchfile individually in a command prompt. It should work perfectly fine then...
Currently, I have tested the changes working properly in Windows 8 with:
1) TeXstudio 2.6.4 Dev Test 2
2) Texmaker 4.0.4 Dev Test 6
The process that I used is:
1) Default quick build
2) Asymptote build
3) Default quick build
from Texmaker 4.0.4 Dev Test 6:
quick build
click on Tools>Asymptote
quick build
same result: 1 pdf w/ No Figures in the dir; TM's pdf viewer shows that erroneous pdf; sterile XP-SP3 per usual
from TexStudio 2.6.4 DT2, performed same (click on double-arrow instead of quick build; click on Tools>Commands>Asymptote instead of Tools>Asymptote; click on double arrow again); same result: 1 pdf w/ No Figures
fyi, AsymptotePortable Dev splash screen displays in both cases;
I'm tempted to say this is an XP problem now... I have had zero errors on Windows 8 even with PATH neutered to just what I specify in the launcher and nothing else. I don't know what to tell you, to be honest.
same results on Win7 (up-to-date; no installed Asymptote)
exec'd the asy.exe script with beautiful output, 5 pdfs, etc. same as on XP;
exec'd the AsymptotePortable script; same result: 1 pdf w/ No Figures (DT splash screen displays during exec., fyi)--same as on XP
Do any command line windows pop up when it hits the AsymptotePortable part? I am having an extremely hard time figuring out what is causing this difference in outputs between our machines. There is nothing that is standing out but every single test seems to be having the exact opposite results.
And can you try putting "START /WAIT" in front of the pdflatex and AsymptotePortable.exe commands in your batchfile? This takes care of the discrepancy of waiting that I found in Windows 8 so maybe it will help in some obscure way with at least the batchfile test.
exec. on Win7; no installed Asymptote or MikTeX;
Can you check inside AsymptotePortable\Data\Temp, if it exists? That folder is where the files SHOULD be kept as they are being created by asymptote.
Reuploaded 2.24 Dev Test 3 with minor path name fix in launcher. Note to other testers: please try Asymptote and post here. We need external validation of some issues seen by d4winds.
Second reupload to replace example file that was deleted by accident.
both Win7 & XP-SP3; no installations of Asymptote or MikTeX on either;
I'm going to be testing on another laptop I was able to borrow to see if I can replicate your results.
I noticed something random when testing on the clean Windows 7 machine. It installed a few things via MiKTeX. Maybe that could be causing some of the issues that you have been seeing; like if you have it set to not install packages when they're needed...
One of the files is called supp-pdf.mkii, maybe that will help.
Okay, so I was able to test with a laptop running Windows 7 with nothing TeX installed and I noticed that there are two things that were screwing with my testing before.
1) MiKTeX Portable (most recent version, CommonFiles plugin not the standalone that I've discontinued) needs to install 5 files in order to process latexusage.tex off the bat:
On the pdflatex run:
tex\context\base\supp-pdf.mkii
On the AsymptotePortable.exe run:
tex\latex\media9\media9.sty
tex\latex\l3kernel\expl3.sty
tex\latex\l3experimental\l3str\l3regex.sty
tex\latex\l3packages\l3keys2e\l3keys2e.sty
Because of these installs, I had to rerun the batchfile twice in order for MiKTeX to have picked up on the changes to the files. Not sure why, but it worked.
2) Even what I thought was the most pristine PATH will still have inadvertant things in it. To mitigate this on my "contaminated" Windows 8.1 machine, I removed all references to the default PATH from all included applications (AsymptotePortable, Ghostscript, GSview, MiKTeX, and TeXstudioPlusPortable) which I had freshly installed to a new folder. I was able to run both TeXstudio and the below batchfile without problem and was able to get the appropriate outputs.
The batchfile I used (changed to reflect the MiKTeX Plugin version):
The batch file exec'd is in Note [1].
(a)MikTeX is fully updated;
(b)Load packages on the fly is set to be On in MikTeX; all formats have been updated & FNDB rebuilt (using MikTeX Options)
(c)manually checked the specific files in MikTeX you specified in your post ('tex\context\base\supp-pdf.mkii',...); all are there;
(d) the asy.exe batch script execs beautifully using same MikTeX on both boxes;
(e)XP & Win7 do not share MikTeX or other PA apps or other installed apps;
(f)no installed MikTeX or Asymptote on either;
(g)fyi, this is the XP path produced by 'echo %path%' from the ordinary command line prompt:
C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\system32\WindowsPowerShell\v1.0
(h) this system path, however, is not being used, only the one specified in the batch file is; that was confirmed by re-directing a 'echo %path%' statement to an output file at tail of the batch;
Note(s):
[1]Batch file used:
rem 'Trace_ID'identifies the type of run for re-directing path & env.var. printouts
set Trace_ID=AsymptotePortable
rem set PAL_PortableAppsDir=C:\Users\Matt\Downloads\PortableApps
rem set PAL_PortableAppsDir=P:\PortableApps
set PAL_PortableAppsDir=C:\USB\PortableAppsEnv\PortableApps
:: name of tex file:
rem set name=latexusage
set name=Asymptote_LaTeX_Sample
:: name of TeX file is %name%.tex
rem set MikTeX_bin=%PAL_PortableAppsDir%\CommonFiles\MiKTeX\miktex\bin
set MikTeX_bin=%PAL_PortableAppsDir%\MiKTeXPortable\App\MiKTeX\miktex\bin
set PATH=%MikTeX_bin%;%PAL_PortableAppsDir%\AsymptotePortable
:: execute:
pdflatex %name%
AsymptotePortable.exe %name%-*.asy
pdflatex %name%
:: Trace path and env. vars used:
del /q "Trace\Trace_path_%Trace_ID%.txt"
del /q "Trace\Trace_EnvVars_%Trace_ID%.txt"
echo %path% > "Trace\Trace_path_%Trace_ID%.txt"
set > "Trace\Trace_EnvVars_%Trace_ID%.txt"
by contrast to the AsymptotePortable script above, this one calling asy.exe execs beautifully in Win7 & XP-SP3 VM; for reference, the verbatim batch script is given first in (1) and then outputs from the Trace at the tail end of this script are shown next in (2);; I see nothing suspicious.
(1)the script:
rem 'Trace_ID'identifies the type of run for re-directing psth & env.var. printouts
set Trace_ID=asy_call
set PAL_PortableAppsDir=P:\PortableApps
:: name of tex file:
set name=Asymptote_LaTeX_Sample
:: name of TeX file is %name%.tex
:: customize these settings
set MikTeX_bin=%PAL_PortableAppsDir%\MiKTeXPortable\App\MiKTeX\miktex\bin
set Asymptote_bin=%PAL_PortableAppsDir%\AsymptotePortable\App\asy
set Ghostscript_bin=%PAL_PortableAppsDir%\CommonFiles\Ghostscript\bin
set AsymptotePortable_dir=%PAL_PortableAppsDir%\AsymptotePortable
rem set path=%MikTeX_bin%;%Asymptote_bin%;%path%
set path=%MikTeX_bin%;%Asymptote_bin%
set ASYMPTOTE_GS=%Ghostscript_bin%\gswin32c.exe
set ASYMPTOTE_HOME=%PAL_PortableAppsDir%\AsymptotePortable\Data\configs
set ASYMPTOTE_PSVIEWER=%PAL_PortableAppsDir%\GSviewPortable\GSviewPortable.exe
set ASYMPTOTE_DIR=%PAL_PortableAppsDir%\AsymptotePortable\App\asy
set ASYMPTOTE_CONFIG=%PAL_PortableAppsDir%\AsymptotePortable\Data\configs\config.asy
set CYGWIN=nodosfilewarning
:: execute:
pdflatex %name%
asy %name%-*.asy
rem AsymptotePortable.exe %name%-*.asy
rem for %%i in (%name%-*.asy) do ( AsymptotePortable.exe %%i )
pdflatex %name%
:: Trace path and env. vars used:
del /q "Trace\Trace_path_%Trace_ID%.txt"
del /q "Trace\Trace_EnvVars_%Trace_ID%.txt"
echo %path% > "Trace\Trace_path_%Trace_ID%.txt"
set > "Trace\Trace_EnvVars_%Trace_ID%.txt"
(2)outputs from the Trace exec'd at end of batch script above; all outputs are from sterile XP-SP3 VM (XPmode from within Win7 64bit Professional):
(a)Path:
P:\PortableApps\MiKTeXPortable\App\MiKTeX\miktex\bin
;P:\PortableApps\AsymptotePortable\App\asy
(b)Environment Variables:
ALLUSERSPROFILE=C:\Documents and Settings\All Users
APPDATA=C:\Documents and Settings\XPMUser\Application Data
AsymptotePortable_dir=P:\PortableApps\AsymptotePortable
Asymptote_bin=P:\PortableApps\AsymptotePortable\App\asy
ASYMPTOTE_CONFIG=P:\PortableApps\AsymptotePortable\Data\configs\config.asy
ASYMPTOTE_DIR=P:\PortableApps\AsymptotePortable\App\asy
ASYMPTOTE_GS=P:\PortableApps\CommonFiles\Ghostscript\bin\gswin32c.exe
ASYMPTOTE_HOME=P:\PortableApps\AsymptotePortable\Data\configs
ASYMPTOTE_PSVIEWER=P:\PortableApps\GSviewPortable\GSviewPortable.exe
CLIENTNAME=Console
CommonProgramFiles=C:\Program Files\Common Files
COMPUTERNAME=VIRTUALXP-40234
ComSpec=C:\WINDOWS\system32\cmd.exe
CYGWIN=nodosfilewarning
FP_NO_HOST_CHECK=NO
Ghostscript_bin=P:\PortableApps\CommonFiles\Ghostscript\bin
HOMEDRIVE=C:
HOMEPATH=\Documents and Settings\XPMUser
LOGONSERVER=\\VIRTUALXP-40234
MikTeX_bin=P:\PortableApps\MiKTeXPortable\App\MiKTeX\miktex\bin
name=Asymptote_LaTeX_Sample
NUMBER_OF_PROCESSORS=1
OS=Windows_NT
PAL_PortableAppsDir=P:\PortableApps
Path=P:\PortableApps\MiKTeXPortable\App\MiKTeX\miktex\bin;P:\PortableApps\AsymptotePortable\App\asy
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.PSC1
PROCESSOR_ARCHITECTURE=x86
PROCESSOR_IDENTIFIER=x86 Family 6 Model 42 Stepping 7, GenuineIntel
PROCESSOR_LEVEL=6
PROCESSOR_REVISION=2a07
ProgramFiles=C:\Program Files
PROMPT=$P$G
PSModulePath=C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\
SESSIONNAME=RDP-Tcp#1
SystemDrive=C:
SystemRoot=C:\WINDOWS
TEMP=C:\DOCUME~1\XPMUser\LOCALS~1\Temp
TMP=C:\DOCUME~1\XPMUser\LOCALS~1\Temp
Trace_ID=asy_call
USERDOMAIN=VIRTUALXP-40234
USERNAME=XPMUser
USERPROFILE=C:\Documents and Settings\XPMUser
windir=C:\WINDOWS
I seriously give up trying to figure it out. Nothing I seem to try that works on mine works on yours. I need someone else to test it or we're getting nowhere. For now, change the PATH accordingly to use asy.exe, set the asymptote variables in TeXstudio and Texmaker, and have it forcefully remove %USERPROFILE%\.asy on close. That's it.
Findings:
the executable (asy.exe) launched by AsympotePortable acts like it's not getting params and/or correct environment vars.--at least on my end;
so I traced it & found that, in fact, it is **not**; other PApps **do** get launcher-modified params, env. vars. etc.; the executable launched by AsymptotePortable (asy.exe, e.g.), however, does not;
In part., it receives **none** of the ASYMPTOTE_... env.vars or the CYGWIN env. var.--they are not defined in what it receives; the PATH env. var. received by asy.exe is the unmodified one existing pre-launcher exec.
by contrast, with LyXPortable, e.g., launcher-defined env. vars. like TEX,PDF,EXTRAS, &, of course, PATH are passed through fully as intended
In both cases (AsymptotePortable & LyXPortable) the usual pre-defined env. vars. like PAL:AppDir, etc. **are** all passed through as originally defined.
Procedure for coming to this conclusion :
(a)a batch file called "Tracer.bat" (see [1]) was added to the binaries dir (App\asy, e.g.); and, the launcher was modified to launch "Tracer.bat" instead of the usual executable (asy.exe, e.g.) . This batch file prints to redirected output the following: the params, env. vars., & current dir. all as existing post-execution of the launcher.
(b)step
was repeated for LyXPortable (binaries in App\LyX\bin; same launcher mod; same Tracer.bat)
All execs. in sterile XP-SP3 VM.
Note(s):
[1]The batch file "Tracer.bat" added to app's directory of binaries:
@echo off
del /q Trace.txt
echo Note: beginning/ending of emphasized strings like params are delimited by the digraph '::' >> Trace.txt
echo --Begin Params-- >> Trace.txt
echo Entering ::%0:: >> Trace.txt
echo param All::%*:: >> Trace.txt
echo param# 1=::%1:: >> Trace.txt
echo param# 2=::%2:: >> Trace.txt
echo param# 3=::%3:: >> Trace.txt
echo param# 4=::%4:: >> Trace.txt
echo param# 5=::%5:: >> Trace.txt
echo param# 6=::%6:: >> Trace.txt
echo param# 7=::%7:: >> Trace.txt
echo param# 8=::%8:: >> Trace.txt
echo param# 9=::%9: >> Trace.txt
echo --End Params-- >> Trace.txt
echo --Begin Environment Variables-- >> Trace.txt
set >> Trace.txt
echo **Env current directory** is ::%cd%:: >> Trace.txt
echo --End Environment Variables-- >> Trace.txt
I read your comment over a few times to make sure I understood what you did to test this. It seems like even when I neutered the paths on my machine, it was surpassing them in lieu of either system environment variables or some Cygwin pathing. I will look up to see if Cygwin applications used a different PATH (like CYGWIN_PATH or something of the sort) and test it. If you don't mind, can you download the newest cygwin1.dll from the Cygwin site and replace the one in Asymptote? I heard there might be problems with older versions and I don't know what version of cygwin1.dll is being used with Asymptote.
Slight update: I was looking through the Cygwin documentation and I ran across a random fact that PATH has to be upper case for Cygwin (it's one of the few always-upper-case environment variables). Other than that, I'll be still looking for other path-related answers.
Further thought: Remove the CYGWIN environment variable. There is a distinct possibility that it is messing with things (since you seem to have been able to run it prior that addition, at least according to my slightly foggy memory). I will be testing all of these things when I get back to my normal computer so I will post below this anything I find.
my suspicions have not been based on evidence but merely on that there seemed little else differentiating execution contexts that may account for the different behavior;
fyi, only one cygwin dll on the XP VM; many on the Win7, however, from cygwin install, Toucan, misc.;
will try the latest & greatest cygwin; am not hopeful, tho'
also CYGWIN env. var not passed thru;
and the launcher modifications to the path do not get passed thru;
removing the CYGWIn env. var. cannot have an effect; the launched executable doesn't see it
I'm getting the same thing, strangely enough. What I thought locked it down during my testing was still allowing my system PATH to show where the installed Asymptote was... I'll look more into it, but that temporary patch I suggested when I said I gave up will have to do for now.
Found this on page 9 of the Asymptote documentation:
the difference had me going;
I tried a few things and managed to get only the most minimal of results:
1) I directly changed the environment variables in the registry but they didn't show up in the application.
2) I set the variables in config.asy and made sure it was in %USERPROFILE\.asy% and the only thing I got was that "home is unknown in this context" when Asymptote launched.
3) On one run, CYGWIN=nodosfilewarning showed up as a variable, but I have a sneaking suspicion I didn't notice it earlier and that it has to do with Cygwin64 already on my system than anything.
4) I tried reordering and removing the variables, to no avail
5) I updated my post in the Portable Apps Development forum to include the environment variable problem, and I'm waiting on an external opinion.
In short, it looks like something like the batch equivalent of a 'Setlocal' and 'Endlocal' is surrounding what gets done in the Environment section and possibly also FileWrites and/or other sections, but not the actual launch. Detailed explanation:
In AsymptotePortable, the behavior from the Environment section looks like the code for the launcher is
(i) properly inheriting the defined environment it gets from the surrounding execution environment at AsymptotePortable execution,
and is
(ii)properly inheriting the env. created within preceding sections of the launcher code (not nec. preceding in the '.ini' file) for defining all the PAL:... env. vars. like PAL:AppDir,
but is
(iii)then defining a new local sub-environment for use within the launcher **only**, so that FileWrites may work, e.g., & so that env. vars. can be defined using other env. vars. defined in the Environment section or from the inherited ones;
but is also Not
(iv)exporting the "launcher-only" sub-environment created in (iii) to the exterior env. of (ii)--which has inherited from (i)--; and, it is from within the env. of (ii) that the actual launch takes place, not the fully-created one of (iii).
(1)behavior: see post above; see Note [1] below also;
(2)kept App\asy as is but blasted cygwin dll from it; got same results from Tracer.bat exec.; cygwin is not the culprit; it might create issues but these issues cannot be laid at its feet;
(3) blasted **everything** from App/asy except for Tracer.bat; got identical Trace.txt results from the "AsymptotePortable" launch; in part., none of the ASYMPTOTE_... env. vars. were inherited; path was not modified, etc.
(4)the type of error described in my post above would be a very easy one to make in the code for Launcher Generator, one can slip up on 'the' environment actually in in effect for the launch itself; further, since FileWrites, etc. may still work, it would not be quickly detected.
Note(s):
[1]on the off chance that the Launcher Generator was improperly following sequence within the '.ini', I re-created the launcher for AsymptotePortable using the up-to-date launcher generator from GetApps' page of PA.c (no betas, etc/) and using your code everywhere with one exception: made sure that the Environment section of the '.ini' came first; got identical lousy results.
In some fairness, this may be the first app that I have worked on that has environment variables that are not only used internally, so that could be why I have never noticed before. What is odd to me is that updating PATH isn't working in this case either (which is contrary to all of my other applications such as LyX, etc.). I think it would be fair for me to read more about the environment variables in the development reference (though slightly outdated) and see what I can come up with. I think we've hit another brick wall with this...
for LyX the path within the Environment section & FileWrites is getting written out to the preferences file; but when the LyXPortable launcher '.ini' is modified to launch Tracer.bat every env. var. created within the launcher--like TEX, etc. which do Not get written to the preferencs file--is picked up by Tracer.txt--like they should be, but, alas, not like in AsymptotePortable.
Well, I was talking about the particular section that modifies PATH: "PATH=%TEX%;%PDF%;%EXTRAS%;%PATH%" which seems to do its job properly, not just for the FileWriteN sections, but your test shows how odd it is for the Asymptote launcher to not get them...
In a post here I see mentioned using Regshot to determine what variables were changed/accessed. This might be a good way of tracing instead of using the custom batchfile (for example, run once in your clean environment before and then once while running).
...I found the problem... one so mundane we both looked clear over it. I can't spell. I found out that I wrote "[Envrionment]" instead of "[Environment]". I feel the fool... Dev Test 4 is coming out momentarily.
duh!!
Updated to 2.24 Dev Test 4. See release notes for details. Thanks to d4winds for their intensive work into helping with this update.
all outputs as expected & looking completely correct;
exec. in sterile XP-SP3 VM;
long journey just to catch a typo;
If I ever have an error in launching again, I am rebuilding the launcher from scratch to try and catch these stupid little errors... thanks again for the effort you put into this; you went above and beyond most of the non-devs on this site.
context: exec'ing under an Admin acct. in sterile XP-SP3 VM;
I had previously noticed cygwin writes to the registry, so re-tested:
(1) deleted the registry keys HKCU\Software\Cygwin and HKLM\Software\Cygwin;
(2) ran batch script using AsymptotePortable (prelinaries, pdflatex, AsymptotePortable, pdflatex--all as previously posted); beautiful output as posted supra;
(3)checked the registry; now have all of the following registry keys when just prior to exec. there were none:
HKCU\Software\Cygwin
HKCU\Software\Cygwin\Program Options
HKCU\Software\Cygwin
HKLM\Software\Cygwin\Program Options
HKLM\Software\Cygwin\Installations
I could have sworn I had registry stuff taken care of... Upon a second look, all I fix is "HKCU\Software\Cygwin\Installations". I'll be updating that to "HKCU\Software\Cygwin" and "HKLM\Software\Cygwin". You have "HKCU\Software\Cygwin" in there twice; is there a different key you meant to write the second time?
nope, sorry about that; went a little overboard on the pasting
I just wanted to make sure... don't want to start a Chrome-like release cycle on my packaged applications.
the 2nd "HKCU\Software\Cygwin" should be "HKLM\Software\Cygwin"
Amazing to find such a needle in a haystack!
Just a small thing, >help in asy environment points to \program files\asymptote\asymptote.pdf, which of course won't be found.
I noticed that in an early build but couldn't find the appropriate place for that to be reset as it may be hardcoded. Thanks for the catch though.
I'm going to wait on releasing a Dev Test 5 with the registry fixes because I posted on the Asymptote SourceForge discussion board asking about the helpfile and why it isn't being found. If they don't get back to me on that, I'll release the next version in a couple of days.
(1)helpfile "location" looks hard-coded to me; probably not going to get anything from discussion board; warning to user to look for Help in Asymptote.pdf in the App\asy dir. might be useful;
(2)registry:
(a)changes to HKLM seems odd;
(b)keys added that were not there; current registry stuff in launcher handles HKCU only & does not delete keys created that were not there before;
The HKLM is probably purely from Cygwin and not because of how Asymptote is developed; an unfortunate consequence of using non-native development for Windows. The launcher updates in the next release will take care of all of the addressed by using the topmost registry keys only (HKCU\Software\Cygwin and HKLM\Software\Cygwin), thus making the registry work easier. And yeah, it's kind of... odd that the helpfile is hardcoded to a particular directory. I did a test to redirect %PROGRAMFILES% to a different folder and it still looked in the default location. I'm hoping that someone in the Asymptote community knows if there is a solution (outside of recompiling it myself), since they seem decently active in helping with issues.
Pages