Hey,
I looked at gtksourceview and its patterns, the syntax
highlighting engine uses regular expressions with up
to 56 subpatterns (length of patterns was the reason
for egg_regex_ref()), which amounts to 670 bytes array
to store offsets. The match structure in this case is
some 40 bytes + those 6
[Mark, I apologize, I accidentally sent it to you in private]
[EMAIL PROTECTED] wrote:
> On Fri, Mar 16, 2007 at 09:15:37PM -0500, Yevgen Muntyan wrote:
>
>> I do understand that a separate match object is a good idea.
>> But "separate match object in C API is a good idea" is questionable.
>> W
On Fri, Mar 16, 2007 at 09:15:37PM -0500, Yevgen Muntyan wrote:
> I do understand that a separate match object is a good idea.
> But "separate match object in C API is a good idea" is questionable.
> While thread-safety is important, it doesn't sound feasible a single
> GRegex object will be used f
Matthias Clasen wrote:
> On 3/16/07, Marco Barisione <[EMAIL PROTECTED]> wrote:
>
>
>> BTW if you want I can split GRegex in two separate objects.
>>
>
> Since that seems to be the overwhelming preference,
"overwhelming"?
> that might
> be a good idea. I hope this shouldn't be too bad, sin
On 3/16/07, Marco Barisione <[EMAIL PROTECTED]> wrote:
> BTW if you want I can split GRegex in two separate objects.
Since that seems to be the overwhelming preference, that might
be a good idea. I hope this shouldn't be too bad, since GRegex
is already split into pattern and match objects, inter
GLib 2.13.0 is now available for download at:
ftp://ftp.gtk.org/pub/gtk/2.13/
http://ftp.gnome.org/pub/GNOME/sources/glib/2.13/
glib-2.13.0.tar.bz2 md5sum: 4c0ffd368819f2af0c5fa531714945b1
glib-2.13.0.tar.gz md5sum: 2b0894cc6a09a8698119e4889853f001
This is a development release le
Il giorno gio, 15/03/2007 alle 18.41 +0100, Hans Breuer ha scritto:
> with only small modifications I was able to compile GRegex with msvc,
> thanks for providing an almost working makefile.msc ;-)
> [...]
> But now for the question: are these 3 failed specific to my build so I
> should investigate
Il giorno gio, 15/03/2007 alle 10.18 -0400, Owen Taylor ha scritto:
> But looking over the header file, there is something that puzzles me
> about the way that it's set up: there is no distinction between a
> "pattern/regular expression" object and a match/matcher object.
The internal code in GReg
On Fri, Mar 16, 2007 at 08:20:11AM +0100, Mathieu Lacage wrote:
> On Thu, 2007-03-15 at 10:56 -0400, Owen Taylor wrote:
> > Well, I could imagine (maybe, barely) that someone could show me numbers
> > that showed that with a variety of long and complicated regular
> > expressions, compiling them wa
On Fri, Mar 16, 2007 at 02:18:23PM -0400, Owen Taylor wrote:
> On Fri, 2007-03-16 at 10:57 -0700, David Moffatt wrote:
> > char *
> > get_leading_digits(const char *str)
> > {
> > static GRegex *regex = NULL;
> > char *result = NULL;
> >
> > if (!regex)
> > regex = g_
You wrote (@ Friday, 16 de March de 2007 18:29):
> On Fri, 2007-03-16 at 18:29 +, Ricardo Cruz wrote:
> > Owen Taylor wrote (@ Thursday, 15 de March de 2007 15:55):
> > > On Sat, 2007-02-10 at 08:59 -0600, Federico Mena Quintero wrote:
> > > > El mar, 06-02-2007 a las 16:43 +, Ricardo Cruz
On Fri, 2007-03-16 at 18:29 +, Ricardo Cruz wrote:
> Owen Taylor wrote (@ Thursday, 15 de March de 2007 15:55):
> > On Sat, 2007-02-10 at 08:59 -0600, Federico Mena Quintero wrote:
> > > El mar, 06-02-2007 a las 16:43 +, Ricardo Cruz escribió:
> > > GdkDisplay keeps some interesting state (
Owen Taylor wrote (@ Thursday, 15 de March de 2007 15:55):
> On Sat, 2007-02-10 at 08:59 -0600, Federico Mena Quintero wrote:
> > El mar, 06-02-2007 a las 16:43 +, Ricardo Cruz escribió:
> > GdkDisplay keeps some interesting state (last-clicked-window, button
> > click times, etc.). If GTK+ do
On Fri, 2007-03-16 at 10:57 -0700, David Moffatt wrote:
> char *
> get_leading_digits(const char *str)
> {
> static GRegex *regex = NULL;
> char *result = NULL;
>
> if (!regex)
> regex = g_regex_new("^\\d+", 0, 0, NULL);
>
> if (g_regex_match(str, 0))
>
char *
get_leading_digits(const char *str)
{
static GRegex *regex = NULL;
char *result = NULL;
if (!regex)
regex = g_regex_new("^\\d+", 0, 0, NULL);
if (g_regex_match(str, 0))
result = g_regex_fetch(regex, 0);
return result;
}
That code bothers
On Fri, 2007-03-16 at 09:36 -0400, Morten Welinder wrote:
> Is there a guarantee that for GRegex (unlike, say, GDate) multiple
> threads can use
> the same object at the same time?
>
> I.e., two threads cannot call g_date_get_weekday on the same date, so why are
> we
> expect that two threads can
On Fri, March 16, 2007 08:28, Owen Taylor wrote:
> char *
> get_leading_digits(const char *str)
> {
> GStaticRegex regex = G_STATIC_REGEX_INIT("^\\d+", 0);
> GMatcher *matcher;
> char *result = NULL;
>
> matcher = g_matcher_new_static(®ex, str, 0);
> if (g_matcher_ma
On 3/16/07, Federico Mena Quintero <[EMAIL PROTECTED]> wrote:
> El jue, 15-03-2007 a las 14:20 +0530, मयंक जैन (makuchaku) escribió:
>
> > I would be happy to volunteer towards maintainence of GTK+.
>
> Wow, thanks!
>
> Here's a task for you to get started. It will take you several days,
> but hop
Hi,
The directory 'trunk/debian' in svn is nearly 10 years old and I
wonder who still uses it. Shouldn't it get removed?
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Is there a guarantee that for GRegex (unlike, say, GDate) multiple
threads can use
the same object at the same time?
I.e., two threads cannot call g_date_get_weekday on the same date, so why are we
expect that two threads can call g_regex_copy or anything like it?
Morten
_
Is there any real need for the "has-tooltip" property? From a quick look
at the API it doesn't seem that useful to me.
The developer either wants to set a simple tooltip with "tooltip-markup"
or connect to the "signal-query" signal to set context-sensitive
tooltips.
Have I missed something?
Dam
On Thu, 2007-03-15 at 14:16 -0500, Yevgen Muntyan wrote:
> [Owen, I apologize, I hit Reply instead of Reply All]
>
> Owen Taylor wrote:
> > So, the regular expression code has been committed to CVS finally. Yay!
> >
> > But looking over the header file, there is something that puzzles me
> > about
Hi Owen,
On Thu, 2007-03-15 at 11:55 -0400, Owen Taylor wrote:
..
> For your purposes, you'd probably be better off modifying your patch
> so that the call to _gdk_events_init() was skipped, but that returns
> you to having a GDK with a number of things that don't quite work (not
> counting the b
On Fri, 16 Mar 2007, Tshepang Lekhonkhobe wrote:
> On 3/16/07, Tim Janik <[EMAIL PROTECTED]> wrote:
>> On Fri, 16 Mar 2007, Tshepang Lekhonkhobe wrote:
>>
>>> On 3/15/07, Tim Janik <[EMAIL PROTECTED]> wrote:
On Thu, 15 Mar 2007, Tshepang Lekhonkhobe wrote:
>>
> It makes NEWS section in tr
On 3/16/07, Tim Janik <[EMAIL PROTECTED]> wrote:
> On Fri, 16 Mar 2007, Tshepang Lekhonkhobe wrote:
>
> > On 3/15/07, Tim Janik <[EMAIL PROTECTED]> wrote:
> >> On Thu, 15 Mar 2007, Tshepang Lekhonkhobe wrote:
>
> >> > It makes NEWS section in trunk/index.html a bit more
> >> > concise and therefore
On Fri, 16 Mar 2007, Tshepang Lekhonkhobe wrote:
> On 3/15/07, Tim Janik <[EMAIL PROTECTED]> wrote:
>> On Thu, 15 Mar 2007, Tshepang Lekhonkhobe wrote:
>> > It makes NEWS section in trunk/index.html a bit more
>> > concise and therefore 'more readable'. I just want a go-ahead from one
>> > of you
On Fri, Mar 16, 2007, Tshepang Lekhonkhobe wrote:
> adding the 'p' option results in:
> "svn: Error parsing diff options: Bad character specified on command line"
> even when I get rid of 'u' option.
If you want to use -p, you can try setting "diff-cmd = my-diff" in the
helpers section of ~/.sub
On 3/16/07, Mathieu Lacage <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-03-15 at 10:56 -0400, Owen Taylor wrote:
>
> > Well, I could imagine (maybe, barely) that someone could show me numbers
> > that showed that with a variety of long and complicated regular
> > expressions, compiling them was still
28 matches
Mail list logo
