vimprobable-users Mailing List for Vimprobable (Page 28)

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hi Hannes!

Pretty nice work!

Daniel

Hi,

here is an updated version of the download hinting patch, adapted for
the new hinting backend. This does not yet explore the possibility of
using the semicolon as a prefix for different hinting modes as
Hans-Peter suggested (and as used in Vimperator), but I wanted to get
the basic functionality back first.

Hannes

Ryan Mullen <rm...@de...> wrote:
> 2011/9/16 Hannes Schüller <ha...@yl...>:
> > Ryan Mullen <rm...@de...> wrote:
> >> Using the most recent hg build, if I sign into the gmail web
> >> interface, my browser-based gchat client is able to connect if and
> >> only if I have a previously untouched cookies file.
> >
> > So, when you're talking about wiping the cookie file, do you mean it
> > has to be completely blank or just free of Google cookies?
> 
> Just Google cookies need to be cleared. Also, I have trouble logging
> into my Google (Apps) account that I use for this email address. If I
> have google cookies from logging into my other gmail account, I can't
> seem to log into this account. If I clear them, I can.

Have you tried looking what's inside this cookie? Anything
readable/suspicious?

Hannes

Hi,

2011/9/16 Hannes Schüller <ha...@yl...>:
> Ryan Mullen <rm...@de...> wrote:
>> Using the most recent hg build, if I sign into the gmail web
>> interface, my browser-based gchat client is able to connect if and
>> only if I have a previously untouched cookies file.
>
> So, when you're talking about wiping the cookie file, do you mean it
> has to be completely blank or just free of Google cookies?

Just Google cookies need to be cleared. Also, I have trouble logging
into my Google (Apps) account that I use for this email address. If I
have google cookies from logging into my other gmail account, I can't
seem to log into this account. If I clear them, I can.

So strange!

Ryan

Hi!

I looked through the code and found places where memory wasn't free()d. I'm a
C-beginner so maybe some of the free()s aren't needed.

Daniel

Sorry, I missed a g_free().

Following patch is a replacement for previous patches.

Daniel

Hi!
On Fri, Sep 16, 2011 at 05:18:25PM +0200, Hans-Peter Deifel wrote:
> Hi,
> 
> It would be nice if we could finally get consistent behaviour regarding
> mallocing and freeing. This means, that script() shouldn't free
> anything and we should instead track down all the places where it's used
> and call free() there. This should also remove the need for a SAVEFREE
> macro.

I like consistency, and the most parts use free-by-caller, so why not to apply
this paradigm to the script() function too.

Following patch removes freeing from script function and fixex also the crash
on :echo foo call.

I think the code should be refactered. In the last days i saw multiple places,
where memory is allocated via g_strdup() and not free()d. By the way we could
replace parts like following by g_strdup_printf().

    new = g_malloc(sizeof("http://") + len);
    strcpy(new, "http://");
    memcpy(&new[sizeof("http://") - 1], filename, len + 1);

Example cames from togge_proxy function where the new pointer isn't free()d.

Daniel

Hi,

On 15:00 Fri 16 Sep     , Daniel Carl wrote:
> Hi!
> 
> The patch introducs memory leaks because only the script function that is used
> for the javascript and echo command frees the given arg->s, other function do
> not free the argument. We should decide where to free the memory.

I'm (like Hannes) in favor of a free-by-caller convention for the
Arg-functions. Thomas tried to implement free-by-callee in those
patches.

It would be nice if we could finally get consistent behaviour regarding
mallocing and freeing. This means, that script() shouldn't free
anything and we should instead track down all the places where it's used
and call free() there. This should also remove the need for a SAVEFREE
macro.

Regards,
HP

Hi!
On Fri, Sep 16, 2011 at 03:59:03PM +0200, Hannes Schüller wrote:
> The reason, and feel free to correct me, was roughly "we cannot be
> bothered to track down all calling instances and free the memory there,
> so let's just do it in this central function". Which lead to all kinds
> of nasty race conditions in several less used functions.
> 
> In your original patch, what I'd suggest to to allocate the memory,
> call the function and then free the memory again afterwards. Nice and
> readable. If we want to be sure, a "safefree" macro as suggested
> certainly will not hurt.

If I understood right, follwing patch should do that. It's a replacement for
previous patch. We need to remove the const Arg from sript function to write
the pointer ti NULL after freeing it.

Daniel

Daniel Carl <dan...@gm...> wrote:
> On Fri, Sep 16, 2011 at 03:25:22PM +0200, Hannes Sch__ller wrote:
> > Please, no asymmetric freeing anymore! This lead to a lot of
> > seemingly unrelated issues in the past.
> 
> What's ment by assymetric feeing, freeing memory where it isn't
> mallo()d? The script function frees memory that it hasn't malloc()d.
> Then the script function should not free arg->s, but it does. What
> was the reason to free arg->s in the script function?

The reason, and feel free to correct me, was roughly "we cannot be
bothered to track down all calling instances and free the memory there,
so let's just do it in this central function". Which lead to all kinds
of nasty race conditions in several less used functions.

In your original patch, what I'd suggest to to allocate the memory,
call the function and then free the memory again afterwards. Nice and
readable. If we want to be sure, a "safefree" macro as suggested
certainly will not hurt.

Hannes

Hi Hannes!
On Fri, Sep 16, 2011 at 03:25:22PM +0200, Hannes Schüller wrote:
> Please, no asymmetric freeing anymore! This lead to a lot of
> seemingly unrelated issues in the past.

What's ment by assymetric feeing, freeing memory where it isn't mallo()d? The
script function frees memory that it hasn't malloc()d. Then the script
function should not free arg->s, but it does. What was the reason to free
arg->s in the script function?

Daniel

Hi!

Daniel Carl <dan...@gm...> wrote:
> I know that the descussion about freeing was done in the paste
> (http://www.vimprobable.org/mailman/archives/vimprobable-users/2011-January/000590.html),
> but I can't find a solution for the problem there. I would prefer the
> way Thoma Adam showed in mail
> (http://www.vimprobable.org/mailman/archives/vimprobable-users/2011-January/000602.html).

Please, no asymmetric freeing anymore! This lead to a lot of
seemingly unrelated issues in the past.

Hannes

Hi!

The patch introducs memory leaks because only the script function that is used
for the javascript and echo command frees the given arg->s, other function do
not free the argument. We should decide where to free the memory.

I know that the descussion about freeing was done in the paste
(http://www.vimprobable.org/mailman/archives/vimprobable-users/2011-January/000590.html),
but I can't find a solution for the problem there. I would prefer the way
Thoma Adam showed in mail
(http://www.vimprobable.org/mailman/archives/vimprobable-users/2011-January/000602.html).

Daniel

Hi!

Ryan Mullen <rm...@de...> wrote:
> Using the most recent hg build, if I sign into the gmail web
> interface, my browser-based gchat client is able to connect if and
> only if I have a previously untouched cookies file.

So, when you're talking about wiping the cookie file, do you mean it
has to be completely blank or just free of Google cookies?

Hannes

Hi,

Using the most recent hg build, if I sign into the gmail web
interface, my browser-based gchat client is able to connect if and
only if I have a previously untouched cookies file.

Basically, wipe the cookies file, open vimprobable2, connect to
gmail.com, wait to see if gchat connects. It should.

If I open the browser after having previously browsed and logged into
gchat, I'll have some gmail cookies stored, and my gchat will NOT
connect. It will keep retrying but never succeed.

I can then wipe my cookies file and restart the browser, and it will
work once more.

If I browse away from the gmail page after logging in from a blank
cookies file, I can return to gmail and gchat will connect. The
problem only begins after I close and reopen the browser.

Any ideas, or can anyone confirm this?

My useragent is a spoofed one that I took from my Iceweasel/Firefox
browser on another PC that works with gchat no problem.

Regards,
Ryan

Hi!

Following patch fixes the crash on :echo command. I don't know if I missed a
free, but it seems to work. Maybe someone else can inspect the issue too.

Daniel

I installed webkit gtk 1.4.0 and, voila!, www.creativecommons.org is
speedy as it should be! I very much appreciate everyone's help in
this!

Thanks,

-N

On 9/4/11, Daniel Carl <dan...@gm...> wrote:
> Hi!
> On Sun, Sep 04, 2011 at 03:48:07PM +0200, Hans-Peter Deifel wrote:
>> I just tried http://creativecommons.org/ with two different WebKit
>> versions. The result:
>>
>> 	webkit-gtk-1.2.7 is slow
>> 	webkit-gtk-1.4.2 is fast
>
> I have version 1.3.13 in use and it's also already fast. The issue was fixed
> in webkit 1.3.6 (https://bugs.webkit.org/show_bug.cgi?id=22102).
>
> Mabe you can use a user css script (.config/vimprobable/style.css) to
> overrule
> the -webkit-box-shadow and -webkit-border-radius properties for a better
> scroll performance. This should work for the first.
>
> Daniel
>

Hi!
On Sun, Sep 04, 2011 at 03:48:07PM +0200, Hans-Peter Deifel wrote:
> I just tried http://creativecommons.org/ with two different WebKit
> versions. The result:
> 
> 	webkit-gtk-1.2.7 is slow
> 	webkit-gtk-1.4.2 is fast

I have version 1.3.13 in use and it's also already fast. The issue was fixed
in webkit 1.3.6 (https://bugs.webkit.org/show_bug.cgi?id=22102). 

Mabe you can use a user css script (.config/vimprobable/style.css) to overrule
the -webkit-box-shadow and -webkit-border-radius properties for a better
scroll performance. This should work for the first.

Daniel

Hi,

On 12:12 Sat 03 Sep     , niemand nobody wrote:
> Is there anything I can do to help resolve this problem? I love using
> Vimprobable, but it's a total bummer when I come across the occasional
> super-laggy website.

I had also experienced this lag on some sites with heavy CSS magic, but
the problems have been gone for a while now, so I suspected a WebKit
update.

I just tried http://creativecommons.org/ with two different WebKit
versions. The result:

	webkit-gtk-1.2.7 is slow
	webkit-gtk-1.4.2 is fast

Regards,
HP

> niemand nobody <nie...@gm...> wrote:
>> Is there any particular reason why the link hinting uses numbers
>> instead of letters?
>
> Yes, there is a very particular (good) reason. That being that there
> are many people (me included) who don't just enter a hint's number, but
> type part of the link text to activate it. A feature which these less
> advanced hinting functions of other browsers don't seem to allow at all
> (making them unusable).
>
> Hannes
>
>

I've played around with link hinting by typing part of the link text,
and I must admit that I like it a lot! My only regret is that I didn't
read through the man page before I'd made my post...

Thanks!

-N

Is there anything I can do to help resolve this problem? I love using
Vimprobable, but it's a total bummer when I come across the occasional
super-laggy website.

Thanks,

-N

On Sat, Sep 3, 2011 at 10:45 AM, Daniel Carl <dan...@gm...> wrote:

> Hi!
> On Sat, Sep 03, 2011 at 10:25:01AM -0700, niemand nobody wrote:
> > I doubt that it is a Vimprobable problem, though, as I can replicate
> > it on the other minimalist webkit browsers Surf and UZBL, but not
> > Chromium nor also Firefox.
>
> I can't feel a significant slower scrolling with vimprobable compared to
> firefox, and if there's a difference I would say vimprobable scrolls a
> little
> faster and smoother than firefix does.
>
> Is there anybody else with this problem? Maybe we can find a solution to
> make
> such pages as fast as with other browsers - or faster.
>
> Daniel
>
>
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> Vimprobable-users mailing list
> Vim...@li...
> https://lists.sourceforge.net/lists/listinfo/vimprobable-users
>
>

Hi!
On Sat, Sep 03, 2011 at 10:25:01AM -0700, niemand nobody wrote:
> I doubt that it is a Vimprobable problem, though, as I can replicate
> it on the other minimalist webkit browsers Surf and UZBL, but not
> Chromium nor also Firefox.

I can't feel a significant slower scrolling with vimprobable compared to
firefox, and if there's a difference I would say vimprobable scrolls a little
faster and smoother than firefix does.

Is there anybody else with this problem? Maybe we can find a solution to make
such pages as fast as with other browsers - or faster.

Daniel

> I have no chromium here, but surfing on named pages seem's to be as fast as
> on other pages. What takes the time, loading th html or to view it in the
> browser?
> Daniel
>

The lag occurs after the page loads. For example, when I go to
www.creativecommons.org, the page will load just fine, but then
scrolling up and down will take AGES. Same with trying to do anything
else on it. I know that the problem is not creativecommons.org,
either, as I've seen it elsewhere.

I doubt that it is a Vimprobable problem, though, as I can replicate
it on the other minimalist webkit browsers Surf and UZBL, but not
Chromium nor also Firefox.

-N

Hi!

niemand nobody <nie...@gm...> wrote:
> Certain websites lag A LOT on Vimprobable. One example is
> creativecommons.org. I've tested this with UZBL, Surf, and Chromium:
> the first two share this problem, but the last does not.

I, too, have experienced this on some sites. I fear, though, that it is
related to screen drawing, i.e. a problem somewhere between Webkit, GTK
and Cairo. I could not find any components controlled by Vimprobable
itself lagging.

Hannes

Hi!
On Fri, Sep 02, 2011 at 08:22:42PM -0700, niemand nobody wrote:
> If there isn't, I just might be able to figure out the hinting code enough
> to patch it myself!

It could be hard to patch. I spent last weeks to revamp the hinting so that
the javascript should be more readable an easier to patch. But if you want to
change hintmarkers from numbers to chars, you have to adapt several methods in
the c layer to, because the c layer differ between chars that are given to the
createHints() function in the JavaScript or numbers that are delgatet to the
updateHints() function.
But I confirm with Hannes that chars aren't the right way to do hinting. For
me it would be confusing to read a link text 'Foo', aktive the hints and have
to write 'sa' to open it.

Daniel

2011	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug (77)	Sep (44)	Oct (43)	Nov (38)	Dec (14)
2012	Jan (40)	Feb (18)	Mar (12)	Apr (25)	May (12)	Jun (13)	Jul (17)	Aug (3)	Sep (20)	Oct (42)	Nov (9)	Dec (2)
2013	Jan (9)	Feb (29)	Mar (9)	Apr (7)	May (38)	Jun	Jul (7)	Aug	Sep (5)	Oct (10)	Nov (11)	Dec (1)
2014	Jan (16)	Feb (18)	Mar (11)	Apr (5)	May (13)	Jun (5)	Jul (5)	Aug (7)	Sep (30)	Oct	Nov	Dec (26)
2015	Jan (5)	Feb (19)	Mar (8)	Apr (15)	May (4)	Jun	Jul	Aug	Sep	Oct	Nov (16)	Dec (10)
2016	Jan	Feb (1)	Mar (14)	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

vimprobable-users Mailing List for Vimprobable (Page 28)

Vimprobable is a lean web browser optimised for full keyboard control

vimprobable-users — Mailing list for Vimprobable users