Pike-devel September 2014

pike-devel@lists.lysator.liu.se

9 participants
29 discussions

Re: Playing music using pike and SDL.
by Martin Nilsson (lvl 60) ＠ Pike (-) developers forum 03 Dec '25

03 Dec '25

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

3 2

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

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

28 Sep '14

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. 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? ChrisA

2 1

Editing the Pike tutorial - where is it?
by Chris Angelico 21 Sep '14

21 Sep '14

The tutorial at http://pike.lysator.liu.se/docs/tutorial/ is a bit out of date, and its header comment says that it "will be updated ASAP". I'd like to fix some of it up (most notably the GTK bits; someone was asking me about them, as they're all GTK1 and don't work with GTK2), but can't find the source files in the main Pike tree. Poking around with the code librarian didn't show me anything, though I may have missed something. Where is the tutorial rendered from? ChrisA

2 2

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