Pike-devel March 2026

pike-devel@lists.lysator.liu.se

5 participants
6 discussions

gobject introspection
by Lance Dillon 24 Mar '26

24 Mar '26

Someone, I think rosuav (Chris Angelico), did a branch with gobject introspection, but I can't remember it, and none of the branches in git branch -ar seem like it is, at least the names don't seem like it: origin/rosuav/async-annotations origin/rosuav/deoptimize-continue-return origin/rosuav/enable-werror origin/rosuav/gtk2-drag-drop origin/rosuav/happy-eyeballs origin/rosuav/hilfe-improvements origin/rosuav/http-multi-connect origin/rosuav/inotify-config origin/rosuav/latex-markdown-renderer origin/rosuav/markdown-attribute-syntax origin/rosuav/markdown-parser-extensibility origin/rosuav/naglingcontrol origin/rosuav/pango_xy_to_char origin/rosuav/pgsql-ssl origin/rosuav/pre-listening-ports origin/rosuav/process-check-run origin/rosuav/sockopt origin/rosuav/support-gdk-quartz unless it is support-gdk-quartz. Would someone be able to point me to it? I want to do some testing... Thanks

2 1

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

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

13 Mar '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) >

3 2

Re: Availability of Pike SRPMs for EL8 and newer builds
by H. William Welliver 10 Mar '26

10 Mar '26

(Forgot to include the list on my original reply to Maksim) That’s great! If you’ve identified things that need to be fixed in the pike source to get things running with GCC 14 (13 is the highest I’m using anywhere), I think we’d love to get patches or a description. That’s something I can assist with getting into the pike tree. I did experience the annoyance of package names moving around between versions, but it was fairly minor so didn’t come up with a huge plan for dealing with it. JDK was definitely the thorniest problem for me (as it was getting Java support working when I did pkgsrc packages). And GTK2 is going to be a problem going forward; I don’t see much way around it, unless there’s a repo somewhere that makes packages for unloved legacy components, or the pike world decides to make their own. I think we (well, I at least) would definitely be interested in seeing what you end up with. There’s an opportunity also to include whatever repos you post as members of the pike language org on GitHub, so that it gets a little visibility as a piece of the puzzle. In a perfect world, pike would be easily available from EL based distros, but being the niche language it is, that’s probably not going to happen, though Debian has it, so maybe not such a dream. At the very least, being able to build good well-thought-out RPMs enables the rest. Am happy to help as I am able! Best, Bill > On Mar 10, 2026, at 7:15 AM, Maksim AbuAjamieh <eng.maksim(a)gmail.com> wrote: > > Thanks for posting the scripts - the Docker-based approach is exactly the right way to handle reproducible RPM builds, and it's great to have a reference implementation to build on. > > I have worked on it and managed to get RPMs for EL9 and EL10 with some effort. > > A few things that may be of interest: > > EL10 support - I did manage to get EL10 building successfully. But yeah it takes some work: GCC 14's stricter implicit function declaration handling breaks several modules, and a handful of dependencies have been renamed (notably mysql-devel → mariadb-connector-c-devel, pcre-devel → pcre2-devel, and crypt() moving out of glibc into libxcrypt). > > I also had to disable the GTK2 module entirely on EL10 as I didn’t want to spend too much time figuring out what the problem was. > > The Java dependency problem on EL9 - I hit exactly this. The Java 8 JDK bundles its own internal libzip.so (with an unversioned soname), which rpmbuild's auto-dependency scanner picks up from the Java module and generates a Requires: libzip.so()(64bit) that can't be satisfied by the system libzip package (which ships as libzip.so.5). The fix was to suppress that auto-generated dependency - the JDK itself satisfies it at runtime. > > On EL10 with Java 21 the situation is different and an explicit Requires: libzip is the right approach there. Breaking it into a subpackage (as was suggested) is indeed the cleanest way to handle it, which is what I did. > > Comments and suggestions are welcome. Happy to publish my work on GitHub if it is useful to anyone. > > Thanks again, > Maksim

1 0

Debugger (really, this time)
by H. William Welliver 02 Mar '26

02 Mar '26

Hi all- I noticed that Pike 9.0 is in a beta release situation (I’m not sure how I missed that!), and I was wondering if there was still time and/or interest in getting the pike debugging functionality that a few of us have worked on merged before the final release. I know I said I’d do this more than once, but I’ll make it happen this time, if there isn’t any objection. This consists of: Some C-level modifications to allow stepping, built on top of some features that Grubba built specifically for this purpose (getting access to locals, etc from within the debugger core) Pike code that implements the Debug Adapter Protocol (DAP), as well as most of the higher level debugging functionality (step into, over, etc). Some modifications to master.pike that allows the DAP server to start up and (optionally) hold the interpreter in a wait state until a debugging client connects. I think the highest risk code exists in the C code (as is usual); the pike level code doesn’t get used if debugging isn’t occurring. A few years ago, I wrote some detail about how it would be used in practice, as well as potential limitations, in case anyone is interested, see below. It seems that the LSP server in development plus DAP support would make a very useful development duo. Any comments and suggestions are welcome! Bill https://wiki.gotpike.org/PikeDevel/PikeDebugger and https://hg.sr.ht/~hww3/vscode-debugger-pike

1 0

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

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 March 2026