From fonseca at diku.dk  Tue May  1 01:30:28 2007
From: fonseca at diku.dk (Jonas Fonseca)
Date: Tue, 1 May 2007 09:30:28 +0200
Subject: [elinks-dev] How do I tell the document has changed?
In-Reply-To: <46368311.9070801@seiner.com>
References: <46368311.9070801@seiner.com>
Message-ID: <20070501073028.GC27876@diku.dk>

Yan Seiner <yan at seiner.com> wrote Mon, Apr 30, 2007:
> Is there something that is guaranteed to change on load/reload that I 
> can check for quickly?  Perhaps something like document_view->name?

A struct document contains a field called "id' which is basically a
counter controlled by the cache system and which is changed--for the
same URL--on reload and unique across different URLs. Maybe it can be
used. 

-- 
Jonas Fonseca

From yan at seiner.com  Wed May  2 16:36:26 2007
From: yan at seiner.com (Yan Seiner)
Date: Wed, 02 May 2007 15:36:26 -0700
Subject: [elinks-dev] Navigating
Message-ID: <4639126A.7090207@seiner.com>

I'm trying to make elinks into a front end for our embedded panel.  So 
far, I've figured out how to manipulate the form and users can enter and 
modify the information on the forms with our interface.

I'm having a bit of an issue with navigation, though.

Question 1:

The form fields are labeled and contain attributes with nav info, eg
<INPUT type='text'  class='float' id='F_2' idindex='22'  tabindex='14' 
WRAP='true'  NUMTYPE='bearing'  VALUE='125'  SIZE='4'  NAME='F_2'  
right='T_2' left='' up='F_1' down='F_3'>

So on down arrow I need to navigate to the INPUT field with ID of 
'F_3'.  I've modified the parser code to extract the attributes I need, 
but I can't figure out the navigation....

How do I navigate 'by force'?  Somehow I need to be able to extract the 
information from the INPUT element and use it to navigate.  I've tried 
next_link_in_dir from within the forms editor but it seems to have no 
effect....

What function or combination of functions should I be looking at to:

exit edit mode
navigate to a given field in the form


Question 2:

I need to implement shortcuts so that when a user hits a button, s/he is 
taken to a new page.  Right now I have F1 mapped to "HomeURL", F2 to 
'back", and F5 to "HelpURL".  How do I tie these keys to URLs?

Thanks,

--Yan

From fonseca at diku.dk  Thu May  3 01:26:37 2007
From: fonseca at diku.dk (Jonas Fonseca)
Date: Thu, 3 May 2007 09:26:37 +0200
Subject: [elinks-dev] Navigating
In-Reply-To: <4639126A.7090207@seiner.com>
References: <4639126A.7090207@seiner.com>
Message-ID: <20070503072637.GB20340@diku.dk>

Yan Seiner <yan at seiner.com> wrote Wed, May 02, 2007:
> I'm trying to make elinks into a front end for our embedded panel.  So 
> far, I've figured out how to manipulate the form and users can enter and 
> modify the information on the forms with our interface.
> 
> I'm having a bit of an issue with navigation, though.
> 
> Question 1:
> 
> The form fields are labeled and contain attributes with nav info, eg
> <INPUT type='text'  class='float' id='F_2' idindex='22'  tabindex='14' 
> WRAP='true'  NUMTYPE='bearing'  VALUE='125'  SIZE='4'  NAME='F_2'  
> right='T_2' left='' up='F_1' down='F_3'>
> 
> So on down arrow I need to navigate to the INPUT field with ID of 
> 'F_3'.  I've modified the parser code to extract the attributes I need, 
> but I can't figure out the navigation....
> 
> How do I navigate 'by force'?  Somehow I need to be able to extract the 
> information from the INPUT element and use it to navigate.  I've tried 
> next_link_in_dir from within the forms editor but it seems to have no 
> effect....
> 
> What function or combination of functions should I be looking at to:
> 
> exit edit mode
> navigate to a given field in the form

I think it will be enough to search the document->links for the form and then
jump to the link. Maybe you need to escape the edit/insert mode yourself.

	struct document *document = doc_view->document;
        int link;

        for (link = 0; link < document->nlinks; link++) {
                struct form_control *fc = get_link_form_control(&document->links[link]);

                if (fc && fc->form == form
		    && CHECK FOR FORM ID) {
                        jump_to_link_number(ses, doc_view, link);
                        return;
                }
        }

> Question 2:
> 
> I need to implement shortcuts so that when a user hits a button, s/he is 
> taken to a new page.  Right now I have F1 mapped to "HomeURL", F2 to 
> 'back", and F5 to "HelpURL".  How do I tie these keys to URLs?

Using building keybindings / actions. This requires adding something to
src/config/action-*.inc and src/viewer/action.c. Maybe try to look for
the patch of a new action that was added in the past.

-- 
Jonas Fonseca

From yan at seiner.com  Thu May  3 07:51:13 2007
From: yan at seiner.com (Yan Seiner)
Date: Thu, 03 May 2007 06:51:13 -0700
Subject: [elinks-dev] Navigating
In-Reply-To: <20070503072637.GB20340@diku.dk>
References: <4639126A.7090207@seiner.com> <20070503072637.GB20340@diku.dk>
Message-ID: <4639E8D1.9070101@seiner.com>

Jonas Fonseca napsal(a):
> Yan Seiner <yan at seiner.com> wrote Wed, May 02, 2007:
>   
>> I'm trying to make elinks into a front end for our embedded panel.  So 
>> far, I've figured out how to manipulate the form and users can enter and 
>> modify the information on the forms with our interface.
>>
>> I'm having a bit of an issue with navigation, though.
>>
>> Question 1:
>>
>> The form fields are labeled and contain attributes with nav info, eg
>> <INPUT type='text'  class='float' id='F_2' idindex='22'  tabindex='14' 
>> WRAP='true'  NUMTYPE='bearing'  VALUE='125'  SIZE='4'  NAME='F_2'  
>> right='T_2' left='' up='F_1' down='F_3'>
>>
>> So on down arrow I need to navigate to the INPUT field with ID of 
>> 'F_3'.  I've modified the parser code to extract the attributes I need, 
>> but I can't figure out the navigation....
>>
>> How do I navigate 'by force'?  Somehow I need to be able to extract the 
>> information from the INPUT element and use it to navigate.  I've tried 
>> next_link_in_dir from within the forms editor but it seems to have no 
>> effect....
>>
>> What function or combination of functions should I be looking at to:
>>
>> exit edit mode
>> navigate to a given field in the form
>>     
>
> I think it will be enough to search the document->links for the form and then
> jump to the link. Maybe you need to escape the edit/insert mode yourself.
>
> 	struct document *document = doc_view->document;
>         int link;
>
>         for (link = 0; link < document->nlinks; link++) {
>                 struct form_control *fc = get_link_form_control(&document->links[link]);
>
>                 if (fc && fc->form == form
> 		    && CHECK FOR FORM ID) {
>                         jump_to_link_number(ses, doc_view, link);
>                         return;
>                 }
>         }
>   
OK, thanks.
>   
>> Question 2:
>>
>> I need to implement shortcuts so that when a user hits a button, s/he is 
>> taken to a new page.  Right now I have F1 mapped to "HomeURL", F2 to 
>> 'back", and F5 to "HelpURL".  How do I tie these keys to URLs?
>>     
>
> Using building keybindings / actions. This requires adding something to
> src/config/action-*.inc and src/viewer/action.c. Maybe try to look for
> the patch of a new action that was added in the past.
>
>   

Great!  I'll look into that section of the code when I get to work...

One thing that would help developers like me is a diagram of the path 
that a character takes as it moves from the keyboard through elinks....  
(If this is in the docs, I missed it...)

I really like the way the code is structured, and it all makes a lot of 
sense, but it is difficult to trace how keyboard input is handled.

For my application, elinks is a great front end to a complex back end.

Thanks for all the hard work, folks.

--Yan

From yan at seiner.com  Mon May  7 16:10:19 2007
From: yan at seiner.com (Yan Seiner)
Date: Mon, 07 May 2007 15:10:19 -0700
Subject: [elinks-dev] Edit mode not exiting cleanly on "Back"
Message-ID: <463FA3CB.2030304@seiner.com>

I have a custom web page with lots of form fields.

I've redefined F2 to be the "back" key.

What happens is that the screen is not resetting the reverse mode.  If I 
am in an edit field and in edit mode and hit back, the reverse mode is 
carried over to the previous screen.  If I enter that screen via a link, 
it displays correctly.  If am not in edit mode when I hit "back",  it 
displays correctly.

I've posted the jpeg at http://www.seiner.com/reverse.jpeg

Can anyone shed any light on this?  Where do I look to fix this?

--Yan

From kon at iki.fi  Tue May  8 00:17:25 2007
From: kon at iki.fi (Kalle Olavi Niemitalo)
Date: Tue, 08 May 2007 09:17:25 +0300
Subject: [elinks-dev] Edit mode not exiting cleanly on "Back"
In-Reply-To: <463FA3CB.2030304@seiner.com>
References: <463FA3CB.2030304@seiner.com>
Message-ID: <87zm4fn8ju.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/20070508/14e98317/attachment.bin 

From yan at seiner.com  Tue May  8 09:12:38 2007
From: yan at seiner.com (Yan Seiner)
Date: Tue, 08 May 2007 08:12:38 -0700
Subject: [elinks-dev] Edit mode not exiting cleanly on "Back"
In-Reply-To: <87zm4fn8ju.fsf@Astalo.kon.iki.fi>
References: <463FA3CB.2030304@seiner.com> <87zm4fn8ju.fsf@Astalo.kon.iki.fi>
Message-ID: <46409366.7030804@seiner.com>

Kalle Olavi Niemitalo wrote:
> Yan Seiner <yan at seiner.com> writes:
>
>   
>> What happens is that the screen is not resetting the reverse
>> mode.  If I am in an edit field and in edit mode and hit back,
>> the reverse mode is carried over to the previous screen.  If I
>> enter that screen via a link, it displays correctly.  If am not
>> in edit mode when I hit "back", it displays correctly.
>>     
>
> If I understand correctly, you mean:
> - Bind F2 to history-move-back.
> - Set document.browse.forms.insert_mode = 1.
> - Go to a page that contains a text field.
> - Select this text field.
> - Go to another page that contains a text field.
> - Select this text field.
> - Press Enter (ACT_EDIT_ENTER) to enter insert mode.
> - Press F2 (ACT_MAIN_HISTORY_MOVE_BACK) to return to the first
>   page.
> - The text field in the first page is highlighted as if insert
>   mode were enabled.
> - Press o.
> - ELinks does not insert the "o" to the text field but rather
>   opens the option manager.  So insert mode was not actually
>   enabled.
>
>   
>> Can anyone shed any light on this?  Where do I look to fix this?
>>     
>
> This occurs because draw_current_link redraws the text field
> before do_action sets ses->insert_mode = INSERT_MODE_OFF.
> Text fields are drawn in two steps: draw_current_link draws the
> attributes, and draw_form_entry draws the characters.
>   
Thanks.  Is this going to be fixed in CVS or should I just try and hack 
around it?

--Yan

> In ELinks 0.12.GIT (d1fa336f7f390d9b51456498fac5dda8f54c18a4):
>
> (gdb) backtrace
> #0  draw_current_link (ses=0x8459780, doc_view=0x8450a58)
>     at /home/Kalle/src/elinks-0.12/src/viewer/text/link.c:231
> #1  0x08115f54 in draw_view_status (ses=0x8459780, doc_view=0x8450a58,
>     active=1) at /home/Kalle/src/elinks-0.12/src/viewer/text/draw.c:175
> #2  0x081165da in draw_doc (ses=0x8459780, doc_view=0x8450a58, active=1)
>     at /home/Kalle/src/elinks-0.12/src/viewer/text/draw.c:297
> #3  0x08116df3 in refresh_view (ses=0x8459780, doc_view=0x8450a58, frames=1)
>     at /home/Kalle/src/elinks-0.12/src/viewer/text/draw.c:386
> #4  0x08116dba in draw_formatted (ses=0x8459780, rerender=2)
>     at /home/Kalle/src/elinks-0.12/src/viewer/text/draw.c:380
> #5  0x080fa410 in display_timer (ses=0x8459780)
>     at /home/Kalle/src/elinks-0.12/src/session/session.c:452
> #6  0x080fe430 in loading_callback (download=0x84597b8, ses=0x8459780)
>     at /home/Kalle/src/elinks-0.12/src/session/task.c:537
> #7  0x080d044b in load_uri (uri=0x84d8480, referrer=0x0, download=0x84597b8,
>     pri=PRI_MAIN, cache_mode=CACHE_MODE_ALWAYS, start=-1)
>     at /home/Kalle/src/elinks-0.12/src/network/connection.c:916
> #8  0x080fd069 in ses_load (ses=0x8459780, uri=0x84d8480, target_frame=0x0,
>     target_location=0x85e8168, cache_mode=CACHE_MODE_ALWAYS,
>     task_type=TASK_HISTORY)
>     at /home/Kalle/src/elinks-0.12/src/session/task.c:83
> #9  0x080fd532 in ses_goto (ses=0x8459780, uri=0x84d8480, target_frame=0x0,
>     target_location=0x85e8168, cache_mode=CACHE_MODE_ALWAYS,
>     task_type=TASK_HISTORY, redir=0)
>     at /home/Kalle/src/elinks-0.12/src/session/task.c:221
> #10 0x080f8e7d in go_history (ses=0x8459780, loc=0x85e8168)
>     at /home/Kalle/src/elinks-0.12/src/session/history.c:156
> #11 0x080f8f9a in go_history_by_n (ses=0x8459780, n=1)
>     at /home/Kalle/src/elinks-0.12/src/session/history.c:175
> #12 0x081128d5 in do_action (ses=0x8459780,
>     action_id=ACT_MAIN_HISTORY_MOVE_BACK, verbose=0)
>     at /home/Kalle/src/elinks-0.12/src/viewer/action.c:268
> #13 0x0812b8e4 in send_kbd_event (ses=0x8459780, doc_view=0x8450a58,
>     ev=0xbfd88574) at /home/Kalle/src/elinks-0.12/src/viewer/text/view.c:1159
> #14 0x0812bb79 in send_event (ses=0x8459780, ev=0xbfd88574)
>     at /home/Kalle/src/elinks-0.12/src/viewer/text/view.c:1224
> #15 0x080fca3c in tabwin_func (tab=0x84509c0, ev=0xbfd88574)
>     at /home/Kalle/src/elinks-0.12/src/session/session.c:1280
> #16 0x08100cb2 in term_send_event (term=0x8451b68, ev=0xbfd88574)
>     at /home/Kalle/src/elinks-0.12/src/terminal/event.c:131
> #17 0x081015da in handle_interlink_event (term=0x8451b68, ilev=0x8451d18)
>     at /home/Kalle/src/elinks-0.12/src/terminal/event.c:390
> #18 0x08101981 in in_term (term=0x8451b68)
>     at /home/Kalle/src/elinks-0.12/src/terminal/event.c:494
> #19 0x080ca0c3 in select_loop (init=0x80c8c8f <init>)
>     at /home/Kalle/src/elinks-0.12/src/main/select.c:289
> #20 0x080c9407 in main (argc=1, argv=0xbfd88714)
>     at /home/Kalle/src/elinks-0.12/src/main/main.c:360
> (gdb)
>
>
> !DSPAM:464015d940451874319035!
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> elinks-dev mailing list
> elinks-dev at linuxfromscratch.org
> http://linuxfromscratch.org/mailman/listinfo/elinks-dev
>
>
> !DSPAM:464015d940451874319035!
>   


From kon at iki.fi  Tue May  8 15:19:23 2007
From: kon at iki.fi (Kalle Olavi Niemitalo)
Date: Wed, 09 May 2007 00:19:23 +0300
Subject: [elinks-dev] Edit mode not exiting cleanly on "Back"
In-Reply-To: <46409366.7030804@seiner.com>
References: <463FA3CB.2030304@seiner.com> <87zm4fn8ju.fsf@Astalo.kon.iki.fi>
	<46409366.7030804@seiner.com>
Message-ID: <87vef3m2sk.fsf@Astalo.kon.iki.fi>

Yan Seiner <yan at seiner.com> writes:

> Thanks.  Is this going to be fixed in CVS or should I just try and hack 
> around it?

I don't know if any ELinks developer is interested in fixing this
bug.  It has rather little impact and the fix is not obvious.  If
you post a patch, it may be accepted to Git (not CVS since 0.11.0).
-------------- next part --------------
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/20070509/885ca250/attachment.bin 

From yan at seiner.com  Thu May 10 09:56:32 2007
From: yan at seiner.com (Yan Seiner)
Date: Thu, 10 May 2007 08:56:32 -0700
Subject: [elinks-dev] Edit mode not exiting cleanly on "Back"
In-Reply-To: <87vef3m2sk.fsf@Astalo.kon.iki.fi>
References: <463FA3CB.2030304@seiner.com>
	<87zm4fn8ju.fsf@Astalo.kon.iki.fi>	<46409366.7030804@seiner.com>
	<87vef3m2sk.fsf@Astalo.kon.iki.fi>
Message-ID: <464340B0.3010404@seiner.com>

Kalle Olavi Niemitalo wrote:
> Yan Seiner <yan at seiner.com> writes:
>
>   
>> Thanks.  Is this going to be fixed in CVS or should I just try and hack 
>> around it?
>>     
>
> I don't know if any ELinks developer is interested in fixing this
> bug.  It has rather little impact and the fix is not obvious.  If
> you post a patch, it may be accepted to Git (not CVS since 0.11.0).
>   
OK, a simple fix:

in viewer/action.c, turn off insert mode for

case: ACT_MAIN_HISTORY_BACK:
   {
    ses->insert_mode = INSERT_MODE_OFF;
...

More of a hack rather than a fix as it leaves the same problem for all 
the other actions, but it fixes it for this one special case.

--Yan

From kon at iki.fi  Wed May 16 00:09:02 2007
From: kon at iki.fi (Kalle Olavi Niemitalo)
Date: Wed, 16 May 2007 09:09:02 +0300
Subject: [elinks-dev] Why utf8_linux_frame_seqs?
Message-ID: <871whhb8qp.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/20070516/7c700864/attachment.bin 

From witekfl at poczta.onet.pl  Wed May 16 10:23:54 2007
From: witekfl at poczta.onet.pl (Witold Filipczyk)
Date: Wed, 16 May 2007 18:23:54 +0200
Subject: [elinks-dev] Why utf8_linux_frame_seqs?
In-Reply-To: <871whhb8qp.fsf@Astalo.kon.iki.fi>
References: <871whhb8qp.fsf@Astalo.kon.iki.fi>
Message-ID: <20070516162354.GA19950@pldmachine>

On Wed, May 16, 2007 at 09:09:02AM +0300, Kalle Olavi Niemitalo wrote:
> In ELinks 0.12.GIT (f8f99cc04ea0ff1f64c0452f5232e1b2567493c2):
> 
> - If UTF-8 I/O is disabled, then src/terminal/screen.c outputs
>   normal characters in the terminal charset, and frame characters
>   usually in a separate frame charset.  To switch between the
>   charsets, it outputs strings from screen_driver.frame_seqs[].
> 
> - If UTF-8 I/O is enabled and CONFIG_UTF8 is not defined, then
>   src/terminal/screen.c outputs all characters in UTF-8.  It
>   converts frame characters first to some unibyte codepage that
>   supports them (typically CP437), and then to UCS-4 and UTF-8.
> 
> - If UTF-8 I/O is enabled and CONFIG_UTF8 is defined, then
>   src/terminal/screen.c outputs normal characters in UTF-8,
>   and frame characters usually in a separate frame charset.
>   To switch between the charsets, it outputs strings from
>   screen_driver.frame_seqs[], which may be
>   utf8_linux_frame_seqs[] defined for this purpose.
> 
> I would like to change src/terminal/screen.c so that UTF-8 I/O
> always outputs frame characters in UTF-8, regardless of whether
> CONFIG_UTF8 is defined.  I have already implemented this but the
> change is currently entangled with fixes for bug 914 and
> separating it will take some time.

You can remove utf8_linux_frame_seqs. It forces the UTF-8 mode on
the Linux console. Proper way is to set the UTF-8 mode before starting
the ELinks.

-- 
Witek


From yan at seiner.com  Wed May 16 12:48:29 2007
From: yan at seiner.com (Yan Seiner)
Date: Wed, 16 May 2007 11:48:29 -0700
Subject: [elinks-dev] [elinks-users] Embedded flash
In-Reply-To: <464B4147.1020500@seiner.com>
References: <464B28EF.5010506@seiner.com> <464B4147.1020500@seiner.com>
Message-ID: <464B51FD.5020802@seiner.com>

Yan Seiner wrote:
> Looking through the code, elinks creates a link to the flash animation, 
> which has to be clicked.
>
> What I need is for elinks to automagically follow that link and launch 
> the player.
>
> Any way to do that within the framework of elinks?
>   
So I'm having this conversation with myself - but I've moved it to the 
-dev list.  :-)

What I really need to figure out is how to automagically launch 
applications for specific mime types, rather than just creating links 
for them.

Also, I need to figure out how to emulate AJAX - I need to continuously 
refresh a specific field in a form via http: queries.  Where do I begin 
to look?

From witekfl at poczta.onet.pl  Fri May 18 12:29:24 2007
From: witekfl at poczta.onet.pl (Witold Filipczyk)
Date: Fri, 18 May 2007 20:29:24 +0200
Subject: [elinks-dev] [elinks-users] Embedded flash
In-Reply-To: <464B51FD.5020802@seiner.com>
References: <464B28EF.5010506@seiner.com> <464B4147.1020500@seiner.com>
	<464B51FD.5020802@seiner.com>
Message-ID: <20070518182924.GA4494@pldmachine>

On Wed, May 16, 2007 at 11:48:29AM -0700, Yan Seiner wrote:
> Yan Seiner wrote:
> > Looking through the code, elinks creates a link to the flash animation, 
> > which has to be clicked.
> >
> > What I need is for elinks to automagically follow that link and launch 
> > the player.
> >
> > Any way to do that within the framework of elinks?
> >   
> So I'm having this conversation with myself - but I've moved it to the 
> -dev list.  :-)
> 
> What I really need to figure out is how to automagically launch 
> applications for specific mime types, rather than just creating links 
> for them.

You can use browser scripting eg. Lua to rewrite HTML.
Instead of <object>...</object> use
<meta http-equiv="Refresh" content="0; URL">,
where URL is the URL to your movie. The above is not correct syntax for
refresh, but should work.
 
> Also, I need to figure out how to emulate AJAX - I need to continuously 
> refresh a specific field in a form via http: queries.  Where do I begin 
> to look?

I have no idea here.

-- 
Witek

From kon at iki.fi  Sun May 20 01:45:44 2007
From: kon at iki.fi (Kalle Olavi Niemitalo)
Date: Sun, 20 May 2007 10:45:44 +0300
Subject: [elinks-dev] Why utf8_linux_frame_seqs?
In-Reply-To: <20070516162354.GA19950@pldmachine>
References: <871whhb8qp.fsf@Astalo.kon.iki.fi>
	<20070516162354.GA19950@pldmachine>
Message-ID: <87lkfkrl93.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/20070520/2381694c/attachment.bin 

From kon at iki.fi  Sat May 26 09:58:21 2007
From: kon at iki.fi (Kalle Olavi Niemitalo)
Date: Sat, 26 May 2007 18:58:21 +0300
Subject: [elinks-dev] http://troll.no/ appears blank in ELinks 0.11.3
Message-ID: <878xbbo9uq.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/20070526/2da76861/attachment.bin 

From kon at iki.fi  Mon May 28 15:54:08 2007
From: kon at iki.fi (Kalle Olavi Niemitalo)
Date: Tue, 29 May 2007 00:54:08 +0300
Subject: [elinks-dev] increased risk of ECMAScript crashes in ELinks
	0.11.3.GIT
Message-ID: <87myzofwcf.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/20070529/ae3a153f/attachment.bin 

From fonseca at diku.dk  Tue May 29 14:33:16 2007
From: fonseca at diku.dk (Jonas Fonseca)
Date: Tue, 29 May 2007 22:33:16 +0200
Subject: [elinks-dev] increased risk of ECMAScript crashes in ELinks
	0.11.3.GIT
In-Reply-To: <87myzofwcf.fsf@Astalo.kon.iki.fi>
References: <87myzofwcf.fsf@Astalo.kon.iki.fi>
Message-ID: <20070529203316.GB6358@diku.dk>

Kalle Olavi Niemitalo <kon at iki.fi> wrote Tue, May 29, 2007:
> Fonseca, if you release ELinks 0.11.4 soon, please revert
> these commits first:
> 
> 644908c130210ed7b17a3bd1241244576b94c546
>   Garbage-collect SMJS objects before flushing caches.
> 
> 5a49b9f14d4b8bb30bfada4958c22e6a8cfab21e
>   NEWS: mention bug 951
> 
> The extra garbage collections increase the risk of crashing
> because of dangling pointers in form_state.ecmascript_obj.
> This bug has been fixed in commit
> b4d9b7f5a60a64a26fcfffcb66a376cae5b31bc1 in ELinks 0.12.GIT.
> I am going to add the bug to bugzilla.elinks.cz (it is not the
> same as bug 755, which is about pointers _to_ struct form_state)
> and then backport that commit to 0.11.3.GIT (or 0.11.4.GIT).
> The fix in 0.12.GIT is not entirely correct (it breaks object
> identity comparisons) but fixing the bug properly will take
> some time and I think it is more important now to remove the
> risk of crashing.

Ok, thanks for the warning, however, I thought that I expressed that I
do not really consider ECMAScript related crashes as something to worry
about for the current stable version.

I will try to find time to release 0.11.4 in the start of June.

-- 
Jonas Fonseca

From kon at iki.fi  Tue May 29 16:02:24 2007
From: kon at iki.fi (Kalle Olavi Niemitalo)
Date: Wed, 30 May 2007 01:02:24 +0300
Subject: [elinks-dev] increased risk of ECMAScript crashes in ELinks
	0.11.3.GIT
In-Reply-To: <20070529203316.GB6358@diku.dk>
References: <87myzofwcf.fsf@Astalo.kon.iki.fi> <20070529203316.GB6358@diku.dk>
Message-ID: <87ps4j70gf.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/20070530/6a804307/attachment.bin 

From witekfl at poczta.onet.pl  Wed May 30 09:32:42 2007
From: witekfl at poczta.onet.pl (Witold Filipczyk)
Date: Wed, 30 May 2007 17:32:42 +0200
Subject: [elinks-dev] Memory allocation
Message-ID: <20070530153242.GA4594@pldmachine>

Hi!
I have such an idea. I saw it in other program.
Instead of check everywhere if mem_alloc, mem_calloc or mem_realloc
succeed. Check it only in those functions.
When there is no more memory say sorry and exit.
All other checks could be removed.
ELinks will be smaller, therefore faster.

-- 
Witek

From witekfl at poczta.onet.pl  Wed May 30 13:35:59 2007
From: witekfl at poczta.onet.pl (Witold Filipczyk)
Date: Wed, 30 May 2007 21:35:59 +0200
Subject: [elinks-dev] Memory allocation
In-Reply-To: <20070530153242.GA4594@pldmachine>
References: <20070530153242.GA4594@pldmachine>
Message-ID: <20070530193559.GA17233@pldmachine>

On Wed, May 30, 2007 at 05:32:42PM +0200, Witold Filipczyk wrote:
> Hi!
> I have such an idea. I saw it in other program.
> Instead of check everywhere if mem_alloc, mem_calloc or mem_realloc
> succeed. Check it only in those functions.
> When there is no more memory say sorry and exit.
> All other checks could be removed.
> ELinks will be smaller, therefore faster.

I just saw that links works that way.
What was the reason to change that in the ELinks?

-- 
Witek

From kon at iki.fi  Wed May 30 15:46:02 2007
From: kon at iki.fi (Kalle Olavi Niemitalo)
Date: Thu, 31 May 2007 00:46:02 +0300
Subject: [elinks-dev] Memory allocation
In-Reply-To: <20070530153242.GA4594@pldmachine>
References: <20070530153242.GA4594@pldmachine>
Message-ID: <87ps4ikmsl.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/20070531/34a8da83/attachment.bin 

From kon at iki.fi  Wed May 30 16:02:38 2007
From: kon at iki.fi (Kalle Olavi Niemitalo)
Date: Thu, 31 May 2007 01:02:38 +0300
Subject: [elinks-dev] Memory allocation
In-Reply-To: <20070530193559.GA17233@pldmachine>
References: <20070530153242.GA4594@pldmachine>
	<20070530193559.GA17233@pldmachine>
Message-ID: <87lkf6km0x.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/20070531/cf839e71/attachment.bin 

From fonseca at diku.dk  Thu May 31 07:20:21 2007
From: fonseca at diku.dk (Jonas Fonseca)
Date: Thu, 31 May 2007 15:20:21 +0200
Subject: [elinks-dev] increased risk of ECMAScript crashes in ELinks
	0.11.3.GIT
In-Reply-To: <87ps4j70gf.fsf@Astalo.kon.iki.fi>
References: <87myzofwcf.fsf@Astalo.kon.iki.fi> <20070529203316.GB6358@diku.dk>
	<87ps4j70gf.fsf@Astalo.kon.iki.fi>
Message-ID: <20070531132021.GB27044@diku.dk>

Kalle Olavi Niemitalo <kon at iki.fi> wrote Wed, May 30, 2007:
> Jonas Fonseca <fonseca at diku.dk> writes:
> 
> > Ok, thanks for the warning, however, I thought that I expressed that I
> > do not really consider ECMAScript related crashes as something to worry
> > about for the current stable version.
> 
> 2007-05-27:
> <paakku> fonseca: Should bug 755 be fixed in 0.11.3.GIT or 0.11.4.GIT?
> <fonseca> paakku: I don't really care about ECMAScript bugs.
> 
> Crashes caused by dangling pointers may be exploitable (unlike
> crashes caused by null pointers).  I think they should be fixed
> regardless of whether they occur in ECMAScript support or
> elsewhere in ELinks.  And I especially don't want to become
> responsible of making a release crash more than the previous one.

Fair enough. I guess my reason for not caring stems from the feeling of
ECMAScript being pushed too soon before it was even half decent. Perhaps
those days are over. ;)

> > I will try to find time to release 0.11.4 in the start of June.
> 
> I don't think I'll be able to fix things properly before that,
> so I have now reverted the two commits from elinks-0.11.

Ok, cool. Will try to find time to do the preparations for .4

-- 
Jonas Fonseca

From fonseca at diku.dk  Thu May 31 07:37:30 2007
From: fonseca at diku.dk (Jonas Fonseca)
Date: Thu, 31 May 2007 15:37:30 +0200
Subject: [elinks-dev] Memory allocation
In-Reply-To: <87ps4ikmsl.fsf@Astalo.kon.iki.fi>
References: <20070530153242.GA4594@pldmachine>
	<87ps4ikmsl.fsf@Astalo.kon.iki.fi>
Message-ID: <20070531133730.GC27044@diku.dk>

Kalle Olavi Niemitalo <kon at iki.fi> wrote Thu, May 31, 2007:
> Which reminds me of bug 297.  Can we use libapr for memory pools?

I remember Miciah also mentioning talloc by the Samba devs.

-- 
Jonas Fonseca