Pike-devel October 2021

pike-devel@lists.lysator.liu.se

3 participants
7 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

New Pike 8.0 release?
by william＠welliver.org 10 Nov '21

10 Nov '21

It's been about a year since the last release, and I've found a number of configure problems on "apple silicon". How about we start the process of a new 8.0 release? Perhaps starting 2 weeks from today? If there are no objections, I'll start cutting release candidates at that point. I'll send a reminder when about a week is left. Bill

3 2

Re: New Pike 8.0 release?
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 28 Oct '21

28 Oct '21

Ah, ok, in 8.0.1116 you mean. Then I understand and completely agree. :-)

1 0

Pike Meet-up 2018-Q1
by Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum 20 Oct '21

20 Oct '21

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 three month mark from the conference is coming up soon, it seems time to announce the first such meeting for 2018: Pike Meet-up 2018-Q1 Date: 2018-02-03 (Sat) Time: 10:00 - afternoon/evening Place: Roxen IS AB S:t Larsgatan 22A Linköping Welcome! /grubba

2 13

Re: What are the consequences of adding a subtype?
by Chris Angelico 20 Oct '21

20 Oct '21

On Wed, Oct 20, 2021 at 8:44 PM Henrik Grubbström (Lysator) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > Not quite correct; normal ones are 0..USHRT_MAX-1 and builtin > functions are USHRT_MAX. The subtype is used to select the > function entry in the function table for the object. Ahh gotcha. > AFAIR the generator function gets the suffix "\0generator" appended > to its function name, but I'm uncertain whether this is visible at > the Pike code level. It technically is, if you sprintf("%O", f), but that seems a hacky way to recognize generator state functions. It also doesn't recognize generator functions themselves, although that's less important. > There may also be a difference in the value returned by _typeof(). True in a sense, when looking at a specific generator and its state function, but I don't think this can be used to directly recognize them: fibonacci: /main()->fibonacci function( : function(void | mixed, void | function(void | mixed ... : void) : int | zero)) fib: /main()->fibonacci\u0000generator function(void | mixed, void | function(void | mixed ... : void) : int | zero) The use-case is an asynchronous function handler. I've started to write it up here: https://rosuav.github.io/StilleBot/Asynchronicity#asynchronous-functions-wi… The spawn_task callable needs to be able to recognize a Concurrent.Future or a generator state function as things to await, and anything else as things to return. If I could ask for the moon here, I'd also really love to be able to know when a state function has finished, other than calling it again and getting undefined back. That would allow a simple check after getting a value to determine whether the value was yielded or returned: if the state function is now finished, then it was returned, otherwise it was yielded (and we should go back and do more stuff later). At the moment, I have to assume that there's still more to do, and then if I ever get an undefined, I assume that the function is finished. That could conceal bugs. I've been tinkering with trying to create a Function.function_type() function, but so far, it's looking like most of the information is handled at compilation time only. ChrisA

1 0

What are the consequences of adding a subtype?
by Chris Angelico 20 Oct '21

20 Oct '21

Currently functions have two subtypes: normal ones (0) and builtin functions (USHRT_MAX). What would be the implications of adding two more? I propose adding FUNCTION_GENERATOR and FUNCTION_GENSTATE to differentiate continue functions, and the state functions that they return; and also a Pike-callable Function.function_type which will return the corresponding type. Thus: continue int demo() { } Function.function_type(demo) == 1 Function.function_type(demo()) == 2 Alternatively, if this doesn't need to be a subtype, is there a way to recognize them already? I'm poking around, trying to implement this, but I think more information needs to be carried through to runtime - might be wrong though. ChrisA

2 1

Confusing results in continue function - overaggressive optimization?
by Chris Angelico 20 Oct '21

20 Oct '21

continue int fibonacci() { int a = 0, b = 1; while (1) { yield(a += b); yield(b += a); } } int main() { function fib = fibonacci(); while (1) { write("--> %d\n", fib()); sleep(0.125); } } In theory, this should yield a stream of Fibonacci numbers (1, 1, 2, 3, 5, 8, 13, etc). In practice - on Pike 8.1.14 - it yields counting numbers (1, 2, 3, 4, 5, etc). I've tried to defeat the optimization in a few ways but to no avail. The only way to get Fibonacci numbers out of it is to avoid yield altogether: #define yield(x) write("%d\n", x) Any ideas? ChrisA

1 0

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 October 2021