- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev] HTTPS Patch

by Lars Segerlund

How about considering subversion ? ( www.tigris.org ). I have been using it at work for about a year with really good results. It can really do branches and such, also handles directories in a sane way. / regards, LArs Segerlund. On Thu, 13 Nov 2003 02:46:56 +0100 (CET) "Indan Zupancic" <indan(a)nul.nu> wrote: > > I've made some scripts which create a temporary copy of the dillo CVS > > dir and the patched dir, remove all unwanted crud from the patched dir, > > do the diff and generate some statistics. I can send them if you want. > > Hm, a script, didn't thought about that. No need to send them though, can > make my own if I need any. > > > Of course this still leaves the issues with patch makers constantly > > being out of sync with eachother, and each patch being broken by updates > > to CVS shortly after the patch was posted. More on that later... > > What about making a seperate Dillo repository, but instead of using CVS > that is too centralized and can't handle branches very well (or so I > heard), we could use GNU Arch (http://www.gnu.org/software/gnu-arch/, > thanks to Paul Pelzl for the tip) or Bitkeeper? That way it should be much > easier to manage all the patches, with one branch for each "patch" (one > branch for https, one for tab+frames, etc). The hardest part should be to > keep our main branch in sync with Dillo's CVS. > > Greetings, > > Indan > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Nov. 14, 2003

Re: [Dillo-dev] Cross Compiling for arm

by Donald McKnight

Same issue it located everything fine except for the X11R6 Headers, I corrected this but I get some errors on the make and they are below: dw_table.c: In function `Dw_table_construct_last_iterator': dw_table.c:649: warning: `child' might be used uninitialized in this function In file included from /opt/arm-linux/include/jpeglib.h:28, from jpeg.c:29: /opt/arm-linux/include/jconfig.h:12: warning: `HAVE_STDLIB_H' redefined ../config.h:38: warning: this is the location of the previous definition /opt/arm-linux/bin/ld: warning: cannot find entry symbol _start; defaulting to 00013c64 /opt/arm-linux/bin/ld: warning: cannot find entry symbol _start; defaulting to 000099b4 Strange this is when I launch it on arm it doesnt give any errors it just sits there and never opens unless I kill it Im lost at this point Thanks for the feed back Donald ----- Original Message ----- From: "Jorge Arellano Cid" <jcid(a)dillo.org> To: "Donald McKnight" <donald.mcknight(a)sbcglobal.net> Cc: "Dillo mailing list" <dillo-dev(a)lists.auriga.wearlab.de> Sent: Thursday, November 13, 2003 1:09 PM Subject: Re: [Dillo-dev] Cross Compiling for arm > > > On Thu, 13 Nov 2003, Donald McKnight wrote: > > > Hello, > > I recently downloaded 0.7.3 to cross compile on the gmate yopy > 3700. with my first attempt I noticed the configure script > grabbed all of my local variables such as /usr/local/lib instead > of /opt/arm-linux/lib. This gave me libgtk.so cannot read > symbols. I went though the configure and manually set the > environment variables and was able to successfully compile dillo, > however when I transfer the binary to arm it does not launch it > just hangs. I have cross-compiled several apps using the same > cross-compiler on my system. I am using slackware 9.1 kernel > 2.4.22, but I don't think the version should matter. Has anyone > ran into this before? > > > Hmmm, I've not been cross compiling dillo, but there's this > portion of code in configure.in: > > dnl -------------------------------------- > dnl Check whether to add /usr/local or not > dnl (this is somewhat a religious problem) > dnl -------------------------------------- > dnl > if test ! "`$CPP -v < /dev/null 2>&1 | grep '/usr/local/include'`"; then > CPPFLAGS="$CPPFLAGS -I/usr/local/include" > LDFLAGS="$LDFLAGS -L/usr/local/lib" > fi > > > Please comment it out, re-run autogen and see what happens. > > If you can't find the answer here, maybe the guys at familiar > may hint you better. > > > HTH > Jorge.- > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Nov. 13, 2003

Re: [Dillo-dev] Cross Compiling for arm

by Jorge Arellano Cid

On Thu, 13 Nov 2003, Donald McKnight wrote: > Hello, > I recently downloaded 0.7.3 to cross compile on the gmate yopy 3700. with my first attempt I noticed the configure script grabbed all of my local variables such as /usr/local/lib instead of /opt/arm-linux/lib. This gave me libgtk.so cannot read symbols. I went though the configure and manually set the environment variables and was able to successfully compile dillo, however when I transfer the binary to arm it does not launch it just hangs. I have cross-compiled several apps using the same cross-compiler on my system. I am using slackware 9.1 kernel 2.4.22, but I don't think the version should matter. Has anyone ran into this before? Hmmm, I've not been cross compiling dillo, but there's this portion of code in configure.in: dnl -------------------------------------- dnl Check whether to add /usr/local or not dnl (this is somewhat a religious problem) dnl -------------------------------------- dnl if test ! "`$CPP -v < /dev/null 2>&1 | grep '/usr/local/include'`"; then CPPFLAGS="$CPPFLAGS -I/usr/local/include" LDFLAGS="$LDFLAGS -L/usr/local/lib" fi Please comment it out, re-run autogen and see what happens. If you can't find the answer here, maybe the guys at familiar may hint you better. HTH Jorge.-

Nov. 13, 2003

Cross Compiling for arm

by Donald McKnight

Hello, I recently downloaded 0.7.3 to cross compile on the gmate yopy 3700. with my first attempt I noticed the configure script grabbed all of my local variables such as /usr/local/lib instead of /opt/arm-linux/lib. This gave me libgtk.so cannot read symbols. I went though the configure and manually set the environment variables and was able to successfully compile dillo, however when I transfer the binary to arm it does not launch it just hangs. I have cross-compiled several apps using the same cross-compiler on my system. I am using slackware 9.1 kernel 2.4.22, but I don't think the version should matter. Has anyone ran into this before? Thanks Donald McKnight

Nov. 13, 2003

Re: [Dillo-dev] HTTPS Patch

by Andreas Schweitzer

On Thu, Nov 13, 2003 at 04:40:35PM +0100, Stephan Goetter wrote: > Am Thu, Nov 13, 2003 at 12:23:52PM +0100 schrieb Indan Zupancic und sprach: > > > I think something like Arch or Subversion, with an accompanying Wiki for > > > developers and users to converse (and converge) is a good idea. > > > > I'm starting to doubt the whole idea, how nice it may be: Are there any > > other active patch makers out there except us? > > I'm working on JavaScript support for dillo using the SpiderMonkey > C-Engine of the Mozilla project: http://www.mozilla.org/js/spidermonkey/ At some point I was thinking (or rather fanatsising :-) ...) about using http://www.bbassett.net/njs/ as a Javascript Interpreter. (That was when I first understood plugins and played with them.) > The patch is not yet stable/clean enough to post it here and it lacks > a lot. Currently I try to clean it up and get the focus set on google. Google uses Javascript ? > I know most people here have low-end machines and there is probably no > interest in JavaScript support in the main branch. IMHO it could be useful to have an extremely light implementation. Only the OnClick, OnSUbmit things. I read on the specs etc., understood only a portion and probably remember only a tiny fraction now :-). But I remember, that it may make sense to only implement a handful of Javascriopt things (as you see, I even forgot the terminology), It may still be compaitible with dillo's design goals. I was mainly thinking of the sites that use Javascript to pop up new windows on clicking some links - which could just as easily be implemented in HTML. I.e. the ones that don't know the difference between Javascript and HTML. Also, the OnSUbmit thing seems to be useful for checking form values before submissions. However, all in all, I use dillo because it does NOT support Javascript and let the browser invade my desktop :-) Cheers, Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

Nov. 13, 2003

Re: [Dillo-dev] HTTPS Patch

by Stephan Goetter

Am Thu, Nov 13, 2003 at 12:23:52PM +0100 schrieb Indan Zupancic und sprach: > > I think something like Arch or Subversion, with an accompanying Wiki for > > developers and users to converse (and converge) is a good idea. > > I'm starting to doubt the whole idea, how nice it may be: Are there any > other active patch makers out there except us? I'm working on JavaScript support for dillo using the SpiderMonkey C-Engine of the Mozilla project: http://www.mozilla.org/js/spidermonkey/ Code as part of the html-file can already be executed. <script>...</script>, window.*(), window.status, location, history, href="javascript:.." do work. The patch is not yet stable/clean enough to post it here and it lacks a lot. Currently I try to clean it up and get the focus set on google. I thought about a patch on top of Frank's patch as I'm using this every day but this wouldn't make things easier. I know most people here have low-end machines and there is probably no interest in JavaScript support in the main branch. Greets, Stephan

Nov. 13, 2003

Re: [Dillo-dev] [RFC] Last call... remove conditional compilation from tab/fram patch?

by Patrick Shanahan

* Frank de Lange <frank(a)unternet.org> [11-13-03 03:25]: > > Those of you who want to keep the conditional compilation options for > tabs and frameset support in the tab/frame patch, speak up now. If I > do not get any serious requests in this direction I will remove the > conditional compilation options in the next patch (any day now...) > and you'll all be stuck with tabs and frames. But... that might be > the reason you applied the patch in the first place, so... Drop the conditional compilation and provide new-window/tab option in the rc file. tks, -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org

Nov. 13, 2003

Re: [Dillo-dev] HTTPS Patch

by Paul Pelzl

On Thu, Nov 13, 2003 at 02:46:56AM +0100, Indan Zupancic wrote: > What about making a seperate Dillo repository, but instead of using CVS > that is too centralized and can't handle branches very well (or so I > heard), we could use GNU Arch (http://www.gnu.org/software/gnu-arch/, > thanks to Paul Pelzl for the tip) or Bitkeeper? That way it should be much > easier to manage all the patches, with one branch for each "patch" (one > branch for https, one for tab+frames, etc). The hardest part should be to > keep our main branch in sync with Dillo's CVS. The best way to handle that with Arch is to have a "CVS gateway" branch that contains only unmodified CVS sources. Other branches (https, tab/frame, etc.) would be tags ("continuations") of the CVS gateway, which would make it relatively easy to merge in patches from CVS. Of course, the "merge in" is where work is sometimes involved, but I don't know of any general solution to that problem. Paul

Nov. 13, 2003

Re: [Dillo-dev] [RFC] keywords

by Paul Pelzl

On Thu, Nov 13, 2003 at 12:51:06PM +0100, Frank de Lange wrote: > in the location bar, which is interpreted as "search for something or > other" through this keyword definition in the dillorc: > > s:http://www.google.com/search?q= > > You can define as many as these as you want. The format is > > keywords = "<keyword>:<url> <keyword>:<url> ..." I think this is an elegant way to handle it. The most immediate benefit I see is that I can (probably) set up keywords for multiple search sites (teoma, turbo10, alltheweb, etc.). > [ and on the subject of preferences... I know what Havoc et al say, but > I do not always agree... In many cases choice is a good thing, as > long as it is not mandatory to choose. Define sane defaults for those > who can not or do not want to choose, but keep things flexible for > those who want to change those defaults. TIMTOWTDI ] I could not agree more. Paul

Nov. 13, 2003

Re: [Dillo-dev] HTTPS Patch

by Andreas Schweitzer

On Thu, Nov 13, 2003 at 09:50:29AM +0100, Thorben Thuermer wrote: > On Thu, 13 Nov 2003 07:59:50 +0100 > Frank de Lange <frank(a)unternet.org> wrote: > > Indan Zupancic wrote: > > > > >What about making a seperate Dillo repository, but instead of using CVS > > >that is too centralized and can't handle branches very well (or so I > > >heard), <snip> > erm... or http://auriga.wearlab.de/ ? ;) Or while at it, use indeed the branch mechanism. In the documentation it does not look that much different from current diff-ing. Furthermore, CVS can be configured (with add-ons) to allow certain comittors only comit into certain branches. This is handled via comittinfo and cvs_acls. cvs_acls is a perl script that is at least in the source tar ball of cvs in the contrib section. Most installations of cvs keep it somewhere ( .../share/.../cvs/.../contrib/ ) If ypu should not have a local copy, check http://ccvs.cvshome.org/source/browse/ccvs/contrib/cvs_acls.in where it is documented in detail how to restrict users to branches. That way, Jorge and Sebastian keep control over the main branch as it is right now, but dedicated branchers could have their repository in the same place. And users simply need to check out these experimental branches. The branchesr only need to marge from current regularly. Of course, I don't know how wearlab has organized their CVS setup and if that would be acceptable. Also, I hope that Jorge or Sebastian read that far down in the thread ;-) ... Cheers Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

Nov. 13, 2003