Pike-devel February 2010

pike-devel@lists.lysator.liu.se

4 participants
15 discussions

New uLPC CVS repository added.
by Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum 20 Feb '10

20 Feb '10

FYI: In my mission to reconstruct the early history of Pike, I've just created a new CVS repository "ulpc.lost-doc", which contains some documetation files that I've reconstructed from the surviving uLPC dists.

1 0

socketpair_ultra?
by Stephen R. van den Berg 17 Feb '10

17 Feb '10

It appears that Hubbe tested socketpair() and found it to return EAGAIN and EADDRINUSE on occasion on AmigaOS? Even though all the UNIX manpages list it as incapable of returning either EAGAIN or EADDRINUSE? Anyone here who can still recall the circumstances? I can't even begin to imagine why the socketpair() call would fail with an EADDRINUSE. Any clues? -- Sincerely, Stephen R. van den Berg. I'm NaN.

3 4

Inf, NaN, DBL_MAX, HUGE_VAL
by Stephen R. van den Berg 16 Feb '10

16 Feb '10

While struggling with Solaris and a native Pike compilation, I stumble across some interesting wildlife regarding the definitions (or lack thereof) of +Inf, -Inf and NaN in Pike. Some points of interest are: - On occasion there seems to be a dependency on HUGE_VAL which is undesirable. - Configure is trying to figure out the way floats are stored (big/little endian, IEEE format or not). - In the IEEE case, we hardwire Inf and NaN through their bytewise representation in a union. - In the non-IEEE case we resort to the usage of infnan or HUGE_VAL. I'm just wondering, instead of this plethora of different avenues (some more convoluted and undesirable than others), is there a compelling reason not to define the following two macros as: #define MAKE_INF(s) (DBL_MAX*DBL_MAX*(s)) #define MAKE_NAN() (0.0/0.0) The upside is that DBL_MAX is defined by ANSI C in <float.h> and is bound to be present on all relevant systems. The only reason I could imagine that defining the above macros could pose a problem is with very old C-compilers on systems that generate a runtime error on either of the above two expressions. Then again, in that case you might be better off running older versions of Pike anyway. -- Sincerely, Stephen R. van den Berg. I'm NaN.

2 2

Paranoia fix kills performance
by Stephen R. van den Berg 16 Feb '10

16 Feb '10

In the pgsql driver I depend on the fact that I can peek(0) with zero delay. Setting the minimum to one millisecond is rather desastrous for performance. What paranoia is your patch supposed to aid? The old 7.8 code *did* a poll(0) if explicitly told to do so. Please keep it that way. The proper paranoia fix would be leaving the timeout = 1, even though I consider that paranoia unnecessary. -- Sincerely, Stephen R. van den Berg. I'm never wrong. I once thought I was wrong, turns out, I was mistaken.

2 1

common_draw.inc bug
by Lance Dillon 13 Feb '10

13 Feb '10

Fixed a bug in common_draw.inc, function draw_text(). unreffed a GObject that I shouldn't. Commenting out the unref fixed the problem. The problem was: [riffraff@hobbes Download]$ pike test6.pike (table:32415): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed (table:32415): Pango-CRITICAL **: pango_context_get_matrix: assertion `PANGO_IS_CONTEXT (context)' failed (table:32415): Pango-CRITICAL **: pango_context_get_matrix: assertion `PANGO_IS_CONTEXT (context)' failed (table:32415): GLib-GObject-CRITICAL **: g_object_get_qdata: assertion `G_IS_OBJECT (object)' failed (table:32415): Pango-CRITICAL **: pango_context_get_matrix: assertion `PANGO_IS_CONTEXT (context)' failed (table:32415): GLib-GObject-CRITICAL **: g_object_get_qdata: assertion `G_IS_OBJECT (object)' failed (table:32415): GLib-GObject-CRITICAL **: g_object_get_qdata: assertion `G_IS_OBJECT (object)' failed The unref caused this. I committed a fix.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pike-devel February 2010