Re: [Dillo-dev]Can't start dpid
Ok, I've joined the dillo-dev list! On Fri, 9 Apr 2004 08:13:17 -0400 (CLT) Jorge Arellano Cid <jcid@dillo.org> wrote:
I should also explain that I have my own distro, Puppy Linux, and everything is compiled against uClibc, not glibc. (www.goosee.com/puppy)
Oh, it would be interesting to have Dillo running under uClibc!
Dillo has been in Puppy right from the start (which was about one year ago). A few months ago I changed over to uClibc and recompiled everything, including Dillo, and all was well until I upgraded to Dillo v0.8.0.
Check if you can run them crom the CLI:
cd /usr/local/lib/dillo/dpi/hello ./hello.filter.dpi
I'm doing this as root. When I try this I get: hello.dpi:: starting... and that's it, nothing more, doesn't exit until I ctrl-c. No error message. ...what is it supposed to do? Regards, Barry Kauler
Ok, for those reading this thread for the first time, the problem is dpid won't start in my custom Puppy Linux distro. Maybe I've found the solution? I have a build environment, but then I run a script to create the Puppy filesystem, which copies files from the build environment. It copies dillo, dpid, dpidc into /usr/local/bin, all of the stuff in /usr/local/lib/dillo gets copied across, however, the script doesn't copy dpidrc and dillorc from /usr/local/etc, as in Puppy all of /usr is read-only. Instead, I have placed dpidrc and dillorc into ~/.dillo, except that this seems to have not been upgraded. I'm running Puppy right now and what I see in ~/.dillo are the files .073 cookiesrc dillorc So, is this my problem? I just checked the dates on those files, and they are from the old 0.7.3 version. It does seem that my oversight is to blame here! One question though, is there any problem with continuing to use the old dillorc? I ask this as when people upgrade to the latest Puppy they may have modified dillorc and I don't want to just overwrite their dillorc file. Looks like Puppy and Dillo are back in business! Puppy v0.8.5 should be out soon, like maybe another week. Regards, Barry Kauler On Sat, 10 Apr 2004 00:56:07 -0600 Barry Kauler <bkauler@goosee.com> wrote:
Ok, I've joined the dillo-dev list!
On Fri, 9 Apr 2004 08:13:17 -0400 (CLT) Jorge Arellano Cid <jcid@dillo.org> wrote:
I should also explain that I have my own distro, Puppy Linux, and everything is compiled against uClibc, not glibc. (www.goosee.com/puppy)
Oh, it would be interesting to have Dillo running under uClibc!
Dillo has been in Puppy right from the start (which was about one year ago). A few months ago I changed over to uClibc and recompiled everything, including Dillo, and all was well until I upgraded to Dillo v0.8.0.
Check if you can run them crom the CLI:
cd /usr/local/lib/dillo/dpi/hello ./hello.filter.dpi
I'm doing this as root. When I try this I get:
hello.dpi:: starting...
and that's it, nothing more, doesn't exit until I ctrl-c. No error message. ...what is it supposed to do?
Regards, Barry Kauler
_______________________________________________ Dillo-dev mailing list Dillo-dev@lists.auriga.wearlab.de http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
On Sat, 10 Apr 2004, Barry Kauler wrote:
Ok, for those reading this thread for the first time, the problem is dpid won't start in my custom Puppy Linux distro. Maybe I've found the solution?
I have a build environment, but then I run a script to create the Puppy filesystem, which copies files from the build environment. It copies dillo, dpid, dpidc into /usr/local/bin, all of the stuff in /usr/local/lib/dillo gets copied across, however, the script doesn't copy dpidrc and dillorc from /usr/local/etc, as in Puppy all of /usr is read-only. Instead, I have placed dpidrc and dillorc into ~/.dillo, except that this seems to have not been upgraded. I'm running Puppy right now and what I see in ~/.dillo are the files .073 cookiesrc dillorc
So, is this my problem?
It seem so! You need either the global rc files (dillorc and dpidrc), or placing them under each ~/.dillo directory in every account.
I just checked the dates on those files, and they are from the old 0.7.3 version. It does seem that my oversight is to blame here!
Please confirm me that it works for you now.
One question though, is there any problem with continuing to use the old dillorc? I ask this as when people upgrade to the latest Puppy they may have modified dillorc and I don't want to just overwrite their dillorc file.
Appart from the comments for each option, and maybe format, the only additions to 0.8.0's dillorc are: <q> # The new parser is more accurate detecting HTML errors. # Also pages may look better or worst (after all is bad-formed HTML). # Uncomment this line if you want to use the old parser. #use_old_parser=YES # Generic messsages (mainly for debugging specific parts) # Uncomment the following line to disable them. #show_msg=NO </q> You can safely append those lines to each user's dillorc and thus, have them upgraded.
Looks like Puppy and Dillo are back in business! Puppy v0.8.5 should be out soon, like maybe another week.
Great. When I get your confirmation of Dillo working OK on it, I'll add Puppy to our compatibility list and place a link to its home page. Cheers Jorge.-
the problem is dpid won't start in my custom Puppy Linux distro.
Jorge, Now that I have dillorc file, dpid does load, but it still isn't working. If I start dillo from the commandline, and enter a url https://www.paypal.com, nothing at all happens in the browser, no error msg even. I get this output from dillo on the stdout/errout: Nav_open_url: Url=>https://www.paypal.com<; url_str = https://www.paypal.com Dpi_parse_token: [<dpi cmd='answer' to_cmd='open_url' msg='nothing sent...'>] Dpi: [Dpi_process_io] IOClose The paypal site is working, I just checked with Mozilla. If I right-click on a link to a file on a webpage and choose to "Save link as...", the destination choice window comes up, but after pressing OK button, the stdout/errout is this: ERROR: [Dpi_get_token] Can't find token start ERROR: [Dpi_get_token] Can't find token start ERROR: [Dpi_get_token] Can't find token start ERROR: [Dpi_get_token] Can't find token start Dpi: [Dpi_process_io] IOClose So, I celebrated too soon! Do these messages mean anything much to you? Any suggestion what I should try next? Regards, Barry Kauler
On Wed, 14 Apr 2004, Barry Kauler wrote:
the problem is dpid won't start in my custom Puppy Linux distro.
Jorge, Now that I have dillorc file, dpid does load, but it still isn't working. If I start dillo from the commandline, and enter a url https://www.paypal.com, nothing at all happens in the browser, no error msg even. I get this output from dillo on the stdout/errout:
Nav_open_url: Url=>https://www.paypal.com<; url_str = https://www.paypal.com Dpi_parse_token: [<dpi cmd='answer' to_cmd='open_url' msg='nothing sent...'>] Dpi: [Dpi_process_io] IOClose
The paypal site is working, I just checked with Mozilla.
Hmmm, it could be an issue with wget. The https dpi is an experimental prototype, that's why it wasn't announced with fanfare in 0.8.0. Currently, Madis and I are working on making an SSL library based https dpi (not wget based)... Please don't worry about the https dpi until it comes out of this "for developers" stage.
If I right-click on a link to a file on a webpage and choose to "Save link as...", the destination choice window comes up, but after pressing OK button, the stdout/errout is this:
ERROR: [Dpi_get_token] Can't find token start ERROR: [Dpi_get_token] Can't find token start ERROR: [Dpi_get_token] Can't find token start ERROR: [Dpi_get_token] Can't find token start Dpi: [Dpi_process_io] IOClose
This should be working.
So, I celebrated too soon! Do these messages mean anything much to you? Any suggestion what I should try next?
Yes and yes. First, check whether the bookmarks dpi works. If it does, then the dpid launch (by dillo) and dpi launch (by dpid) are ok. If this is true, test with the hello and the ftp dpis. If all of them work, we should be looking closer into the downloads dpi. Cheers Jorge.-
I get this output from dillo on the stdout/errout:
Nav_open_url: Url=>https://www.paypal.com<; url_str = https://www.paypal.com Dpi_parse_token: [<dpi cmd='answer' to_cmd='open_url' msg='nothing sent...'>] Dpi: [Dpi_process_io] IOClose
The paypal site is working, I just checked with Mozilla.
Hmmm, it could be an issue with wget.
The https dpi is an experimental prototype, that's why it wasn't announced with fanfare in 0.8.0.
Jorge, something that may interest you. In Puppy Linux I am also using the "Light" web browser, which is a frontend to Mozilla. Very very lightweight. For download it uses wget, which works fine. I can't recall exactly, but it downloads to the home folder, no choice, but it is possible to get the Moz destination dialog box to come up, but can't be changed out of the home folder. Light is not actively being developed anymore, but maybe the code would be useful, for reference on how he got wget going.
First, check whether the bookmarks dpi works. If it does, then the dpid launch (by dillo) and dpi launch (by dpid) are ok. If this is true, test with the hello and the ftp dpis.
If all of them work, we should be looking closer into the downloads dpi.
Yes, bookmarks works! After creating a bookmark, I then selected it, and this is the stdout: Dpi_parse_token: [<dpi cmd='start_send_page' url='dpi:/bm/'>] Dpi: [Dpi_process_io] IOClose Nav_open_url: Url=>http://www.goosee.com<; However, ftp doesn't work. Here is the output: Nav_open_url: Url=>ftp://ibiblio.org/pub/Linux/distributions< url_str = ftp://ibiblio.org/pub/Linux/distributions Dpi_parse_token: [<dpi cmd='snwer' to_cmd='open_url' msg='not a directory'>] Dpi: [Dpi_process_io] IOClose That url is a directory. I tried another url, same thing. Putting a "/" on end of url makes no difference. Regards, Barry Kauler
Jorge, Below is a repeat of part of my last posting in thread "Can't start dpid". I would like to know, is there anything further that I can do to help chase this bug down?
First, check whether the bookmarks dpi works. If it does, then the dpid launch (by dillo) and dpi launch (by dpid) are ok. If this is true, test with the hello and the ftp dpis.
If all of them work, we should be looking closer into the downloads dpi.
Yes, bookmarks works! After creating a bookmark, I then selected it, and this is the stdout:
Dpi_parse_token: [<dpi cmd='start_send_page' url='dpi:/bm/'>] Dpi: [Dpi_process_io] IOClose Nav_open_url: Url=>http://www.goosee.com<;
However, ftp doesn't work. Here is the output:
Nav_open_url: Url=>ftp://ibiblio.org/pub/Linux/distributions< url_str = ftp://ibiblio.org/pub/Linux/distributions Dpi_parse_token: [<dpi cmd='snwer' to_cmd='open_url' msg='not a directory'>] Dpi: [Dpi_process_io] IOClose
That url is a directory. I tried another url, same thing. Putting a "/" on end of url makes no difference.
Regards, Barry Kauler
_______________________________________________ Dillo-dev mailing list Dillo-dev@lists.auriga.wearlab.de http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
On Sun, 18 Apr 2004, Barry Kauler wrote:
Jorge, Below is a repeat of part of my last posting in thread "Can't start dpid". I would like to know, is there anything further that I can do to help chase this bug down?
Yes, surely you can! Yesterday it happened to me on my machine, so today (Sunday 18), I'm going trying to chase the bug. Probably I'll add some debugging code to the dpis and try to reproduce the bug, then I'll contact you. Cheers Jorge.-
First, check whether the bookmarks dpi works. If it does, then the dpid launch (by dillo) and dpi launch (by dpid) are ok. If this is true, test with the hello and the ftp dpis.
If all of them work, we should be looking closer into the downloads dpi.
Yes, bookmarks works! After creating a bookmark, I then selected it, and this is the stdout:
Dpi_parse_token: [<dpi cmd='start_send_page' url='dpi:/bm/'>] Dpi: [Dpi_process_io] IOClose Nav_open_url: Url=>http://www.goosee.com<;
However, ftp doesn't work. Here is the output:
Nav_open_url: Url=>ftp://ibiblio.org/pub/Linux/distributions< url_str = ftp://ibiblio.org/pub/Linux/distributions Dpi_parse_token: [<dpi cmd='snwer' to_cmd='open_url' msg='not a directory'>] Dpi: [Dpi_process_io] IOClose
That url is a directory. I tried another url, same thing. Putting a "/" on end of url makes no difference.
Regards, Barry Kauler
_______________________________________________ Dillo-dev mailing list Dillo-dev@lists.auriga.wearlab.de http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
_______________________________________________ Dillo-dev mailing list Dillo-dev@lists.auriga.wearlab.de http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
On Sun, 18 Apr 2004, Jorge Arellano Cid wrote:
On Sun, 18 Apr 2004, Barry Kauler wrote:
Jorge, Below is a repeat of part of my last posting in thread "Can't start dpid". I would like to know, is there anything further that I can do to help chase this bug down?
Yes, surely you can!
Yesterday it happened to me on my machine, so today (Sunday 18), I'm going trying to chase the bug. Probably I'll add some debugging code to the dpis and try to reproduce the bug, then I'll contact you.
After quickly studying the problem, there's some new code in our CVS for downloads.c (removes a buffer corruption because of improper error message handling). Please test it and tell us how it works. At least is solves the problem in my machine. Cheers Jorge.- PS: Please confirm me you're not using a proxy to go out. If so, maybe the PROXY environment var may help wget to gets it way out.
some guy from somewhere told me of an idea : what if there was no "frames in one window" support, and frames were opened each in its own window, probably laid out according to the frameset? it sounds good to me. (however, i understand that some users won't like this behaviour. the thing is, are they a majority ? ;e) ) m.
Hi Barry,
Jorge, Below is a repeat of part of my last posting in thread "Can't start dpid". I would like to know, is there anything further that I can do to help chase this bug down?
A few days ago I answered this email with some new code in CVS for testing. Did it solve the problem? It'd be good to have it solved before the dillo-0.8.1 release, which is coming soon. Cheers Jorge.-
This is off-topic, but it may interest someone on the Dillo-dev list. I am using the "Ted" wordprocessor in my tiny Puppy Linux distro, and I notice that Damn Small Linux has also gone over to Ted. We are both using the GTK version. Mark de Does, the author, wrote it for Motif, and someone helped him to get it to work on GTK 1.2, and we use the GTK version on Puppy and DSL. That person who originally helped him has moved on, and the GTK interface is left somewhat immature. I don't want to poach anyone off the Dillo development, as I want Dillo to go full steam ahead, but if anyone reading this has an interest in helping Mark as an additional temporary project, you can find his web page at www.nllgg.nl/Ted and his email is mdedoes@xs4all.nl Ted is philosophically like Dillo, small and powerful. Ted works on RTF as its native format and can export to html, ps and pdf. Ted is also WYSIWYG. Note that the html generated uses a lot of CSS, to get the layout right. Mostly what is wrong is that the GTK dialog boxes are enormous, and font selection is disfunctional (plus more things). I upgraded to the latest, v2.16, but I get a gdk error message when change fonts, had to go back to v2.14. Dillo handles fonts very smoothly (hats off to you guys on that one) and some of that would be very good in Ted. So, thought I would post this, in case it interests anyone. There might be some code that can come the other way. Regards, Barry Kauler
participants (4)
-
Barry Kauler -
Barry Kauler -
honza m. -
Jorge Arellano Cid