Pike-devel September 2014

pike-devel@lists.lysator.liu.se

9 participants
31 discussions

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

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

xenofarm?
by Stephen R. van den Berg 03 Dec '14

03 Dec '14

Xenofarm seems to have been out of order since a while, correct? -- Stephen.

6 7

debugger opcodes
by Bill Welliver 30 Oct '14

30 Oct '14

I noticed that folks have been working on code generation lately. Any chance it might be possible to implement some of the opcodes required to get debugging working (step, break, etc)? I seem to recall someone indicating it wasn't a terribly difficult task, but it's clearly beyond my understanding of the problem. Bill

4 6

Freeze of Debian 8.0 "jessie"
by Magnus Holmgren, Millnet/Lysator/Debian/Mensa ＠ Pike developers forum 16 Oct '14

16 Oct '14

A reminder since I neglected it the last time: The next release of Debian will be frozen on 5 November 23:59 UTC [1]. Any new versions must make it to testing before that, i.e. be uploaded before 26 October. If you wish to make another stable Pike release and have it be included in jessie, now is the time to start finalizing it. [1] https://release.debian.org/jessie/freeze_policy.html

9 16

Re: Array augmented assignment doesn't always work
by Chris Angelico 30 Sep '14

30 Sep '14

On Wed, Oct 1, 2014 at 2:05 AM, Henrik Grubbström (Lysator) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > No problem, the test program triggered the bug consistently, so it was > easy to find and fix the bug. > > Fixed in current Pike 8.0. > Thanks for that! Confirmed successful. It actually took me a while to make that test program. The failing code was deep inside several levels of indirection, but when I tried to do the same thing manually, I invariably used a string literal instead of a string variable - and then it worked perfectly :) But I'm glad there are these occasional over-optimization bugs. They're part and parcel with a highly optimized interpreter, and that's something I love about Pike. ChrisA

1 0

Array augmented assignment doesn't always work
by Chris Angelico 30 Sep '14

30 Sep '14

Apologies for the non-minimality of the test-case, but this is a smidge weird. The changes made in b2d25e "Compiler: Improved soundness of the op-assign optimizer" seem to have broken this: //Should print ({ }) to stdout and return 0, because the array should end up empty. //This is what happens in 7.8 on Windows. //In the latest 8.0, the first removal fails, so it shows ({ "a" }) and returns 1. array(string) arr=({"a","b","c"}); int main() { add_constant("G",this); compile_string("void x() {string z=\"a\"; G->arr-=({z});}")()->x(); compile_string("void x() {string z=\"b\"; G->arr=G->arr-({z});}")()->x(); compile_string("void x() {G->arr-=({\"c\"});}")()->x(); write("%O\n",arr); return sizeof(arr); } In theory, the three forms of element removal ought to be equivalent, but the first one doesn't seem to be functional. I'm afraid the details are a bit beyond me - the optimizer isn't something I'm familiar with. All I know is, bisection points to that commit, and reverting it on top of 8.0 makes the above script work correctly. Sorry for the vagueness. ChrisA

2 1

Re: Program.all_inherits needs documentation... or a better spec
by Chris Angelico 28 Sep '14

28 Sep '14

On Mon, Sep 29, 2014 at 3:35 AM, Henrik Grubbström (Lysator) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: >>Program.all_inherits has a FIXME asking for docs. But its definition >>is a little odd: it returns a list of the given program's inherits, >>and everything they inherit - but not recursively. > > Not quite... Take a closer look at the loop -- It isn't a foreach()... > >>I could document it as such, but it strikes me that this should be >>recursive, similar to inherit_tree but returning a flat array. Example >>implementation in branch rosuav/pgm_all_inherits - what do you think? > > No need for a new implementation; the current already does it. Oohhhhh...... right. I looked at it and misread it as a manually-implemented foreach. Okay. In that case, I'll document it as-is, but also add an explanatory comment for the benefit of the next person. ChrisA

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