Pike-devel

pike-devel@lists.lysator.liu.se

2 participants
3046 discussions

Hi All, , , I get a lot of 'Cannot access global variables in destructed object' errors when rebooting Roxen. It looks as though a function call is completed even after the object is destructed. I only get the error when setting (private) class members of an object. The rest of the functions seems to execute without problem., , Is there any way to prevent this? Like either not execute the function if the object is (going to be) destructed or not destruct an instance until the function has completed?, , Than
by Coen Schalkwijk 08 Mar '10

08 Mar '10

Hi All, I get a lot of 'Cannot access global variables in destructed object' errors when rebooting Roxen. It looks as though a function call is completed even after the object is destructed. I only get the error when setting (private) class members of an object. The rest of the functions seems to execute without problem. Is there any way to prevent this? Like either not execute the function if the object is (going to be) destructed or not destruct an instance until the function has completed? Thanks in advance!* * -- Met vriendelijke groet / With kind regards / mit besten Grüßen, Coen Schalkwijk Software Engineer coen.schalkwijk(a)rtl.nl <mailto:coen.schalkwijk@rtl.nl> coen(a)rtlinteractief.nl <mailto:coen@rtlinteractief.nl> +31 (0)35 671 8915

1 0

Re: Feedback (Re: pcvs2git.pike)
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 01 Mar '10

01 Mar '10

In svn, a change in a keyword value does not count as a change; the file does not indicate as modified and the result of "svn diff" is empty.

4 7

port.c does not work in CONFIGURE_TEST mode?
by Stephen R. van den Berg 28 Feb '10

28 Feb '10

On eureka-git.lysator.liu.se: --------------------- $ make configure [...] checking if union initialization works... yes checking if port.c works in CONFIGURE_TEST mode... no configure: error: port.c does not work in CONFIGURE_TEST mode. This is an internal problem in Pike. configure aborted since further configure tests will be unreliable. gmake: *** [configure] Error 1 --------------------- Is this a known issue? Any suggestions? -- Sincerely, Stephen R. van den Berg. I'm NaN.

2 2

pike-git.lysator.liu.se unreachable?
by Stephen R. van den Berg 25 Feb '10

25 Feb '10

Is there a good reason why pike-git.lysator.liu.se is unreachable? -- Sincerely, Stephen R. van den Berg. A: Because it messes up the order you normally read text in. Q: Why is top-reply so bad? A: Top-reply. Q: What is the most annoying thing in E-mail?

2 1

Re: Testsuite failures (Re: Gz.FIXED and Windows build)
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 21 Feb '10

21 Feb '10

The OS X manpage for ld mentions a "-macosx_version_min" option, are we correctly applying that one? I'm assuming it needs to match the number used for __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ for things to work out as intended.

2 2

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

20 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

Jump to page:

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