Hi all, This is a little offtopic (it deals with luatex only) but as Mojca said: there are many more luatex-using people here than on dev-luatex. In a discussion with Yue Wang he convinced me that it would be better to use uname() for finding os.name instead of the current jungle of #ifdefs. Because I do not want to alter the lua return values, that means I will have to interpret the contents of the returned structure a bit. To do that, I would appreciate it if the people on a non-linux32intel platform would compile and run the attached minimalistic C file. Thanks in advance, Taco
On May 21, 2008, at 2:11 PM, Taco Hoekwater wrote:
Because I do not want to alter the lua return values, that means I will have to interpret the contents of the returned structure a bit. To do that, I would appreciate it if the people on a non-linux32intel platform would compile and run the attached minimalistic C file.
Thanks in advance, Taco
Hi Taco, on i386-darwin, the file doesn't compile (I saved the file as "mini"): ld: warning in mini, file is not of required architecture Undefined symbols: "_main", referenced from: start in crt1.10.5.o ld: symbol(s) not found collect2: ld returned 1 exit status Thomas
on i386-darwin, the file doesn't compile (I saved the file as "mini"):
ld: warning in mini, file is not of required architecture Undefined symbols: "_main", referenced from: start in crt1.10.5.o ld: symbol(s) not found collect2: ld returned 1 exit status
Are you sure you copy the right source code? Here is the result on Mac OS X intel 10.5: $ gcc -Wall test.c -o test epicalyx:c jjgod$ ./test sysname: Darwin nodename: epicalyx.local release: 9.2.2 version: Darwin Kernel Version 9.2.2: Tue Mar 4 21:17:34 PST 2008; root:xnu-1228.4.31~1/RELEASE_I386 machine: i386
On May 21, 2008, at 2:59 PM, Yue Wang wrote:
Are you sure you copy the right source code? Here is the result on Mac OS X intel 10.5:
$ gcc -Wall test.c -o test epicalyx:c jjgod$ ./test sysname: Darwin nodename: epicalyx.local release: 9.2.2 version: Darwin Kernel Version 9.2.2: Tue Mar 4 21:17:34 PST 2008; root:xnu-1228.4.31~1/RELEASE_I386 machine: i386
Oops, sorry, you're right... To make up for it, I can at least send Taco the output from a linux-ppc box: sysname: Linux nodename: g5 release: 2.6.23-gentoo version: #2 SMP Fri Oct 19 10:37:53 CEST 2007 machine: ppc64 Thomas
On May 21, 2008, at 9:11 PM, Taco Hoekwater wrote:
In a discussion with Yue Wang he convinced me that it would be better to use uname() for finding os.name instead of the current jungle of #ifdefs.
Because I do not want to alter the lua return values, that means I will have to interpret the contents of the returned structure a bit. To do that, I would appreciate it if the people on a non-linux32intel platform would compile and run the attached minimalistic C file.
My Intel-based Leopard shows the following result: sysname: Darwin nodename: jin-hwan-chos-macbook.local release: 9.2.2 version: Darwin Kernel Version 9.2.2: Tue Mar 4 21:17:34 PST 2008; root:xnu-1228.4.31~1/RELEASE_I386 machine: i386 Best regards, ChoF.
This is a little offtopic (it deals with luatex only) but as Mojca said: there are many more luatex-using people here than on dev-luatex.
You could also try tlbuild@tug.org, the list of people building binaries for TeX Live, where you can find people running all sorts of architectures. We're in the process of committing binaries for TeX Live 2008 right now, so running a small test would be a welcome distraction and a matter of seconds. Anyway:
To do that, I would appreciate it if the people on a non-linux32intel platform would compile and run the attached minimalistic C file.
You're going to love that: on Solaris compilation works fine, but execution prints “uname() failed”. And indeed, the section 2 man page for uname explains: RETURN VALUES Upon successful completion, a non-negative value is returned. Otherwise, -1 is returned and errno is set to indicate the error. (In that case, it returned 1). Looks like you have to check for errno ... Apart from that, the struct actually contains: sysname: SunOS nodename: harmakis release: 5.9 version: Generic_117171-07 machine: sun4u I also tested on Sparc Linux: sysname: Linux nodename: notung release: 2.6.22-14-sparc64 version: #1 Sun Oct 14 21:57:46 GMT 2007 machine: sparc64 Note that “sun4u” means more or less the same than “sparc64”. Arthur
Hi,
You're going to love that: on Solaris compilation works fine, but execution prints "uname() failed". And indeed, the section 2 man page for uname explains:
I am aware of that because there is some solaris users encountered the same failure here. It seems that we should use umask() function first. I had nudged Taco about that problem and provided a possible solution just ago. Yue Wang
2008/5/22 Arthur Reutenauer
No; instead of (uname(&uts)) it should be (uname(&uts) < 0) .
Well, no: if the function fails on Linux and returns, say, 1, this test wouldn't catch it. But Taco knows what to do, and the discussion
From uname(2) on Linux: RETURN VALUE On success, zero is returned. On error, -1 is returned, and errno is set appropriately.
And SUS3 has this: Upon successful completion, a non-negative value shall be returned. Otherwise, -1 shall be returned and errno set to indicate the error. Best Martin
Hi, Arthur and Taco
On 5/22/08, Arthur Reutenauer
No; instead of (uname(&uts)) it should be (uname(&uts) < 0) .
Well, no: if the function fails on Linux and returns, say, 1, this test wouldn't catch it. But Taco knows what to do, and the discussion is getting even more off-topic :-)
No, It wont. In Linux/FreeBSD/Mac OS X, -1 will return if it failed. I am pretty sure about that because I read the manual pages of these operating systems yesterday. Again, see the Open Group Specification, (all the Unix and Unix like operating system should follow the Open Group Specification or otherwise it cannot be called Unix or Unix like. There is no need for us to pay attention to the non-Unix(like) systems apart from Windows.): http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/utsname.h.html The return value section: A NON-NEGATIVE VALUE shall be returned. Otherwise -1 should be returned and set errono to indicate an error. so we should better write our program like this: if (uname(&uts)<0) { /*or we can also say if uname(&uts)==-1*/ puts("uname() failed"); } Here Taco, as I said yesterday, there is no need to leave a #ifdef for the solaris operating system. Just remove all the jungles and remain only one #ifdef for Windows system, and leave the rest time to spend a good weekend:)
Because I do not want to alter the lua return values, that means I will have to interpret the contents of the returned structure a bit.
I think it is better to only return a table while calling the Lua function. The table contains key=value pairs for {sysname=,nodename=,release=, version=,machine=}. For Windows, you just fill these names by hand instead(easy, isn't it?). Keep the problem small and simple, as well as flexible, and leave everything toplevel for higher programs like ConTeXt. LuaTeX is going public in months, so before that every major API change is OK to the developers. After public, changing APIs will make other developers unhappy. Yue Wang
Hi, Yue Wang wrote:
I think it is better to only return a table while calling the Lua function. The table contains key=value pairs for {sysname=,nodename=,release=, version=,machine=}. For Windows, you just fill these names by hand instead(easy, isn't it?).
Easy to say, sure. You are not on windows either, I assume? Anyway, 0.30.0 will have both the old and the new ( os.uname() function), and the old variables will not go away until 0.40.0.
LuaTeX is going public in months, so before that every major API change is OK to the developers. After public, changing APIs will make other developers unhappy.
I do not know what you are referring to. Nothing in the API is fixed until 1.0.0, and that is still a few years off ! Best wishes, Taco
On Thu, May 22, 2008 at 1:21 PM, Taco Hoekwater
Hi,
Yue Wang wrote:
I think it is better to only return a table while calling the Lua function. The table contains key=value pairs for {sysname=,nodename=,release=, version=,machine=}. For Windows, you just fill these names by hand instead(easy, isn't it?).
Easy to say, sure. You are not on windows either, I assume?
Anyway, 0.30.0 will have both the old and the new ( os.uname() function), and the old variables will not go away until 0.40.0.
LuaTeX is going public in months, so before that every major API change is OK to the developers. After public, changing APIs will make other developers unhappy.
I do not know what you are referring to. Nothing in the API is fixed until 1.0.0, and that is still a few years off !
hmm, we must what david says about that, see http://granthinam.blogspot.com/search/label/Conference report "Kastrup, one of the developers of LuaTeX," :)))))))))))))) -- luigi it's new . it's powerful . it's luatex . http://www.luatex.org
luigi scarso wrote:
On Thu, May 22, 2008 at 1:21 PM, Taco Hoekwater
wrote: Hi,
Yue Wang wrote:
I think it is better to only return a table while calling the Lua function. The table contains key=value pairs for {sysname=,nodename=,release=, version=,machine=}. For Windows, you just fill these names by hand instead(easy, isn't it?). Easy to say, sure. You are not on windows either, I assume?
Anyway, 0.30.0 will have both the old and the new ( os.uname() function), and the old variables will not go away until 0.40.0.
LuaTeX is going public in months, so before that every major API change is OK to the developers. After public, changing APIs will make other developers unhappy. I do not know what you are referring to. Nothing in the API is fixed until 1.0.0, and that is still a few years off ! hmm, we must what david says about that, see http://granthinam.blogspot.com/search/label/Conference report "Kastrup, one of the developers of LuaTeX,"
funny, the luatex team is 3*h (hoekwater, henkel & hagen) ... small is beautiful (efficient and effective) -) ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
hmm, we must what david says about that, see http://granthinam.blogspot.com/search/label/Conference report "Kastrup, one of the developers of LuaTeX,"
funny, the luatex team is 3*h (hoekwater, henkel & hagen) ... small is beautiful (efficient and effective) -) yes, but 3hk is one thousand 3h..
Sorry I cannot resist.... :))))) -- luigi it's new . it's powerful . it's luatex . http://www.luatex.org
Yue Wang wrote:
Hi, Arthur and Taco
On 5/22/08, Arthur Reutenauer
wrote: No; instead of (uname(&uts)) it should be (uname(&uts) < 0) . Well, no: if the function fails on Linux and returns, say, 1, this test wouldn't catch it. But Taco knows what to do, and the discussion is getting even more off-topic :-)
No, It wont. In Linux/FreeBSD/Mac OS X, -1 will return if it failed. I am pretty sure about that because I read the manual pages of these operating systems yesterday.
i suggest to direct mails about this topic to taco directly Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On Wed, May 21 2008, Taco Hoekwater wrote:
Because I do not want to alter the lua return values, that means I will have to interpret the contents of the returned structure a bit. To do that, I would appreciate it if the people on a non-linux32intel platform would compile and run the attached minimalistic C file.
Result on openSUSE-x86_64: sysname: Linux nodename: gaston release: 2.6.23.1-13-default version: #1 SMP 2007/11/01 23:00:04 UTC machine: x86_64 Cheers, Peter -- http://pmrb.free.fr/contact/
2008/5/21 Taco Hoekwater
Hi all,
This is a little offtopic (it deals with luatex only) but as Mojca said: there are many more luatex-using people here than on dev-luatex.
sysname: FreeBSD nodename: genipizza.casadep.home release: 8.0-CURRENT version: FreeBSD 8.0-CURRENT #0: Tue May 13 23:26:04 CEST 2008 machine: i386 -- Diego Depaoli
"Taco" == Taco Hoekwater
writes:
Hi! Taco> Thanks in advance, Taco Output on my x86-64 laptop gour@nitai ~> uname -a Linux nitai 2.6.24-zen5-20080404 #6 SMP PREEMPT Fri Apr 4 13:18:03 CEST 2008 x86_64 AMD Turion(tm) 64 Mobile ML-34 AuthenticAMD GNU/Linux gives: sysname: Linux nodename: nitai release: 2.6.24-zen5-20080404 version: #6 SMP PREEMPT Fri Apr 4 13:18:03 CEST 2008 machine: x86_64 Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D ----------------------------------------------------------------
Le mercredi 21 mai 2008 à 22:09 +0200, Gour a écrit :
"Taco" == Taco Hoekwater
writes: Hi!
'lo, mh@home:~/Documents/Tata$ uname -a Linux home 2.6.24-17-generic #1 SMP Thu May 1 14:31:33 UTC 2008 i686 GNU/Linux mh@home:~/Documents/Tata$ RAS mh
Taco> Thanks in advance, Taco
Output on my x86-64 laptop
gour@nitai ~> uname -a Linux nitai 2.6.24-zen5-20080404 #6 SMP PREEMPT Fri Apr 4 13:18:03 CEST 2008 x86_64 AMD Turion(tm) 64 Mobile ML-34 AuthenticAMD GNU/Linux
gives:
sysname: Linux nodename: nitai release: 2.6.24-zen5-20080404 version: #6 SMP PREEMPT Fri Apr 4 13:18:03 CEST 2008 machine: x86_64
Sincerely, Gour
___________________________________________________________________________________ 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 : https://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___________________________________________________________________________________
Hi All, Just to wrap this up: thanks everybody for their results, it has been useful. The luatex trunk now has support for os.uname(), also under Windows. Some people may find it interesting to see the outcome of this mini-survey. Here is a tally of what I received from various people, besides my own Linux/i386-es, and Hans' Windows Vista/i686: 1 CYGWIN_NT-5.1/i686 6 Darwin/i386 2 Darwin/Power Macintosh 1 FreeBSD/amd64 1 FreeBSD/i386 1 HP-UX/ia64 1 IRIX64/IP27 1 IRIX/IP32 1 Linux/i686 2 Linux/ppc 1 Linux/ppc64 2 Linux/sparc64 5 Linux/x86_64 1 OpenBSD/i386 1 OpenVMS/HP_rx2600__(1.40GHz/1.5MB) 2 SunOS/sun4u Best wishes, Taco
On Wed, May 21, 2008 at 2:11 PM, Taco Hoekwater wrote:
In a discussion with Yue Wang he convinced me that it would be better to use uname() for finding os.name instead of the current jungle of #ifdefs.
Because I do not want to alter the lua return values, that means I will have to interpret the contents of the returned structure a bit. To do that, I would appreciate it if the people on a non-linux32intel platform would compile and run the attached minimalistic C file.
Oh, yes ... the garden returns sysname: Linux nodename: paris release: 2.6.18 version: #1 SMP Sun Feb 10 17:55:04 UTC 2008 machine: x86_64 and runs in 32-bit mode. I guess there is no way to fix that (on the server side), right? Unaltered minimals with automatic platform recognition already fail to work already anyway. Mojca
participants (13)
-
Arthur Reutenauer
-
Diego Depaoli
-
Gour
-
Hans Hagen
-
Jin-Hwan Cho
-
luigi scarso
-
Martin Schröder
-
Michael Hallgren
-
Mojca Miklavec
-
Peter Münster
-
Taco Hoekwater
-
Thomas A. Schmitz
-
Yue Wang