Re: Understand the behaviour of Stdio.Buffer()->match()

On Wed, 8 May 2024 at 17:57, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum <10...@lyskom.lysator.liu.se> wrote: > > Yes, although I'm still not sure this follows the principle of least > astonishment: > > If no matches results in "", and the result is the sum of the

Re: Understand the behaviour of Stdio.Buffer()->match()

On Wed, 8 May 2024 at 17:04, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum <10...@lyskom.lysator.liu.se> wrote: > > The behaviour of match() when there is not exactly one thing matching > seems a bit weird in general: > > Pike v9.0 release 2 running Hilfe v3.5 (Incremental

Re: Understand the behaviour of Stdio.Buffer()->match()

On Wed, 8 May 2024 at 16:28, Henrik Grubbström (Lysator) @ Pike (-) developers forum <10...@lyskom.lysator.liu.se> wrote: > Thanks for the report. > > Fixed in Pike master. match() now returns "" in this case. Ah! Thank you! ChrisA

Re: Running an HTTP(S) server using an externally-provided file descriptor

On Thu, 2 May 2024 at 19:15, Henrik Grubbström (Lysator) @ Pike (-) developers forum <10...@lyskom.lysator.liu.se> wrote: > > Hi again Chris. > > > On Thu, 2 May 2024 at 17:58, Henrik Grubbström (Lysator) @ Pike (-) > > developers forum <10...@lyskom.lysator.liu.se> wrote: > > > > > > Does

Re: Running an HTTP(S) server using an externally-provided file descriptor

On Thu, 2 May 2024 at 17:58, Henrik Grubbström (Lysator) @ Pike (-) developers forum <10...@lyskom.lysator.liu.se> wrote: > > Hi Chris. > > > See branch rosuav/pre-listening-ports for a first attempt at this. > > > > With Stdio.Port(), it's possible to receive an open socket as a file > >

Running an HTTP(S) server using an externally-provided file descriptor

See branch rosuav/pre-listening-ports for a first attempt at this. With Stdio.Port(), it's possible to receive an open socket as a file descriptor and start accepting connections on it. (Notably, this allows systemd to provide a socket as FD 3, allowing unprivileged programs to listen on

Understand the behaviour of Stdio.Buffer()->match()

I'm a bit confused by this behaviour, and am unsure whether it needs to be better documented, or perhaps is a bug. int main() { object buf = Stdio.Buffer("#44"); write("Matches: %O %O\n", buf->sscanf("#%2[4]"), (string)buf); buf = Stdio.Buffer("#4"); write("Doesn't: %O %O\n",

Re: File descriptor usage in Protocols.HTTP.Server.SSLPort

On Fri, 5 Apr 2024 at 23:59, Henrik Grubbström (Lysator) @ Pike (-) developers forum <10...@lyskom.lysator.liu.se> wrote: > > Is there a better way to handle this than simply forcing garbage > > collection every request? > > The best way is to break the cycle before dropping the object on the >

File descriptor usage in Protocols.HTTP.Server.SSLPort

I've run into a strangeness with my TLS-based web server. It seems that, for every incoming request, three file descriptors are used (they all seem to be sockets), and they aren't immediately cleaned up. With keep-alive disabled, they CAN be disposed of, but it takes an explicit gc() call. With

Re: Pure Pike annotations?

On Fri, 16 Feb 2024 at 03:09, wrote: > > Hi Chris- > > You might also find some helpful information here: > > http://wiki.gotpike.org/PikeDevel/Annotations > > There are one or two missing features in annotations, one of which is (I > think) the lack of ability to add an annotation to a top level

Re: Pure Pike annotations?

On Thu, 15 Feb 2024 at 23:39, Henrik Grubbström (Lysator) @ Pike (-) developers forum <10...@lyskom.lysator.liu.se> wrote: > > I'm trying to make good use of annotations, but all the existing ones > > are in cmod files, and I'm trying to work out how best to write them > > in Pike. My goal is to

Pure Pike annotations?

(Side note: This mailing list seems very dead lately. Is the LysKOM gateway down?) I'm trying to make good use of annotations, but all the existing ones are in cmod files, and I'm trying to work out how best to write them in Pike. My goal is to have an annotation that can be parameterized,

Debian Pike packaging and GTK2

The latest releases of Debian don't include a pike8.0-gtk package any more. Apparently it's because it depends on old libraries: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885673 But all of those are optional dependencies. I just tested a fresh Debian 12 installation and was able to build

Re: Client certificate support in Sql.pgsql?

On Sat, 9 Dec 2023 at 04:06, wrote: > I'm pretty sure that SSL.File should be able to handshake in callback > mode. Shuffler however, is a complication that can break the facade that > SSL.File is just another Stdio.File object... I've definitely used > shuffler with SSL.File objects in

Re: Client certificate support in Sql.pgsql?

On Sat, 9 Dec 2023 at 04:06, wrote: > I'm not familiar with how the pgsql module is set up, so there > may be some magic going on that needs to be worked around. If you're > trying to attempt some sort of conditional TLS ala STARTTLS, you might > find that handshaking doesn't work until the

Re: Client certificate support in Sql.pgsql?

On Sat, 9 Dec 2023 at 03:57, wrote: > > > > > Hmm. Maybe I should polish the two scripts I was using, and then put > > them into the SSL module somewhere as examples. There are quite a few > > subtleties (like that you won't see client certs unless you set > > "ctx->auth_level =

Re: Client certificate support in Sql.pgsql?

On Fri, 8 Dec 2023 at 20:17, Stephen R. van den Berg wrote: > > Chris Angelico wrote: > >3. It's surprisingly hard to find tools that can help you debug client > >certificates. > > It's a mess. It has been a mess for a long time. > The few times I tried to use somethin

Re: Client certificate support in Sql.pgsql?

On Fri, 8 Dec 2023 at 19:39, Stephen R. van den Berg wrote: > > Chris Angelico wrote: > >In working on the implementation, I'm running into some trouble with > >SSL connections in general. As of Pike 8.1, the pgsql module uses > >Shuffler (this wasn't the case in Pik

Re: Client certificate support in Sql.pgsql?

On Wed, 6 Dec 2023 at 08:32, Chris Angelico wrote: > > On Wed, 6 Dec 2023 at 05:10, Chris Angelico wrote: > > Sound good? I'll try to put together an implementation, although I'm > > not sure there's a viable way to add tests for it. > > > > In working on t

Re: Client certificate support in Sql.pgsql?

On Wed, 6 Dec 2023 at 05:10, Chris Angelico wrote: > Sound good? I'll try to put together an implementation, although I'm > not sure there's a viable way to add tests for it. > In working on the implementation, I'm running into some trouble with SSL connections in general. As of

Re: Client certificate support in Sql.pgsql?

On Wed, 6 Dec 2023 at 04:28, wrote: > > Hi Chris, > > the SSL module supports passing client certificates, and the Sql.pgsql > module uses SSL.File, however it doesn't directly provide any hooks for > configuring the client certs. I think it would be easy to add, basically > you just need a way

Client certificate support in Sql.pgsql?

Is it possible to use client SSL certificates for authentication with the Sql.pgsql or (the deprecated) Sql.postgres driver? I've been setting up a multihomed Pike program and would ideally like to be able to have all nodes connect to the same database, using their SSL certificates as proof of

Type annotating continue functions for asynchronous work

I've been making extensive use of continue functions (generators) using a pattern whereby they will *yield* an awaitable (a Concurrent.Future or a couple of other options), but will *return* a final result (could be any type, eg int, string, mapping, array, etc). This is working fairly nicely,

Re: Pike 9.0 quirk with implicit lambda

On Tue, 31 Oct 2023 at 20:39, <"\"Henrik Grubbström (Lysator) @ Pike (-) developers forum\" <10...@lyskom.lysator.liu.se>"@lysator.liu.se> wrote: > > Hi Chris. > > > In Pike 8 (tested on 8.1.15), the implicit lambda correctly receives > > its __ARGS__, and will happily provide those as closure

Pike 9.0 quirk with implicit lambda

void call(function cb) {cb(42);} int main() { werror("Pike version %O:\n", __VERSION__); call() { werror("Args: %O\n", __ARGS__); mixed value = 1234; werror("%O\n", lambda() {werror("%O\n", value);}); }; return 0; } In Pike 8 (tested on 8.1.15), the

Re: Syntax / Function callbacks

On Tue, 12 Sept 2023 at 01:25, wrote: > > It should do: > https://pike.lysator.liu.se/generated/manual/modref/ex/predef_3A_3A/_Stdio/_port/set_accept_callback.html > > It exists within the documentation…? also Stdio.Port mainsock = > Stdio.Port(, accept_callback) and if

Re: Syntax / Function callbacks

On Tue, 12 Sept 2023 at 01:14, wrote: > > int main() { … mainsock->set_accept_callback(accept_callback); ... } > > Attempt to call the NULL-value > Unknown program: 0(/main()->accept_callback) > main.pike:53: /main()->main() > Looks like it's not a syntax problem, but that there's no

Re: rntcl

On Tue, 1 Aug 2023 at 02:32, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum <10...@lyskom.lysator.liu.se> wrote: > > The thing about rntcl is that it is a cross compiler. The output of > the compiler _is_ "foo.exe", but that binary can not be run on the > build system. So

Re: Protocols.HTTP.Query with open_socket address

On Thu, 9 Jun 2022 at 16:02, David Tàpia wrote: > > It would be appreciated if you could consider add this feature in > Protocols.HTTP.Query > > > //! You may specify an address to bind to if your machine has many IP numbers. > string address = 0; > ... > con = Stdio.File(); >

Re: bufferdAmount or bufferedAmount?

On Fri, Nov 19, 2021 at 10:33 AM ceder (-) Per Cederqvist @ Pike (-) developers forum <10...@lyskom.lysator.liu.se> wrote: > > This code in lib/modules/Protocols.pmod/WebSocket.pmod seems to be > missing an "e": > > //! @decl int bufferedAmount > //! Number of bytes in the send buffer. > >

Re: What are the consequences of adding a subtype?

On Wed, Oct 20, 2021 at 8:44 PM Henrik Grubbström (Lysator) @ Pike (-) developers forum <10...@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

What are the consequences of adding a subtype?

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

Confusing results in continue function - overaggressive optimization?

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

Segfault from Pike 8.1 - possible type check issue?

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

Re: Bleeding-edge Pike broadly operable - code review appreciated

On Thu, Jun 17, 2021 at 8:29 AM Chris Angelico wrote: > > On Thu, Jun 17, 2021 at 7:49 AM Tobias S. Josefowitz > wrote: > > > > On Wed, Jun 16, 2021 at 11:08 PM Chris Angelico wrote: > > > > > > Should host_to_ip be put completely back how it was (IPv

Type checking segfault in Pike 8.1

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]);}

Re: Bleeding-edge Pike broadly operable - code review appreciated

On Thu, Jun 17, 2021 at 7:49 AM Tobias S. Josefowitz wrote: > > On Wed, Jun 16, 2021 at 11:08 PM Chris Angelico wrote: > > > > Should host_to_ip be put completely back how it was (IPv4 only), or > > should it return IPv4 if available, IPv6 else? > > In my opinion

Re: Bleeding-edge Pike broadly operable - code review appreciated

On Thu, Jun 17, 2021 at 6:57 AM Tobias S. Josefowitz wrote: > > On Fri, Jun 11, 2021 at 1:31 PM Chris Angelico wrote: > > > > Branch: rosuav/http-multi-connect > > > > New APIs in Protocols.DNS.async_client - host_to_ips in both callback > > and Promise v

Re: Bleeding-edge Pike broadly operable - code review appreciated

On Thu, Jun 10, 2021 at 6:49 AM Stephen R. van den Berg wrote: > > Chris Angelico wrote: > >> > 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

Re: Bleeding-edge Pike broadly operable - code review appreciated

On Thu, Jun 10, 2021 at 11:49 AM Martin Nilsson (Coppermist) @ Pike (-) developers forum <10...@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

Re: Bleeding-edge Pike broadly operable - code review appreciated

On Thu, Jun 10, 2021 at 8:21 AM Tobias S. Josefowitz wrote: > > On Wed, Jun 9, 2021 at 10:49 PM Stephen R. van den Berg wrote: > > > > I'd say, the way forward should be changing the connecting functions to > > iterate through the IP addresses and find the first that actually connects. > > > >

Re: Bleeding-edge Pike broadly operable - code review appreciated

On Thu, Jun 10, 2021 at 1:41 AM Tobias S. Josefowitz wrote: > > On Wed, Jun 9, 2021 at 3:48 PM Chris Angelico wrote: > > > > There's another, more significant, change that happened in the past > > few months. It's not a simple fix. The default behaviour of > >

Bleeding-edge Pike broadly operable - code review appreciated

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

Re: Replacing a single function/method in an existing live class?

On Mon, May 3, 2021 at 4:25 AM Stephen R. van den Berg wrote: > > Chris Angelico wrote: > >My usual practice is to completely recompile the class, and have a > >single mapping for all "carry-over" state, something like this: > > >And then to replac

Re: Replacing a single function/method in an existing live class?

On Mon, May 3, 2021 at 3:35 AM Stephen R. van den Berg wrote: > > Lance Dillon wrote: > >The closest I could see is to not really have the functions directly, I > >guess, but an mapping of functions, and overload `() so that it pulls the > >function from the mapping, then you could easily

Re: Replacing a single function/method in an existing live class?

On Mon, May 3, 2021 at 2:04 AM Stephen R. van den Berg wrote: > > Say I have this: > > class A { > int k; > void B() { > write("foo %d\n", k); > } > void C() { > k = 3; > write("bar\n"); > } > } > > int main() { > A a = A(); > a->C(); // Displays: bar > a->B();

Re: Pike 8.1 type errors

On Sat, Apr 10, 2021 at 5:20 PM Stephen R. van den Berg wrote: > > The last time I had a bleeding edge "standard" pike that actually > worked for me was: > > commit 94a868dae24642de2e71e0a6079a27aabae32132 I've been doing the same, although my last-known-good is a bit older than yours. Keep

Pike 8.1 segfault compiling unknown name

int main() { //compile("void x(int id) {boom = ({id});}"); compile("void x(int id) {boom += ({id});}"); } The first (commented-out) line will raise a standard exception regarding the unknown name "boom". The second will segfault the interpreter. The crash appears to happen deep inside

Re: Compression.Lz4

On Thu, Apr 1, 2021 at 6:18 PM Stephen R. van den Berg wrote: > > Martin Nilsson (Coppermist) @ Pike (-) developers forum wrote: > >>Compression.Bz2 > >>Compression.Gz > >>Compression.Lz4 > > >If we change location I want them to have the same API so you can > >switch between them easily. Old

Re: Did someone already try to ask someone at Lysator?

On Mon, Mar 15, 2021 at 10:22 PM Henrik Grubbström (Lysator) @ Pike (-) developers forum <10...@lyskom.lysator.liu.se> wrote: > > Hi Stephen! > > > Did someone already try to ask someone at Lysator to push the power button? > > The power button wasn't the problem... > > The problem was due to the

Proposal: Built-ins for generators

A generator function will, when called, return a generator state function. (Are there better terms for these?) It'd be extremely helpful to have a couple of built-in functions to give some info about them. 1) generatorp continue int gen() {continue return 1; return 2;} generatorp(gen) ==> 1

Re: Possible over-optimization with 'continue return'

On Sat, Mar 6, 2021 at 7:59 AM Henrik Grubbström (Lysator) @ Pike (-) developers forum <10...@lyskom.lysator.liu.se> wrote: > > > Playing around with generators, and have come across a strange oddity. > > This code works fine: > [...] > > But remove any of the 'if' guards, and the function

Possible over-optimization with 'continue return'

Playing around with generators, and have come across a strange oddity. This code works fine: continue int gen(int x) { if (x == 1) continue return 1; if (x == 1) continue return 2; if (x == 1) continue return 3; return 4; } int main() { function foo = gen(1); while (1) { int i =

CONCURRENT_DEBUG default state - active or not?

lib/modules/Concurrent.pmod starts out by defining CONCURRENT_DEBUG to the value 0. This counts as defined, for the purposes of storing backtraces and such. Is that meant to be active by default? At the moment, there are a number of werror lines that are quite noisy; not sure whether they're part

Re: Information leakage in httpserver

On Fri, Oct 9, 2020 at 8:17 AM Tobias S. Josefowitz wrote: > > As you may have noticed I took the liberty of applying the proposed > fix recently. Thank you! ChrisA

Information leakage in httpserver

string file = "."+combine_path("/",request->not_query); file = Protocols.HTTP.uri_decode(file); Stdio.Stat s = file_stat( file ); If the not_query contains "..%2F", combine_path sees that as a perfectly normal directory, and then it gets URI decoded, and Pike will happily read files

Re: Pike, WebSockets, and SSL

On Wed, Aug 12, 2020 at 6:40 PM Arne Goedeke wrote: > Sounds like it, yes. Let's fix this on master first and backport it > 'soon'. This way people get a chance to complain. By "soon" do you mean "commit to the 8.0 branch now and have it in the next release"? Because that's what I would normally

Re: Pike, WebSockets, and SSL

On Wed, Aug 12, 2020 at 5:59 PM Arne Goedeke wrote: > > On 2020-08-07 13:49, Chris Angelico wrote: > > Closing an SSL websocket bombs out. SSL sockets can only be closed in > > both directions at once, but websockets send a FRAME_CLOSE and then > > close in

Re: Type checking of exponentiation

On Mon, Aug 10, 2020 at 1:02 AM Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum <10...@lyskom.lysator.liu.se> wrote: > > 4^-2 is not an integer. It's 0.0625 (or 1/16, if expressed as a > fraction, which seems to be what 8.1 has chosen here). True. In the original, though,

Type checking of exponentiation

In order to implement an expression evaluator, I have a two-pass compilation that first uses a magic resolver to find external name references, and then compiles the actual code to get a function back. This cut-down version of it showcases a strange phenomenon: //Magic resolver. Any symbol at all

Pike, WebSockets, and SSL

Closing an SSL websocket bombs out. SSL sockets can only be closed in both directions at once, but websockets send a FRAME_CLOSE and then close in the write direction only. Is it necessary to close in the write direction only, or can the websocket simply close both ends at once? The exception

Recursive typedefs and add_constant

I've run into a weirdness involving a recursive typedef and adding a constant. Example: typedef string|int|array(foo) foo; If compiled on its own, this creates a recursive typedef that can handle arbitrarily-nested arrays of strings and ints. Contrast: typedef multiset(string|int) strint;

Re: Any interest in an open source HTTP daemon in Pike? (Spike)

On Mon, May 25, 2020 at 1:50 AM Stephen R. van den Berg wrote: > > I've written (for internal use) an HTTP daemon in Pike, using roughly > the following featureset: > - Mainly meant to run (custom) pike modules processing requests. > - Also serves static content (through a simple config file). >

Re: RFC: Attributes in Markdown text

On Fri, May 22, 2020 at 9:28 AM Martin Nilsson (Coppermist) @ Pike (-) developers forum <10...@lyskom.lysator.liu.se> wrote: > > > > >How does that sound? > > > > Sounds good to me. The expectations should be to move it from Tools to > Parser (or something) also once the changes are done. Cool.

Re: RFC: Attributes in Markdown text

On Fri, May 22, 2020 at 4:00 AM Martin Nilsson (Coppermist) @ Pike (-) developers forum <10...@lyskom.lysator.liu.se> wrote: > > While I'm indifferent to markdown itself, my problem with the markdown > implementation in Pike is that it was implemented as an application > with no programmatic way

Re: SQLite query segfaults

On Wed, Apr 29, 2020 at 5:25 AM Marc Simpson wrote: > > On Tue, Apr 28, 2020 at 12:20 PM Chris Angelico wrote: > > > > On Wed, Apr 29, 2020 at 5:13 AM Marc Simpson wrote: > > > [...] > > > > > > It seems that I can reliably segfault recent Pike 8.1 i

Re: SQLite query segfaults

On Wed, Apr 29, 2020 at 5:13 AM Marc Simpson wrote: > > Hi folks, > > It seems that I can reliably segfault recent Pike 8.1 installs when > using sprintf-style SQLite queries: > > $ echo ' > create table demo(a, b); > insert into demo(a, b) values(1, "abc")' | sqlite3 demo.db > >

Re: RFC: Attributes in Markdown text

On Wed, Apr 8, 2020 at 1:12 AM Chris Angelico wrote: > With the proposed enhancement, it's governed by the flag "attributes" > - set it to 1 to get the new functionality (otherwise an attribute > block will be seen as just another paragraph of text). If there's > actually

Re: RFC: Attributes in Markdown text

On Wed, Apr 8, 2020 at 1:04 AM H William Welliver wrote: > > Hi Chris- > > I haven’t looked at your branch (yet). Given that there are a number of > popular extensions to Markdown, perhaps rather than having a number of > different classes, we could have a flag that enables the various

RFC: Attributes in Markdown text

See branch: rosuav/markdown-attribute-syntax There's a not-very-well-known syntax supported by some Markdown parsers (including GitHub Flavored Markdown) that allows HTML attributes to be attached to a paragraph of text: Text goes here blah blah blah {: someattr=value otherattr=otherval} This

Re: Image.PNG unable to find Gz

On Wed, Jan 1, 2020 at 12:38 AM Tobias S. Josefowitz @ Pike developers forum <10...@lyskom.lysator.liu.se> wrote: > > >As of commit 1c31950, the Image.PNG module fails unless Gz has already > >been loaded. The PIKE_MODULE_IMPORT lines fail, and the module chooses > >to export nothing. > > > >Is

Image.PNG unable to find Gz

As of commit 1c31950, the Image.PNG module fails unless Gz has already been loaded. The PIKE_MODULE_IMPORT lines fail, and the module chooses to export nothing. rosuav@sikorsky:~/pike$ pike -e 'write("%d\n", sizeof(indices(Image.PNG)));' 0 But if the Gz module gets tagged first, it works:

Re: Comments/thoughts requested: Generators and async functions in Pike

On Tue, Aug 27, 2019 at 7:51 PM Stephen R. van den Berg wrote: > > Chris Angelico wrote: > >string show_channel_info(string name) { > >int id = continue return get_channel_id(name); > ... > >return name + " is offline."; > > >The intermediate

Re: Comments/thoughts requested: Generators and async functions in Pike

On Tue, Aug 27, 2019 at 3:26 AM Henrik Grubbström (Lysator) @ Pike (-) developers forum <10...@lyskom.lysator.liu.se> wrote: > > > 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

Re: Use of ::_destruct() in arbitrary objects

On Tue, Aug 27, 2019 at 3:18 AM Stephen R. van den Berg wrote: > > Chris Angelico wrote: > >In digging into a problem with Protocols.HTTP.Promise, I came across > > ># define PROMISE_DESTRUCTOR \ > > protected void _destruct() { \ > &

Use of ::_destruct() in arbitrary objects

In digging into a problem with Protocols.HTTP.Promise, I came across an issue with inheritance and destructors. #ifdef HTTP_PROMISE_DESTRUCT_DEBUG # define PROMISE_DESTRUCTOR \ protected void _destruct() { \ werror("%O()._destruct()\n", object_program(this)); \ }

Re: SSL cert for pike.lysator.liu.se has expired

On Fri, Aug 23, 2019 at 11:59 PM Peter Bortas @ Pike developers forum <10...@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

SSL cert for pike.lysator.liu.se has expired

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

Re: Comments/thoughts requested: Generators and async functions in Pike

On Sun, Aug 11, 2019 at 8:37 AM Stephen R. van den Berg wrote: > > Chris Angelico wrote: > >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 o

Comments/thoughts requested: Generators and async functions in Pike

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

Re: Shuffler.Shuffler, does anyone use it?

On Thu, Jun 13, 2019 at 9:38 PM Stephen R. van den Berg wrote: > > I though Roxen might be using it, but maybe I remember it wrong. > Anyone else? > > I ask because I'm changing Protocols.HTTP.Server.Request to use the > Shuffler, and I'm close to done, but it appears that in the process I have >

Re: Interaction between automap and argument splicing segfaults

On Thu, Apr 4, 2019 at 11:11 PM Henrik Grubbström (Lysator) @ Pike (-) developers forum <10...@lyskom.lysator.liu.se> wrote: > > > The crash is on this line: > [...] > > If pike is built with PIKE_DEBUG, you get this fatal instead: > [...] > > So the crash is in the compiler proper, not in the

Interaction between automap and argument splicing segfaults

Test case: int score_image(string image, int r, int g, int b) {return 42;} array(int) getpixel() {return ({1, 2, 3});} int main(int argc, array(string) argv) { if (argc < 2) exit(0, "All good! Try again with -DBOOM for a segfault.\n"); array images = ({"foo", "bar", "quux"}); for

Re: Protocols.DNS.server anyone used it in a DNS server?

On Thu, Feb 8, 2018 at 12:04 PM, Stephen R. van den Berg wrote: > Has anyone ever used Protocols.DNS.server in an application > (to implement a mini-DNS server)? > Is the code available? Yep! Here's one that shares your /etc/hosts.

Re: GTK/GDK on OSX

On Thu, Mar 23, 2017 at 12:51 AM, Chris Angelico <ros...@gmail.com> wrote: > On Sat, Mar 18, 2017 at 3:55 AM, H William Wellliver III > <will...@welliver.org> wrote: >> Thanks for taking a stab at it, Chris. I will have a look this weekend... >> just got a fresh OSX V

Re: JSON5

On Sun, Dec 24, 2017 at 10:58 AM, Martin Nilsson (Coppermist) @ Pike (-) developers forum <10...@lyskom.lysator.liu.se> wrote: >>Having taken a quick cursory look at the new JSON5 module, I think it >>would make sense to have a distinct decoder for JSON5, but have common >>code for the encoder.

Re: GTK2.Object()->destroy() checking for no args?

On Sat, Dec 23, 2017 at 2:11 AM, Henrik Grubbström (Lysator) @ Pike (-) developers forum <10...@lyskom.lysator.liu.se> wrote: >>On Sat, Dec 23, 2017 at 12:42 AM, Henrik Grubbström (Lysator) @ Pike >>(-) developers forum <10...@lyskom.lysator.liu.se> wrote: >>> Note that AFAIK destruct() in some

Re: GTK2.Object()->destroy() checking for no args?

On Sat, Dec 23, 2017 at 12:42 AM, Henrik Grubbström (Lysator) @ Pike (-) developers forum <10...@lyskom.lysator.liu.se> wrote: > Note that AFAIK destruct() in some GTK2 classes is a public function > (and thus part of the API). Do you mean destroy? It got renamed in the big _destruct rename, and

Re: GTK2.Object()->destroy() checking for no args?

On Fri, Dec 22, 2017 at 9:49 PM, Stephen R. van den Berg <s...@cuci.nl> wrote: > Chris Angelico wrote: >>before calling gtk_object_destroy. Any idea why? Is there a situation >>in which destroy() might have been called with arguments, such that it >>shouldn't actually

GTK2.Object()->destroy() checking for no args?

I doubt anyone will know the answer to this, as it's in 12+ year old code in the GTK2 module, but the destroy method (now renamed to _destruct) was explicitly checking that it received exactly zero args before calling gtk_object_destroy. Any idea why? Is there a situation in which destroy() might

Re: Calendar does not seem to use mktime()/localtime()/gmtime()

On Fri, Dec 15, 2017 at 12:41 AM, Peter Bortas @ Pike developers forum <10...@lyskom.lysator.liu.se> wrote: > While true, for actual Pike installations 64bit dominate. The number > of Pike mobile applications are quite low. By "quite low" do you actually mean zero, or is there actually such a

Re: Proposed improvements to Hilfe

On Thu, Nov 23, 2017 at 8:44 AM, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum <10...@lyskom.lysator.liu.se> wrote: >>The other is the addition of a new help() built-in function, which >>gives human-readable information about whatever object it's given. >>Currently it

Re: Proposed improvements to Hilfe

On Thu, Nov 23, 2017 at 8:44 AM, Henrik Grubbström (Lysator) @ Pike (-) developers forum <10...@lyskom.lysator.liu.se> wrote: >>Branch: rosuav/hilfe-improvements >> >>Two smallish improvements to Hilfe. One is suppressing "quit" and >>"exit", per the TODO at the top; fairly simple but I'd like

Re: "old" mails on the list

On Thu, Nov 23, 2017 at 9:02 AM, Peter Bortas wrote: > Hello list subscribers, > > I finally took over responsibility for the LysKOM exporter, and ran it > through the backlog. Which means you just got a bunch of new mails > that have a send date of today but might have been

Re: Conditional inclusion of inotify_config.h?

On Thu, Nov 23, 2017 at 7:58 AM, Martin Nilsson (Coppermist) @ Pike (-) developers forum <10...@lyskom.lysator.liu.se> wrote: > The change look good. I've no idea when you posted this, but I only just saw it. So I've merged that branch in now. The lyskom => mailing list gateway must have been

Proposed improvements to Hilfe

Branch: rosuav/hilfe-improvements Two smallish improvements to Hilfe. One is suppressing "quit" and "exit", per the TODO at the top; fairly simple but I'd like someone else's eyeballing to make sure it's going about things the right way. The other is the addition of a new help() built-in

Possible issue with elliptic curve crypto?

I'm far from any sort of crypto expert, but this looks a bit odd. SSL.File() is bombing out when trying to work with ECDHE ciphers. Using this Pike script: object ssl; void readcb(mixed id, string data) {exit(0, "Readable\n%s\n", data);} int x=1; void writecb() {if (x) ssl->write("asdf\n"); x=0;

Conditional inclusion of inotify_config.h?

Branch: rosuav/inotify-config Currently, inotify.cmod won't go looking for inotify_config.h unless HAVE_INOTIFY_CONFIG_H is defined. This doesn't seem to match the way other autoheader files get included, and it results in System.Inotify not being available even on systems that support inotify.

Re: GDK/GTK on OSX

On Wed, May 24, 2017 at 7:37 AM, H. William Welliver III wrote: > I’ve been quietly working on this for a few weeks now, and have got the > various permutations working on OS X. Basically, there are 2 paths for GTK > on OS X (now called macOS): X11, which is the classic

Re: Bad function identifier on 8.1

On Wed, May 24, 2017 at 8:32 PM, Stephen R. van den Berg <s...@cuci.nl> wrote: > Chris Angelico wrote: >>The simplest workaround is to delete the .o file in question after you >>install. I still haven't managed to track down exactly what the >>problem is, or make a minim

  1   2   3   >