Print

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

[Pidgeot]

Try 0.10b, possibly you've encountered this bug.

I'm getting the same result. However, I've seen other things that suggest perhaps there ought to be a 'mod' listed as df_40_24 that contains the original raws? I'm not seeing that--do I have to make it and put it in the mods folder?
I'm using PeridexisErrant's starter pack r12, if that changes anything. I've stuck version 0.10b of PyLNP in there, too, per your instructions.

There should be a df_40_24 in LNP\Baselines - but if you downloaded the pack, I'm pretty sure PeridexisErrant's already packaged it.

He's the guy who wrote much of the current mod system, though, so he would have a better chance of guessing what the problem might be - but consider launching PyLNP with a command-line argument -d, and then keep an eye on stderr.txt after you've tried this operation; it might contain extra information.

Quick notes:  GLP3 and ISC licenses are usually incompatible, but since you've clearly given permission to include it in PyLNP that's a nonissue.

I looked at your top-level files and didn't see a license.txt there. I'll check out the ISC license and see how it strikes me.

It's named COPYING.txt, a common name for license files.

Question - the __init__.py s were added by PyDev when I created the packages, are those actually necessary to have packages? They don't seem to do anything...

Yes, they are necessary.

[Xolroc]

consider launching PyLNP with a command-line argument -d, and then keep an eye on stderr.txt after you've tried this operation; it might contain extra information.

Nothing showed up in stdout or stderr, so I'm not sure what happened. It seems that PyLNP thinks it's doing everything right, which makes me think I'm doing something completely wrong.

[Bien]

I'd hate to necro but how do I get this to work with, say, the Fortbent mod? Switching tilesets seems to delete the troll mod's raws, forcing me to reinstall every time I switch.

[Pidgeot]

PSA: I have been offered a job in another country, and this will cause some interruptions to my participation here.

Starting July 22, I will not have access to my main development PC for a couple of months. This is going to limit my ability to participate in development, and it is highly likely that I will be unable to post builds.

I do not know exactly when I will regain access, as this depends on how quickly I can find and move into an apartment of my own (I am initially staying in shared company housing, until I can find one). My current best estimate for that is 2-3 months (October/November), but it all depends on what the market has to offer.

I will still try to keep up with proposed changes and bug reports, but especially in the first couple of weeks, that may be quite difficult.

It is also possible that I will be kept quite busy with this in the interim period - I *have* been busy with this for nearly a month now - but things seem to be falling into place now, so these last few weeks will hopefully be a bit calmer on my end.

Pack maintainers: If important changes are made during this period, and you wish to include them in your pack, you will most likely need to build your own executables.

[PeridexisErrant]

PSA: I have been offered a job in another country, and this will cause some interruptions to my participation here.

Congratulations, thanks for letting us know, and good luck!

[TV4Fun]

Getting the following error when I attempt to launch Dwarf Fortress:
Traceback (most recent call last):
  File "/usr/bin/gnome-terminal", line 3, in <module>
    import string
  File "/usr/lib/python3.4/string.py", line 49, in <module>
    from collections import ChainMap
  File "/usr/lib/python3.4/collections/__init__.py", line 11, in <module>
    from operator import itemgetter as _itemgetter, eq as _eq
ImportError: dynamic module does not define init function (PyInit_operator)
Error in sys.excepthook:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/apport_python_hook.py", line 62, in apport_excepthook
    import re, traceback
  File "/usr/lib/python3.4/traceback.py", line 3, in <module>
    import linecache
  File "/usr/lib/python3.4/linecache.py", line 10, in <module>
    import tokenize
  File "/usr/lib/python3.4/tokenize.py", line 28, in <module>
    import collections
  File "/usr/lib/python3.4/collections/__init__.py", line 11, in <module>
    from operator import itemgetter as _itemgetter, eq as _eq
ImportError: dynamic module does not define init function (PyInit_operator)

Original exception was:
Traceback (most recent call last):
  File "/usr/bin/gnome-terminal", line 3, in <module>
    import string
  File "/usr/lib/python3.4/string.py", line 49, in <module>
    from collections import ChainMap
  File "/usr/lib/python3.4/collections/__init__.py", line 11, in <module>
    from operator import itemgetter as _itemgetter, eq as _eq
ImportError: dynamic module does not define init function (PyInit_operator)
Traceback (most recent call last):
  File "/usr/bin/gnome-terminal", line 3, in <module>
    import string
  File "/usr/lib/python3.4/string.py", line 49, in <module>
    from collections import ChainMap
  File "/usr/lib/python3.4/collections/__init__.py", line 11, in <module>
    from operator import itemgetter as _itemgetter, eq as _eq
ImportError: dynamic module does not define init function (PyInit_operator)
Error in sys.excepthook:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/apport_python_hook.py", line 62, in apport_excepthook
    import re, traceback
  File "/usr/lib/python3.4/traceback.py", line 3, in <module>
    import linecache
  File "/usr/lib/python3.4/linecache.py", line 10, in <module>
    import tokenize
  File "/usr/lib/python3.4/tokenize.py", line 28, in <module>
    import collections
  File "/usr/lib/python3.4/collections/__init__.py", line 11, in <module>
    from operator import itemgetter as _itemgetter, eq as _eq
ImportError: dynamic module does not define init function (PyInit_operator)

Original exception was:
Traceback (most recent call last):
  File "/usr/bin/gnome-terminal", line 3, in <module>
    import string
  File "/usr/lib/python3.4/string.py", line 49, in <module>
    from collections import ChainMap
  File "/usr/lib/python3.4/collections/__init__.py", line 11, in <module>
    from operator import itemgetter as _itemgetter, eq as _eq
ImportError: dynamic module does not define init function (PyInit_operator)


This was on Ubuntu-Vivid after setting the terminal command to "gnome-terminal -x" from File->Configure terminal. A quick Google search on this issue suggests it's a Cython bug. See http://www.dietabaiamonte.info/518243.html for instance.

[PeridexisErrant]

I'd suggest running it under Python 2.7; I've tried to keep Py3 compatibility up but most other development and testing is Py2.

[lethosor]

What version of Python are you using? I seem to recall a bug similar to that which was fixed in a later 3.4 release.

[TV4Fun]

I'd suggest running it under Python 2.7; I've tried to keep Py3 compatibility up but most other development and testing is Py2.

My system's default Python is 2.7.9. I'm not sure why it's using Py3 unless it was the version the Cython binary I got from Pidgeot's site is compiled against.
Edit: Tried running direct from the source file, and it worked fine from there.

[Pidgeot]

The binaries should all use 2.7, so I've no idea why you'd be seeing anything about 3.4 then...

[lethosor]

It looks to me like the 2.7 interpreter is trying to load 3.4 libraries from the system and failing when it gets to a compiled library (which is likely not binary-compatible). I'm not sure how to check it, but are you sure that all of the necessary libraries (collections, operator, etc.) are included in the Linux builds?

Edit: Actually, it looks like system programs that use Python 3.4 are failing to import that module for some reason.

[lethosor]

This could be tricky, but I'd like to suggest moving the PyLNP source outside of the executable (i.e. making the executable only consist of the Python interpreter, libraries, and whatever else is necessary to run the PyLNP source). Although it's not as easy as importing a module directly, Python allows loading source files from a specific path, so the executable could consist of a simple launcher that locates and loads the "main" PyLNP source file, from where other imports should work. Some advantages:

* The executable wouldn't change between versions (this would help avoid antivirus issues)
* Packs can distribute new versions of PyLNP without having to rebuild the executable again (or relying on it to be rebuilt by someone else if they don't have a build environment on specific platforms)

Starting July 22, I will not have access to my main development PC for a couple of months. This is going to limit my ability to participate in development, and it is highly likely that I will be unable to post builds.
<snip>
Pack maintainers: If important changes are made during this period, and you wish to include them in your pack, you will most likely need to build your own executables.

Also, if we can move auxiliary files out of the executable, that would address issues like this, where the xdg-terminal script embedded in PyLNP is non-portable and I have no easy way of fixing it, even though a fixed script has been present in the Linux LNP repo ever since that issue was reported.

I'm unfamiliar with PyInstaller, but all this would involve would be ignoring all source files except the launcher script (which should probably import all modules that the pack needs, so PyLNP bundles them), then including those source files in individual packs in a designated (sub)folder. Adding compiled Python libraries might require a new build of the executable (but that would be much less frequent than rebuilding it every release), but source-only libraries (and maybe binary libraries) could also be distributed externally if the launcher modifies sys.path appropriately. (The launcher could easily read from a config file to figure out these paths.)

[Pidgeot]

In principle, it shouldn't actually be *too* hard (it's pretty much how you describe), but it's not something I can do until I regain access to my PC.

I'm not sure what you're talking about regarding xdg-terminal,  because that one has always been external. If it isn't in the builds I've uploaded, that would mean I accidentally messed up the build script when switching VMs - it's not integrated in the PyLNP executable, so it needs to be present... It's also one of the things I *can* update if necessary.

[lethosor]

Well updating the xdg-terminal script in the pack apparently doesn't fix the issue, and the error message shows a path in /tmp (which I believe someone determined is where PyLNP is extracted to) instead of in the LNP folder.

Edit: I was able to extract xdg-terminal from the PyLNP executable with pyi-archive_viewer, so it's definitely in the executable.

[Pidgeot]

Edit: I was able to extract xdg-terminal from the PyLNP executable with pyi-archive_viewer, so it's definitely in the executable.

...so I see. I clearly got some things messed up at some point, because that's not what I'd intended originally.

In that case, I can't really fix it myself until I get my PC back, but if someone wants to make a pull request, I'd be happy to take a look.