Re: New Pike beta: 7.8.700

On Thu, Aug 9, 2012 at 6:30 AM, Bill Welliver b...@welliver.org wrote: Very good. I'll try to download and give it a test. I've also uploaded 32 and 64 bit binaries for MacOSX 10.7. Bill Many thanks! I've grabbed the Windows one onto a computer here, and I'll try to prod a Mac person into

Re: Pike 8 @ Pike conf 2013

a few patches that I haven't heard back regarding. They're mostly fairly trivial/simple. Is there a better way to suggest patches than posting them to this list or pike@roxen? ChrisA From c81cbe6479179f3082c64efe1d501c691f384f2e Mon Sep 17 00:00:00 2001 From: Chris Angelico ros...@gmail.com Date: Thu

Re: do crash pike

On Wed, Jan 15, 2014 at 3:19 PM, Martin Bähr mba...@email.archlab.tuwien.ac.at wrote: in 7.8 or 7.9 it leads to a fatal crash: Also SIGABRTs with 8.0 latest. ChrisA

Re: pike 7.8 alpha

On Fri, Jan 17, 2014 at 8:13 AM, Arne Goedeke e...@laramies.com wrote: There were also a couple of other bugfixes which i backported just now. I guess there is other candidates, but I am not so sure. Can I put in some requests for GTK2 bugfix backports, please? All of these apply cleanly to

Re: pike 7.8 alpha

On Sat, Jan 25, 2014 at 3:59 AM, Bill Welliver b...@welliver.org wrote: Hi Chris, I'll take a look at the requested changesets and will try to merge them this weekend. In general, I'm in favor of keeping GTK2 reasonably up-to-date, providing it doesn't cause compat problems with existing

Re: bash/dash

e3f00ee7de4ed2e72c025e998acdf0af6373f076 Mon Sep 17 00:00:00 2001 From: Chris Angelico ros...@gmail.com Date: Wed, 26 Feb 2014 04:02:31 +1100 Subject: [PATCH] Rework bin/getwhitespace.sh to use a heredoc for dash/bash compatibility This reverts commit 19e464ce97f8b3ac796c87fe0cdac279961aaf40. --- bin

Re: bash/dash

of single-quoted heredoc syntax, so that might need to be checked. BTW, need to strip off a pile of those backslashes. Alternative patch attached. ChrisA From 6b6c7aa886a854a1e73a5c49b9a96c1c9b66d8af Mon Sep 17 00:00:00 2001 From: Chris Angelico ros...@gmail.com Date: Wed, 26 Feb 2014 04:02:31

Re: bash/dash

On Wed, Feb 26, 2014 at 5:20 AM, Arne Goedeke e...@laramies.com wrote: Simply replacing echo by printf also works and _should_ be portable. At least posix does not say anything about 'implementation defined'. Ah, good. Always take the simplest available solution :) ChrisA

Re: curious printf bug

On Thu, Feb 27, 2014 at 11:23 AM, Martin Bähr mba...@email.archlab.tuwien.ac.at wrote: write(%.3f\n,Gmp.mpf(3.14159265359)) prints all the decimals, not just three It's listed as a fixme in src/modules/Gmp/mpf.cmod:329 ChrisA

Re: compiling the source (VPATH err)

On Fri, Mar 14, 2014 at 6:12 AM, Danesh Daroui danesh.dar...@gmail.com wrote: I have only the branch for version 8.0. I upgraded my autoconf (it is weird if autoconf 2.13 is the source of the problem!) and now the error with VPATH is gone, but at the end, compilation fails and no executable is

Re: Concurrency in Pike

if you can get your head around it, single-threaded callback handling works beautifully there. Chris Angelico

Re: Concurrency in Pike

On Sat, May 3, 2014 at 1:34 AM, Danesh Daroui danesh.dar...@gmail.com wrote: Thanks for your answer. I guess threads is something that I was looking for. By concurrency I meant being able to spawn multiple threads which will logically run in parallel. Moreover having the possibility to define

Re: Concurrency in Pike

On Mon, May 5, 2014 at 9:21 AM, Stephen R. van den Berg s...@cuci.nl wrote: Danesh Daroui wrote: Thanks for the info. I thought Pike would run all threads simultaneously when number of threads does not exceed number of available processors and otherwise using time sharing like other languages.

Three patches for review

not as important. Would love to see the GTK fixes arrive in time to go into the next published builds. Thanks! ChrisA From a063c2b2c8da29b2543aba4e5a34dc3c7ae12ae3 Mon Sep 17 00:00:00 2001 From: Chris Angelico ros...@gmail.com Date: Fri, 6 Dec 2013 01:02:58 +1100 Subject: [PATCH 1/3] Add nodelay

[PATCH] De-constify hashtable lookup to prevent compiler warning

, a more explicit cast could be done, so the compiler knows that part of it is constant and part isn't. Attached patch removes 'const'. ChrisA From 0ef675642ad9c053741097ec7416a8df28b76d19 Mon Sep 17 00:00:00 2001 From: Chris Angelico ros...@gmail.com Date: Fri, 30 May 2014 12:26:34 +1000 Subject

Re: [PATCH] De-constify hashtable lookup to prevent compiler warning

On Sat, May 31, 2014 at 1:08 AM, Arne Goedeke e...@laramies.com wrote: I think the hash lookup should not modify the hash list. Its quite expensive to relink it on every lookup and definitely negates any intended speedup. Interestingly, that code seems to go back all the way to the first pike

Re: [PATCH] De-constify hashtable lookup to prevent compiler warning

On Sat, May 31, 2014 at 2:59 AM, Stephen R. van den Berg s...@cuci.nl wrote: Chris Angelico wrote: So the question is, what does a 'const struct hash_table *' imply? Is Strictly speaking it only says that the direct struct hash_table element this pointer is pointing at will not be modified

Re: [PATCH] De-constify hashtable lookup to prevent compiler warning

On Sat, May 31, 2014 at 5:46 AM, Stephen R. van den Berg s...@cuci.nl wrote: Chris Angelico wrote: On Sat, May 31, 2014 at 2:59 AM, Stephen R. van den Berg s...@cuci.nl wrote: Strictly speaking it only says that the direct struct hash_table element this pointer is pointing

sprintf optimizations have issues with %{ %} - segfault

Example code: int main() { array x=({ ({128,0,TiMidity,TiMidity port 0}), ({128,1,TiMidity,TiMidity port 1}), }); write(Ports available:\n%{%3d:%-3d %-32.32s %s\n%},x); } In the latest Pikes, this may segfault or produce horribly wrong data; a --with-debug build

Re: sprintf optimizations have issues with %{ %} - segfault

On Sun, Jun 1, 2014 at 9:42 PM, Arne Goedeke e...@laramies.com wrote: Thanks for the report. The translation was somewhat mechanical, but I somehow messed that up. Fixed in 8.0. That does cure the problem, but now it's not possible for the fs-fsp incorrect trap to happen at all. Was there an

Re: Memory use

On Wed, Jun 11, 2014 at 6:15 PM, Henrik Grubbström (Lysator) @ Pike (-) developers forum 10...@lyskom.lysator.liu.se wrote: The large wide strings at startup are most likely the bytecode for the master and related modules. Why is the bytecode for the master a wide string? ChrisA

Casting int to float broken in 8.0 on amd64 Linux

As of commit 7666f806, casting an int to a float fails: rosuav@sikorsky:~/pike$ bin/pike Pike v8.0 release 3 running Hilfe v3.5 (Incremental Pike Frontend) (float)1; Cast failed, wanted float, got int HilfeInput:1: HilfeInput()-___HilfeWrapper() This happens also on any arithmetic operation

Re: Casting int to float broken in 8.0 on amd64 Linux

On Tue, Jun 24, 2014 at 7:05 PM, Per Hedbor () @ Pike (-) developers forum 10...@lyskom.lysator.liu.se wrote: Could you give this version of SET_SVAL a try, perhaps? #define SET_SVAL(SVAL, TYPE, SUBTYPE, FIELD, EXPR) do { \ /* Set the type afterwards to avoid a clobbered \ *

Re: Casting int to float broken in 8.0 on amd64 Linux

On Tue, Jun 24, 2014 at 7:54 PM, Chris Angelico ros...@gmail.com wrote: I'm starting up a completely fresh Pike clone to see if somehow I've accumulated cruft of some sort. If that behaves differently, I'll let you know. That didn't solve anything, but the latest commit on 8.0 branch did

Re: Hello

On Wed, Jul 23, 2014 at 6:30 AM, Guillaume Collet bilou...@free.fr wrote: my name is Guillaume Collet, I'm a french bioinformatician interested in Pike. This message was just to introduce myself. I write C/C++ for for 10 years and I found Pike's features really interesting. That's why I'm

Re: Hello

On Wed, Jul 23, 2014 at 6:49 AM, Guillaume Collet bilou...@free.fr wrote: First, I need to install Pike... I didn't got it work. What platform? There's been a new 7.8 release made, but currently there's no Windows installer for it. You can still use 7.8.700 on Windows:

Re: Pike 7.8.866 for Windows

On Wed, Jul 23, 2014 at 2:29 PM, H. William Welliver III b...@welliver.org wrote: After a few weeks of messing around with libraries, I’ve got a windows build of Pike with a reasonably complete set of modules ready for testing. Please have a look and let me know if there are any problems or

Possible bug in Gz with latest Pike 7.8.866 Windows?

Not sure how to diagnose this. Test case: int main() { string

Re: Possible bug in Gz with latest Pike 7.8.866 Windows?

On Tue, Jul 29, 2014 at 11:04 AM, H. William Welliver III b...@welliver.org wrote: I can’t really offer much in terms of suggestions; I wasn’t able to get the code you sent to work… there’s something wrong with the zip string. I can say that the zlib that I used is both a) old and b) has been

Codepage decoding tables have incorrect data

it on everything in the MICSFT/PC/ directory; the resulting patch is attached, as is a patch to create that file. ChrisA From 86fdbc9d4e18651999a33f4fda235bb1ece8de49 Mon Sep 17 00:00:00 2001 From: Chris Angelico ros...@gmail.com Date: Mon, 4 Aug 2014 12:00:17 +1000 Subject: [PATCH 1/2] Correct MS/IBM

Re: Codepage decoding tables have incorrect data

On Tue, Aug 5, 2014 at 6:55 AM, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum 10...@lyskom.lysator.liu.se wrote: And I'd be inclined to fix any acctual errors, rather than blindly following one or the other. :-) Just so you know, the MAPPINGS files on unicode.org is

Re: Codepage decoding tables have incorrect data

On Fri, Aug 8, 2014 at 1:30 AM, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum 10...@lyskom.lysator.liu.se wrote: I have pushed fixes for the box drawing characters, and for the incorrect forms of arabic characters. This includes fixes to IBM 851 and IBM 868, which were

Re: Codepage decoding tables have incorrect data

On Fri, Aug 8, 2014 at 1:50 AM, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum 10...@lyskom.lysator.liu.se wrote: Ok. Then my approach would be to keep things as they are until someone comes up with a specific complaint. :-) As I said, the box drawing stuff is fixed,

Re: Hilfe-crash.

On Mon, Aug 11, 2014 at 4:20 AM, Martin Nilsson (Opera Mini - AFK!) @ Pike (-) developers forum 10...@lyskom.lysator.liu.se wrote: After the new code generation I get a consistent crash if I start hilfe and does arrow up. Not very helpful backtrace though. It seems to depend on having a

Re: zero_type of implicit return

On Sun, Aug 17, 2014 at 3:15 AM, Martin Nilsson (Opera Mini - AFK!) @ Pike (-) developers forum 10...@lyskom.lysator.liu.se wrote: Would it make sense if the implicit return 0; in pike functions had a different zero type than 0, like UNDEFINED? I'm conceptually okay with it, but it will break

Re: zero_type of implicit return

On Mon, Aug 18, 2014 at 7:15 AM, Mirar @ Pike developers forum 10...@lyskom.lysator.liu.se wrote: I can't imagine any code that relies on that a function not returning anything is returning 0 and not UNDEFINED. Hmm. Actually, I think you're right. I do frequently make use of the implicit zero

Removal of 7.2 compat broke Stdio.read_file

Test case: int main() {write(Stdio.read_file(readfileboom.pike));} Oddly enough, this works fine if run from a non-installed Pike: rosuav@sikorsky:~/pike$ bin/pike readfileboom.pike int main() {write(Stdio.read_file(readfileboom.pike));} But installing it and using that causes a crash:

Re: Fun with lfuns: `= and `[..]=

On Thu, Aug 28, 2014 at 3:44 AM, Stephen R. van den Berg s...@cuci.nl wrote: - There obviously is no `= lfun. Is that technically challenging or hasn't there simply been no need to make it possible? Don't like this idea! When you assign to a name, it should always rebind. Imagine: mixed foo

Re: Fun with lfuns: `= and `[..]=

On Thu, Aug 28, 2014 at 4:09 PM, Stephen R. van den Berg s...@cuci.nl wrote: The operation could be determined by overloading based on types. I.e. a String Buffer `=(string a) would only activate when the lvalue is a buffer type, and the rvalue is of type string. Maybe. Still strikes me as

Branches for discussion: Pango.Layout xy_to_char, Stdio.File nodelay

Both of these have been discussed previously, but now they're posted as topic branches in the main repo. (I've also pushed a few non-controversial GTK2 changes to the 8.0 and 7.8 branches.) Branch: rosuav/pango_xy_to_char Adds a new method xy_to_char() to the GTK2.Pango.Layout object, parallel

Re: Branches for discussion: Pango.Layout xy_to_char, Stdio.File nodelay

On Fri, Aug 29, 2014 at 12:04 AM, Lance Dillon riffraff...@yahoo.com wrote: Maybe both? Have individual methods for those who want to just call it, and a setflags type method that you can pass bit flags into to set. That way if you have several flags to set you can do it in one call, or just

Setting socket options: so many, uhh, options!

Topic branch: rosuav/sockopt Per Lance's suggestion, I've made a generic setsockopt() function. It works only with integers, so it's not suitable for SO_LINGER, which therefore should stay the way it is (linger() takes a magic parameter of -1), but it works for any of the simple boolean options.

Re: Refcounting gone wild?

On Fri, Sep 5, 2014 at 4:46 AM, Arne Goedeke e...@laramies.com wrote: I think that is a hilfe effect. Yeah, that's Hilfe's result history. Visible thus: object c=Stdio.File(); _refs(c); (1) Result: 2 c=c; (2) Result: Stdio.File(0, 0, 777 /* fd=-1 */) _refs(c); (3) Result: 3 c=c; (4)

Backport fix of program indexing

This was fixed in 8.0 with commit afa24a, but not on 7.8. Is it okay to backport this fix? See branch rosuav/backport_program_indexing_fix which is cherry-picking that commit and fixing an insignificant merge conflict. Test case: constant foo=test; int main() {write(%O\n,this_program[foo]);} On

Re: lfun `+= and bogus conditions, performance loss, semantic errors

On Mon, Sep 8, 2014 at 10:21 PM, Stephen R. van den Berg s...@cuci.nl wrote: The question now remains: - Do we agree this is a bug? - Or do we document that this is a feature? - Or maybe we already documented it as a feature and I just didn't see it. It's documented here:

Re: lfun `+= and bogus conditions, performance loss, semantic errors

On Mon, Sep 8, 2014 at 10:30 PM, Stephen R. van den Berg s...@cuci.nl wrote: Let the record show though that I consider it to be a rather messy way to handle this :-). I've worked with Python's way of doing things, and it has its own issues. This kind of thing comes up periodically on

Re: lfun `+= and bogus conditions, performance loss, semantic errors

On Mon, Sep 8, 2014 at 10:38 PM, Stephen R. van den Berg s...@cuci.nl wrote: Well, for one, someone browsing the docs needs to be explained the difference between http://pike.lysator.liu.se/generated/manual/modref/ex/predef_3A_3A/_backtick_add.html and

Re: Fun with lfuns: `= and `[..]=

On Wed, Sep 17, 2014 at 10:57 PM, Stephen R. van den Berg s...@cuci.nl wrote: Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote: What if b is declared as string|String.Buffer? Is it obvious what should happen then? string|String.Buffer is a union type, so using it in

Editing the Pike tutorial - where is it?

The tutorial at http://pike.lysator.liu.se/docs/tutorial/ is a bit out of date, and its header comment says that it will be updated ASAP. I'd like to fix some of it up (most notably the GTK bits; someone was asking me about them, as they're all GTK1 and don't work with GTK2), but can't find the

Re: Editing the Pike tutorial - where is it?

On Sun, Sep 21, 2014 at 1:11 PM, H. William Welliver III b...@welliver.org wrote: I think the tutorial exists only as a set of xml/html files in the pike website, at least I think that’s how I got hold of it the last time I needed to make changes. Ah, okay. I tried to make an export of the

Program.all_inherits needs documentation... or a better spec

Program.all_inherits has a FIXME asking for docs. But its definition is a little odd: it returns a list of the given program's inherits, and everything they inherit - but not recursively. I could document it as such, but it strikes me that this should be recursive, similar to inherit_tree but

Re: Program.all_inherits needs documentation... or a better spec

On Mon, Sep 29, 2014 at 3:35 AM, Henrik Grubbström (Lysator) @ Pike (-) developers forum 10...@lyskom.lysator.liu.se wrote: Program.all_inherits has a FIXME asking for docs. But its definition is a little odd: it returns a list of the given program's inherits, and everything they inherit - but not

Re: Freeze of Debian 8.0 jessie

On Mon, Sep 29, 2014 at 12:02 PM, Martin Bähr mba...@email.archlab.tuwien.ac.at wrote: what is the version currently available for debian? greetings, martin. 7.8.866 ChrisA

Array augmented assignment doesn't always work

Apologies for the non-minimality of the test-case, but this is a smidge weird. The changes made in b2d25e Compiler: Improved soundness of the op-assign optimizer seem to have broken this: //Should print ({ }) to stdout and return 0, because the array should end up empty. //This is what happens

Re: Array augmented assignment doesn't always work

On Wed, Oct 1, 2014 at 2:05 AM, Henrik Grubbström (Lysator) @ Pike (-) developers forum 10...@lyskom.lysator.liu.se wrote: No problem, the test program triggered the bug consistently, so it was easy to find and fix the bug. Fixed in current Pike 8.0. Thanks for that! Confirmed successful.

Re: Pike 8.0

On Sat, Oct 4, 2014 at 12:00 AM, Per Hedbor () @ Pike (-) developers forum 10...@lyskom.lysator.liu.se wrote: The intent is to fairly soon (for values of soon) release a new stable from 8.0. If you have any issues with the current version, please tell us about it. :) Sounds good to me! Which

Re: Freeze of Debian 8.0 jessie

On Wed, Oct 15, 2014 at 1:00 AM, Martin Nilsson (Opera Mini - AFK!) @ Pike (-) developers forum 10...@lyskom.lysator.liu.se wrote: What do we need to make a 8.0 release this week, even if it is only for Debian? Possibly fix the docs building, which (last I checked) is failing in 8.1 and 8.0.

Proposal: Enhance Process.run() to accept functions for stdout/stderr

I periodically find myself needing something similar to Process.run(), but processing intermediate output. Example: https://github.com/Rosuav/FrozenOST/blob/master/build.pike#L114 It needs to take whatever's sent to stderr, turn all \n into \r, and send it on to the real stdout. (Yes, it sends

Re: Text files

On Mon, Oct 20, 2014 at 2:20 AM, Martin Nilsson (Opera Mini - AFK!) @ Pike (-) developers forum 10...@lyskom.lysator.liu.se wrote: README-GIT : Should be verified. The autoconf section needs an update on working versions. I'm having no trouble with autoconf 2.69, for instance. What versions are

Re: Proposal: Enhance Process.run() to accept functions for stdout/stderr

On Sat, Oct 18, 2014 at 6:52 PM, Chris Angelico ros...@gmail.com wrote: The code is now at branch rosuav/process_run_with_func; the equivalent to my above code would be simply: Process.run(({sox,-S,-m,-v,.5})+tracklist/1*({-v,.5})+({soundtrack}), ([stderr:lambda(string data) {write

Re: Proposal: Enhance Process.run() to accept functions for stdout/stderr

On Mon, Nov 3, 2014 at 10:55 PM, Per Hedbor () @ Pike (-) developers forum 10...@lyskom.lysator.liu.se wrote: Any views on this feature? (I just rebased the branch on top of current 8.1, no other changes.) Fears of breakage? Interest in using it? Anything? It looks good to me. And, yes, it is

Can Pike 8.0 drop string_to_unicode/unicode_to_string?

These functions are somewhat misnamed anyway (they convert to UTF-16 byte streams), and you can always explicitly manipulate UTF-16 using the Charset.encoder/decoder functions. UTF-8 is far more common, and the corresponding string_to_utf8/utf8_to_string functions are more usefully named too. Is

Build failure when HAVE_NETTLE_ECDSA_H not set

/home/rosuav/pike/src/post_modules/Nettle/hogweed.cmod:1008:1: error: ‘SECP192R1’ undeclared (first use in this function) The symbols are defined inside a block guarded by HAVE_NETTLE_ECDSA_H, but then are used in hogweed_init, which is unguarded. One possible fix would be to move the defines

Re: Build failure when HAVE_NETTLE_ECDSA_H not set

On Sat, Feb 7, 2015 at 10:30 PM, Henrik Grubbström (Lysator) @ Pike (-) developers forum 10...@lyskom.lysator.liu.se wrote: These symbols are only useful when ECC is available, so they should be guarded in the same way as their definitions. Fixed. Thanks for the report. Thanks, working

Small tweak to Process.run() new feature

In Pike 8.1, Process.run() will accept functions for stdout and stderr, as was discussed here a while ago. I just tweaked that to check for *callables* rather than specifically functions, which allows easy tee'ing of the output: Process.run( ({some_command,with,args}),

Unexpected and unused calls to resolv()

See attached test-case: run main.pike. When a function is defined in a file, I would normally expect that resolv() is not called. But if the function definition is below the usage, resolv() is called, but the result seems to be ignored; the code uses the function from elsewhere in the file. (Note

Re: Setting socket options: so many, uhh, options!

On Thu, Feb 26, 2015 at 10:32 PM, Arne Goedeke e...@laramies.com wrote: I think we should merge this, or at least a similar API. Any objections? Haven't heard anyone else's views on this, which suggests that nobody's particularly bothered one way or the other. Which version of the API do you

Re: Setting socket options: so many, uhh, options!

On Tue, Mar 10, 2015 at 10:05 PM, Mirar @ Pike developers forum 10...@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:

Re: = Lambda shorthand syntax

On Sat, Mar 14, 2015 at 8:50 PM, Mirar @ Pike developers forum 10...@lyskom.lysator.liu.se wrote: I'm not against. Does it collide with anything? Also not against it. Would simplify callback code somewhat. ChrisA

Re: Setting socket options: so many, uhh, options!

On Tue, Mar 10, 2015 at 8:17 PM, Stephen R. van den Berg s...@cuci.nl wrote: Chris Angelico wrote: On Thu, Feb 26, 2015 at 10:32 PM, Arne Goedeke e...@laramies.com wrote: I think we should merge this, or at least a similar API. Any objections? Haven't heard anyone else's views on this, which

Re: Setting socket options: so many, uhh, options!

On Tue, May 5, 2015 at 3:08 AM, Stephen R. van den Berg s...@cuci.nl wrote: Chris Angelico wrote: Separately to the REUSE* questions, I've been experimenting today with the IP_TOS settings, and to that end, dusted off this branch. The change is taking effect - I can see it in my outgoing logs

Re: Setting socket options: so many, uhh, options!

On Tue, Mar 10, 2015 at 10:33 PM, Stephen R. van den Berg s...@cuci.nl wrote: Chris Angelico wrote: On Tue, Mar 10, 2015 at 10:05 PM, Mirar @ Pike developers forum 10...@lyskom.lysator.liu.se wrote: Wait, I said REUSEPORT? What's the difference to REUSEADDR? Mysteries of TCP sockets... http

Re: Possible parenthesization problem?

On Thu, May 7, 2015 at 5:29 PM, Arne Goedeke e...@laramies.com wrote: on the other hand, i guess that placement was not intentional and for sure placing it around the comparison is less confusing. Shall I make the change, then? There's no way it can break anything, right? ChrisA

Re: Possible parenthesization problem?

On Thu, May 7, 2015 at 8:50 PM, Arne Goedeke e...@laramies.com wrote: Yes, I think it should be changed. Fixed in 8.1 and 8.0. ChrisA

Possible parenthesization problem?

Poking around in signal_handler.c out of curiosity, I came across this: while(UNLIKELY(close(control_pipe[0])) 0 UNLIKELY(errno==EINTR)); while(UNLIKELY(close(control_pipe[1])) 0 UNLIKELY(errno==EINTR)); (lines 3580-3581) The UNLIKELY marker normally applies to an entire

SSL curve ciphers

See branch: rosuav/curve_crypto_guard Is there a simpler way to cope with crypto absences than all the #if'ing everywhere? It's easy to create a Pike that won't build on systems that lack one or other. ChrisA

Re: split-string branch

On Wed, Aug 19, 2015 at 2:09 PM, Per Hedbor p...@hedbor.org wrote: There is no need to consume or trim the buffer, it is automatically done in output_to. That removes the written data from the start of the buffer. You would need to keep relevant checks, yes, but the current size (except for a

Re: split-string branch

On Wed, Aug 19, 2015 at 1:45 PM, Per Hedbor p...@hedbor.org wrote: In this specific case you could use Stdio.Buffer instead. Change writeme to be a buffer, then add to it using -add(string) In the socket_write function, you only need this: if( sizeof( con-_writeme ) )

Re: split-string branch

On Mon, Aug 24, 2015 at 11:00 PM, Per Hedbor () @ Pike (-) developers forum 10...@lyskom.lysator.liu.se wrote: Since this change does fix the testcase, should I commit it to 8.1? Please go ahead and commit it. Pushed. Thanks for the advice! ChrisA

Re: split-string branch

On Mon, Aug 24, 2015 at 10:48 PM, Per Hedbor p...@hedbor.org wrote: I am personally much more interrested in why it breaks? The strings really are static. I assume it could be the lack of trailing \0? It should not really cause them to compare diffently, but I guess it might? Changing to

Re: split-string branch

On Sun, Aug 23, 2015 at 5:50 AM, Per Hedbor () @ Pike (-) developers forum 10...@lyskom.lysator.liu.se wrote: Ok.. I accidentally commited about half of the changes to 8.1, without the other half (I did a 'git push' but aborted almost directly when I noticed it was pushing 8.1. However, it

Re: split-string branch

On Wed, Aug 19, 2015 at 6:13 AM, Per Hedbor () @ Pike (-) developers forum 10...@lyskom.lysator.liu.se wrote: Another advantage with this method is that it is reasonably trivial to add new string types. As an example that I am seriously considering: A string that is a tail port of another

C99, variadic macros, and rbtree.c

a5a15b makes rb_fatal identical to Pike_fatal when debugging is not active. This doesn't work, because Pike_fatal takes just sprintf format and args, but rb_fatal takes a node pointer first. Since variadic macros exist only in ISO C 1999 and newer, I'm guessing they shouldn't be used; otherwise,

Re: switch and Math.nan

On Thu, Jul 9, 2015 at 2:09 AM, Arne Goedeke e...@laramies.com wrote: Of course all this is nothing new. Python afaik tries to treat NaN in containers as if it compared equal to itself. Is that the best one can do? What about the following radical proposal: Define Math.nan == Math.nan to be

Re: switch and Math.nan

On Thu, Jul 9, 2015 at 2:37 AM, Arne Goedeke e...@laramies.com wrote: Violating IEEE without a good reason would introduce other problems, and I'm sure there'll be discussions around the place of exactly why nan has to be unequal to itself. Incidentally, Python's rule about NaN in containers

Re: New Defects reported by Coverity Scan for Pike-master

On Tue, Sep 8, 2015 at 12:28 AM, wrote: > 1614 case TWO(STRING_ALLOC_SUBSTRING,1): > 1615 Pike_fatal("This should not happen, substrings are never > unlinked.\n"); CID 1323178: Control flow issues (MISSING_BREAK) The above case falls

Re: C99, variadic macros, and rbtree.c

On Wed, Aug 26, 2015 at 1:25 AM, Per Hedbor () @ Pike (-) developers forum 10...@lyskom.lysator.liu.se wrote: C11 is default since gcc 5.2, I think. But C99 seems to have been skipped (as the default) entirely. The example line of code that I gave works fine on my system (gcc 4.9.2), but that

Re: 9233989: ecx and edx were mixed up

On Tue, Sep 29, 2015 at 12:40 AM, Martin Nilsson (Opera Mini - AFK!) @ Pike (-) developers forum <10...@lyskom.lysator.liu.se> wrote: > Well, I didn't actually change the order. But I see that the code in > cpulib outputs them differently depending on which assembler code is > used, which is bad

Re: 9233989: ecx and edx were mixed up

On Tue, Sep 29, 2015 at 2:00 AM, Martin Nilsson (Opera Mini - AFK!) @ Pike (-) developers forum <10...@lyskom.lysator.liu.se> wrote: > I'm not sure what they stand for (well, they are listed in the x86 > processor specific output constraints in the gcc documentation). I > simply checked that the

9233989: ecx and edx were mixed up

For operation 0, the text string is indeed returned in [EAX]/EBX/EDX/ECX. However, the string is used only in src/code/ia32.c for its detection of AMD vs Intel, so it's entirely possible this change won't break anything anywhere else. Might merit a comment and some odd code in that one file,

Internal compiler error (push_compiler_frame0)

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

Re: Pike 8.0 beta

On Fri, Jan 1, 2016 at 9:08 AM, Peter Bortas wrote: > I'm taking up an old tradition that haven't been practiced since 2008 as far > as > I can tell: Making releases on new years eve. Bill has been busy with other > things, so I'll jump in to my old role as release manager for

Re: Pike 8.0 beta

On Fri, Jan 1, 2016 at 9:38 AM, Peter Bortas <bor...@gmail.com> wrote: > On Thu, Dec 31, 2015 at 11:32 PM, Chris Angelico <ros...@gmail.com> wrote: >> Is the below information lifted straight from somewhere? There are a >> couple of typos in it. If it was just for this

Re: Internal compiler error (push_compiler_frame0)

On Mon, Jan 4, 2016 at 11:55 AM, Chris Angelico <ros...@gmail.com> wrote: > The following code triggers an "internal error" (seems to be from > language.yacc:699). > > function frame0(function x) > { > return lambda() > { > if (st

Over-eager optimization in Pike 8.1

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

Re: Promises in Pike vs other languages

On Wed, May 25, 2016 at 10:30 PM, Per Hedbor () @ Pike (-) developers forum <10...@lyskom.lysator.liu.se> wrote: >>I think the biggest benefit is that your async programming becomes/or >>looks more sequential/synchroneous which tend to be easier to follow, >>or in other words less spaghetti-ish. >

Re: System.Memory and mmap()

On Tue, Jun 14, 2016 at 6:00 AM, Mirar @ Pike developers forum <10...@lyskom.lysator.liu.se> wrote: > The only other case for SIGSEGV would be to crash your program to > restart it because _Pike itself_ had a bug. I haven't seen that case > for many years. YMMV. GTK2 bugs have been crashing Pike

Re: Protocols.IRC unmaintained - want me to give it some TLC?

On Sun, Feb 7, 2016 at 11:20 AM, Peter Bortas @ Pike developers forum <10...@lyskom.lysator.liu.se> wrote: > Please do. > > I have (after a bit of head-scratching) figured out how the key > management works. I think. Try it. Thank you, seems to be working! Much appreciated. Ran into a problem

Re: Pike 8.0.162 release candidate

On Mon, Feb 8, 2016 at 5:36 AM, Peter Bortas wrote: > Windows build: > > > https://pike.lysator.liu.se/pub/pike/beta/8.0.162/Pike-v8.0.162-win32-oldli > bs.msi > > I did some work on building newer support libs for Windows, but that > ended up being 6 hours of mostly

Change of public key

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...

  1   2   3   >