Guild of Writers

Chacal wrote:I don't see why not eventually provide support for diffs for text files, providing I can find a good command-line diff tool for Windows that doesn't come with all kinds of dependencies. The tool must be able to generate and apply diff files.
This will make processing python files more complex, since I will now have to unpack, decompyle, modify, recompyle, repack. Also more error-checking.

For doing the diff itself, you can search any Linux source code for the diff command. Here's one diff algorithm, based on GNU diff:

http://www.ioplex.com/~miallen/libmba/dl/src/diff.c

Note that ULM's installer can unpack, decompyle, modify, recompyle, and repack. PM Trylon to get access to the installer source code.

However having to diff all the time would make packaging the Offline KI much harder. Even worse, depending on what the suer already has installed (vanilla Uru, ULM, previous Offline KI versions) you would need different diffs. And last but not least, the diffs would reduce the amount of copyrighted work, but not remove it: Lines which are changed or removed as well as the context lines (to allow fuzzy applying) will still be distributed. The way sdl, age or prp files are changed saves work for the distributor, but having to do all the diffs for python would add a lot of work.

I also have a script here which unpacks, decompyles, patches, compyles and packs. It consists mainly of python and uses libPlasma tools, so it might even work on Windows, too. PM me if you are interested

EDIT: Oh, and what about Linux support? I won't be able to really use it otherwise as I have to test distros before distributing them

OK - I get it: trying to remove Cyan content from offline-KI is a lost cause.

But it would be useful in general to have Python-patch support in UruDistro. Perhaps diff isn't the best format, as you had cited.

diafero wrote: Oh, and what about Linux support? I won't be able to really use it otherwise as I have to test distros before distributing them

Edit: numbering corrected.

Ah, we're getting to that topic ahead of time. I wanted to start discussing "the future".

Presently the scripts are VBscript and use Windows-dependent resources. This choice was made because, since the game is Windows-only, most of our users (Uru players) all must have some kind of Windows environment, even if it's a VM or Wine, and all WIndows users have the VB scripting engine.

For now, I'd say the easiest way for testing the scripts in Linux would be to use Wine or a Windows VM. I can make you a VM that you can use with the free VMWare viewer.

I was planning to release version 1 in VBscript, let beta-testers go at it for a while, and then make a decision about version 2.
There are several possibilities for the future:

1- Stay in VBscript
pros: it works, nothing to install for users, low maintenance
cons: works only on Windows

2- Translate into Python
pros: true programming language, works on all platforms
cons: lots of work and testing again, users must install Python, and I'd have to learn Python.

3- Translate into C++ and turn it into a libPlasma tool using the libPlasma library instead of other libPlasma tools.
pros: true programming language, works on all platforms
cons: lots of work and testing again, users must install libraries, and I'd have to learn C++ again

4- Translate into Java and integrate into Drizzle
pros: simplest for users, takes care of both distribution and installing, most viable solution, works on all platforms
cons: lots of work and testing again, for me and for Dustin. Drizzle gets bloated. Have to basically re-code libPlasma into java. I'd have to learn Java (bleh)

Chacal wrote:users must install Python

Not necessarily... http://www.py2exe.org
Real OSes come with Python standard, but Windows, being its fake self, does not have Python.

Learning Python is easy enough and libPlasma has PyPlasma for Python 2.5, 2.6, and 3.0... I'd assume it also works on 3.1, but I've never tried that.

I place my vote for either options 2 or 3. I strongly advise against 4 (which you labeled as a second 3). Drizzle is already complicated enough. I was slightly overwhelmed when I tried Drizzle20. I believe the last time I used it was before Drizzle8--I compiled from SVN. It was actually more user-friendly then.

Drizzle is simple enough, it's the interface that's cluttered. Probably it should be split into two different utilities:
- for users: Simple conversion and UAM
- for hackers: the rest. Almost all of it is only used by Dustin and a few of us anyway.

This would solve your objection about complexity.
I still think that Drizzle is the ideal vehicle for UruDistro, because from a user's perspective, it already distributes and installs changes. This one case where functional requirements trump other considerations.

I'll have a look at you link.

Also there is another options:

5- Partially integrate with Drizzle, without translating into Java. This means packaging each distribution as if it was any other Age, or the off-line KI, or Race's additions, so that it is distributed with UAM, which solves the distribution problem. But instead of processing the distribution, Drizzle would only unzip it into a folder and call the UruDistro install script. Option 5 is not incompatible with option 1.

I love how, of the four languages you list, you only label C++ and Python as "true programming languages"... I have to say, I agree completely . In any case, I would second Hoikas' vote for Option 2 or 3, probably 2... Most people who are messing with Uru files will already have Python, and Python makes scripting quite easy (much easier than VBScript, IMO, but then I've never liked anything VB*). The biggest issue with this, of course, is that I haven't exposed ANY of the PRC stuff to PyPlasma, so you'd either need to call prcc/prcdc for the PRC support, or go with the C++ option...

Zrax wrote:I love how, of the four languages you list, you only label C++ and Python as "true programming languages"... I have to say, I agree completely .

I didn't even notice that.

*Hoikas commends Chacal on recognizing greatness*

Though, I have my bias toward Python...

Zrax did make a good point about most people already having Python already. I didn't even think about that for some reason. Things get tricky when you start getting into Python 2.x vs Python 3.x though...

The project started as DOS batch files. Given the limitations of those, I naturally switched to vbscript for the reasons listed above. I seriously considered Python, but the target audience being the typical Uru player (not the Writer or the hacker), I stayed with vbs. I tried to use the Python 2.x that comes with Uru but there's no python.exe. Anyway I figured vbscript is so easy to read, anyone with half a brain can convert it to Python. I added lots of comments anyway (unlike *cough* certain developers *cough*).

Zrax wrote:The biggest issue with this, of course, is that I haven't exposed ANY of the PRC stuff to PyPlasma, so you'd either need to call prcc/prcdc for the PRC support, or go with the C++ option...

...or continue running your compiled tools, as I do now.

BTW, I can't release UruDistro until you fix PlasmaSum!

I would vote for 1 or 4(surprise! :P). 1 works now, and converting it to Python or C++ seems like wasted effort at this point, since those also have problems with code not being cross-platform(unless you really know what you're doing, and even then it is easy to slip up with that; I've done a ton of C++ over the years, and it is the most powerful language in terms of "generic" programming and multiple other paradigms, but it is typically difficult to debug and maintain, which is more important in a project like this, I think.) And for being an interpreted language, Python surprisingly has different byte-orders on different platforms; it's cross-platformness is about on par with C++: possibly, but you have to be very vigilant while programming anything non-trivial. Java, while being long-winded, is very fast (about 90% the speed of native code in practice) these days, and is extremely good at cross-platformness and avoiding errors at compiletime, whereas Python is next-to-useless at that. (Python is still a good language for teaching non-programmers how to program, though.) So, to summarise my opinion on the languages(of which I've used all 4 quite a bit): C++ is great though not consistent nor predictable; Python is a bug nightmare; Java is stable but wordy.

I could help with 4 if you tell me what you need, but I should mention that there is one known shortcoming: decompiling/recompiling python files, which may or may not be a problem for UruDistro. This is because the "pickling" Python does is heavily version dependant, and requires binaries from each version of Python decompiled (check out the source for Decompyle if you want to know precisely what I mean.)

So, perhaps option 1 would be the best, depending on what you want, and as you say, it can easily be distributed/updated as a tool through UAM.