[NTG-context] Feedback on draft manual
How does one provide feedback on the current draft manual at: http://pmrb.free.fr/contextref.pdf Thanks. Chandra ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] calling ConTeXt as a background process
Am 2010-10-07 um 18:32 schrieb Florian Wobbe: Well, remote sensing with computers is cumbersome and as I haven't got a clue what happens on your machine I'd rather see your the shell script. Don't keep fixed on that shell script - it was only one of many failed attempts. context itself is only a shell script that calls mtxrun. It doesn't matter how I call ConTeXt from the server process - it hangs at texlua. How is this script intended to be called: as a subshell from the prompt, as a cron job in the background, ...? At the end I want to run it via Celery/RabbitMQ (an AMQP message queue), but since that's another complication, I tried first to run it directly from my Django view (in other framework's talk that's the controller). I've got Ubunto and OSX here and could try to reproduce the error for you, if you post your script. Thank you, but the problem is most probably something in my server setup that doesn't fit something in LuaTeX. As I mentioned: I got no problems calling TeX directly, just from the server process. A shell script with just these 4 lines #!/bin/bash cd $HOME/context/tests export PATH=$PATH:$HOME/applic/context/tex/texmf-linux-64/bin context --batchmode test.tex works as expected on Ubunto 2.6.32-24-server x86_64 with an almost empty environment (none of the TEX* variables set). You just have to set the path to context - nothing else is necessary. As for the environment variables set: you can test for that in the script via 'env' and redirect the output to a file. Guess what I tested before complaining. I redirect the whole process output to a log file, unfortunately I catch no message from TeX whatsoever, e.g. with set date context hello I get the env settings and the date, but no message from context. I'll write a summary. Greetlings from Lake Constance! Hraban --- http://www.fiee.net/texnique/ http://wiki.contextgarden.net https://www.cacert.org (I'm an assurer) ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] Feedback on draft manual
On 10/08/2010 08:54 AM, R (Chandra) Chandrasekhar wrote: How does one provide feedback on the current draft manual at: http://pmrb.free.fr/contextref.pdf The supelec.fr project for the reference manual has a dedicated mailing list: http://foundry.supelec.fr/mailman/listinfo/contextman-reference That is by far the best place to post actual feedback. See also the actual project page: http://foundry.supelec.fr/gf/project/contextman Best wishes, Taco ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] calling ConTeXt as a background process
On Oct 8, 2010, at 09:36 , Henning Hraban Ramm wrote: I've got Ubunto and OSX here and could try to reproduce the error for you, if you post your script. Thank you, but the problem is most probably something in my server setup that doesn't fit something in LuaTeX. As I mentioned: I got no problems calling TeX directly, just from the server process. All right. I have one more suggestion. If you don't want to dive into debugging via gdb you should try another attempt at strace. Previously you posted a tracedump of context. But it only shows context (the shell script) waiting and nothing related to luatex. You may want to make strace follow forks (-f). Florian ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] calling ConTeXt as a background process
Summary so far: * Machine: virtual server on Debian 5.0 (x86_64) (I thought it was Ubuntu, because I run that on my other Linux machines, sorry). * Webserver: Django 1.2/fcgi (Python 2.5) behind Nginx I can run ConTeXt without any problems from the shell, also as the same user that runs the server process. From the shell it doesn't matter if I call it as context (that's a shell script calling mtxrun), mtxrun, other shell script or simple Python script. I want to run ConTeXt from the server process (at the end I want it to run via Celery/RabbitMQ, but that doesn't matter at the moment), but it hangs at the texlua process and doesn't do anything. - With an unmodified mtxrun that hangs at its external uname call (gets defunct); I patched it to just take x86_64 instead of calling uname. - After that it doesn't matter how I call ConTeXt, it always hangs at texlua. - I tried os.system (that directly uses C's system call) and several variants of subprocess.Popen - I tried calling setuptex as well as setting PATH, TEXROOT and TEXMFOS for the environment of the process and checked that they exist in the call. - Calls of several linux tools via os.system or subprocess.Popen worked. I suspected SElinux settings, Taco hinted at AppArmor, but both aren't active, as far as I can tell. So, the problem is with the web server and texlua. Django/fcgi unfortunately swallows error messages (known problem of the fcgi mode). Next I'll try a different server setup. Unfortunately Apache with mod_wsgi or mod_python is too heavy for my virtual server (with Nginx I can run more that 5 Django sites, with Apache I had massive ressource problems with 3-4). Green Unicorn (http://gunicorn.org/) looks good for my purpose. Sorry for the OT thread, I suspected the problem being more in the LuaTeX area. Greetlings from Lake Constance! Hraban --- http://www.fiee.net/texnique/ http://wiki.contextgarden.net https://www.cacert.org (I'm an assurer) ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] calling ConTeXt as a background process
Sorry for the OT thread, I suspected the problem being more in the LuaTeX area. I don't think it's in the LuaTeX area, for LuaTeX is just a regular process. I have to admit that I have run into similar problems with different software I tried to run from a server process (whatever this means) and it always took me some time to get it right. At the end it was aways clear to me why it wouldn't run (but I can't remember anymore, since it is many years ago). So I suggest to replace the LuaTeX call with different other software and see where it breaks. Use software that reads STDIN, that writes to STDOUT/STDERR and alike and see if they are ok. Patrick ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] calling ConTeXt as a background process
On Fri, Oct 8, 2010 at 10:00 AM, Henning Hraban Ramm hra...@fiee.net wrote: Summary so far: * Machine: virtual server on Debian 5.0 (x86_64) (I thought it was Ubuntu, because I run that on my other Linux machines, sorry). * Webserver: Django 1.2/fcgi (Python 2.5) behind Nginx I can run ConTeXt without any problems from the shell, also as the same user that runs the server process. From the shell it doesn't matter if I call it as context (that's a shell script calling mtxrun), mtxrun, other shell script or simple Python script. I want to run ConTeXt from the server process (at the end I want it to run via Celery/RabbitMQ, but that doesn't matter at the moment), but it hangs at the texlua process and doesn't do anything. An user permissions/environment issue ? After this I have no other suggestions. -- luigi ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] calling ConTeXt as a background process
Am 2010-10-08 um 09:59 schrieb Florian Wobbe:
Thank you, but the problem is most probably something in my server
setup that doesn't fit something in LuaTeX.
As I mentioned: I got no problems calling TeX directly, just from
the server process.
All right. I have one more suggestion. If you don't want to dive
into debugging via gdb you should try another attempt at strace.
Previously you posted a tracedump of context. But it only shows
context (the shell script) waiting and nothing related to luatex.
You may want to make strace follow forks (-f).
Sorry, I've no experience using strace. Here we are:
This is how my process tree looked:
14025 ?Sl 0:01 | \_ /var/www/xxx/bin/python /var/
www/xxx/.../manage.py runfcgi ...
14116 ?S 0:00 | \_ /bin/sh -c set
_context.log strace -f context --batchmode --once hello
_context.log
14117 ?S 0:00 | \_ strace -f context --
batchmode --once hello
14118 ?T 0:00 | \_ /bin/sh /var/opt/
context/tex/texmf-linux-64/bin/context --batchmode --once hello
14119 ?R 0:11 | \_ texlua /var/opt/
context/tex/texmf-linux-64/bin/mtxrun --script context --batchmode --
once hello
The logfile was empty, texlua seemed to hang. I killed 14119 and got:
execve(/var/opt/context/tex/texmf-linux-64/bin/context, [context,
--batchmode, --once, hello], [/* 10 vars */]) = 0
brk(0) = 0x8e2e000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x2b08959ac000
uname({sys=Linux, node=aine.fiee.net, ...}) = 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or
directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x2b08959ad000
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or
directory)
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=20573, ...}) = 0
mmap(NULL, 20573, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2b08959af000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or
directory)
open(/lib/libncurses.so.5, O_RDONLY) = 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\320%
\1\0\0\0\0\0@..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=256288, ...}) = 0
mmap(NULL, 2353152, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x2b0895bad000
mprotect(0x2b0895be8000, 2093056, PROT_NONE) = 0
mmap(0x2b0895de7000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|
MAP_FIXED|MAP_DENYWRITE, 3, 0x3a000) = 0x2b0895de7000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or
directory)
open(/lib/libdl.so.2, O_RDONLY) = 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0
\0\1\0\0\0\20\16\0\0\0\0\0\0@..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=14616, ...}) = 0
mmap(NULL, 2109728, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x2b0895dec000
mprotect(0x2b0895dee000, 2097152, PROT_NONE) = 0
mmap(0x2b0895fee000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_DENYWRITE, 3, 0x2000) = 0x2b0895fee000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or
directory)
open(/lib/libc.so.6, O_RDONLY)= 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0
\0\1\0\0\0\300\342\1\0\0\0\0\0@..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1375536, ...}) = 0
mmap(NULL, 3482232, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x2b0895ff
mprotect(0x2b089613a000, 2093056, PROT_NONE) = 0
mmap(0x2b0896339000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|
MAP_FIXED|MAP_DENYWRITE, 3, 0x149000) = 0x2b0896339000
mmap(0x2b089633e000, 17016, PROT_READ|PROT_WRITE, MAP_PRIVATE|
MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2b089633e000
close(3)= 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x2b0896343000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x2b0896344000
arch_prctl(ARCH_SET_FS, 0x2b0896343af0) = 0
mprotect(0x2b0896339000, 12288, PROT_READ) = 0
munmap(0x2b08959af000, 20573) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
open(/dev/tty, O_RDWR|O_NONBLOCK) = -1 ENXIO (No such device or
address)
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffd5440e70) = -1 EINVAL
(Invalid argument)
brk(0) = 0x8e2e000
brk(0x8e2f000) = 0x8e2f000
brk(0x8e3) = 0x8e3
getuid()= 1005
getgid()= 1006
geteuid() = 1005
getegid() = 1006
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
brk(0x8e31000) = 0x8e31000
open(/proc/meminfo, O_RDONLY) = 3
fstat(3,
Re: [NTG-context] calling ConTeXt as a background process
Am 2010-10-08 um 10:37 schrieb luigi scarso: An user permissions/environment issue ? I can't exclude that, but since the web server and its subprocesses run as the same user that I (can) use for login and got no problems running TeX as that user, I wouldn't know where to look for the wrong permissions. Greetlings from Lake Constance! Hraban --- http://www.fiee.net/texnique/ http://wiki.contextgarden.net https://www.cacert.org (I'm an assurer) ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] calling ConTeXt as a background process
On Fri, Oct 8, 2010 at 10:47 AM, Henning Hraban Ramm hra...@fiee.net wrote: Am 2010-10-08 um 10:37 schrieb luigi scarso: An user permissions/environment issue ? I can't exclude that, but since the web server and its subprocesses run as the same user that I (can) use for login and got no problems running TeX as that user, I wouldn't know where to look for the wrong permissions. try to cd to a 777 dir -- luigi ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
[NTG-context] Question for wiki authors
Hi, As you may know, Patrick and I are constantly reviewing the edits on the wiki to filter out bad people(tm). In doing so, it is not always immediately obvious who is doing what because the 'recent changes' list quite often does not contain a useful summary message. This is understandable, but it would really help if everybody would at least put something in the Summary field. On a related note: I think it would be nice if the people that use a wildly different ID on the wiki from their emails on the list could create a short wiki page under their user name so that we can easily make the connection to a 'known person'. This is not a requirement at all, but it would be really handy during administration, so if you do not mind putting such a page up, please do. Thanks, Taco ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] calling ConTeXt as a background process
Am 2010-10-08 um 10:12 schrieb Patrick Gundlach: I don't think it's in the LuaTeX area, for LuaTeX is just a regular process. Hm, I suspect it might be some system call inside LuaTeX that is blocked or the like. I have to admit that I have run into similar problems with different software I tried to run from a server process (whatever this means) and it always took me some time to get it right. At the end it was aways clear to me why it wouldn't run (but I can't remember anymore, since it is many years ago). So I suggest to replace the LuaTeX call with different other software and see where it breaks. Use software that reads STDIN, that writes to STDOUT/STDERR and alike and see if they are ok. A simple case like python -c print 'Hello' works ok. I tried shell commands and simple tools (echo, set, date, touch) before, and strace works, too. Even texlua --help works, so it's not texlua generally. texlua --script context --batchmode --once hello gives: Script file context not found (at least a usable error message, nothing hangs) The same with /var/opt/context/tex/setuptex texlua --script context --batchmode -- once hello Greetlings from Lake Constance! Hraban --- http://www.fiee.net/texnique/ http://wiki.contextgarden.net https://www.cacert.org (I'm an assurer) ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] calling ConTeXt as a background process
Am 2010-10-08 um 09:59 schrieb Florian Wobbe:
Thank you, but the problem is most probably something in my server setup
that doesn't fit something in LuaTeX.
As I mentioned: I got no problems calling TeX directly, just from the
server process.
All right. I have one more suggestion. If you don't want to dive into
debugging via gdb you should try another attempt at strace. Previously you
posted a tracedump of context. But it only shows context (the shell script)
waiting and nothing related to luatex. You may want to make strace follow
forks (-f).
Sorry, I've no experience using strace.
Some things are explained here: http://blog.ksplice.com/tag/unix/
Here we are:
This is how my process tree looked:
14025 ?Sl 0:01 | \_ /var/www/xxx/bin/python
/var/www/xxx/.../manage.py runfcgi ...
14116 ?S 0:00 | \_ /bin/sh -c set _context.log
strace -f context --batchmode --once hello _context.log
14117 ?S 0:00 | \_ strace -f context --batchmode
--once hello
14118 ?T 0:00 | \_ /bin/sh
/var/opt/context/tex/texmf-linux-64/bin/context --batchmode --once hello
14119 ?R 0:11 | \_ texlua
/var/opt/context/tex/texmf-linux-64/bin/mtxrun --script context --batchmode
--once hello
The logfile was empty, texlua seemed to hang. I killed 14119 and got:
[...]
[pid 14119] brk(0xaa3c000) = 0xaa3c000
[pid 14119] brk(0xaa5f000) = 0xaa5f000
[pid 14119] brk(0xaa82000) = 0xaa82000
[pid 14119] brk(0xaaa3000) = 0xaaa3000
[pid 14119] uname({sys=Linux, node=aine.fiee.net, ...}) = 0
This output looks quite messy because it is composed of the mixed output for
five processes. I don't suspect the fault in luatex executable itself, however,
mtxrun calls uname -m in a subshell and my guess is that it hangs there. Have
you tried calling uname alone from your script? Next you could do
strace -ff -o ctxtrace mtxrun --script context --batchmode --once hello
This gives you hopefully four ctxtrace.pid files. Then do (for each pid)
strace -p pid
before killing luatex and see where it hangs. Interrupt and kill your luatex
and have a look at the ctxtrace.* files.
Florian
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___
Re: [NTG-context] calling ConTeXt as a background process
On Fri, Oct 8, 2010 at 11:21 AM, Henning Hraban Ramm hra...@fiee.net wrote: Am 2010-10-08 um 10:12 schrieb Patrick Gundlach: I don't think it's in the LuaTeX area, for LuaTeX is just a regular process. Hm, I suspect it might be some system call inside LuaTeX that is blocked or the like. I have to admit that I have run into similar problems with different software I tried to run from a server process (whatever this means) and it always took me some time to get it right. At the end it was aways clear to me why it wouldn't run (but I can't remember anymore, since it is many years ago). So I suggest to replace the LuaTeX call with different other software and see where it breaks. Use software that reads STDIN, that writes to STDOUT/STDERR and alike and see if they are ok. A simple case like python -c print 'Hello' works ok. I tried shell commands and simple tools (echo, set, date, touch) before, and strace works, too. Even texlua --help works, so it's not texlua generally. texlua --script context --batchmode --once hello gives: Script file context not found (at least a usable error message, nothing hangs) The same with /var/opt/context/tex/setuptex texlua --script context --batchmode --once hello I use something like this os.system(bash -c 'cd /opt/luatex/minimals-new/tex ; source setuptex ; echo $PATH;cd %(jobpath)s context --batch %(filetex)s 2/dev/null 1/dev/null' %kv) -- luigi ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] calling ConTeXt as a background process
Am 2010-10-08 um 11:25 schrieb Florian Wobbe:
This output looks quite messy because it is composed of the mixed
output for five processes. I don't suspect the fault in luatex
executable itself, however, mtxrun calls uname -m in a subshell and
my guess is that it hangs there. Have you tried calling uname alone
from your script?
As I told Taco and Luigi off-list:
Simply calling uname works
as well as calling it in a shell script
as well as calling another Python script that calls uname.
Next you could do
strace -ff -o ctxtrace mtxrun --script context --batchmode --once
hello
Ok, here we are:
14203 ?Sl 0:01 | \_ /var/www/xxx/bin/python /var/
www/.../manage.py runfcgi method=threaded ...
14255 ?S 0:00 | \_ strace -ff -o ctxtrace
mtxrun --script context --batchmode --once hello
14256 ?R 0:06 | \_ texlua /var/opt/context/
tex/texmf-linux-64/bin/mtxrun --script context --batchmode --once hello
This gives you hopefully four ctxtrace.pid files.
I got only one for 14256
Then do (for each pid)
strace -p pid
before killing luatex and see where it hangs. Interrupt and kill
your luatex and have a look at the ctxtrace.* files.
strace -p 14256
attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted
(as the same user as well as as root)
After killing my log file is empty. The ctxtrace file says:
execve(/var/opt/context/tex/texmf-linux-64/bin/mtxrun, [mtxrun, --
script, context, --batchmode, --once, hello], [/* 10 vars
*/]) = 0
brk(0) = 0xe092000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x2b782d964000
uname({sys=Linux, node=aine.fiee.net, ...}) = 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or
directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x2b782d965000
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or
directory)
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=20573, ...}) = 0
mmap(NULL, 20573, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2b782d967000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or
directory)
open(/lib/libc.so.6, O_RDONLY)= 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0
\0\1\0\0\0\300\342\1\0\0\0\0\0@..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1375536, ...}) = 0
mmap(NULL, 3482232, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x2b782db65000
mprotect(0x2b782dcaf000, 2093056, PROT_NONE) = 0
mmap(0x2b782deae000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|
MAP_FIXED|MAP_DENYWRITE, 3, 0x149000) = 0x2b782deae000
mmap(0x2b782deb3000, 17016, PROT_READ|PROT_WRITE, MAP_PRIVATE|
MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2b782deb3000
close(3)= 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x2b782deb8000
arch_prctl(ARCH_SET_FS, 0x2b782deb86e0) = 0
mprotect(0x2b782deae000, 12288, PROT_READ) = 0
munmap(0x2b782d967000, 20573) = 0
brk(0) = 0xe092000
brk(0xe0b3000) = 0xe0b3000
execve(/var/opt/context/tex/texmf-linux-64/bin/texlua, [texlua, /
var/opt/context/tex/texmf-linux..., --script, context, --
batchmode, --once, hello], [/* 10 vars */]) = 0
brk(0) = 0x1c0fd000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x2acfe2773000
uname({sys=Linux, node=aine.fiee.net, ...}) = 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or
directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x2acfe2774000
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or
directory)
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=20573, ...}) = 0
mmap(NULL, 20573, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2acfe2776000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or
directory)
open(/lib/libdl.so.2, O_RDONLY) = 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0
\0\1\0\0\0\20\16\0\0\0\0\0\0@..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=14616, ...}) = 0
mmap(NULL, 2109728, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x2acfe2974000
mprotect(0x2acfe2976000, 2097152, PROT_NONE) = 0
mmap(0x2acfe2b76000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_DENYWRITE, 3, 0x2000) = 0x2acfe2b76000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or
directory)
open(/lib/libm.so.6, O_RDONLY)= 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0P
\0\0\0\0\0\0@..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=534736, ...}) = 0
mmap(NULL, 2629848, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) =
Re: [NTG-context] calling ConTeXt as a background process
On 8-10-2010 10:00, Henning Hraban Ramm wrote: Sorry for the OT thread, I suspected the problem being more in the LuaTeX area. I never had problems running luatex (texlua) on linux boxes as part of a web service so I cannot image luatex being the problem. Can you see what pdftex does? Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl - ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] calling ConTeXt as a background process
On Oct 8, 2010, at 12:00 , Henning Hraban Ramm wrote:
Am 2010-10-08 um 11:25 schrieb Florian Wobbe:
This output looks quite messy because it is composed of the mixed output for
five processes. I don't suspect the fault in luatex executable itself,
however, mtxrun calls uname -m in a subshell and my guess is that it hangs
there. Have you tried calling uname alone from your script?
As I told Taco and Luigi off-list:
Simply calling uname works
as well as calling it in a shell script
as well as calling another Python script that calls uname.
Next you could do
strace -ff -o ctxtrace mtxrun --script context --batchmode --once hello
Ok, here we are:
14203 ?Sl 0:01 | \_ /var/www/xxx/bin/python
/var/www/.../manage.py runfcgi method=threaded ...
14255 ?S 0:00 | \_ strace -ff -o ctxtrace mtxrun
--script context --batchmode --once hello
14256 ?R 0:06 | \_ texlua
/var/opt/context/tex/texmf-linux-64/bin/mtxrun --script context --batchmode
--once hello
This gives you hopefully four ctxtrace.pid files.
I got only one for 14256
Right, so you are not even getting to the point where luatex is called. This is
still texlua executing instructions from mtxrun.
Then do (for each pid)
strace -p pid
before killing luatex and see where it hangs. Interrupt and kill your luatex
and have a look at the ctxtrace.* files.
strace -p 14256
attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted
(as the same user as well as as root)
Something to do with SElinux?
[...]
read(3, his script\n-- ... later we will u..., 4096) = 4096
read(3, xecute\) then\n\n-- execute scr..., 4096) = 4096
read(3, guments_after)\nresolvers.dowi..., 4096) = 2858
read(3, ..., 4096)= 0
close(3)= 0
munmap(0x2acfe2776000, 4096)= 0
brk(0x1c37a000) = 0x1c37a000
brk(0x1c39d000) = 0x1c39d000
brk(0x1c3c) = 0x1c3c
Here, uname -m should be called. But I guess you still have all unames replaced
by their return value I guess?
brk(0x1c3e1000) = 0x1c3e1000
uname({sys=Linux, node=aine.fiee.net, ...}) = 0
--- SIGTERM (Terminated) @ 0 (0) ---
+++ killed by SIGTERM +++
Here it should continue with reading texmfcnf.lua.
The last
uname({sys=Linux, node=aine.fiee.net, ...
you get is from the os.uname call I would guess.
Try putting the lines
for k, v in next, os.uname() do
print(k, v)
end
in a file and run it with texlua from the script to be sure.
Then you might also try to invoke luatex directly:
luatex --interaction=batchmode --fmt=path to/formats/cont-en --lua=path
to/formats/cont-en.lui --backend=pdf hello
Florian
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___
[NTG-context] typesetting xml targets
Hi all, I'm currently experimenting with the TEI schema for critical editions. There's one thing that goes beyond my minimal understanding: for internal references, the guidelines strongly suggest defining them with the xml:id attribute. Let's take the example of a textual witness, which could be defined as witness xml:id=Amanuscript A/witness Whenever this witness is referenced, it will be done with a target: rdg wit=#AHello/rdg How can I catch such targets in my ConTeXt setup? Would it be possible to have the #A translated into a macro \WIT:A or something like that? Would it be possible to have ConTeXt read in the value of the witness tag to which the taget refers and typset that? There must be something easier than a huge set of nested \doifelse calls, but I can't quite find what would be the best way. I hope this question isn't too confusing... Thanks, and best Thomas ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] calling ConTeXt as a background process
Am 2010-10-08 um 13:46 schrieb Florian Wobbe:
Right, so you are not even getting to the point where luatex is
called. This is still texlua executing instructions from mtxrun.
strace -p 14256
attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted
(as the same user as well as as root)
Something to do with SElinux?
As far as I can tell, SElinux isn't active. (libselinux is installed,
but no other selinux package)
Here, uname -m should be called. But I guess you still have all
unames replaced by their return value I guess?
Yes, I didn't reinstate the original mtxrun script.
brk(0x1c3e1000) = 0x1c3e1000
uname({sys=Linux, node=aine.fiee.net, ...}) = 0
--- SIGTERM (Terminated) @ 0 (0) ---
+++ killed by SIGTERM +++
Here it should continue with reading texmfcnf.lua.
The last
uname({sys=Linux, node=aine.fiee.net, ...
you get is from the os.uname call I would guess.
Probably.
Try putting the lines
for k, v in next, os.uname() do
print(k, v)
end
in a file and run it with texlua from the script to be sure.
That works:
texlua call_uname.lua
version #1 SMP Tue Jul 6 14:34:09 MSD 2010
release 2.6.18-028stab070.2
machine x86_64
nodenameaine.fiee.net
sysname Linux
Then you might also try to invoke luatex directly:
luatex --interaction=batchmode --fmt=path to/formats/cont-en --
lua=path to/formats/cont-en.lui --backend=pdf hello
Now I get the defunct uname again:
16002 15978 TS 21 15:41 ?00:00:01 \_ /var/www/xxx/bin/
python /var/www/.../manage.py run_gunicorn -c /var/www/.../gunicorn-
settings.py
16210 16002 TS 14 15:42 ?00:00:08 \_ luatex --
interaction=batchmode --fmt=/var/opt/context/tex/texmf-cache/.../
formats/cont-en --lua=/var/opt/context/tex/texmf-cache/...
16212 16210 TS 17 15:42 ?00:00:00 \_ [uname]
defunct
(Meanwhile I switched from fcgi to gunicorn app server, but that
didn't change anything WRT ConTeXt.)
I get no log output.
BTW: Thank you very much for your patience! I owe you! (And you, Taco,
of course, and the others!)
Greetlings from Lake Constance!
Hraban
---
http://www.fiee.net/texnique/
http://wiki.contextgarden.net
https://www.cacert.org (I'm an assurer)
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___
Re: [NTG-context] calling ConTeXt as a background process
On 10/08/2010 03:47 PM, Henning Hraban Ramm wrote:
16002 15978 TS 21 15:41 ? 00:00:01 \_ /var/www/xxx/bin/python
/var/www/.../manage.py run_gunicorn -c /var/www/.../gunicorn-settings.py
16210 16002 TS 14 15:42 ? 00:00:08 \_ luatex --interaction=batchmode
--fmt=/var/opt/context/tex/texmf-cache/.../formats/cont-en
--lua=/var/opt/context/tex/texmf-cache/...
16212 16210 TS 17 15:42 ? 00:00:00 \_ [uname] defunct
Hm, defunct, eh?
The luatex binary itself definitely does not call uname as a
process, therefore this has to be the os.resultof() function
that Hans implements in l-os.lua. I am suspecting issues with
redirection now, as that function is defined as:
function os.resultof(command)
local handle = io.popen(command,r)
return handle and handle:read(*all) or
end
and it is called like so:
os.resultof('uname -m')
of course this will fail/block rather horribly if uname -m
does not write to STDOUT (and that is not just uname, thre
are a few more uses of os.resultof()).
Best wishes,
Taco
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___
Re: [NTG-context] calling ConTeXt as a background process
On Fri, Oct 8, 2010 at 3:47 PM, Henning Hraban Ramm hra...@fiee.net wrote:
Am 2010-10-08 um 13:46 schrieb Florian Wobbe:
Right, so you are not even getting to the point where luatex is called.
This is still texlua executing instructions from mtxrun.
strace -p 14256
attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted
(as the same user as well as as root)
Something to do with SElinux?
As far as I can tell, SElinux isn't active. (libselinux is installed, but no
other selinux package)
Here, uname -m should be called. But I guess you still have all unames
replaced by their return value I guess?
Yes, I didn't reinstate the original mtxrun script.
brk(0x1c3e1000) = 0x1c3e1000
uname({sys=Linux, node=aine.fiee.net, ...}) = 0
--- SIGTERM (Terminated) @ 0 (0) ---
+++ killed by SIGTERM +++
Here it should continue with reading texmfcnf.lua.
The last
uname({sys=Linux, node=aine.fiee.net, ...
you get is from the os.uname call I would guess.
Probably.
Try putting the lines
for k, v in next, os.uname() do
print(k, v)
end
in a file and run it with texlua from the script to be sure.
That works:
texlua call_uname.lua
version #1 SMP Tue Jul 6 14:34:09 MSD 2010
release 2.6.18-028stab070.2
machine x86_64
nodename aine.fiee.net
sysname Linux
Then you might also try to invoke luatex directly:
luatex --interaction=batchmode --fmt=path to/formats/cont-en
--lua=path to/formats/cont-en.lui --backend=pdf hello
Now I get the defunct uname again:
16002 15978 TS 21 15:41 ? 00:00:01 \_ /var/www/xxx/bin/python
/var/www/.../manage.py run_gunicorn -c /var/www/.../gunicorn-settings.py
16210 16002 TS 14 15:42 ? 00:00:08 \_ luatex
--interaction=batchmode
--fmt=/var/opt/context/tex/texmf-cache/.../formats/cont-en
--lua=/var/opt/context/tex/texmf-cache/...
16212 16210 TS 17 15:42 ? 00:00:00 \_ [uname] defunct
(Meanwhile I switched from fcgi to gunicorn app server, but that didn't
change anything WRT ConTeXt.)
I get no log output.
valgrind ?
--
luigi
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___
Re: [NTG-context] calling ConTeXt as a background process
function os.resultof(command) local handle = io.popen(command,r) return handle and handle:read(*all) or end shouldn't the handle be close()d? Patrick ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] calling ConTeXt as a background process
Am 2010-10-08 um 15:54 schrieb Taco Hoekwater:
On 10/08/2010 03:47 PM, Henning Hraban Ramm wrote:
16002 15978 TS 21 15:41 ? 00:00:01 \_ /var/www/xxx/bin/python
/var/www/.../manage.py run_gunicorn -c /var/www/.../gunicorn-
settings.py
16210 16002 TS 14 15:42 ? 00:00:08 \_ luatex --interaction=batchmode
--fmt=/var/opt/context/tex/texmf-cache/.../formats/cont-en
--lua=/var/opt/context/tex/texmf-cache/...
16212 16210 TS 17 15:42 ? 00:00:00 \_ [uname] defunct
Hm, defunct, eh?
The luatex binary itself definitely does not call uname as a
process, therefore this has to be the os.resultof() function
that Hans implements in l-os.lua. I am suspecting issues with
redirection now, as that function is defined as:
function os.resultof(command)
local handle = io.popen(command,r)
return handle and handle:read(*all) or
end
The version in the garden has:
function os.resultof(command)
ioflush() -- else messed up logging
local handle = io.popen(command,r)
if not handle then
-- print(unknown command '.. command .. ' in os.resultof)
return
else
return handle:read(*all) or
end
end
and it is called like so:
os.resultof('uname -m')
of course this will fail/block rather horribly if uname -m
does not write to STDOUT (and that is not just uname, thre
are a few more uses of os.resultof()).
I tried to redirect stdout and stderr to my log file, maybe that's a
problem then?
If I call using os.system, I can't redirect, but the result is the same.
I can redirect uname's output like so:
uname -m context.log
So I guess, it's using stdout at least normally - perhaps not via
os.resultof, no clue.
I just don't understand why any lua script would call uname externally
if it's available as os.uname?
Or does os.uname call os.resultof('uname')? (Probably not, otherwise
Florian's suggestion wouldn't have worked.)
print(os.resultof('uname -m'))
gives
attempt to call field 'resultof' (a nil value)
Can I import that function anyhow? I just copied it to my script and
replaced ioflush with io.flush.
My script now calls first os.uname and then the external one.
From the shell it works like expected.
And even from the server process! That alone doesn't seem to be the
problem.
Here's the trace:
strace -ff texlua call_uname.lua
execve(/var/opt/context/tex/texmf-linux-64/bin/texlua, [texlua,
call_uname.lua], [/* 10 vars */]) = 0
brk(0) = 0x6a38000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x2b8eb789f000
uname({sys=Linux, node=aine.fiee.net, ...}) = 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or
directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x2b8eb78a
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or
directory)
open(/etc/ld.so.cache, O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=20573, ...}) = 0
mmap(NULL, 20573, PROT_READ, MAP_PRIVATE, 4, 0) = 0x2b8eb78a2000
close(4)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or
directory)
open(/lib/libdl.so.2, O_RDONLY) = 4
read(4, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0
\0\1\0\0\0\20\16\0\0\0\0\0\0@..., 832) = 832
fstat(4, {st_mode=S_IFREG|0644, st_size=14616, ...}) = 0
mmap(NULL, 2109728, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 4,
0) = 0x2b8eb7aa
mprotect(0x2b8eb7aa2000, 2097152, PROT_NONE) = 0
mmap(0x2b8eb7ca2000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_DENYWRITE, 4, 0x2000) = 0x2b8eb7ca2000
close(4)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or
directory)
open(/lib/libm.so.6, O_RDONLY)= 4
read(4, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0P
\0\0\0\0\0\0@..., 832) = 832
fstat(4, {st_mode=S_IFREG|0644, st_size=534736, ...}) = 0
mmap(NULL, 2629848, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 4,
0) = 0x2b8eb7ca4000
mprotect(0x2b8eb7d26000, 2093056, PROT_NONE) = 0
mmap(0x2b8eb7f25000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_DENYWRITE, 4, 0x81000) = 0x2b8eb7f25000
close(4)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or
directory)
open(/lib/libc.so.6, O_RDONLY)= 4
read(4, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0
\0\1\0\0\0\300\342\1\0\0\0\0\0@..., 832) = 832
fstat(4, {st_mode=S_IFREG|0755, st_size=1375536, ...}) = 0
mmap(NULL, 3482232, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 4,
0) = 0x2b8eb7f27000
mprotect(0x2b8eb8071000, 2093056, PROT_NONE) = 0
mmap(0x2b8eb827, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|
MAP_FIXED|MAP_DENYWRITE, 4, 0x149000) = 0x2b8eb827
mmap(0x2b8eb8275000, 17016, PROT_READ|PROT_WRITE, MAP_PRIVATE|
MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2b8eb8275000
close(4)= 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) =
Re: [NTG-context] typesetting xml targets
On 8-10-2010 2:46, Thomas A. Schmitz wrote: Hi all, I'm currently experimenting with the TEI schema for critical editions. There's one thing that goes beyond my minimal understanding: for internal references, the guidelines strongly suggest defining them with the xml:id attribute. Let's take the example of a textual witness, which could be defined as witness xml:id=Amanuscript A/witness Whenever this witness is referenced, it will be done with a target: rdg wit=#AHello/rdg How can I catch such targets in my ConTeXt setup? Would it be possible to have the #A translated into a macro \WIT:A or something like that? Would it be possible to have ConTeXt read in the value of thewitness tag to which the taget refers and typset that? There must be something easier than a huge set of nested \doifelse calls, but I can't quite find what would be the best way. I hope this question isn't too confusing... can you make me a small example file. i will fill in the bits for you then Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl - ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] calling ConTeXt as a background process
Hi, On 10/08/2010 04:30 PM, Henning Hraban Ramm wrote: I just don't understand why any lua script would call uname externally if it's available as os.uname? My guess is that this is historical. Hans? Best wishes, Taco Sorry, no smart ideas about the rest of the problems any more ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] calling ConTeXt as a background process
Just installed Ruby, fetched the latest beta and tried texexec: 26382 26367 TS 20 16:38 ?00:00:01 \_ /var/www/xxx/bin/ python /var/www/xxx/manage.py run_gunicorn -c /var/www/.../gunicorn- settings.py 26509 26382 TS 20 16:38 ?00:00:00 \_ /bin/sh -c texexec --batchmode --once hello _context.log 26510 26509 TS 20 16:38 ?00:00:00 \_ /bin/sh /var/ opt/context/tex/texmf-linux-64/bin/texexec --batchmode --once hello 26511 26510 TS 14 16:38 ?00:00:21 \_ texlua / var/opt/context/tex/texmf-linux-64/bin/mtxrun --usekpse --execute texexec --batchmode --once hello 26512 26511 TS 14 16:38 ?00:00:00 \_ [uname] defunct Argl, I didn't knew texexec also depends on mtxrun/lua... Ok, patching mtxrun again, now I even replace os.uname, but I get the same as above. Hraban ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] calling ConTeXt as a background process
On Oct 8, 2010, at 16:30 , Henning Hraban Ramm wrote: Am 2010-10-08 um 15:54 schrieb Taco Hoekwater: On 10/08/2010 03:47 PM, Henning Hraban Ramm wrote: 16002 15978 TS 21 15:41 ? 00:00:01 \_ /var/www/xxx/bin/python /var/www/.../manage.py run_gunicorn -c /var/www/.../gunicorn-settings.py 16210 16002 TS 14 15:42 ? 00:00:08 \_ luatex --interaction=batchmode --fmt=/var/opt/context/tex/texmf-cache/.../formats/cont-en --lua=/var/opt/context/tex/texmf-cache/... 16212 16210 TS 17 15:42 ? 00:00:00 \_ [uname] defunct Hm, defunct, eh? The luatex binary itself definitely does not call uname as a process, therefore this has to be the os.resultof() function that Hans implements in l-os.lua. I am suspecting issues with redirection now, as that function is defined as: function os.resultof(command) local handle = io.popen(command,r) return handle and handle:read(*all) or end The strange thing is that running luatex --interaction=batchmode --fmt=.../formats/cont-en --lua=.../formats/cont-en.lui --backend=pdf hello causes luatex (or say l-os.lua) to call 'uname -m' via os.resultof However, when doing mtxrun --script context --batchmode --once hello *only* texlua calls 'uname -m' and the following luatex child does *not* anymore. Why? of course this will fail/block rather horribly if uname -m does not write to STDOUT (and that is not just uname, thre are a few more uses of os.resultof()). if that is the case you should not see any reads after the child forks: clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7feb7a0369d0) = 14998 [...] read(3, x86_64\n, 4096) = 7 read(3, , 4096) = 0 --- SIGCHLD (Child exited) @ 0 (0) --- My script now calls first os.uname and then the external one. From the shell it works like expected. And even from the server process! That alone doesn't seem to be the problem. Here's the trace: strace -ff texlua call_uname.lua [...] I'm running out of ideas. From your script os.resultof(uname -m) works and from luatex it doesn't. What does this trace distinguish from the one of luatex? Florian ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] calling ConTeXt as a background process
On 8-10-2010 4:57, Taco Hoekwater wrote: Hi, On 10/08/2010 04:30 PM, Henning Hraban Ramm wrote: I just don't understand why any lua script would call uname externally if it's available as os.uname? My guess is that this is historical. Hans? yes, and also related to some issues on osx where the built in uname was not yet ok (needs checking, but not today by me) - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl - ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] Question for wiki authors
In doing so, it is not always immediately obvious who is doing what because the 'recent changes' list quite often does not contain a useful summary message. This is understandable, but it would really help if everybody would at least put something in the Summary field. +1 Thanks for mentioning this! Sometimes I am really unsure, especially if this edit is from an anonymous user. Patrick ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] change register entry separator
Hello Hans,
On 10/01/2010 11:20 PM, Hans Hagen wrote:
On 1-10-2010 12:02, Jano Kula wrote:
Hi,
any way to change register entry and subentry separator from + to
something else? Preferably to kanji character, so I'm sure it will not
appear in the text. Entries and subentries are autoflushed, so it can be
really anything.
Other way around: I substitute + with PLUS in index terms before
writing into the index, but which command is reading the sorted index
entries to change it back to + when typesetting the sorted index on
pages?
\setregisterentry[index]
[entries:1=...,
entries:2=...,
entries:3=...,
keys:1=...,
keys:2=...,
keys:3=...,
...
Thank you, it took me a while, to find out if this was the answer to the
first or second question ;) Partly, because there is a bug somewhere, I
think.
If the entry with [keys:1=blue, keys:2=red] is supposed to be sorted by
blue on the first level, and by red on the second, it doesn't work
as expected. Instead of keys, the entries are written into the *.tuc file.
Can you, please, have a look at the minimal example?
Thanks,
Jano
\starttext
\placeregister[index]
\blank[3*big]
\page
% works
\setregisterentry[index][entries=aaa,keys=bbb] page 2
\page
% works
\setregisterentry[index][entries:1=aaa,entries:2=bbb] page 3
\page
% doesn't work
% in *.tuc file the entries are written on both positions
% { aaa, aaa },
% { bbb, bbb },
\setregisterentry[index][entries:1=aaa,entries:2=bbb,keys:1=ccc,keys:2=ddd]
page 4
\stoptext
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___
[NTG-context] Announcing TLContrib
Hello everybody, Please allow me to introduce a new project: TLContrib. TLContrib is a website + repository that hosts contributed packages for TeX Live 2010. The packages on TLContrib are packages that are not distributed inside TeX Live proper for one or another of following reasons: * because it is not free software according to the Debian guidelines; * because it is a binary update; * because it is not available on CTAN; * because it is an intermediate release for testing. In short, anything TeX-related that can not be on TeX Live but can still legally be distributed over the Internet can have its place on TLContrib. The ultimate goal is to provide a companion to the core TeX Live tlnet distribution in much the same way as Debian's non-free tree is a companion to their normal, 100% free software distribution. The goal is not to replace TeX Live: package and updates that can be part of TeX Live itself should stay (or be added) there. TLContrib is simply trying to fill in a gap in the current distribution system. Quick start: to use TLContrib as a TeX Live repository, point the TeX Live package manager to http://tlcontrib.metatex.org/2010/ For more detailed information, visit the website: http://tlcontrib.metatex.org/ The current version of the website is preliminary, and much can still be improved. Even so, both the website and the repository are fully functional and can be used for both the publication of packages and as a repository source for the TeX Live package manager. Currently included in the repository are: * context 2010.07.30 * the context cow fonts * luatex 0.63.0 (but not yet for all architectures) * metapost 1.502 (also not for all architectures) Currently, there are binary updates for i386-linux, universal-darwin win32, x86_64-darwin, and x86_64-linux. Mojca Miklavec and myself are working hard on providing the missing architectures soon. This announcement is also a call for more contributors: if you are the maintainer of a package that you would like to see distributed but that for one reason or another can not or should not be in the core TeX Live distribution, please consider adding it to TLContrib. The website explains the process, and it is of course possible to ask questions on the mailing list: tlcont...@ntg.nl Incidentally, the mailing list's web page is: http://www.ntg.nl/cgi-bin/mailman/listinfo/tlcontrib I hope you will like this new addition to the TeX community, and I also want to take the opportunity to thank the TeX Live and ConTeXt minimals teams for their encouragement and ongoing help in bringing this project to life. Best wishes, Taco ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] calling ConTeXt as a background process (SOLVED)
Ok, the failures were the same with fcgi and gunicorn app servers. But it _works_ with django's dev server (which you must not use in production due to memory/security holes etc.). While ConTeXt runs it looks like: 5852 25767 TS 21 18:04 pts/000:00:00 \_ python manage.py runserver 8000 1477 5852 TS 23 18:07 pts/000:00:03 \_ /var/www/ cerebrale/bin/python manage.py runserver 8000 3395 1477 TS 22 18:08 pts/000:00:00 \_ /bin/sh -c date +%Y-%m-%d %H:%M:%S cd /var/www/.../_textemp /var/opt/ context/tex/texmf-linux-64/bin/context --purgeall --batchmode -- result=/var/www/... 3397 3395 TS 22 18:08 pts/000:00:00 \_ /bin/ sh /var/opt/context/tex/texmf-linux-64/bin/context --purgeall -- batchmode --result=/var/www/... 3398 3397 TS 15 18:08 pts/000:00:00 \_ texlua /var/opt/context/tex/texmf-linux-64/bin/mtxrun --script context --purgeall --batchmode --result=/var/www/... 3400 3398 TS 21 18:08 pts/000:00:00 \_ luatex --interaction=batchmode --fmt=/var/opt/context/tex/texmf- cache/.../cont-en --lua=/var/opt/context/tex... TeX completes fast, and everything seems well afterwards. But I started that app server from an active shell. Maybe that's the difference? Right, if I start gunicorn manually, it also works. So, the culprit seems to be the automatic background start of the app server via daemontools. I'll have to test other means of starting and supervising the processes - e.g. runit or supervisor. Since I like Python and don't want to replace init yet, I try the latter first. Some hours later: YES IT WORKS with supervisor so far! Thank you all for your patience, ideas and help! Greetlings from Lake Constance! Hraban --- http://www.fiee.net/texnique/ http://wiki.contextgarden.net https://www.cacert.org (I'm an assurer) ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
