Pike-devel June 2014

pike-devel@lists.lysator.liu.se

4 participants
16 discussions

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

15 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

Redefinition of size_t
by Magnus Holmgren, Millnet/Lysator/Debian/Mensa ＠ Pike developers forum 03 Jun '14

03 Jun '14

Automated build revealed problems in _Image_JPEG due to redefinition of size_t: http://bugs.debian.org/750430 The commit log message (8b7ca6ff970aed0c) for the "#define size_t unsigned int" line talks about applying kludges from image_jpeg.c. The commit log message from image_jpeg.c is from 1998 and reads "header file compat fixes (what happened?)", but the change was undone there in 2008 by 4e36f92cfa282f0b, and so you should probably restore transupp.c as well.

1 0

sprintf optimizations have issues with %{ %} - segfault
by Chris Angelico 01 Jun '14

01 Jun '14

Example code: int main() { array x=({ ({128,0,"TiMidity","TiMidity port 0"}), ({128,1,"TiMidity","TiMidity port 1"}), }); write("Ports available:\n%{%3d:%-3d %-32.32s %s\n%}",x); } In the latest Pikes, this may segfault or produce horribly wrong data; a --with-debug build emits a fatal "sprintf: fs->fsp incorrect after recursive sprintf.". Bisecting a non-debug build pointed to 7fdf94 as the crash culprit, but I couldn't replicate that bisection on a debug build for some reason (the build didn't finish for several commits). The problem seems to occur when %{ %} results in a reallocation of the format_info_stack at the top of low_pike_sprintf (sprintf.c:1026). There's a ptrdiff_t that doesn't seem to be used anywhere, and which could be connected. I'm not sure why 7fdf94 should bring in the problem, though, as it looks like a direct - almost mechanical - translation. ChrisA

2 3

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 June 2014