[edbrowse-dev] tidySetOptBool vs tidySetOptInt on debian

[edbrowse-dev] tidySetOptBool vs tidySetOptInt on debian

[Adam Thompson]

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.

Re: [edbrowse-dev] tidySetOptBool vs tidySetOptInt on debian

[Dominique Martinet]

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

Re: [edbrowse-dev] tidySetOptBool vs tidySetOptInt on debian

[Alfonso S. Siciliano]

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>

Re: [edbrowse-dev] tidySetOptBool vs tidySetOptInt on debian

[Dominique Martinet]

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

Re: [edbrowse-dev] tidySetOptBool vs tidySetOptInt on debian

[Adam Thompson]

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).

Re: [edbrowse-dev] tidySetOptBool vs tidySetOptInt on debian

[alf.siciliano]

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>

Re: [edbrowse-dev] tidySetOptBool vs tidySetOptInt on debian

[Dominique Martinet]

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

Re: [edbrowse-dev] tidySetOptBool vs tidySetOptInt on debian

[Geoff McLane]

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

[edbrowse-dev] tidySetOptBool vs tidySetOptInt on debian

[Karl Dahlke]

[-- 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

Re: [edbrowse-dev] tidySetOptBool vs tidySetOptInt on debian

[Alfonso Sabato Siciliano]

[-- 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 --]

Re: [edbrowse-dev] tidySetOptBool vs tidySetOptInt on debian

[Dominique Martinet]

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

Re: [edbrowse-dev] tidySetOptBool vs tidySetOptInt on debian

[Adam Thompson]

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.

Re: [edbrowse-dev] tidySetOptBool vs tidySetOptInt on debian

[Geoff McLane]

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.

Re: [edbrowse-dev] tidySetOptBool vs tidySetOptInt on debian

[Adam Thompson]

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.