* [Caml-list] error messages to stdout? @ 2002-01-16 5:12 Doug Bagley 2002-01-16 18:50 ` Warp 2002-01-16 19:49 ` Remi VANICAT 0 siblings, 2 replies; 9+ messages in thread From: Doug Bagley @ 2002-01-16 5:12 UTC (permalink / raw) To: caml-list I've been learning how to use Ocaml for writing scripts, and I've encountered a small problem. By "scripts", I mean they have the canonical custom toplevel in the interpreter line. They also dynamically load libs. I had updated one lib and not another that depended on it, so I got a message like so, to stdout: File /usr/local/lib/ocaml/contrib/fs_lib.cma is not up-to-date with respect to interface Pcre The problem was that I piped my ocaml script's output to a file that was supposed to just contain data, and then I graphed it, so the error message showed up in a graph, which was kind of funny but not what I expected. I use pipes and filters a lot, so this could really put a wrench in my plans. Anyway, it would be like, cool, if I could get those errors going to stderr instead, or be enlightened as to the error of my ways. Thanks. cheers, doug ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Caml-list] error messages to stdout? 2002-01-16 5:12 [Caml-list] error messages to stdout? Doug Bagley @ 2002-01-16 18:50 ` Warp 2002-01-16 19:06 ` Doug Bagley 2002-01-16 19:49 ` Remi VANICAT 1 sibling, 1 reply; 9+ messages in thread From: Warp @ 2002-01-16 18:50 UTC (permalink / raw) To: caml-list, Doug Bagley > File /usr/local/lib/ocaml/contrib/fs_lib.cma is not up-to-date with respect to > interface Pcre > > The problem was that I piped my ocaml script's output to a file that > was supposed to just contain data, and then I graphed it, so the error > message showed up in a graph, which was kind of funny but not what I > expected. I use pipes and filters a lot, so this could really put a > wrench in my plans. > > Anyway, it would be like, cool, if I could get those errors going to > stderr instead, or be enlightened as to the error of my ways. Thanks. If this message comes from RunTime ( when Dynamic Linking ) then that might be an exception throwed by the dynlink. Then you can catch it and print it to stderr ( using Printexc.to_string ) ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Caml-list] error messages to stdout? 2002-01-16 18:50 ` Warp @ 2002-01-16 19:06 ` Doug Bagley 0 siblings, 0 replies; 9+ messages in thread From: Doug Bagley @ 2002-01-16 19:06 UTC (permalink / raw) To: caml-list Warp wrote: > If this message comes from RunTime ( when Dynamic Linking ) then > that might be an exception throwed by the dynlink. Then you can > catch it and print it to stderr ( using Printexc.to_string ) Well, I may be wrong, but this message is just printed to stdout by toplevel/topdirs.ml ... it is not the result of an exception. And, I'm no expert, but I believe "exceptions" already go to stderr. The philosophy of printing all errors and diagnostics to a separate channel from program data is, well, maybe the way to go? Just my .02 Euros. cheers, doug ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Caml-list] error messages to stdout? 2002-01-16 5:12 [Caml-list] error messages to stdout? Doug Bagley 2002-01-16 18:50 ` Warp @ 2002-01-16 19:49 ` Remi VANICAT 2002-01-16 20:09 ` Doug Bagley 1 sibling, 1 reply; 9+ messages in thread From: Remi VANICAT @ 2002-01-16 19:49 UTC (permalink / raw) To: caml-list Doug Bagley <doug@bagley.org> writes: > I've been learning how to use Ocaml for writing scripts, and I've > encountered a small problem. > > By "scripts", I mean they have the canonical custom toplevel in the > interpreter line. They also dynamically load libs. > > I had updated one lib and not another that depended on it, so I got a > message like so, to stdout: > > File /usr/local/lib/ocaml/contrib/fs_lib.cma is not up-to-date with respect to > interface Pcre > > The problem was that I piped my ocaml script's output to a file that > was supposed to just contain data, and then I graphed it, so the error > message showed up in a graph, which was kind of funny but not what I > expected. I use pipes and filters a lot, so this could really put a > wrench in my plans. > > Anyway, it would be like, cool, if I could get those errors going to > stderr instead, or be enlightened as to the error of my > ways. Thanks. you should compile your program to (at least) bytecode code. It will be faster, and those kind of error will only exist at compile time, not at execution time... ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Caml-list] error messages to stdout? 2002-01-16 19:49 ` Remi VANICAT @ 2002-01-16 20:09 ` Doug Bagley 2002-01-17 18:33 ` John Malecki 0 siblings, 1 reply; 9+ messages in thread From: Doug Bagley @ 2002-01-16 20:09 UTC (permalink / raw) To: caml-list Remi VANICAT wrote: > you should compile your program to (at least) bytecode code. It will > be faster, and those kind of error will only exist at compile time, > not at execution time... Well, I certainly could do that, but I was hoping to use Ocaml to replace my bash/awk/sed/perl scripts. For me, the convenience of having one single source file, and no compilation step, is one of the attractions of "scripts". As far as I can tell, the extra load time due to compilation of the script is negligible, and I assume the run-time is equivalent to a pre-compiled byte-code executable? I have many scripts that do filtering, so having a clean output stream is important to me. It seems to me that if the ability to use a custom toplevel as a script interpreter exists, then it would be very nice if it printed all diagnostics to stderr. Anyway, I have a workaround, I wrote a "trampoline" program that can be used in place of the toplevel interpreter and does the compilation transparently for lazy persons such as myself. It essentially turns any compiled language into a scripting language. If anyone is interested in it ... I could clean it up for public consumption. cheers, doug ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Caml-list] error messages to stdout? 2002-01-16 20:09 ` Doug Bagley @ 2002-01-17 18:33 ` John Malecki 2002-01-17 19:15 ` Doug Bagley ` (2 more replies) 0 siblings, 3 replies; 9+ messages in thread From: John Malecki @ 2002-01-17 18:33 UTC (permalink / raw) To: Doug Bagley; +Cc: caml-list Doug Bagley wrote (2002-01-16T14:09:48-0600): > > Anyway, I have a workaround, I wrote a "trampoline" program that can > be used in place of the toplevel interpreter and does the compilation > transparently for lazy persons such as myself. > > It essentially turns any compiled language into a scripting language. > If anyone is interested in it ... I could clean it up for public > consumption. Hi Doug, I'd be interested in the trampoline program. At the moment we are operating in a homogeneous computing environment. Sooner or later we will add some a different computer architecture to our pool and I was thinking about how to take advantage of compiling byte-code once and using it on all platforms. This has the advantage that a developer can compile once, on any one platform, and make that program immediately available on all other machine architectures. I'm not sure of the best way to do this. I was thinking of using the bash MACHTYPE environment variable and then install the byte-code program in /usr/local/bin but have the 1st line of that file say #! /usr/local/bin/ocamlrun.$MACHTYPE Unfortunately the loader does not perform environment variable expansion. I tried other tricks but I couldn't find a simple "1 liner". I'm still looking for something simple. If anyone has any ideas I'd like to hear them. (Yes, there are probably automount tricks I could use but I'm looking for a solution that will work for people without administrator privileges.) -cheers ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Caml-list] error messages to stdout? 2002-01-17 18:33 ` John Malecki @ 2002-01-17 19:15 ` Doug Bagley 2002-01-19 8:11 ` Stefano Zacchiroli 2002-01-19 8:46 ` Florian Douetteau 2 siblings, 0 replies; 9+ messages in thread From: Doug Bagley @ 2002-01-17 19:15 UTC (permalink / raw) To: John Malecki; +Cc: caml-list John Malecki wrote: > Doug Bagley wrote (2002-01-16T14:09:48-0600): > > > > Anyway, I have a workaround, I wrote a "trampoline" program that can > > be used in place of the toplevel interpreter and does the compilation > > transparently for lazy persons such as myself. > > > > It essentially turns any compiled language into a scripting language. > > If anyone is interested in it ... I could clean it up for public > > consumption. > > Hi Doug, > > I'd be interested in the trampoline program. Well, it's pre-release, and uses some pre-requesite libs of mine that are also pre-release :-) And I haven't had anyone else test out the build process yet, and so on and so forth, but if you are adventurous, you are welcome to take a look and give me feedback, as long as you realize it is a very raw work-in-progress :) It is currently here: http://www.bagley.org/~doug/ocaml/scriptomatic/ It basically hands off the build work to make, and I have a very simple makefile included whichs needs a lot of polishing, but the basic idea seems sound, and I can write "scripts" that compile to byte or optimized Ocaml, or even write "scripts" in C :) The built executables are cached, and only rebuilt if the original script changes. > At the moment we are operating in a homogeneous computing environment. > Sooner or later we will add some a different computer architecture to > our pool and I was thinking about how to take advantage of compiling > byte-code once and using it on all platforms. This has the advantage > that a developer can compile once, on any one platform, and make that > program immediately available on all other machine architectures. > > I'm not sure of the best way to do this. I was thinking of using the > bash MACHTYPE environment variable and then install the byte-code > program in /usr/local/bin but have the 1st line of that file say > > #! /usr/local/bin/ocamlrun.$MACHTYPE > > Unfortunately the loader does not perform environment variable > expansion. I tried other tricks but I couldn't find a simple "1 > liner". I'm still looking for something simple. If anyone has any > ideas I'd like to hear them. I think that simply doing what you want above is a little easier than what I have implemented, and you may wish to use the simplest solution. I've appended an idea for a replacement interpreter that is an "almost one-liner" in C below. It switches the toplevel interpreter based on the machine type environement variable. Maybe it will give you an idea. (Note that on Linux, the program execed by the trampoline may not see itself in argv[0], I sent a note to caml-bugs about an old fix (557), which I think is related to the problem). cheers, doug -- trampo.c: /* gcc trampo.c -o trampo */ #include <stdio.h> main (int argc, char **argv) { char exe[256]; if (snprintf(exe, 256, "ocamlrun.%s", getenv("MACHTYPE")) > -1) execvp(exe, argv); else fprintf(stderr, "ouch\n"); } /* end */ int the shell: export MACHTYPE=MACLISA # or whatever tramptest: #! ./trampo let _ = print_endline "Hello World" ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Caml-list] error messages to stdout? 2002-01-17 18:33 ` John Malecki 2002-01-17 19:15 ` Doug Bagley @ 2002-01-19 8:11 ` Stefano Zacchiroli 2002-01-19 8:46 ` Florian Douetteau 2 siblings, 0 replies; 9+ messages in thread From: Stefano Zacchiroli @ 2002-01-19 8:11 UTC (permalink / raw) To: caml-list On Thu, Jan 17, 2002 at 10:33:06AM -0800, John Malecki wrote: > At the moment we are operating in a homogeneous computing environment. > Sooner or later we will add some a different computer architecture to > our pool and I was thinking about how to take advantage of compiling > byte-code once and using it on all platforms. This has the advantage > that a developer can compile once, on any one platform, and make that > program immediately available on all other machine architectures. > > I'm not sure of the best way to do this. I was thinking of using the > bash MACHTYPE environment variable and then install the byte-code > program in /usr/local/bin but have the 1st line of that file say > > #! /usr/local/bin/ocamlrun.$MACHTYPE Probably I miss the point but if your machines have some local disk data you can install ocamlrun executable locally on each machine but using the same path. In such a way using "#! /usr/local/bin/ocamlrun" will work on each architecture. But, obviously, if all of your filesystems are shared this trick doesn't work. Cheers. -- Stefano "Zack" Zacchiroli <zack@cs.unibo.it> ICQ# 33538863 Home Page: http://www.cs.unibo.it/~zacchiro Undergraduate student of Computer Science @ University of Bologna, Italy - Information wants to be Open - ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Caml-list] error messages to stdout? 2002-01-17 18:33 ` John Malecki 2002-01-17 19:15 ` Doug Bagley 2002-01-19 8:11 ` Stefano Zacchiroli @ 2002-01-19 8:46 ` Florian Douetteau 2 siblings, 0 replies; 9+ messages in thread From: Florian Douetteau @ 2002-01-19 8:46 UTC (permalink / raw) To: John Malecki; +Cc: caml-list > > I'd be interested in the trampoline program. > > At the moment we are operating in a homogeneous computing environment. > Sooner or later we will add some a different computer architecture to > our pool and I was thinking about how to take advantage of compiling > byte-code once and using it on all platforms. This has the advantage > that a developer can compile once, on any one platform, and make that > program immediately available on all other machine architectures. > > I'm not sure of the best way to do this. I was thinking of using the > bash MACHTYPE environment variable and then install the byte-code > program in /usr/local/bin but have the 1st line of that file say > > #! /usr/local/bin/ocamlrun.$MACHTYPE > An usual trick is to make the bytecode file start with #! /path_to_my_mach_type_dispatcher /usr/local/bin/ocamlrun Executing the file will make the system execute: "my_mach_type_dispatcher /usr/local/bin/ocamlrun bytecode-file-name" my_mach_type_dispatcher can be a script as simple as: #! /bin/sh $1.$MACHTYPE $2 Another trick is to make each /usr/local/bin/ocamlrun.$MACHTYPE be a symbol link to a script: $0.$MACHTYPE $@ -- Florian Douetteau ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2002-01-21 10:11 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-01-16 5:12 [Caml-list] error messages to stdout? Doug Bagley 2002-01-16 18:50 ` Warp 2002-01-16 19:06 ` Doug Bagley 2002-01-16 19:49 ` Remi VANICAT 2002-01-16 20:09 ` Doug Bagley 2002-01-17 18:33 ` John Malecki 2002-01-17 19:15 ` Doug Bagley 2002-01-19 8:11 ` Stefano Zacchiroli 2002-01-19 8:46 ` Florian Douetteau
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox