Pike-devel

pike-devel@lists.lysator.liu.se

3 participants
3059 discussions

Java module
by H. William Welliver 03 Jul '26

03 Jul '26

Somewhat related to my previous message, I’ve been struggling with getting the Java module to compile. I don’t think this has anything to do with Pike, and rather is related to the techniques that pkgsrc uses to ensure there’s no leakage from the surrounding environment into the build environment. That and the fact that Java has its own mini-hierarchy of libs that are related to embedding Java. This isn’t a new problem, and has in fact been something I’ve struggled with for years. I’m wondering if there are folks that commonly use this module and thus it is something I should try to sort out, or if I should just tell anyone who asks to “compile it yourself”. I can confirm that a “pike -x module” in the Java module directory builds just fine if JAVA_HOME is set, so the problem is mostly about being able to provide a binary package of the Java support. Happy to hear feedback on the subject either way. Bill

3 5

Process.run() after fork() fails on Pike 9.0
by H. William Welliver 02 Jul '26

02 Jul '26

Hi all, While working on getting some code ready for Pike 9, I ran into what seems to be a regression: when forking a process into the background, Process.run() called in the child process seems to hang. I was able to confirm this behavior on macOS and illumos, so I don’t think it’s platform specific. I’ve attached a fairly minimal test case that demonstrates the problem: data should be written to the log file each second but the initial call to Process.run() never returns and so only the very first log message is generated. I’ve confirmed that Pike 8 does not have this behavior. I’m hoping that someone more familiar with the Process module will have an idea of what’s going on. Thanks in advance! https://paste.sr.ht/~hww3/504e8244449110b5646f0267a5c0cb7e1b154206

2 4

Install glitch with fakeroots
by H. William Welliver 02 Jul '26

02 Jul '26

I’ve been working on updating the pkgsrc package for pike8.0 and ran into a problem (that I think I’ve seen before). The installation process uses a fake root to install pike into a temporary location before packaging that directory up. The problem occurs when pike is already installed into the destination location (minus the fake root). So, the prefix might be /opt/local, and the fake installation root might be /tmp/pkgsrc/.dest/, with files being installed into /tmp/pkgsrc/.dest/opt/local/…. The problem seems to be that in bin/install.pike, fix_smartlink() is called to prep and install a few files like specs and friends. fix_smartlink() then calls compare_to_file() to make sure a duplicate file isn’t being written, but it doesn’t apply the fake root prefix, so it sees the file already installed in the real install location and as a result skips writing the file into the temporary packaging directory. Then some minor mayhem ensues and the packaging process fails. I suspect this isn’t pkgsrc specific, though other packaging systems might use other approaches that avoid this problem (maybe a chroot somewhere)? I _think_ this is a minor oversight and that changing if(compare_to_file(data, dest)) { To if(compare_to_file(data, fakeroot(dest))) { Will fix the problem without negative side effects. However, I’d like to get the okay before I make that change. Any thoughts? Thanks in advance! Bill

1 0

Build question gmp and Odbc
by H. William Welliver 27 Jun '26

27 Jun '26

Hi all- I’ve been spending some time getting pike running on some newer platforms I have here and have run into a few minor problems that I’d like to get feedback on. The first is on some platforms (Darwin and SunOS so far), Odbc fails to build because it needs to be linked with gmp. I notice that the LIBS being passed into the configure script doesn’t contain -lgmp; what’s the appropriate fix here? Should I just test for the gmp library in the Odbc configure script, or is there a more proper approach? Thanks in advance for the advice! Bill

1 0

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

18 May '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

2 8

Pike 9.0.11 (beta 3) released.
by Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum 09 May '26

09 May '26

The above is now available for download from the Pike site. Please test and enjoy. /grubba

1 1

Re: Slow promise awaiting when large amounts of data transmitted
by Chris Angelico 07 May '26

07 May '26

On Wed, 6 May 2026 at 18:07, Henrik Grubbström (Lysator) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > > > > I wonder if it would be reasonable to have a cut-down backtrace > > > display that doesn't show the contents of mappings or arrays, so the > > > function arguments would be shown as some_function(([...])) instead of > > > the full details. That still would keep the most relevant parts of the > > > traceback, and could retain strings and numbers, but would prevent > > > unbounded growth. > > > > Yes, that would solve the main issue. > > Try now. > Hmm. It's definitely made the change, and yet something's still slow. Welp. I guess it's time for me to make a cut-down demonstration case so we can figure this out. Will report back once I've made a version of my Twitch bot where it doesn't need a database or anything but still has the problem. ChrisA

1 3

Re: Slow promise awaiting when large amounts of data transmitted
by Chris Angelico 06 May '26

06 May '26

On Mon, 4 May 2026 at 18:16, Henrik Grubbström (Lysator) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > > Could the Promise retain the backtrace as an array of frames, rather > > than describing it immediately and retaining the string? That is also > > fast (since most of the time it doesn't need to display anything), but > > will still produce equivalent output. Or would that result in a > > reference loop? > > The reason for the backtrace being saved as a string is indeed to > avoid reference issues. One possibility could be to truncate the > backtrace to just a few frames. > I wonder if it would be reasonable to have a cut-down backtrace display that doesn't show the contents of mappings or arrays, so the function arguments would be shown as some_function(([...])) instead of the full details. That still would keep the most relevant parts of the traceback, and could retain strings and numbers, but would prevent unbounded growth. ChrisA

2 2

Re: Slow promise awaiting when large amounts of data transmitted
by Chris Angelico 04 May '26

04 May '26

On Mon, 4 May 2026 at 16:30, Henrik Grubbström (Lysator) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > > > Having a large blob of data returned from an await() results in all > > subsequent awaits to slow down. Example: > > > > __async__ void reconnect() { > > mapping commands = await(load_commands()); //Returns a big array > > //werror("This should be a one: %O\n", > > await(Concurrent.resolve(1))); //Returns just an integer > > foreach (commands; string uuid; mapping data) do_stuff_with(uuid, data); > > } > > Wow! Somebody (other than me) is already using __async__ and await()! I sure am! I love it and use it in all my projects now, pretty much. My main Twitch bot (Mustard Mine) switched over to that back when they were "continue functions" and without a moment's hesitation I moved to proper async/await. > Concurrent.Promise et al should be agnostic with respect to the size > of data that is passed. As you have noted though, due to it saving > the backtrace at time of creation, the size of the backtrace will > affect timing. > > > If do_stuff_with() involves multiple promises/awaits, each one has a > > notional backtrace involving the entire large array. The inclusion of > > the dummy resolve(1) changes this so that the earlier call in the > > backtrace is much smaller. > > Try disabling the orig_backtrace handling (eg initialize it to "" > instead of the backtrace) in Concurrent.pmod, and see if it solves > your issue. Yes, hacking that out does prevent the problem. > > I'm not sure what changed recently, but when I upgraded Pike, this > > started to be slow. However, Concurrent.pmod doesn't seem to have > > changed recently, so I'm not sure what the cause is. (It's also > > possible an unrelated change of my own triggered this.) > > One easy way to reduce the backtrace size is to wrap the large value > in an object when passing it as an argument. I could do that. I'd have to figure out how much of a nuisance that'd be API-wise, since I don't know how much of a problem it's going to be. Notably, this is only really a problem when there are a *lot* of promise backtraces being generated (the code I posted above is simplified, but there's several layers of iteration and calls - this is loading roughly a hundred channel's worth of data, then for each channel, going and setting things up). > > Promises currently seem to retain a text backtrace. I'm not sure if > > that's relevant or not, as it has always been there, but it may be > > connected. > > They have been there for quite a while, albeit they were not enabled > by default initially. They were enabled by default as they were so > useful when debugging problematic Promises. > Ah, interesting. I thought that change happened years ago though, so I didn't think that was the cause. Could the Promise retain the backtrace as an array of frames, rather than describing it immediately and retaining the string? That is also fast (since most of the time it doesn't need to display anything), but will still produce equivalent output. Or would that result in a reference loop? ChrisA

3 3

Slow promise awaiting when large amounts of data transmitted
by Chris Angelico 04 May '26

04 May '26

Having a large blob of data returned from an await() results in all subsequent awaits to slow down. Example: __async__ void reconnect() { mapping commands = await(load_commands()); //Returns a big array //werror("This should be a one: %O\n", await(Concurrent.resolve(1))); //Returns just an integer foreach (commands; string uuid; mapping data) do_stuff_with(uuid, data); } If do_stuff_with() involves multiple promises/awaits, each one has a notional backtrace involving the entire large array. The inclusion of the dummy resolve(1) changes this so that the earlier call in the backtrace is much smaller. I'm not sure what changed recently, but when I upgraded Pike, this started to be slow. However, Concurrent.pmod doesn't seem to have changed recently, so I'm not sure what the cause is. (It's also possible an unrelated change of my own triggered this.) Promises currently seem to retain a text backtrace. I'm not sure if that's relevant or not, as it has always been there, but it may be connected. Any ideas what's going on here? ChrisA

2 1

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