#329 make: gfn file skips trailing comments from inp code file

[Ekkehart Schlicht]

In my inp file I have

 if nelem(C)==0      # if no checking for time-variability of
        #               # coefficients required, do estimation
        #               # (nelem(C)>0 activates Monte-Carlo Mode)

Upon compilation to a function package I get in the gfn file:

   if nelem(C)==0
        #               # coefficients required, do estimation
        #               # (nelem(C)>0 activates Monte-Carlo Mode) 

That is, a comment is dropped. This may make it difficult to understand the comment.

Cheers
Ekkehart

[Ekkehart Schlicht]

Similarily,

        bundle b = TVCestimate(S,L,g',0,like)   # estimate time-invariant specification
        R2restricted=b.R2           # get R-squared for restricted spec.
        R2inv=b.R2                  # get R-squared for time-invariant specification
        R2stripped=b.R2             # get R-squared for time-invariant specification
        R2list=R2list|R2stripped    # R2list is empty here, R2stripped is appended
        #                           # such that it is the first element of R2list

turns after compilation into

        bundle b = TVCestimate(S,L,g',0,like)
        R2restricted=b.R2
        R2inv=b.R2
        R2stripped=b.R2
        R2list=R2list|R2stripped
        #                           # such that it is the first element of R2list

I have not been aware of that and shall adjust my way of commenting. But maybe it would be nice allow for comments after commands.
I see, however,that this is not a bug but rather a feature!
Cheers

Ekkehart

[Sven Schreiber]

Not sure this is a feature instead of a bug. I believe it is actually a recent change that comments are preserved at all in the gfn, and so I'd guess that the removal of trailing comments is perhaps an oversight. (It still seems to happen, at least for me with a recent snapshot.)

[Allin Cottrell]

I wouldn't say this is a feature, exactly. But it's not inadvertent and I wouldn't say it's a bug. It's kind of a forced move to ensure greatest efficiency of hansl function code. We can fairly easily detect lines that are entirely comment, and store them but mark them as IGNORE for execution purposes. It would no doubt be possible, but would be a good deal more complicated, to preserve trailing inline comments.

[Ekkehart Schlicht]

So what is the recommendation for authors?

On 3/18/2026 7:21 PM, Allin Cottrell wrote:

I wouldn't say this is a feature, exactly. But it's not inadvertent
and I wouldn't say it's a bug. It's kind of a forced move to ensure
greatest efficiency of hansl function code. We can fairly easily
detect lines that are entirely comment, and store them but mark them
as IGNORE for execution purposes. It would no doubt be possible, but
would be a good deal more complicated, to preserve trailing inline
comments.

---

[bugs:#329] https://sourceforge.net/p/gretl/bugs/329/ make: gfn
file skips trailing comments from inp code file

Status: open
Group: v1.0_(example)
Created: Mon Feb 23, 2026 12:37 PM UTC by Ekkehart Schlicht
Last Updated: Tue Mar 17, 2026 06:18 PM UTC
Owner: nobody

In my inp file I have

|ifnelem(C)==0# if no checking for time-variability of # #
coefficients required, do estimation # # (nelem(C)>0 activates
Monte-Carlo Mode) |

Upon compilation to a function package I get in the gfn file:

|ifnelem(C)==0 ##coefficientsrequired,doestimation

(nelem(C)>0activatesMonte-CarloMode)|

That is, a comment is dropped. This may make it difficult to
understand the comment.

Cheers
Ekkehart

---

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/gretl/bugs/329/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

[Sven Schreiber]

The more or less official recommendation right now is what you said before: if you want the comments to appear to the user in the code view, then only put them on separate lines, not inline.
Of course, for non-packaged functions and especially for your own codebase you can continue to put the comments wherever you like. Personally, I also use the inline commenting style a lot, but I understand that currently the cost-benefit ratio of preserving those inside a packaged function is too large.
So I'm going to close this.

[Allin Cottrell]

I'm reopening this because I thought some more about the issue and realized there was a simpler way of preserving inline comments in function-package code. That's now in git, but needs more testing. I'm away from home right now but I'll put up new snapshots in a couple of days.

[Sven Schreiber]

I tested this with some package code of my own with the latest snapshot and inline / end-of-line comments show up alright in the code view of the package.
So I would close this again, or did you have other tests in mind, @allin?

[Allin Cottrell]

No, I think it can now be closed again.