Pike-devel December 2014

pike-devel@lists.lysator.liu.se

5 participants
19 discussions

negative indices in array ranges
by Martin Baehr 14 Aug '26

14 Aug '26

hi, instead of having to do: reverse(reverse(foo/"/")[1..]); i'd very much prefer: (foo/"/")[..-2]; are there any reasons that speak against supporting this other than me not being able to offer a patch? greetings, martin.

13 51

negative indices in array ranges
by Mirar ＠ Pike developers forum 14 Aug '26

14 Aug '26

levels might possibly be from -1 and up, -1 meaning infinite.

10 25

pike_frame->fun = FUNCTION_BUILTIN
by Arne Goedeke 16 Apr '26

16 Apr '26

In INIT, EXIT and some gc callbacks the fun in Pike_fp is set to FUNCTION_BUILTIN. there are some places in the code (e.g. ADT.List()->_get_iterator) where ->fun is used in INHERIT_FROM_INT et al, which segfaults (except with PIKE_DEBUG). I am not sure where to fix this. Should the *_FROM_INT macros check for FUNCTION_BUILTIN or is this better to be handled in the individual INIT/EXIT methods ? does anyone object to making ADT.Stack and ADT.Queue inherit ADT.List? arne

3 2

managing comport settings in linux
by Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum 10 Apr '26

10 Apr '26

Not a good idea; the design philosophy of Pike is that Pike-level code should never be able to cause memory corruption at C-level. With ioctls there's no way to know what data a specific ioctl wants without reading the documentation for that specific ioctl for that specific OS. ioctls and fcntls are a way for device handlers to hook in APIs that aren't standard across all filedescriptors. / Henrik Grubbström (Lysator) Previous text: >2004-08-17 13:32: >Subject: managing comport settings in linux >-------------------------------------------------------------------- >What would be nice, is a way to define ioctl methods in >Pike. Perhaps something like > >object i = Stdio.IOCTL(4242 /* request_id */ ); >i->add_int_parameter(); >i->add_string_parameter(); >i->set_return_type(STRING); > >string ret = i(fd, 1, "somestring"); > > >That ought to be possible, or..? > > / Marcus Agehall (PacketFront) >

4 3

Re: Playing music using pike and SDL.
by Martin Nilsson (lvl 60) ＠ Pike (-) developers forum 13 Mar '26

13 Mar '26

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)?

5 4

full MySQL 4.x support. or pike roadmap
by thomas.gusenleitner＠com-bet.com ＠ Pike developers forum 01 Mar '26

01 Mar '26

HI to all! mysql 4.x support works only with a mysql CFLAGS=-DUSE_OLD_FUNCTIONS is this correct ? are there plans to make a full 4.x support ? bye, thomas

4 4

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

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

Mail gateway stuck again?
by Stephen R. van den Berg 05 Jan '15

05 Jan '15

Anyway, I just tested the threading problem on 8.0. Comparable (fatal) results. -- Stephen.

2 4

Pike development meeting notes
by H. William Welliver III 19 Dec '14

19 Dec '14

As requested, I’ve organized my notes into a sort of after-report on the developer meeting that occurred on Dec 5-7 at the Roxen offices in Linköping. Please note that these notes are not complete; any additions or corrections are welcome. The permanent URL for this document is: http://wiki.gotpike.org/PikeDevel/Conference+2014 Conference Topics - Should we identify the criteria for what features get added to given branches (devel vs stable)? Who will declare a development branch stable? - What are the powers of the release manager? - Should we have procedures for adding new features to a stable branch. Note: do we need this if our stable releases happen at reasonable intervals? Note note: Aren't feature branches the tool to deal with long development cycles of complex features? - consistent type for sizes? (size_t, etc) - pointer aliasing in pike strings. There are several possibilities to fix this "for good". For instance by having a union of char[4], short[2] and int[1] arrays at the end. Alternatively, if string data was allocated seperately from the struct pike_string, a void pointer would could be correctly casted to all 3 string types without breaking aliasing rules. - arm32 machine code support (tobi/arne) - should we have a defined procedure for deprecating an API? (arne) A few other impromptu topics were discussed and didn't make it onto the "official" agenda. Conference notes These notes are probably incomplete, as discussion occasionally went in multiple directions simultaneously. Database Support Our database layer has not kept up to date with changes in database techniques: - Precompiled queries for enhanced performance, even if this is “simulated”. - Oracle/ODBC are capable of returning binary data, which would allow us to receive native data such as integers. - We should probably not allow multiple queries to be included within one call to query(), as this (among other things) invites abuse. - The use of bindings should probably be documented in order to identify the recommended usage (and include examples). Development Process Some ground rules were agreed upon in order to have a framework for managing the development and release process of Pike. These are: - Code that is not a bug fix should be committed to a development branch and be allowed to “mature” before committing to a stable branch. Seek feedback to determine when your code is “mature”. - Use of feature branches is recommended in order to allow a line of development to be more easily identified and reviewed. - When deprecating an API, that API must be marked as deprecated for at least 1 stable (X.Y) release before removal. Compatibility glue should be added wherever possible. - Your code should compile before being committed to the main branch. Try to keep in mind that pike gets built on non-*nix systems such as Windows, so your changes should take this fact into account. - When in doubt, advice should be solicited on the development list. We all have a role to play in keeping the stable tree in a reasonable state; additionally, the release manager is “deputized" to deal with unruly commits if the system doesn’t catch them. Opera Critic is a code review system that might be worth considering for use with Pike development. We got a brief demo of it and it looks promising. Additionally, Opera’s auto build system has some nice features (binary exports, etc) that might be desirable in Pikefarm. As is often mentioned, it would be good to do stable major releases more frequently. A suggestion was made that once every 2 years would be good. The point was made that development can occur in parallel to stabilization without affecting timing. The major reason stable releases don’t get made seems to be due to the dread of generating release notes, though waiting longer between releases makes this a greater real problem. We’d like to rename the 8.1 branch to reflect it’s development status; this should various things easier (by avoiding having to explicitly change branches when a new stable branch is created). ARM Machine Code Arne and Tobi have been working on a machine code generator for 32 bit ARM machines. Currently, only a handful of opcodes have been implemented, but the generator generates working code. In addition to implementing more opcodes, a longer term goal includes support for ARM64. The code has been checked in to git in a feature branch (tobij/arm32) Future roadmap aka the wish list (incomplete, obviously, please send me additional items): - Support for “implements” - Getting more up to date pikes into more distros - the ebuild is kept up to date by grubba - a working rpm spec file was submitted to the rpm forge project, however that project seems to be a zombie: the merge request has been lingering for over 6 months.

1 0

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