Print

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

[salithus]

It really comes down to how you want people who are compiling themselves to do it. When I did it with .40.12, I just followed the step by step instructions because it was my first time. With .40.13, I did the master branch thinking it'd prove more of a point about how close the DF code was across the 3 releases and I didn't want to unknowingly include active development that might address an issue I wasn't aware of. Whichever I should be compiling against, that's the one I recommend not have an official version string as the default. (Might even be worth taking those lines out of source control entirely somehow [addmittedly no idea how CMake works], so that it always has to be specified by whoever is doing the compiling to make sure it's done correctly.)

uhh through IRC? kinda find the idea that if anyone willingly set on building dfhack and compiling a (dev/branch/copy/early access) build should hang out with the devs and listen to them discuss builds and plugins.
like you cross the step from being a user of dfhack to being a developer and drank the darkspawn blood and finally become a Git Warden, now shall wait out your continuous life in Freenode dusting the giant ruins of DF to unearth more stuff for the wizards of the camp to craft wonderful spells or trinkets of either entertainment or ease of use. This quest is a long and repeating one that has it's ups and downs, but's thats the life of a git warden. jokes aside that sounds like alot of effort to do in the middle of a dev cycle that updates around in weeks and that whole dfhack shouldn't cause people to wait out for the new update of DFH to play the new update of DF.

then again this is a opinion from a guy who writes scripts(lua) all day and too lazy or/and incompetent to write a solution that doesn't end with rewriting everything. Take with a grain of salt.

throw in some Zolgar and count me in.

[mifki]

despite being the same original source (master branch of DFHack), previous DLLs would not work (aside from the version string issue), due to those changes?

Most of them will because they don't use changed structures.

[salithus]

despite being the same original source (master branch of DFHack), previous DLLs would not work (aside from the version string issue), due to those changes?

Most of them will because they don't use changed structures.

Sanity check - if I understand what you said:

Let's say there are 30 structures total and that 2 of them changed. Most of the DLLs could work, because those 2 structures aren't ones "typically" used?

So phase 1 would be: if 0 of the structures changed, we're ok to use all the same plugins from before. Versioning would need to be based off identifying a specific changeset used from the symbols project.

Phase 2 would be figuring out a registration system, or some other method to see what specific structures are used, and identify the specific changeset AND structure used, which would require stricter handling on the plugin side, but looser coupling on the DFHack side.

Does that make sense?

[Rose]

I have an idea:

Anybody that does an unofficial DFHack build that intends to release it should change the version number to reflect that.

So instead of being DFHack 40.12.r1, which is only for official builds, or 40.12.r0, which is ambiguous, it should be something like 40.12.whiny-and-impatient-noobs-version, to avoid confusion with the official releases.

[LeoCean]

I have an idea:

Anybody that does an unofficial DFHack build that intends to release it should change the version number to reflect that.

So instead of being DFHack 40.12.r1, which is only for official builds, or 40.12.r0, which is ambiguous, it should be something like 40.12.whiny-and-impatient-noobs-version, to avoid confusion with the official releases.

Then they couldn't use twbt so they'd throw a r1 on it.

[salithus]

I have an idea:

Anybody that does an unofficial DFHack build that intends to release it should change the version number to reflect that.

So instead of being DFHack 40.12.r1, which is only for official builds, or 40.12.r0, which is ambiguous, it should be something like 40.12.whiny-and-impatient-noobs-version, to avoid confusion with the official releases.

That doesn't really solve the problem presented though does it? The idea is to make the default that would be grabbed by anyone not paying close enough attention be something that's easily distinguishable from a supported build, given the advice when waiting for official releases is and has been:

you'll have to wait or compile it on your own

If that's going to be the stance, you've either got to accept the casualties from defaulting to a supported build number (admittedly a bad idea) or safeguard yourself from it.

What about CMake's capabilities - can you have it prompt the user each time?

[Nopenope]

Forgive me if it's obvious, but it seems the problem at hand is the necessity to recompile every plugin every time the version number changes. However there doesn't seem to be this problem with scripts; is there any dfhack magic involved (save for that of laziness which I understand perfectly, mind you) that would prevent people from rewriting said plugins into lua/ruby scripts?

Toady's gone a bit farther than that; he provides the guarantee of a complete absence of guarantee. He's said before that he doesn't want to have to keep 3rd party programs in mind when he writes Dwarf Fortress; it's pretty much the same problem as a UI API.

This is interesting; the way he releases a new version in a matter of hours after each dfhack release and focuses on dfhack-fixable bugs first makes me wonder if he doesn't want people to get used too much to dfhack magic.

I have an idea:

Anybody that does an unofficial DFHack build that intends to release it should change the version number to reflect that.

So instead of being DFHack 40.12.r1, which is only for official builds, or 40.12.r0, which is ambiguous, it should be something like 40.12.whiny-and-impatient-noobs-version, to avoid confusion with the official releases.

That's unfair, there are many legitimate reasons one would wish to compile from source, if one wants to add a port to Gentoo or a bleeding-edge package to the AUR. Maybe the version should be .40.12r1u2 (second unofficial build from the first dfhack release from the .40.12 version), .40.13r0u1 (first unofficial build from the .40.13 version) or even .34.11r5e1u1 for experimental builds expwnent has been known to release.

[Putnam]

Forgive me if it's obvious, but it seems the problem at hand is the necessity to recompile every plugin every time the version number changes. However there doesn't seem to be this problem with scripts; is there any dfhack magic involved (save for that of laziness which I understand perfectly, mind you) that would prevent people from rewriting said plugins into lua/ruby scripts?

Can't interpose vmethods in Lua; you need C++ to access events related to those.

[salithus]

Forgive me if it's obvious, but it seems the problem at hand is the necessity to recompile every plugin every time the version number changes. However there doesn't seem to be this problem with scripts; is there any dfhack magic involved (save for that of laziness which I understand perfectly, mind you) that would prevent people from rewriting said plugins into lua/ruby scripts?

Can't interpose vmethods in Lua; you need C++ to access events related to those.

Plus as I understand it, there's a noticeable performance hit from running it as a Lua script instead of a compiled plugin, because it's compiled each time it's run + the abstraction to the memory addresses.

[Nopenope]

Can't interpose vmethods in Lua; you need C++ to access events related to those.

From what I understand some events (the onSomething thingies) have been exported to lua, making it possible to use them in scripts, isn't that right?

Plus as I understand it, there's a noticeable performance hit from running it as a Lua script instead of a compiled plugin, because it's compiled each time it's run + the abstraction to the memory addresses.

I don't know if it's "noticeable", and I don't know whether performance is paramount when dealing with a script that will only be punctually used (such as a gui or various hack magic). There's only that much stuff that runs continuously along the game (like emigration, rendermax or twbt).

[Putnam]

Yes, it's possible. That's what I meant by needing C++ to access them. I'm fairly sure that that needs to be recompiled on later versions.

[salithus]

Can't interpose vmethods in Lua; you need C++ to access events related to those.

From what I understand some events (the onSomething thingies) have been exported to lua, making it possible to use them in scripts, isn't that right?

Plus as I understand it, there's a noticeable performance hit from running it as a Lua script instead of a compiled plugin, because it's compiled each time it's run + the abstraction to the memory addresses.

I don't know if it's "noticeable", and I don't know whether performance is paramount when dealing with a script that will only be punctually used (such as a gui or various hack magic). There's only that much stuff that runs continuously along the game (like emigration, rendermax or twbt).

I don't have any first-hand knowledge here, just relaying what I took away from Quietust's posts.

[vjek]

Regarding 0.40.12-r1 'forum-dwarves' script included with the release version, in vanilla df 0.40.12:

Spoiler (click to show/hide)

[DFHack]# forum-dwarves
<viewscreen_textviewerst: 0x1afaf588>
child                    = nil
parent                   = <viewscreen_itemst: 0x154c8378>
breakdown_level          = 0
option_key_pressed       = 0
title                    =   (cave spider silk trousers)
title_colors             =
src_text                 = <vector<string*>: 0x1afaf5d0>
outvar_type              =
outvar_name              =
meeting_context          = <meeting_context: 0x1afaf618>
help_filename            = text_viewer
page_filename            =
formatted_text           = <vector<viewscreen_textviewerst.T_formatted_text*>: 0x1afaf660>
hyperlinks               = <vector<char*>: 0x1afaf670>
logged_error             = 0
scroll_pos               = 0
cursor_line              = 0
pause_depth              = 0
<viewscreen_textviewerst.T_formatted_text: 0x1b762ec8>
text                     = <char: 0x116ccd28>
format                   = <char: 0x116ccdb0>
flags                    = <viewscreen_textviewerst.T_formatted_text.T_flags: 0x1b762ed0>
pause_depth              = 0
return_val               = -1
indent                   = 0
<char: 0x116ccd28>
value                    = 84
...Documents\df\df_40_12_win\hack\scripts/forum-dwarves.lua:73: bad argument #1 to 'find' (string ex
pected, got userdata)
stack traceback:
        [C]: in function 'find'
        ...Documents\df\df_40_12_win\hack\scripts/forum-dwarves.lua:73: in function 'format_for_foru
m'
        ...Documents\df\df_40_12_win\hack\scripts/forum-dwarves.lua:116: in main chunk
        (...tail calls...)

That's just from trying to use it to output the details of any object (in this case, cave spider silk trousers).
I don't know how to fix the problem, or I would.   

[Putnam]

It looks like the "text" object there should be interpreted by Lua as a Lua string instead of the weird userdata C char[] or whatever it is now.

[Malorn]

Seems like the stockflow is bugged.  Had a hard lockup when my recordkeeper went to update his records.  Crash does not occur if I insure there are no stockpiles with stockflow settings.  Nothing is printed to stdout or stderr.