Pike-devel

pike-devel@lists.lysator.liu.se

2 participants
3049 discussions

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

09 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

Pike Meet-up 2024-Q2
by Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum 09 Apr '26

09 Apr '26

Hi. At Pike Conference 2017 it was decided that we ought to hold a more informal meeting in Linköping ~ once every quarter. As the 6 month mark from the latest conference is coming up soon, it seems time to announce the second such meeting for 2024: Pike Meet-up 2024-Q2 Date: 2024-05-11 (Sat) Time: 10:00 - afternoon/evening Place: Roxen IS AB Storgatan 46 Linköping Welcome! /grubba

1 5

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

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 01 Mar '26

01 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 28 Feb '26

28 Feb '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

Protocols.HTTP.Query and 100 Continue
by H. William Welliver 13 Jan '26

13 Jan '26

Hello all, I found myself interacting with a HTTP server that returns 100 Continue responses to HTTP POST requests. The pike HTTP client treats those as the final response, but they’re are meant to be considered intermediate responses. I couldn’t figure out if there was a way to get it to continue past that, and it doesn’t look like there is. The standard says a server shouldn’t send them if they aren’t requested, but also says that clients must treat them as informational and carry on. I have a proposed fix, but since that’s a messing with a pretty widely used bit of code, I wanted to get feedback before I start making changes. I don’t know if there are other similar scenarios that this fix doesn’t cover; I’d be happy to hear feedback on that as well. In Protocols.pmod/HTTP.pmod/Query.pike, following this line: int bytes_read = sscanf(headerbuf,"%s%*[ ]%d%*[ ]%s%*[\r]",protocol,status,status_desc); add: // we don't expect continue responses, but we must deal with them, // and treat them as informational if(status == 100) { int q = sizeof(headerbuf); // find the end of the response message, and move past the newlines present. // since the whole request has been sent already, we just have to wait for the response, // if it isn’t already in the buffer. Either way, there should be trailing line endings, // as those were required to be present for us to have gotten this far. while(q < sizeof(buf)) { if(buf[q] == '\n' || buf[q] == 'r') continue; break; } // reset the buffer to the point just past the continue response and start over. buf = buf[q+1..]; // a better approach might be a do-while loop, but this is a bit clearer, // and we shouldn't find ourselves recursing more than once. return ponder_answer(); } I think this affects all versions of pike (certainly 8.x and 9.x). Thanks in advance! Bill

1 0

Generated (precompiled) function names changing
by Magnus Holmgren, Millnet/Lysator/Debian/Mensa ＠ Pike developers forum 07 Jan '26

07 Jan '26

When building both the current stable 8.0 and 9.0.11, *sometimes* the C code gets regenerated from .cmod (by precompile.pike, I guess) and then the macros in src/modules/Gmp/mpq.c change names from f_mpq_* to f_Gmp_mpq_* (and similarly in other modules), which in that case causes compilation to fail because mpq.cmod contains references to some of the generated function names, e.g. f_mpq_get_int(0) in cast(string). Any idea how this is happening and if it's supposed to happen and the function calls should be changed to match?

2 4

Re: Availability of Pike SRPMs for EL8 and newer builds
by H. William Welliver 11 Dec '25

11 Dec '25

So, as usual my time estimates were a bit off. I’ve cleaned my scripts up a little and have posted them here: https://hg.sr.ht/~hww3/pike_rpm_build I use docker and rpmbuild to generate the RPMS, and I have successfully built and tested packages for EL8 and EL9 on amd64 and aarch64. Things don’t build on EL10 for a couple of reasons; I think some work will be required to get things working properly there (a combination of dependencies being renamed/deleted as well as some build errors probably triggered by the latest versions of gcc. I’ve included the non-working EL10 setup in case anyone wants to take a stab at fixing the problems. The use of docker allows us (hopefully) to have a reproducible, pristine build environment, and also allows RPMS to be built from non-linux platforms without needing to have a linux system set up. There are notes in the repo above that describe how to build the docker build images, and then use them to prepare (S)RPMS, as well as the basic steps needed to support new versions of Enterprise Linux. I did notice a minor problem on Oracle Linux 9 with there being odd dependencies that couldn’t be resolved (Java related, mainly and as per the usual).You can ignore them or better yet, break them into a sub-package. I’ll try to make time to upload my builds later today or tomorrow. Comments/questions/suggestions are welcome, as always. Bill > On Dec 6, 2025, at 9:00 PM, Maksim AbuAjamieh <eng.maksim(a)gmail.com> wrote: > > > Hi Bill, > > Thanks so much for the update and for taking the time to clean things up and make them accessible. > > I’ll look forward to the SRPMs whenever you’re ready to share them, but it is perfectly fine if you would prefer to just share what you already have. I really appreciate the effort you are putting into this. > > Best regards, > Maksim > > On Wed, Nov 19, 2025 at 7:41 AM <william(a)welliver.org <mailto:william@welliver.org>> wrote: >> Hi- >> >> That would be my fault... I've always been so focused on the rpms but >> the srpm is an artifact I seem to forget to upload the SRPM. >> >> I have a spec file that's never been checked into version control, as >> well as some scripts that I've used to produce the RPMs available for >> download... Part of the reason it's always languished on my build system >> is that the spec file needs changing for various el releases, and >> there's a separate dependency installation step required to get the >> builds to work. I didn't want a proliferation of files in the pike >> packaging directory. I will try to clean those up a bit and put them >> somewhere publicly accessible. >> >> Note: pike doesn't seem to build properly on el10, I suspect due to the >> version of gcc in use. The fix is a one-liner, but a patch is necessary >> until a new release is made. >> >> Stand by for an update on this, probably in a day or two. >> >> Best, >> >> Bill

1 0

Jump to page:

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