Pike-devel

pike-devel@lists.lysator.liu.se

3041 discussions

Calendar.Timezone etc. - Up-to-date timezone and daylight savings data
by Magnus Holmgren, Millnet/Lysator/Debian/Mensa ＠ Pike developers forum 26 Mar '16

26 Mar '16

I'm thinking about getting around to integrating Pike with the tzdata package in Debian, which I was talking about at the conference some years ago, but I need to check and understand some things first. If I understand correctly, the Calendar module knows about daylight savings time and other jumps in local time in different regions, which is has to in order to convert past moments in time between local and universal time, but it doesn't make use of the operating system for this (except to find out what the current local timezone is), only data provided with the source code (which as of 8.0.182 is from 2013). Now, there is mkrules.pike, which compiles the tzdata files into a set of classes, but it apparently isn't run at build time and while I guess that one could use the generated classes directly, I can't see that they are used by Calendar.Timezone. The following comment suggests that mkrules.pike was discontinued but left in the source tree. // ================================================================ // this is to runtime-compile timezones // it's not very nice; based on the one-time-compilation // utility I wrote first - but that method was too slow :/ // ================================================================ Now, having the tzdata source package create a tzdata-pike package by running mkrules.pike would have created a bootstrapping problem as pike8.0-core would depend on a package that itself would be needed for to build, so perhaps it's only easier to create a package that simply installs the tzdata source files in the right location?

2 2

Re: Segfault in colortable.c
by Chris Angelico 25 Mar '16

25 Mar '16

On Fri, Mar 25, 2016 at 10:55 PM, Martin Nilsson (Coppermist) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > Probably correct. We really should have all the image operations > performed in the image testasuite as well... Okay, pushed to 8.1 then. Thanks. ChrisA

1 0

Segfault in colortable.c
by Chris Angelico 25 Mar '16

25 Mar '16

I've been digging into a segfault that was preventing 'make doc' from operating correctly, and pinned it down to this code: src/modules/Image/colortable.c:2010 - rnd->u.refs++; + ++*rnd->u.refs; and corresponding decrementing of the refcount. The count appears to be a pointer, not a direct integer, so it looks like it ought to be dereferenced here. Not 100% sure the fix is correct though, so I pushed to branch rosuav/colortable-segfault instead of directly to 8.1. Can someone check it, please? Test case, cribbed from the code behind 'make doc': #define IMAGE_DIR "/home/rosuav/pike/refdoc/src_images/" object lena() { catch { return Image.load(IMAGE_DIR + "image_ill.pnm"); }; catch { return Image.load(IMAGE_DIR + "lena.ppm"); }; catch { return Image.load(IMAGE_DIR + "lenna.rs"); }; return Image.load(IMAGE_DIR + "lena.gif"); } int main() { object c=Image.Colortable(lena(),2)->randomcube(60,60,60); c*lena(); } ChrisA

2 1

Windows-Hilfe
by Martin Nilsson (Coppermist) ＠ Pike (-) developers forum 23 Mar '16

23 Mar '16

Anyone know what termcaps should be on windows cmd terminal? It's super-annoying not having history in hilfe.

1 0

random on iterators
by Martin Nilsson (Coppermist) ＠ Pike (-) developers forum 14 Mar '16

14 Mar '16

How stable are Mapping.Iterator and Multiset.Iterator? Is the order guaranteed, platform dependent or something else?

2 4

Pike 8.0.182 release candidate
by Peter Bortas 10 Mar '16

10 Mar '16

Release candidate for testing: https://pike.lysator.liu.se/pub/pike/beta/8.0.182/Pike-v8.0.182.tar.gz Changes since Pike 8.0.164 (current stable) ---------------------------------------------------------------------- New features ------------ o gc It is now possible to run the gc in a quick mode to just cut weak references from a specific container. Bug fixes --------- o ADT.Heap The Element class lost track of its position when remove() was used. o Filesystem.Monitor * Improved thread safety and robustness * Inotify-related fixes. o pgsql The new driver in 8.0 suffered from filedescriptor leaks if the database connections were not explicitly close()d. Fixes have been applied which eliminate the filedescriptor leak and also ensure that the filedescriptors are closed the instant the object loses all references. o programs The runtime now attempts to wait for any compilations in progress to complete before complaining about cloning of unfinished programs. This fixes a race-condition when the same program is compiled from different threads. o Runtime Fixed multiple potential NULL-dereferences. o SSL.File Fixed breaking of circular references when the peer terminates the connection. o Standards.URI Support the userinfo field containing '@'. o Stdio.File The second argument to set_buffer() should now work. o Testsuite Updated the SHA3_* testvectors to FIPS 202. Building and installing ----------------------- o Multiple fixes for building on Solaris 11.

4 6

Fixing compilation with --enable-werror
by Chris Angelico 03 Mar '16

03 Mar '16

Currently, 8.1 trunk doesn't build with CONFIGUREARGS=--enable-werror on GCC 5.3.1, due to a couple of small issues. I've pushed fixes to the rosuav/enable-werror branch; can someone please try this on a different system, different compiler, etc, to see if it breaks anything? The three changes are: 1) Add a #include to ensure that a function is available. 2) Enable a block of code that was otherwise restricted to PIKE_DEBUG mode 3) Work around a spurious GCC warning! ChrisA

1 0

Re: Tracking down corruption after exception in GTK signal handler
by Chris Angelico 03 Mar '16

03 Mar '16

On Thu, Mar 3, 2016 at 11:00 PM, Peter Bortas @ Pike developers forum <10353(a)lyskom.lysator.liu.se> wrote: > Try compileing Pike with -fsanitize=address, there's a fairly good > chance that would catch exactly when things start going wrong of we > are talking about any kind of over/under-flow. > While I was poking with this, Grubba pushed a fix that appears to cure the problem (both for my little test case and for the original): bdcd55, using safe_apply_value. Thanks Grubba! Came across a really obscure compilation bug, though. Fun stuff. ChrisA

1 0

Tracking down corruption after exception in GTK signal handler
by Chris Angelico 03 Mar '16

03 Mar '16

int main() { GTK2.setup_gtk(); object btn=GTK2.Button("Raise an exception"); object win=GTK2.Window(0)->add(btn)->show_all(); win->signal_connect("destroy",lambda() {exit(0);}); btn->signal_connect("clicked",lambda() {error("Baboom!\n");}); return -1; } Run this, click the button, then close the window. Pike will segfault. Running a --with-debug Pike under gdb shows that the actual segfault occurs in backend_callback (defined in GTK2/source/global.pre), where it calls into the low end main loop for an iteration. Not immediately helpful. I suspect that something's getting corrupted - maybe in the Pike stack, maybe something gets freed in GTK that should have another reference - when the exception happens. How can I go about tracking this down? Where would I put probes to watch for unexpected changes? ChrisA

4 19

Re: Pike 8.0.182 release candidate
by Stephen R. van den Berg 03 Mar '16

03 Mar '16

Peter Bortas wrote: >o programs > The runtime now attempts to wait for any compilations in progress to > complete before complaining about cloning of unfinished programs. > This fixes a race-condition when the same program is compiled from > different threads. Incidentally: this fix is incomplete. So it fixes some of those race-conditions, but not all of them. -- Stephen.

2 3

Jump to page:

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