* [edbrowse-dev] tidySetOptBool vs tidySetOptInt on debian @ 2019-12-07 17:15 Adam Thompson 2019-12-07 18:43 ` Dominique Martinet 0 siblings, 1 reply; 14+ messages in thread From: Adam Thompson @ 2019-12-07 17:15 UTC (permalink / raw) To: edbrowse-dev Hi all, Just recompiled the latest edbrowse against the versions of tidy-html5 and duktape available in Debian sid. In order to get it to run I had to change the call on html-tidy.c:129 from: tidyOptSetBool(tdoc, TidyStyleTags, no); to: tidyOptSetInt(tdoc, TidyStyleTags, no); As otherwise the browser aborts at runtime with an assertion error that the option isn't a bool. I'm not sure if this is a new change in the tidy lib or a Debian-specific patch and, more importantly, how to fix this so it "just works" for everyone. I guess an ifdef is needed but I'm not sure against what? Cheers, Adam. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [edbrowse-dev] tidySetOptBool vs tidySetOptInt on debian 2019-12-07 17:15 [edbrowse-dev] tidySetOptBool vs tidySetOptInt on debian Adam Thompson @ 2019-12-07 18:43 ` Dominique Martinet 2019-12-07 19:01 ` Alfonso S. Siciliano 0 siblings, 1 reply; 14+ messages in thread From: Dominique Martinet @ 2019-12-07 18:43 UTC (permalink / raw) To: Adam Thompson; +Cc: edbrowse-dev Hi, Adam Thompson wrote on Sat, Dec 07, 2019: > Just recompiled the latest edbrowse against the versions of tidy-html5 and > duktape available in Debian sid. In order to get it to run I had to change > the call on html-tidy.c:129 from: > tidyOptSetBool(tdoc, TidyStyleTags, no); > > to: > tidyOptSetInt(tdoc, TidyStyleTags, no); > > As otherwise the browser aborts at runtime with an assertion error that the > option isn't a bool. That is surpising, I just checked Tidy code and 'TidyStyleTags' is a bool no matter how I look at it, including in debian sid sources and the latest git. I don't know what can be done for that... I'll try to reproduce tonight -- Dominique ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [edbrowse-dev] tidySetOptBool vs tidySetOptInt on debian 2019-12-07 18:43 ` Dominique Martinet @ 2019-12-07 19:01 ` Alfonso S. Siciliano 2019-12-07 19:34 ` Dominique Martinet 2019-12-07 19:44 ` Adam Thompson 0 siblings, 2 replies; 14+ messages in thread From: Alfonso S. Siciliano @ 2019-12-07 19:01 UTC (permalink / raw) To: Dominique Martinet; +Cc: Adam Thompson, edbrowse-dev Hi all, 2 day ago I had the same problem with FreeBSD, the problem was the version of tidy-html5, the discussion and fix is: https://github.com/CMB/edbrowse/issues/53 Anyway, now I' m using debian SID, it seems to run, the version of the library is: libtidy.so.5deb1.6.0 On Sat, 7 Dec 2019 19:43:54 +0100 Dominique Martinet <asmadeus@codewreck.org> wrote: > Hi, > > Adam Thompson wrote on Sat, Dec 07, 2019: > > Just recompiled the latest edbrowse against the versions of tidy-html5 and > > duktape available in Debian sid. In order to get it to run I had to change > > the call on html-tidy.c:129 from: > > tidyOptSetBool(tdoc, TidyStyleTags, no); > > > > to: > > tidyOptSetInt(tdoc, TidyStyleTags, no); > > > > As otherwise the browser aborts at runtime with an assertion error that the > > option isn't a bool. > > That is surpising, I just checked Tidy code and 'TidyStyleTags' is a > bool no matter how I look at it, including in debian sid sources and the > latest git. > > I don't know what can be done for that... I'll try to reproduce tonight > > -- > Dominique > --- Alfonso S. Siciliano <alf.siciliano@gmail.com> ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [edbrowse-dev] tidySetOptBool vs tidySetOptInt on debian 2019-12-07 19:01 ` Alfonso S. Siciliano @ 2019-12-07 19:34 ` Dominique Martinet 2019-12-07 19:49 ` Adam Thompson 2019-12-07 19:44 ` Adam Thompson 1 sibling, 1 reply; 14+ messages in thread From: Dominique Martinet @ 2019-12-07 19:34 UTC (permalink / raw) To: Adam Thompson, edbrowse-dev Alfonso S. Siciliano wrote on Sat, Dec 07, 2019: > 2 day ago I had the same problem with FreeBSD, the problem was the version of > tidy-html5, the discussion and fix is: > > https://github.com/CMB/edbrowse/issues/53 Ah, yeah, if edbrowse compiled with headers from tidy-html5 but linked against tidy 0.99 it can't work... Adam, can you confirm it's the same thing? What does `dpkg -l | grep tidy` list? -- Dominique ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [edbrowse-dev] tidySetOptBool vs tidySetOptInt on debian 2019-12-07 19:34 ` Dominique Martinet @ 2019-12-07 19:49 ` Adam Thompson 2019-12-07 21:45 ` alf.siciliano 0 siblings, 1 reply; 14+ messages in thread From: Adam Thompson @ 2019-12-07 19:49 UTC (permalink / raw) To: Dominique Martinet; +Cc: edbrowse-dev On Sat, Dec 07, 2019 at 08:34:33PM +0100, Dominique Martinet wrote: > Alfonso S. Siciliano wrote on Sat, Dec 07, 2019: > > 2 day ago I had the same problem with FreeBSD, the problem was the version of > > tidy-html5, the discussion and fix is: > > > > https://github.com/CMB/edbrowse/issues/53 > > Ah, yeah, if edbrowse compiled with headers from tidy-html5 but linked > against tidy 0.99 it can't work... > > Adam, can you confirm it's the same thing? What does `dpkg -l | grep tidy` list? It's the same issue but that analysis in the link doesn't match the error in the assertion (also in the linked issue) unless I'm missing something. Anyway: dpkg -l | grep tidy ii libtidy-dev:amd64 2:5.6.0-10 amd64 HTML/XML syntax checker and reformatter - development ii libtidy5deb1:amd64 2:5.6.0-10 amd64 HTML/XML syntax checker and reformatter - shared library So no weird linkage on my side. I wonder if tidySetOptInt also fixes the FreeBSD port as it's fixed my version (and yes I've compiled and tested this on Debian)? What I'm not sure about is if that causes other versions of the library to blow up (and unfortunately don't have any to hand right now to test). ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [edbrowse-dev] tidySetOptBool vs tidySetOptInt on debian 2019-12-07 19:49 ` Adam Thompson @ 2019-12-07 21:45 ` alf.siciliano 2019-12-07 22:16 ` Dominique Martinet 0 siblings, 1 reply; 14+ messages in thread From: alf.siciliano @ 2019-12-07 21:45 UTC (permalink / raw) To: edbrowse-dev On Sat, 7 Dec 2019 19:49:28 +0000 Adam Thompson <arthompson1990@gmail.com> wrote: > Anyway: > dpkg -l | grep tidy > ii libtidy-dev:amd64 2:5.6.0-10 amd64 HTML/XML syntax checker and > reformatter - development > ii libtidy5deb1:amd64 2:5.6.0-10 amd64 HTML/XML syntax checker and > reformatter - shared library > > So no weird linkage on my side. I wonder if tidySetOptInt also fixes the > FreeBSD port as it's fixed my version (and yes I've compiled and tested this > on Debian)? What I'm not sure about is if that causes other versions of the > library to blow up (and unfortunately don't have any to hand right now to > test). > On debian we have the same version of libtidy, but debian sid hasn't the last version of edbrowse, so I' m using the old 3.7.5.1-1, if you have compiled the last version we are tring a different version. Anyway, on FreeBSD, I have the last version release 3.7.6 (and git master), if I change from tidyOptSetBool(tdoc, TidyStyleTags, no); to tidyOptSetInt(tdoc, TidyStyleTags, no); the runtime output is: ./edbrowse .ebrc: unrecognized keyword linelength at line 49 edbrowse ready b www.google.com 12613 Assertion failed: (option_defs[ optId ].type == TidyInteger), function prvTidySetOptionInt, file /usr/ports/www/tidy-html5/work/tidy-html5-5.7.28/src/config.c, line 487. Abort (core dumped) it seems freebsd current has a newer tidy-html6 (5.7.28) than debian sid (5.6.0), too. Alfonso --- alf.siciliano@gmail.com <alf.siciliano@gmail.com> ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [edbrowse-dev] tidySetOptBool vs tidySetOptInt on debian 2019-12-07 21:45 ` alf.siciliano @ 2019-12-07 22:16 ` Dominique Martinet 2019-12-08 2:29 ` Geoff McLane 0 siblings, 1 reply; 14+ messages in thread From: Dominique Martinet @ 2019-12-07 22:16 UTC (permalink / raw) To: alf.siciliano; +Cc: edbrowse-dev alf.siciliano@gmail.com wrote on Sat, Dec 07, 2019: > On debian we have the same version of libtidy, but debian sid hasn't the last > version of edbrowse, so I' m using the old 3.7.5.1-1, if you have compiled > the last version we are tring a different version. > > Anyway, on FreeBSD, I have the last version release 3.7.6 (and git master), > if I change > from > tidyOptSetBool(tdoc, TidyStyleTags, no); > to > tidyOptSetInt(tdoc, TidyStyleTags, no); > > the runtime output is: > > ./edbrowse > .ebrc: unrecognized keyword linelength at line 49 > edbrowse ready > b www.google.com > 12613 > Assertion failed: (option_defs[ optId ].type == TidyInteger), function prvTidySetOptionInt, file /usr/ports/www/tidy-html5/work/tidy-html5-5.7.28/src/config.c, line 487. > Abort (core dumped) TidyStyleTags is a bool, no matter how you look at it, trying to change it to int without understanding what we are doing is not going to help. I tried rebuilding edbrowse on a debian sid and it works fine here, I think he either had old build artefact built with previous tidy version linked with a newer version -- tidy reordered the fields of the enum so the values will have changed. I think it is unrelated to the problem you had on FreeBSD anyway, as he says there is no libtidy-0.99 on his system. -- Dominique ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [edbrowse-dev] tidySetOptBool vs tidySetOptInt on debian 2019-12-07 22:16 ` Dominique Martinet @ 2019-12-08 2:29 ` Geoff McLane 2019-12-08 3:56 ` Karl Dahlke ` (2 more replies) 0 siblings, 3 replies; 14+ messages in thread From: Geoff McLane @ 2019-12-08 2:29 UTC (permalink / raw) To: Dominique Martinet, alf.siciliano; +Cc: edbrowse-dev Hi all, So sorry for the role 'libTidy' plays in this... Since it was introduced, circa 2017, the option 'TidyStyleTags' is a boolean... ie use 'tidyOptSetBool'... No change is allowed... even if it works... no ifdef whatever... since commit [1]... full stop... When linking, the installed version of tidy, through 'FindTidy.cmake', when found, and used, it is of paramount importance, that the installed 'lbtidy-dev', namely the headers, are of the /SAME/ version... That is the tidy.h, which includes tidyenum.h, are of the /SAME/ version as the shared library found... not very easy to determine... Else there will be 'assert' problems in the non-release build, and unknown, untold, unseen, problems otherwise... Now specific os distributions muddy the water... and the 'tidy' cmake build of 'libTidy' is very flexible... so you get differences... Like I am very alarmed by the 'findTidy.cmake' change - ``` set(TIDY_NAMES tidy) if (${CMAKE_SYSTEM_NAME} STREQUAL "FreeBSD") set(TIDY_NAMES tidy5) endif () ``` Ugh, a library name change! But the cmake build allows it, for distros... and IF the installed 'tidy.h' agree, ie are the same version... then why not... So we have to look, case by case, at these failures... How can I help? Usually, need more information... The results from - ``` $ ldd edbrowse | grep tidy ``` can help... of course that link usually needs to be traced back to its source... and then to the installed 'tidy.h' public headers... And especially in the cases where `find /usr/include -name tidy.h` yields things like - ``` /usr/include/tidy/tidy.h /usr/include/tidy.h ``` What is installed = ``` $ dpkg -l | grep tidy ``` can also help... but can be /very/ misleading... if you have built, and installed, the current tidy from source... Each problem has a solution... but usually /NOT/ from altering the source code... Just hope this helps... At the moment, my os windows build fails on 'main.c:140 - if (ti == pthead_self())`, since you can not compare structures in that way... but maybe this is just windows specific... but the docs suggest if (pthread_equal(t1, t2)) ... Regards, Geoff. [1] https://github.com/htacg/tidy-html5/commit/50859e82583c383a866e76a4289f601352c335b7 ^ permalink raw reply [flat|nested] 14+ messages in thread
* [edbrowse-dev] tidySetOptBool vs tidySetOptInt on debian 2019-12-08 2:29 ` Geoff McLane @ 2019-12-08 3:56 ` Karl Dahlke 2019-12-08 8:08 ` Alfonso Sabato Siciliano 2019-12-08 8:07 ` Dominique Martinet 2019-12-08 13:22 ` Adam Thompson 2 siblings, 1 reply; 14+ messages in thread From: Karl Dahlke @ 2019-12-08 3:56 UTC (permalink / raw) To: edbrowse-dev, alf.siciliano [-- Attachment #1: Type: text/plain, Size: 1232 bytes --] Hi folks, Writing software for various systems and platforms is challenging, but tidy has done it, duktape has done it, and I'm sure we can too. I'm 99% sure the recent tidy comfusion is incompatibility between headers and linked in library. This is sometimes caused by distros that already have tidy, but an older version, so a packager brings in a new version and builds and that's fine but then there are two such libraries, if he doesn't remove the old one, and one can glom on to the old library, and just anything can happen after that. > I am very alarmed by the 'findTidy.cmake' change - I can remove these lines if you wish, I am the arbiter, is there another approach that might work better for these bsd folks? I will mostly stay out of the middle of this one and you can collectively advise me. One thing we recommend is when you must bring in a newer tidy to build edbrowse you *have* to delete the old one and make the new one the only tidy in the distro, then of course that will be the only one cmake can find and there shouldn't be trouble. It is clear that the thread type is suppose to be opaque, and accessed only through api, so I changed to pthread_equal as you suggest. Karl Dahlke ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [edbrowse-dev] tidySetOptBool vs tidySetOptInt on debian 2019-12-08 3:56 ` Karl Dahlke @ 2019-12-08 8:08 ` Alfonso Sabato Siciliano 0 siblings, 0 replies; 14+ messages in thread From: Alfonso Sabato Siciliano @ 2019-12-08 8:08 UTC (permalink / raw) To: Karl Dahlke; +Cc: edbrowse-dev [-- Attachment #1: Type: text/plain, Size: 715 bytes --] Now it's obvious: my problem (and solution) with FreeBSD and Adam's problem with debian are different; so FreeBSD is off-topc here. Anyway I seem if (${CMAKE_SYSTEM_NAME} STREQUAL "FreeBSD") set(TIDY_NAMES tidy5) is a normal solution when an OS manages some different version of a library renaming it. In this specific case, it fixes incompatibility between headers and linked library. Properly: /usr/local/include/tidy/tidy.h and tidy.so are libtidy.0.99 (www/tidy-lib port) while the right is /usr/local/include/tidy.h and tidy5.so (www/tidy-html5 port) cmake finds the correct tidy.h but it cannot find the right ".so" without: set(TIDY_NAMES tidy5), of course a better solution is welcome. Alfonso [-- Attachment #2: Type: text/html, Size: 883 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [edbrowse-dev] tidySetOptBool vs tidySetOptInt on debian 2019-12-08 2:29 ` Geoff McLane 2019-12-08 3:56 ` Karl Dahlke @ 2019-12-08 8:07 ` Dominique Martinet 2019-12-08 13:22 ` Adam Thompson 2 siblings, 0 replies; 14+ messages in thread From: Dominique Martinet @ 2019-12-08 8:07 UTC (permalink / raw) To: Geoff McLane; +Cc: edbrowse-dev Geoff McLane wrote on Sun, Dec 08, 2019: > At the moment, my os windows build fails on 'main.c:140 - if (ti == > pthead_self())`, since you can not compare structures in that > way... but maybe this is just windows specific... but the docs > suggest if (pthread_equal(t1, t2)) ... Sorry for that one, since pthread_t is an int on linux I didn't notice. Agreed `if (pthread_equal(t1, pthread_self()))` is the proper way of doing it -- Dominique ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [edbrowse-dev] tidySetOptBool vs tidySetOptInt on debian 2019-12-08 2:29 ` Geoff McLane 2019-12-08 3:56 ` Karl Dahlke 2019-12-08 8:07 ` Dominique Martinet @ 2019-12-08 13:22 ` Adam Thompson 2019-12-08 21:22 ` Geoff McLane 2 siblings, 1 reply; 14+ messages in thread From: Adam Thompson @ 2019-12-08 13:22 UTC (permalink / raw) To: Geoff McLane; +Cc: Dominique Martinet, alf.siciliano, edbrowse-dev On Sun, Dec 08, 2019 at 03:29:04AM +0100, Geoff McLane wrote: > So sorry for the role 'libTidy' plays in this... > > Since it was introduced, circa 2017, the option 'TidyStyleTags' is a > boolean... ie use 'tidyOptSetBool'... No change is allowed... even if it > works... no ifdef whatever... since commit [1]... full stop... That's what I thought which is why this was so odd. > When linking, the installed version of tidy, through 'FindTidy.cmake', when > found, and used, it is of paramount importance, that the installed > 'lbtidy-dev', namely the headers, are of the /SAME/ version... > > That is the tidy.h, which includes tidyenum.h, are of the /SAME/ version as > the shared library found... not very easy to determine... > > Else there will be 'assert' problems in the non-release build, and unknown, > untold, unseen, problems otherwise... Yes... I had a closer look at the state of the system. Turns out that, whereas the library versions appeared to be correct in terms of linking (tidy 5 for both) it was somehow finding headers from a different version of tidy5 compiled from the git repo... Sorry for not noticing the old headers (thought I'd deleted those). I wonder if there's a version/release date in the headers anywhere which can be used, when debugging such issues, to tell such things? To be specific: on debian the tidy5 headers live in /usr/include/tidy whereas the standard install location for compiled tidy5 from git would appear to be /usr/local/include. As another question, why is TidyBodyOnly an option which takes a bool as an argument but tidySetOptInt is used to set it? Cheers, Adam. PS: Appologies again for not noticing the system was in an... odd... state. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [edbrowse-dev] tidySetOptBool vs tidySetOptInt on debian 2019-12-08 13:22 ` Adam Thompson @ 2019-12-08 21:22 ` Geoff McLane 0 siblings, 0 replies; 14+ messages in thread From: Geoff McLane @ 2019-12-08 21:22 UTC (permalink / raw) To: Adam Thompson; +Cc: Dominique Martinet, alf.siciliano, edbrowse-dev Hi, A few things here - 1: Windows compile - the change to using 'pthread_equal' fixed this... thanks... 2: The 'show-body-only', aka 'TidyBodyOnly', is /not/ strictly a boolean otpion, but a special, tidy defined, so called 'autobool' option. This is a tri-state option, which is kept/maintained internally as in integer, 0 (no) TidyNoState, 1 (yes) TidyYesState, 2 (auto) TidyAutoState, so uses 'tidyOptSetInt' to set it... 3: Yes, "Writing software for various systems and platforms is challenging, ...", but not insurmountable... Maybe 'alarmed' by the 'findTidy.cmake' change, is a bad choice of words... for a distro which changed the /name/ of the tidy shared library, maybe very necessary, regretfully... there seems no other solution... if the name is changed... But in the specific as given case, /ONLY/ by shear chance, did it work... By default cmake will search in /usr/include, and I think /usr/local/include, in most cases, but seemingly not always, when searching for the 'tidy.h' header. And the current 'FindTidy.cmake' also allows, if not found in the suffix 'include', to search 'include/tidy' as well... but only if /NOT/ found in 'include'... the order of 'PATH_SUFFIXES' matters... Again, if there was no other conflicting 'libtidy-dev' installed, then this would find /usr/local/include/tidy/tidy.h and libtidy.so => libtidy.0.99 (www/tidy-lib port), and all would be fine... except the current eb/html-tidy.c code would fail to compile, since 'TidyStyleTags' would /NOT/ be found in those old headers... Ideally, when a later 'libtidy-dev' was installed, with /NO/ name change, it would overwrite the libtidy.so link... with something like 'libtidy.so.5.7.28'... then the later 'tidy.h', now in just 'include', would match the libtidy found... and all would again be fine... would compile, link, and run normally... Even if the residual, OLD 'include/tidy/tidy.h', and 'libtidy.so.0.99.0' etc etc were /NOT/ removed... And, unfortunately, there is no version/date in the headers themselves, so identifying and deleting the /OLD/ can be a challenge... of course, $ grep TidyStyleTags tidyenum.h, will tell you if it is pre-2017, or not... I can not speak for what distro maintainer feel they must do... this type of name change has been discussed, at length, in tidy issues, especially for debian... and you will see I strongly felt there should be no name change... this is just the evolution of 'libTidy'... it should just replace the previous... Strongly support - > One thing we recommend is when you must bring in a newer tidy > to build edbrowse you *have* to delete the old one and make > the new one the only tidy in the distro, then of course that > will be the only one cmake can find and there shouldn't be trouble. And, as you can see, library name changing does /NOT/ really solve this... despite accidentally working in the one specific case... HTH Regards, Geoff. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [edbrowse-dev] tidySetOptBool vs tidySetOptInt on debian 2019-12-07 19:01 ` Alfonso S. Siciliano 2019-12-07 19:34 ` Dominique Martinet @ 2019-12-07 19:44 ` Adam Thompson 1 sibling, 0 replies; 14+ messages in thread From: Adam Thompson @ 2019-12-07 19:44 UTC (permalink / raw) To: Alfonso S. Siciliano; +Cc: Dominique Martinet, edbrowse-dev On Sat, Dec 07, 2019 at 08:01:47PM +0100, Alfonso S. Siciliano wrote: > Hi all, > > 2 day ago I had the same problem with FreeBSD, the problem was the version of > tidy-html5, the discussion and fix is: > > https://github.com/CMB/edbrowse/issues/53 > > Anyway, now I' m using debian SID, it seems to run, the version of the library > is: libtidy.so.5deb1.6.0 Yes, I followed that discussion. I'm running with the same version and it definitely needs to be tidySetOptInt for this one. Not sure why or if that breaks on other distros. Apparently, from some research, this looks to be a thing that's happened with other options. I notice the TidyBodyOnly option takes a bool but is SetOptInt as well. From the assertion (and running the code through gdb to find the line which was exploding) it looks like the option setting code performs some assertion that the type of the setter matches the expected type of the option. In the version on Debian that would appear to be int even though it appears to be one of tidy's boolean values which it takes as argument. ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2019-12-08 21:23 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-12-07 17:15 [edbrowse-dev] tidySetOptBool vs tidySetOptInt on debian Adam Thompson 2019-12-07 18:43 ` Dominique Martinet 2019-12-07 19:01 ` Alfonso S. Siciliano 2019-12-07 19:34 ` Dominique Martinet 2019-12-07 19:49 ` Adam Thompson 2019-12-07 21:45 ` alf.siciliano 2019-12-07 22:16 ` Dominique Martinet 2019-12-08 2:29 ` Geoff McLane 2019-12-08 3:56 ` Karl Dahlke 2019-12-08 8:08 ` Alfonso Sabato Siciliano 2019-12-08 8:07 ` Dominique Martinet 2019-12-08 13:22 ` Adam Thompson 2019-12-08 21:22 ` Geoff McLane 2019-12-07 19:44 ` Adam Thompson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).