Pike-devel June 2014

pike-devel@lists.lysator.liu.se

4 participants
16 discussions

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 … [View More]

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: … [View More]

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 … [View More]

2 3

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