Pike-devel

pike-devel@lists.lysator.liu.se

1 participants
3041 discussions

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 19 Oct '21

19 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

Segfault from Pike 8.1 - possible type check issue?
by Chris Angelico 06 Sep '21

06 Sep '21

float thing_sum(array(string) things) { return `+(@(array(float))things) + 1.0; } Without the "+ 1.0" at the end (or some other arithmetic operation), it doesn't bomb out. GDB is pointing to src/pike_types.cmod:11185 which is just an assignment, but I suspect the issue is the add_ref above it. Unfortunately that line gets hit a LOT, so I didn't get very far with debugging. ChrisA

1 0

Bleeding-edge Pike broadly operable - code review appreciated
by Chris Angelico 25 Aug '21

25 Aug '21

I just pushed a few changes to master that get the build working (on 64-bit Debian Linux, no other platforms tested). They're mostly small changes and I hope they won't break anything. This actually gets "make doc" happy again after a good while, so it would be really awesome if I haven't just broken something unrelated :) There's another, more significant, change that happened in the past few months. It's not a simple fix. The default behaviour of Protocols.DNS.async_host_to_ip, which is used by Protocols.HTTP, changed from "only look up A records" to "look up AAAA and A records, and return the first AAAA if found, otherwise the first A". Unfortunately everything is built to assume that there's at most one IP address for that host name. The ultimate solution would be to have an asynchronous "establish connection" call, which will do an async DNS lookup, then attempt to connect to each IP in turn until one succeeds. That would require some other changes, and I'm not sure how it would interact with HTTP keep-alive, for instance. As a lesser solution, would it be reasonable to have a method like Protocols.DNS.prefer_ipv4() to invert the return order of DNS records? ChrisA

4 12

Type checking segfault in Pike 8.1
by Chris Angelico 27 Jun '21

27 Jun '21

void boom(mapping info) {m_delete(info[0]);} It ought to give a compilation error (not enough args to m_delete) but it segfaults the interpreter on compilation. Correct behaviour is restored if the argument is explicitly cast to mapping: void boom(mapping info) {m_delete((mapping)info[0]);} boom.pike:1:Too few arguments to m_delete (got 1). boom.pike:1:Expected: mixed. boom.pike:1:Function type: boom.pike:1:Got : scope(0,function(object, mixed : mixed) | function(mapping((0=mixed):(1=mixed)), 0 : 1) | function(multiset((0=mixed)), 0 : int(1bit))). Pike: Failed to compile script. The crash happens in src/pike_ctypes.cmod, get_first_arg_type, in the T_MANY case - fun_type->car is NULL. ChrisA

1 0

Re: Bleeding-edge Pike broadly operable - code review appreciated
by Chris Angelico 09 Jun '21

09 Jun '21

On Thu, Jun 10, 2021 at 11:49 AM Martin Nilsson (Coppermist) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > > > > >Okay. Here's a proposal: > > > >1) Have a Protocols.DNS.prefer_ipv6() that chooses whether IPv6 is > >preferred over IPv4 for simple lookups. Calling prefer_ipv6(1) will > >result in the current behaviour, calling prefer_ipv6(0) will return to > >previous behaviour. This just changes the order of responses, nothing > >else. > > No, add new methods for new behavior. The old function continues to > return IPv4 and the new one does IPv6+IPv4. Or have some new parameter > to control preference on a per call basis. We don't want global states > in modules. Trouble with that is that it'd need to be carried through as part of the API for everything that uses it. So Protocols.HTTP.Query would need to have something to control which one it prefers, and Protocols.HTTP.get_url would need to have something to set that parameter, etc. But maybe that won't matter, if the other parts of the plan are worth doing. ChrisA

1 0

← Newer
1
2
3
4
5
6
7
8
9
...
305
Older →

Jump to page:

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