Reading from stdin

Users
1

I want to get input from stdin: here is my code:

use IO;

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?

Thanks,
Roger

2

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,
-Brad

3

Hello Brad,

Thanks for the response.

printchpllenv says:

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_TARGET_PLATFORM: freebsd
CHPL_TARGET_COMPILER: llvm
CHPL_TARGET_ARCH: amd64
CHPL_TARGET_CPU: unknown
CHPL_LOCALE_MODEL: flat
CHPL_COMM: gasnet *
CHPL_COMM_SUBSTRATE: udp
CHPL_GASNET_SEGMENT: everything
CHPL_TASKS: fifo
CHPL_LAUNCHER: amudprun
CHPL_TIMERS: generic
CHPL_UNWIND: none
CHPL_MEM: jemalloc
CHPL_ATOMICS: cstdlib
CHPL_NETWORK_ATOMICS: none
CHPL_GMP: bundled
CHPL_HWLOC: none
CHPL_RE2: bundled
CHPL_LLVM: system
CHPL_AUX_FILESYS: none

I'm setting some envars in my ~/.zshrc:

export CHPL_HOME=$HOME/Software/Chapel/chapel-1.32.0
source $CHPL_HOME/util/mychapelenv.bash
export CHPL_COMM=gasnet
export GASNET_SPAWNFN=S
export GASNET_SSH_SERVERS="this that"

Thanks again,
Roger

4

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 / stdin.

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.

Note that 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 or CHPL_COMM_SUBSTRATE options when performance matters.

Best wishes,
-Brad

5

Hello Brad,

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.

Thanks again,
Best wishes,
Roger

1 Like
6

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

-Brad

7

Hello Brad,

Bradcray via Chapel Programming Language notifications@chapel.discoursemail.com 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
1.32

Ah yes, good idea.

Many thanks,
Roger