Am 23.08.20 um 01:43 schrieb Allin Cottrell: > On Sat, 22 Aug 2020, Sven Schreiber wrote: > >> Am 18.08.2020 um 16:19 schrieb Artur Tarassow: >>> >>> I spotted a possible "bug" when trying to plot weekly or hourly data >>> over time. Take a time-series, set some frequency and check the plot. >>> Even though the <print invest -o> command shows a correct date index, >>> the x-axis of the plot does _not_ show any date format for weekly or >>> hourly data. For other frequencies, things are fine. >> >> I agree it would be nice to also display that information in the graphs. > > Well-tested patches would be reviewed with interest. Otherwise, I'm > afraid this is not a priority for me. [moving this to devel] This is perfectly fine, we know you are constantly working hard on many aspects of gretl. I have started experimenting with the sample label printing business in the branch "samplelabel" branch on git. Certainly very far from being well tested (actually already with a known bug where I haven't pushed the fix yet, but will in a minute). This is not exactly the same thing as date label printing in plots, but similar I think. When looking at the code, I see the function 'ntodate' (in lib/src/dataio.c) which nowadays is a little misleading I'd say, because it is also used to construct the label for a panel observation (which includes the unit, not just a date). So my proposal would be to adjust that name eventually - of course this means a lot of changes to all the calls, but with grep and search and replace this shouldn't be a big problem. Or is there anything I'm missing?

And a question: AFAICS dset->panel_pd is the time-series frequency within a panel dataset. (So playing the role of dset->pd in a time-series dataset, but dset->pd is the overall time dimension length in the panel context, cf. also the hansl accessor $pd -- I've always found that confusing! So what actually is the hansl way to retrieve the information about the time series frequency in a panel, after it has been set with --set-panel-time??) My question: does this panel_pd always exist in a panel, or only conditionally on the user action of setting it?

> I don't think you're missing anything. Renaming that function might be > helpful -- maybe as ntolabel or similar? ntolabel sounds good. (Or ntoobslabel?)

Am 29.08.2020 um 19:45 schrieb Riccardo (Jack) Lucchetti: > On Tue, 25 Aug 2020, Sven Schreiber wrote: > >>> I don't think you're missing anything. Renaming that function might be >>> helpful -- maybe as ntolabel or similar? >> >> ntolabel sounds good. (Or ntoobslabel?) > > I vote for ntolabel. OK, shall I go ahead? After grepping it seems to be a pretty easy case of mass search-and-replace. (Apparently 172 times.) This includes a function variant ntodate_8601 used in conjunction with csv imports apparently, where I would propose to also just rename that to ntolabel_8601.

Am 07.09.2020 um 21:20 schrieb Allin Cottrell: > On Mon, 7 Sep 2020, Sven Schreiber wrote: > >> >> OK, shall I go ahead? After grepping it seems to be a pretty easy case >> of mass search-and-replace. (Apparently 172 times.) >> >> This includes a function variant ntodate_8601 used in conjunction with >> csv imports apparently, where I would propose to also just rename that >> to ntolabel_8601. > > I don't mean to act like an over-anxious "parent" (though maybe that's > what I'm doing!), but would you mind branching first, then test that > things still work (though of course they should) before putting this > change into master? This would also be my preferred course of action! I see I'm slowly pulling you into the branching camp...

Am 08.09.20 um 19:17 schrieb Sven Schreiber: > Am 07.09.2020 um 21:34 schrieb Sven Schreiber: >> Am 07.09.2020 um 21:20 schrieb Allin Cottrell: >>> On Mon, 7 Sep 2020, Sven Schreiber wrote: >>> >>>> >>>> This includes a function variant ntodate_8601 used in conjunction with >>>> csv imports apparently, where I would propose to also just rename that >>>> to ntolabel_8601. >>> > OK, there's a new branch "ntolabel" for that. I used the rpl tool under > Debian with the following command: > > rpl -R -x .c -x .h ntodate ntolabel * > > That is, only C source and header files are changed. The branch seems to > compile OK after this change. Right now I cannot test the GUI, however. > So some more testing surely needed before merging. > OK I've tested the gretl GUI compiled from this branch. Basic stuff works as usual, including sample restrictions. What do I need to do in order to test (implicitly) the mentioned function ntolabel_8601? I guess just importing a csv file wouldn't be enough?

Am 09.09.2020 um 01:16 schrieb Cottrell, Allin: > On Tue, Sep 8, 2020 at 5:05 PM Sven Schreiber <svetosch(a)gmx.net&gt; wrote:

> I think you're fine at this point, Sven. If anything bad were going to > happen it could really only be collateral damage in case rpl didn't > work quite as it was supposed to. And I reckon that would be apparent > by now. Right, I merged these changes into master and pushed it to the repo. Bye-bye ntodate. In principle the branch "ntolabel" can be deleted now, but I haven't done that yet.