From thomas at xteddy.org Sat Dec 4 01:23:28 2010 From: thomas at xteddy.org (Thomas Adam) Date: Sat, 4 Dec 2010 01:23:28 +0000 Subject: [Vimprobable-users] [PATCH 0/1] Use "changed" signal to update cookies. Message-ID: <20101204012324.GA10560@shuttle.home> Hi all, This is a minor update to how we handle cookies. The huge comment that's been removed when saving cookies is a pretty good indicator, hopefully, of why this change is necessary. Go back to using the "changed" signal (early attempts of mine to use this failed, but I've got it right now, I hope) on the on-disk cookie jar, to update the session store of each Vimprobable instance. This reduces the need to lock the cookie jar on disk whenever it's being read or written to, and perhaps more importantly won't continually have to load in all the cookies on disk when the jar changes. So if you were experiencing slowness problems before in Vimprobable, I am hoping this will speed them up. Please give this the usual amount of testing, etc., and feedback welcome as always. Thomas Adam (1): Use "changed" signal to update cookie jars. main.c | 68 +++++++++------------------------------------------------------ 1 files changed, 10 insertions(+), 58 deletions(-) -- 1.7.2.3 From thomas at xteddy.org Sat Dec 4 01:24:33 2010 From: thomas at xteddy.org (Thomas Adam) Date: Sat, 4 Dec 2010 01:24:33 +0000 Subject: [Vimprobable-users] [PATCH 1/1] Use "changed" signal to update cookie jars. Message-ID: <20101204012430.GA10686@shuttle.home> Go back to using libsoup's "changed" signal handling on the file-store for the on disk cookie-jar, and update our session-store as it's updated. Request headers from URLs which contain cookies go straight into the file cookie jar on disk. This should help reduce the overhead of needing to read/write to the entire file cookie store on disk each time. --- main.c | 68 +++++++++------------------------------------------------------ 1 files changed, 10 insertions(+), 58 deletions(-) diff --git a/main.c b/main.c index 9e8145e..5dba254 100644 --- a/main.c +++ b/main.c @@ -150,11 +150,9 @@ static char *cookie_store; static void setup_cookies(void); static const char *get_cookies(SoupURI *soup_uri); static void load_all_cookies(void); -static void save_all_cookies(void); static void new_generic_request(SoupSession *soup_ses, SoupMessage *soup_msg, gpointer unused); -static void update_cookie_jar(SoupCookie *new); +static void update_cookie_jar(SoupCookieJar *jar, SoupCookie *old, SoupCookie *new); static void handle_cookie_request(SoupMessage *soup_msg, gpointer unused); -static int lock; #endif /* callbacks */ void @@ -2150,18 +2148,13 @@ setup_cookies() g_object_unref(session_cookie_jar); session_cookie_jar = soup_cookie_jar_new(); - cookie_store = g_strdup_printf(COOKIES_STORAGE_FILENAME); - lock = open(cookie_store, 0); - flock(lock, LOCK_EX); + cookie_store = g_strdup_printf(COOKIES_STORAGE_FILENAME); load_all_cookies(); - flock(lock, LOCK_UN); - close(lock); - - soup_session_add_feature(session, SOUP_SESSION_FEATURE(session_cookie_jar)); - soup_session_add_feature(session, SOUP_SESSION_FEATURE(file_cookie_jar)); + g_signal_connect((GObject *)file_cookie_jar, "changed", + G_CALLBACK(update_cookie_jar), NULL); return; } @@ -2191,7 +2184,7 @@ const char * get_cookies(SoupURI *soup_uri) { const char *cookie_str; - cookie_str = soup_cookie_jar_get_cookies(session_cookie_jar, soup_uri, TRUE); + cookie_str = soup_cookie_jar_get_cookies(file_cookie_jar, soup_uri, TRUE); return cookie_str; } @@ -2213,70 +2206,29 @@ handle_cookie_request(SoupMessage *soup_msg, gpointer unused) soup_date = soup_date_new_from_time_t(time(NULL) + cookie_timeout * 10); soup_cookie_set_expires(cookie, soup_date); } - soup_cookie_jar_add_cookie(session_cookie_jar, cookie); - update_cookie_jar(cookie); + soup_cookie_jar_add_cookie(file_cookie_jar, cookie); } return; } void -update_cookie_jar(SoupCookie *new) +update_cookie_jar(SoupCookieJar *jar, SoupCookie *old, SoupCookie *new) { if (!new) { /* Nothing to do. */ return; } - /* TA: Note that this locking is merely advisory -- because there's - * no linking between different vimprobable processes, the cookie jar, - * when being written to here, *WILL* be truncated and overwritten - * with cookie contents from the specific session saving its cookies - * at that time. - * - * This may or may not contain cookies stored in other Vimprobable - * instances, although when those instances save their cookies, - * they'll just replace the cookie store's contents. - * - * The locking should probably be changed to be fcntl() based one day - * -- but the caveat with that is all Vimprobable instances would then - * block waiting for the cookie file to become availabe. The - * advisory locking used here so far seems to work OK, but if we run - * into problems in the future, we'll know where to look. - * - * Ideally, if Vimprobable were ever to want to do this cleanly, - * something like using libunique to pass messages between registered - * sessions. - */ - lock = open(cookie_store, 0); - flock(lock, LOCK_EX); + SoupCookie *copy; + copy = soup_cookie_copy(new); - save_all_cookies(); - load_all_cookies(); - - flock(lock, LOCK_UN); - close(lock); + soup_cookie_jar_add_cookie(session_cookie_jar, copy); return; } void -save_all_cookies() -{ - GSList *session_cookie_list = soup_cookie_jar_all_cookies(session_cookie_jar); - - for (; session_cookie_list; - session_cookie_list = session_cookie_list->next) - { - soup_cookie_jar_add_cookie(file_cookie_jar, session_cookie_list->data); - } - - soup_cookies_free(session_cookie_list); - - return; -} - -void load_all_cookies() { file_cookie_jar = soup_cookie_jar_text_new(cookie_store, COOKIES_STORAGE_READONLY); -- 1.7.2.3 From thomas at xteddy.org Sat Dec 4 14:02:16 2010 From: thomas at xteddy.org (Thomas Adam) Date: Sat, 4 Dec 2010 14:02:16 +0000 Subject: [Vimprobable-users] [PATCH 0/3] Minor tweaks to fixed-size variables. Message-ID: <20101204140207.GA7775@shuttle.home> These are some minor tweaks to fixed-sized strings. It's not perfect, ideally we should be bounds-checking this, or allocating the values of "useragent" and "homepage" (which can be set in a config) on the heap and using malloc(). But for now, assuming "1024" should be OK. There's a few patches in here which introduce a VERSION and INTERNAL_VERSION constants for easier updating of the VERSION, and also to correctly report on the *actual* useragent of Vimprobable via "-v", where the useragent string might have changed. I was bitten by the hard-coded lengths of useragent, BTW, by seeing odd changes to the colour of the statusline -- static memory corruption FTW. :) Thomas Adam (3): Increase length of static strings (useragent/homepage) Put VERSION in its own define. Use INTERNAL_VERSION to describe Vimprobable config.h | 8 ++++++-- main.c | 2 +- 2 files changed, 7 insertions(+), 3 deletions(-) -- 1.7.2.3 From thomas at xteddy.org Sat Dec 4 14:02:57 2010 From: thomas at xteddy.org (Thomas Adam) Date: Sat, 4 Dec 2010 14:02:57 +0000 Subject: [Vimprobable-users] [PATCH 1/3] Increase length of static strings (useragent/homepage) Message-ID: <20101204140254.GA7803@shuttle.home> Since these can be set in a config, give them a fairly long length. --- config.h | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/config.h b/config.h index e4dc277..8773a02 100644 --- a/config.h +++ b/config.h @@ -8,8 +8,8 @@ */ /* general settings */ -char startpage[241] = "http://www.vimprobable.org/"; -char useragent[120] = "Vimprobable2/0.9.7.0"; +char startpage[1024] = "http://www.vimprobable.org/"; +char useragent[1024] = "Vimprobable2/0.9.7.0"; static const gboolean enablePlugins = TRUE; /* TRUE keeps plugins enabled */ static const gboolean enableJava = TRUE; /* FALSE disables Java applets */ -- 1.7.2.3 From thomas at xteddy.org Sat Dec 4 14:03:43 2010 From: thomas at xteddy.org (Thomas Adam) Date: Sat, 4 Dec 2010 14:03:43 +0000 Subject: [Vimprobable-users] [PATCH 2/3] Put VERSION in its own define. Message-ID: <20101204140340.GA7816@shuttle.home> Don't hard code the version of Vimprobable as part of the default useragent string. --- config.h | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/config.h b/config.h index 8773a02..5f8fd52 100644 --- a/config.h +++ b/config.h @@ -7,9 +7,12 @@ see LICENSE file */ +/* Vimprobable version number */ +#define VERSION "0.9.7.0" + /* general settings */ char startpage[1024] = "http://www.vimprobable.org/"; -char useragent[1024] = "Vimprobable2/0.9.7.0"; +char useragent[1024] = "Vimprobable2/" VERSION; static const gboolean enablePlugins = TRUE; /* TRUE keeps plugins enabled */ static const gboolean enableJava = TRUE; /* FALSE disables Java applets */ -- 1.7.2.3 From thomas at xteddy.org Sat Dec 4 14:04:21 2010 From: thomas at xteddy.org (Thomas Adam) Date: Sat, 4 Dec 2010 14:04:21 +0000 Subject: [Vimprobable-users] [PATCH 3/3] Use INTERNAL_VERSION to describe Vimprobable Message-ID: <20101204140419.GA7823@shuttle.home> When printing out Vimprobable's version via "-v" on the command-line, don't assume that the useragent value will be the default. Instead, always use INTERNAL_VERSION which is: "Vimprobable/VERSION". --- config.h | 1 + main.c | 2 +- 2 files changed, 2 insertions(+), 1 deletions(-) diff --git a/config.h b/config.h index 5f8fd52..afc97d2 100644 --- a/config.h +++ b/config.h @@ -9,6 +9,7 @@ /* Vimprobable version number */ #define VERSION "0.9.7.0" +#define INTERNAL_VERSION "Vimprobable/"VERSION /* general settings */ char startpage[1024] = "http://www.vimprobable.org/"; diff --git a/main.c b/main.c index 9e8145e..9734c03 100644 --- a/main.c +++ b/main.c @@ -2331,7 +2331,7 @@ main(int argc, char *argv[]) { } if (ver) { - printf("%s\n", useragent); + printf("%s\n", INTERNAL_VERSION); return EXIT_SUCCESS; } -- 1.7.2.3 From robin.kreis at uni-bremen.de Sat Dec 4 15:07:35 2010 From: robin.kreis at uni-bremen.de (Robin Kreis) Date: Sat, 4 Dec 2010 16:07:35 +0100 Subject: [Vimprobable-users] [PATCH 0/1] Use "changed" signal to update cookies. In-Reply-To: <20101204012324.GA10560@shuttle.home> References: <20101204012324.GA10560@shuttle.home> Message-ID: <20101204160735.ca0643d0.robin.kreis@uni-bremen.de> On Sat, 4 Dec 2010 01:23:28 +0000 Thomas Adam wrote: > Hi all, > > This is a minor update to how we handle cookies. The huge comment that's > been removed when saving cookies is a pretty good indicator, hopefully, of > why this change is necessary. > > Go back to using the "changed" signal (early attempts of mine to use this > failed, but I've got it right now, I hope) on the on-disk cookie jar, to > update the session store of each Vimprobable instance. > > This reduces the need to lock the cookie jar on disk whenever it's being > read or written to, and perhaps more importantly won't continually have to > load in all the cookies on disk when the jar changes. > > So if you were experiencing slowness problems before in Vimprobable, I am > hoping this will speed them up. > > Please give this the usual amount of testing, etc., and feedback welcome as > always. Nothing went wrong after half a day of testing, and some "black sheep" pages that used to block vimprobable2 for tens of seconds now load quickly. Thanks! Robin -- L??t der Knecht die Arbeit liegen, kann er leicht 'n Arsch vollkriegen. From jtimrod at yahoo.com Sat Dec 4 21:57:19 2010 From: jtimrod at yahoo.com (Jason Timrod) Date: Sat, 4 Dec 2010 13:57:19 -0800 (PST) Subject: [Vimprobable-users] Slow websites in Vimprobable Message-ID: <85321.35211.qm@web121007.mail.ne1.yahoo.com> Hi, Im using vimprobable2 - version 0.9.7.0. Ive just switched to it from another browser and note that sites like google or imdb, etc., take ages to load. Any idea why this might be? i'm sorry i cant give much more information, it seems random to me, where the same sites in different browsers are really fast. thanks! Jason From robin.kreis at uni-bremen.de Sun Dec 5 00:35:23 2010 From: robin.kreis at uni-bremen.de (Robin Kreis) Date: Sun, 5 Dec 2010 01:35:23 +0100 Subject: [Vimprobable-users] Slow websites in Vimprobable In-Reply-To: <85321.35211.qm@web121007.mail.ne1.yahoo.com> References: <85321.35211.qm@web121007.mail.ne1.yahoo.com> Message-ID: <20101205013523.34fab202.robin.kreis@uni-bremen.de> On Sat, 4 Dec 2010 13:57:19 -0800 (PST) Jason Timrod wrote: > Hi, > > Im using vimprobable2 - version 0.9.7.0. Ive just switched to it from another browser and note that sites like google or imdb, etc., take ages to load. > > Any idea why this might be? i'm sorry i cant give much more information, it seems random to me, where the same sites in different browsers are really fast. > > thanks! > > Jason Hi! Try disabling cookie support by editing the config.h. Also compare it to other browsers using the GTK Webkit bindings like midori or epiphany, just to make sure. If disabling cookie support works for you, try Thomas Adam's patch regarding cookie support - you can find it here on the ML or at: https://github.com/ThomasAdam/vimprobable/commit/e8bb64fec51d0eb0a62b800bd18d410d96d07aa1 Greetings, Robin -- Kommt der Gockel unter'n Trecker, gibt es morgens keinen Wecker. -- F?hrt der Bauer raus zum Jauchen, wird er nachts ein Deo brauchen. From jtimrod at yahoo.com Sun Dec 5 00:51:20 2010 From: jtimrod at yahoo.com (Jason Timrod) Date: Sat, 4 Dec 2010 16:51:20 -0800 (PST) Subject: [Vimprobable-users] Slow websites in Vimprobable In-Reply-To: <20101205013523.34fab202.robin.kreis@uni-bremen.de> Message-ID: <982936.13517.qm@web121008.mail.ne1.yahoo.com> --- On Sun, 12/5/10, Robin Kreis wrote: > epiphany, just to make sure.? If disabling cookie > support works for > you, try Thomas Adam's patch regarding cookie support - you > can find > it here on the ML or at: > https://github.com/ThomasAdam/vimprobable/commit/e8bb64fec51d0eb0a62b800bd18d410d96d07aa1 I know nothing of git - even with this patch, what do I do with it? I am not sure if it's any better disabling cookies or not but I will try this patch if I know what to do with it! Thanks! Jason From robin.kreis at uni-bremen.de Sun Dec 5 01:12:44 2010 From: robin.kreis at uni-bremen.de (Robin Kreis) Date: Sun, 5 Dec 2010 02:12:44 +0100 Subject: [Vimprobable-users] Slow websites in Vimprobable In-Reply-To: <982936.13517.qm@web121008.mail.ne1.yahoo.com> References: <20101205013523.34fab202.robin.kreis@uni-bremen.de> <982936.13517.qm@web121008.mail.ne1.yahoo.com> Message-ID: <20101205021244.abc9176e.robin.kreis@uni-bremen.de> On Sat, 4 Dec 2010 16:51:20 -0800 (PST) Jason Timrod wrote: > I know nothing of git - even with this patch, what do I do with it? I am not sure if it's any better disabling cookies or not but I will try this patch if I know what to do with it! > > Thanks! > > Jason Starting from nothing: git clone git://github.com/ThomasAdam/vimprobable.git cd vimprobable git checkout ta/cookie-handling2 make If disabling cookie support doesn't change anything, it has to be another issue. If it doesn't exist in, say, midori, I'm clueless. Good luck, Robin -- Wer nachts in einem Flu?bett pennt, am Morgen na? nach Hause rennt. From jtimrod at yahoo.com Sun Dec 5 01:38:12 2010 From: jtimrod at yahoo.com (Jason Timrod) Date: Sat, 4 Dec 2010 17:38:12 -0800 (PST) Subject: [Vimprobable-users] Slow websites in Vimprobable In-Reply-To: <20101205021244.abc9176e.robin.kreis@uni-bremen.de> Message-ID: <334313.93002.qm@web121005.mail.ne1.yahoo.com> --- On Sun, 12/5/10, Robin Kreis wrote: > If disabling cookie support doesn't change anything, it has > to be > another issue.? If it doesn't exist in, say, midori, > I'm clueless. Wow! i just tried this as you said and now Vimprobable is really really fast. Thank you very much Robin for your patch! You rock! Jason From robin.kreis at uni-bremen.de Sun Dec 5 09:37:41 2010 From: robin.kreis at uni-bremen.de (Robin Kreis) Date: Sun, 5 Dec 2010 10:37:41 +0100 Subject: [Vimprobable-users] Slow websites in Vimprobable In-Reply-To: <334313.93002.qm@web121005.mail.ne1.yahoo.com> References: <20101205021244.abc9176e.robin.kreis@uni-bremen.de> <334313.93002.qm@web121005.mail.ne1.yahoo.com> Message-ID: <20101205103741.185b894e.robin.kreis@uni-bremen.de> On Sat, 4 Dec 2010 17:38:12 -0800 (PST) Jason Timrod wrote: > Wow! i just tried this as you said and now Vimprobable is really really fast. Thank you very much Robin for your patch! You rock! > > Jason To be fair, it's not my patch - Thomas Adam wrote it. So he rocks! :) Robin -- Ist erst die letzte Klammer zu, hat der Lispler seine Ruh. From hannes at yllr.net Sun Dec 5 10:06:53 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sun, 5 Dec 2010 11:06:53 +0100 Subject: [Vimprobable-users] [PATCH 0/1] Use "changed" signal to update cookies. In-Reply-To: <20101204012324.GA10560@shuttle.home> References: <20101204012324.GA10560@shuttle.home> Message-ID: <20101205110653.78482b51@workstation> Hi! Thomas Adam wrote: > This is a minor update to how we handle cookies. The huge comment > that's been removed when saving cookies is a pretty good indicator, > hopefully, of why this change is necessary. > > So if you were experiencing slowness problems before in Vimprobable, > I am hoping this will speed them up. > > Please give this the usual amount of testing, etc., and feedback > welcome as always. I never experienced any such problems, so I'm not a good judge to confirm whether this solves the issue. I'm depending on you others to tell me whether it should be merged. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From jtimrod at yahoo.com Sun Dec 5 15:24:36 2010 From: jtimrod at yahoo.com (Jason Timrod) Date: Sun, 5 Dec 2010 07:24:36 -0800 (PST) Subject: [Vimprobable-users] [PATCH 0/1] Use "changed" signal to update cookies. In-Reply-To: <20101205110653.78482b51@workstation> Message-ID: <110556.54138.qm@web121002.mail.ne1.yahoo.com> Hi --- On Sun, 12/5/10, Hannes Sch?ller wrote: > I never experienced any such problems, so I'm not a good > judge to > confirm whether this solves the issue. I'm depending on you > others to > tell me whether it should be merged. it works ok for me and speeds up my browsing! i think it should be merged Jason From matto at matto.nl Sun Dec 5 15:56:56 2010 From: matto at matto.nl (matto fransen) Date: Sun, 5 Dec 2010 16:56:56 +0100 Subject: [Vimprobable-users] [PATCH 0/1] Use "changed" signal to update cookies. In-Reply-To: <20101204012324.GA10560@shuttle.home> References: <20101204012324.GA10560@shuttle.home> Message-ID: Hi, On 04/12/2010, Thomas Adam wrote: > Hi all, > > This is a minor update to how we handle cookies. The huge comment that's > been removed when saving cookies is a pretty good indicator, hopefully, of > why this change is necessary. > [ ... ] > Please give this the usual amount of testing, etc., and feedback welcome as > always. > Runs fine on my Acer Aspire One :) I did experience the problem that this patch should solve (no extremely slow browsing experiences) so I don't know wether it solved the problem or not :) Gmail works fine, I think I remember a message complaining about the speed on gmail's site. Cheers, Matto From jasonwryan at gmail.com Sun Dec 5 23:44:47 2010 From: jasonwryan at gmail.com (Jason Ryan) Date: Mon, 6 Dec 2010 12:44:47 +1300 Subject: [Vimprobable-users] [PATCH 0/1] Use "changed" signal to update cookies. In-Reply-To: <20101205110653.78482b51@workstation> References: <20101204012324.GA10560@shuttle.home> <20101205110653.78482b51@workstation> Message-ID: <20101205234447.GE3732@Longbow.dev.ssc.govt.nz> On 05/12/10 at 11:06am, Hannes Sch?ller wrote: > Hi! > > Thomas Adam wrote: > > This is a minor update to how we handle cookies. The huge comment > > that's been removed when saving cookies is a pretty good indicator, > > hopefully, of why this change is necessary. > > > > So if you were experiencing slowness problems before in Vimprobable, > > I am hoping this will speed them up. > > > > Please give this the usual amount of testing, etc., and feedback > > welcome as always. > > I never experienced any such problems, so I'm not a good judge to > confirm whether this solves the issue. I'm depending on you others to > tell me whether it should be merged. > > Hannes It solves the issue I was having with SSL sites. I'd like to see it merged. Thanks for all the work on this Thomas. /J -- Jason Ryan http://jasonwryan.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From thomas at xteddy.org Mon Dec 6 00:33:16 2010 From: thomas at xteddy.org (Thomas Adam) Date: Mon, 6 Dec 2010 00:33:16 +0000 Subject: [Vimprobable-users] [PATCH 0/1] Use "changed" signal to update cookies. In-Reply-To: <20101205234447.GE3732@Longbow.dev.ssc.govt.nz> References: <20101204012324.GA10560@shuttle.home> <20101205110653.78482b51@workstation> <20101205234447.GE3732@Longbow.dev.ssc.govt.nz> Message-ID: <20101206003313.GA25590@shuttle.home> On Mon, Dec 06, 2010 at 12:44:47PM +1300, Jason Ryan wrote: > On 05/12/10 at 11:06am, Hannes Sch?ller wrote: > > Hi! > > > > Thomas Adam wrote: > > > This is a minor update to how we handle cookies. The huge comment > > > that's been removed when saving cookies is a pretty good indicator, > > > hopefully, of why this change is necessary. > > > > > > So if you were experiencing slowness problems before in Vimprobable, > > > I am hoping this will speed them up. > > > > > > Please give this the usual amount of testing, etc., and feedback > > > welcome as always. > > > > I never experienced any such problems, so I'm not a good judge to > > confirm whether this solves the issue. I'm depending on you others to > > tell me whether it should be merged. > > > > Hannes > > It solves the issue I was having with SSL sites. I'd like to see it merged. Note that if your cookie-jar has a fair number of cookies stored on-disk as mine does (currently >300 cookies), then you may well notice a second or two delay going to some websites if you were to do: % vimprobable foo.com Or indeed, ask Vimprobable to load up a homepage -- either way, it amounts to the same thing. For SSL sites though, this delay is likely compounded by the negotiation of the connection *plus* cookie loading (if it's the first site you're visiting, of course.) This is because when *that* Vimprobable instance loads, it has to load all of the cookies from the file cookie-jar into its session store. There's not a lot I can do about this. Or maybe there is. Ideally, I would love to use libunique to solve this properly -- but this wouldn't work too well with the current Vimprobable philosophy of having separate instances being independent of one another. So if we can't do that, there's only one other options -- to have a Vimprobable cookie daemon. This is quite a big step to be honest -- and it's not something I'd be too bothered to implement, but this does flag up a problem in the current design philosophy -- where, I've now had to sacrifice/hack in improvements to effectively share cookies between disparate instances, whilst potentially always making it slower. The good thing about a cookie daemon is that it's only really a pointer that associates the on-disk store with something in its session -- that would therefore only ever require one read of the cookie store on disk per instance of Vimprobable loading. Still, not that it's likely ever going to matter, but it's still interesting to ponder, and for me to outline flaws in my own implementation so that if others want to patch this (hint, hint), they're not left clueless. :) > Thanks for all the work on this Thomas. You're welcome. -- Thomas Adam -- "Deep in my heart I wish I was wrong. But deep in my heart I know I am not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.) From mtreibton at googlemail.com Mon Dec 6 01:05:06 2010 From: mtreibton at googlemail.com (Michael Treibton) Date: Mon, 6 Dec 2010 01:05:06 +0000 Subject: [Vimprobable-users] [PATCH 2/3] Put VERSION in its own define. In-Reply-To: <20101204140340.GA7816@shuttle.home> References: <20101204140340.GA7816@shuttle.home> Message-ID: hi - this patch sucks! whats the point of it? youre a useless programmer. rot in hell. Michael On 4 December 2010 14:03, Thomas Adam wrote: > Don't hard code the version of Vimprobable as part of the default useragent > string. > --- > ?config.h | ? ?5 ++++- > ?1 files changed, 4 insertions(+), 1 deletions(-) > > diff --git a/config.h b/config.h > index 8773a02..5f8fd52 100644 > --- a/config.h > +++ b/config.h > @@ -7,9 +7,12 @@ > ? ? see LICENSE file > ?*/ > > +/* Vimprobable version number */ > +#define VERSION "0.9.7.0" > + > ?/* general settings */ > ?char startpage[1024] ? ? ? ? ? ? ? ? ? ?= "http://www.vimprobable.org/"; > -char useragent[1024] ? ? ? ? ? ? ? ? ? ?= "Vimprobable2/0.9.7.0"; > +char useragent[1024] ? ? ? ? ? ? ? ? ? ?= "Vimprobable2/" VERSION; > ?static const gboolean enablePlugins ? ? = TRUE; /* TRUE keeps plugins enabled */ > ?static const gboolean enableJava ? ? ? ?= TRUE; /* FALSE disables Java applets */ > > -- > 1.7.2.3 > _______________________________________________ > Vimprobable-users mailing list > Vimprobable-users at vimprobable.org > http://vimprobable.org/mailman/listinfo/vimprobable-users > From tyler at monkeypox.org Mon Dec 6 01:24:12 2010 From: tyler at monkeypox.org (R. Tyler Croy) Date: Sun, 5 Dec 2010 17:24:12 -0800 Subject: [Vimprobable-users] [PATCH 2/3] Put VERSION in its own define. In-Reply-To: References: <20101204140340.GA7816@shuttle.home> Message-ID: <20101206012412.GA24426@kiwi.local> On Mon, 06 Dec 2010, Michael Treibton wrote: > hi - > > this patch sucks! whats the point of it? youre a useless programmer. > > rot in hell. > > Michael Well that seems like a bit of an overreaction. - R. Tyler Croy -------------------------------------- GitHub: http://github.com/rtyler Twitter: http://twitter.com/agentdero -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From robin.kreis at uni-bremen.de Mon Dec 6 10:07:07 2010 From: robin.kreis at uni-bremen.de (Robin Kreis) Date: Mon, 6 Dec 2010 11:07:07 +0100 Subject: [Vimprobable-users] [PATCH 0/1] Use "changed" signal to update cookies. In-Reply-To: <20101206003313.GA25590@shuttle.home> References: <20101204012324.GA10560@shuttle.home> <20101205110653.78482b51@workstation> <20101205234447.GE3732@Longbow.dev.ssc.govt.nz> <20101206003313.GA25590@shuttle.home> Message-ID: <20101206110707.89b0dbdc.robin.kreis@uni-bremen.de> On Mon, 6 Dec 2010 00:33:16 +0000 Thomas Adam wrote: > Note that if your cookie-jar has a fair number of cookies stored on-disk as > mine does (currently >300 cookies), then you may well notice a second or two > delay going to some websites if you were to do: > > % vimprobable foo.com > > Or indeed, ask Vimprobable to load up a homepage -- either way, it amounts > to the same thing. > > For SSL sites though, this delay is likely compounded by the negotiation of > the connection *plus* cookie loading (if it's the first site you're > visiting, of course.) > > This is because when *that* Vimprobable instance loads, it has to load all of > the cookies from the file cookie-jar into its session store. > > There's not a lot I can do about this. > > Or maybe there is. > > Ideally, I would love to use libunique to solve this properly -- but this > wouldn't work too well with the current Vimprobable philosophy of having > separate instances being independent of one another. So if we can't do > that, there's only one other options -- to have a Vimprobable cookie daemon. > > This is quite a big step to be honest -- and it's not something I'd be too > bothered to implement, but this does flag up a problem in the current design > philosophy -- where, I've now had to sacrifice/hack in improvements to > effectively share cookies between disparate instances, whilst potentially > always making it slower. > > The good thing about a cookie daemon is that it's only really a pointer that > associates the on-disk store with something in its session -- that would > therefore only ever require one read of the cookie store on disk per > instance of Vimprobable loading. > > Still, not that it's likely ever going to matter, but it's still interesting > to ponder, and for me to outline flaws in my own implementation so that if > others want to patch this (hint, hint), they're not left clueless. :) If there's agreement on it, I could implement a cookie daemon - that would take a few months, basically because I'm a lazy person. While it's a big step, if it's a big step in the right direction and fixes more issues than it raises, it should happen someday. Are other options like using shared memory in some way or some kind of database (sqlite) viable? Greetings, Robin -- F?hrt man r?ckw?rts an den Baum, verkleinert sich der Kofferraum. From thomas at xteddy.org Mon Dec 6 10:09:58 2010 From: thomas at xteddy.org (Thomas Adam) Date: Mon, 6 Dec 2010 10:09:58 +0000 Subject: [Vimprobable-users] [PATCH 0/1] Use "changed" signal to update cookies. In-Reply-To: <20101206110707.89b0dbdc.robin.kreis@uni-bremen.de> References: <20101204012324.GA10560@shuttle.home> <20101205110653.78482b51@workstation> <20101205234447.GE3732@Longbow.dev.ssc.govt.nz> <20101206003313.GA25590@shuttle.home> <20101206110707.89b0dbdc.robin.kreis@uni-bremen.de> Message-ID: <20101206100955.GA2889@abacus.soton.smoothwall.net> On Mon, Dec 06, 2010 at 11:07:07AM +0100, Robin Kreis wrote: > If there's agreement on it, I could implement a cookie daemon - that > would take a few months, basically because I'm a lazy person. While > it's a big step, if it's a big step in the right direction and fixes > more issues than it raises, it should happen someday. Dont' -- it's not worth it. The implementation we have now is fine. The thing to take away from this though, isn't that we need a cookie daemon, it's to note that sharing information between processes which have no IPC can be annoying. > Are other options like using shared memory in some way or some kind of > database (sqlite) viable? Not in this context, no. -- Thomas Adam From hannes at yllr.net Mon Dec 6 17:09:15 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Mon, 6 Dec 2010 18:09:15 +0100 Subject: [Vimprobable-users] [PATCH 2/3] Put VERSION in its own define. In-Reply-To: References: <20101204140340.GA7816@shuttle.home> Message-ID: <20101206180915.13df9e4f@laptop2.lan.localhost> Michael Treibton wrote: > hi - > > this patch sucks! whats the point of it? youre a useless programmer. > > rot in hell. > > Michael Did I miss anything? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From matto at matto.nl Mon Dec 6 19:47:42 2010 From: matto at matto.nl (Matto Fransen) Date: Mon, 6 Dec 2010 20:47:42 +0100 Subject: [Vimprobable-users] [PATCH 2/3] Put VERSION in its own define. In-Reply-To: References: <20101204140340.GA7816@shuttle.home> Message-ID: <20101206194740.GA1866@aspire.tradesystem.nl> Hello, On Mon, Dec 06, 2010 at 01:05:06AM +0000, Michael Treibton wrote: > hi - > > this patch sucks! whats the point of it? youre a useless programmer. > > rot in hell. > There is no need for this. We are a group of people that try to create something useful and have some fun in the proces. If you have reasons to question the code and can pinpoint problems there is always opportunity to do so. But not like this. This makes us all feel ashamed. Sincerely, Matto -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From hannes at yllr.net Sat Dec 11 18:32:39 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sat, 11 Dec 2010 19:32:39 +0100 Subject: [Vimprobable-users] [PATCH v3 1/1] Ignore event->state bits not set in GdkEventMask In-Reply-To: <1289763798-16555-1-git-send-email-robin.kreis@uni-bremen.de> References: <1289763798-16555-1-git-send-email-robin.kreis@uni-bremen.de> Message-ID: <20101211193239.731c6a71@workstation> Merged -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From hannes at yllr.net Sat Dec 11 18:34:24 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sat, 11 Dec 2010 19:34:24 +0100 Subject: [Vimprobable-users] [PATCH 1/1] Fixup function declarations. In-Reply-To: <20101120022842.GA13683@shuttle.home> References: <20101120022842.GA13683@shuttle.home> Message-ID: <20101211193424.67f73a4b@workstation> Merged -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From hannes at yllr.net Sat Dec 11 18:42:32 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sat, 11 Dec 2010 19:42:32 +0100 Subject: [Vimprobable-users] [PATCH 0/1] Use "changed" signal to update cookies. In-Reply-To: <20101204012324.GA10560@shuttle.home> References: <20101204012324.GA10560@shuttle.home> Message-ID: <20101211194232.4cd7357b@workstation> Merged -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From hannes at yllr.net Sat Dec 11 18:54:06 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sat, 11 Dec 2010 19:54:06 +0100 Subject: [Vimprobable-users] [PATCH 0/3] Minor tweaks to fixed-size variables. In-Reply-To: <20101204140207.GA7775@shuttle.home> References: <20101204140207.GA7775@shuttle.home> Message-ID: <20101211195406.3716bbe6@workstation> All merged -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From hannes at yllr.net Sat Dec 11 19:03:58 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sat, 11 Dec 2010 20:03:58 +0100 Subject: [Vimprobable-users] Vimprobable 0.9.20.5 & Vimprobable2 0.9.7.1 released! Message-ID: <20101211200358.05532c93@workstation> This is a bugfix release: - Workaround for some strange interactions with ibus using undefined bits which caused keybindings to stop working (patch by Robin Kreis). - Bigger safety margin for some string (e.g. the useragent) to avoid memory corruption (patch by Thomas Adam). - -v command line switch now always shows the actual Vimprobable version number instead of the user agent which might have been customised by the user (patch by Thomas Adam). - More efficient handling of session-shared cookies, fixing the slowdowns noticed by some users (patch by Thomas Adam). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From thomas at xteddy.org Sat Dec 11 22:57:43 2010 From: thomas at xteddy.org (Thomas Adam) Date: Sat, 11 Dec 2010 22:57:43 +0000 Subject: [Vimprobable-users] [PATCH 0/2] Add V_DEBUG make target In-Reply-To: <20101120030922.GA15000@shuttle.home> References: <20101120030922.GA15000@shuttle.home> Message-ID: <20101211225742.GB4763@shuttle.home> On Sat, Nov 20, 2010 at 03:09:26AM +0000, Thomas Adam wrote: > Introduce V_DEBUG in the Makefile to enable not only sanity checking, but to > compile Vimprobable with debug symbols, useful when wanting to analyse > reproducable corefiles, patching, etc. > > Off by default, of course. > > Thomas Adam (2): > Add V_DEBUG target. > Update PATCHES to reflect V_DEBUG make target. > > Makefile | 9 +++++++++ > PATCHES | 12 ++++++++++++ > 2 files changed, 21 insertions(+), 0 deletions(-) Was there any comment on this? -- Thomas Adam -- "Deep in my heart I wish I was wrong. But deep in my heart I know I am not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.) From jtimrod at yahoo.com Sun Dec 19 00:04:54 2010 From: jtimrod at yahoo.com (Jason Timrod) Date: Sat, 18 Dec 2010 16:04:54 -0800 (PST) Subject: [Vimprobable-users] [PATCH 0/2] Add V_DEBUG make target In-Reply-To: <20101211225742.GB4763@shuttle.home> Message-ID: <688738.41608.qm@web121008.mail.ne1.yahoo.com> Hi, --- On Sat, 12/11/10, Thomas Adam wrote: > Was there any comment on this? How would someone use this? Jason From hannes at yllr.net Sun Dec 19 10:11:59 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sun, 19 Dec 2010 11:11:59 +0100 Subject: [Vimprobable-users] [PATCH 0/2] Add V_DEBUG make target In-Reply-To: <20101120030922.GA15000@shuttle.home> References: <20101120030922.GA15000@shuttle.home> Message-ID: <20101219111159.3acf6a72@workstation> Ah, yes, I forgot about this one... The problem with this is that last year, I've been asked by distribution's package maintainers not to 'hardcode' any flags in the Makefile. Now, we could argue that these could be ignored/disabled without any effort. I'm undecided. Waiting for comments/protest. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From thomas at xteddy.org Sun Dec 19 14:26:31 2010 From: thomas at xteddy.org (Thomas Adam) Date: Sun, 19 Dec 2010 14:26:31 +0000 Subject: [Vimprobable-users] [PATCH 0/2] Add V_DEBUG make target In-Reply-To: <20101219111159.3acf6a72@workstation> References: <20101120030922.GA15000@shuttle.home> <20101219111159.3acf6a72@workstation> Message-ID: <20101219142629.GA3143@shuttle.home> On Sun, Dec 19, 2010 at 11:11:59AM +0100, Hannes Sch?ller wrote: > Ah, yes, I forgot about this one... > > The problem with this is that last year, I've been asked by > distribution's package maintainers not to 'hardcode' any flags in the > Makefile. Now, we could argue that these could be ignored/disabled > without any effort. I'm undecided. Waiting for comments/protest. I think that concern is secondary, to be honest. I have no idea what problems maintainers would have with flags not used in Makefiles, but this sort of thing with debug flags is very common. Plus, it's not *meant* to be enabled by default, so I fail to see how package maintainers have anything to worry about. -- Thomas Adam -- "Deep in my heart I wish I was wrong. But deep in my heart I know I am not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.) From thomas at xteddy.org Mon Dec 20 20:37:52 2010 From: thomas at xteddy.org (Thomas Adam) Date: Mon, 20 Dec 2010 20:37:52 +0000 Subject: [Vimprobable-users] [PATCH 1/1] Support Webkit's enable-page-cache setting Message-ID: <20101220203747.GA19159@shuttle.home> See: http://webkit.org/blog/427/webkit-page-cache-i-the-basics/ Off by default, as this was always the case with Vimprobable. When turned on, seems to improve my own browsing experience a little. I am sure it's more than just a placebo. :) --- config.h | 2 ++ main.c | 1 + 2 files changed, 3 insertions(+), 0 deletions(-) diff --git a/config.h b/config.h index e0290d3..e4ea17e 100644 --- a/config.h +++ b/config.h @@ -16,6 +16,7 @@ char startpage[1024] = "http://www.vimprobable.org/"; char useragent[1024] = "Vimprobable2/" VERSION; static const gboolean enablePlugins = TRUE; /* TRUE keeps plugins enabled */ static const gboolean enableJava = TRUE; /* FALSE disables Java applets */ +static const gboolean enablePagecache = FALSE; /* TRUE turns on the page cache. */ /* appearance */ char statusbgcolor[] = "#000000"; /* background color for status bar */ @@ -148,6 +149,7 @@ static Setting browsersettings[] = { { "useragent", useragent, "user-agent", FALSE, FALSE, FALSE, FALSE }, { "scripts", NULL, "enable-scripts", FALSE, TRUE, FALSE, FALSE }, { "plugins", NULL, "enable-plugins", FALSE, TRUE, FALSE, FALSE }, + { "pagecache", NULL, "enable-page-cache", FALSE, TRUE, FALSE, FALSE }, { "java", NULL, "enable-java-applet", FALSE, TRUE, FALSE, FALSE }, { "images", NULL, "auto-load-images", FALSE, TRUE, FALSE, FALSE }, { "shrinkimages", NULL, "auto-shrink-images", FALSE, TRUE, FALSE, FALSE }, diff --git a/main.c b/main.c index 95ad0cd..13f03eb 100644 --- a/main.c +++ b/main.c @@ -2072,6 +2072,7 @@ setup_settings() { g_object_set((GObject*)settings, "enable-scripts", enablePlugins, NULL); g_object_set((GObject*)settings, "enable-plugins", enablePlugins, NULL); g_object_set((GObject*)settings, "enable-java-applet", enableJava, NULL); + g_object_set((GObject*)settings, "enable-page-cache", enablePagecache, NULL); filename = g_strdup_printf(USER_STYLESHEET); filename = g_strdup_printf("file://%s", filename); g_object_set((GObject*)settings, "user-stylesheet-uri", filename, NULL); -- 1.7.2.3