Pike-devel February 2010

pike-devel@lists.lysator.liu.se

4 participants
17 discussions

SO_REUSEADDR after an accept()?
by Stephen R. van den Berg 21 Feb '10

21 Feb '10

Why are we setting SO_REUSEADDR on a filedescriptor/socket that came from an accept()? (in socket.c) IMO that seems useless. For a socket used in a bind(), it makes sense, but not for anything else. Any insights? (Henrik? You touched that piece of code last). -- Sincerely, Stephen R. van den Berg. A sign seen in a jewelry store window: "Ears pierced while you wait"

1 0

Gz.FIXED and Windows build
by Stephen R. van den Berg 20 Feb '10

20 Feb '10

In checking the Windows build I notice: -------- Doing tests in modules/Image/testsuite (1480 tests, pid 44356) Cond 1477:1:Index 'FIXED' not present in module Gz. Cond 1477:1:Indexed module was: Gz. Conditional 1477 (line 827) failed. Doing tests in modules/Mysql/testsuite (0 tests, pid 45592) -------- The testsuite of Gz seems to be ok, though. Any takers? -- Sincerely, Stephen R. van den Berg. "First, God created idiots. That was just for practice. Then he created school boards." -- Mark Twain

6 28

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 12 Feb '10

12 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

2026

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