PenUltima Online

You mean you don't want to know if one of your include in unused in one of yours .src files Yukiko?
Even if an unused include doesn't make you ecl bigger, if you modify that include it causes your script to recompile also if not needed.
Ecompile already checkes if function inside an include are used or not, display a warning would not raise your compile time.

First, I don't care if a script recompiles or not. Compiling scripts isn't a big time concern of mine. Frankly I am impressed at the efficiency of ecompile. So that makes little difference to me.

Second, I am tired of seeing all those "unused variable" warnings in the ecompile output. I don't want another, in my humble opinion, unnecessary item cluttering up the output from ecompile.

Third, I am not convinced that having an unused include file causes any inefficiencies in POL executing the compiled files. I can see where an unused variable would take up space unnecessarily in the shards data files but unused includes seem to only take up space in the source files and appear to have no adverse effects on the world data file size or script execution.

Maybe if you compile 20 scripts isn't a big time, if you have to recompile more then one thousand it is
As already Silver said, it would be more useful to add a line in the .dep files than having a warning, althought if you can see warnings in the ecompile you can go editing the script (removing the unused include) ad you'll never see it again, easy, no?

Having unused include files DOES NOT causes inefficiencies during execution of POL, but it can take lot of time when compiling scripts

But what I don't think you are understanding is, what is being asked for here is to add time to the eCompile process to 'fix' something that you should have fixed already. It's sort of like asking eCompile to check for any endless loops in your code, or any of a thousand other coding mistakes. I would -much- prefer eCompile just took me at my word when I write a script, and do what I ask it to do... and not be spending time double-checking my work. You are asking eCompile to take longer for ME, because you can't organize your includes properly... when there are plenty of other ways to do what you are asking for (like simply commenting-out includes if you suspect they aren't used, and try recompiling to see).



As it is, on my shard, due to the extent that the Housing and Town Stone systems are involved in things (there is very little that does not check something in one or the other of those systems), I very often have compiles that do hundreds of scripts at a time. So, it takes a couple minutes. Big deal. However, in my case, because I've organized all of my includes properly from the start (ok; not 'from the start', because the include mess in WoD/Ackadia was horrid), I know very well that ALL of those scripts really do need to be recompiled, because I know that only includes that are necessary are in each script.

Not all shards have only one scripter that works on all scripts. If i'm insure of an include into one script i can remove it and check if it compiles, but doing it for every include in every script is way longer than looking for what ecompile already does.
I repeat it: what ecompile already does
It wouldn't take hours to write in the .dep if the include is used because the functions are already checked, if no function is checked the include is useless.
We're asking for a feature, you already said that if implemented it would be useless to you, like other features are for us. I think we already explained why we want or not this to be implemented, now it's up to the developers

I don't know of any shards that have only one scripter. However, I do know this: having more than one scripter is more reason to keep everything organized... not less.



Just because you repeat something, does not make it true. I just opened a .dep file, and guess what? No counts of how many identifiers/functions are used in each include. If it already did it, I would have to wonder why it's being asked for, then.

Quoting Marilla:
"I don't know of any shards that have only one scripter."

You do now Marilla unless you count the scripts I have borrowed/used from other shards. For most of the life of Hope Lives I have been the sole scripter.

As for the number of scripts and ecompile time...

Output from the last ecompile of my shard:
Compilation Summary:
Compiled 1127 scripts in 141781 ms.

Now unless I am mistaken that's a 141 second compile time or just over two minutes and twenty seconds. I'd say that's not a major delay for 1,127 programs compiling.

There is one thing I think would be neat but only for the sake of curiosity. I wish ecompile gave a total count of all lines compiled in the summary. It would be for nothing else than curiosity. But that's another topic.

That's the feature we're asking for (the alternative, at least): writing to .dep files the hit count of include calls (already done by ecompile scripts parsing)

Xadhoom said (and, let's not forget, repeated) that eCompile 'already does this', referring to counting how many times a function is used. Since it being displayed somewhere is the only way I could imagine he knows that, I looked.

I think he (and also you) is confusing the fact that eCompile never reads functions that are never called, with it having any clue how many times a certain include is used.


What I'm saying is: Why slow down ALL of our eCompiles to count and track this stuff, when the problem is that you have a mess of includes in the first place. That is: You are asking eCompile to go beyond being a compiler, and instead you want it to be an auditor of your code. My hope is that does not happen: I use eCompile too.

Try to put an useless include in a .src file: the generated .dep file will list that file anyway.
This means: ecompile already looks for every included file, so it could be easy and fast to track which .inc are really used (while it parses .src file) and which ones are not.

We're asking a feature to improve our compiling optimization, not to slow down yours, obviously.

If a dev will tell that this could slow down ecompile performance, never mind.

This is quite the non sequitur. Of course eCompile looks for every included file. It would be fairly useless if it did not. Actually, this fact shows exactly what you are missing: eCompile lists the file anyway because it doesn't know (or care) if you've used anything in it, or not, because by design, it simply ignores code that you never call.




You are asking for a feature to do your job as scripter for you... you are asking for the compiler to do more work than it needs to, because you don't want to do the work yourself. In the time you've taken posting about this, you could have fixed the problem. Also, the time you've spent posting about this is probably more than the extra time it takes your eCompile to run due to an extra include here or there, unless you have a REALLY slow system, or basically have all includes included in every single source file.



I figure the devs will do or not do the feature based on whatever criteria they have. One criteria might be: Is it worth taking time to develop this feature, when it's something that the scripter could and should themselves do?

This is quite the non sequitur. Of course eCompile looks for every included file. It would be fairly useless if it did not. Actually, this fact shows exactly what you are missing: eCompile lists the file anyway because it doesn't know (or care) if you've used anything in it, or not, because by design, it simply ignores code that you never call.




You are asking for a feature to do your job as scripter for you... you are asking for the compiler to do more work than it needs to, because you don't want to do the work yourself. In the time you've taken posting about this, you could have fixed the problem. Also, the time you've spent posting about this is probably more than the extra time it takes your eCompile to run due to an extra include here or there, unless you have a REALLY slow system, or basically have all includes included in every single source file.



I figure the devs will do or not do the feature based on whatever criteria they have. One criteria might be: Is it worth taking time to develop this feature, when it's something that the scripter could and should themselves do?

This is quite the non sequitur. Of course eCompile looks for every included file. It would be fairly useless if it did not. Actually this fact shows what I think you are missing: eCompile lists the file anyway because it doesn't know (or care) if you've used anything in it or not, because by design it simply ignores code that you never call.




You are asking for a feature to do your job as scripter for you... you are asking for the compiler to do more work than it needs to, because you don't want to do the work yourself. In the time you've taken posting about this, you could have fixed the problem. Also, the time you've spent posting about this is probably more than the extra time it takes your eCompile to run due to an extra include here or there, unless you have a REALLY slow system, or basically have all includes included in every single source file.



I figure the devs will do or not do the feature based on whatever criteria they have. One criterion might be: Is it worth taking time to develop this feature, when it's something that the scripter could and should themselves do?

This looks like a function better suited to some other scripting language. Maybe Perl or some text parsing language like Perl. If I understand Perl's capabilities a script could be written to parse all src files and check for includes not referenced by those files or their includes.

Another can be: would this feature be useful to people who don't know all their includes by heart? like people who downloads the distro and want to modify something in the include organization?
But as i've already said: it's up to the dev, no need to continue this (useless) discussion, so don't expect me to reply again

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.