> "_wstat does not work with Windows Vista symbolic links. In these cases,
> _wstat will always report a file size of 0. _stat does work correctly with
> symbolic links."
Ugh, how weird and unexpected. (My expectation would have been that
neither supports symbolic links.) For which C runtime is
Ugh, how weird and unexpected. (My expectation would have been that
neither supports symbolic links.) For which C runtime is this, btw,
the system msvcrt.dll, or some of the MSVC-version-specific ones?
The MSDN documentation doesn't specify. I suspect its all of them TBH.
Instead, we should jus
>> Ugh, how weird and unexpected. (My expectation would have been that
>> neither supports symbolic links.) For which C runtime is this, btw,
>> the system msvcrt.dll, or some of the MSVC-version-specific ones?
>
> The MSDN documentation doesn't specify. I suspect its all of them TBH.
Actually, lo
On Thu, Sep 29, 2011 at 11:35, Tor Lillqvist wrote:
>
>> Sure but if all I want to know how big a file is, do I *really* want to link
>> in all of that extra crud? GIO is huge. There are times when the low level
>> functions are just plain appropriate.
>
> I would say, bah. Any actively maintained
hi;
On 29 September 2011 09:57, Andrew W. Nosenko
wrote:
> On Thu, Sep 29, 2011 at 11:35, Tor Lillqvist wrote:
>> I would say, bah. Any actively maintained (or recently written)
>> GLib-using code that doesn't use GIO by now is just being maintained
>> or written in a misguided fashion.
>
> Tor,
On Thu, Sep 29, 2011 at 10:05:57AM +0100, Emmanuele Bassi wrote:
> On 29 September 2011 09:57, Andrew W. Nosenko
> wrote:
> > On Thu, Sep 29, 2011 at 11:35, Tor Lillqvist wrote:
> >> I would say, bah. Any actively maintained (or recently written)
> >> GLib-using code that doesn't use GIO by now i
On Thu, Sep 29, 2011 at 12:05, Emmanuele Bassi wrote:
> hi;
>
> On 29 September 2011 09:57, Andrew W. Nosenko
> wrote:
>> On Thu, Sep 29, 2011 at 11:35, Tor Lillqvist wrote:
>>> I would say, bah. Any actively maintained (or recently written)
>>> GLib-using code that doesn't use GIO by now is jus
On Thu, 2011-09-29 at 12:44 +0300, Andrew W. Nosenko wrote:
> On Thu, Sep 29, 2011 at 12:05, Emmanuele Bassi wrote:
> > if GIO is measurably slower at doing I/O than a stat(), please: file
> > bugs along with profiling data.
>
> GIO as layer is so comparable to stat() as apples comparable to
> gr
if GIO is measurably slower at doing I/O than a stat(), please: file
bugs along with profiling data.
This is WAY off topic but still ... how can you possibly believe it is NOT
slower? One system call versus:
1. Allocate arrays
2. Allocate hash tables
3. Do strdups
4. Calculate hashes
5. Involve
On 29 September 2011 10:53, Kean Johnston wrote:
> I really don't need accurate GPS measuring to know that a Bugati Veyron is
> faster than a Fiat Uno, any more than I need to provide you with profiling
> data to prove that GIO is slower than g_stat().
I can also tell you that for driving from my
Of course GIO is slower when you look at the LoC count, the question
is for the typical case is performance acceptable. If your
application is opening a million files then maybe it's not typical.
Maybe my application runs on a router and not on an 64-core Core i5000 with
16 petabytes of RAM. J
On 29 September 2011 11:13, Kean Johnston wrote:
> No way you can convince me
> otherwise I'm afraid, and that's not because I'm being stubborn, it's
> because I (and I think you) know I'm right. GIO is appropriate for some
> applications, of that I have no doubt, but trying to convince me that it
If you are happy limiting yourself to a single platform and don't need
some the magic that comes with GIO, feel free to use stat(). It's not
UNIXWARE, SCO OpenServer, AIX, Solaris, MacOS X, Windows, Linux,
FreeBSD, OpenBSD, NetBSD, Minix, HP-UX ... did I miss any platforms? I'll
consider myself
Am 29.09.2011 12:24, schrieb Kean Johnston:
If you are happy limiting yourself to a single platform and don't need
some the magic that comes with GIO, feel free to use stat(). It's not
UNIXWARE, SCO OpenServer, AIX, Solaris, MacOS X, Windows, Linux,
FreeBSD, OpenBSD, NetBSD, Minix, HP-UX ... did
On 9/29/2011 6:24 AM, Kean Johnston wrote:
If you are happy limiting yourself to a single platform and don't need
some the magic that comes with GIO, feel free to use stat(). It's not
UNIXWARE, SCO OpenServer, AIX, Solaris, MacOS X, Windows, Linux,
FreeBSD, OpenBSD, NetBSD, Minix, HP-UX ... did
Hi,
I'm battling a problem where imsettings, running as part of the
desktop session, causes a delay between 5 and 20 seconds on every
system shutdown, while it is trying to clean up dbus stuff.
When shutting down, systemd quickly sends TERM signals to everything
in the display manager cgroup, inc
Thanks, Allin. Glib's ./configure --help mentions environment variables
PKG_CONFIG path to pkg-config utility
PKG_CONFIG_PATH
directories to add to pkg-config's search path
PKG_CONFIG_LIBDIR
path overriding pkg-config's built-in search path
ZLIB_CFLAGS C compi
On Wed, Sep 28, 2011 at 11:52:26PM -0700, stu...@zulazon.com wrote:
> I think it should be possible for someone unfamiliar with either package
> to build glib from source after reading INSTALL, before installing
> pkg-config. Either that, or to install pkg-config before installing glib
I guess yo
On Wed, 28 Sep 2011 at 23:52:26 -0700, stu...@zulazon.com wrote:
> CXXCPP C++ preprocessor
There are many more like this (CC, LD, CXXFLAGS etc.), but they're standard
for all Autotools packages, and none are mandatory.
> PCRE_CFLAGS C compiler flags for PCRE, overriding pkg-config
> PC
Hi!
> GtkGrid should be pretty much a drop-in replacement for GtkTable. Keep
> in mind that GtkGrid uses the align and expand flags of
> GtkWidget[2][3][4][5] instead of having expand and fill child
> properties.
>
> As always, should you have any questions, don't hesitate to ask.
This is a massi
On Thu, Sep 29, 2011 at 12:30 PM, Johannes Schmid wrote:
> Hi!
>
>> GtkGrid should be pretty much a drop-in replacement for GtkTable. Keep
>> in mind that GtkGrid uses the align and expand flags of
>> GtkWidget[2][3][4][5] instead of having expand and fill child
>> properties.
>>
>> As always, sho
Hi!
> deprecated != gone.
>
> There is no super-urgent need to rid the world of GtkTables - unless
> you want your module to compile with disabled deprecations.
Sure, but you know how picky some people are about deprecations...
Regards,
Johannes
___
On Thu, Sep 29, 2011 at 6:30 PM, Johannes Schmid wrote:
> This is a massive change to existing GtkBuilder .ui files so I would
> suggest that somebody able to do xml and/or sed/grep magic would write a
> script that just replaces GtkTable with GtkGrid in existing .ui files. If
> that is included i
There exists a bug in the gdk-pixbuf's GDI+ animation handling that
causes it to use the first frame's delay to be used for all frames.
This is causing a much-lamented bug in Pidgin on Windows
(http://developer.pidgin.im/ticket/11858).
A couple of months ago I reported this bug (#655755) and provi
If GtkTable and GtkGrid were replaceable by a sed expression, I don't
think we would have bothered breaking API.
On Thu, Sep 29, 2011 at 1:11 PM, Johannes Schmid wrote:
> Hi!
>
>> deprecated != gone.
>>
>> There is no super-urgent need to rid the world of GtkTables - unless
>> you want your modul
25 matches
Mail list logo
