[Edbrowse-dev] edbrowse and edbrowse-js not communicating

[Edbrowse-dev] edbrowse and edbrowse-js not communicating

[Chuck Hallenbeck]

Hi all,

Just reconnected here after long absence.  Also just installed 3.6.0 on
my archlinux system, all libraries in and versions good, both edbrowse
and edbrowse-js compiled and a symlink between e and edbrowse. But
javascript fails everywhere I tried it.  Here is a simple example:


Script started on Mon 14 Dec 2015 07:46:02 AM EST
[user ~]$ e www.amazon.com
25541
342
/<>
/<>
Search <> <Go>
i1=black jelly beans
i1=black jelly beans
Search <black jelly beans> <Go>
db2
db2
i*
i*
* http://www.amazon.com/gp/aw/s/ref=is_box_
submitting form
375999
5375
edbrowse-js: config.c:386: prvTidySetOptionInt: Assertion `option_defs[ optId ].type == TidyInteger' failed.
Unable to communicate with edbrowse-js, javascript is closed.
Javascript engine has failed; all current javascript sessions have been closed.
q
q
Script done on Mon 14 Dec 2015 07:49:11 AM EST

What have I overlooked? What other info is needed?
Will the latest snapshot fix it?

Chuck

Re: [Edbrowse-dev] edbrowse and edbrowse-js not communicating

[Chris Brannon]

Hi Chuck,
I think I know exactly what is wrong.
You installed the tidyhtml package.
Instead, you need tidy-html5.  It is maintained (whereas the old
tidy-1.x code is not), and it is a drop-in replacement.
You should get tidy-html5 from the AUR.
You could install tidy-html5-git instead, if you want a more up-to-date
version than their tagged release.

-- Chris

[Edbrowse-dev] edbrowse and edbrowse-js not communicating

[Karl Dahlke]

I fear there will be a lot of confusion in this regard
for quite some time, and I wonder,
is it possible to have edbrowse check at run time
whether it has the correct and latest tidy, and issue a warning message if it does not?
We did this with curl for a time,
when we just had to have the latest or edbrowse wouldn't run.
See main.c line 1042.
I don't think there is anything quite this convenient for tidy though.

Karl Dahlke

Re: [Edbrowse-dev] edbrowse and edbrowse-js not communicating

[Chris Brannon]

Karl Dahlke <eklhad@comcast.net> writes:

> is it possible to have edbrowse check at run time
> whether it has the correct and latest tidy, and issue a warning message if it does not?

Here's the problem.
The old tidy code defined tidyReleaseDate.
tidy-html5 defines tidyLibraryVersion and tidyReleaseDate, but they
claim that tidyReleaseDate is deprecated.  So I don't know how long that
will be available.
For now, tidy-html5 is a drop-in replacement for the original tidy, so I
suppose I could look at tidyReleaseDate to determine whether we're using
old tidy code.
A better solution would be to check at build time.
That's quite doable with cmake, and I'm starting to get a handle on how
to use it, so maybe that's the way to go.

That begs a question.  At some point, should we consider deprecating all
of our makefiles?

-- Chris

Re: [Edbrowse-dev] edbrowse and edbrowse-js not communicating

[Adam Thompson]

[-- Attachment #1: Type: text/plain, Size: 1423 bytes --]

On Mon, Dec 14, 2015 at 08:55:26PM -0800, Chris Brannon wrote:
> Karl Dahlke <eklhad@comcast.net> writes:
> 
> > is it possible to have edbrowse check at run time
> > whether it has the correct and latest tidy, and issue a warning message if it does not?
> 
> Here's the problem.
> The old tidy code defined tidyReleaseDate.
> tidy-html5 defines tidyLibraryVersion and tidyReleaseDate, but they
> claim that tidyReleaseDate is deprecated.  So I don't know how long that
> will be available.
> For now, tidy-html5 is a drop-in replacement for the original tidy, so I
> suppose I could look at tidyReleaseDate to determine whether we're using
> old tidy code.
> A better solution would be to check at build time.
> That's quite doable with cmake, and I'm starting to get a handle on how
> to use it, so maybe that's the way to go.

Definitely, otherwise we leave ourselves open to all sorts of strangeness in the future.

> That begs a question.  At some point, should we consider deprecating all
> of our makefiles?

I was actually planning to send an email asking this,
particularly as I've now been successfully building with cmake on a bunch of
Debian machines. On the subject of cmake,
is there any chance we could add an install (and even uninstall)
rule just to make everything a bit more standard and in case we ever need to
compile parts of the code as shared objects?

Cheers,
Adam.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Edbrowse-dev] edbrowse and edbrowse-js not communicating

[Chris Brannon]

Adam Thompson <arthompson1990@gmail.com> writes:

> Definitely, otherwise we leave ourselves open to all sorts of strangeness in the future.

Well unfortunately checking for Tidy versions is going to be a smidge
more involved than I'd like.  Basically at compile time, we can
trivially determine whether we're trying to link against tidy or
tidy-html5, refusing to link against old tidy.
But then we also have to do a runtime check, to make sure that we have a
recent enough tidy-html5.

>> That begs a question.  At some point, should we consider deprecating all
>> of our makefiles?

> I was actually planning to send an email asking this,

Yes, it works quite well, doesn't it?
I've always been a bit fond of our single makefile approach, but cmake
is so much better for the cross-platform stuff.
If we keep the makefiles around, our biggest concern will be
guaranteeing that they never get out of sync with cmake.

> is there any chance we could add an install (and even uninstall)
> rule just to make everything a bit more standard and in case we ever need to
> compile parts of the code as shared objects?

Sure.  I added the install rule tonight.
It's too bad that cmake doesn't give you an uninstall rule "for free",
but they describe how to craft one in their FAQ.  I'll be happy to add
it if you like.

-- Chris

Re: [Edbrowse-dev] edbrowse and edbrowse-js not communicating

[Adam Thompson]

[-- Attachment #1: Type: text/plain, Size: 1973 bytes --]

On Thu, Dec 17, 2015 at 02:44:19AM -0800, Chris Brannon wrote:
> Adam Thompson <arthompson1990@gmail.com> writes:
> 
> > Definitely, otherwise we leave ourselves open to all sorts of strangeness in the future.
> 
> Well unfortunately checking for Tidy versions is going to be a smidge
> more involved than I'd like.  Basically at compile time, we can
> trivially determine whether we're trying to link against tidy or
> tidy-html5, refusing to link against old tidy.
> But then we also have to do a runtime check, to make sure that we have a
> recent enough tidy-html5.

Ok, that makes sense, though I'm surprised we can't check at configure time if
the version of tidy defines the symbols (and macros) we expect.
I know autotools can do this and I'm sure I've seen someone do something like
this with cmake before now.

> >> That begs a question.  At some point, should we consider deprecating all
> >> of our makefiles?
> 
> > I was actually planning to send an email asking this,
> 
> Yes, it works quite well, doesn't it?
> I've always been a bit fond of our single makefile approach, but cmake
> is so much better for the cross-platform stuff.
> If we keep the makefiles around, our biggest concern will be
> guaranteeing that they never get out of sync with cmake.

I personally like makefiles but they're no use for compiling with native Windows tools (i.e. not MinGW etc).
Cmake does all this stuff for us and appears to work well.

> > is there any chance we could add an install (and even uninstall)
> > rule just to make everything a bit more standard and in case we ever need to
> > compile parts of the code as shared objects?
> 
> Sure.  I added the install rule tonight.

Thanks.

> It's too bad that cmake doesn't give you an uninstall rule "for free",
> but they describe how to craft one in their FAQ.  I'll be happy to add
> it if you like.

If it's not too much work then yes please add it.

Cheers,
Adam.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Edbrowse-dev] edbrowse and edbrowse-js not communicating

[Chris Brannon]

Adam Thompson <arthompson1990@gmail.com> writes:

> Ok, that makes sense, though I'm surprised we can't check at configure time if
> the version of tidy defines the symbols (and macros) we expect.


Sure, we can check for symbols.  If the library defines
tidyLibraryVersion, it is tidy-html5.  If it doesn't, then it's some ancient
version of tidy, so throw up our hands and refuse to proceed.
What we won't know  without building and running an executable is the
version number of tidy-html5.
Really, we don't know the actual version until runtime.  I can build a
program under version 5.1.x and then run it under 5.1.y, just fine,
assuming the public API hasn't changed between x and y.
Hence we should probably do both a compile-time and run-time check.
Compile-time tells us whether we have tidy-html5 or tidy, run0-time
tells us more specifically which version of tidy-html5 we have.

-- Chris