- Dillo-dev - lists.mailman3.com

[Dillo-dev]Orthogonalize the parser (leaks, XML, CSS)

by Jorge Arellano Cid

Hi there, I'm devoted 100% to this task now. It started as a small polish and ended being a huge patch. It's incredible how tricky optional tags can get when combined into a pot of tag soup! :-) Add, memory management (almost done), validation, HTML+XML soup and you'll get the idea. I'm testing now. It seems pretty good by now, but there's a page where it hangs dillo with almost no CPU consumption. A riddle to solve... -- Cheers Jorge.-

Nov. 15, 2004

Re: [Dillo-dev]Toolkit & dillo

by Riccardo Mottola

robert w hall wrote: > > > > Suggest: use directfb combined with gtk eventually > > will that translate easily across all machine architectures? absolutely not. WHile Motif/lesstif is. -R

Nov. 15, 2004

Re: [Dillo-dev]Toolkit & dillo

by Roberto A. Foglietta

robert w hall wrote: > In article <41987D95.7010209(a)sad.it>, Roberto A. Foglietta > <roberto.foglietta(a)sad.it> writes > >>Lars Segerlund wrote: >> >>> There has been a lot of talk about toolkits and dillo, and I had a small >> >>idea. What about using lesstif ( Motif ) for dillo ? It's fairly small ( you can >>bring only the widgets you need ) and if done with some care a statically linked >>dillo would not be bloated. >> >>Suggest: use directfb combined with gtk eventually > > > will that translate easily across all machine architectures? ALL? What does it means? ;-) Before choosing a toolkit is necessary understand the target of users. What kind of usage and what kind of arch is very impostant for dillo? In my opinion Dillo is not a good project BECAUSE graphic and gtk are mixed up with HTML rendering engine and everything else. You have to split up: - html engine - cache doesn't have to depend on html engine - plugin and applet engine - users functionalities \___ gui - graphic / 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

Nov. 15, 2004

Re: [Dillo-dev]Toolkit & dillo

by robert w hall

In article <41987D95.7010209(a)sad.it>, Roberto A. Foglietta <roberto.foglietta(a)sad.it> writes >Lars Segerlund wrote: >> There has been a lot of talk about toolkits and dillo, and I had a small >idea. What about using lesstif ( Motif ) for dillo ? It's fairly small ( you can >bring only the widgets you need ) and if done with some care a statically linked >dillo would not be bloated. > > Suggest: use directfb combined with gtk eventually will that translate easily across all machine architectures? > > > Cheers, -- robert w hall

Nov. 15, 2004

Re: [Dillo-dev]Toolkit & dillo

by Roberto A. Foglietta

Lars Segerlund wrote: > There has been a lot of talk about toolkits and dillo, and I had a small idea. What about using lesstif ( Motif ) for dillo ? It's fairly small ( you can bring only the widgets you need ) and if done with some care a statically linked dillo would not be bloated. Suggest: use directfb combined with gtk eventually 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

Nov. 15, 2004

Re: [Dillo-dev]Task list & priorities

by Jorge Arellano Cid

Hi Brian, Please keep this thread on dillo-dev. On Tue, Nov 09, 2004 at 08:12:50AM -0500, Brian Hechinger wrote: > On Mon, Nov 08, 2004 at 06:15:59PM -0300, Jorge Arellano Cid wrote: > > > > Great! > > Now we have a man in charge of it. > > i would be honored. > > > str = a_Prefs_get("font_factor"); > > if (str) > > ff = strtol(str); > > g_free(str); > > i've read all your email, and it looks like mostly enough to get me started, > but i just had this thought: > > if the dpi reads all the rc files in, we're going to have to be able to > specify which rc file we want to get our config from. we need to > implement a system of scope for the rc files. i don't want the cookie > module asking if it has permission to authorize a site to use cookies > by getting it's config from the cacherc which has an identical format. > > what do you think is the best way to go about doing that? make the rc > filename a requirement in the call? > > str = a_Prefs_get("font_factor", "dillorc"); This is a good idea to start with. > > and then in the dpi just have the rc files as a linked list with an entry for > the filename to do a strcmp() on? Maybe, but remember that cookiesrc has another format. It's not a variable/value pairs list, but a list of instances of the same abstract variable (to name it somehow ;). This also needs some thought. > > also, i still need to read about dpis of course, but are they long running > processes? Dpi servers, YES. Dpi filters come and go per request. > the way i'm thinking is that we don't want the rc files read > every time a preference is needed, so the first instance of dillo will start > the config dpi running, and it will continue to run until there are no more > instances of dillo running. does this sound reasonable? Yes. In fact, that's what the bookmarks dpi server does. You don't even have to worry about launching a dpi, that's the dpid job. It's done automatically. -- Cheers Jorge.-

Nov. 9, 2004

Re: [Dillo-dev]Toolkit & dillo

by Riccardo Mottola

Hello, Lars Segerlund wrote: > > There has been a lot of talk about toolkits and dillo, and I had a small idea. What about using lesstif ( Motif ) for dillo ? It's fairly small ( you can bring only the widgets you need ) and if done with some care a statically linked dillo would not be bloated. You immediately would have a supporter! a tester and partially a coder too. > I can have a look at it, but I would like the general opinion first, ( I would even give Xt a shot :-) that way it would be FAST & SMALL ). Well, Xt is pretty extreme, maybe Xaw in case then. Anyway rememebr that most graphic part in Xm is just passed over to Xt calls. I have already proposed and welcomed a motif port. Lately I am coding a bit on my IRC application written in it and am always surprised by the speed and the cleaniness of the result GTK doesn't even get close. But Motif is tricky, do something wrong and you end with a segfault. It is quite low-level sometimes and tied to X11 quite a bit. Even if I learned quite a deal of Motif, doing a port of dillo myself would be out of reach. But I could probably help. Also I have various OSs with different Motif implementations, from 1.1 to 2.1. It's great for testing. My desperation for motif was so great that I went up to digging out mMosaic! and the last beta of it is interesting. It is so fast in the interface (menus, scrolling etc) although the parser is often inferior to dillo. I never coded a single line of Athena though. VIM supports athena, motif, gtk and lately QT even. It would be nice to be able to accomplish this in dillo too! -R

Nov. 9, 2004

[Dillo-dev]Toolkit & dillo

by Lars Segerlund

There has been a lot of talk about toolkits and dillo, and I had a small idea. What about using lesstif ( Motif ) for dillo ? It's fairly small ( you can bring only the widgets you need ) and if done with some care a statically linked dillo would not be bloated. I can have a look at it, but I would like the general opinion first, ( I would even give Xt a shot :-) that way it would be FAST & SMALL ). regards, Lars Segerlund.

Nov. 9, 2004

Re: [Dillo-dev]Task list & priorities

by Jorge Arellano Cid

Hi Brian, On Sat, Nov 06, 2004 at 11:44:48PM -0500, Brian Hechinger wrote: > On Sat, Nov 06, 2004 at 07:11:12PM -0300, Jorge Arellano Cid wrote: > > Hi there, > > Hello!! > > > > [3] Preferences dpi. > > > [3] Handling of configuration data. > > > > <Sebastian> > > I'd regard this as one task (from the user's point of view). Here, I'd > > rather focus on designing a solid base rather soon, on which future > > extensions may be build on. It is not clear yet, how this will look > > like at all, but supposed (as an example), that dillo manages the > > configuration data (not a dpi), communication with configuration dpis > > should be considered, but made possible later. > > > > (Except the feature, on which Daniel Fairhead is working.) > > > > <Jorge> > > Configuration data also needs some sync. For instance, dillorc, > > cookiesrc, cacherc, <dpis>rc. Maybe having a common format and a > > powerful preferences dpi makes sense at this stage. > > ok, i will take ahold if this one if no-one objects. i would love to > see this done, as it makes doing lots of other things much, much simpler > in the future, especially the cache thing. since the cache thing is now > going to be pretty much on hold until after the CCC study, i need something > to do in the mean-time. ;) Great! Now we have a man in charge of it. > > i don't think it should be too relevant as to if configuration is handled > by a dpi or by dillo proper, since it's just a matter of what part things > ask to get their configuration data from, as they should never have to > look at a config file themselves. it should be fairly trivial to rewrite > how things ask for their config. keep in mind i have yet to look at the > dpi system at all, so i could be completely wrong with that assumption. There's at least one big advantage of having the preferences done in a dpi server instead of Dillo (but some more come to mind :). If you have two instances of Dillo which one is in charge of preferences? If you have a dpi running, and the user exits from Dillo what happens with preferences. If there're two Dillos running we'd need to provide for Dillo to Dillo communcation. How do we handoff preferences from an old Dillo that exits to a newer instance? etc. On the plus side, a Dpi server solves those problems. The issue with this approach is how to communicate with Dillo, but we already have the dpi protocol (dpip). Which is flexible and extensible and can make this communication happen (for instance as the "chat" command in bookmarks). The rc files could all reside in ~/.dillo/ and there would be no race conditions on them (as now with cookies). For instance a simple approach (and simplicity is an asset) is something like: str = a_Prefs_get("font_factor"); if (str) ff = strtol(str); g_free(str); a_Prefs_get() could do it task by sending a dpi command: <dpi cmd='get_preference' name='font_factor'> the answer can arrive packed like this: <dpi cmd='answer' to_cmd='get_preference' name='font_factor' value='1.25'> and recovering "value" with a_Misc_get_attr_value() is trivial! > i'm assuming that being able to offer a configuration API would allow a > layer of abstraction that would hide the internals of how things are > actually done as pertaining to aquiring configuration data. Sure. > > i've got a higher priority project currently on my plate, but the way > things are looking, it shouldn't be but a couple more days until i'm > done with it, at which time i will study the dillo code at great length > and evaluate which would be the easier way (for me at least) to handle > this. Read doc/Dpid.txt. It's a good introduction. You can also have a look at Cfg.txt inside: http://www.dillo.org/misc_files/cfg-test-0.0.3.tar.gz but this is more advanced than what we need now. Anyway it may show some light of things we may require in the future. Sebastian can provide more feedback on that part although I'd regard that as part 2. > > > > [3] Make cookies into a dpi server. > > > > <Jorge> > > Procrastinated from a long time ago. This solves the problem of > > only the first Dillo instance (and its child windows) having > > cookies enabled. Now that cookies work better (with 302 > > redirections) this problem will be more evident. > > i think it may be to my advantage to tackle this task first, as it > will give me a much greater understanding of the dpi structure. that > should certainly make a configuration dpi a very simple task to get > completed. I'd advice to try to use the 'chat' command for this task, and asking me when in trouble. Getting inside the CCC at this stage is not a good idea. > > > > [5] GUI dpi for downloads. > > > > <Sebastian> > > i agree 100% with you on this, however....... > > > <Jorge> > > i think of such annoying sites as sourceforge that do all sorts of > wonky things with the url you send it that wget just doesn't properly > grok. while i certainly prefer to copy the url and give it to wget > myself, sometimes that just isn't practical. This is very simple, but needs some time. For instance, adding login information messages to the FTP dpi is a matter of calling dup2 on stderr, and dup2 into a pipe for stdout, that way the former stderr can be parsed, the pertinent 'send_status_message' commands sent into the pipe, followed by the actual data. The same applies for downloads, and there's a prototype. -- Cheers Jorge.-

Nov. 8, 2004

Re: [Dillo-dev]Task list & priorities

by Brian Hechinger

On Sat, Nov 06, 2004 at 07:11:12PM -0300, Jorge Arellano Cid wrote: > Hi there, Hello!! > > [3] Preferences dpi. > > [3] Handling of configuration data. > > <Sebastian> > I'd regard this as one task (from the user's point of view). Here, I'd > rather focus on designing a solid base rather soon, on which future > extensions may be build on. It is not clear yet, how this will look > like at all, but supposed (as an example), that dillo manages the > configuration data (not a dpi), communication with configuration dpis > should be considered, but made possible later. > > (Except the feature, on which Daniel Fairhead is working.) > > <Jorge> > Configuration data also needs some sync. For instance, dillorc, > cookiesrc, cacherc, <dpis>rc. Maybe having a common format and a > powerful preferences dpi makes sense at this stage. ok, i will take ahold if this one if no-one objects. i would love to see this done, as it makes doing lots of other things much, much simpler in the future, especially the cache thing. since the cache thing is now going to be pretty much on hold until after the CCC study, i need something to do in the mean-time. ;) i don't think it should be too relevant as to if configuration is handled by a dpi or by dillo proper, since it's just a matter of what part things ask to get their configuration data from, as they should never have to look at a config file themselves. it should be fairly trivial to rewrite how things ask for their config. keep in mind i have yet to look at the dpi system at all, so i could be completely wrong with that assumption. i'm assuming that being able to offer a configuration API would allow a layer of abstraction that would hide the internals of how things are actually done as pertaining to aquiring configuration data. i've got a higher priority project currently on my plate, but the way things are looking, it shouldn't be but a couple more days until i'm done with it, at which time i will study the dillo code at great length and evaluate which would be the easier way (for me at least) to handle this. > > [3] Make cookies into a dpi server. > > <Jorge> > Procrastinated from a long time ago. This solves the problem of > only the first Dillo instance (and its child windows) having > cookies enabled. Now that cookies work better (with 302 > redirections) this problem will be more evident. i think it may be to my advantage to tackle this task first, as it will give me a much greater understanding of the dpi structure. that should certainly make a configuration dpi a very simple task to get completed. > > [5] GUI dpi for downloads. > > <Sebastian> i agree 100% with you on this, however....... > <Jorge> i think of such annoying sites as sourceforge that do all sorts of wonky things with the url you send it that wget just doesn't properly grok. while i certainly prefer to copy the url and give it to wget myself, sometimes that just isn't practical. -brian -- IHTFP: I firmly believe that people dumber than me exist solely for my amusement. IHTFP: Okay, maybe not solely for my amusement. Some of them make good cake.

Nov. 7, 2004

[Dillo-dev]Task list & priorities

by Jorge Arellano Cid

Hi there, Here I'm attaching the draft for the priorities list we're working on with Sebastian. Note that [1] Parsing of XML empty tags (e.g <script/> as <script></script>). is already done! and I'm working on the parser to avoid memory leaks with bad HTML, to be able to get the doc tree from parsing (XML well formedness validation and hopefully good for CSS too). Let's name this one as: [1] Orthogonalize the parser (leaks, XML, CSS) And here are a few to add to the list too: [ ] Login messages for the ftp dpi. [ ] Bookmarks dpi "sort" function. [ ] Back/Forward for #anchored links. -- Cheers Jorge.- PS: Please conside all of these works when I'm sending delayed answers :-P

Nov. 6, 2004

Re: [Dillo-dev]Parsing of XML empty tags

by Jorge Arellano Cid

On Fri, Nov 05, 2004 at 05:57:16PM +0100, Matthias Franz wrote: > On Fri, Nov 05, 2004 at 10:11:21AM -0300, Jorge Arellano Cid wrote: > > Now the parser recognizes: </x>, <x /> and <x/>. (committed) > > Maybe one should do this only in w3c_plus_heuristics mode (or in > a future XML mode), for two reasons: > > Firstly, the slash "/" has a special meaning in SGML, hence in HTML, > as a so-called NET-enabling start tag. Essentially, this means that > > <x/content/ > > is equivalent to > > <x>content</x> > > (This is one of the weird features of HTML that almost no browser > supports, see http://www.cs.tut.fi/~jkorpela/html/empty.html .) > Therefore, parsing <x/> or <x /> as <x></x> makes Dillo manifestly > non-HTML-conforming. Don't worry, Dillo will never be SGML compliant! ;) Being HTML compliant (and therefore SGML compliant) involves having an SGML parser, which is too big and complex for Dillo to have. > Secondly, if I understand the HTML compatibility guidelines of Appendix C > of the XHTML 1.0 spec correctly, they suggest to use <x /> only for elements > which have no close tag in HTML, like <hr> or <br> for instance. For others, > one should use an explicit end tag. This means that one can ignore an "/" > at the end of a tag for all XHTML documents which follow these guidelines. > (But note that according to the first point these guidelines are not > compatible with SGML.) Yes, this is a known issue. Even more, "<br/>" is valid XML, notwithstanding the compatibility recommendation of writing it as "<br />". And there's the HTML "<a href=http://foo.org/>" type of tag (for instance with google). --note the final "/>". So, as usual, I tried to code a solution that accounts for most of the cases with a view to better usability. BTW, now I'm very advanced in studying a way to modify the parser to be able to generate the document tree from the tags. Basically by being more orthogonal at pushing ans popping tags. This will also serve to cut memory leaks with bad HTML. -- Cheers Jorge.-

Nov. 6, 2004

Re: [Dillo-dev]Parsing of XML empty tags

by Matthias Franz

On Fri, Nov 05, 2004 at 10:11:21AM -0300, Jorge Arellano Cid wrote: > Now the parser recognizes: </x>, <x /> and <x/>. (committed) Maybe one should do this only in w3c_plus_heuristics mode (or in a future XML mode), for two reasons: Firstly, the slash "/" has a special meaning in SGML, hence in HTML, as a so-called NET-enabling start tag. Essentially, this means that <x/content/ is equivalent to <x>content</x> (This is one of the weird features of HTML that almost no browser supports, see http://www.cs.tut.fi/~jkorpela/html/empty.html .) Therefore, parsing <x/> or <x /> as <x></x> makes Dillo manifestly non-HTML-conforming. Secondly, if I understand the HTML compatibility guidelines of Appendix C of the XHTML 1.0 spec correctly, they suggest to use <x /> only for elements which have no close tag in HTML, like <hr> or <br> for instance. For others, one should use an explicit end tag. This means that one can ignore an "/" at the end of a tag for all XHTML documents which follow these guidelines. (But note that according to the first point these guidelines are not compatible with SGML.) All the best, -- Matthias Franz Section de Mathématiques, Université de Genève, Suisse

Nov. 5, 2004

Re: [Dillo-dev]Parsing of XML empty tags (e.g <script/> as <script></script>).

by Brian Hechinger

On Thu, Nov 04, 2004 at 07:28:16PM -0300, Jorge Arellano Cid wrote: > Topic change (cache control): > > Brian: Take a look at BUG#161, Madis worked on the same problem > long ago. Some ideas may be saved... I'm not saying the patch is > wrong, I just happened to notice this entry while skimming. ok, i've got a copy. i'm going to put this on hold until a decision is made for configuration stuffs however, since i would like to get that written first before i continue with cache control. -brian -- IHTFP: I firmly believe that people dumber than me exist solely for my amusement. IHTFP: Okay, maybe not solely for my amusement. Some of them make good cake.

Nov. 5, 2004

Re: [Dillo-dev]Parsing of XML empty tags (e.g <script/> as <script></script>).

by Jorge Arellano Cid

On Thu, Nov 04, 2004 at 07:28:16PM -0300, Jorge Arellano Cid wrote: > Hi there, > > Well, the priorities list draft had this one with top priority > (among others): > > <q> > [1] Parsing of XML empty tags (e.g <script/> as <script></script>). > </q> > > [...] > Unto the bug, it's BUG#514 and seems also #587. It needs some > testing. As a matter of fact I had to fix the patch because google's answer links were not being rendered. Now the parser recognizes: </x>, <x /> and <x/>. (committed) -- Cheers Jorge.-

Nov. 5, 2004

[Dillo-dev]dpi menu and inteface hadling question

by Diego Sáenz

I have made some proof of concept about dpi menu handling with a patch that add a dpi command that add a toolbar item/button and some test commands. ¿must i continue with menus or must i wait for fltk port and universal ccc implementation? The attached files are the b2ziped patch and a b2ziped and tared directory tree with some test files. Look at the second attachment for the dpi command. To test use the patch (works from cvs 2004-09-18 to current cvs), uncompres the directory in a /home/SOME_USER/.dillo/dpi/ directory, run the patched dillo and put dpi:/dpitest/ in the location bar. Then you can use the buttons that apear in the toolbar. Please if you have any suggestion reply and say it. I am open to change even command name :) If dillo suported onevent and css or javascript all the dillo interface could be a html page with an iframe(or something like that) that contain the site viewed. An external dpi or program could modify the interface page to add buttons or menu items when dpis ask for it and say to dillo to refresh interface page. I think this is the way that less code add to dillo but it is imposible for now and waste a few mem. DarkSpirit/Diego Saenz PD: sorry for my english

Nov. 4, 2004

[Dillo-dev]Parsing of XML empty tags (e.g <script/> as <script></script>).

by Jorge Arellano Cid

Hi there, Well, the priorities list draft had this one with top priority (among others): <q> [1] Parsing of XML empty tags (e.g <script/> as <script></script>). </q> I'll post the priorities draft tomorrow for you to read, probably before Sebastian has a chance to review it... Unto the bug, it's BUG#514 and seems also #587. It needs some testing. Thorben: Do you have a test page for #587? --- Topic change (cache control): Brian: Take a look at BUG#161, Madis worked on the same problem long ago. Some ideas may be saved... I'm not saying the patch is wrong, I just happened to notice this entry while skimming. -- Cheers Jorge.-

Nov. 4, 2004

Re: [Dillo-dev]Memory leak bug

by Jorge Arellano Cid

On Wed, Nov 03, 2004 at 09:32:15AM +0100, Roberto A. Foglietta wrote: > Roberto A. Foglietta wrote: > >Hi, > > > > I didn't find memory leak bug but I have to say this: waiting html page > >load complete doesn't help. > > > > I have done a patch which after first load doesn't show images BUT I > >lost it because I didn't care it... But when I saw my logs I see that > >patch fixed memory leak. Even if memory leak has nothing to do with > >images because trivial pages has no images. Probably 4kb is a structure > >not data. > > > > Thinking memory leak is generated by losing a structure instead data > >could explain why has fixed size (4kb for each reload) and probably why > >it happen only during a reload. In reload some data is cached but > >structures a created and destroyed... probably not all of them. > > > > Unfortunately it's time I have to find another browser to use it in my > >project. Sorry. > > Suggest: > > http://valgrind.kde.org/overview.html Yes, I haven't used it in a long time. Good to remember. After upgrading to valgrind-2.2.0, and testing, it detected two minor leaks in Dillo (fixed now in CVS), but these were not the cause for the "reload" leak. After that, I got no more leak errors detected inside Dillo (while testing a trivial page with 12 reloads) with: valgrind --tool=addrcheck --leak-check=yes ./dillo /tmp Interesting to note is this one in GTK+: ==9413== ==9413== ==9413== 2816 bytes in 36 blocks are definitely lost in loss record 47 of 54 ==9413== at 0x34148F1D: calloc (in /usr/lib/valgrind/vgpreload_addrcheck.so) ==9413== by 0x34343F2A: g_malloc0 (in /usr/lib/libglib-1.2.so.0.0.10) ==9413== by 0x342C12AA: gtk_type_new (in /usr/lib/libgtk-1.2.so.0.9.1) ==9413== by 0x34284C27: gtk_pixmap_new (in /usr/lib/libgtk-1.2.so.0.9.1) ==9413== -- Cheers Jorge.-

Nov. 3, 2004

Re: [Dillo-dev]Memory leak bug

by Roberto A. Foglietta

Roberto A. Foglietta wrote: > Hi, > > I didn't find memory leak bug but I have to say this: waiting html page > load complete doesn't help. > > I have done a patch which after first load doesn't show images BUT I > lost it because I didn't care it... But when I saw my logs I see that > patch fixed memory leak. Even if memory leak has nothing to do with > images because trivial pages has no images. Probably 4kb is a structure > not data. > > Thinking memory leak is generated by losing a structure instead data > could explain why has fixed size (4kb for each reload) and probably why > it happen only during a reload. In reload some data is cached but > structures a created and destroyed... probably not all of them. > > Unfortunately it's time I have to find another browser to use it in my > project. Sorry. Suggest: http://valgrind.kde.org/overview.html 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

Nov. 3, 2004

[Dillo-dev]dillo.c patch

by Russell J. Wood

Hello all, Attached is a patch for dillo.c that merely ensures all command line arguments are parsed and complete before the GUI environment. Previous to this, the locale and GUI functions where run and then the command line, of which, in my opinion, should be run after the CLI because the CLI has the immediate commands. There is no point firing up the GUI when all one would like to know is the version they are running, right? Again, it's nothing major and doubtfully increases performance in any way. Regards, Russell

Nov. 3, 2004

[Dillo-dev]Memory leak bug

by Roberto A. Foglietta

Hi, I didn't find memory leak bug but I have to say this: waiting html page load complete doesn't help. I have done a patch which after first load doesn't show images BUT I lost it because I didn't care it... But when I saw my logs I see that patch fixed memory leak. Even if memory leak has nothing to do with images because trivial pages has no images. Probably 4kb is a structure not data. Thinking memory leak is generated by losing a structure instead data could explain why has fixed size (4kb for each reload) and probably why it happen only during a reload. In reload some data is cached but structures a created and destroyed... probably not all of them. Unfortunately it's time I have to find another browser to use it in my project. Sorry. 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

Nov. 2, 2004

Re: [Dillo-dev]protocol handler dpi for mailto:, etc.

by Jorge Arellano Cid

On Sun, Oct 31, 2004 at 10:41:14AM -0330, Lee Bigelow wrote: > Hello again, Hi! > I did up a proto-type bash shell dpi for handling > unsupported protocols, like mailto:, with external > applications. I called it xproto. > > It uses the config file $HOME/dillo/protorc to > decide what to do. The plugin will make a default > one you can edit when it's first run. > > I'm working on the C version, but I'm just > learning C, so it'll take me a bit. Good you made a prototype. Dpi isn't that hard to program and I hope your code will encourage more developers to try it. > > One thing I can't seem to figure out is how to > send a url from the plugin to dillo and have dillo > display that page. For example I would like the > url gg:water to send dillo > http://www.google.com/search?q=water For now I > just have it open up another dillo. I tried > sending <dpi cmd="open_url" > url="http://www.google.com/search?q=water"> but > that didn't work, booo. Try the small patch below. It's a no frills version to keep you going on... Beware that there's a safety test in the function: Capi_verify_dpi_url_request() (Safety test: only allow dpi-urls from dpi-generated pages.) To avoid the "permission denied" message, while testing the patch, I asked for bookmarks (dpi generated page) and then the hello dpi (that was modified to send 'open_url'). If this is too much trouble, just disable the safety test! :-) > > Again, xproto.filter.dpi is just a shell script, > so play away. If you have any hints on the gg: > thing let me know, please... Please post the next prototype as an URL. If you don't have access to a web server please ask Jörgen to put it on our downloads directory. Sometime ago someone asked about how to make a slide show with dpi. Another thing to have in mind is how to tell a running Dillo to display another URL (for instance for sylpheed, or slides, or help manual apps.). Please try the small patch. That's the basis, details need to be thought better. ... & tell us how it works for you! -- Cheers Jorge.-

Nov. 1, 2004

[Dillo-dev]protocol handler dpi for mailto:, etc.

by Lee Bigelow

Hello again, I did up a proto-type bash shell dpi for handling unsupported protocols, like mailto:, with external applications. I called it xproto. It uses the config file $HOME/dillo/protorc to decide what to do. The plugin will make a default one you can edit when it's first run. I'm working on the C version, but I'm just learning C, so it'll take me a bit. One thing I can't seem to figure out is how to send a url from the plugin to dillo and have dillo display that page. For example I would like the url gg:water to send dillo http://www.google.com/search?q=water For now I just have it open up another dillo. I tried sending <dpi cmd="open_url" url="http://www.google.com/search?q=water"> but that didn't work, booo. Again, xproto.filter.dpi is just a shell script, so play away. If you have any hints on the gg: thing let me know, please... The patch, against dillo-0.8.2: -------------------------------------- diff -pruN dillo-0.8.2/dpi/Makefile.am dillo-0.8.2-xproto/dpi/Makefile.am --- dillo-0.8.2/dpi/Makefile.am 2004-01-29 17:04:05.000000000 -0330 +++ dillo-0.8.2-xproto/dpi/Makefile.am 2004-10-31 09:51:39.000000000 -0330 @@ -5,11 +5,13 @@ downloadsdir = $(libdir)/dillo/dpi/downl ftpdir = $(libdir)/dillo/dpi/ftp httpsdir = $(libdir)/dillo/dpi/https hellodir = $(libdir)/dillo/dpi/hello +xprotodir = $(libdir)/dillo/dpi/xproto bookmarks_PROGRAMS = bookmarks.dpi downloads_PROGRAMS = downloads.dpi ftp_PROGRAMS = ftp.filter.dpi https_PROGRAMS = https.filter.dpi hello_PROGRAMS = hello.filter.dpi +xproto_PROGRAMS = xproto.filter.dpi bookmarks_dpi_LDADD = @GLIB_LIBS@ downloads_dpi_LDADD = @GLIB_LIBS@ diff -pruN dillo-0.8.2/dpi/Makefile.in dillo-0.8.2-xproto/dpi/Makefile.in --- dillo-0.8.2/dpi/Makefile.in 2004-07-06 14:31:24.000000000 -0230 +++ dillo-0.8.2-xproto/dpi/Makefile.in 2004-10-31 10:18:28.000000000 -0330 @@ -44,6 +44,7 @@ downloads_PROGRAMS = downloads.dpi$(EXEE ftp_PROGRAMS = ftp.filter.dpi$(EXEEXT) https_PROGRAMS = https.filter.dpi$(EXEEXT) hello_PROGRAMS = hello.filter.dpi$(EXEEXT) +xproto_PROGRAMS = xproto.filter.dpi$(EXEEXT) subdir = dpi DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in ACLOCAL_M4 = $(top_srcdir)/aclocal.m4 @@ -53,14 +54,15 @@ am__configure_deps = $(am__aclocal_m4_de mkinstalldirs = $(mkdir_p) CONFIG_HEADER = $(top_builddir)/config.h CONFIG_CLEAN_FILES = -am__installdirs = "$(DESTDIR)$(bookmarksdir)" "$(DESTDIR)$(downloadsdir)" "$(DESTDIR)$(ftpdir)" "$(DESTDIR)$(hellodir)" "$(DESTDIR)$(httpsdir)" +am__installdirs = "$(DESTDIR)$(bookmarksdir)" "$(DESTDIR)$(downloadsdir)" "$(DESTDIR)$(ftpdir)" "$(DESTDIR)$(xprotodir)" "$(DESTDIR)$(hellodir)" "$(DESTDIR)$(httpsdir)" bookmarksPROGRAMS_INSTALL = $(INSTALL_PROGRAM) downloadsPROGRAMS_INSTALL = $(INSTALL_PROGRAM) ftpPROGRAMS_INSTALL = $(INSTALL_PROGRAM) helloPROGRAMS_INSTALL = $(INSTALL_PROGRAM) +xprotoPROGRAMS_INSTALL = $(INSTALL_PROGRAM) httpsPROGRAMS_INSTALL = $(INSTALL_PROGRAM) PROGRAMS = $(bookmarks_PROGRAMS) $(downloads_PROGRAMS) $(ftp_PROGRAMS) \ - $(hello_PROGRAMS) $(https_PROGRAMS) + $(xproto_PROGRAMS) $(hello_PROGRAMS) $(https_PROGRAMS) am_bookmarks_dpi_OBJECTS = bookmarks.$(OBJEXT) bookmarks_dpi_OBJECTS = $(am_bookmarks_dpi_OBJECTS) bookmarks_dpi_DEPENDENCIES = @@ -81,7 +83,7 @@ depcomp = $(SHELL) $(top_srcdir)/depcomp am__depfiles_maybe = depfiles @AMDEP_TRUE@DEP_FILES = ./$(DEPDIR)/bookmarks.Po \ @AMDEP_TRUE@ ./$(DEPDIR)/downloads.Po ./$(DEPDIR)/ftp.Po \ -@AMDEP_TRUE@ ./$(DEPDIR)/hello.Po ./$(DEPDIR)/https.Po +@AMDEP_TRUE@ ./$(DEPDIR)/hello.Po ./$(DEPDIR)/https.Po COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \ $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) CCLD = $(CC) @@ -198,6 +200,7 @@ downloadsdir = $(libdir)/dillo/dpi/downl ftpdir = $(libdir)/dillo/dpi/ftp httpsdir = $(libdir)/dillo/dpi/https hellodir = $(libdir)/dillo/dpi/hello +xprotodir = $(libdir)/dillo/dpi/xproto bookmarks_dpi_LDADD = @GLIB_LIBS@ downloads_dpi_LDADD = @GLIB_LIBS@ ftp_filter_dpi_LDADD = @GLIB_LIBS@ @@ -333,6 +336,28 @@ uninstall-helloPROGRAMS: clean-helloPROGRAMS: -test -z "$(hello_PROGRAMS)" || rm -f $(hello_PROGRAMS) + +install-xprotoPROGRAMS: $(xproto_PROGRAMS) + @$(NORMAL_INSTALL) + test -z "$(xprotodir)" || $(mkdir_p) "$(DESTDIR)$(xprotodir)" + @list='$(xproto_PROGRAMS)'; for p in $$list; do \ + p1=`echo $$p|sed 's/$(EXEEXT)$$//'`; \ + if test -f $$p \ + ; then \ + f=`echo "$$p1" | sed 's,^.*/,,;$(transform);s/$$/$(EXEEXT)/'`; \ + echo " $(INSTALL_PROGRAM_ENV) $(xprotoPROGRAMS_INSTALL) '$$p' '$(DESTDIR)$(xprotodir)/$$f'"; \ + $(INSTALL_PROGRAM_ENV) $(xprotoPROGRAMS_INSTALL) "$$p" "$(DESTDIR)$(xprotodir)/$$f" || exit 1; \ + else :; fi; \ + done + +uninstall-xprotoPROGRAMS: + @$(NORMAL_UNINSTALL) + @list='$(xproto_PROGRAMS)'; for p in $$list; do \ + f=`echo "$$p" | sed 's,^.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/'`; \ + echo " rm -f '$(DESTDIR)$(xprotodir)/$$f'"; \ + rm -f "$(DESTDIR)$(xprotodir)/$$f"; \ + done + install-httpsPROGRAMS: $(https_PROGRAMS) @$(NORMAL_INSTALL) test -z "$(httpsdir)" || $(mkdir_p) "$(DESTDIR)$(httpsdir)" @@ -480,7 +505,7 @@ check-am: all-am check: check-am all-am: Makefile $(PROGRAMS) installdirs: - for dir in "$(DESTDIR)$(bookmarksdir)" "$(DESTDIR)$(downloadsdir)" "$(DESTDIR)$(ftpdir)" "$(DESTDIR)$(hellodir)" "$(DESTDIR)$(httpsdir)"; do \ + for dir in "$(DESTDIR)$(bookmarksdir)" "$(DESTDIR)$(downloadsdir)" "$(DESTDIR)$(ftpdir)" "$(DESTDIR)$(xprotodir)" "$(DESTDIR)$(hellodir)" "$(DESTDIR)$(httpsdir)"; do \ test -z "$$dir" || $(mkdir_p) "$$dir"; \ done install: install-am @@ -530,7 +555,7 @@ info: info-am info-am: install-data-am: install-bookmarksPROGRAMS install-downloadsPROGRAMS \ - install-ftpPROGRAMS install-helloPROGRAMS \ + install-ftpPROGRAMS install-helloPROGRAMS install-xprotoPROGRAMS \ install-httpsPROGRAMS install-exec-am: @@ -560,7 +585,7 @@ ps-am: uninstall-am: uninstall-bookmarksPROGRAMS uninstall-downloadsPROGRAMS \ uninstall-ftpPROGRAMS uninstall-helloPROGRAMS \ - uninstall-httpsPROGRAMS uninstall-info-am + uninstall-httpsPROGRAMS uninstall-xprotoPROGRAMS uninstall-info-am .PHONY: CTAGS GTAGS all all-am check check-am clean \ clean-bookmarksPROGRAMS clean-downloadsPROGRAMS \ @@ -570,14 +595,14 @@ uninstall-am: uninstall-bookmarksPROGRAM html-am info info-am install install-am \ install-bookmarksPROGRAMS install-data install-data-am \ install-downloadsPROGRAMS install-exec install-exec-am \ - install-ftpPROGRAMS install-helloPROGRAMS \ + install-ftpPROGRAMS install-xprotoPROGRAMS install-helloPROGRAMS \ install-httpsPROGRAMS install-info install-info-am install-man \ install-strip installcheck installcheck-am installdirs \ maintainer-clean maintainer-clean-generic mostlyclean \ mostlyclean-compile mostlyclean-generic pdf pdf-am ps ps-am \ tags uninstall uninstall-am uninstall-bookmarksPROGRAMS \ uninstall-downloadsPROGRAMS uninstall-ftpPROGRAMS \ - uninstall-helloPROGRAMS uninstall-httpsPROGRAMS \ + uninstall-xprotoPROGRAMS uninstall-helloPROGRAMS uninstall-httpsPROGRAMS \ uninstall-info-am # Tell versions [3.59,3.63) of GNU make to not export all variables. diff -pruN dillo-0.8.2/dpi/xproto.filter.dpi dillo-0.8.2-xproto/dpi/xproto.filter.dpi --- dillo-0.8.2/dpi/xproto.filter.dpi 1969-12-31 20:30:00.000000000 -0330 +++ dillo-0.8.2-xproto/dpi/xproto.filter.dpi 2004-10-31 09:44:40.000000000 -0330 @@ -0,0 +1,64 @@ +#!/bin/bash +read -d'>' dpip_tag + +url=${dpip_tag##*url=\'} +url=${url%\'} +dproto=${url%%:*} +ddata=${url#*:} + +confdir="$HOME/.dillo" +if [ ! -d "$confdir" ]; then + if ! mkdir $confdir; then + msg="Error, could not make directory $confdir" + fi +else + conffile="$confdir/xprotorc" +fi + +if [ "$conffile" ]; then + if [ ! -e "$conffile" ]; then + echo " +# %d is replaced with just the data after the : +# %s is replaced with the full url +ed2k; ed2k.sh %s +mailto; sylpheed --compose %d +rtsp; realplay %s +gg; dillo http://www.google.com/search?q=%d" > $conffile + fi + if [ -e "$conffile" ]; then + while read line; do + line=${line%%#*} + fproto=${line%%;*} + if [ x"$fproto" = x"$dproto" ]; then + handler=${line#*;} + break + fi + done < $conffile + else + msg="Error, could not create file $conffile" + fi +fi + +if [ "$handler" ]; then + handler=${handler//\\%s/"$url"} + handler=${handler//\\%d/"$ddata"} + msg="Using: $handler" + output=$($handler &) +else + msg="No handler registered for protocol: $dproto +Please edit the config file: $conffile" +fi + +cat <<EOF +<dpi cmd="start_send_page" url="dpi:/xproto/xproto.filter.dpi"> +Content-type: text/html + +<html> +<head><title>Xproto Feedback</title></head> +<body> +<hr><h1>Xproto Feedback</hq><hr> +<pre>$msg</pre> +<h3>Command Output, If Any:</h3> +<pre>$output</pre> +</body></html> +EOF diff -pruN dillo-0.8.2/src/capi.c dillo-0.8.2-xproto/src/capi.c --- dillo-0.8.2/src/capi.c 2004-05-21 19:43:07.000000000 -0230 +++ dillo-0.8.2-xproto/src/capi.c 2004-10-31 06:03:28.000000000 -0330 @@ -247,6 +247,9 @@ gint a_Capi_url_uses_dpi(gchar *url_str, } else if (g_strncasecmp(url_str, "https:/", 7) == 0) { server = g_strdup("https"); + + } else { + server = g_strdup("xproto"); } return ((*server_ptr = server) ? 1 : 0); diff -pruN dillo-0.8.2/src/IO/Url.c dillo-0.8.2-xproto/src/IO/Url.c --- dillo-0.8.2/src/IO/Url.c 2004-05-21 19:43:29.000000000 -0230 +++ dillo-0.8.2-xproto/src/IO/Url.c 2004-10-31 06:19:57.000000000 -0330 @@ -108,6 +108,6 @@ ChainFunction_t a_Url_get_ccc_funct(cons if ( j == KeyLen ) return cccList[i].cccFunction; } - return NULL; + return a_Dpi_ccc; } -- Lee Bigelow Blatch Enterprises <ligelowbee(a)yahoo.com>

Oct. 31, 2004

Re: [Dillo-dev]meta refresh patch for 0.8.2

by Brian Hechinger

On Fri, Oct 29, 2004 at 02:58:20PM -0300, Jorge Arellano Cid wrote: > Hi Brian, > > Sorry for the delayed answer, I had a lot of work with the > release and now I'm trying to catch up. not a problem. > Cookies will most probably end being a dpi server (to solve the > problem of enabling cookies in multiple Dillo instances). This > was planned long ago and hasn't been realized because of lack of > manpower (aka priorities :-). ok. > The configuration data problem (cacherc, cookiesrc, dillorc, > <dpi-name>rc) is also a general issue that we're considering with > Sebastian. Maybe it will all end in a generic preferences dpi; > this needs some further thought. ok, in that case, i'm going to leave things as they are the way i did them for now, when it is decided how configuration will be handled, i'd be more than happy to work on that to get it done. > Soon a prioritized task list will be available in dillo-dev (I > just sent back a good draft to Seb.). This account for what we, > the core developers, will be doing the next months. ok, i can't wait!! > The good news is that tasks that get lower priorities can be > advanced by the interested volunteers. you can count me in on this as well. > Please stay tuned, we're trying to cope with all the work we > have, by organizing the work. The cache issues intersect with SSL > (needs cache control), preferences handling, cookies dpi server, > and the universal CCC branch idea). When the commented task list > is posted, you'll get the idea. ok, at that point we can start discussing how things will be done as relates to what i've been working on. i'll wait till then! -brian -- IHTFP: I firmly believe that people dumber than me exist solely for my amusement. IHTFP: Okay, maybe not solely for my amusement. Some of them make good cake.

Oct. 30, 2004

[Dillo-dev]unsubscribe methods

by Patrick Shanahan

* Haines Brown <brownh(a)hartford-hwp.com> [10-29-04 19:40]: > I've tried to get myself unsubscribed to this list (to which someone > kindly subscribed me without my knowledge or permission), by emailing > the admistrator, but it seems my letter ended up on hold > somewhere. Would somone kindly suggest an alternative method for me to > unsubscribe? There's no facility on the web page for doing so. there is a mailto address in every header from dillo-dev and webpage provision in the trailer mailto:dillo-dev-request@lists.auriga.wearlab.de?subject=unsubscribe http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev directions for unsubing appear in the bottom section of the web page. ps: it is also common curtesy to give a subject indicative of the message content and to *not* hijack threads. Please have a good day and remember: read the instructions provided. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/photos

Oct. 30, 2004

Re: [Dillo-dev]Memory leak bug (was dillo-0.8.3)

by brownh＠hartford-hwp.com

I've tried to get myself unsubscribed to this list (to which someone kindly subscribed me without my knowledge or permission), by emailing the admistrator, but it seems my letter ended up on hold somewhere. Would somone kindly suggest an alternative method for me to unsubscribe? There's no facility on the web page for doing so. Haines Brown

Oct. 29, 2004

Re: [Dillo-dev]meta refresh patch for 0.8.2

by Jorge Arellano Cid

Hi Brian, Sorry for the delayed answer, I had a lot of work with the release and now I'm trying to catch up. On Thu, Oct 28, 2004 at 12:17:29PM -0400, Brian Hechinger wrote: > On Thu, Oct 28, 2004 at 04:20:29PM +0200, Diego S?enz wrote: > > What is the difference between CACHE_ACCEPT and CACHE_ACCEPT_SESSION? > > nothing, i just wanted to keep the code as identical to the original cookie > version for now until it is decided what is going to be done with that hunk > of code. Cookies will most probably end being a dpi server (to solve the problem of enabling cookies in multiple Dillo instances). This was planned long ago and hasn't been realized because of lack of manpower (aka priorities :-). The configuration data problem (cacherc, cookiesrc, dillorc, <dpi-name>rc) is also a general issue that we're considering with Sebastian. Maybe it will all end in a generic preferences dpi; this needs some further thought. Soon a prioritized task list will be available in dillo-dev (I just sent back a good draft to Seb.). This account for what we, the core developers, will be doing the next months. The good news is that tasks that get lower priorities can be advanced by the interested volunteers. Please stay tuned, we're trying to cope with all the work we have, by organizing the work. The cache issues intersect with SSL (needs cache control), preferences handling, cookies dpi server, and the universal CCC branch idea). When the commented task list is posted, you'll get the idea. -- Cheers Jorge.-

Oct. 29, 2004

[Dillo-dev]Proper XHTML (was Re: dillo patch: anchor names)

by Kelson Vibber

Jorge Arellano Cid wrote: > BTW, it's hard to find a site that serves XHTML as > "application/xhtml+xml", that's not intended for testing. I think within the web design/web standards blogging community, you're more likely to find them. There was a "hall of fame"-type list someone did a while back, though I can't remember what it was called or where it was. Wordpress generates valid XHTML by default and sends it as text/html -- but some of the more standards-zealous and/or technically-inclined WP users have modified their sites to send the proper mime type when appropriate. (I haven't since I still don't quite trust user-supplied text not to break the XHTML -- but several sections of my site do.) Also, XHTML sites are going to be hard to find with a browser that doesn't support it, because most sites that *do* use the proper mime type use content negotiation to decide which mime type to send. This is the only way to keep the site visible to HTML-only browsers like that IE thing some people still use ;-). So unless your UA's HTTP Accept: header includes application/xhtml+xml, it won't see many sites using that mime type. > Maybe a partial validation can serve the standards compliance > objective. I mean, for instance: proper nesting, lowercase tags, > tag names in the XHTML namespace. Not much more than that. I don't recall exactly what the spec states, but from experience with Gecko browsers the main issue with broken XHTML appears to be with pages that aren't *well-formed*. So tossing in an unfamiliar attribute may break validation, but it's still well-formed XML (all tags nested and closed properly, including <img/>, <br/>, <meta/>, etc.) so the page will still display. The main errors I've noticed Mozilla complaining about are misnesting, missing closing tags, and undefined character entities. On a related note: is there a reason Dillo doesn't send an Accept: header? I'd think that something basic like "text/html, image/png, image/jpeg, image/gif, text/plain;q=0.9" with an optional ", */*;q=0.1" at the end would be about right. -- Kelson Vibber www.hyperborea.org

Oct. 29, 2004

Re: [Dillo-dev]Memory leak bug (was dillo-0.8.3)

by Roberto A. Foglietta

Jorge Arellano Cid wrote: > On Wed, Oct 27, 2004 at 07:58:36PM +0100, robert w hall wrote: > >>In article <417FCFE6.8040306(a)sad.it>, Roberto A. Foglietta >><roberto.foglietta(a)sad.it> writes >> >>>[...] >>>Sorry to inform you but v0.8.3 (far from, at least v0.8.2) has a >>>memory leak bug. >>> >>>Clicking on reload button used memory increase around 4kb for each >>>click. Stop clicking make used memory increasing stop too. So increase >>>memory size of dillo depends on reloads but not following links. >> >> >>Hmm - could this be distro/kernel dependent? > > > I don't think so. > > On the same machine, my testing shows no leak with 'http', but > leaks with 'file' and 'hello'. It looks like a leak in the dpi > branch. I'm working hard on it but it'very difficult... ...IMHO could be a_Web_free(web); in a_Capi_url_uses_dpi because moving out of that function the free (who make malloc, make free - policy) I see a lot of strange behaviure e segmentation fault in about:splash. The reason is because not all pointer freed are immediately set to NULL value. 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

Oct. 29, 2004

Re: [Dillo-dev]Memory leak bug (was dillo-0.8.3)

by Jorge Arellano Cid

On Wed, Oct 27, 2004 at 07:58:36PM +0100, robert w hall wrote: > In article <417FCFE6.8040306(a)sad.it>, Roberto A. Foglietta > <roberto.foglietta(a)sad.it> writes > > [...] > > Sorry to inform you but v0.8.3 (far from, at least v0.8.2) has a > >memory leak bug. > > > > Clicking on reload button used memory increase around 4kb for each > >click. Stop clicking make used memory increasing stop too. So increase > >memory size of dillo depends on reloads but not following links. > > > Hmm - could this be distro/kernel dependent? I don't think so. On the same machine, my testing shows no leak with 'http', but leaks with 'file' and 'hello'. It looks like a leak in the dpi branch. Does anyone know whether g_mem_profile can help to track this down? -- Cheers Jorge.-

Oct. 29, 2004

Re: [Dillo-dev]news about memory leak

by Roberto A. Foglietta

Riccardo Mottola wrote: > Hey, > > I am on a NetBSD/ppc system. DIllo 0.8.3 and can reproduce the leak. I > noted however that: > > - clicking the reload button in thight succession gets an increment of > about 4K every time > - the leak is consitent, you can make the amount of leaked memory > skyrocket to megabytes. > - clicking slowly, waitning 10 seconds each time does NOT make dillo > leak > > I suspect the leak happens if you click reload before dillo has > "finished" the page and the "stop button" is disabled. > What is the best way to check if a page has been load completely? I mean checking BrowserWidows or DilloUrl structures... 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

Oct. 29, 2004

Re: [Dillo-dev]Protocol Handlers

by Jorge Arellano Cid

Hi, On Thu, Oct 28, 2004 at 04:07:06AM -0230, Lee Bigelow wrote: > Hello there, I was playing with the dpi's and > made one for ed2k:// links (based on the Hello > World example). It was just a quicky, and not > generally useful, but I was wondering if anyone > was working on a general protocol handler. This is a good idea and some prototypes have been tried in the past. It'd be very good to implement this as a dpi. Please read: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2004-October/002278.html and ask Matthias (and Lars IIRC). If you're interested I can answer/develop/help with the dpi part. > > Along these lines: > > - Dillo doesn't recognize the protocol so sends it > to say external.dpi > > - external.dpi reads an external.conf file that > has a list of protocols and respective > external handlers. > > - If it finds a matching protocol it sends > the url(%s), or just the url data (%r), to > the handler. > > - If there's no matching > protocol it could show an edit page (like > bookmarks modify) for the external.conf. > > This could be used for mailto:, nntp:, telnet:, > etc.. > > Anyhow, I starting playing with it, and I > thought I should check to see if anyone else was > also working on it before I went any further. > > Also, if there's any advice on the approach, or > code I should look at, that would be cool. I am > no expert C programer, I'm just reading the docs > and modifying the code the other fellows already > did. (I hope that's ok) Yes, that's OK, and good for the project. :-) -- Cheers Jorge.-

Oct. 28, 2004

[Dillo-dev]CYGWIN compatibility

by Jorge Arellano Cid

Hi, Sometime ago I forwarded this message to dillo-dev: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2004-October/002295.html <q> Hi anyone, I successfully compiled and installed dillo-0.8.2 on an AMD K7 600MHz: $ uname -a CYGWIN_NT-5.0 fermat 1.5.11(0.116/4/2) 2004-09-04 23:17 i686 unknown unknown Cygwin It runs very well, so you can update your compatibility file ;) Greetings, Marianne </q> Has anyone contacted Marianne to know the recipe? -- Cheers Jorge.-

Oct. 28, 2004

Re: [Dillo-dev]Re: dillo patch: anchor names

by Jorge Arellano Cid

Matthias, Please excuse me for the delayed answer. I had a hard time fixing release candidates for the dillo-0.8.3 release... On Tue, Oct 19, 2004 at 12:03:17PM +0200, Matthias Franz wrote: > Hi Richard, > > thanks for your comments! Yes, very interesting. > > On Fri, Oct 15, 2004 at 04:35:29PM -0400, Richard Page-Wood wrote: > > I do know a bit about HTML and XHTML, though, and I was wondering > > about your doctype-sniffing patch. As I understand it, you're trying > > to distinguish between HTML 4.01 and XHTML 1.x by sniffing the doctype > > and giving appropriate warnings for invalid markup. Are you also going > > to alter the rendering for XHTML? > > Certainly not as part of my patch. It's origin was simply the > observation that Dillo refused anchor names like "Dürst" which are > allowed in HTML if defined with the "name" attribute (see Section 12.2.3 > of the HTML 4.01 spec). > > > There's a good article here: > > > > http://www.hixie.ch/advocacy/xhtml > > > > which talks amongst other things about the impossibility of correctly > > identifying an XHTML document which might be of interest to you. > > Having looked at this article and the references given therein, I don't > feel anymore that it would be a good idea to try and figure out whether > the document type is HTML or XHTML. > > I still like the idea of supporting XHTML in some way, mostly because XML > lacks many of the strange features of SGML that make parsing difficult. > For example, "<" and "&" are not allowed as ordinary characters in XML. > But this has nothing to do with anchor names, so I will remove the XHTML > parts of the patch (unless someone complains). > > Jorge: Are you still interested in evaluating <!DOCTYPE> to figure out > the HTML version? Maybe it would be ok for a small browser like Dillo > to stick to HTML 4.01. Could be... As the suggested document explains, there's not a big gain in serving XHTML as such, and nowadays most of it is served as "text/html". BTW, it's hard to find a site that serves XHTML as "application/xhtml+xml", that's not intended for testing. In our case the "detection" was just to try to provide a hintful HTML/XHTML warning. The easy solution is not to raise a warning or to send it to extra warnings ;). What worries me a bit more is what to do with XHTML served with the proper MIME type. Currently it's not rendered at all, though Dillo can perfectly cope with it. The reason is that the XHTML SPEC requires a validating client, and as Dillo doesn't include a formal XML parser this is not possible. Today this is not a problem because such sites are very seldom found. Maybe a partial validation can serve the standards compliance objective. I mean, for instance: proper nesting, lowercase tags, tag names in the XHTML namespace. Not much more than that. Perhaps MIME type detection, plus some doctype sniffing (to have "an idea" of whether we are dealing with HTML 2.0, 3.2, 4.0, 4.1 or XHTML), and having that information in a structure like the one suggested in the former mail could serve to fine tune a bit the warning messages (or parser behaviour). For instance having that info, in the case of anchor names can lead to something as simple as: if (!isalpha(val[0]) && doctype == DOCTYPE_XHTML) MSG_HTML("first character of '%s' value is outside" " the [A-Za-z] set\n", attrname); Just make the patch with comment where this messages should go. With the fuzzy detection code in place it'll be a matter of binding. Not the highest priority, but easy to merge. -- Cheers Jorge.-

Oct. 28, 2004

Re: [Dillo-dev]meta refresh patch for 0.8.2

by Brian Hechinger

On Thu, Oct 28, 2004 at 04:20:29PM +0200, Diego S?enz wrote: > What is the difference between CACHE_ACCEPT and CACHE_ACCEPT_SESSION? nothing, i just wanted to keep the code as identical to the original cookie version for now until it is decided what is going to be done with that hunk of code. -brian -- IHTFP: I firmly believe that people dumber than me exist solely for my amusement. IHTFP: Okay, maybe not solely for my amusement. Some of them make good cake.

Oct. 28, 2004

Re: [Dillo-dev]meta refresh patch for 0.8.2

by Diego Sáenz

What is the difference between CACHE_ACCEPT and CACHE_ACCEPT_SESSION? DarkSpirit. El Thu, 28 Oct 2004 08:05:20 -0400 Brian Hechinger <wonko(a)4amlunch.net> escribio: > On Thu, Oct 28, 2004 at 11:02:17AM +0200, Roberto A. Foglietta wrote: > > > > Obviously to respect Dillo's team decision to do not allow refresh as > > default policy I make it optional by setting a flag from command line > > speaking of patches, i have finished the caching work yesterday, and need some > people to look at it and test it. > > it uses .dillo/cacherc to control which sites are allowed to set the browser to > not cache the pages there, and also, it only currently honors Pragma no-cache. > > i want to modify the control functions to live in a public place and be > generic enough that they can be used for anything, since all i did was copy > them out of cookies.c and changed all occurances of Cookie or Cookies to Cache > so the functions themselves don't change. > > once done, this could very easily be applied to the refresh tag to control that, > and in fact, could be applied to any tag whatsoever at that point. > > here is the patch, let me know what you think, it patches against: > > /cache.c/1.74/Mon Oct 25 22:49:26 2004// > /cache.h/1.18/Thu Oct 21 14:45:51 2004// > /html.c/1.219/Thu Oct 21 22:48:54 2004// > > -brian > -- > IHTFP: I firmly believe that people dumber than me exist solely for my > amusement. > IHTFP: Okay, maybe not solely for my amusement. Some of them make good cake. >

Oct. 28, 2004

Re: [Dillo-dev]meta refresh patch for 0.8.2

by Brian Hechinger

On Thu, Oct 28, 2004 at 11:02:17AM +0200, Roberto A. Foglietta wrote: > > Obviously to respect Dillo's team decision to do not allow refresh as > default policy I make it optional by setting a flag from command line speaking of patches, i have finished the caching work yesterday, and need some people to look at it and test it. it uses .dillo/cacherc to control which sites are allowed to set the browser to not cache the pages there, and also, it only currently honors Pragma no-cache. i want to modify the control functions to live in a public place and be generic enough that they can be used for anything, since all i did was copy them out of cookies.c and changed all occurances of Cookie or Cookies to Cache so the functions themselves don't change. once done, this could very easily be applied to the refresh tag to control that, and in fact, could be applied to any tag whatsoever at that point. here is the patch, let me know what you think, it patches against: /cache.c/1.74/Mon Oct 25 22:49:26 2004// /cache.h/1.18/Thu Oct 21 14:45:51 2004// /html.c/1.219/Thu Oct 21 22:48:54 2004// -brian -- IHTFP: I firmly believe that people dumber than me exist solely for my amusement. IHTFP: Okay, maybe not solely for my amusement. Some of them make good cake.

Oct. 28, 2004

Re: [Dillo-dev]news about memory leak

by Roberto A. Foglietta

Riccardo Mottola wrote: > Hey, > > I am on a NetBSD/ppc system. DIllo 0.8.3 and can reproduce the leak. I > noted however that: > > - clicking the reload button in thight succession gets an increment of > about 4K every time > - the leak is consitent, you can make the amount of leaked memory > skyrocket to megabytes. > - clicking slowly, waitning 10 seconds each time does NOT make dillo > leak > > I suspect the leak happens if you click reload before dillo has > "finished" the page and the "stop button" is disabled. Excellent but using my refresh patch I could fix exactly delay among reloads and I see that 5 second are sufficient to load a trivial or not trivial html page but memory leak still. So what happens in ten seconds that doesn't happen in five? 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

Oct. 28, 2004

[Dillo-dev]meta refresh patch for 0.8.2

by Roberto A. Foglietta

Hi to all, actually I'm working for a local public transport company in which I have to develop a new way to display time table and information to people. Using Dillo into embedded linux system allow my collegues to change graphical display just editing php code in the server BUT this kind of information have to stay up-to-date. Commit a refresh from server is, in this case, the best solution I can immagine. So supporting meta refresh tag makes Dillo good for embedded client systems. This is the main reason because I developed this web-deprecated but very-useful-in-embedded function. In addition to this pratical consideration I think people use free software to be free, so it makes sense give them the freedoom to choose also deprecated functions. Obviously to respect Dillo's team decision to do not allow refresh as default policy I make it optional by setting a flag from command line The patch is plenty of /* RAF, 2004-10-XX: bla bla */ comments because they are usefull for others developers inside my company when they will patch an original version of Dillo and found quickly what I have changed in. If you agree to apply this patch to future stable branches this kind of comments are not any more usefull. If you will include my patch, in agreement with gpl, please inserit somewhere a noticed of code-contribution refering me and the company which is employing me actually. Patch doens't add the memory leak bug which I submit, simply it was the way I discovered that bug. 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

Oct. 28, 2004

[Dillo-dev]news about memory leak

by Riccardo Mottola

Hey, I am on a NetBSD/ppc system. DIllo 0.8.3 and can reproduce the leak. I noted however that: - clicking the reload button in thight succession gets an increment of about 4K every time - the leak is consitent, you can make the amount of leaked memory skyrocket to megabytes. - clicking slowly, waitning 10 seconds each time does NOT make dillo leak I suspect the leak happens if you click reload before dillo has "finished" the page and the "stop button" is disabled. I used a very simple page: <html>this is a test</html> Cheers, Riccardo

Oct. 28, 2004

Re: [Dillo-dev]Memory leak bug (was dillo-0.8.3)

by Roberto A. Foglietta

robert w hall wrote: > Hmm - could this be distro/kernel dependent? > Doing something similar (toggling reload when monitoring the dillo cvs > page IIRC) and monitoring memory via top on a remote terminal shows No > systematic effect - but this is playstation2-linux - an old 2.2.21 > kernel on a redhat-like implementation for a mips. > > In detail:- > On first coming from the home page to the CVS changelog, top shows > 9460k; this goes up to 9564 on first and stays there for subsequent > presses of reload. Returning to Home then back to cvs recovers the 9460, > 9564, 9564 sequence. > Bob It should be a glibc bug much more than kernel one, IMHO. Sometimes (but very rarely) I supposed to have managed to fix it because I didn't see it anymore, but recompiling THE SAME code or simply restarting dillo I saw it again. Obviously I was reloading THE SAME trivial html page (html, head, body, 4 links in 4 rows, closing-end). I'm working on MDK 10.1 but I could test it on a slackware too. Or better I will test dillo running on A but compiled in B and all others combinations foreach A, B in {mdk,slack}. 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

Oct. 28, 2004

Re: [Dillo-dev]Memory leak bug (was dillo-0.8.3)

by Roberto A. Foglietta

Jorge Arellano Cid wrote: > On Wed, Oct 27, 2004 at 06:42:14PM +0200, Roberto A. Foglietta wrote: > >>Jorge Arellano Cid wrote: >> >>> [...] >>> Please get it at: >>> >>> http://www.dillo.org/download/dillo-0.8.3.tar.bz2 >>> >>> and send your feedback. 36 hours of testing time remain! :-) >>> >>> >> >> Sorry to inform you but v0.8.3 (far from, at least v0.8.2) has a >>memory leak bug. > > > I tested it and 0.8.2 also leaks the same amount. :-) > > >> Clicking on reload button used memory increase around 4kb for each >>click. Stop clicking make used memory increasing stop too. So increase >>memory size of dillo depends on reloads but not following links. >> >> Dillo show the same memory leak using back-foward button between two >>different address. Could you reproduce it? > > > Yes I can. > > I'm testing with a trivial HTML page: "<html>@</html>", because > bad formed pages may result in some leaks. It's interesting to > note that the leak shows with this page too. I forgot to say that probably small and big pages have different amount of memory leak but it exist always, even in trivial and correct pages. The first thing I try to check was the correctness of my html. After I check that EVERY TAG, included <p> was always closed even if is not necessary close it (like meta tag, or <p> or <br>). HTML doesn't seem to me the reason of memory leak, if it were probably memory leak get out in following links too bit it doesn't. > > I'll give it a look, though it's hard to know where to start... Checking previuos version hoping to found one which hasn't this bug and comparing code between has/has-not could give us a good starting point to solve bug. > > Thanks for the report. If you find more details of this BUG, > please let us know. I will... 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

Oct. 28, 2004

[Dillo-dev]Protocol Handlers

by Lee Bigelow

Hello there, I was playing with the dpi's and made one for ed2k:// links (based on the Hello World example). It was just a quicky, and not generally useful, but I was wondering if anyone was working on a general protocol handler. Along these lines: - Dillo doesn't recognize the protocol so sends it to say external.dpi - external.dpi reads an external.conf file that has a list of protocols and respective external handlers. - If it finds a matching protocol it sends the url(%s), or just the url data (%r), to the handler. - If there's no matching protocol it could show an edit page (like bookmarks modify) for the external.conf. This could be used for mailto:, nntp:, telnet:, etc.. Anyhow, I starting playing with it, and I thought I should check to see if anyone else was also working on it before I went any further. Also, if there's any advice on the approach, or code I should look at, that would be cool. I am no expert C programer, I'm just reading the docs and modifying the code the other fellows already did. (I hope that's ok) -- Lee Bigelow <ligelowbee(a)yahoo.com>

Oct. 28, 2004

[Dillo-dev]Re: Dillo

by Jorge Arellano Cid

On Wed, Oct 27, 2004 at 04:48:37PM -0700, Eugenia Loli-Queru wrote: > >>Please note that the front-end of Gnomefiles has been specifically > >>optimized to work well with Dillo, > > > > I noted, good HTML, and it looks pretty too. > > Thanks, I have made sure that our other sites, osnews.com and nmcx.com also > render well. :) Great! > > > If you can add the missing </form> tag, the application-submit > >process on www.GnomeFiles.org may be finished by using a standard > >dillo-0.8.3. That'd be good news for our users. > > Please retry. I have changed the code to allow Dillo and added the missing > tag. Thanks! > Hmm, I can't seem to make dillo login to gnomefiles's dev corner. I have > edited my .dillo/cookiersrc file to say DEFAULT ALLOW but it still doesn't > login... Oh, it's "DEFAULT ACCEPT". BTW, I use: <q> DEFAULT DENY [...] www.gnomefiles.org ACCEPT_SESSION <q> > Do you have a better luck with it? Yes! By using a standard dillo-0.8.3, I was able to go through the whole process without any hassle. As a result, Dillo has now its own record at www.gnomefiles.org, and it's the first on the "Latest Software" list at the time of this writing. Thanks for your help. -- Cheers Jorge.-

Oct. 28, 2004

Re: [Dillo-dev]0.8.3 deb

by Frank McCormick

hello Forget it! I had been testing 0.8.2 before compiling/testing 0.8.3 . Everything is OK now. Sorry. On Wed, 27 Oct 2004 16:31:14 -0300 Jorge Arellano Cid <jcid(a)dillo.org> wrote: > On Wed, Oct 27, 2004 at 02:11:19PM -0400, Frank McCormick wrote: > > > > hello > > Hi. > > > 0.8.3 deb tells me " can't start dpi daemon" when trying to load an html > > file. Bad deb ? > > I assume you're using: > > http://willem.engen.nl/debian/dists/woody/dillo/binary-i386/ > dillo_0.8.3_i386.deb > > Check there're no other dpid instances, nor older dpis running: > > ps aux | grep dpid > dpidc stop > kill <dpid PIDs> > ps aux | grep dpi > kill <dpi PIDs> > > Then tell us how it went. > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev -- ---Frank McCormick--- Montreal <a ref="http://www.spreadfirefox.com/?q=affiliates&id=0&t=1">Get Firefox!</a>

Oct. 27, 2004

Re: [Dillo-dev]Memory leak bug (was dillo-0.8.3)

by Jorge Arellano Cid

On Wed, Oct 27, 2004 at 06:42:14PM +0200, Roberto A. Foglietta wrote: > Jorge Arellano Cid wrote: > > [...] > > Please get it at: > > > > http://www.dillo.org/download/dillo-0.8.3.tar.bz2 > > > > and send your feedback. 36 hours of testing time remain! :-) > > > > > > Sorry to inform you but v0.8.3 (far from, at least v0.8.2) has a > memory leak bug. I tested it and 0.8.2 also leaks the same amount. :-) > > Clicking on reload button used memory increase around 4kb for each > click. Stop clicking make used memory increasing stop too. So increase > memory size of dillo depends on reloads but not following links. > > Dillo show the same memory leak using back-foward button between two > different address. Could you reproduce it? Yes I can. I'm testing with a trivial HTML page: "<html>@</html>", because bad formed pages may result in some leaks. It's interesting to note that the leak shows with this page too. I'll give it a look, though it's hard to know where to start... Thanks for the report. If you find more details of this BUG, please let us know. -- Cheers Jorge.-

Oct. 27, 2004

Re: [Dillo-dev]0.8.3 deb

by Jorge Arellano Cid

On Wed, Oct 27, 2004 at 02:11:19PM -0400, Frank McCormick wrote: > > hello Hi. > 0.8.3 deb tells me " can't start dpi daemon" when trying to load an html > file. Bad deb ? I assume you're using: http://willem.engen.nl/debian/dists/woody/dillo/binary-i386/ dillo_0.8.3_i386.deb Check there're no other dpid instances, nor older dpis running: ps aux | grep dpid dpidc stop kill <dpid PIDs> ps aux | grep dpi kill <dpi PIDs> Then tell us how it went. -- Cheers Jorge.-

Oct. 27, 2004

Re: [Dillo-dev]Memory leak bug (was dillo-0.8.3)

by robert w hall

In article <417FCFE6.8040306(a)sad.it>, Roberto A. Foglietta <roberto.foglietta(a)sad.it> writes >Jorge Arellano Cid wrote: >> Hi there, >> >> Finally dillo-0.8.3 is ready for download. It should have been >> named dillo-0.8.3-rc4, but as this release is too much delayed, I >> took a chance and called it dillo-0.8.3 with the hope of making >> the official announcement this Wednesday. >> >> Please download it and give it a hard try. >> >> Notwistanding my hopes, if any BUG is detected in this short >> period, an rc5 must follow... >> >> Please get it at: >> >> http://www.dillo.org/download/dillo-0.8.3.tar.bz2 >> >> and send your feedback. 36 hours of testing time remain! :-) >> >> > > Sorry to inform you but v0.8.3 (far from, at least v0.8.2) has a >memory leak bug. > > Clicking on reload button used memory increase around 4kb for each >click. Stop clicking make used memory increasing stop too. So increase >memory size of dillo depends on reloads but not following links. Hmm - could this be distro/kernel dependent? Doing something similar (toggling reload when monitoring the dillo cvs page IIRC) and monitoring memory via top on a remote terminal shows No systematic effect - but this is playstation2-linux - an old 2.2.21 kernel on a redhat-like implementation for a mips. In detail:- On first coming from the home page to the CVS changelog, top shows 9460k; this goes up to 9564 on first and stays there for subsequent presses of reload. Returning to Home then back to cvs recovers the 9460, 9564, 9564 sequence. Bob -- robert w hall

Oct. 27, 2004

[Dillo-dev]0.8.3 deb

by Frank McCormick

hello 0.8.3 deb tells me " can't start dpi daemon" when trying to load an html file. Bad deb ? -- ---Frank McCormick--- Montreal

Oct. 27, 2004

Re: [Dillo-dev]Memory leak bug (was dillo-0.8.3)

by Roberto A. Foglietta

Roberto A. Foglietta wrote: > Sorry to inform you but v0.8.3 (far from, at least v0.8.2) has a memory > leak bug. forgot: I work whole day trying to fix this memory leak... 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

Oct. 27, 2004