[Edbrowse-dev] master

[Edbrowse-dev] master

[Karl Dahlke]

Yes I think it would be easier if all this was moved into master,
if Adam then had permission to push into masster, as I do,
if that's ok with you chris, and it's ok with me of course.
A piece of my brain thinks there should be some backward compatibility,
like a flag to makefile to build the old way against 185,
for those who don't have 24 yet,
but then a larger piece of my brain thinks about the linux kernel,
where they really discourage that sort of thing.
Youre just expected to keep up!
Linux has a means of conditional compilation
#if version <= 3.2.7
That kind of thing, but I tell you, you hardly ever see it in the kernel code,
because if you ever started your code would be full of #if versions
maybe all the way back to 2.4, and impossible to read,
so they just tell you generically not to do it.
So I have come to understand the practical point of view of
marching forward, and if you want the latest of this you better get
the latest of that.
Anyways I digress; I think master would be fine,
the only thing we really have to stop nad pause and well test is the threshold
of version 3.4.11.
I think we all have to say yea before we do that.

Karl Dahlke

Re: [Edbrowse-dev] master

[Chris Brannon]

> if Adam then had permission to push into masster, as I do,

I have no problem with that.  He has more than proven his capability to
me.  I would also like to see these changes merged into master, so more
people can test and help us find problems.
Adam, you can now push to the main repository.
Please merge whenever you're ready.

> A piece of my brain thinks there should be some backward compatibility,
> like a flag to makefile to build the old way against 185,

Well, it would require a lot of backward-compatibility code.  Let's not
go there.

> the only thing we really have to stop nad pause and well test is the threshold
> of version 3.4.11.

Right.  In fact, I'd be inclined to bump the minor number: 3.5.0 instead
of 3.4.11.  But we aren't ready for that yet.

-- Chris

Re: [Edbrowse-dev] master

[Adam Thompson]

Sorry didn't see this before replying.
On Tue, Jan 28, 2014 at 08:41:18AM -0800, Chris Brannon wrote:
> > if Adam then had permission to push into masster, as I do,
> 
> I have no problem with that.  He has more than proven his capability to
> me.  I would also like to see these changes merged into master, so more
> people can test and help us find problems.
> Adam, you can now push to the main repository.
> Please merge whenever you're ready.

Thanks, hopefully everything's merged now.

> > the only thing we really have to stop nad pause and well test is the threshold
> > of version 3.4.11.
> 
> Right.  In fact, I'd be inclined to bump the minor number: 3.5.0 instead
> of 3.4.11.  But we aren't ready for that yet.

That's a good point, a library change like this probably should cause a minor 
number bump.

Cheers,
Adam.

Re: [Edbrowse-dev] master

[Adam Thompson]

On Tue, Jan 28, 2014 at 06:20:12AM -0500, Karl Dahlke wrote:
> Yes I think it would be easier if all this was moved into master,
> if Adam then had permission to push into masster, as I do,
> if that's ok with you chris, and it's ok with me of course.

Ok, looks like I've been added.  I guess it's ok if I start pushing changes?

> A piece of my brain thinks there should be some backward compatibility,
> like a flag to makefile to build the old way against 185,
> for those who don't have 24 yet,
> but then a larger piece of my brain thinks about the linux kernel,
> where they really discourage that sort of thing.
> Youre just expected to keep up!
> Linux has a means of conditional compilation
> #if version <= 3.2.7
> That kind of thing, but I tell you, you hardly ever see it in the kernel code,
> because if you ever started your code would be full of #if versions
> maybe all the way back to 2.4, and impossible to read,
> so they just tell you generically not to do it.
> So I have come to understand the practical point of view of
> marching forward, and if you want the latest of this you better get
> the latest of that.
Yeah, I think in this case the changes are too large to sustain any sort of
backward compatibility and it'd just make debugging that bit harder.

> Anyways I digress; I think master would be fine,
> the only thing we really have to stop nad pause and well test is the threshold
> of version 3.4.11.
> I think we all have to say yea before we do that.

Yes, definitely. There're a few bugs I know about and think need squashing
before 3.4.11 happens, but the list is thankfully shrinking slowly.
Do we have some form of issue tracker which works with edbrowse (I'm not sure
how edbrowse-friendly the github setup is)?

On the subject of 3.4.11, apart from the js lib change and other bug fixes,
are there any other features or major changes we want to make before it
happens, or do we want to get out the js update and then start pushing
features etc in the next release?

Cheers,
Adam.

Re: [Edbrowse-dev] master

[Chris Brannon]

Adam Thompson <arthompson1990@gmail.com> writes:

> Do we have some form of issue tracker which works with edbrowse (I'm not sure
> how edbrowse-friendly the github setup is)?

Well, the github issue tracker isn't edbrowse-friendly at all.  Github
uses lots and lots of ajax and other fancy web stuff.
However, they do provide an API for programmatic access.
A few years back, I wrote a command-line interface to github, using
their API.  It works well with their issue tracker.  You can clone the
code here: git://github.com/CMB/cligh.git
Coincidentally, this is the program I used to give you and Karl push
access to the main repository.
It's written in Python.  Also, it requires a couple of external
dependencies, one of which is probably not packaged on most
distributions.  I suspect this is a problem for some people.

> On the subject of 3.4.11, apart from the js lib change and other bug fixes,
> are there any other features or major changes we want to make before it
> happens

I don't think so.

-- Chris

Re: [Edbrowse-dev] master

[Cleverson Casarin Uliana]

On an issue tracker, I find Trac's interface quite easy, although I 
haven't tested it with edbrowse. It's used by the NVDA screen reader 
developers, for example.

Regards
Cleverson

Em 28/01/2014 15:16, Chris Brannon escreveu:
> Adam Thompson<arthompson1990@gmail.com>  writes:
>
>> Do we have some form of issue tracker which works with edbrowse (I'm not sure
>> how edbrowse-friendly the github setup is)?
>
> Well, the github issue tracker isn't edbrowse-friendly at all.  Github
> uses lots and lots of ajax and other fancy web stuff.
> However, they do provide an API for programmatic access.
> A few years back, I wrote a command-line interface to github, using
> their API.  It works well with their issue tracker.  You can clone the
> code here: git://github.com/CMB/cligh.git
> Coincidentally, this is the program I used to give you and Karl push
> access to the main repository.
> It's written in Python.  Also, it requires a couple of external
> dependencies, one of which is probably not packaged on most
> distributions.  I suspect this is a problem for some people.
>
>> On the subject of 3.4.11, apart from the js lib change and other bug fixes,
>> are there any other features or major changes we want to make before it
>> happens
>
> I don't think so.
>
> -- Chris
> _______________________________________________
> Edbrowse-dev mailing list
> Edbrowse-dev@lists.the-brannons.com
> http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev

Re: [Edbrowse-dev] master

[Adam Thompson]

On Tue, Jan 28, 2014 at 03:31:39PM -0200, Cleverson Casarin Uliana wrote:
> On an issue tracker, I find Trac's interface quite easy, although I
> haven't tested it with edbrowse. It's used by the NVDA screen reader
> developers, for example.

Yeah, I've used Trac extensively with edbrowse.
It certainly works, though I seem to remember a couple of shiny things not
quite working as expected.
They were still usable though.

Given that all the code is hosted on github though,
I'm not sure going down the Trac road is the best idea,
unless anyone fancies hosting an instance (no idea what's involved here).

Cheers,
Adam.

[Edbrowse-dev] master

[Karl Dahlke]

There are many enhancements that would be good to make,
but probably not bundled with this one.
Go to 3.5.1 first, then other changes can push the third number again.
These changes are mostly additions to the DOM, objects that I haven't implemented
or even simulated,
and as we all saw, when one of these is missing javascript stops in its tracks.
That's why edbrowse isn't working on more and more sites.
We need to have the same objects and methods,
or stubs for these objects and methods,
as you might find in a browser.
It's just grunt-work, and not very easy or satisfying.
A site doesn't work, set db3, track it down,
what variable is missing, look it up in a js dom tutorial,
what does the variable do, implement it or simulate it.
Then move on to the next broken website, and so on.
All needs to be done, all good stuff,
but rather independent of what we're doing now.

Some of these changes won't happen until the big rewrite,
those where js creates brand new thingies that are normally made by html.
That's backwards in my path today, so we'll just wait on these.

Anyways that's how I see the road ahead.

Karl Dahlke

Re: [Edbrowse-dev] master

[Adam Thompson]

On Tue, Jan 28, 2014 at 12:35:03PM -0500, Karl Dahlke wrote:
> There are many enhancements that would be good to make,
> but probably not bundled with this one.
> Go to 3.5.1 first, then other changes can push the third number again.

My thoughts exactly but thought I'd just check.

> These changes are mostly additions to the DOM, objects that I haven't implemented
> or even simulated,
> and as we all saw, when one of these is missing javascript stops in its tracks.
> That's why edbrowse isn't working on more and more sites.
> We need to have the same objects and methods,
> or stubs for these objects and methods,
> as you might find in a browser.
> It's just grunt-work, and not very easy or satisfying.
> A site doesn't work, set db3, track it down,
> what variable is missing, look it up in a js dom tutorial,
> what does the variable do, implement it or simulate it.
> Then move on to the next broken website, and so on.
> All needs to be done, all good stuff,
> but rather independent of what we're doing now.

Yeah, I guess the big ones are AJAX and friends.

> Some of these changes won't happen until the big rewrite,
> those where js creates brand new thingies that are normally made by html.
> That's backwards in my path today, so we'll just wait on these.

They look a bit messy to implement, but we may find that we have no choice
given the way the web is going. Any specific candidates for such things?

> Anyways that's how I see the road ahead.

Yeah, I was also wondering about  other features.
A couple that spring to mind:
An option (config file or command line)
to increase the max limit on the number of lines (basically switch from a static array to malloc)
same for max line length (not sure about the possibility of this one)

These are mainly motivated by the fact that I sometimes need to edit gygantic
ascii data files and such editing is usually much easier to do in a text editor
rather than other more specialist software.

Cheers,
Adam.

[Edbrowse-dev] master

[Karl Dahlke]

Another often requested feature is imap,
something I've wanted to do for a while.
Don't know anything about it; I'd have to start with the rfc.
Or maybe there's an imap library that we could use.

> to increase the max limit on the number of lines

Sounds easy, but the line number is actually sprintfed into places with seven spaces,
with other characters around it,
so would take some rewriting to increase it.
I know, kind of a bad design, but 15 years ago who would imagine
wanting to store more than 10 million lines??
I can find the code in buffers.c and point it out,
or think about what it would take to modify.

> same for max line length

You realize that lines are arbitrarily long inside,
else you could not faithfully download a binary file.
The line length is just what is displayed,
and it can be changed by

linelength = 1000

in your config file.

Like Chuck, my distro doesn't seem to have any js packages beyond 185;
where can I get 24, and compiling from source is fine,
in some ways preferable.
Thanks.

Karl Dahlke

Re: [Edbrowse-dev] master

[Chris Brannon]

> where can I get 24, and compiling from source is fine,

https://ftp.mozilla.org/pub/mozilla.org/js/mozjs-24.2.0.tar.bz2

-- Chris

Re: [Edbrowse-dev] master

[Adam Thompson]

On Tue, Jan 28, 2014 at 04:45:01PM -0500, Karl Dahlke wrote:
> Another often requested feature is imap,
> something I've wanted to do for a while.
> Don't know anything about it; I'd have to start with the rfc.
> Or maybe there's an imap library that we could use.
I suspect there's a library we can use for this,
but can't think what it's called.
> 
> > to increase the max limit on the number of lines
> 
> Sounds easy, but the line number is actually sprintfed into places with seven spaces,
> with other characters around it,
> so would take some rewriting to increase it.
> I know, kind of a bad design, but 15 years ago who would imagine
> wanting to store more than 10 million lines??
> I can find the code in buffers.c and point it out,
> or think about what it would take to modify.

Both would be nice. I have to say, until I loaded my first multi-hundred mb
ascii file into edbrowse I'd never thought 10000000 lines was a problem.
> 
> > same for max line length
> 
> You realize that lines are arbitrarily long inside,
> else you could not faithfully download a binary file.
> The line length is just what is displayed,
> and it can be changed by

Yeah, in theory, but I've seen errors from substitutions complaining that the
result would be longer than (I think) 40000 bytes.
This (I seem to remember) was caused when trying to debug a js error which
involved trying to read a minified version of some js lib (basically remove
newlines, comments etc). I was trying to run:
s/;/;\n/g
To make the file almost readable. I don't have a test case for this I'm afraid.

I know the line is stored internally in the edbrowse buffer faithfully, but I
guess by line length I should have said editable line length (i.e.
the length of line one can perform editing commands on,
regardless of whether the results are fully displayed).

> Like Chuck, my distro doesn't seem to have any js packages beyond 185;
> where can I get 24, and compiling from source is fine,
> in some ways preferable.

What distro?

The download url I used for mozjs 24 is (source version):
https://ftp.mozilla.org/pub/mozilla.org/js/mozjs-24.2.0.tar.bz2

I can't remember what it needs in terms of dependancies, but if you uncompress, cd js/src and the ./configure you should see a whole load of stuff including any failures.

For debugging edbrowse I built with:
./configure --prefix <whereever_you_put_custom_stuff> --disable-optimize --enable-debug
make
make install

The --enable-debug meant I didn't need to mess around with manually setting
CFLAGS etc and the --disable-optimize makes things nicer when using gdb.

As you said, compiling from source in this case really does make life easier.
Even with the debian package's debugging symbols I still needed to use my own
compiled version to get any real debugging done due to the fact that most
(hopefully all) distros will package mozjs 24 with optimizations enabled.

Cheers,
Adam.