Pike-devel

pike-devel@lists.lysator.liu.se

3041 discussions

Comments/thoughts requested: Generators and async functions in Pike
by Chris Angelico 26 Aug '19

26 Aug '19

Pike now (8.1) has a decent promise/future subsystem. It's always had great handling of multiple asynchronous operations (GUI, socket, time delay, etc) with the convenience of just returning -1 from main. Interested in people's opinions on whether it would be of value to introduce generators and (built on them) asynchronous functions. I'm borrowing terminology heavily from Python and ECMAScript here, and both of them have drawn from prior art. A *generator function* is a function that can be partially run, then set aside until resumed. Effectively, its stack frame can be encapsulated in an object for future use. It would look something like this: int get_numbers() { write("Starting\n"); yield 1; write("Continuing\n"); yield 2; write("Finishing\n"); return 3; } Calling get_numbers would prepare an execution context, but not actually begin running the function at all. The caller would get back a *generator object*. Asking this generator object to produce its next value would begin executing the function, triggering the call to write, and would stop at the first yield point, returning that value (1). Asking for another value resumes the function, triggering the second write, and returns the next yielded value. The third time you request a value, it would run the function to completion, and report that it returned (not yielded) 3. (The types yielded don't have to match the type of the return value. I'm not sure if there's a good way to declare the yielded types, or if it's best to just assume 'mixed'.) A generator object would be an Iterator, allowing you to loop over the yielded values easily: foreach (get_numbers() ;; int num) The 'yield' keyword would be an expression/operator, allowing you to send a value back into the generator function as the result of the yield expression. The awesomeness of this becomes more apparent when combined with Concurrent.Future objects. An asynchronous function would be a generator which yields Futures until it is ready to return a value. Calling such a function automatically returns a ready-to-go Future, set up such that it is automatically transform_with'd the next yielded Future, or transform'd into the returned value. It would be used somewhat thus: void show_channel_info(string name) { int id = yield get_channel_id(name); mapping data = yield query_channel(id); write("Status: %s\n", data->status); mapping stream = yield get_stream_info(id); if (stream) write("%s is online, %s\n", name, stream->uptime); else write("%s is offline.\n", name); } This is WAY more readable than the equivalent with a bunch of lambda functions to capture the intermediate values. Thoughts? Concerns? Questions? ChrisA

3 3

Re: SSL cert for pike.lysator.liu.se has expired
by Chris Angelico 23 Aug '19

23 Aug '19

On Fri, Aug 23, 2019 at 11:59 PM Peter Bortas @ Pike developers forum <10353(a)lyskom.lysator.liu.se> wrote: > > I guess that's me. Fixed. Thanks! I was doing some Pike coding on live-stream today and one of my viewers mentioned it. Appreciate the quick fix! ChisA

1 0

SSL cert for pike.lysator.liu.se has expired
by Chris Angelico 23 Aug '19

23 Aug '19

Going to https://pike.lysator.liu.se/ shows a big warning about the certificate having expired. Who's in charge of this? ChrisA

2 1

Broken online documentation
by Tomasz Jamroszczak 02 Aug '19

02 Aug '19

When I look for for "Timer" in the "Site search" box on http://pike.lysator.liu.se/generated/manual/modref/ex/predef_3A_3A/System.h… page, I can see link to System.Timer http://pike.lysator.liu.se/generated/manual/modref/ex/predef_3A_3A/System/T… but it returns HTTP 404. Best Regards, Tomasz Jamroszczak

1 0

Errors in the docs
by Stephen R. van den Berg 24 Jul '19

24 Jul '19

There currently are two errors in the docs: - src/post_modules/_Sass/module.pmod.in: Web.Sass.Compiler ends up in _Sass.Compiler in the docs. - And this: --post-process autodoc.xml doc_build ProcessXML: Duplicate documentation for class CompilerEnvironment Reading template file structure/modref.html... Splitting to destination directory modref... Circular inherit in predef::CompilerEnvironment. Circular inherit in predef::CompilerEnvironment. -- Stephen.

2 1

Re: Pike Meet-up 2019-Q3
by Mateusz Krawczuk 19 Jul '19

19 Jul '19

Any chance to move it further towards the end of August? I'm away on 4th. 17th, or 24th maybe? pt., 19 lip 2019 o 14:22 Henrik Grubbström (Lysator) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> napisał(a): > > 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 > nine month mark from the latest conference is coming up soon, > it seems time to announce the third such meeting for 2019: > > Pike Meet-up 2019-Q3 > Date: 2018-08-04 (Sun) > Time: 10:00 - afternoon/evening > Place: Roxen IS AB > S:t Larsgatan 22A > Linköping > > Note that this time the meeting is on a Sunday. > > Welcome! > > /grubba

2 1

Example how to use Protocols.HTTP2 ?
by Stephen R. van den Berg 03 Jul '19

03 Jul '19

Does anyone have any sample code that demonstrates how to use Protocols.HTTP2 ? -- Stephen.

2 1

Re: Hyperscan regexp engine
by Tomasz Jamroszczak 28 Jun '19

28 Jun '19

On Thu, 27 Jun 2019 17:39:01 +0200, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > You can still want things which do not exist. :-) But given the > attitude of the author I don't expect I'll be wanting either that or > hyperscan. If _you_ want something which is only of interest to > "network [companies] looking to scan 5,000 complex regexes in > streaming mode" (who does that?), feel free to integrate it, but keep > it on Monger please. OK, I see your standing. There are two clarifications needed though. First, "the author" of Hyperscan is not only Geoff Langdale, but quite a big team. Second, the library is useful not only for network security hardware. It's used by GitHub (https://github.blog/2018-10-17-behind-the-scenes-of-github-token-scanning/) and in general is just faster than current regexp engines' state of art. Top view of constraints and areas of improvements is described on https://www.hyperscan.io/2015/10/20/match-regular-expressions/. br, tj.

1 0

Re: Hyperscan regexp engine
by Tomasz Jamroszczak 27 Jun '19

27 Jun '19

On Thu, 27 Jun 2019 15:59:01 +0200, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > So I interpret this as "ure3" (whatever that is) being the thing we > actually want, not this garbage fire? On https://branchfree.org/2019/02/28/paper-hyperscan-a-fast-multi-pattern-rege… the author in the commets writes on March 27, 2019: """ I would like “ure3” to be open. I also will need help. I designed Hyperscan but did not build it all by myself; [...] If I build a new regex matching system it will be a lot smaller and simpler, but it will still be a huge effort. """ And on April 15, 2019: """ if I get to it. """ So well, given the fact that the "ure3" doesn't exist, I doubt it is something we should or even could want. br, tj.

2 1

Re: Hyperscan regexp engine
by Tomasz Jamroszczak 27 Jun '19

27 Jun '19

On Thu, 27 Jun 2019 13:58:02 +0200, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: >> /paper-hyperscan-a-fast-multi-pattern-regex-matcher-for-modern-cpus/ > > For modern CPU:s? Looks more like they are targeting a certain 1970:s > architecture: > > cpuid(1, 0, &eax, &ebx, &ecx, &edx); > > Did you test it on RISC-V? From https://news.ycombinator.com/item?id=19270199: """ I suppose "Some Modern CPUs" was too long-winded a title? As I said, it doesn't take a genius to understand Intel's motivations. They bought the project, after all. Not being @ Intel anymore, I don't have access to the older stuff, and even if I did, the codebase has diverged significantly since. Without going on too much of a tirade - the experience of developing for all those platforms really sucked. Almost all the non-x86 platforms had significant bugs in their toolchains. One of the MIPS variants (particular architecture elided to spare the guilty) had bugs in their gcc intrinsics in a way that suggested that no-one had ever done any significant third-party dev on the platform. Big-endian was also a huge PITA. It was a ton of work to keep all those systems alive, and our machine rack looked like a zoo of dev boards and weirdo devices. In the "ure3" system I mention, I would make retargetability/portability to other systems a first-class goal. One way of achieving this is not having such a huge profusion of methods and complexity. Hyperscan is over-engineered for many use cases if you aren't a network company looking to scan 5,000 complex regexes in streaming mode at hopefully maximal performance. """ > Also: 114 kLOC for a regexp matcher. Srsly? For a 40x speed boost? Worth at least trying. BR, tj

2 2

Jump to page:

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