(No golfing there at all, just increment accumulator until value is reached, output, reset to zero.
Btw, @cairdcoinheringaahing, your docs have something weird in them: "Commands operate on the active accumulator, which can be changed through the use of the <# command." But the description for <#: "XORs active with 1"
In order to output the number 0, the code would need to contain a *\ according to the docs. Or enough spaces to get the charcode for ascii 0. Eitherway, ಠ_ಠ.
@Dennis @Phoenix thanks for figuring that out for me and thanks for getting it on TIO. Yeah I need to fix that in the docs, and I didn't have a Hello world because that's a string and Commentator hates strings.
@saruftw, @Dennis: I don't know much about the TIO implementation of Chapel, but the typical implementation makes queries to the system to determine the number of cores available to determine the default parallelism.
TIO uses this implementation (the official one, yes?), compiled like this and invoked like this. If there's anything I could do better, please let me know.
@Dennis: I'm brand-new to TIO (was brought here by the Chapel port): Are there any policy restrictions against running multiple threads per core from a system utilization perspective? (e.g., we could potentially make the installation oversubscribe).
Also, since you mentioned multiple servers: Is it possible/legal to run a program across multiple servers? (with some minor mods to configuration, this is something we should be able to do quite easily).
@Brad That's not possible at the moment. The reason TIO has multiple servers is to balance the load, and 4 single-core servers are cheaper than one 4-core server. They don't communicate with each other.
@Phoenix They do have internet access. It just isn't exposed to user-supplied code.
OK, thanks, we'll focus on single-node runs for TIO for now.
For reference: Multi-node Chapel would require ssh from the launching node to the servers, the ability to set an environment variable specifying the server names/IP addresses, and UDP between the servers.
We could also potentially simulate multi-node executions by additional oversubscription of the server if it came to that. But I'm going to focus on the multi-threaded part first.
@Dennis: I think we ought to be able to do it without a rebuild by adding an environment variable to the compile + run script. I just have to verify that and figure out which variable to set.
It seems like an intresting language, especially the parallelism seems cool, but I can't even figure out what the example code on the main page of the website is doing.
It essentially deals the integers 1..n out to all of the compute nodes on which the program is running in a cyclic manner, and each of them prints a little hello world message indicating its ID.
It's the standard tension: Don't want to put too much code (bogs down) but want to entice people to look deeper. Sounds like we're on the wrong side of that for your background.
If that had support from an IDE, it could have a section for modifying config variables, allowing you to quickly test values for e.g. the allignment of some graphical element.
Or if you were using a library, you could make customizations without editing the library code.
@Phoenix: config adds command-line support for overriding a symbol's default initializer as specified in the code. So by default, the code will run with a problem size of 100, but running with --n=100000 would override that.
Chapel also supports config types and params (static / compile-time values) which can be specified on the compiler's command-line: essentially a c-pre-processor replacement. e.g., tio.run/…
Except that... something seems broken in the compiler flag settings. E.g., -st=real -sv=1.23 seems to generate a scripting-related error for me. :(
@Phoenix: When do people use pre-processors? :) Switching between 32-bit and 64-bit representations of numeric values, writing a rank-independent algorithm that you can recompile as 1D, 2D or 3D between debug and production runs, etc.
Granted my four-line example is not particularly compelling... :)
@Dennis Sorry to bother you, but I came across something a bit odd that I can't explain. I was trying to make a bubbglegum program from my phone (don't ask), so I used TIO's bash to try this.
I tried to use this output as a bubblegum program, but the output is noise. I noticed that the output of each gzip differs in the fifth byte, but gzip -d seems to work.
@FryAmTheEggman Bubblegum uses raw DEFLATE, not the gzip format. That means you have to cut off the gzip header (ten bytes), and you can cut off the checksum at the end (8 bytes).
@Dennis: I just added a comment to your commit of the Chapel compile + run code with a suggestion for how to enable parallelism in the execution environment. I'm about to break for lunch but will check back later.
To make the case you were running more interesting (report locales other than #0), we'd need to re-build for multiple locales (compute nodes) and add some more environment variables to run them in an oversubscribed manner. Would you be interested in pursuing that?
@Dennis: Related: When does the install step run? When you ask it to? Whenever someone requests a Chapel environment? (seems unlikely given the response times I'm seeing).
@Phoenix: If you change the forall loop to a for loop, it'll print them in serial order.
The reason they come out unsorted is that the forall loop says "do all iterations in parallel"
Though if you look at it closely, you'll see that for the 4 threads we configured it to run on, it actually breaks the range into four serial chunks which are then merged in a nondeterministic order.
Of course, you could also compute the parallel, unsorted results and store them into an array where the array indexing would "re-sort" the results by iteration.
@Brad Languages are installed when the servers are rebuilt (TIO recently moved to another VPS provider) or when the language is updated (usually by request of the author).
Or, you could literally create a distinct task per iteration by changing the forall into a coforall ("concurrent forall") in which case you wouldn't see any serial chunking at all: tio.run/##S85ILEjN@f8/OT8tvygxJ0chUyEzT8FQT8/…
@Dennis: OK, thanks. So what we could do is this: (1) build both the comm=none (single-node) and comm=gasnet (multi-node) builds; (2) set some environment variables that would get us ready for either mode to run; (3) Then a user could opt into one or the other via a compiler flag when they compile.
Let me know if this would be of interest and I'll prototype and pass along additional notes (probably on GitHub).
@Brad If you really wanted to, GitHub provides instructions for setting up your own instance of TIO in a docker container, so you could test things yourself.
@Phoenix: Thanks for that note. I'm not enough of a Docker user for that to sound way attractive, and also don't think we'll have much trouble getting it going. Mostly I've just been distracted by "work" today. :)
@Dennis: I just posted proposed mods that I believe should enable multi-locale gasnet but just as I was verifying something locally I ran into a small surprise, so if you haven't started into them already, I'd hold off for now until I've had a chance to determine if this is a personal error or a real problem.
@FryAmTheEggman Yes, being able to switch between text and hex would be useful for a number of fields (code, input, output, maybe args). That is on my to-do list, but so are 100 other things.
So many ideas, so little time...
Next on the list are Hello World examples (loadable from the frontend) and WebSockets.
@Dennis: Something's definitely amiss (github.com/chapel-lang/chapel/issues/6749). I suspect it won't be resolved before tomorrow, so let's postpone the gasnet attempt for now and I'll ping you once we're on firmer ground.
talk.tryitonline.net
talk.tryitonline.net