PenUltima Online

I can see both sides of this argument; but I still lean towards the "Do not implement" side. Considering that the compiler would have to log all the include files it reads, then log all the ones that aren't used, then output to a file... it sounds simple in theory, but it would add needless overhead to compilation time. The only times I can think of that this would even be useful would be when the scripts are someone *elses* and they screwed up the includes so bad that it takes 3 years to compile. But you should always understand your scripts, so if you don't like the include structure: fix it manually, and learn the includes while you're at it.

IMHO the use of includes in scripts has blossomed into something larger and more complicated than what it should be. Includes or the idea of them as I understand it was two fold. One, you could create a library of functions/procedures that could be reused without having to copy them into each file that might use them. And two, by creating these canned functions/procedures you could simplify your programming because you'd already have a pre-written piece of code that was "bug free". The problem is that people have gone "include crazy" and created so many different includes that are put into includes embedded in includes three and four deep. That is sloppy coding. It's impossible to sort out some of the scripts the way they are coded. Just try to trace through any package in any Distro version

It's like when the GUI interface was invented. We were told "This will make things easier because you can recognize functions from the little icon rather than having to read the verbal description." But the use of cryptic icons has caused the need for "help text balloons" to give us a verbal description of what the icon means. Thus defeating the original purpose of the GUI.

Oooh goody. That means I can get in the last word!

People who "don't know their includes by heart" also should not need this - they shouldn't be adding includes willy-nilly; They should be carefully examining whether they need a particular include.

This just seems silly to me, on so many levels. I mean... can you imagine someone programming in C/C++ by simply slapping include and using statements at the top of every source file, until something happens to work? Yet, it often seems like that's how some people try to get eScript to work.

===============================

To me, programming is not so much about just 'knowing' everything... but it's about knowing where to find things, and how to use the environment and systems involved in the language/compiler you are using to get the effect you want. Just throwing whatever code you want into includes leaves you with a mess that apparently, some people think can only be solved by having the compiler do even more work beyond simply compiling.

While I don't think -any- modern 'compiler' is merely a compiler any more, these days, I think that it's always a good thing to keep compilers as lean as possible, and limited to doing work that is at least related to compiling. Aside from obvious things that could cause serious problems (like compiler warnings about hidden and unused variables), I do not think the compiler should be checking our code.

Yukiko mentioned something really great above, too; This sort of effort is something tailor-made for Perl. For those not familiar with Perl, C or Java could likely also be used. On Windows systems, a VB.NET or C# console program could be written to do this (much like Danielle's program that checks source files to positively make sure you have the appropriate 'use' statements - a program could be written that negatively assures you are actually using the includes you note. It could also easily be expanded to do the same thing for use statements (to assure you don't have any extras))


But I think that someone who has this problem with any frequency will be left with a big mess, still; They'll end up having to run such an auditing program frequently, because they are likely never to really know what their includes are for, and so they are likely to just keep tossing in more and more includes every time they try to work with a source file, until they find what they are looking for... and in the meantime, they usually leave the dozen or so other includes there, too. Bleh!

That's an unfortunate truth here. Believe it or not, the knowledge of that fact has tempered my response to this suggestion Because I know that by default, everyone's includes were a mess.


However, I don't recall the 095 distro having much trouble with large numbers of unneeded includes, thereby causing unnecessary recompiles. As you noted above somewhere, too; So what? It seems like you would have to have some really broad problem here for it to be noticeable; A half-dozen scripts with an extraneous include would hardly be something to notice, unless there is, otherwise, only a like or smaller number of scripts that legitimately need it. In such a case, it would seem easy to fix the problem.

But even if you are starting out with the 'fresh' distro, you still should not be just tossing include statements into your scripts as a way to 'fix' them... yet I know from looking at others' code, and seeing how many include lines exist, then are commented out (often to be later added in below), I know that people seem to do this, an awful lot.

To the extent that your includes simply are a mess, and that's simply what you must do to work; OK. I worked with a distro in the past, and I originally started with a script set that, as full of neat ideas it may have been, was a horrible mess as far as includes and lots of other basic scripting problems (WoD/Ackadia); So I had to deal with all of this myself.

It took time - lots of it - to get the includes into something resembling organization. In fact, I would say that only my recent upgrade work - where I also brought in another scripter - forced me to really finish that. Up until recently, I still had, for example, std.inc. Forgive me, those who wrote functions in it - but at least the version of it I had was a horrible mess; mostly filled with functions that had been replaced with core functions since 092, at least. However, the biggest problem with it was that it was a huge hodgepodge of functions, very few of which were related to any other functions there. I had, over the years, been removing any links into that file from any of my scripts; replacing them with calls to core functions that did the same thing, or creating new, targeted includes that made more sense (so that when you see the name of an include, you know exactly what it's for. Exactly what obvious purpose does an include named "std" serve? Compare that to an include named "webbrowser" or "townstones" or "magiceffects". Granted, often the 'obvious' is a bit esoteric, but still...)

It was only when I brought on someone to help, and they started using functions again in std.inc, that I realized that file was still there, and needed to be deleted. Having another set of eyes and hands in the scripting made me realize even more how important it was to keep things organized and understandable. I still have some way to go with that now, due to having more hands in the soup - for instance, I had long relied on 'clips' in TextPad as a reference to what functions I had available where, and what their parameter lists were, when I did not remember something off the top of my head (which, I almost never do!)... but of course, my scripter does not use TextPad, so I can't just send him my clip file. This has left me largely manually documenting the functions in my includes for his use.

It would have been much better had I done something like have a comment 'header' in each include which included a list of the functions meant to be called from outside that include, along with their return values and explanations of their parameters. As it is, he's done a good job of discovering the uses of the include functions themselves (often he goes there before he goes to the Core functions, which is how he ended up using functions in std.inc, most of which had better Core functions instead)


So.. umm... that's my big rant for the day!

My god what a long set of replies and views on something trivial, lol

Sounds my like a rant thread than feature request

Why... you... you... parade-rainer-oner-ofer!

hmph!

*points to Marilla's post*

Yeah what he said!
Whatever it was.

*chuckles*

mwuahahahah

It seems ecompile already ignores includes that are not used, and it would be absurdly trivial to simply print out any of them. How does something like this turn into a 3 page thread??

I think it would be helpful to have a configurable option in ecompile.cfg that's off by default that would print out unnecessary includes, unless it's not as trivial as I assume it is.

Which is why this isn't needed.



Depends on how you define 'absurdly trivial'. I think it would be 'absurdly trivial' to simply use your includes properly in the first place. But I think you are failing to understand that eCompile is doing what you said above: IGNORING code in includes that it is not using. If no code is ever called that's in an include, it's not bothering with any of the stuff in that file. It's IGNORING it - as in, not doing anything. It's not counting it, tracking it, or even reading the contents of its functions (it's merely making sure that it gets a list of the function/variable identifiers so as it compiles, it know what's where).



It was dead, until you brought it up again. I think it turns into a 3 page thread because it's a request made by lazy scripters that would cause all of our compiles to take some extra time and effort, when the problem here is in your code, and should be fixed there.

Why not have eCompile warn you when you have an infinite loop due to using a constant as a control and having no break statement? It would be 'absurdly trivial' to do so, wouldn't it? Why... it could even be an option you could turn on and off in ecompile.cfg...



I think it would be helpful for people to understand how to use includes properly, so that requests like this would die.

Marilla, I am not so sure these programmers are lazy or bad coders. I think the reason that they want this is because they are using someone else's script base...
*coughs*
...zuluhotel maybe and want ecompile to help clean these up.

Now that having been said, I agree that this isn't needed.

Ask someone who is proficient in PERL or maybe SED and GREP to code up a script or whatever in those languages/systems to do the work.

Anyway, Maud can you finally shoot this horse so it really dies?

Oh and please let's stop beating the dead horses.

Marilla you posts are so robust. Where do you find the time?

I know it was kind of a old post but sometimes my life happens and I can't live on the forums... That and there wasn't a clear answer to the request. So I figured I'd throw in my 2 cents.

It would be useful to me because I'm usually working on a large project with few people, so I make many changes in many places often and I can't keep track sometimes, or I might make a mistake. It's not really feasible for me to sit down and make flow charts and complete design plans (not to say that I don't plan at all!), but I usually spend more time coding than I do planning so some design changes might make some include lines not necessary. It wouldn't be a problem if I could just remember every line of ever script.

An example would be magery in the distro. At first I had all spell scripts calling core functions to play SFX and GFX. If you wanted to change the GFX or SFX of a spell you had to change the script itself. This might be fine for some people, but with anything I do for the distro I try to make it as configurable and user-friendly as possible, so I moved most of it over to a configuration file. Now all the spell scripts call a shared function in spells.inc to take care of SFX and GFX. This makes the spellSounds include in each of the scripts obsolete. This wouldn't be that hard to fix, but I might miss one. And I've made several changes like this, like how spells handle targetting. Or I'll use one spell that has a lot of includes as a template for other spells and I'll forget to remove the unnecessary include lines because I'm more focused on adding functionality than having pretty code.

There are 70 .src files in the magery package alone and sometimes I'd take long breaks from working on it and sometimes I'd work on it late at night and I'll just forget to take out the includes in a few places. I really don't have the time to finger through 70 scripts (let alone the whole distro) and weed out unnecessary includes mostly because it doesn't matter as ecompile ignores it anyway. It would just be nice to know which ones were not needed to so I could make my code pretty. When I'm done adding functionality I like pretty code. It makes me smile and feel happy.

I don't have vast amounts of time to argue with anyone about this or have anyone jump down my throat. It's probably very simple to implement and would have little to no negative impact on anything and could possibly help keep code just a tiny little bit neater.

And, as I've been saying; that's why this isn't needed at all.

we didn't use someone else's script base, we just changed the structure of ours includes and checking every file if it includes something unnecessary takes a very long time (and i repeat, ecompile already does this, because it ignores unused includes but still have to compile a file if one of the unused includes is modified)

but I don't want to start again discussing, maybe I am too lazy also for this, right Marilla?

This getting out of hand, lol