Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  
Pages: 1 ... 73 74 [75] 76 77 ... 242

Author Topic: DFHack 50.11-r6  (Read 795383 times)

PatrikLundell

  • Bay Watcher
    • View Profile
Re: DFHack 0.44.10-r1
« Reply #1110 on: May 24, 2018, 05:27:41 am »

Thanks jecowa.
That's partially covered here: https://dfhack.readthedocs.io/en/stable/docs/Compile.html (I've gotten that from Lethosor).
I'm not interested in cloning "my" project (I wouldn't put any development stuff there unless forced to): I'm interested in contributing to DFHack, so its various (sub)repos is what's of interest. My stuff on github is there only because it's required for pull requesting to work (apart from my scripts, which are there only so they can be downloaded by others: I don't do any work on them there).
You're also skipping the essential steps of making branches and connecting to them, as well as how to connect to your fork on github (since you assume connection to your own project rather than DFHack).
git status lies. It can tell you things are up to date while you can clearly see the local file differs from the one on github. It also doesn't tell you which branch it thinks you're on, and it couldn't care less about whether it's in sync with your github fork branch (it probably doesn't even know about it).
Essential git commands not mentioned:
git remote -v and git remote add <get the path syntax right for your DFHack (sub)repo fork> (and git remote remove <got the path syntax wrong> to undo it without nuking).
git branch <your_update_branch>
git checkout <your_update_branch>

When I run into problems I copy the file I've changed to a safe place, nuke the failed local repo and reclone to wipe git's faulty internal state. I'm getting better at it, so it's probably down to less than once per pull request.

Also, don't use the web interface to update your fork's files, as it changes the <EOL> indication to one Travis rejects.

And now something completely different: Temperature measurements/predictions:
Bearskie's script provided the nudges I needed to move forward. I've got measurements of the temperature every day for a year for a single point in 117 world tiles in a vertical line (out of 257), and it's taken its time (somewhere between 12 and 18 hours, at a guess) before DF crashed, but that data is saved on a file. It seems to make sense when looked at in that the temperature increases over the summer and decreases during the winter (except at the equator, where the temperature seems to be constant). However, looking closer at it it doesn't quite make sense, as temperature changes essentially linearly and then makes a jump back to a temperature it had a few days earlier before changing linearly again, and these discontinuities seem to appear at the same date for multiple (all I've looked at) locations, and those dates don't hold any obvious significance, e.g. 76-78, 120-121, 166-167, 232-238, (the ranges are because of trouble reading the data points from the spreadsheet as I haven't pinpointed it in the measurements themselves).
The temperatures seem to increase more in the summer than they decrease in the winter, as measured from the starting point in spring, but possible the center point should be mid spring, rather than the start of spring.
Obviously, the measurement process may be flawed so the values measures aren't the correct ones.

@Bearskie: You may want this for your script to save on entering the unit id manually:
  local unit = df.unit.find (df.global.ui_advmode.player_id)
Logged

Atomic Chicken

  • Bay Watcher
    • View Profile
Re: DFHack 0.44.10-r1
« Reply #1111 on: May 24, 2018, 06:11:24 am »

@Bearskie: You may want this for your script to save on entering the unit id manually:
  local unit = df.unit.find (df.global.ui_advmode.player_id)

player_id refers to the adventurer's nemesis id, which isn't necessarily identical to the unit id (although it often is in practice) so it'd probably be more appropriate to use "df.nemesis_record.find(df.global.ui_advmode.player_id).unit". Alternatively, you could use "df.global.world.units.active[0]", which generally corresponds to the player unit in adventure mode.
Logged
As mentioned in the previous turn, the most exciting field of battle this year will be in the Arstotzkan capitol, with plenty of close-quarter fighting and siege warfare.  Arstotzka, accordingly, spent their design phase developing a high-altitude tactical bomber. 

lethosor

  • Bay Watcher
    • View Profile
Re: DFHack 0.44.10-r1
« Reply #1112 on: May 24, 2018, 08:19:59 am »

%XXX% is a placeholder for %program files (86)% or something along those lines.

I believe I did see an error message saying that something or other couldn't be found at the C: drive, and I think it pointed down the program file guff path to where VS would have been placed if it had been on the C: drive.
So your program files folder is on your C: drive but VS isn't in that? BenLubar made this change 10 days ago - does that help?
Quote
I'm using the the command line (git xxx <guess at parameters here>). "git help" provides a dozen commands, most of which I've never used, and most of the ones I need aren't listed. The "documentation" is horrible, resulting in a web page that only provides overall syntax, but not any parameters, nor any description of the commands. Web searches are needed to find commands, and sub repo juggling was found in a comment somewhere half way through a discussion of failed attempts.
As it currently stands, I can stumble by with git and a frequent "remove everything and download from scratch" approach. For instance, I won't create a new pull request in a (sub) repo before the previous one is done as I don't want to try to juggle several instances of it (and the complete DFHack surrounding it that's required for the sub repo stuff to be tested), as pull requests are frequently requested to be changed, so the local copy needs to be prepared for making changes to be pushed up.
You should be using branches instead of several copies of the repo, which can get rather large. And I think you have been using branches, which confuses me more. You should be able to use "git checkout" to switch between branches, and changes you've made and committed on a branch will only be visible when that branch is checked out, so you can do work on multiple branches/PRs in the same clone.

This is "git help" from Git 2.17:
Spoiler (click to show/hide)
I can't think of any I use regularly that aren't listed here. Maybe you're using an old Git version that doesn't list all of these? I would highly recommend upgrading to something newer if you are - core behavior doesn't change, but some output is in a nicer format by default.

"git help COMMAND" or "man git-COMMAND" or "git COMMAND --help" will all give you detailed help about individual commands. https://git-scm.com/docs/ is the same information, and I've pointed people at https://git-scm.com/book/en/v2 before (it's long but thorough).

  • git clone yourproject.git - downloads the project from github the first time (you theoretical only need to do this once)
<snip>
If you have any problems, backup the project to another folder and reclone it from the github.
For the record, my DFHack clone dates back to 2014, when I first started working on DFHack. So yes, you can get by with only cloning it once. (I do have a second clone for some administrative stuff, like syncing branches on GitHub without touching all of the files in my main clone and needing a rebuild, but I haven't had to re-clone that either.)

  • git add filename.file - adds a file to the list of files getting sent. (or git add . to add all the red untracked files)
  • git status - do this once more to make sure it all looks right
  • git commit -am "change description" - this makes a save point or something with a comment of what you just changed.
DO NOT DO THIS! The "-a" flag to git commit will commit EVERYTHING (except untracked files), so if you picked out individual changes to add with "git add", "git commit -a" will throw away all of that and commit everything (and lead to confusion because it doesn't match what "git status" showed).

Thanks jecowa.
That's partially covered here: https://dfhack.readthedocs.io/en/stable/docs/Compile.html (I've gotten that from Lethosor).
I'm not interested in cloning "my" project (I wouldn't put any development stuff there unless forced to): I'm interested in contributing to DFHack, so its various (sub)repos is what's of interest. My stuff on github is there only because it's required for pull requesting to work (apart from my scripts, which are there only so they can be downloaded by others: I don't do any work on them there).
Jecowa was talking about DFHack forks, which is also what you're talking about.
Quote
git status lies. It can tell you things are up to date while you can clearly see the local file differs from the one on github. It also doesn't tell you which branch it thinks you're on, and it couldn't care less about whether it's in sync with your github fork branch (it probably doesn't even know about it).
It doesn't lie, if you use "git fetch" or "git pull" to update your local copy. I use it constantly, and it does help avoid confusion.
"On branch X" is literally the first line of its output in my Git version. Again, if you're using an old version and don't see that, you should upgrade.
Quote
Essential git commands not mentioned:
git remote -v and git remote add <get the path syntax right for your DFHack (sub)repo fork> (and git remote remove <got the path syntax wrong> to undo it without nuking).
git branch <your_update_branch>
git checkout <your_update_branch>
You can change remote URLs with "git remote set-url": https://git-scm.com/docs/git-remote. No need to nuke anything.
Are you saying Jecowa's post is missing that, or DFHack's documentation? I still don't think we need to recreate Git tutorials in the DFHack documentation, but I'm okay with adding things specific to DFHack's process. We kind of assume a basic knowledge of Git, though.
Quote
When I run into problems I copy the file I've changed to a safe place, nuke the failed local repo and reclone to wipe git's faulty internal state. I'm getting better at it, so it's probably down to less than once per pull request.
I wouldn't describe it as faulty myself, but if you need help sorting something out, I'd be willing to work with you if you can provide "git status" output and a description of what you're trying to do.

Quote
Also, don't use the web interface to update your fork's files, as it changes the <EOL> indication to one Travis rejects.
It has never done this for me. It might be due to your editor using DOS-style newlines (\r\n), so change that if you can. Git locally changes newlines to \n by default on Windows, but maybe GitHub's UI does not, so copying a file in like that could be problematic.
By the way, I want to be clear that this is also documented in Contributing - it's not a surprise check that Travis throws in at the last minute or anything.
« Last Edit: May 24, 2018, 08:25:09 am by lethosor »
Logged
DFHack - Dwarf Manipulator (Lua) - DF Wiki talk

There was a typo in the siegers' campfire code. When the fires went out, so did the game.

SlimeOfSteel

  • Bay Watcher
  • Novice Programmer
    • View Profile
Re: DFHack 0.44.10-r1
« Reply #1113 on: May 24, 2018, 09:14:30 am »

Okay, one more thing. The Visual C++ 2015 Redistributable Update 3 is standalone, and doesn't depend on the C: drive, right?

I know I should probably have figured this all out by now, but there were other things in my life that needed my attention first. You can also blame my terrible memory for this as well.

Listen, I know you're probably sick of this whole thing, but I honestly have to thank you for being so patient.
Logged
It works, but I don't know why.

lethosor

  • Bay Watcher
    • View Profile
Re: DFHack 0.44.10-r1
« Reply #1114 on: May 24, 2018, 09:55:17 am »

I wouldn't know; I haven't tried it. It's fairly small, though. Is there a reason you can't install it on multiple computers if necessary?
Logged
DFHack - Dwarf Manipulator (Lua) - DF Wiki talk

There was a typo in the siegers' campfire code. When the fires went out, so did the game.

Clément

  • Bay Watcher
    • View Profile
Re: DFHack 0.44.10-r1
« Reply #1115 on: May 24, 2018, 09:57:07 am »

So your program files folder is on your C: drive but VS isn't in that? BenLubar made this change 10 days ago - does that help?

I have never built DFHack on Windows, so I am not sure it help: when I build Dwarf Therapist, I use %VS140COMNTOOLS%VsDevCmd.bat to setup the environment for cmake. It is not the same directory you are using in the linked patch, but it works with non-standard install paths (my MSVC2015 is not installed on the system disk).
Logged

PatrikLundell

  • Bay Watcher
    • View Profile
Re: DFHack 0.44.10-r1
« Reply #1116 on: May 24, 2018, 09:58:36 am »

@Lethosor:
BenLubar's change *should* result in me not having to change install-debug for every clone. However, %ProgramFiles(x86)% is the variable that points to C: and has to do so. There is one structure on the C: drive where old program installs are and one on D: where new ones, including most of VS (it's installation placed versions older than 14 on C: anyway), are (I had to change the install location when bloatware filled the OS partition, as the PC vendor apparently doesn't care that this happens).

I don't have multiple clones as I nuke them when done, and yes, I'm using branches, but given how much I trust git not to screw up things I don't trust it to switch between branches and not destroy/corrupt data. It's fairly easy to get into a state I can't get out of (I know you can do HEAD surgery and whatnot, but I don't know how to do that).

git remote is one command that isn't listed by the help (and my git installation is less than a year old and made according to DFHack instructions, so it shouldn't be ancient). When I've tried git help <command> it hasn't produced anything useful (like e.g. listing parameters), and I think it didn't seem to recognize the command at all.

I do add and commit files individually (and have to do so to not include install-debug.bat when in the top/main structure).

I certainly don't want to download the old junk in my fork, as I want to work with the latest stuff, and apparently the fork cannot be updated without first downloading the data locally and then push it up (apart from nuking the fork and recreating it, of course). The fork's main branch only acts as an administrative placeholder to create github branches so pull request can be made (and those branch copies have to be updated by pushing the newly cloned/pulled stuff up).

Missing commands: I was referring to jecowa's list. As I said, "git remote remove" can be used to remove failures so so "git remote add" can be tried again, without nuking, and I assume your command has parameters for modifying the path of an existing element, thus allowing the usage of one command instead of two.
The mentioning of which of a bazillion different git structure organizations DFHack uses ought to be required even for those familiar with git (i.e. "git flow" as mention in your earlier post), and the usage of a main repo with multiple sub-repos (docked in the top structure under other names, at least in the case of df-structures->xml) ought to be documented as well, as I assume that isn't immediately apparent.

<EOL>: I've changed my text editor settings to satisfy Travis' demands, but I'm unsure if it had rejected things before that or if the change was made because I read it would demand it (and I haven't checked that the settings have been retained when it has updated itself). When I tried the web UI to cut out the administrative steps in updating a minor change Travis rejected the file, while it was accepted when pushed up (and I didn't touch it in between). I wouldn't exactly be surprised if the web UI behavior differed between browsers and OS's, though (Firefox on Windows, in my case). Also, I haven't changed any settings in VS (and don't know if you can modify line terminations there), but I don't remember what kind of file it was (i.e. script, XML, or code).

@SlimeOfSteel: When I installed VS partial older versions insisted on ending up on the C: drive, with 14.0 correctly landing on D:. However, I suspect it may be due to the %ProgramFiles(x86)% variable pointing at C:\..., so you may want to check that variable. Note that I'm mostly guessing, though. It that guess is correct, you'd probably have to make sure nothing dependent on it is installed on the C: drive, or keep switching it back and forth depending on what you do.
Logged

SlimeOfSteel

  • Bay Watcher
  • Novice Programmer
    • View Profile
Re: DFHack 0.44.10-r1
« Reply #1117 on: May 24, 2018, 10:47:05 am »

I wouldn't know; I haven't tried it. It's fairly small, though. Is there a reason you can't install it on multiple computers if necessary?

I don't have the permissions to install VS on the computers.

@SlimeOfSteel: When I installed VS partial older versions insisted on ending up on the C: drive, with 14.0 correctly landing on D:. However, I suspect it may be due to the %ProgramFiles(x86)% variable pointing at C:\..., so you may want to check that variable. Note that I'm mostly guessing, though. It that guess is correct, you'd probably have to make sure nothing dependent on it is installed on the C: drive, or keep switching it back and forth depending on what you do.

Well, I guess I'll have to give it a shot once I can get to my home computer and maybe stop procrastinating so much.
Logged
It works, but I don't know why.

Clément

  • Bay Watcher
    • View Profile
Re: DFHack 0.44.10-r1
« Reply #1118 on: May 24, 2018, 10:59:54 am »

I have no idea what are the differences between the two scripts but replacing call "%ProgramFiles(x86)%\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" amd64 with call "%VS140COMNTOOLS%VsDevCmd.bat" worked for me.
Logged

lethosor

  • Bay Watcher
    • View Profile
Re: DFHack 0.44.10-r1
« Reply #1119 on: May 24, 2018, 03:31:56 pm »

So your program files folder is on your C: drive but VS isn't in that? BenLubar made this change 10 days ago - does that help?

I have never built DFHack on Windows, so I am not sure it help: when I build Dwarf Therapist, I use %VS140COMNTOOLS%VsDevCmd.bat to setup the environment for cmake. It is not the same directory you are using in the linked patch, but it works with non-standard install paths (my MSVC2015 is not installed on the system disk).
Interestingly enough, the win32 build/install/package scripts all use
Code: [Select]
call "%VS140COMNTOOLS%vsvars32.bat"
I don't remember if there was an issue doing that with the win64 scripts, and I'm not sure why it wasn't done for win32 package scripts. Ben or others might know.

@Lethosor:
BenLubar's change *should* result in me not having to change install-debug for every clone. However, %ProgramFiles(x86)% is the variable that points to C: and has to do so. There is one structure on the C: drive where old program installs are and one on D: where new ones, including most of VS (it's installation placed versions older than 14 on C: anyway), are (I had to change the install location when bloatware filled the OS partition, as the PC vendor apparently doesn't care that this happens).
Ok, yeah, that sounds like something the existing scripts can't support without changes. Maybe there's a way we can make the VS tools path user-configurable (and ignored by Git), but I'm not familiar enough with batch scripts to do that.
Quote
I don't have multiple clones as I nuke them when done, and yes, I'm using branches, but given how much I trust git not to screw up things I don't trust it to switch between branches and not destroy/corrupt data. It's fairly easy to get into a state I can't get out of (I know you can do HEAD surgery and whatnot, but I don't know how to do that).
It's really hard to destroy or corrupt data. Sometimes you'll end up with merge conflicts that are hard to resolve when pulling or merging, but Git will keep you from pulling/merging things that will overwrite your changes, and some form of "git reset" will get you out of a merge if you decide to give up on it.
Quote
git remote is one command that isn't listed by the help (and my git installation is less than a year old and made according to DFHack instructions, so it shouldn't be ancient). When I've tried git help <command> it hasn't produced anything useful (like e.g. listing parameters), and I think it didn't seem to recognize the command at all.
Fair, but "git help remote" gives me a 233-line man page that definitely lists parameters and is basically the same as https://git-scm.com/docs/git-remote. The syntax for commands is in the "Synopsis" section.

Out of curiosity, what does "made according to DFHack instructions" mean? Do we give instructions on building Git or something? Or did you download binaries from some recommended source? Check on your actual version with "git --version" if it's the latter, since some binaries can be extremely out of date.
Quote
I do add and commit files individually (and have to do so to not include install-debug.bat when in the top/main structure).
Yeah, that complaint was directed at Jecowa. That's good.
Quote
I certainly don't want to download the old junk in my fork, as I want to work with the latest stuff, and apparently the fork cannot be updated without first downloading the data locally and then push it up (apart from nuking the fork and recreating it, of course). The fork's main branch only acts as an administrative placeholder to create github branches so pull request can be made (and those branch copies have to be updated by pushing the newly cloned/pulled stuff up).
This is true, but you can fetch from the upstream remote ("git fetch origin" if "origin" is your name for DFHack's copy), then create a new branch based on origin/some-branch (e.g. origin/master or origin/develop) if you use "origin" ("git checkout origin/some-branch", then "git checkout -b my-new-branch"), and that will give you a new branch "my-new-branch" that's based on DFHack's some-branch without having to update your own some-branch.

I guess this is a tip that could be documented.
Quote
Missing commands: I was referring to jecowa's list. As I said, "git remote remove" can be used to remove failures so so "git remote add" can be tried again, without nuking, and I assume your command has parameters for modifying the path of an existing element, thus allowing the usage of one command instead of two.
Yeah, it does. "git remote set-url [--push] <name> <newurl>" from the man page, so e.g. "git remote set-url bob https://github.com/bob/dfhack"
Quote
The mentioning of which of a bazillion different git structure organizations DFHack uses ought to be required even for those familiar with git (i.e. "git flow" as mention in your earlier post), and the usage of a main repo with multiple sub-repos (docked in the top structure under other names, at least in the case of df-structures->xml) ought to be documented as well, as I assume that isn't immediately apparent.
Honestly, "we do all work on the develop branch" has been enough people familiar with Git for most development. The "git flow" page is interesting for theory and all, but in most cases, working off the develop branch is all that matters for contributors.

Quote
<EOL>: I've changed my text editor settings to satisfy Travis' demands, but I'm unsure if it had rejected things before that or if the change was made because I read it would demand it (and I haven't checked that the settings have been retained when it has updated itself). When I tried the web UI to cut out the administrative steps in updating a minor change Travis rejected the file, while it was accepted when pushed up (and I didn't touch it in between). I wouldn't exactly be surprised if the web UI behavior differed between browsers and OS's, though (Firefox on Windows, in my case). Also, I haven't changed any settings in VS (and don't know if you can modify line terminations there), but I don't remember what kind of file it was (i.e. script, XML, or code).
I suspect Firefox on Windows (or maybe anything on Windows) includes the carriage returns when pasting, which causes the issue. Are you sure your editor is saving with UNIX-style newlines?
Logged
DFHack - Dwarf Manipulator (Lua) - DF Wiki talk

There was a typo in the siegers' campfire code. When the fires went out, so did the game.

PatrikLundell

  • Bay Watcher
    • View Profile
Re: DFHack 0.44.10-r1
« Reply #1120 on: May 24, 2018, 04:47:10 pm »

According to the instructions: Same as before: https://dfhack.readthedocs.io/en/stable/docs/Compile.html, i.e. via Chocolatey.

"origin" is what DFHack (on github) is called when cloned. So far I've mostly nuked the local clone and recloned it to get the latest, but I've had some success with fetching it, creating a branch locally (same name as in my github repo) from it, check it out, and push that up to my github repo (with the occasional accidental attempt to push it up to origin, which (fortunately) doesn't work). I haven't used any -b switch, though.

Those who do not know git and try to figure out anything about the organization by reading the git documentation will just have to guess at which workflow description sort of matches what's used, and using the insider description that you're just working off develop doesn't help one bit (and it is correct only for the top repo anyway) when you don't know what a "develop" is or what git hierarchy item it might be an instance of.

<EOL>: Given that browser file uploading involves drag&drop of the file, not its contents, I'm fairly sure it's not a cut-and-paste issue. Checking Notepad++ it claims to use "Unix (LF)" still, but as I said, it might have been code, in which case VS is the "editor".
Logged

Roses

  • Bay Watcher
    • View Profile
Re: DFHack 0.44.10-r1
« Reply #1121 on: May 24, 2018, 06:21:43 pm »

As a contribution to the git discussion. Some of my favorite commands are git rebase and git stash. They are great for moving across branches and forks.

I highly suggest those interested in using git to take one of the multitude of online tutorials. Most of them go through step by step processes involving all/almost all of the commands you would ever want/need. It can be a very steep learning curve, but once you becomes more proficient you can easily keep dozens of versions of the same code on your system.
Logged

lethosor

  • Bay Watcher
    • View Profile
Re: DFHack 0.44.10-r1
« Reply #1122 on: May 24, 2018, 08:01:12 pm »

According to the instructions: Same as before: https://dfhack.readthedocs.io/en/stable/docs/Compile.html, i.e. via Chocolatey.

"origin" is what DFHack (on github) is called when cloned. So far I've mostly nuked the local clone and recloned it to get the latest, but I've had some success with fetching it, creating a branch locally (same name as in my github repo) from it, check it out, and push that up to my github repo (with the occasional accidental attempt to push it up to origin, which (fortunately) doesn't work). I haven't used any -b switch, though.
Yeah, "origin" is the default name for the remote for the URL you passed to "git clone". Some people clone their own fork and make a new remote called "upstream" or something that points to DFHack's. Others (like me and you) clone DFHack's and make a new remote for their own fork. Either way works.
Quote
Those who do not know git and try to figure out anything about the organization by reading the git documentation will just have to guess at which workflow description sort of matches what's used, and using the insider description that you're just working off develop doesn't help one bit (and it is correct only for the top repo anyway) when you don't know what a "develop" is or what git hierarchy item it might be an instance of.
It's not an "insider description" - it's mentioned on https://dfhack.readthedocs.io/en/latest/Contributing.html, and it says "develop branch" in both cases.
Looking at recently closed PRs, I only see one made against the wrong branch, although I think there was a second one that I override somehow. Several PRs (correctly made) came from first-time PR authors too.

Now, I don't mean to alienate anyone with a lack of git knowledge. Adding a more detailed page on DFHack's Git/GitHub process has been on my list for a while, although a low priority, but it has moved up thanks to discussions here.

At the same time, I'm not sure how to improve what we currently have. The process involving being on the develop branch is a bit different from some repos, but I think it's documented so that anyone who is somewhat familiar with Git, including how to submit pull requests and use branches, can understand the information provided. The activity I've seen on GitHub agrees with that. If you, or anyone else, has ideas for ways that we can make it better while the Git-documentation process is happening, feel free to suggest them.

Quote
<EOL>: Given that browser file uploading involves drag&drop of the file, not its contents, I'm fairly sure it's not a cut-and-paste issue. Checking Notepad++ it claims to use "Unix (LF)" still, but as I said, it might have been code, in which case VS is the "editor".
Oh, I didn't know you were uploading the file directly (that's a newer feature than the online editor, which I'm more familiar with and does allow editing file contents).
Logged
DFHack - Dwarf Manipulator (Lua) - DF Wiki talk

There was a typo in the siegers' campfire code. When the fires went out, so did the game.

jecowa

  • Bay Watcher
    • View Profile
Re: DFHack 0.44.10-r1
« Reply #1123 on: May 24, 2018, 11:08:01 pm »

GCC 7.3.0 64-bit build works on Mac OS X 10.10 Yosemite as well.

On Mac OS X 10.5.8, the GCC 7.3.0 builds did not run in either 32-bit or 64-bit Dwarf Fortress. The same was true with both of the GCC 4.8.5 builds. The thing the error logs had in common in all 4 versions was:
Code: [Select]
Trace/BPT trap          DYLD_INSERT_LIBRARIES=./hack/libdfhack.dylib ./dwarfort.exe "$@"
error logs for the versions:
  • Spoiler: 64-bit GCC v4.8.5 (click to show/hide)
  • Spoiler: 32-bit GCC v4.8.5 (click to show/hide)
  • Spoiler: 64-bit GCC v7.3.0 (click to show/hide)
  • Spoiler: 32-bit GCC v7.3.0 (click to show/hide)

Test status of different Mac versions:
  • OSX 10.5 Leopard
  • OSX 10.6 Snow Leopard
  • OSX 10.7 Lion
  • OSX 10.8 Mountain Lion
  • OSX 10.9 Mavericks
  • OSX 10.10 Yosemite
  • OSX 10.11 El Capitan
  • OSX 10.12 Sierra
  • OSX 10.13 High Sierra
Logged

PatrikLundell

  • Bay Watcher
    • View Profile
Re: DFHack 0.44.10-r1
« Reply #1124 on: May 26, 2018, 03:56:21 am »

My attempt to describe how DFHack is organized on github, as well as an attempt to describe how to work with it (Warning! don't try to use the workflow description, as it probably is not correct).
Spoiler (click to show/hide)
Logged
Pages: 1 ... 73 74 [75] 76 77 ... 242