I want to get input from stdin: here is my code:
var x: int;
x = read(int);
writeln("You entered: ", x);
I compile like this: chpl io_1.chpl
I run like this: ./io_1 -nl 1
and get this error:
uncaught EofError: end of file (while reading int(64) with path "unknown" offset 0)
io_1.chpl:5: thrown here
io_1.chpl:5: uncaught here
Can someone please enlighten me on what I'm doing wrong?
Hi Roger —
Welcome to the Chapel Discourse!
Can you share what sort of system you're running on and what your CHPL_COMM and CHPL_LAUNCHER variables are being set or inferred to? (where you can run
$CHPL_HOME/util/printchplenv to find out, if you didn't set them manually).
Thanks for the response.
machine info: FreeBSD pyrope 12.4-RELEASE-p3 FreeBSD 12.4-RELEASE-p3 GENERIC amd64
CHPL_HOME: /home/rmason/Software/Chapel/chapel-1.32.0 *
script location: /usr/home/rmason/Software/Chapel/chapel-1.32.0/util/chplenv
CHPL_COMM: gasnet *
I'm setting some envars in my ~/.zshrc:
export GASNET_SSH_SERVERS="this that"
Hi Roger —
Unfortunately, I believe that you are running into a limitation of using
CHPL_LAUNCHER=amudp for distributed memory runs, due to
amudprun not supporting re-routing of console input /
This is something I have not thought about, nor run into, for some time, but I can reproduce your behavior locally. Checking some mail from 2007, I'm seeing a statement from the GASNet team (who provide
amudprun and the GASNet communication library that
CHPL_COMM=gasnet relies upon) that this configuration did not support any forwarding of
stdin at that time; and given that their focus is almost soley on high-performance networks, I'd be surprised if the situation had changed since then (but could check if that'd be of interest). I'm also realizing that our documentation should make this clearer and have opened Improve documentation with respect to launcher support for `stdin` · Issue #23718 · chapel-lang/chapel · GitHub to capture that TODO.
stdin is supported by many of our other launchers for distributed memory runs, such as slurm-based launchers and other gasnetrun_* launchers. However, I'm not currently aware of a way to use
udp as the communication mechanism on multiple nodes and to have
stdin be re-routed. Maybe there's something heroic that could be done, though, that I'm not thinking of.
stdin does seem to work OK with
amudprunin some cases that target the local node, like when using GASNET_SPAWNFN=L to simulate running multiple locales by running them all locally. This isn't very useful for production runs, but can serve as a way to debug multi-locale runs locally before deploying them to systems using a communication mechanism other than 'udp'.
I'm curious how big of a blocker this is for you. E.g., would it be possible to read the inputs you're looking for from a file rather than from
stdin? (or to set them via command-line arguments?).
Also, I want to mention that
udp as a communication option in GASNet and Chapel is provided for the sake of portability and convenience, but is not considered a high-performance communication option (in case that matters for your use case). We use it extensively for development and debugging, but rely on other
CHPL_COMM_SUBSTRATE options when performance matters.
Thank you for making such a thorough reply. Indeed, I can use command line arguments instead of relying on stdin. I have not tried reading from a file but no doubt that would work too. I am running tests on a couple of clunky old machines with modest network performance, hence using udp. Mentioning that limitation in the docs would be useful, I think.
Hi Roger —
If you're already running on multiple locales with GASNet, you probably know enough Chapel to know this as well, but:
If command-line args are an option, a case like the one in your original post would be well-handled by a
config declaration, like:
config var x: int;
where you could then run your program like:
$ ./myProgram -nl 1 --x=42
to set the value of
x. If you need to do something more complicated than a
config can support (or support easily), the
ArgumentParser package is another option before resorting to file I/O: ArgumentParser — Chapel Documentation 1.32
Bradcray via Chapel Programming Language firstname.lastname@example.org writes:
If you need to do something more complicated than a config can support
(or support easily), the ArgumentParser package is another option
before resorting to file I/O: ArgumentParser — Chapel Documentation
Ah yes, good idea.