You can subscribe to this list here.
2005 |
Jan
(2) |
Feb
(43) |
Mar
(83) |
Apr
(52) |
May
(7) |
Jun
|
Jul
(7) |
Aug
(2) |
Sep
(9) |
Oct
|
Nov
|
Dec
|
---|
From: Jason C. <ja...@jc...> - 2005-04-13 08:30:05
|
On Wed, Apr 13, 2005 at 08:00:27AM +0100, Nigel Horne wrote: > On Tuesday 12 Apr 2005 23:30, Vassilis Pandis wrote: > > Excellent, thumbs up. Using req->size is much better (we save a call = to > > strlen()). Does it fix it ? Why isn't strlen() correct (not doubting > > anything, just can't see why). >=20 > It isn't correct because it only works on strings, not aribitary data w= hich > can contain NUL bytes in the middle of them and aren't terminated by > a NUL byte. > > > > Nice work, > > Pandis As Nigel said. To check the problem I added debug to Kritton for the number of bytes sen= t. This was only 7, using a hex dump of the jpg file I could see that the= re was a NULL in the data around the 6th byte. So by passing the length o= f the buffer to transmit we can send the required length. I should have it checked in this evening after I collect my motorcycle fr= om my mechanic. Jason --=20 ja...@jc... Fortune: Any given program costs more and takes longer.=20 -- Murphy's Laws of Computer Programming n=B08 |
From: Nigel H. <nj...@ba...> - 2005-04-13 07:00:55
|
On Tuesday 12 Apr 2005 23:30, Vassilis Pandis wrote: > Excellent, thumbs up. Using req->size is much better (we save a call to > strlen()). Does it fix it ? Why isn't strlen() correct (not doubting > anything, just can't see why). It isn't correct because it only works on strings, not aribitary data which can contain NUL bytes in the middle of them and aren't terminated by a NUL byte. > > Nice work, > Pandis |
From: Vassilis P. <pa...@ya...> - 2005-04-13 01:14:32
|
These errorpages were sent to me by Dimitris Kontossis. I liked them and thought that they are a significant improvement over the current pages. Take a look at them and tell me what you think. Pandis Send instant messages to your online friends http://uk.messenger.yahoo.com |
From: Vassilis P. <pa...@ya...> - 2005-04-12 22:30:57
|
Excellent, thumbs up. Using req->size is much better (we save a call to strlen()). Does it fix it ? Why isn't strlen() correct (not doubting anything, just can't see why). Nice work, Pandis --- Jason Corcoran <ja...@jc...> wrote: > Lads, > > Not sure if my last mail made it to the list. But basically I have > modified > the dillo code ( and open source web browser ) to give extra debug. > This > showed that we were not sending the correct amount of bytes for a > file. This > seems to be due to the transmit function using strlen to set the > value of > total. > > This is wrong for binary data. I have modified the transmit function > so that > you need to pass the size of the data ( req->size ) for send file. > > I have a fix for this locally, but i did not perform a cvs update so > there is > a conflict with me checking it in. I will resolve this and check it > in > tomorrow. > > Jason > -- > ja...@jc... > > Fortune: > Whatever doesn't succeed in two months and a half in California will > never succeed. > -- Rev. Henry Durant, founder of the University of California > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Kritton-devel mailing list > Kri...@li... > https://lists.sourceforge.net/lists/listinfo/kritton-devel > Send instant messages to your online friends http://uk.messenger.yahoo.com |
From: Jason C. <ja...@jc...> - 2005-04-12 21:59:18
|
Lads, Not sure if my last mail made it to the list. But basically I have modified the dillo code ( and open source web browser ) to give extra debug. This showed that we were not sending the correct amount of bytes for a file. This seems to be due to the transmit function using strlen to set the value of total. This is wrong for binary data. I have modified the transmit function so that you need to pass the size of the data ( req->size ) for send file. I have a fix for this locally, but i did not perform a cvs update so there is a conflict with me checking it in. I will resolve this and check it in tomorrow. Jason -- ja...@jc... Fortune: Whatever doesn't succeed in two months and a half in California will never succeed. -- Rev. Henry Durant, founder of the University of California |
From: Jason C. <ja...@jc...> - 2005-04-12 12:55:44
|
Just a heads up on what I have been doing. I have modified the Dillo source code ( open source web browser ) to outp= ut debug when browsing and looking at what we are returning for an image. One thing I have noticed is that wer seem to be sending extra headers aft= er a page is served. I am looking into this at the moment. [This can be seen by printf'ing on the prepare_header function]. Thanks Jason. --=20 ja...@jc... Fortune: Any given program, when running, is obsolete.=20 -- Murphy's Laws of Computer Programming n=B07 |
From: Nigel H. <nj...@ba...> - 2005-04-11 15:16:57
|
> -----Original Message----- > From: kri...@li... > [mailto:kri...@li...]On Behalf Of Vassilis > Pandis > Sent: 11 April 2005 16:04 > To: kri...@li... > Subject: [Kritton-devel] MTU and buffering transmit() > > > I was thinking of implementing Nigel's suggestion in his bug report > #1120940. Basically, Nigel suggested that we have a buffer in > transmit() so as to make one call to send, not two (body+header) to > minimize TCP packet overhead. After some reading I discovered that this > is already done by the TCP stack. Sounds very TCP implementation specific to me. Is it true of all stacks? > The question is: Will the speed benefit of calling send() once instead > of twice outweigh the speed penalty for having a buffer? I stick with my view point ;-) > Pandis -Nigel |
From: Vassilis P. <pa...@ya...> - 2005-04-11 15:04:39
|
I was thinking of implementing Nigel's suggestion in his bug report #1120940. Basically, Nigel suggested that we have a buffer in transmit() so as to make one call to send, not two (body+header) to minimize TCP packet overhead. After some reading I discovered that this is already done by the TCP stack. TCP buffers small packets to send them when it thinks it should. There is no definite way of forcing packets to be sent *immediately* after send() is called. As a result, I question the neccessity of implementing such a buffer (consider the buffering overhead too ). I am not absolutely certain that TCP does exactly what Nigel suggested, but from what I gather, it seems quite close. Surely though, such a buffer would save us (in any case) of calling send() twice or more. We could have a buffer larger than the MTU (say, a 4KB buffer - MTU is usually 1.5KB ) so that we get both body and header to fit into a single variable, and then call send once. Of course, if the file to be sent is large, send() will be called more than once, but in any case, will be called less times than it would with the current implementation. The question is: Will the speed benefit of calling send() once instead of twice outweigh the speed penalty for having a buffer? Pandis Send instant messages to your online friends http://uk.messenger.yahoo.com |
From: Jason C. <ja...@jc...> - 2005-04-11 12:12:11
|
On Sun, Apr 10, 2005 at 05:40:27PM +0100, Vassilis Pandis wrote: > I think the directory listing problem has been sorted but needs testing > before we consider the matter settled. Stuff is rather quiet now, but > there is a major outstanding issue with the images.=20 > If the frequent CVS commits interfere with your testing process, you > can do weekly CVS updates and report your bugs when they show up. CVS > code is fairly good - it always compiles and usually works too.=20 >=20 > Keep the bugs coming, > Pandis I have looked at the image problem and will send a report on it tonight, = at work at the moment and do not have the time. Should have a commit before wed. Jason --=20 ja...@jc... Fortune: If a program is useful, it will have to be changed.=20 -- Murphy's Laws of Computer Programming n=B09 |
From: Vassilis P. <pa...@ya...> - 2005-04-10 16:40:36
|
I think the directory listing problem has been sorted but needs testing before we consider the matter settled. Stuff is rather quiet now, but there is a major outstanding issue with the images. If the frequent CVS commits interfere with your testing process, you can do weekly CVS updates and report your bugs when they show up. CVS code is fairly good - it always compiles and usually works too. Keep the bugs coming, Pandis --- Nigel Horne <nj...@ba...> wrote: > I know I've been quiet - I've been waiting for the software > to settle down before I start testing it further. > > Let me know when it'll be worth starting again. > > -Nigel > > > > Send instant messages to your online friends http://uk.messenger.yahoo.com |
From: Nigel H. <nj...@ba...> - 2005-04-10 16:31:05
|
I know I've been quiet - I've been waiting for the software to settle down before I start testing it further. Let me know when it'll be worth starting again. -Nigel |
From: Vassilis P. <pa...@ya...> - 2005-04-08 16:55:40
|
Hi, was looking at the bugs at sourceforge.net and saw the wrong vhost with firefox. I looked at the code and it has been corrected (my error not to have closed it on Sf.net, sorry) but it was corrected with ending the loop at a \n, whereas the HTTP protocol specifies that lines end with a CRLF. So, to conclude, I changed the \n to \r and it should work correctly now. Pandis Send instant messages to your online friends http://uk.messenger.yahoo.com |
From: Vassilis P. <pa...@ya...> - 2005-04-08 16:41:37
|
Hi guys, I hope I'm not hurrying to commit, but the glitch I mentioned in the previous mail appears to have been fairly straightforward and I think I've sorted out the directory problem (everything should work properly). I tried it and couldn't find a malfunction. Check it out and tell me if it works. Pandis Send instant messages to your online friends http://uk.messenger.yahoo.com |
From: Vassilis P. <pa...@ya...> - 2005-04-08 16:33:08
|
Ok, I spent some time and fortunately significantly progressed with the slash bug. I figured out that the problem with the directory listing and the final slash is that : 1. When you type http://localhost/foo/bar/, the browser knows that /foo/bar/ is a directory because of the leading slash. So, if the directory listing in /foo/bar/ has a link to "blah", the browser looks in http://localhost/foo/bar/blah 2. When you type http://localhost/foo/bar, the browser thinks that bar is a file within /foo/. As a result, when there is a link to "blah", it gets interpreted as http://localhost/foo/blah . I changed some stuff (mostly Florent's attempt to correct the slash problem) and now it works. However, there is one final glitch to be corrected: when the link in the browser is http://localhost/blah, no files get displayed. If it is http://localhost/blah/, it's ok. I'll look into the problem if I have more time to spare this evening. In the meanwhile, can somebody check that my fixes are actually fixes? (If I did something stupid, we'll revert to main.c v. 1.11.4.16 . Pandis --- Florent Morel <fl...@fr...> wrote: > Hi, > > I did a commit that fix the dir browsing bug (#1176631). > > The problem of files that are not displayed is solved (stat was > complaining > because i didn't copy correctly the path). > > So the "final /" bug remains, if you can give it a look, i think it's > a > trivial problem but since i'm not very experimented with working with > (char > *), i may do a mistake that gives me this "blah/@, @Èy @" instead of > "blah/". > > Note that the "/" is added, but i can't figure out why the "@, @Èy @" > is added > as well. > > Regards, > > Florent > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_ide95&alloc_id396&op=click > _______________________________________________ > Kritton-devel mailing list > Kri...@li... > https://lists.sourceforge.net/lists/listinfo/kritton-devel > Send instant messages to your online friends http://uk.messenger.yahoo.com |
From: Florent M. <fl...@fr...> - 2005-04-08 11:09:11
|
Hi, I did a commit that fix the dir browsing bug (#1176631). The problem of files that are not displayed is solved (stat was complaining= =20 because i didn't copy correctly the path). So the "final /" bug remains, if you can give it a look, i think it's a=20 trivial problem but since i'm not very experimented with working with (char= =20 *), i may do a mistake that gives me this "blah/@, @=C8y @" instead of "bla= h/".=20 Note that the "/" is added, but i can't figure out why the "@, @=C8y @" is = added=20 as well. Regards, =46lorent |
From: Florent M. <fl...@fr...> - 2005-04-08 08:46:58
|
Hi, i've been working on the bug #1176631 the last few days. I corrected it (see send_dir() in main.c) and we can now browse directories. Two problems arise from the correction :=20 - when going in a sub-directory, it does not display every file, it stops = at=20 one or two and i don't know why for the time. - i figured out that when we put a "/" at the end of the directory (i.e := =20 http://localhost/blah/), browsing works great. But if the "/" is not here, = it=20 doesn't work.=20 So i tried to add a "/" at the end (if we have to display a dir, so i put t= he=20 code in send_dir so we won't have a foo/index.html/), but i'm encountig=20 problems because i'm adding a character to a char * . Example : if the URL is http://localhost/blah, i take path and add a "/" at= =20 the end. Instead of having "blah/", i get a "blah/@, @=C8y @" and guess what : this= =20 directory does not exist. If someone has an idea how to add a "/" at the end without having these wei= rd=20 stuffs at the end, it would be very nice. I'll commit my code this morning so everyone could look at it and maybe fin= d=20 something interesting to do. Bye, =46lorent. |
From: Vassilis P. <pa...@ya...> - 2005-04-07 14:37:01
|
I've left the image problem aside for a while, will get back to it later ( Jason said he'll take a look at it too). In the meantime I've made some changes in main.c and config.c which will make Kritton ignore leading a trailing slashes and handle all slashes internally. I'll take a look at Florent's bug although some fleeting attempts yesterday failed to fix it. Pandis Send instant messages to your online friends http://uk.messenger.yahoo.com |
From: Jason C. <ja...@jc...> - 2005-04-06 20:47:10
|
On Wednesday 06 April 2005 20:49, Jason Corcoran wrote: > Pandis, > > The problem with the jpegs not being displayed, are you seeing garbage on > the screen? > > I have noticed that the content-type is being returned as text/html when > you try to load an image. > > I will look into this. > > Jason Please ignore, my mime type file was blank so I did not have a mime type for the file. Still looking at the jpg problem. Jason -- ja...@jc... Fortune: MAC user's dynamic debugging list evaluator? Never heard of that. |
From: Jason C. <ja...@jc...> - 2005-04-06 20:39:19
|
Pandis, The problem with the jpegs not being displayed, are you seeing garbage on the screen? I have noticed that the content-type is being returned as text/html when you try to load an image. I will look into this. Jason -- ja...@jc... Fortune: He is a man capable of turning any colour into grey. -- John LeCarre |
From: Vassilis P. <pa...@ya...> - 2005-04-05 18:47:09
|
Hi guys, this is just a minor CVS update which optimizes the function make_lower_case in main.c. I didn't get the image thing sorted out, yet , I'd like you're ideas if there are any. Pandis Send instant messages to your online friends http://uk.messenger.yahoo.com |
From: Nigel H. <nj...@ba...> - 2005-04-02 14:39:32
|
On Friday 01 Apr 2005 18:05, Vassilis Pandis wrote: > Yep. It should be ok now. Nigel did you get your CVS problems sorted > out ? The patches you are referring to is the INADDR_ANY patch? This > has also been incorporated, but in main.h instead of main.c to keep > code cleaner. The INADDR_ANY patch has been put in, I know. I am refering to the bind() fix. > > Pandis -Nigel |
From: Vassilis P. <pa...@ya...> - 2005-04-01 17:05:59
|
Yep. It should be ok now. Nigel did you get your CVS problems sorted out ? The patches you are referring to is the INADDR_ANY patch? This has also been incorporated, but in main.h instead of main.c to keep code cleaner. Pandis --- Nigel Horne <nj...@ba...> wrote: > On Friday 01 Apr 2005 03:19, Kwan M Lim wrote: > > I tried a checkout of the DEVELOPMENT branch but had trouble > building > > kritton because 'make' said I needed tabs instead of 8 spaces. I > > changed the 8 spaces before each command to tabs and it worked. Was > I > > supposed to do this or is there a different way to run make? > > This is correct. You do need tabs not spaces. Too much cut 'n' > pasting > has probably lost the tabs. > > -Nigel > > > ------------------------------------------------------- > This SF.net email is sponsored by Demarc: > A global provider of Threat Management Solutions. > Download our HomeAdmin security software for free today! > http://www.demarc.com/Info/Sentarus/hamr30 > _______________________________________________ > Kritton-devel mailing list > Kri...@li... > https://lists.sourceforge.net/lists/listinfo/kritton-devel > Send instant messages to your online friends http://uk.messenger.yahoo.com |
From: Vassilis P. <pa...@ya...> - 2005-04-01 17:02:38
|
I don't think you need to uncomment anything besides CONNECTION_NOCLOSE (delete it, as a matter of fact). SMN support is not there in the time being so simply comment it out (SMN support should also be in the TODO I posted yesterday - but this time it should be implemented properly). It would be a good idea to rename the makefile-writing function as something_linux_fedora() and ask the user to choose OS from a list. This will help in creating the Makefile as it should be for different distributions (remember the debianization of Kritton we discussed a few weeks ago on the list? We can get without an autoconf script after all). Pandis --- Florent Morel <fl...@fr...> wrote: > > Hi team, > > after a few days out, i'm posting to say that i'm working on the > configuration > tool (tools/config.c). > > i'll commit when done (and working ;-), but here are the first points > : > > *1) In Makefile, there is : > > kritton : $(OBJECTS) > > $(CC) $(LDFLAGS) -o kritton $(OBJECTS) > > rm -f gmon.out > > Where does the LDFLAGS come from ? I replaced it with CFLAGS, what to > do ? > > *2) in config.c, I commented out lbl6 (CONNECTION_NOCLOSE), but i > don't know > what is to be commented as well (is the one about SMN to be commented > ?). > > Thanks for telling me if you have an idea. > > Regards, > Flo > > > ------------------------------------------------------- > This SF.net email is sponsored by Demarc: > A global provider of Threat Management Solutions. > Download our HomeAdmin security software for free today! > http://www.demarc.com/Info/Sentarus/hamr30 > _______________________________________________ > Kritton-devel mailing list > Kri...@li... > https://lists.sourceforge.net/lists/listinfo/kritton-devel > Send instant messages to your online friends http://uk.messenger.yahoo.com |
From: Nigel H. <nj...@ba...> - 2005-04-01 11:53:44
|
On Friday 01 Apr 2005 12:43, Florent Morel wrote: >=20 > Hi team, >=20 > after a few days out, i'm posting to say that i'm working on the config= uration=20 > tool (tools/config.c). >=20 > i'll commit when done (and working ;-), but here are the first points := =20 >=20 > *1) In Makefile, there is : > > kritton : $(OBJECTS) > > =A0 =A0 =A0 =A0 $(CC) $(LDFLAGS) -o kritton $(OBJECTS) > > =A0 =A0 =A0 =A0 rm -f gmon.out >=20 > Where does the LDFLAGS come from ? I replaced it with CFLAGS, what to d= o ? I've been through this before. CFLAGS is used to build modules, LDFLAGS i= s used to build an executable from modules. Look at make's built in rules: make -p -f /dev/null | fgrep LDFLAGS As already proposed, that should read: kritton : $(OBJECTS) $(CC) $(LDFLAGS) -o kritton $(OBJECTS) $(RM) gmon.out But thinking about it, even that is wrong. It should read: kritton: $(OBJECTS) $(CC) $(LDFLAGS) -o $@ $(OBJECTS) $(RM) gmon.out > Regards, > Flo -Nigel --=20 Nigel Horne. Arranger, Composer, Typesetter. NJH Music, Barnsley, UK. ICQ#20252325 nj...@de... http://www.bandsman.co.uk |
From: Florent M. <fl...@fr...> - 2005-04-01 11:43:38
|
Hi team, after a few days out, i'm posting to say that i'm working on the configurat= ion=20 tool (tools/config.c). i'll commit when done (and working ;-), but here are the first points :=20 *1) In Makefile, there is : > kritton : $(OBJECTS) > =A0 =A0 =A0 =A0 $(CC) $(LDFLAGS) -o kritton $(OBJECTS) > =A0 =A0 =A0 =A0 rm -f gmon.out Where does the LDFLAGS come from ? I replaced it with CFLAGS, what to do ? *2) in config.c, I commented out lbl6 (CONNECTION_NOCLOSE), but i don't kno= w=20 what is to be commented as well (is the one about SMN to be commented ?). Thanks for telling me if you have an idea. Regards, =46lo |