11 Mar, 2008, Tailsthefox wrote in the 1st comment:
Votes: 0
Either I am doing this wrong, or it patch doesn't work with smaugfuss 1.8, When I do the command alot of errors and rejects come up with it, So I was wondering is there an updated verison for smaugfuss 1.8 Or can someone explain to me how to add them in to this codebase?
11 Mar, 2008, Kayle wrote in the 2nd comment:
Votes: 0
There's no updated version. So you're going to have to manually apply the code changes. And the Gboards snippet is going to take a LOT of work to get working, not just in FUSS but in any Smaug, as it was incredibly buggy. I'd release my Gboards, but I seem to have misplaced the code. However, if I manage to find it, I'll let you know.
11 Mar, 2008, Tailsthefox wrote in the 3rd comment:
Votes: 0
Thanks for the input, Hope you find it.
11 Mar, 2008, Guest wrote in the 4th comment:
Votes: 0
Snippet patch files in general tend to break horribly once you've begun modifying your code. With all the mods done to FUSS over the years I'm not surprised it broke. This is the reason I prefer to write up manual instructions for most things. No patch files to get dirty, and it's easier to adapt on the fly.
11 Mar, 2008, David Haley wrote in the 5th comment:
Votes: 0
Why not just use the patch file as a guide, Tails? It's telling you absolutely everything that a hand-written "snippet format" file would. Look at what it's telling you to change, and apply those changes adapted as necessary to the code you have in front of you. A diff-format patch is giving no less information than a snippet-format patch, and is arguably giving more.
11 Mar, 2008, quixadhal wrote in the 6th comment:
Votes: 0
Heh, assuming the code that's being diff'd has a few useful comments in it, otherwise:
-  if(x[++y]–) foo();
+ if(x[y++]–) foo();

is kind of obnoxious. Best to hope they didn't rename x or change it from an array to some other data structure.
11 Mar, 2008, David Haley wrote in the 7th comment:
Votes: 0
Sure, that's true. But a snippet would tell you the same thing: Find the if statement "if (x[++y]–) foo();" and change it to …… It's just that the snippet would tell you in words. The diff also gives you line numbers and so forth, which, granted, can changed; finally, the diff also gives you more context than just one line (typically three lines each way). At best, a snippet might give you the function name in which the change takes place: but hey, best hope that the function name didn't change etc.
11 Mar, 2008, Guest wrote in the 8th comment:
Votes: 0
Regardless, I still think that written directions are less of a hassle. They also don't carry the risk of someone trying to patch the thing in only to break the snippet and the codebase. Backups backups backups! It's easier to look for "do_something" than it is to realize that do_something is on line 784 of a 4000 line file. :)
12 Mar, 2008, quixadhal wrote in the 9th comment:
Votes: 0
I more meant they might have changed (vs. the code the diff was made against) the whole way x works, so you wouldn't find a line that looks anything like the one in the diff. Mildly annoying to a programmer, terrifying to an admin who got stuck with the job of maintaining the driver. :)

Myself, I prefer both. I like having diffs with comments, or a text file alongside that mentions roughly where and what each chunk does.
12 Mar, 2008, David Haley wrote in the 10th comment:
Votes: 0
Well, sure, but like I said, snippets tend to give you instructions like "find the line of code X and change something nearby to Y". My point was that the snippet gives you instructions that are just as vulnerable to change in the long run.

The only advantage AFAICT of a snippet is providing function name in addition to the patch's line number. Still, that can be fixed by having patch files with a little more context.

The disadvantage of snippets is that they are very tedious to apply for somebody who knows what they're doing, and are hard to generate and error-prone in the first place.

Even better would be to do this properly from the get-go and actually provide full version control revisions instead of snippets or patch files. Distributed VCSs make this a trivial task: each snippet would be a branch off of the main branch. Then you can see the entire source tree before and after the change.
12 Mar, 2008, Guest wrote in the 11th comment:
Votes: 0
Maintaining ginormous repositories isn't feasible for very many people. It would be for me since I can devote all the space I want to it. MudBytes could do the same, but not with as many. Snippets keep things easy and simple. Even the newbiest of newbies I've run into can follow clear directions along the lines of "open comm.c, find read_from_buffer, change …. to !!!!!". The only problem is when the snippet doesn't come with clear instructions. At which point you're back to square one. I hate patch files for the most part. They're only useful if kept current, and hardly anyone I know has the time to maintain a collection at that level.
12 Mar, 2008, David Haley wrote in the 12th comment:
Votes: 0
Who's talking about ginormous repositories? Distributed VCSs are designed for this kind of thing. It is basically "free" to create branches, unlike CVS or SVN. Having a branch like this probably costs you less than a snippet with instructions, because the latter has to add all those instructions in addition to the changes. That's the beauty of intelligent version control…

And what of snippets with crystal clear instructions but that refer to code that has since been modified? Same problem as patch files… (Which, incidentally, also give the file name. Like I said, the only extra information in a snippet seems to be the function name.)
12 Mar, 2008, Conner wrote in the 13th comment:
Votes: 0
Sheesh, "Down boys!"
Y'all are arguing patch files versus hand made snippets when the original poster just wanted to know very specifically how to make the gboards snippet work with SmaugFUSS 1.8. :sad:
12 Mar, 2008, Guest wrote in the 14th comment:
Votes: 0
Kayle answered his question already. The rest is just … I dunno. Getting to where a guy can't say anything without it being attacked or ridiculed or mocked or something.
12 Mar, 2008, David Haley wrote in the 15th comment:
Votes: 0
That question got answered as far as it's probably going to be answered in the first reply to the thread. :wink: I think it's not irrelevant to speak of how to better manage future snippets/patches to avoid this kind of question, no?
12 Mar, 2008, Darwin wrote in the 16th comment:
Votes: 0
And now, here's a monkey flinging poo.
12 Mar, 2008, David Haley wrote in the 17th comment:
Votes: 0
Samson said:
Getting to where a guy can't say anything without it being attacked or ridiculed or mocked or something.

Who's ridiculing or attacking whom? No, seriously: it seems to me that there was absolutely nothing wrong with the thread until these last few posts. Maybe people are just feeling a little touchy and see everything as an attack these days. :shrug:

Darwin, of course, has it right… :wink:
12 Mar, 2008, Tailsthefox wrote in the 18th comment:
Votes: 0
make -s smaug
Compiling o/board.o….
board.c: In function `void finish_note(GLOBAL_BOARD_DATA*)':
board.c:178: warning: too many arguments for format
board.c: In function `void unlink_note(GLOBAL_BOARD_DATA*, NOTE_DATA*)':
board.c:222: warning: too many arguments for format
board.c: In function `void load_board(GLOBAL_BOARD_DATA*)':
board.c:377: warning: too many arguments for format
board.c:399: warning: too many arguments for format
board.c: In function `void make_note(const char*, const char*, const char*, cons
t char*, int, const char*)':
board.c:869: warning: too many arguments for format
board.c: In function `void handle_con_note_to(DESCRIPTOR_DATA*, char*)':
board.c:930: warning: too many arguments for format
board.c: In function `void handle_con_note_subject(DESCRIPTOR_DATA*, char*)':
board.c:1000: warning: too many arguments for format
board.c: In function `void handle_con_note_expire(DESCRIPTOR_DATA*, char*)':
board.c:1054: warning: too many arguments for format
board.c: In function `void handle_con_note_text(DESCRIPTOR_DATA*, char*)':
board.c:1100: warning: too many arguments for format
board.c: In function `void handle_con_note_finish(DESCRIPTOR_DATA*, char*)':
board.c:1165: warning: too many arguments for format


So yeah I did it by hand, and everything was running smoothly until it started to compile board.c Which as you all know is the main file of the global boards. I also switched it out with a working on, that I use on my dbz mud and still got the same errors just on different lines.
If you all could give me a heads up on how to fix these, It would surely help.
12 Mar, 2008, David Haley wrote in the 19th comment:
Votes: 0
It would help if you showed an example of a line giving warnings. Chances are that you have "x" format specifiers in a printf-type call, but more than "x" arguments passed in. (Well, that's just reading the warning… :wink:)
12 Mar, 2008, Tailsthefox wrote in the 20th comment:
Votes: 0
I would but atm it is impossible, for me to download anything, Where I am currently at they disabled downloading. But , the file is base from the globalboards snippets, so you could take a look from there.
0.0/32