Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[PeridexisErrant]

I'd also note that there are decent API docs for Lua, and none at all for Ruby.

[Dirst]

I'd also note that there are decent API docs for Lua, and none at all for Ruby.

Do I hear PE volunteering to take on a side project?

Just kidding!

[grendelfreak]

I'm looking for a script/plugin (I don't know the difference) that allows Dwarves to get pregnant. Catsplosion does work but it is a bit too indiscriminate for my liking, being that allows babies to have their own babies - I would prefer it to be restricted to married Dwarves or at least adult.

[PeridexisErrant]

I'd also note that there are decent API docs for Lua, and none at all for Ruby.

Do I hear PE volunteering to take on a side project?

What gave you that idea?

But seriously, no.  I don't know Ruby at all, and honestly I think Ruby support should be dropped in favor of improving Lua which is already much better.  Python was dropped years ago, and it's my favorite language!

[jecowa]

Did DFHack used to have plugins written in Python?

[lethosor]

Scripts, yes. Back when it was out-of-process and really slow (using any language). Python support was lost with the transition to DFHack being in-process. It's not impossible to embed, as far as I know - I managed to get some simple I/O working with an embedded Python interpreter - but it's a lot of work to get to anything close to the Lua/Ruby APIs.

[Max™]

I meant ruby is friendlier than C++, not lua, lua is cuddly.

[Warmist]

I meant ruby is friendlier than C++, not lua, lua is cuddly.

Well at least C++ is !!FUN!!

[milo christiansen]

As an interesting side note, I wrote a Lua compiler a while ago that used syntax much closer to C or Go. It used curly brackets for blocks (curly brackets for tables still worked, the compiler can tell the difference), "&&" instead of "and", "!=" instead of "~=", it even had a "continue" keyword. All this and it still produced bytecode that would run on the standard Lua VM. Code quality generally exactly matched that produced by the standard Lua compiler, but there were a few cases where it was slightly worse due to me being lazy...

Unfortunately it was written in Go, so it would not be possible to use it with standard Lua without a total rewrite or using it as a stand-alone tool (not to mention the fact that the "load" function was something of an issue, as it still used standard Lua syntax).

The idea of the new syntax was to make it easier to work with for a programmer used to C/C++, C#, Java, Go, etc. It worked great, but I never bothered to write a C version and publish it...

[lethosor]

I've heard of people adding operators to the lua interpreter before, so I imagine it wouldn't be too difficult to add those. Not sure about braces or "continue", though.

[milo christiansen]

Continue was trivial. All you needed to do was keep track of the end of the loop (which you need to do for "break" anyway). "continue" then becomes a jump to just before the end of loop instructions instead of "break"'s jump to just after. This has minor issues with variable scoping in one certain kind of loop, but there are solutions to that that I could have implemented if I had wanted something other than a toy. (my continue was basically a "goto" targeted at the end of the loop)

Braces were also easy, just replace "end" with "}" and consolidate all the block begin keywords ("then", "do", ect) to one, "{".

Mind this was an all new compiler, trying to modify the default Lua compiler would probably also work, but I am not terribly familiar with its internals.

Frankly it took me ~10 minutes to get braces and new operators working, continue was already implemented (but left unused) at the same time I wrote the code for break. C style comments were a little harder, as was a different syntax for multiline strings. I never bothered with ++ and --, but they would have been fairly easy.

[lethosor]

Oh, something I just realized is that we use the system Lua in Travis (mainly for syntax checks - yes, some scripts have actually failed those). We'd have to make a standalone interpreter as well if we wanted to make syntax changes. That's definitely possible, though - I tried doing that once, and the only issue I had was linking against and loading libdfhack successfully.

[mifki]

As an interesting side note, I wrote a Lua compiler a while ago that used syntax much closer to C or Go. It used curly brackets for blocks (curly brackets for tables still worked, the compiler can tell the difference), "&&" instead of "and", "!=" instead of "~=", it even had a "continue" keyword. All this and it still produced bytecode that would run on the standard Lua VM. Code quality generally exactly matched that produced by the standard Lua compiler, but there were a few cases where it was slightly worse due to me being lazy...

Unfortunately it was written in Go, so it would not be possible to use it with standard Lua without a total rewrite or using it as a stand-alone tool (not to mention the fact that the "load" function was something of an issue, as it still used standard Lua syntax).

The idea of the new syntax was to make it easier to work with for a programmer used to C/C++, C#, Java, Go, etc. It worked great, but I never bothered to write a C version and publish it...

What makes people write compiler for one non-standard (i.e. runtime not available by default) language in another one...
Other than that, it's very interesting, and I thought it was possible to make standalone binaries with Go, at least I've seen some tools distributed that way.

As for me, the main problem of Lua is still 1-based numbering which, when porting more or less complex algorithms, makes it easier to rewrite them from scratch to avoid mistakes than to simply change syntax as between other languages.

[mifki]

Continue was trivial. All you needed to do was keep track of the end of the loop (which you need to do for "break" anyway). "continue" then becomes a jump to just before the end of loop instructions instead of "break"'s jump to just after. This has minor issues with variable scoping in one certain kind of loop, but there are solutions to that that I could have implemented if I had wanted something other than a toy. (my continue was basically a "goto" targeted at the end of the loop)

What about this? http://stackoverflow.com/a/3526946/991806

[milo christiansen]

Oh, I have a standalone compiler, but do you really want to have to compile your scripts before you can use them? Anyway, the compiler was to support the Go Lua VM I wrote for Rubble, so it made sense to write it in Go at the time

As for me, the main problem of Lua is still 1-based numbering which, for more or less complex algorithms, makes it easier to rewrite them from scratch to avoid mistakes than to simply change syntax as between other languages.

1 based indexing is an obvious example of massive brain damage... Hmmm... Maybe I should brush up my C skills some and write a language that takes all the best parts of Lua, but use C-like syntax, 0 based indexing, etc. The problem is, I already have too many projects.

What about this? http://stackoverflow.com/a/3526946/991806

Ironically I read that a few minutes before posting Look at the accepted workaround, goto a label named "continue", which is literally exactly what my compiler does. There are still problems with out of scope variables in poorly written repeat-until loops, but a simple compile-time check (the same one goto makes if I remember correctly) makes that an error.