@Pavel Could you give me the exact sequence of commands you use to build Broccoli on Fedora? cd's and everything.

With altered HOME, if possible.

@Dennis git clone ... ; cd broccoli/Broccoli ; export HOME=. ; dotnet publish -r linux-x64 --self-contained;

And to run?

@Dennis bin/Debug/netcoreapp2.0/linux-x64/publish/Broccoli

I was executing linux-x64/Broccoli, not linux-x64/publish/Broccoli. ._.

Well then

@Dennis Did that work?

Yes.

\o/

Currently doing a full test run to see if any of this broke anything else.

Ok

@Pavel @ASCII-only @NickClifford @DJMcMayhem tio.run/#broccoli

YASS

:D

I didn't need the 2.1.4 SDK after all, I think.

Well, why not have more updated software

Because it's 275 MiB on top of the stuff it doesn't replace. Migrating from 2.0.0 to 2.1.4 would be different.

But I have no idea if that would break the build process of any of the languages, so I'm not prepared to do that right now.

It shouldn't, but I can understand your warriness

There are lots of things that shouldn't happen. Like world-writable files.

Or Dodos needing 20 seconds and a raised recursion depth to quine...

@Dennis Yay!

@Dennis or Clean's marking collector being broken on Linux.

Or the code generator breaking when encountering certain integral constants on an Intel platform.

@Dennis That can be improved to 0.5 seconds by optimizing one of the functions the Dodos compiler generates...

.oO ( That actually went to my inbox. )

@Dennis Could you please pull attache?

@ConorO'Brien Done.

@Dennis Please pull broccoli, and change the wrapper to use -- "$@" instead of "$@".

We have actual unit tests so 99% guaranteed not broken

@Dennis Thanks!

@Pavel Pulled. Why does it need --?

@Dennis Our option parsing library is kinda dumb, or just poorly documented. I'm not sure how to get it to parse arguments without processing them as flags without --.

So it would treat abc as a flag, even though it has no -?

No, it would treat -c as a flag regardless of if it comes after or before the filename.

That's true for most languages and most option libraries.

As far as I can tell there's no way to change that

Which is why I don't enable command-line options for these, to avoid confusion.

Actually, what you could do is just disable options entirely (still with -- "$@") and add cauliflower as a seperate language.

Cauliflower is just Broccoli -c

My philosophy is that it should work locally if it works on TIO. If you need -- on the command line to avoid treating -c as a flag, you should need it on TIO as well.

Alright

But I'll gladly add Cauliflower as a separate language anyway. Separate languages should have separate interpreters on TIO.

Yeah

-c is the only flag we have that changes behaviour by the way. The other two are -h|--help and -r|--repl.

Should I also remove command line options for Broccoli? Doesn't make much sense if they're not distinguished from arguments.

Yep

Even if we implement some that actually modify the way the interpreter works in a way useful on TIO, they'll only apply to cauli anyway.

What's the difference?

Broccoli follows the exact specification of a language we discovered a while back.

It's closed source and only has a windows binary, so we reimplemented it.

Cauliflower is Broccoli but with extensions to make it more practical, i.e. an actual language

tio.run/#cauliflower

thanks

@Pavel well it doesn't exactly follow the reference interpreter

Almsot exact

As close as we could

we could do it closer, just 1. I'm too lazy and 2. some of it would affect Cauliflower too

@Dennis Please pull Broccoli

Cauliflower has Dictionaries now!

@Pavel Done.

@Dennis Can you please pull Triangularity?

@Mr.Xcoder Done.

Thanks!

@Dennis Oops I made a huge mistake. Can you please re-pull it?

@Mr.Xcoder Done.

Thanks again and sorry

No worries.

@Dennis thanks

@Dennis Please pull Broccli again

@Pavel Done.

Thanks