- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev]Using dillo on SourceForge

by Diego Sáenz

El Fri, 3 Jun 2005 13:47:21 -0400 Jorge Arellano Cid <jcid(a)dillo.org> escribio: > > On Thu, Jun 02, 2005 at 03:56:29AM +0200, Diego Sáenz wrote: > > Hello Jorge, i am the guy who make the path to move the dillo > > cookies code to a dpi. I want to know why is not the cookies > > dpi patch in the cvs? What must i do/change to see the code in > > the cvs? I use dillo with the cookies dpi patch every day and i > > have no complains.(I allow cookies for few sites anyway so i do > > not know if it is enought) > > CVS is about to be released as bugfix dillo-0.8.5. The idea is > to merge the new cookies dpi with the new dpi stuff in the fltk2 > tree. Now, as it could certainly help the debugging of this dpi, > I'll merge it into the 0.8.5 CVS after the release so the guys in > dillo-dev can help you with the testing&debugging. Ok, thanks by the fast answer. Can you advance something about the new dpi stuff? > > > About sourceforge thing it do not login or create new > > account(try to load(¿?) the submit url but do not do), but you > > can copy the cookies for the "remember me" option from another > > browser, while cookies.dpi is off, and use dillo normally. > > This would be interesting to investigate. I mean, what's > required to fully work with sourceforge (from a distance, it > looks like some HTTP1.1 tweaks can help). There are other websites in wich dillo do not logging or register(even sites that not use https for them), but after you copy the cookies you can use it. A feature to load(but not update) cookies files from others browsers, now that dillo uses netescape like cookies file, can be very easy to do in cookies dpi. > > > About test if the cookies work correctly over https i do not ... Goodbye

June 3, 2005

Re: [Dillo-dev]Using dillo on SourceForge

by Jorge Arellano Cid

On Thu, Jun 02, 2005 at 03:56:29AM +0200, Diego Sáenz wrote: > Hello Jorge, i am the guy who make the path to move the dillo > cookies code to a dpi. I want to know why is not the cookies > dpi patch in the cvs? What must i do/change to see the code in > the cvs? I use dillo with the cookies dpi patch every day and i > have no complains.(I allow cookies for few sites anyway so i do > not know if it is enought) CVS is about to be released as bugfix dillo-0.8.5. The idea is to merge the new cookies dpi with the new dpi stuff in the fltk2 tree. Now, as it could certainly help the debugging of this dpi, I'll merge it into the 0.8.5 CVS after the release so the guys in dillo-dev can help you with the testing&debugging. > About sourceforge thing it do not login or create new > account(try to load(¿?) the submit url but do not do), but you > can copy the cookies for the "remember me" option from another > browser, while cookies.dpi is off, and use dillo normally. This would be interesting to investigate. I mean, what's required to fully work with sourceforge (from a distance, it looks like some HTTP1.1 tweaks can help). > About test if the cookies work correctly over https i do not > have a configured server at hand, but i have not free time > until june 20th too. dillo-dev: anyone? (just ask Diego for the patch or wait for the CVS after the 0.8.5 release is done). > El Wed, 27 Apr 2005 11:38:40 +0200 > Jorge Arellano Cid <jcid(a)dillo.org> escribio: > > > On Tue, Apr 26, 2005 at 05:55:54PM +0200, Diego Sáenz wrote: > > > Very thanks again. With the a_Dpi_send_blocking_cmd was enough > > the other code was allmost as that i have code. It is working > > just now. I will clean my code and test it some more before post > > to the list. > > > > Good Diego! > > > > I'm interested in the https cookies stuff. AFAIK everything is > > there for it to work. I haven't checked whether the https dpi is > > sending back the cookies to dillo, but you can do that! :-) > > > > BTW, the next time you have a patch, please set a URL with it. > > Don't send it to dillo-dev. If you don't have an http server at > > hand, just ask Jorgen Viksell to put it in our site. > > > > -- > > Cheers > > Jorge.- -- Cheers Jorge.-

June 3, 2005

Re: [Dillo-dev]Preparing the dillo-0.8.5 release.

by Jorge Arellano Cid

Hi, On Fri, Jun 03, 2005 at 12:06:03PM +0200, Thomas-Martin Seck wrote: > * Jorge Arellano Cid (jcid(a)dillo.org) > > > I'm preparing the dillo-0.8.5 tarball now. This will hopefully > > be the last GTK1-based dillo to be released, as the next one will > > be FLTK2-based. The plan is to show a strong protoype in Dijon at > > the LSM 2005, and have it shortly thereafter ready for public > > consumption (after a play/test/fix/stabilize cycle on dillo-dev). > > Will FLTK2.0 be officially released by then? AFAIK FLTK2.0 doesn't have a projected release date yet. > I'm asking because I can > only update dillo to FLTK-dillo when we have a FLTK2 port in the FreeBSD > ports tree. (I just looked and we don't even seem have FLTK 1.2 in > there, only 1.1.6. Hm. Looks like work.) FLTK2 is much cleaner, and multiplatform, so it should'n be that hard to port. BTW, can't you have a statically linked FLTK2-based dillo in FreeBSD? > > > Back to dillo-0.8.5: this release is mainly a bug-fix release. > > The final touches were just uploaded to current CVS. Please > > download it, test, and report back to the list on how it works. > > This will help me to make the tarball and release it ASAP. > > I managed to fetch a few minor updates around 0700 UTC -- the CVS server > seems to have died after that. Could someone investigate? At least for me CVS is working now, as of this writting. > What I got > calls itself 0.8.5-pre and works as well as 0.8.4 on both FreeBSD 4 > and 5 (i386). Yes, that's the one. I'm just to change 0.8.5-pre to 0.8.5 and update the splash screen brief before packing the tarball for the final test before public release. -- Cheers Jorge.-

June 3, 2005

Re: [Dillo-dev]Preparing the dillo-0.8.5 release.

by Thomas-Martin Seck

* Jorge Arellano Cid (jcid(a)dillo.org) > I'm preparing the dillo-0.8.5 tarball now. This will hopefully > be the last GTK1-based dillo to be released, as the next one will > be FLTK2-based. The plan is to show a strong protoype in Dijon at > the LSM 2005, and have it shortly thereafter ready for public > consumption (after a play/test/fix/stabilize cycle on dillo-dev). Will FLTK2.0 be officially released by then? I'm asking because I can only update dillo to FLTK-dillo when we have a FLTK2 port in the FreeBSD ports tree. (I just looked and we don't even seem have FLTK 1.2 in there, only 1.1.6. Hm. Looks like work.) > Back to dillo-0.8.5: this release is mainly a bug-fix release. > The final touches were just uploaded to current CVS. Please > download it, test, and report back to the list on how it works. > This will help me to make the tarball and release it ASAP. I managed to fetch a few minor updates around 0700 UTC -- the CVS server seems to have died after that. Could someone investigate? What I got calls itself 0.8.5-pre and works as well as 0.8.4 on both FreeBSD 4 and 5 (i386).

June 3, 2005

[Dillo-dev]Preparing the dillo-0.8.5 release.

by Jorge Arellano Cid

Hi there! A long time since the last post right? Well, don't worry, as always, a silent dillo-dev list means lots of stuff going on behind the scenes! I'm preparing the dillo-0.8.5 tarball now. This will hopefully be the last GTK1-based dillo to be released, as the next one will be FLTK2-based. The plan is to show a strong protoype in Dijon at the LSM 2005, and have it shortly thereafter ready for public consumption (after a play/test/fix/stabilize cycle on dillo-dev). Back to dillo-0.8.5: this release is mainly a bug-fix release. The final touches were just uploaded to current CVS. Please download it, test, and report back to the list on how it works. This will help me to make the tarball and release it ASAP. As currently I'm working on three source trees, getting rid of this one will certainly relieve my workload. The second tree is a rewrite of the plugin stuff under a cleaner design that's to be included in the FLTK2-tree. -- Cheers Jorge.-

June 2, 2005

[Dillo-dev]clicking on incomplete link

by beartooth

I have dillo set as my default browser. It opens all right when I click on a full URL in an email, but if what's there just starts with www, leaving off the http://, it fails. Other browsers can figure that out -- as can dillo if I type it into the location field. Why not by clicking? Have I got something tweaked wrong? -- Beartooth Neo-Redneck, Linux Evangelist FC 1&3, YDL 4; Pine 4.63, Pan 0.14.2; Privoxy 3.0.3; Dillo 0.8.4, Opera 8.0, Firefox 1.0.3, Epiphany 1.0.4 Remember that I have little idea what I am talking about.

June 1, 2005

Re: [Dillo-dev]dillo on sparc64

by Damien COUDERC

Hi Jorge ! >>The following line is reallocating a buffer: >>conn->Buf = g_realloc(conn->Buf, (gulong)io->Status); >> >>But when debugging the values of io->Status don't seem to be adequate. >>I haven't been able to completely fix it as the code is seriously >>lacking of comment. > > All the dpi stuff is under a big revision. The current diff I'm > working on is 40 pages. BTW, in the new version, that line is: > > conn->Buf = g_realloc(conn->Buf, conn->BufSize + (gulong)io->Status); That is what i had first done to fix the problem. But dillo still segfault a bit later and i've not been able to found where yet. I can just say that there is a problem with the start of a string that is lost somewhere. IMHO the fix of Roberto looks better but as i'm not used to this code i'm maybe wrong. >>To be honest i don't even completely understand what >>this chunk is doing and the code is so unreadable that it doesn't help >>(not to be harsh but just to give my humble opinion). > > :-O This is meant to be a constructive critic. I'm addicted to maintainable code and by experience i know that if there are not enough comments the code is not easily readable. For the record, this bug has been found month ago but i've been unmotivated each time i had to read again the dpi.c file. If it had been well commented i should have been able to fix the problem by myself and to send you the resulting patch. Think that you have maybe lost potential developers just for this reason. Now and again this is just my humble opinion and i'm not pretensious enough to try to learn you how to manage your own project. Cheers, Damien

May 19, 2005

Re: [Dillo-dev]dillo on sparc64

by Jorge Arellano Cid

On Thu, May 19, 2005 at 04:40:55PM +0200, Damien COUDERC wrote: > Hi, > i have problems with dillo on sparc64. When using a mechanism of OpenBSD > 's malloc i'm able to detect a bug in the dpi stuff. > At the moment i've found that the function Dpi_append_io_buf() in the > file src/IO/dpi.c is wrong. > > The following line is reallocating a buffer: > conn->Buf = g_realloc(conn->Buf, (gulong)io->Status); > > But when debugging the values of io->Status don't seem to be adequate. > I haven't been able to completely fix it as the code is seriously > lacking of comment. All the dpi stuff is under a big revision. The current diff I'm working on is 40 pages. BTW, in the new version, that line is: conn->Buf = g_realloc(conn->Buf, conn->BufSize + (gulong)io->Status); > To be honest i don't even completely understand what > this chunk is doing and the code is so unreadable that it doesn't help > (not to be harsh but just to give my humble opinion). :-O -- Jorge.-

May 19, 2005

Re: [Dillo-dev]dillo on sparc64

by Roberto A. Foglietta

Damien COUDERC wrote: > Hi, > i have problems with dillo on sparc64. When using a mechanism of OpenBSD > 's malloc i'm able to detect a bug in the dpi stuff. > At the moment i've found that the function Dpi_append_io_buf() in the > file src/IO/dpi.c is wrong. > > The following line is reallocating a buffer: > conn->Buf = g_realloc(conn->Buf, (gulong)io->Status); > > But when debugging the values of io->Status don't seem to be adequate. > I haven't been able to completely fix it as the code is seriously > lacking of comment. To be honest i don't even completely understand what > this chunk is doing and the code is so unreadable that it doesn't help > (not to be harsh but just to give my humble opinion). in the file src/IO/IO.h, in the function static gboolean IO_read(IOData_t *io) there is at line 464 (in last stable release 0.8.4) io->Status = St; but that is true only if not have been read some more data with DataPending = TRUE; which repeate while and it is in the last else that was wrongly commented as /* BytesRead == io->BufSize */ while that conditions is /* BytesRead == io->BufSize */ So in few words the patch I propose is: io->Status = 0; //HERE do { ret = FALSE; DataPending = FALSE; St = read(io->FD, io->Buf, io->BufSize); io->Status += St; //AND HERE obviuosly who read have to free the previous buffer and set io->Status to zero... but in IMHO because the io struct has a flag wich tell us if there is something allocated is a good idea to use it and also free the buffers whose are sent to be read but not freed before. Cheers, -- Roberto A. Foglietta Analista Programmatore GNU/Linux SAD Trasporto Locale S.p.a. Corso Italia 13/N 39100 BOLZANO (I) Tel. +39/0471-450.261 Fax +39/0471-450.253

May 19, 2005

[Dillo-dev]dillo on sparc64

by Damien COUDERC

Hi, i have problems with dillo on sparc64. When using a mechanism of OpenBSD 's malloc i'm able to detect a bug in the dpi stuff. At the moment i've found that the function Dpi_append_io_buf() in the file src/IO/dpi.c is wrong. The following line is reallocating a buffer: conn->Buf = g_realloc(conn->Buf, (gulong)io->Status); But when debugging the values of io->Status don't seem to be adequate. I haven't been able to completely fix it as the code is seriously lacking of comment. To be honest i don't even completely understand what this chunk is doing and the code is so unreadable that it doesn't help (not to be harsh but just to give my humble opinion). Damien

May 19, 2005