> I've been running with phobos built using "-ffunction-sections -fdata-sections" since ~the time of #293 and so far haven't seen any problems (which of course doesn't mean that there aren't any).

Me too. If you don't use gc-sections there shouldn't be any difference and if you do a lot of unnecessary code is stripped.

Am Mon, 23 Apr 2012 12:00:02 +0200
schrieb Trass3r <un@known.com>:

> > I've been running with phobos built using "-ffunction-sections -fdata-sections" since ~the time of #293 and so far haven't seen any problems (which of course doesn't mean that there aren't any).
> 
> Me too. If you don't use gc-sections there shouldn't be any difference and if you do a lot of unnecessary code is stripped.

Allright, I just built GDC with DFLAGS=-ffunction-sections -fdata-sections
You know what happened? My animation in the Gtk app started to stop for some milliseconds in regular intervals. Yes, the application got smaller, but it started to show subtle anomalies, like back when I had the problem with exceptions. :-/

-- 
Marco

On Monday, 23 April 2012 at 11:28:08 UTC, Marco Leise wrote:
> You know what happened? My animation in the Gtk app started to stop for some milliseconds in regular intervals.

Sounds like GC problems. My wild guess without even really thinking about whether it makes sense: The GC now scans a much larger memory region because of an unexpected section layout, leading to the noticeable pauses – which platform are you on?

David

Am Mon, 23 Apr 2012 17:48:07 +0200
schrieb "David Nadlinger" <see@klickverbot.at>:

> On Monday, 23 April 2012 at 11:28:08 UTC, Marco Leise wrote:
> > You know what happened? My animation in the Gtk app started to stop for some milliseconds in regular intervals.
> 
> Sounds like GC problems. My wild guess without even really thinking about whether it makes sense: The GC now scans a much larger memory region because of an unexpected section layout, leading to the noticeable pauses – which platform are you on?
> 
> David

I suspect the GC as well, but I have no idea what you have in mind. How does the section layout influence the GC? I'm on Linux x86_64.

-- 
Marco

I did a test run with a system profiler and I see this:

--8<-----------------

CPU: Core 2, speed 2001 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (Unhalted core cycles) count 100000

%        symbol name
24.5102  void gc.gcx.Pool.__invariant()
10.4862  void gc.gcx.Gcx.__invariant()

--8<-----------------

invariant()? Wouldn't that be removed in a release build? Then it came to my head, that maybe, just maybe, setting
export DFLAGS="-ffunction-sections -fdata-sections"
before running make would disable all other flags. ... Yes that was the problem. Now it is working as expected.

-- 
Marco

Have you tested it on osx?
I get lots of errors such as Error: module Atk from file gtk2/atk.d conflicts with another module Atk from file gtk2/atk.d etc...
I'm wondering whether it's due to case insensitivity on OSX/windows. I thought the convention was to use all lowercase for module names. As it is it seems to create collisions. Also there were a few other errors which I had tweak for eg:

phobos/std/bitmanip.d(66): Error: shift by 32 is outside the range 0..31
phobos/std/bitmanip.d(149): Error: template instance std.bitmanip.createAccessors!("_mantissa_low_mantissa_high_biased_exponent_sign",uint,"mantissa_low",32,0u) error instantiating
phobos/std/bitmanip.d(203):        instantiated from here: createFields!("_mantissa_low_mantissa_high_biased_exponent_sign",0,uint,"mantissa_low",32,uint,"mantissa_high",20,uint,"biased_exponent",11,uint,"sign",1)
.../girtod/gtk2/glib2.d(3528):        instantiated from here: bitfields!(uint,"mantissa_low",32,uint,"mantissa_high",20,uint,"biased_exponent",11,uint,"sign",1)



On Sunday, 1 April 2012 at 19:54:31 UTC, Artur Skawina wrote:
> What's new?
>
>  - Now, in addition to
>
>    GLib, GModule, GObject, Gio, GdkPixbuf, Pango, PangoCairo, PangoFT, Gdk, Atk and Gtk+
>
>    there are also bindings for
>
>    Clutter, ClutterX11, Cogl, CoglPango and Mx.
>
>  - Struct inheritance. No more need for "container.add(&vbox.widget);", you can
>    write that as just "container.add(vbox);", the compiler will do all the work
>    to check if the 'vbox' is somehow derived from 'widget', and convert the
>    pointer by itself.
>
>    This works not only for "struct Widget {}; struct VBox { Widget widget; ... };",
>    but also for "struct Widget {}; struct VBox { Widget* widget; ... };".
>    You can extend built-in widgets and still use them with the std APIs.
>
> -  Objects can now be constructed as "gtk.VBox(0, 0)";
>    the old way, ie "gtk.VBox.new_(0, 0);" still works.
>
> -  All methods that take a (char*) pointer now also silently accept D strings;
>    casting to (char*) and/or calling toStringz are no longer necessary. It will
>    be done implicitly every time you try to pass a D string; you can still pass
>    a (char*) to avoid the copy.
>
> -  GTK (GObject) interfaces supported.
>
> -  Better error messages when registering signal callbacks (the messages given by
>    the compiler when a template instantiation fails are not very helpful and, as
>    it typically happens via several alias levels, were often just confusing).
>
> -  Some 64-bit fixes (I don't have a 64-bit GTK stack ATM, so there could be
>    more problems around).
>
> -  The pre-generated D modules were built using newer library versions
>    (still GTK2, only the glib version is newer than that).
>
> -  New examples: Clutter and Mx. Trivial, but enough to get you started.
>
>
> A D GTK app now looks like this:
>
>    http://repo.or.cz/w/girtod.git/blob/refs/heads/master:/example_gtk.d
>
> doesn't need a single cast (other than for skipping the string copies, using
> (void*) library APIs and object lookup tricks, all of which could be avoided,
> but I intentionally didn't do this in the example), looks much better than
> the equivalent C version would and couldn't be done any more efficiently in C
> (assuming same compiler middle/backend and ignoring the string differences, as
> for most cases these don't matter. The convenience makes up for the few extra
> copies and these can be avoided in every case where performance really matters).
>
>
> The code is here: http://repo.or.cz/w/girtod.git
>
> The easiest way to try the bindings is probably to check out the "gtk2" branch,
> copy the "gtk2" directory to your app directory and import from there.
>
> The girtod tool used to generate the D modules lives in the "master" branch.
> When used with different lib versions than the ones I tried it on, it may need
> a few tweaks; sometimes new types appear or move between the libs, new weird or
> broken introspection data shows up etc.
>
> artur
>
> PS. Are there any sane Cairo D binding out there? (What's "sane"? Well, if
>     there's a "class" in there somewhere then it's not sane)

On 06/01/12 12:01, timotheecour wrote:
> Have you tested it on osx?

No. You are probably the first person to try it on osx.

> I get lots of errors such as Error: module Atk from file gtk2/atk.d conflicts with another module Atk from file gtk2/atk.d etc...
> I'm wondering whether it's due to case insensitivity on OSX/windows. I thought the convention was to use all lowercase for module names. As it is it seems to create collisions.

Weird, never happened here (linux). All (gtk) D module file names use only lower case ASCII, so case-insensitivity and/or normalization shouldn't cause problems. What are you doing when you get the above error?

> Also there were a few other errors which I had tweak for eg:
> 
> phobos/std/bitmanip.d(66): Error: shift by 32 is outside the range 0..31
> phobos/std/bitmanip.d(149): Error: template instance std.bitmanip.createAccessors!("_mantissa_low_mantissa_high_biased_exponent_sign",uint,"mantissa_low",32,0u) error instantiating
> phobos/std/bitmanip.d(203):        instantiated from here: createFields!("_mantissa_low_mantissa_high_biased_exponent_sign",0,uint,"mantissa_low",32,uint,"mantissa_high",20,uint,"biased_exponent",11,uint,"sign",1)
> .../girtod/gtk2/glib2.d(3528):        instantiated from here: bitfields!(uint,"mantissa_low",32,uint,"mantissa_high",20,uint,"biased_exponent",11,uint,"sign",1)

This appears to be a std.bitmanip.bitfields bug. Doesn't happen here.
You can just comment out that struct definition to make things compile.
(these bitfields are not accessible anyway, because of a girtod bug, which
i only noticed now and will fix soon).

What compiler/version?

artur