#include files

[SirWumpus]

From the Guidelines

Including a small extra file from your submission (plus the usual system include files) perfectly reasonable.

Would this qualify as suitable permissible example?

/* prog.h Config */

#define DELAY 123
#define MULTIPLIER 321
#define LF_KEY  'h'
#define UP_KEY  'j'
#define DN_KEY  'k'
#define RT_KEY  'l'

... possible long list, say 30 #define of only constants ...

- - - 
/* prog.c */

#include <prog.h>

Does prog.h count to towards Rule 2 beyond the #include? Or appear as subverting Rule 2?

If the above is what you envision? Is it worth adding as an example to Guidelines? Or leave it as an exercise to the reader?

[xexyl]

Quite amusingly I have been grappling with the same issue ... I have had two ideas or else include in prog.c which I am more inclined to do simply because of the fact others have done this before, #include a file and one was 'best abuse of the rules' (and I guess at that point it was no longer allowed).

Landon told me years ago that it is okay (but maybe this has changed!) to include a file for help. But I don't know and I'd like to know this too.

Better yet if so what is the maximum size of the included file (according to iocccsize presumably).

[SirWumpus]

One maybe One #include to #include them all.? Instead of using the Makefile CINCLUDE with a list of --include, use a single include file to include the supporting system files.

[xexyl]

One maybe One #include to #include them all.? Instead of using the Makefile CINCLUDE with a list of --include, use a single include file to include the supporting system files.

No. That would break some things too. Also consider dynamic includes that sometimes happens. Most people probably just use #include anyway. The variable works well and that is why it's there. There seems to be no point too in doing #include on a file with #includes when you can just use the Makefile.

I am not, incidentally, saying that nobody would use it. Clearly it seems you might. But the variable is definitely needed at times just like the other variables.

[SirWumpus]

That would break some things too.

How so?

Also consider dynamic includes that sometimes happens.

Huh? What you talking about Willis?

[xexyl]

That would break some things too.

How so?

Getting rid of the variable would be problematic. See also below.

Also consider dynamic includes that sometimes happens.

Huh? What you talking about Willis?

Just like with warnings one can include files depending on other variables ... that's how. Also different platforms sometimes need different include files.

So how would you address it? The Makefile works well. Whether or not anyone would use your idea I do not know but I also don't know why they would want to when they have the Makefile. That's the point of the variable. But I also only speak for myself. It seems like a waste to me but at least one person would use it so it must not be. The other parts though, those are important.

[xexyl]

That would break some things too.

How so?

Getting rid of the variable would be problematic. See also below.

Also consider dynamic includes that sometimes happens.

Huh? What you talking about Willis?

Just like with warnings one can include files depending on other variables ... that's how. Also different platforms sometimes need different include files.

So how would you address it? The Makefile works well. Whether or not anyone would use your idea I do not know but I also don't know why they would want to when they have the Makefile. That's the point of the variable. But I also only speak for myself. It seems like a waste to me but at least one person would use it so it must not be. The other parts though, those are important.

FYI: sometimes it's not just -include but also -I in the Makefile variable. That's an example. But some systems like macOS have different paths. I had to resolve that issue with one old entry that did not work with macOS. Alt code obviously.

[SirWumpus]

Also different platforms sometimes need different include files.
So how would you address it?

Didn't understand first what you meant by dynamic, but realised you meant conditional includes. Some thing like...

#ifdef __NetBSD__
#include <curses.h>
#else
##include <ncurses.h>
#endif

#ifdef DARWIN
#include <sys/random.h>
#endif

The autoconf tool chain being a notorious example for conditional includes based on functionality or platform.

[xexyl]

Also different platforms sometimes need different include files.
So how would you address it?

Didn't understand first what you meant by dynamic, but realised you meant conditional includes. Some thing like...

Yes it would have been better if I said 'conditional' but I think due to being so tired and maybe thinking of more than just that that I chose a less accurate word. Apologies.

#ifdef __NetBSD__
#include <curses.h>
#else
##include <ncurses.h>
#endif

#ifdef DARWIN
#include <sys/random.h>
#endif

That's true but it would not work in every case for the contest at least. Actually I think I also interpreted it as 'we don't need the CINCLUDE variable' but thinking on that I guess that I interpreted something a bit too literally (for which I am afraid being tired is not entirely the reason although it probably did not help). In some cases though like I said the Makefile variable uses -I.

The autoconf tool chain being a notorious example for conditional includes based on functionality or platform.

Yup.

--

And again I'm not saying your idea is bad or wrong or anything. I guess (but for no good reason one way or another) that the judges won't want that but if I'm honest it's not like it's really any different from using the Makefile. Well to me I find it uglier but that's a personal preference only. I would not use it especially as the Makefile system already allows for it easily (and one fewer file to include in the submission! - it is curious but I seem to run into the limit .. did last time for sure and I think other times as well). But obviously I don't have a say in the matter and I also don't want to say in the matter. I was mostly just thinking (at the time) that you were saying instead of the CINCLUDE.

I would say this feels like cheating except that we have the Makefile option. Unless..unless of course it's a great amount of includes and it would be too many for the Makefile (for the judges) of course! As for including a config file that is code. I guess that is 'cheating' according to the judges. I suppose if iocccsize scanned local include files it would be something but it would have to be done carefully I guess: imagine if there is a string that suggests it includes a file, for example. But I guess that's not necessary either.

Anyway I think it's an interesting idea if nothing else even if I would not use it (or I don't think I would). I still am much more interested in the idea of including code via the #include! I thought that was a big 'no'. I don't recall that in the guidelines before - at least not in the way it seems to be interpreted now (if at all). Just a few minutes before you posted this I actually was playing with ideas for something as well so it's fun timing. (In fact I think I probably would not use it for reasons I obviously am not going to get into.)

Hope you have a great day! I'm curious how this will go too.

[lcn2]

Guidelines of Rule 2

UPDATE 0

The guidelines are explicitly vague for an exactly one good reason: to not stifle creativity.

We won't comment on, nor pay much attention to the discussion above ⬆️ in case that transpires becomes a submission.

Nevertheless, more than 0 IOCCC judges have a long standing tradition to pre-scan submissions before the start of round 0 and identify possible Rule 2 violations. On the other hand 🤚 such violators get a fair look 👀 to see if they can be rescued (by more than 0 IOCCC judges playing the "softy"). Nevertheless the number of submissions that escape round 0 with a possible Rule 2 violation can be guesstimated by examining the collection of winning entries.

On the 3rd hand 🖐️, at least 1 IOCCC judge wonders why some submissions haven't attempted to "drive large trucks 🚛 thru" (as the expression goes) various vague aspects of the guidelines: possibly by hoping for an "abuse of the rules" gambit.

On the (OK .. foot 🦶): if such a submission might have attempted such a "truck drive" that did survive round 0, but it failed to "fail to suck" (as the expression goes), and/or lost to better submissions in later rounds, the outside world would not know. 😉

And using the other foot 📏 (apologies those who aren't metricly challenged), one had approximately 10.0000 +- 0 submission slots to work in, so who knows❓🤔

[xexyl]

Guidelines of Rule 2

UPDATE 0

The guidelines are explicitly vague for an exactly one good reason: to not stifle creativity.

We won't comment on, nor pay much attention to the discussion above ⬆️ in case that transpires becomes a submission.

I was thinking the same thing actually ... the example.

Nevertheless, more than 0 IOCCC judges have a long standing tradition to pre-scan submissions before the start of round 0 and identify possible Rule 2 violations. On the other hand 🤚 such violators get a fair look 👀 to see if they can be rescued (by more than 0 IOCCC judges playing the "softy"). Nevertheless the number of submissions that escape round 0 with a possible Rule 2 violation can be guesstimated by examining the collection of winning entries.

On the 3rd hand 🖐️, at least 1 IOCCC judge wonders why some submissions haven't attempted to "drive large trucks 🚛 thru" (as the expression goes) various vague aspects of the guidelines: possibly by hoping for an "abuse of the rules" gambit.

On the (OK .. foot 🦶): if such a submission might have attempted such a "truck drive" that did survive round 0, but it failed to "fail to suck" (as the expression goes), and/or lost to better submissions in later rounds, the outside world would not know. 😉

And using the other foot 📏 (apologies those who aren't metricly challenged), one had approximately 10.0000 +- 0 submission slots to work in, so who knows❓🤔

I was not expecting the commentary but it was a good laugh that I needed! I actually thought something was fishy (to continue the analogy making) with the reading. I wish I knew what you meant in all of it though - but I know that is quite deliberately obscure (which is rather charming in its own way). As for me I would not dare to take such a risk.

Speaking of metrically challenged I want to remind you that we're all vertically challenged at different times in our lives: technically we're all very similar height when we lie down to die. Or to sleep for that matter. It just then comes down to how much weight one has. So we might say that at the time of lying down your weight is part of your height. Or perhaps your weight IS your height.

[xexyl]

Speaking of metrically challenged I want to remind you that we're all vertically challenged at different times in our lives: technically we're all very similar height when we lie down to die. Or to sleep for that matter. It just then comes down to how much weight one has. So we might say that at the time of lying down your weight is part of your height. Or perhaps your weight IS your height.

Also climbing races are bigoted to midgets (yes yes I know that's not considered 'polite' but I'm not calling anyone a midget! Besides I am not exactly tall either! Actually it's kind of necessary for the joke, or at least it makes it more ironic). See if I'm a Hobbit (and I'm not but I'm not considered 'tall' either) then my head is lower. That means that my arms are lower too. That means I have to climb further up before I can reach the top. That means if I start at the same time as the giant I am at a disadvantage. This is not right.

And yes. I know that for the joke it would have also worked to say Dwarf but there are very good reasons I did not even if it would contrast nicely. Maybe.

[lcn2]

From the Guidelines

Including a small extra file from your submission (plus the usual system include files) perfectly reasonable.

Would this qualify as suitable permissible example?

/* prog.h Config */



#define DELAY 123

#define MULTIPLIER 321

#define LF_KEY  'h'

#define UP_KEY  'j'

#define DN_KEY  'k'

#define RT_KEY  'l'



... possible long list, say 30 #define of only constants ...



- - - 

/* prog.c */



#include <prog.h>

Does prog.h count to towards Rule 2 beyond the #include? Or appear as subverting Rule 2?

If the above is what you envision? Is it worth adding as an example to Guidelines? Or leave it as an exercise to the reader?

While a fair question, it's also hard to give a definitive answer.

Nevertheless we can try:

A gut reaction was .. maybe OK .. until we saw the line:

... possible long list, say 30 #define of only constants ...

Then, insert a bit of a "squishy face" (as the expression goes), comes into play.

It's also a matter of degree and fairness.

If the prog.c was about 2-3k (I.e., plenty of rule 2 room) and wanted to pack some defines into a prog.h, that might not be so bad: unless that prog.h was more than a "finger of k" (we ARE being deliberately vague) in size.

Also think about fairness to those it work hard to squeeze under the Rule 2 limit only to have some "lazy" submission try to blow past the limit by overdoing the compile line and/or include set.

At the risk of a spoiler

Perhaps a "safer" play would to have a prog.c that fit under the size limit that didn't include some file by default, say because some symbol wasn't defined by default, AND this version of prog.c was interesting, obfuscated, and fun while compiled that way.

The consider that when some symbol was defined, some optional.h becomes included that added a fun, obfuscated, and interesting twist to the code. And that the remarks.md made is extremely clear why optional.h wasn't an attempt to bypass the limits.

Now the prog.c ALL BY ITSE LF would have to be a worthy candidate for consideration of a winning entry to survive IOCCC judging, otherwise the world wouldn't know it as a winning entry.

We hope this sprinkles a bit of seasoning 🧂 into your mind.

[xexyl]

While a fair question, it's also hard to give a definitive answer.

Nevertheless we can try:

A gut reaction was .. maybe OK .. until we saw the line:

... possible long list, say 30 #define of only constants ...

Then, insert a bit of a "squishy face" (as the expression goes), comes into play.

I thought that too .. connected to your point about it being unfair to those who worked hard to squeeze it in.

It's also a matter of degree and fairness.

If the prog.c was about 2-3k (I.e., plenty of rule 2 room) and wanted to pack some defines into a prog.h, that might not be so bad: unless that prog.h was more than a "finger of k" (we ARE being deliberately vague) in size.

Now that is interesting. I have sometimes thought: if I am under the size and I include data by #include and that would still result in < the size would it matter? I have never risked that because then I cannot as easily determine if it would be actually under the size or not. But it's still interesting.

I asked you before @lcn2 but: if one were to do this strictly for a help option would it matter? I have no need for this btw .. just wondered. I remember what I did in the past and it was ironically not very helpful.

Also think about fairness to those it work hard to squeeze under the Rule 2 limit only to have some "lazy" submission try to blow past the limit by overdoing the compile line and/or include set.

I'm glad you see it that way too.

At the risk of a spoiler

Perhaps a "safer" play would to have a prog.c that fit under the size limit that didn't include some file, say because some symbol wasn't defined by default, AND this version of prog.c was interesting, obfuscated, and fun while compiled that way.

The consider that when some symbol was defined, a optional.h was included that added a fun, obfuscated, and interesting twist to the code. And that the remarks.md made is extremely clear why optional.h wasn't an attempt to bypass the limits.

Now the prog.c ALL BY ITSE LF would have to be a worthy candidate for consideration of a winning entry to survive IOCCC judging, otherwise the world wouldn't know it as a winning entry.

That reminds me of the no interactive programs and also the idea that if you want to risk breaking the rules it would be better to do another version that does not break the rules - and then clarify the fact and then try and justify it. Those are either in the rules or guidelines or both.

Some fun ideas though.

We hope this sprinkles a bit of seasoning 🧂 into your mind.

I'd rather chocolate personally!

[lcn2]

I asked you before @lcn2 but: if one were to do this strictly for a help option would it matter?

If prog.c, as compiled by make all, was a worthy submission that could rise to the level of an IOCCC winner, then if complied with a -DWITH_HELP that caused a help.h via some make with_help make rule, and the remarks.md made it clear near the top that the help.h was optional / not a Rule 2 bypass, then one might successfully argue that the help.h fit well within the Guidelines for Rule 2.

And of course, -DWITH_HELP is just an example. The make with_help rule could easily just add -include help.h on the compile line just as well.

BE CREATIVE ‼️ (and, if possible, eat great chocolate 🍫)

Of course, the trick, skill, and real effort is to have a prog.c that was worth of becoming an IOCCC winning entry in the first place.

[xexyl]

I asked you before @lcn2 but: if one were to do this strictly for a help option would it matter?

If prog.c, as compiled by make all, was a worthy submission that could rise to the level of an IOCCC winner, then if complied with a -DWITH_HELP that caused a help.h via some make with_help make rule, and the remarks.md made it clear near the top that the help.h was optional / not a Rule 2 bypass, then one might successfully argue that the help.h fit well within the Guidelines for Rule 2.

And of course, -DWITH_HELP is just an example. The make with_help rule could easily just add -include help.h on the compile line just as well.

BE CREATIVE ‼️ (and, if possible, eat great chocolate 🍫)

Of course, the trick, skill, and real effort is to have a prog.c that was worth of becoming an IOCCC winning entry in the first place.

Of course .. as I have done a number of times :-)

Actually I was just wondering if it was allowed. I think that it would not be worth it in a lot of cases.

Of course with the WITH_HELP that uses a lot of bytes. In some cases it might just be better to include a document on help if it uses too many bytes! And it's not like I'm not good at writing a lot too much.

As for eating great chocolate. Would my mum's double layered chocolate fudge cake work? I'll be having it soon enough: towards the end of the year (when I have two or sometimes three) and then my birthday in February. I think it will :-)