From: Karl Dahlke <email@example.com>
Subject: [edbrowse-dev] local version of website
Date: Sat, 01 Jun 2019 07:53:30 -0400 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 1933 bytes --]
It is not easy to figure out what is wrong with edbrowse js in the real world.
I always seem to need a local copy of the website, with all its js files, deminimized, and css files too, so I can put in debug prints, and breakpoints, etc.
That task alone use to take hours.
I'm trying to streamline it with a snapshot() function.
You call it from within jdb.
Let's use nasa as the quintessential example,
an incredibly complicated website just to disseminate information.
1. make a directory somewhere called nasa and cd into it.
This directory is empty.
2. Call up edbrowse and set demin for deminimization, and db3 if you want to see what is going on.
3. Verify you have about 180 lines, you got real stuff. Try to ignore the errors for now.
4. jump into jdb and run snapshot().
5. Use . to exit out of jdb, then ub to unbrowse.
This sets the base tag.
Save the home page to a local file.
We're done here.
6. ls to see what has happened.
7. edbrowse the base file, just a local file.
db3 to see what is happening, and b to browse.
Also the css files, though I don't have this working for @import yet.
You should get the same errors, and the same 180 lines of stuff.
8. You can change the js files, add alert statements, breakpoints, etc, and browse and change and browse again, and otherwise debug.
This should support nontrivial debugging.
You don't need a local web server to do this, which I needed in the past.
For ongoing work, change the filenames to be more intuitive.
Perhaps f2.js is vendor.js and f3.js is nasa.js.
Just make the same change in the jslocal map.
Maybe I can improve the software to come up with better filenames.
There's more work to do here so send along patches and suggestions.
reply other threads:[~2019-06-01 12:01 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).