[Edbrowse-dev] Now on 24

[Edbrowse-dev] Now on 24

[Karl Dahlke]

I downloaded moz 24, and am following the master branch for edbrowse.
I built everything, ran jsrt ok,
and am using edbrowse now to write and send this email.

I pushed a commit that changes several files, but all docs,
trying to bring that up to date with what we're doing.
Mostly README which was way out of date.
Also gave credit to Adam for his work in our usersguide.html,
but if you would rather have your privacy I will happily delete the reference.
My default is to give people the credit they are due.

With three of us accessing the main branch we need to coordinate.

One chunk of work is to clean up html.cpp,
use string objects where it makes sense,
like anywhere you see stringAndString or stringAndChar etc
all that mess is easier with strings,
and use the array class instead of my lists so all those warnings go away.
I could do this, unless someone else is in there anyways
and wants to take it on.

Tracking down more js bugs, probably best left to you.
Why for instance would a js object call ever return null?
Can't believe we're out of memory.

Then there is the question of substituting in longer lines,
or allowing for more lines.
This one probably best left to me, as I am more familiar with buffers.c.

Then there's lots of new features and enhancements to do, as we discussed,
but probably we should get this stuff stable first,
make a new version, then move on to other things.

What do you think?

Karl Dahlke

Re: [Edbrowse-dev] Now on 24

[Adam Thompson]

On Wed, Jan 29, 2014 at 01:49:18PM -0500, Karl Dahlke wrote:
> I downloaded moz 24, and am following the master branch for edbrowse.
> I built everything, ran jsrt ok,
> and am using edbrowse now to write and send this email.

Good to hear. On the subject of jsrt,
not sure if this still happens now we have html.cpp,
but there was a really awkward to reproduce segfault with jsrt.
I think it basically involved filling in the form,
submitting it with the various submit buttons then pressing reset.
I also ran all the other tests before doing this.
It doesn't always happen so I've not been able to work out what's exploding.
As I said, since html.cpp I've not been able to reproduce it,
but my reproduction rate before was hardly reliable anyway.
Also, any idea how to make jsrt work the gc rooting stuff even more?

> I pushed a commit that changes several files, but all docs,
> trying to bring that up to date with what we're doing.
> Mostly README which was way out of date.
> Also gave credit to Adam for his work in our usersguide.html,
> but if you would rather have your privacy I will happily delete the reference.

Giving me credit is fine.  Thanks.
> With three of us accessing the main branch we need to coordinate.
> 
> One chunk of work is to clean up html.cpp,
> use string objects where it makes sense,
> like anywhere you see stringAndString or stringAndChar etc
> all that mess is easier with strings,
> and use the array class instead of my lists so all those warnings go away.
> I could do this, unless someone else is in there anyways
> and wants to take it on.

I don't know who's best to do this. I guess probably you or Chris since you
know more about the code already, however I can take this on if you like.

> Tracking down more js bugs, probably best left to you.
> Why for instance would a js object call ever return null?
> Can't believe we're out of memory.

Hmmm, really not sure. I guess we need to check most of these and then we'll
actually be able to exit when this happens rather than segfault at some later 
point.

> Then there is the question of substituting in longer lines,
> or allowing for more lines.
> This one probably best left to me, as I am more familiar with buffers.c.

Agreed.

> Then there's lots of new features and enhancements to do, as we discussed,
> but probably we should get this stuff stable first,
> make a new version, then move on to other things.
Yeah definitely. We need to get this done and stable for the next debian version.

Cheers,
Adam.

Re: [Edbrowse-dev] Now on 24

[Chris Brannon]

> use string objects where it makes sense,
> and use the array class instead of my lists so all those warnings go away.
> I could do this, unless someone else is in there anyways

Swapping your lists for C++ lists should be a five-minute job, but the
string stuff is going to be tedious.  I'm also willing to do it if you
aren't too enthused at the prospect.

-- Chris