Re: calendar (1) - patch to correct error description
JFYI: port version 0.7 or the latest sources in CURRENT include a number of further enhancements (and an important fix to allow the calendar to be build on 11.x/12.x which do not have _PATH_LOCALBASE in paths.h). I have added an #undef command (since it was supported by the calendar program that used cpp and since it occurs in one of calendar files that have traditionally been included in FreeBSD) and checks for the correct use of #else and #endif. Warnings and error messages caused by malformed input files are now reported with filename and line number. The man-page and tests have not been updated to reflect this latest set of changes, I'll hope to be able to update them in the next few days. Please let me know if there are any issues with these changes, since I want to merge them to 11-STABLE and 12-STABLE sometime next week. Regards, STefan OpenPGP_signature Description: OpenPGP digital signature
Re: calendar (1) - patch to correct error description
Am 30.10.20 um 00:48 schrieb Julian H. Stacey: Here's another 2 calendar errors, presumably cpp, that manifest in 12.2-STABLE, that 9.2-RELEASE gets right. Man calendar: Empty lines and lines protected by the C commenting syntax (/* ... */) are ignored. --- Input ~/.calendar/calendar friday fish /* * Oct 21 AAA */ friday and chips ---12.2-STABLE output Oct 30* and chips Oct 30 AAA Oct 30* fish Oct 31 AAA ---9.2-RELEASE output Oct 30* and chips Oct 30* fish --- Error 1:Why does it emit AAA ? The version you used does only support /* ... */ on a single line. The "*" in front of "Oct" seems to have been parsed as a wild-card, but I have not checked why it lead to be interpreted as "Oct 30". This is fixed with the comment processing that I have added to the internal pre-processor. Error 2:Why twice ? No idea and I do not consider this relevant now that the issue is fixed. Puzzle: Doesnt happen if you change Oct above to Aug inside the comment. Feel free to solve this puzzle, I really do not have the time to waste on this question ;-) (PS both do a nasty stack unstack, which may look familiar to us programmers, but looks silly to normal peopler, inverting fish & chips) Yes, a linked list that got built-up be putting the new element at the head and the previously added values into the "next" field of that element. Please check the calendar version in -CURRENT or the deskutil/calendar port version 0.6. Both issues should be fixed there. Regards, STefan OpenPGP_signature Description: OpenPGP digital signature
Re: calendar (1) - patch to correct error description
Here's another 2 calendar errors, presumably cpp, that manifest in 12.2-STABLE, that 9.2-RELEASE gets right. Man calendar: Empty lines and lines protected by the C commenting syntax (/* ... */) are ignored. --- Input ~/.calendar/calendar friday fish /* * Oct 21 AAA */ friday and chips ---12.2-STABLE output Oct 30* and chips Oct 30 AAA Oct 30* fish Oct 31 AAA ---9.2-RELEASE output Oct 30* and chips Oct 30* fish --- Error 1:Why does it emit AAA ? Error 2:Why twice ? Puzzle: Doesnt happen if you change Oct above to Aug inside the comment. (PS both do a nasty stack unstack, which may look familiar to us programmers, but looks silly to normal peopler, inverting fish & chips) Cheers, -- Julian Stacey, Consultant Sys. Eng. BSD Linux Unix, http://berklix.com/jhs/cv/ Crash Brexit profits financial speculators in cabinet damaging Britain. UK stole 3.7 million votes from Brits abroad 700 K in EU http://stolenvotes.uk ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: calendar (1) - patch to correct error description
Am 29.10.20 um 13:07 schrieb Diane Bruce: On Thu, Oct 29, 2020 at 01:29:39AM +0100, Julian H. Stacey wrote: Hi Stefan Am 28.10.20 um 13:02 schrieb Julian H. Stacey: man calendar states: "The calendar internal cpp does not correctly do #ifndef and will discard the rest of the file if a #ifndef is triggered." That is wrong, as proved by test file: If I was asked about this I'd suggest ripping out the internal cpp and switching back to an external cpp IFF calendar is all in ports. The idea when the original very hurried hack was done was to remove more from base. No longer a problem if using ports. This is a possibility, but there exists no plan to remove the calendar program from base, currently. I have created the deskutils/calendar port for RELEASE users that want to take advantage of recent changes to the calendar program, but this port exists for only this particular purpose. Piping of the calendar files through CPP leads to other problems, e.g. how to feed error messages from CPP back to the calendar program in a sensible way. I have made the semantics of #define and #if(n)def more similar to that of a CPP, but there still is one major difference: #define COND true #ifdef COND will not get the result you might expect, since "COND true" has been defined and #ifdef COND true will evaluate to true. This is easily changed (I'd use only the first word in #define and reject #ifdef if followed by more than one word), but while being nearer to what CPP would give, it deviates from many years of practice in FreeBSD and might not be allowed to be MFCed. And different semantics in -CURRENT vs. -STABLE are even less acceptable, IMHO. But I'd like to apply such a patch, anyway. There are other changes to the semantics that are possible, e.g. to check that #ifdef/#endif are balanced or that there is no #else outside an #ifdef/#endif range. Implementing such checks is quite simple, given the structure of the code, but I'm not sure that this is required or even a good idea, since it might break current calendar data files that are not really well-formed ... Best regards, STefan ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: calendar (1) - patch to correct error description
On Thu, Oct 29, 2020 at 01:29:39AM +0100, Julian H. Stacey wrote: > Hi Stefan > > Am 28.10.20 um 13:02 schrieb Julian H. Stacey: > > > man calendar states: > > >"The calendar internal cpp does not correctly do #ifndef and will > > > discard > > >the rest of the file if a #ifndef is triggered." > > > That is wrong, as proved by test file: If I was asked about this I'd suggest ripping out the internal cpp and switching back to an external cpp IFF calendar is all in ports. The idea when the original very hurried hack was done was to remove more from base. No longer a problem if using ports. > > > --- > > > // Test data for ~/.calendar/calendar > > > * bla0 ... > > This is not obvious from reading the man-page and it might be more > > intuitive, if the identifier was only the word up to the first blank, > > Yes > > > but the code in the calendar program does just strip off leading and > > trailing white-space. It might be too late to change this behavior. > > Hopefully not too late. > Either way, Ameliorations: > - Do a global edit in manual from "cpp" to "pre-processor" > to remove expectation of similarity to cpp. > - Define in manual exactly how the pre-processor handles defines. > > > > I have updated the code in -CURRENT to support #ifdef (MFC in 3 days) > > Nice > > > > and I plan to add supported for nested conditions in -CURRENT > > Nice > > > > (not > > sure whether that should be merged to -STABLE, though). > > Probably yes ? > > > > I could change the #define and #if/ifndef to only consider the first > > following word, but do not plan to do that at this time. > > Would be good if you did, silently swallowing space seperated text > as extended name of a define instead of value of define, is not > intuitive, At least document if you have no time to change it please ? > > Fixing documenting & extanding a pp in calendar could become like > re-inventing the wheel ? As a cpp is in src/ & not ports, can't > calendar use popen(/usr/bin/cpp) & save work ? Looks like there's > enough work to do in main calendar without extra work of a custom > pre processor ? > > Thanks for copy of your reply to Greg Balfour's off list mail, ref > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205580 > which notes: > "This patch is against 11.4-RELEASE. Note that it requires > the installation of the devel/tradcpp port/package." > > I agree your policy point, FreeBSD can't use a port as dependency > to build calendar, while calendar is still build by src/ world. (& > not just for Free, but Net & Open BSD etc will have similiar views > I presume) Indeed I'd revert back to this. > > I don't know which cpp's from where might have been looked at in the past, > > > Regards, STefan > > Thanks ! > > Cheers, > -- > Julian Stacey, Consultant Sys. Eng. BSD Linux Unix, http://berklix.com/jhs/cv/ > Crash Brexit profits financial speculators in cabinet damaging Britain. > UK stole 3.7 million votes from Brits abroad 700 K in EU http://stolenvotes.uk Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: calendar (1) - patch to correct error description
Hi Stefan > Am 28.10.20 um 13:02 schrieb Julian H. Stacey: > > man calendar states: > >"The calendar internal cpp does not correctly do #ifndef and will discard > >the rest of the file if a #ifndef is triggered." > > That is wrong, as proved by test file: > > --- > > // Test data for ~/.calendar/calendar > > * bla0 > > #ifdef DEBUG1 > > * 28bla1 > > #endif > > #ifdef DEBUG2 > > * 28bla2 > > #endif > > #ifndef DEBUG3 > > * 28bla3 > > #endif > > #define DEBUG4 TRUE > > #ifndef DEBUG4 > > * 28bla4 > > #endif > > * 28bla5 > > --- > > Produces: > > --- > > Oct 28 bla5 > > Oct 28 bla4 > > Oct 28 bla3 > > Oct 28 bla2 > > Oct 28 bla1 > > --- > > Correction: > >The calendar internal cpp ignores directives #ifdef , #ifndef and #endif > > , > >and simply including intervening text regardless. > > Hi Julian, > > no, the calendar program worked as documented, see the BUGS section of > the man-page: > > .Sh BUGS > The > .Nm > internal cpp does not correctly do #ifndef and will discard the rest-of > the file if a #ifndef is triggered.-It also has a maximum of 50 include > file and/or 100 #defines and only recognises #include, #define and > #ifndef. Ah OK, here's 2 test cases ---Ex 1 * 29bla1 #ifndef RAINEY * 29bla4 #endif * 29bla5 --- Ex 2 * 29bla1 #define RAINEY YES #ifndef RAINEY * 29bla4 #endif * 29bla5 --- They both produce: --- Oct 29 bla5 Oct 29 bla4 Oct 29 bla1 --- Where manual misleads with: "internal cpp ... will discard the rest-of the file if a #ifndef is triggered" Triggered or not, that #ifndef to cpp seems not discard rest of file. > There is no mention of #ifdef being supported ... OK, I just assumed that would be supported if #ifndef was. > And your "#ifndef DEBUG4" did not trigger, since the whole line after > #define is used as the identifier, in your case "DEBUG4 TRUE". There lies the problem, Thanks ! Nasty, I dont recall anything called cpp aka C Pre Processor ever being that limited, back to 1983 on a C compiler that ran on CP/M, where masses of other C things were broken. Best that calendar not call it cpp at all, as name misleads. OK, tested with --- * 29bla1 #define RAINEY #ifndef RAINEY * 29bla4 #endif * 29bla5 --- & got --- Oct 29 bla5 Oct 29 bla1 --- & finaly in this special case current manual correctly reports a bug. > This is not obvious from reading the man-page and it might be more > intuitive, if the identifier was only the word up to the first blank, Yes > but the code in the calendar program does just strip off leading and > trailing white-space. It might be too late to change this behavior. Hopefully not too late. Either way, Ameliorations: - Do a global edit in manual from "cpp" to "pre-processor" to remove expectation of similarity to cpp. - Define in manual exactly how the pre-processor handles defines. > I have updated the code in -CURRENT to support #ifdef (MFC in 3 days) Nice > and I plan to add supported for nested conditions in -CURRENT Nice > (not > sure whether that should be merged to -STABLE, though). Probably yes ? > I could change the #define and #if/ifndef to only consider the first > following word, but do not plan to do that at this time. Would be good if you did, silently swallowing space seperated text as extended name of a define instead of value of define, is not intuitive, At least document if you have no time to change it please ? Fixing documenting & extanding a pp in calendar could become like re-inventing the wheel ? As a cpp is in src/ & not ports, can't calendar use popen(/usr/bin/cpp) & save work ? Looks like there's enough work to do in main calendar without extra work of a custom pre processor ? Thanks for copy of your reply to Greg Balfour's off list mail, ref https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205580 which notes: "This patch is against 11.4-RELEASE. Note that it requires the installation of the devel/tradcpp port/package." I agree your policy point, FreeBSD can't use a port as dependency to build calendar, while calendar is still build by src/ world. (& not just for Free, but Net & Open BSD etc will have similiar views I presume) I don't know which cpp's from where might have been looked at in the past, > Regards, STefan Thanks ! Cheers, -- Julian Stacey, Consultant Sys. Eng. BSD Linux Unix, http://berklix.com/jhs/cv/ Crash Brexit profits financial speculators in cabinet damaging Britain. UK stole 3.7 million votes from Brits abroad 700 K in EU http://stolenvotes.uk ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: calendar (1) - patch to correct error description
Am 28.10.20 um 13:02 schrieb Julian H. Stacey: man calendar states: "The calendar internal cpp does not correctly do #ifndef and will discard the rest of the file if a #ifndef is triggered." That is wrong, as proved by test file: --- // Test data for ~/.calendar/calendar * bla0 #ifdef DEBUG1 * 28bla1 #endif #ifdef DEBUG2 * 28bla2 #endif #ifndef DEBUG3 * 28bla3 #endif #define DEBUG4 TRUE #ifndef DEBUG4 * 28bla4 #endif * 28bla5 --- Produces: --- Oct 28 bla5 Oct 28 bla4 Oct 28 bla3 Oct 28 bla2 Oct 28 bla1 --- Correction: The calendar internal cpp ignores directives #ifdef , #ifndef and #endif , and simply including intervening text regardless. Hi Julian, no, the calendar program worked as documented, see the BUGS section of the man-page: .Sh BUGS The .Nm internal cpp does not correctly do #ifndef and will discard the rest-of the file if a #ifndef is triggered.-It also has a maximum of 50 include file and/or 100 #defines and only recognises #include, #define and #ifndef. There is no mention of #ifdef being supported ... And your "#ifndef DEBUG4" did not trigger, since the whole line after #define is used as the identifier, in your case "DEBUG4 TRUE". This is not obvious from reading the man-page and it might be more intuitive, if the identifier was only the word up to the first blank, but the code in the calendar program does just strip off leading and trailing white-space. It might be too late to change this behavior. I have updated the code in -CURRENT to support #ifdef (MFC in 3 days) and I plan to add supported for nested conditions in -CURRENT (not sure whether that should be merged to -STABLE, though). I could change the #define and #if/ifndef to only consider the first following word, but do not plan to do that at this time. Regards, STefan ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
