Pike-devel February 2015

pike-devel@lists.lysator.liu.se

4 participants
13 discussions

Re: Playing music using pike and SDL.
by Martin Nilsson (lvl 60) ＠ Pike (-) developers forum 03 Dec '25

03 Dec '25

Were you not able to get any C code to play through SDL either? Does your SDL library have a mixer compiled in it (I think it is optional)?

3 2

8.0
by Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum 22 Mar '15

22 Mar '15

> Would anyone object to releasing 8.0 from 8.0.38? Sounds good to me. I don't think I have any known major issues left to fix.

3 10

Setting socket options: so many, uhh, options!
by Chris Angelico 10 Mar '15

10 Mar '15

Topic branch: rosuav/sockopt Per Lance's suggestion, I've made a generic setsockopt() function. It works only with integers, so it's not suitable for SO_LINGER, which therefore should stay the way it is (linger() takes a magic parameter of -1), but it works for any of the simple boolean options. As to shortcut functions, though, there are a few ways they can be done. 1) set_keepalive() always exists, even if SO_KEEPALIVE isn't available. If you call it when there's no SO_KEEPALIVE, it sets errno and returns failure. 2) set_nodelay() exists only if TCP_NODELAY is available. 3) setsockopt() itself is useless without the constants, and Stdio.TCP_NODELAY will exist only if TCP_NODELAY is available. So in a Pike script, using setsockopt() requires either has_index() run-time checks or #if compile-time checks for the options you want; set_keepalive's model works easily if you know that the Pike version you're targeting supports it; and set_nodelay's model lets you treat older Pikes and systems without that feature the same way. I'd rather make it as easy as possible on the Pike code. Which way makes more sense? ChrisA

5 13

pike7.8 precompile with old pike 7.8 installed
by Arne Goedeke 26 Feb '15

26 Feb '15

The precompile.sh in pike 7.8 initially just tries to run 'pike -x precompile' if that pike supports precompile. If that precompile does not succeed, the script does not try to run any of the other possibilities (compiled pike, etc). The install then fails completely. This is happening to me when precompiling the zxid.cmod which uses string rages, which are not supported by older pike 7.8 versions. How should we fix that? Its something that will happen to people trying to install a newer pike7.8 from git. arne

1 0

Stdio.File buffer mode
by Arne Goedeke 24 Feb '15

24 Feb '15

I gave the new buffer mode another try. Unfortunately there are a couple of bugs. I don't really want to start changing things around, especially because I am not sure how it was intended to work. I will just dump a list here, some are questions. All this happens when using buffer mode for both directions in nonblocking callback mode. 1) Stdio.File calls intput_from from the read cb but does not properly handle the return -1 case and does not check errno(). The close callback is never called. input_from also reactivates the read event, so the read will reoccur for ever. 2) set_buffer_mode does __fd_set_output( this ) which leads to add() calling Stdio.File()->write() calling output_to(), which leads to data written in the wrong order initially. I guess __fd_set_output( ::write ) should be the right thing to do here? 3) Why does the io_call_write call triggered by add() only write a maximum of 100 bytes? arne

1 0

cycle detection and destroy()
by Arne Goedeke 21 Feb '15

21 Feb '15

The destruction of objects is deferred. this leads to destroy() being called at some later point (after error, function return, some io handling, etc). when destroy() calls any code which has cycle detection, this can lead to spurious errors. Imagine a destroy function which calls sprintfs with some global object (e.g. Val.null). Similar problems arise when destroy is called while some mutex lock is being held and destroy() tries to aquire the same lock. Of course in that case the cycle detection simply guards against deadlock. What kinds of things can safely be done from within destroy() and should we document them? arne

4 3

%x on strings
by Martin Nilsson (Opera Mini - AFK!) ＠ Pike (-) developers forum 17 Feb '15

17 Feb '15

How about making %x and %X work on strings to hexcode them?

3 6

Re: gdb_backtraces()
by Chris Angelico 10 Feb '15

10 Feb '15

On Wed, Feb 11, 2015 at 1:45 AM, Mirar @ Pike developers forum <10353(a)lyskom.lysator.liu.se> wrote: > What's the git command to get whatever git is calling the head > revision of Pike? (I presume it's there.) Not sure what you mean. You can get the exact commit hash: $ git rev-parse HEAD dffaa5d5405548d2f35355bd749e10bf8a2fc026 Or the symbolic name, which identifies the branch: $ git rev-parse --symbolic-full-name HEAD refs/heads/8.1 The meaning of HEAD will depend on what's checked out, if you're looking at a local (non-bare) clone of the repo. ChrisA

3 2

Re: gdb_backtraces()
by Mirar ＠ Pike developers forum 10 Feb '15

10 Feb '15

I probably need some sort of URL too?

1 0

gdb_backtraces()
by Mirar ＠ Pike developers forum 10 Feb '15

10 Feb '15

Should gdb_backtraces() still work in 8.0? (gdb) call gdb_backtraces() Program received signal SIGSEGV, Segmentation fault. 0x0005e0c4 in gdb_backtrace (thread_id=<optimized out>) at /home/pi/Pike-v8.0.10/src/interpret.c:3345 3345 args = DO_NOT_WARN((INT32) MINIMUM(f->num_args, Pike_sp - f->locals)); The program being debugged was signaled while in a function called from GDB. GDB remains in the frame where the signal was received. To change this behavior use "set unwindonsignal on". Evaluation of the expression containing the function (gdb_backtraces) will be abandoned. When the function is done executing, GDB will silently stop. (gdb) p *f $2 = {refs = 1, args = 1, fun = 9, num_locals = 1, num_args = 1, flags = 0, ident = 0, next = 0x1f7bd84, scope = 0x0, pc = 0x0, return_addr = 0x200336f "\024\217-", locals = 0xb6ac5098, save_sp = 0xb6ac5090, expendible = 0xb6ac5098, save_mark_sp = 0xb6a63000, mark_sp_base = 0xb6a63000, current_object = 0x1f78608, current_program = 0x1f726ec, context = 0x1f858dc, current_storage = 0x1f8ef50 "`\357\370\001\003"} (gdb) p *Pike_interpreter_pointer Cannot access memory at address 0x0 (gdb) info threads Id Target Id Frame * 2 Thread 0xb65c4470 (LWP 19748) "pike" 0xb6e9e250 in nanosleep () from /lib/arm-linux-gnueabihf/libpthread.so.0 1 Thread 0xb6fde000 (LWP 19742) "pike" 0x0005e0c4 in gdb_backtrace (thread_id=<optimized out>) at /home/pi/Pike-v8.0.10/src/interpret.c:3345 Both threads look like normal pike interpreter threads, except the one with the crashed gdb_backtraces() on top. This is repeatable, but not from just running Hilfe. ARM (Pi).

3 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 February 2015