Pike-devel January 2016

pike-devel@lists.lysator.liu.se

6 participants
11 discussions

Re: Setting socket options: so many, uhh, options!
by Chris Angelico 15 Sep '16

15 Sep '16

On Tue, Mar 10, 2015 at 10:05 PM, Mirar @ Pike developers forum <10353(a)lyskom.lysator.liu.se> wrote: > Wait, I said REUSEPORT? What's the difference to REUSEADDR? Mysteries > of TCP sockets... Here's a decent explanation, I think: http://stackoverflow.com/questions/14388706/socket-options-so-reuseaddr-and… ChrisA

3 6

Pike 8 release next weekend
by Peter Bortas 06 Feb '16

06 Feb '16

I'm aiming for a release of Pike 8 next weekend on Sunday the 7th. This is my current list of "blockers", please speak up if you have any others or if you have input on any of the existing: ** random() might now be really random (incompatible change) Will not be backed out. We should provide a pseudo-random() that is seedable, and preferably does not have a name that includes "random". I don't want to hold the release for that unless someone has a real application that needs it or have a finished implementation with a well thought out API by next Saturday. ** OpenBSD compile failures (regression) I will not hold the release for this unless someone with a OpenBSD machine tells me that they are actively working on it. ** Windows support libraries are old (not a regression, just regrettable) Will make an effort to build new versions of GMP och Nettle, and see if we can bundle a newer GTK release. Since this is not a regression I will not hold back a release for it though. Cheers, -- Peter Bortas, NSC

2 3

Change of public key
by Chris Angelico 28 Jan '16

28 Jan '16

I've just suffered a major hard drive meltdown, which wiped out one of my private keys. This is not a compromise, so there's no panic; but it means I've lost access to anything that it granted. Attached is my new public key, and a GPG signature so you know it's mine. Sorry for the hassle... welcome to security, where stuff sometimes goes wrong :) ChrisA

1 0

keypair loop
by Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum 25 Jan '16

25 Jan '16

>The PIKE_MAPPING_KEYPAIR_LOOP is not enabled by default. Is this work >in progress? Is it worth keeping? Yes. It would allow for a more static traversal order for mappings.

1 0

Over-eager optimization in Pike 8.1
by Chris Angelico 12 Jan '16

12 Jan '16

int main() { array(int) positions=({4,3}); int pos=1; array unrolled=({}); foreach (positions, int nextpos) { write("Extending to %d\n",nextpos); for (;pos<=nextpos;++pos) unrolled+=({"Spam"}); } } The basic concept is that it should unroll an array of counts into individual entries. (Think run-length decoding or something.) There's a bug in it, that the second position is lower than the first. A naive implementation would simply note that pos isn't less than or equal to nextpos, ergo it should skip the loop altogether; and in Pike 7.8.352, this is what happens. In Pike 8.1 current, this results in an infinite loop that allocates gobs of memory. I tried to bisect to find the problem, but it's been there for a very long time, and a lot of the old builds won't compile on my system for some reason. ChrisA

3 2

lookup of named inherits with modules
by Arne Goedeke 12 Jan '16

12 Jan '16

The following artificial example generates a syntax error. What is the correct syntax? main.pike: class B { inherit FOO.A; void f() { FOO.A::f(); } } FOO.pmod: class A { void f() {} } Arne

2 1

Pike 8: pgsql doesn't disconnect when destructed
by Jeff Hungerford 11 Jan '16

11 Jan '16

Greetings, I've been testing Pike 8.0.147, and I've noticed that pgsql connections to postgres don't appear to disconnect when the objects are destroyed, they linger until pike exits. For example, when I run: int main() { object foo = Sql.Sql("pgsql://hungerf3@localhost:5432/hungerf3"); destruct(foo); gc(); sleep(60); } I still see an active connection in the pg_stat_activity view in the database until the script exits. The same script drops the database connection as soon as the object is destructed in 7.8.941 In both cases, I've been testing against Postgres 9.5 on FreeBSD. -Jeff

1 0

C99
by Martin Nilsson (Opera Mini - AFK!) ＠ Pike (-) developers forum 08 Jan '16

08 Jan '16

So with Pike 8 we set the baseline at C89 support. There have been wishes to move Pike 8.1 to C99. Anyone against that?

1 0

Internal compiler error (push_compiler_frame0)
by Chris Angelico 07 Jan '16

07 Jan '16

The following code triggers an "internal error" (seems to be from language.yacc:699). function frame0(function x) { return lambda() { if (string bad=x() //Missing close parenthesis { } }; } $ pike frame0.pike frame0.pike:6:Internal compiler error (push_compiler_frame0). frame0.pike:8:Missing ')'. frame0.pike:10:Missing ';'. frame0.pike:10:Unexpected end of file. frame0.pike:10:Missing '}'. frame0.pike:10:Opening '{' was here. frame0.pike:10:Unexpected end of file. Pike: Failed to compile script. The code *is* in error (there should be another close parenthesis on line 5), but the actual error is masked. Is this worth looking into? ChrisA

1 1

Re: Pike 8.0 beta
by Stephen R. van den Berg 04 Jan '16

04 Jan '16

On Mon, Jan 4, 2016 at 7:33 AM, Lahtinen Kimmo (Valtori) <kimmo.lahtinen(a)valtori.fi> wrote: > I think I can understand the need for your request, but I am wondering is the random function correct for that kind of purpose. I think the main function is to generate random sequence and more random is better. I think the random seed was invented to solve the problem of not enough randomness? Historically, the random() function has always served a dual purpose (if that is a good thing, is debatable). This was due to the fact that it always used to be gemerated by a pseudo-random-generator. So historically, the expectation is thus: a. When not setting random_seed(), simply generate the best random sequence you can, preferably different for each run. b. random_seed() was never intended to increase randomness, instead it was used to generate predictable random sequences in order to get repeatable results when needed. That random_seed() was intended to increase randomness is a common misconception though. -- Stephen.

1 0

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 January 2016