[Edbrowse-dev] jsrt works

[Edbrowse-dev] jsrt works

[Karl Dahlke]

Ok, with the new js process architecture, I finally got jsrt to load properly,
and I think I've exercised all its functions, of which there are many.
I even did some new things that didn't make sense in the old world.

edbrowse jsrt jsrt
b
e2
b

Now you have two instances of the regression test running.
In the second one, run the memory hog,
and js runs out of memory and dies.
Switch back to the first jsrt and do a few things
and note that js is not there.
But unbrowse and browse, and you have all your js functionality
back again. So that's kinda cool.

I'll be looking at html.cpp to see if I can pull it back to html.c.
And of course fixing bugs as you and I find them.

I was thinking about background downloads, as has been requested by
several people, and propose this interface, always trying to keep it
command line and simple.
For any ftp download, or for an http download where the content
is other than text/html, propt the user

download foo_bar_3.7.9.8.tar.gz

The user hits return to download to the specified file,
or enters a new filename, or hits space and return to download to memory
as is done today.
I think it's easy and clean, but opens a question of whether
we should by default download to the current directory,
or follow the industry standard of downloading to a download directory
which you could set in the config file.
I both like and don't like the download directory standard.
Sometimes it makes sense, sometimes I just want the damn file where I am,
like I'm there for a reason.
And I could always say ~/dld/whatever.tar.gz
if I want to direct it to a download directory.
So I kind of waffle on this one.
Anyways it spins off in background and downloads,
or stays and pulls it into memory with the progress dots that you have today.

Karl Dahlke

Re: [Edbrowse-dev] jsrt works

[Adam Thompson]

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

On Fri, Dec 26, 2014 at 12:05:44PM -0500, Karl Dahlke wrote:
> Ok, with the new js process architecture, I finally got jsrt to load properly,
> and I think I've exercised all its functions, of which there are many.
> I even did some new things that didn't make sense in the old world.
> 
> edbrowse jsrt jsrt
> b
> e2
> b
> 
> Now you have two instances of the regression test running.
> In the second one, run the memory hog,
> and js runs out of memory and dies.
> Switch back to the first jsrt and do a few things
> and note that js is not there.
> But unbrowse and browse, and you have all your js functionality
> back again. So that's kinda cool.

Yeah that's cool.
> I'll be looking at html.cpp to see if I can pull it back to html.c.
> And of course fixing bugs as you and I find them.

Ok, I've just pushed a bunch of commits to start this process (the first two
should have done it, but I did a git pull before a git commit, or something,
and it failed, so I pushed a reset and started again).

> I was thinking about background downloads, as has been requested by
> several people, and propose this interface, always trying to keep it
> command line and simple.
> For any ftp download, or for an http download where the content
> is other than text/html, propt the user
> 
> download foo_bar_3.7.9.8.tar.gz
> 
> The user hits return to download to the specified file,
> or enters a new filename, or hits space and return to download to memory
> as is done today.
> I think it's easy and clean, but opens a question of whether
> we should by default download to the current directory,
> or follow the industry standard of downloading to a download directory
> which you could set in the config file.
> I both like and don't like the download directory standard.

I'd prefer the download dir, at the end of the day you can always put a ./
before the file name to get the current directory (shorter than typing the path to a download directory imho).

> Sometimes it makes sense, sometimes I just want the damn file where I am,
> like I'm there for a reason.
> And I could always say ~/dld/whatever.tar.gz
> if I want to direct it to a download directory.
> So I kind of waffle on this one.
> Anyways it spins off in background and downloads,
> or stays and pulls it into memory with the progress dots that you have today.
That sounds cool, how would this be implemented?
If you want to put that in, I'll continue with the html.c convertion since I've
got a good idea what needs to happen now.

Cheers,
Adam.

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