Pike-devel

pike-devel@lists.lysator.liu.se

2 participants
3046 discussions

Re: Casting int to float broken in 8.0 on amd64 Linux
by Chris Angelico 25 Jun '14

25 Jun '14

On Tue, Jun 24, 2014 at 7:05 PM, Per Hedbor () @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > Could you give this version of SET_SVAL a try, perhaps? > > #define SET_SVAL(SVAL, TYPE, SUBTYPE, FIELD, EXPR) do { \ > /* Set the type afterwards to avoid a clobbered \ > * svalue in case EXPR throws. */ \ > struct svalue * _sv_ptr=&( SVAL ); \ > _sv_ptr->u.FIELD = (EXPR); \ > *((ptrdiff_t*)&_sv_ptr->type) = TYPE_SUBTYPE(TYPE,SUBTYPE);\ > } while(0) Has exactly the same result. It's entirely possible I'm misdiagnosing this. To come to the conclusion I did, I took the current 8.0 branch, reverted that one commit, and then began applying it piece by piece. The change to configure.in didn't break anything, the change to svalue.h did. Within that, changing from INT16 to short had no effect (on my system, I believe INT16 compiles to short anyway); adding structures and unused defines, unsurprisingly, didn't break anything; and changing the definition of SET_SVAL induced the error message. That's all the info I have to offer. I'm starting up a completely fresh Pike clone to see if somehow I've accumulated cruft of some sort. If that behaves differently, I'll let you know. ChrisA

5 6

new 7.8 stable
by Bill Welliver 24 Jun '14

24 Jun '14

I've moved the latest 7.8 (7.8.866) build to the "all" directory and created a symbolic link to latest-stable. Please feel free to download and upload binaries if you're into such things. Do let me know if any problems are discovered... if all goes well I'll announce things on the main mailing list sometime tomorrow. Best, Bill

1 0

Casting int to float broken in 8.0 on amd64 Linux
by Chris Angelico 24 Jun '14

24 Jun '14

As of commit 7666f806, casting an int to a float fails: rosuav@sikorsky:~/pike$ bin/pike Pike v8.0 release 3 running Hilfe v3.5 (Incremental Pike Frontend) > (float)1; Cast failed, wanted float, got int HilfeInput:1: HilfeInput()->___HilfeWrapper() This happens also on any arithmetic operation that mixes int and float, which does an equivalent cast implicitly. Fiddling around with the corresponding code suggests it may be connected to the GCC warning that also comes up: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] In SET_SVAL, two pointers to the same object with different types are used. I think this violates the C standard, which is why sometimes stuff isn't getting correctly written out - something's getting optimized away. Is there a way to do the same job with a union inside struct svalue, instead of the pointer casts? Or alternatively, can the compiler be told not to optimize this out? ChrisA

2 1

Re: Float details
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 22 Jun '14

22 Jun '14

In e.g. C you would use the signbit() function to find that out. It looks like the Pike sgn() function isn't usable for this purpose though.

1 0

Re: Float details
by Chris Angelico 21 Jun '14

21 Jun '14

On Sat, Jun 21, 2014 at 9:45 AM, Martin Nilsson (Opera Mini - AFK!) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > So -0.0 is a thing. Should we fix any of these: > >> -0.0; > (1) Result: -0.0 >> equal(-0.0, 0.0); > (2) Result: 1 >> -0.0 < 0.0; > (4) Result: 0 These look fine. IEEE 754 says that negative and positive zero are equal. >> decode_value(encode_value(-0.0)); > (3) Result: 0.0 This is the only one that could be called wrong. I doubt it's going to have tripped people up, so changing it or not changing it could be simply a matter of convenience. ChrisA

1 0

problem building 8.0 on sunos 11
by Bill Welliver 19 Jun '14

19 Jun '14

Well, technically it's SmartOS on intel... pike builds but any attempts to use the resulting binary generate the following error (such as when used by post_modules): /home/hww3/dev/rsynced/build/pike/src/pike_types.c:8451: Fatal error: Type mark stack overflow. No stack - no backtrace. I've tried a few random commits back through march and they all have the same problem, so it doesn't appear to be a very new problem. Anyone have any suggestions? Bill

1 0

pike 7.8 stable final
by H. William Welliver III 16 Jun '14

16 Jun '14

I’m about ready to declare 7.8.866 stable; is anyone else able to make Windows binaries? I’ve got a build environment, but I’m pretty sure I’m using a different set of libs and an old version of VC, so it would probably be better to use something more similar to previous builds. If that’s not an option, I can prepare something, but there will likely be differences that some people might notice. On a side note, I did learn a bit more about the problems I noticed with MSI builds… it doesn’t look like DLL bundling was ever working for WIX input generation. There is code for bundling up the DLLs, but it looks like it was only running with the previous windows install method. I’ve got some more testing to do to make sure it works properly, but will probably check things in sometime this week (in case anyone was interested :)). Bill

1 0

Memory use
by Martin Nilsson (Opera Mini - AFK!) ＠ Pike (-) developers forum 11 Jun '14

11 Jun '14

While looking at other things I did this small program that summaries the string memory void main() { string x = ""; mapping m = ([]); do { x = _next(x); m[ (sizeof(x)*String.width(x))/1024*1024 ]++; } while( x!="2"); write("%O\n", m); } and to my surprise there are some really large ones right at startup. Do they originate from the type system? Getting them to not be wide strings would be a great first step. ([ /* 33 elements */ 0: 2098, 1024: 76, 2048: 41, 3072: 26, 4096: 13, 5120: 14, 6144: 4, 7168: 4, 8192: 4, 9216: 3, 10240: 5, 11264: 2, 12288: 3, 13312: 4, 14336: 2, 15360: 1, 16384: 3, 17408: 2, 18432: 1, 20480: 1, 21504: 1, 22528: 1, 23552: 1, 25600: 1, 28672: 1, 30720: 1, 39936: 2, 59392: 1, 66560: 1, 71680: 1, 99328: 1, 117760: 1, 190464: 1 ])

3 3

Re: Memory use
by Chris Angelico 11 Jun '14

11 Jun '14

On Wed, Jun 11, 2014 at 6:15 PM, Henrik Grubbström (Lysator) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > The large wide strings at startup are most likely the bytecode for the > master and related modules. Why is the bytecode for the master a wide string? ChrisA

1 0

7.8 feedback
by H. William Welliver III 03 Jun '14

03 Jun '14

Does anyone have any feedback that would prevent me from announcing 7.8.856 as the new stable build? I was hoping to make some headway on the windows ell problem I noticed, but if Peter’s build doesn’t have that problem, I’m not too worried about having an answer to the problem beforehand. Bill

3 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