From samuel at translate.org.za Sun May 4 16:39:08 2008 From: samuel at translate.org.za (Samuel Murray (Groenkloof)) Date: Mon, 05 May 2008 00:39:08 +0200 Subject: [elinks-dev] Off-topic: Translators wanted for opensource Message-ID: <481E3B0C.2030103@translate.org.za> G'day everyone Please allow me to tell you about our translation project. I'm hoping that some of you might be able to help us with translations or ideas. One of the types of programs that I'm sure will be useful to translate, is browsing programs. Since you guys already work on or translate a browsing program, would you mind telling me what you think one should look for in a browsing program from the point of view of translating it? What things do you think one needs to keep in mind when selecting a single browsing program for a translation project with volunteers? We call our project the Decathlon because we want to encourage people who feel passionate about their language to translate up to ten or more opensource programs into their languages in 2008. This year, we limit our selection of translated programs to applications aimed at end-users, and preferably programs that run on multiple platforms. All translations are done in our web-based translations system, Pootle. The value of Pootle is that a team of translators can work together on a single file. Pootle also has quality checking features, to ensure that translations don't break the software they are used in. Pootle requires the Gettext PO format, but we can convert certain other formats to and from PO. You can read more about the Decathlon project at http://translate.sourceforge.net/wiki/decathlon/mainpage. Or take a look at the online translation system: http://pootle.locamotion.org/ Or join the low-volume newsletter mailing list: https://lists.sourceforge.net/lists/listinfo/translate-decathlon Or contact the project leader, Samuel Murray, at samuel at translate.org.za. I look forward to hearing from you. Sincerely Samuel Murray Decathlon project leader From scott.m.mcdermott at gmail.com Wed May 7 03:29:42 2008 From: scott.m.mcdermott at gmail.com (Scott Mcdermott) Date: Wed, 7 May 2008 02:29:42 -0700 Subject: [elinks-dev] elinks crash in DOM code, and backtrace Message-ID: <20080507092942.GA27075@omnius.localdomain> I get an elinks crash at the following URL: http://podcasts.odiogo.com/2020-nexus/podcasts-xml.php Here is the elinks version, features, internal crash handler output and gdb backtrace. If a fix is made, please if you can, post it here, not just to the GIT repo. I don't know anything about the DOM code, sorry. Thanks, -- Scott * * * ELinks 0.13.GIT 43036aec73dacfa924bada4d68c825eb4c261f5a-dirty Built on May 7 2008 02:02:28 Features: Standard, Fastmem, IPv6, gzip, bzip2, No mouse, UTF-8, Periodic Saving, Viewer (Search History, Timer, Marks), Cascading Style Sheets, Protocol (Authentication, BitTorrent, File, CGI, Finger, FTP, Gopher, HTTP, NNTP, URI rewrite, User protocols), SSL (OpenSSL), MIME (Option system, Mailcap, Mimetypes files), LED indicators, Bookmarks, Cookies, ECMAScript (SpiderMonkey), Form History, Global History, Scripting (Lua, Spidermonkey ECMAScript), Exmode, Goto URL History ./elinks(dump_backtrace+0x1c)[0x80ee39c] ./elinks[0x80bc70d] ./elinks[0x80bc638] [0x110420] ./elinks(pop_dom_node+0x3e)[0x80a086e] ./elinks(render_dom_document+0x183)[0x8088453] ./elinks(render_document+0x4fa)[0x808451a] ./elinks(render_document_frames+0x1bd)[0x80847bd] ./elinks(draw_formatted+0x26)[0x80f5d46] ./elinks(display_timer+0x2a)[0x80e2daa] ./elinks[0x80e4814] ./elinks[0x80b7606] ./elinks(read_from_socket+0x33)[0x80b9ae3] ./elinks[0x80d4d00] ./elinks[0x80d540f] ./elinks(http_got_header+0xb6a)[0x80d5faa] ./elinks[0x80b9bc8] ./elinks(select_loop+0x1fa)[0x80b481a] ./elinks(main+0x93)[0x80b3f13] /lib/libc.so.6(__libc_start_main+0xe0)[0xa80390] Program received signal SIGSEGV, Segmentation fault. 0x080a0772 in call_dom_stack_callbacks (stack=0x8eab318, state=0x8ebf850, action=DOM_STACK_POP) at stack.c:145 145 callback = context->info->pop[state->node->type]; (gdb) bt #0 0x080a0772 in call_dom_stack_callbacks (stack=0x8eab318, state=0x8ebf850, action=DOM_STACK_POP) at stack.c:145 #1 0x080a086e in pop_dom_node (stack=0x8eab318) at stack.c:222 #2 0x08088453 in render_dom_document (cached=0x8ebc200, document=0x8ebf490, buffer=0xbff22700) at renderer.c:138 #3 0x0808451a in render_document (vs=0x8ebf3e0, doc_view=0x8ebb898, options=0xbff22744) at renderer.c:262 #4 0x080847bd in render_document_frames (ses=0x8ea7b80, no_cache=2) at renderer.c:469 #5 0x080f5d46 in draw_formatted (ses=0x8ea7b80, rerender=3) at draw.c:351 #6 0x080e2daa in display_timer (ses=0x8ea7b80) at session.c:453 #7 0x080e4814 in loading_callback (download=0x8ebf3b8, ses=0x8ea7b80) at task.c:538 #8 0x080b7606 in notify_connection_callbacks (conn=0x8ec03e8) at connection.c:449 #9 0x080b9ae3 in read_from_socket (socket=0x8ec0480, buffer=0x8ec0f98, state=S_SENT, done=0x80d5050 ) at socket.c:912 #10 0x080d4d00 in read_more_http_data (conn=, rb=0x8ec0f98, already_got_anything=1) at http.c:1145 #11 0x080d540f in read_http_data (socket=0x8ec0480, rb=0x8ec0f98) at http.c:1350 #12 0x080d5faa in http_got_header (socket=0x8ec0480, rb=0x8ec0f98) at http.c:1906 #13 0x080b9bc8 in read_select (socket=0x8ec0480) at socket.c:879 #14 0x080b481a in select_loop (init=0x80b38a0 ) at select.c:289 #15 0x080b3f13 in main (argc=2, argv=0xbff22b74) at main.c:365 From moreno.carullo at pulc.it Thu May 8 23:49:36 2008 From: moreno.carullo at pulc.it (Moreno Carullo) Date: Fri, 9 May 2008 07:49:36 +0200 Subject: [elinks-dev] Elinks, CSS and dump Message-ID: <9210b0260805082249k116cb30au690b84d027fdf66@mail.gmail.com> I recently started hacking on Elinks, in particular on the dump functionality. I noticed that the external css of the document is never read (tested with local file and the stat command), resulting in no css applied. This can be a limit also for dumps, considering that CSS properties can also format the alignment of a text. I tested this on the development branch of Elinks. Is it the correct behavior? Thanks in advance, Moreno -- Moreno Carullo email // moreno.carullo (at) pulc (dot) it web // http://moreno.pulc.it/ skype // morec82 From witekfl at poczta.onet.pl Sun May 11 05:27:51 2008 From: witekfl at poczta.onet.pl (Witold Filipczyk) Date: Sun, 11 May 2008 13:27:51 +0200 Subject: [elinks-dev] Big files upload Message-ID: <20080511112751.GA21979@pldmachine> The big_files-1008-r branch is derived from master. On that branch there is the code handling big file uploads. The feature which was missing from the begining of the ELinks. I expect that someone review that code and eventually apply it to the master. -- Witek From kon at iki.fi Sun May 11 15:14:52 2008 From: kon at iki.fi (Kalle Olavi Niemitalo) Date: Mon, 12 May 2008 00:14:52 +0300 Subject: [elinks-dev] Big files upload In-Reply-To: <20080511112751.GA21979@pldmachine> References: <20080511112751.GA21979@pldmachine> Message-ID: <87mymwtuer.fsf@Astalo.kon.iki.fi> A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20080512/b7bac433/attachment.bin From witekfl at poczta.onet.pl Mon May 12 05:14:27 2008 From: witekfl at poczta.onet.pl (Witold Filipczyk) Date: Mon, 12 May 2008 13:14:27 +0200 Subject: [elinks-dev] Big files upload In-Reply-To: <87mymwtuer.fsf@Astalo.kon.iki.fi> References: <20080511112751.GA21979@pldmachine> <87mymwtuer.fsf@Astalo.kon.iki.fi> Message-ID: <20080512111427.GA765@pldmachine> On Mon, May 12, 2008 at 12:14:52AM +0300, Kalle Olavi Niemitalo wrote: > Witold Filipczyk writes: > > > The big_files-1008-r branch is derived from master. On that branch > > there is the code handling big file uploads. > > Thank you. It is easier for me to review a branch than a set of > patches. It is a new tradition "branch per feature" :) > In addition to what I posted as comment #4 in bug 1008, I see > these potential problems: > > - The code is duplicated between src/protocol/file/cgi.c and > src/protocol/http/http.c. This may be the best way but it > looks a bit annoying. I have no idea how to make it better. > - It is not clear how http_connection_info.post_fd is closed if > the user aborts the connection. Is http_end_request() called > in that case? It seems not. I moved the post_fd to the struct connection. Now, the post_fd is closed in many places (too many probably). > > - send_big_files() should check whether the open(big_file + 1, > O_RDONLY) call succeeds. I added a check. > - If something changes the size of the file while ELinks is > sending it, then it seems possible that the amount of data > posted does not match the generated Content-Length header. > ELinks should detect this and report an error instead of > annoying the server with an invalid request. (Alternatively, > send the POST request in chunked encoding, so that the size > need not be known in advance.) I skip this. It's too difficult to implement right now. > - You moved struct http_connection_info from > src/protocol/http/http.c to src/protocol/http/http.h but left > the related macros and comments in http.c. Please keep them > together, or at least add a comment in the definition of the > structure, saying that the values of those macros are used. I added some comments. > - In struct uri, there's a comment /* Number of files bigger than > 1M */ but the actual limit in encode_multipart() seems to be 64k. I changed the implementation. Upload of files is done by the new code for all files. > - In encode_multipart(), please check for error from fstat(). I used access intead. > - Please move struct big_files_offset into src/viewer/text/form.c > and add a comment saying that the begin and end numbers > indicate the position of the file name in the POST data > generated by encode_multipart(), thus int will be large enough > regardless of how big the files are. I added some comments. Feel free to add more. > - Please fully document the format of uri.post, including: > - whether it contains only the body or can also contain headers; > - that most of the data is encoded in hexadecimal; > - that the data can include names of files to be posted, and > each such name begins and ends with BIG_FILE_CHAR; > - that BIG_FILE_CHAR has this meaning only in the post component, > i.e. when it follows POST_CHAR. I replaced BIG_FILE_CHAR with FILE_CHAR, everywhere. I didn't add comments here. My Emglish is too bad to write more than a few sentences. -- Witek From giridhar at appaji.net Tue May 13 07:18:21 2008 From: giridhar at appaji.net (Y Giridhar Appaji Nag) Date: Tue, 13 May 2008 18:48:21 +0530 Subject: [elinks-dev] where to handle python version mismatches? Message-ID: <20080513131820.GF5814@loktak.hq.netapp.com> Hi, In Python 2.5, PyString_AsStringAndSize takes Py_ssize_t* instead of int* as its last argument. This causes ELinks 0.12 build failures on 64bit archs if Python 2.5 is used for building the Python hooks. I understand that the way to fix this sort of a thing in ELinks is to define a new type (say Py_ssize_t_T) that maps to the right thing. What would be the best place to do it? src/osdep/types.h doesn't look to the right place because I will have to include Python.h (and hence python patchlevel.h) and define Py_ssize_t_T conditionally depending on PY_VERSION_HEX. Or do you suggest that I just fix this in src/scripting/python/hooks.c where PyString_AsStringAndSize is used? i.e. cast the third argument conditionally or declare len conditionally there. Giridhar -- Y Giridhar Appaji Nag | http://appaji.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20080513/a203e508/attachment.bin From kon at iki.fi Tue May 13 13:17:55 2008 From: kon at iki.fi (Kalle Olavi Niemitalo) Date: Tue, 13 May 2008 22:17:55 +0300 Subject: [elinks-dev] where to handle python version mismatches? In-Reply-To: <20080513131820.GF5814@loktak.hq.netapp.com> References: <20080513131820.GF5814@loktak.hq.netapp.com> Message-ID: <87zlquqaho.fsf@Astalo.kon.iki.fi> A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20080513/2a43ff7e/attachment.bin From jonas.fonseca at gmail.com Tue May 13 14:42:23 2008 From: jonas.fonseca at gmail.com (Jonas Fonseca) Date: Tue, 13 May 2008 22:42:23 +0200 Subject: [elinks-dev] Big files upload In-Reply-To: <20080512111427.GA765@pldmachine> References: <20080511112751.GA21979@pldmachine> <87mymwtuer.fsf@Astalo.kon.iki.fi> <20080512111427.GA765@pldmachine> Message-ID: <2c6b72b30805131342y53340945g9cacc2fbc2948f29@mail.gmail.com> On Mon, May 12, 2008 at 1:14 PM, Witold Filipczyk wrote: > On Mon, May 12, 2008 at 12:14:52AM +0300, Kalle Olavi Niemitalo wrote: > > Witold Filipczyk writes: > > > > > The big_files-1008-r branch is derived from master. On that branch > > > there is the code handling big file uploads. > > > > Thank you. It is easier for me to review a branch than a set of > > patches. > > It is a new tradition "branch per feature" :) This is a good idea, however, it also means that you share these branches with everybody since you chose to put them in the public tree. I'd rather that we try to keep the public tree somewhat clean with respect with branches. This is made very easy by places like repo.or.cz/gitorious.org/github.com where you can make your own fork/clone to host the stuff. -- Jonas Fonseca From levinsm at users.sourceforge.net Tue May 13 22:43:57 2008 From: levinsm at users.sourceforge.net (M. Levinson) Date: Wed, 14 May 2008 00:43:57 -0400 Subject: [elinks-dev] where to handle python version mismatches? In-Reply-To: <87zlquqaho.fsf@Astalo.kon.iki.fi> Message-ID: <1190.1210740237@poultrygeist.com> On May 13, 2008, at 10:17pm, Kalle Olavi Niemitalo writes: >I think we should copy this code snippet from the public-domain >PEP 353 : > >#if PY_VERSION_HEX < 0x02050000 && !defined(PY_SSIZE_T_MIN) >typedef int Py_ssize_t; >#define PY_SSIZE_T_MAX INT_MAX >#define PY_SSIZE_T_MIN INT_MIN >#endif > >into src/scripting/python/core.h, with a comment saying where it >came from. Then also change python_menu() to use Py_ssize_t for >the result of PySequence_Length(items) and return NULL if length >exceeds INT_MAX. That and script_hook_pre_format_html() are the >only relevant uses of int in /src/scripting/python/, I think. For what it's worth, I looked into this at one point and came to the same conclusions as you did above. But as I recall, I was still left wondering if there's a sufficiently portable way to determine whether a Py_ssize_t value could overflow an off_t when the len from PyString_AsStringAndSize() is passed to normalize_cache_entry(), which takes an off_t parameter. Was I missing something obvious? From giridhar at appaji.net Wed May 14 00:11:17 2008 From: giridhar at appaji.net (Y Giridhar Appaji Nag) Date: Wed, 14 May 2008 11:41:17 +0530 Subject: [elinks-dev] where to handle python version mismatches? In-Reply-To: <87zlquqaho.fsf@Astalo.kon.iki.fi> References: <20080513131820.GF5814@loktak.hq.netapp.com> <87zlquqaho.fsf@Astalo.kon.iki.fi> Message-ID: <20080514061116.GB4189@loktak.hq.netapp.com> On 08/05/13 22:17 +0300, Kalle Olavi Niemitalo said ... > Y Giridhar Appaji Nag writes: > > > In Python 2.5, PyString_AsStringAndSize takes Py_ssize_t* instead of int* as > > its last argument. This causes ELinks 0.12 build failures on 64bit archs if > > Python 2.5 is used for building the Python hooks. > > Does ELinks 0.11 also fail to build? Does it work correctly? I did not try this but I am certain it would failt to build. > The Python scripting module is marked as experimental, so build > failures caused by it might not have to be fixed in the stable > elinks-0.11 branch. OTOH, if it builds but corrupts memory at > runtime, that's more serious. Indeed, I uploaded a snapshot of elinks 0.12 to Debian experimental with experimental features and --debug enabled. This is a Debian "experimental" only bug. > I think we should copy this code snippet from the public-domain > PEP 353 : > > #if PY_VERSION_HEX < 0x02050000 && !defined(PY_SSIZE_T_MIN) > typedef int Py_ssize_t; > #define PY_SSIZE_T_MAX INT_MAX > #define PY_SSIZE_T_MIN INT_MIN > #endif > > into src/scripting/python/core.h, with a comment saying where it > came from. Then also change python_menu() to use Py_ssize_t for > the result of PySequence_Length(items) and return NULL if length > exceeds INT_MAX. That and script_hook_pre_format_html() are the > only relevant uses of int in /src/scripting/python/, I think. OK. I will try and submit a patch, however, I don't have a 64bit machine to compile and test so it might take some time because I don't want to submit an untested patch. Giridhar -- Y Giridhar Appaji Nag | http://appaji.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20080514/093dbbb8/attachment.bin