New Features: Freepascal support

[xenon]

GPC has been replaced by FreePascal 1.0.6

Everything should run without changing anything in your source codes. Rejudgments - if any - will use FreePascal but nothing strange should happen.

Well, I'm in big trouble now because of the difference in the way strings are defined between GPC and Freepascal. GPC uses round brackets and FP uses square brackets. All my submissions that use strings will now be rejected in the event of a rejudge, because I always format the string type (string(255), string(1000), string(1000000), etc., whatever is needed for the particular problem).

I solved 383 problems in Pascal, about half of which contain strings, so I'll have to edit some 190 source files and resubmit them.

What now?
- xenon

[fpnc]

Mmm... I've always used [] to denote lengths in gpc, so I haven't thought of this problem before.

I'd be happy if I could say GPC is going to be kept forever and ever... but I cannot. If we use gpc we cannot upgrade gcc so we must sacrifice gpc...

Two things can be done at this point:
1) You use a "simple macro" like this:

Code: Select all

cat file.p | sed 's/\(.*string\)(\([0-9]*\))\(.*\)/\1[\2]\3/'

which replaces all the ocurrences of "string(number)" with "string[number]" and lefts everything else as is. It should give the correct sourcecode to be submitted.

The problem would be if you've used constants. In that case, it should be something like

Code: Select all

cat file.p | sed 's/\(.*string\)(\([A-Za-z0-9]*\))\(.*\)/\1[\2]\3/'

but I don't know if this would be right and wouldn't cause more troubles...

2) We use that sentence as we rejudge the problems just before compiling. If I'm right - I really expect to be totally right here - that sed sentence should have no other consequences, so it should be safe to use it just before compiling, and it would do the trick.

I can tell you that we're never going back to gpc, so from now on you should type using string[]. For those submitted problems until now I think the best thing is to implement #2.

Let me know your opinion, please. I want to fix this asap.

Best regards,

[xenon]

I can't check it from here, I'm at my work right now, but as I remember the GPC standard is/was to use round braces for strings-dimensions, and square braces for everything else. Because I always used Freepascal myself, I had to include compiler directives to take care of the round braces.

It's not the changing of the sourcecode that I'm worrying about, but the resubmitting. It will lower my Accepted/Submitted rate , but that's probably something I'll have to overcome. And it's a lot of work.

More worrying, IMO, is the fact that a lot of people will not be aware of the change, and will be confronted with compiler errors when a problem is rejudged. Or am I the only one that uses round braces? There are enough problems that require one to use long strings.

I fully agree with the conversion from GPC to Freepascal, which is far more sophisticated, but I just don't know an elegant solution to this conversion problem...

[xenon]

Sorry, I didn't read your post carefully enough before replying. You were sugesting using sed before compiling at the judge end; not for me to solve the problem.... (haste, haste, haste).

I don't know if it would work in general, but I think so. Probably the best thing to do, is test it on a great number of Pascal submissions that were accepted previously, but I don't know if that is practical.

FreePascal gives a compiler error when round braces are used. Maybe it's possible to trap them when rejudging, although the question remains what to do with them then.

Well, I'll have to go now...