@MDXF Triangular appears to be broken.

triangular.c:134:75: error: expected ‘]’ before ‘)’ token
       case 'l': size > 1 && (stack[size-2] = (stack[size-2] > stack[size-1)); size > 1 && (size--); break;

@Dennis Oh, duh, forgot to push after I fixed that.

Fixed.

@MDXF @Phlarx @Phoenix Done.

Waffles

Also TY

Never trust tab completion.

@Brad I got home a little bit later than anticipated and I'm rather tired. I'll review your proposed changes tomorrow.

Thanks

@Dennis: No problem. I'll be on vacation next week, so if it doesn't work out for tomorrow, let me know and I'll have someone else on the team check in here while I'm away.

Will do.

25 more languages needed until 300! I wonder what the 300th will be...

@Dennis can you pull Add++ please?

@Dennis Thanks

@Dennis Could you pull Husk when you get the chance, please?

@cairdcoinheringaahing Gaot++

@Phoenix ┻━┻ ︵ヽ(ಠ_ಠ)ﾉ︵ ┻━┻

@cairdcoinheringaahing @Zgarb Done.

Great, thanks!

@Dennis Henceforth, the less-than operator shall look like >, and the greater-than operator shall look like <. ಠ_ಠ can you pull Triangular please

@MDXF Done.

@Dennis: Give a shout if you have the time and inclination to try and get the multi-locale distribution of Chapel built and available today. I'll be online until 4:30-5:00 PT.

@Brad Building now. If I understood your comments on the tryitonline repo correctly, all I should add to the wrapper are QT_HWPAR and the three GASNET_ variables, yes?

@Dennis: For the wrappers/chapel script, yes.

OK. First make finished, now trying the second.

@Dennis Never mind. It's not a bug with TIO. I found another interpreter that does the same thing.

@Brad All done. tio.run/##S0oszvj/P6dYQTdIQT@/oEQ/…

I didn't perform the tests you suggest here yet because I don't know what output I should be expecting.

@Dennis: Got interrupted by a call there. Thanks! I'll kick the tires a bit and see what I find.

@Dennis: Hmm, not so good results on my first attempt. The linker complains: 'ld terminated with signal 25 [File size limit exceeded].' I don't think I've seen this before -- is the system set up to limit the size of binary files in some way?

Part of the sandboxing limits file size to 4 MiB to avoid filling up the disk. It's a rather conservative limit; I can relax it a bit.

@Brad Changed the limit to 16 MiB. Does that help?

Giving it a try

Got farther...

I'm now getting mv errors that I think you may have seen once the other day, and which I've seen from time to time. They seem much more consistent this time around, though: mv: failed to set default file creation context to ‘unconfined_u:object_r:sandbox_file_t:s0’: Permission denied

I'm digging a bit to see where they're coming from (best guess: we do do moves from TMPDIR to the cwd IIRC).

That's nothing to worry about. mv tries to set the default context, but everything in the sandbox has a MCS range specific to that sandbox, which differs from the default.

@Dennis: It appears that that guess was correct. Our compiler's Makefiles do two mv commands which seem to correspond to the two mv errors that I'm getting:

mv /tmp/chpl-runner-24532.deleteme/.bin.tio.tmp .bin.tio_real

mv /tmp/chpl-runner-24532.deleteme/.bin.tio.tmp .bin.tio

In retrospect, maybe those aren't the fatal problem, though since it seems we can still run bin.tio.

Does this cause any problems? The errors from mv can be ignored, but I'm not sure if your scripts treat them as fatal.

Its job is to create one or more copies of .bin.tio_real representing the different compute nodes (oversubscribed on the single compute node here).

It seems to be generating internal error: execvp() failed: No such file or directory

I don't know whether that failure is due to the mv errors or not...

Could you link me to what you're trying to execute?

Oh wait, I think I see the problem. I think the mv errors were a false alarm.

Unfortunately, it looks like another 'make install' issue (sigh). This is a new feature for us that hasn't been in an official release yet, so this is turning out to be the acid test that's identifying bugs. Sorry about that.

On the plus side, all the mods to your scripts look correct and to be working properly. We just need to fix a path in our make install step (it refers back to the build location and in our testing, we didn't clean up the build so the path was still valid).

@Dennis: Bottom line: Ball's back in our court, but I think you could commit these script changes if you haven't for once the bug is fixed.

@Brad OK, I'll commit them. Let me know when I should rebuild.

Will do. Not sure if I'll be able to fix this before leaving for vacation this coming week. If not, I'll recruit someone else to take it over or else pause this effort until I'm back.

@Dennis could you pull cQuents when you have a chance? Thanks!

@StepHen Done.

@Dennis Thank you! :)

I didn't sync last night 0.o I'll ask again later tonight, sorry

No worries.

@Dennis Could you please pull MATL again? Sorry that it's only been two days since the last time...

@LuisMendo Pulled and currently syncing. No worries, I'll pull as often as needed.

Thanks :-)

Hi @Dennis: Just pushed a fix if you're still around and game to try another rebuild.

I think this should do it (he said, likely jinxing himself)

Sure. I'll start the build now. Roughly took 12 minutes the last time.

@Brad Building finished and I'm currently syncing to the arena servers. make installsays Detecting CHPL_HOME as /opt/chapel/build among other things, but that directory gets removed to save space. Is that a problem?

@Brad All done. Let me know how it went.

@Dennis: That does sound problematic, but I don't think anything w.r.t. that should've changed there since last time around. Let me give it a whirl and see.

It looks like that was not a problem.

I'll check the message afterwards.

We got further, but no joy. And in retrospect, maybe I was being naive.

I was thinking that, when run in oversubscribed mode, GASNet would not require things like sockets, which I think you said were intentionally disabled. But I think it was wrong (at least in our current build configuration).

Specifically, I'm getting a: socket() failed while creating a listener socket (13:Permission denied)

@Dennis: If you could confirm that this is expected (sockets should not be available to processes within a compute node), I'll research whether we have other options available to us, like communicating through shared memory.

(But probably not until after vacation -- or else I'll have someone else on the team look into it).

Yes, the sandbox disables all network access, including sockets. This is a problem for a number of languages, but I haven't found a (safe) way around it yet.

@Dennis: s/enables/disables?

Yes, of course.

@Dennis: It does appear that there is a shared memory option and that I was just forgetting that it isn't used by default by GASNet or at least in our use of it. We'll look into what it would take to enable this for the TIO build and get back to you.

Thanks for all the help this week and sorry for the false start or two along the way.