Re: New Pike beta: 7.8.700

[Chris Angelico]

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 trying Pike out.

Windows Pike is behaving nicely so far, stable and no obvious issues.

ChrisA

Re: Pike 8 @ Pike conf 2013

[Chris Angelico]

On Sun, Nov 17, 2013 at 2:15 AM, Henrik Grubbström (Lysator) @ Pike
(-) developers forum 10...@lyskom.lysator.liu.se wrote:
 And now the branch and Pike 8.0.1 exist:

 | Pike v8.0 release 1 running Hilfe v3.5 (Incremental Pike Frontend)
 | 

Cool!

This looks like a good opportunity to mention 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, 1 Nov 2012 06:03:20 +1100
Subject: [PATCH 1/6] Add convenience function get_ip to HTTP Request objects,
 and document my_fd member

---
 .../Protocols.pmod/HTTP.pmod/Server.pmod/Request.pike |   13 +
 1 file changed, 13 insertions(+)

diff --git a/lib/modules/Protocols.pmod/HTTP.pmod/Server.pmod/Request.pike b/lib/modules/Protocols.pmod/HTTP.pmod/Server.pmod/Request.pike
index 7eda95e..7ca6e69 100644
--- a/lib/modules/Protocols.pmod/HTTP.pmod/Server.pmod/Request.pike
+++ b/lib/modules/Protocols.pmod/HTTP.pmod/Server.pmod/Request.pike
@@ -51,7 +51,9 @@ protected class Port {
   void destroy();
 }
 
+//! The socket that this request came in on.
 Stdio.File my_fd;
+
 Port server_port;
 .HeaderParser headerparser;
 
@@ -581,6 +583,17 @@ string make_response_header(mapping m)
return res*\r\n+\r\n\r\n;
 }
 
+//! Return the IP address that originated the request, or 0 if
+//! the IP address could not be determined. In the event of an
+//! error, @[my_fd]@tt{-errno()@} will be set.
+string get_ip()
+{
+	string addr = my_fd?-query_address();
+	if (!addr) return 0;
+	sscanf(addr,%s ,addr);
+	return addr;
+}
+
 //! return a properly formatted response to the HTTP client
 //! @param m 
 //! Contains elements for generating a response to the client.
-- 
1.7.10.4

From a281fa9b3f4826f6541e1dc0247b8a523d317fff Mon Sep 17 00:00:00 2001
From: Chris Angelico ros...@gmail.com
Date: Sat, 16 Mar 2013 23:56:42 +1100
Subject: [PATCH 2/6] low_read_file: Show length read as unsigned int with %u
 for safety

---
 src/object.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/object.c b/src/object.c
index 3495a01..e78fb62 100644
--- a/src/object.c
+++ b/src/object.c
@@ -491,8 +491,8 @@ static struct pike_string *low_read_file(const char *file)
 	  Pike_fatal(low_read_file(%s) failed, errno=%d\n,file,errno);
 	}
 	Pike_fatal(low_read_file(%s) failed, short read: 
-		   %PRINTPIKEOFFTd  %PRINTPIKEOFFTd\n,
-		   file, pos, len);
+		   %u  %PRINTPIKEOFFTd\n,
+		   file, (unsigned)pos, len);
   }
   pos+=tmp;
 }
-- 
1.7.10.4

From d9619cdba197f15fc22d71c6335e9b8c77951aa1 Mon Sep 17 00:00:00 2001
From: Chris Angelico ros...@gmail.com
Date: Mon, 18 Mar 2013 22:59:47 +1100
Subject: [PATCH 3/6] Configure: Halt the OOB check on poll error to prevent
 hang

---
 src/configure.in |1 +
 1 file changed, 1 insertion(+)

diff --git a/src/configure.in b/src/configure.in
index 1c5453f..6872de3 100644
--- a/src/configure.in
+++ b/src/configure.in
@@ -7451,6 +7451,7 @@ int main(int argc, char **argv)
 
 for(e=0;e2;e++)
 {
+  if(pollset[e].revents  POLLERR) exit(1);
   if(pollset[e].revents  POLLRDBAND) pong(e);
   if(pollset[e].revents  POLLWRBAND) ping(e);
   if(pollset[e].revents  POLLIN) pang(e);
-- 
1.7.10.4

From 8495d82553364d171e974133c6531efda39008aa Mon Sep 17 00:00:00 2001
From: Chris Angelico ros...@gmail.com
Date: Sat, 23 Mar 2013 01:37:06 +1100
Subject: [PATCH 4/6] GTK2.TreePath: Query the depth for get_indices() rather
 than looking for a terminator

---
 src/post_modules/GTK2/source/gtktreepath.pre |   10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/src/post_modules/GTK2/source/gtktreepath.pre b/src/post_modules/GTK2/source/gtktreepath.pre
index 7e5dd93..13a1407 100644
--- a/src/post_modules/GTK2/source/gtktreepath.pre
+++ b/src/post_modules/GTK2/source/gtktreepath.pre
@@ -104,14 +104,16 @@ array(int) get_indices()
 //! of integers, each representing a node in a tree.
 {
   int n=0;
+  gint depth=gtk_tree_path_get_depth((GtkTreePath *)THIS-obj);
   gint *arr=gtk_tree_path_get_indices((GtkTreePath *)THIS-obj);
   pgtk2_pop_n_elems(args);
-  while (arr[n])
-PGTK_PUSH_INT(arr[n++]);
-  if (!n)
-ref_push_array(empty_array);
+  if (!depth) ref_push_array(empty_array);
   else
+  {
+while (ndepth)
+  PGTK_PUSH_INT(arr[n++]);
 f_aggregate(n);
+  }
 }
 
 void destroy()
-- 
1.7.10.4

From 7d870ad3306d3d78db60287d73cf5a7c17bb81f5 Mon Sep 17 00:00:00 2001
From: Chris Angelico ros...@gmail.com
Date: Sun, 9 Jun 2013 04:51:45 +1000
Subject: [PATCH 5/6] Shorten/simplify the recording of string flags
 upper/lowercase

---
 src/stralloc.c |6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/src/stralloc.c b/src/stralloc.c
index 0374964..951aa76 100644
--- a/src/stralloc.c
+++ b/src/stralloc.c
@@ -179,12

Re: do crash pike

[Chris Angelico]

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

[Chris Angelico]

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 7.8 branch:

git cherry-pick b4a385 54b2df ff1242 8d4b39

The most important is ff1242, increasing refcounts of strings; all
would be useful, but none absolutely critical.

ChrisA

Re: pike 7.8 alpha

[Chris Angelico]

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 code (or crashes, naturally).

Thanks. In most cases, the GTK changes I've put forward haven't
changed existing code at all - some have been to _prevent_ crashes,
others will simply add new functions or arguments to current
functions. The only one of the above that might break existing code is
54b2df, which changes the args to a callback from being the anomalous
array to being a set of separate args, same as every other callback
is. I strongly suspect nobody's actually using that, or it would have
been changed already.

ChrisA

Re: bash/dash

[Chris Angelico]

On Wed, Feb 26, 2014 at 3:47 AM, Arne Goedeke e...@laramies.com wrote:
 My gentoo /bin/sh (which is bash) unlike dash generates a broken
 whitespace.h file from the current bin/getwhitespace.sh . I dont know
 which of the two is wrong here, but should we simply use numeric values
 instead of character escapes?

 arne

There's a difference between bash and dash handling there. I suspect
the easiest solution will be to switch to a heredoc, which - not being
a quoted string itself - doesn't parse apostrophes. It's not as tidy
as the other version, though.

Patch attached.

ChrisA
From 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/getwhitespace.sh |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/bin/getwhitespace.sh b/bin/getwhitespace.sh
index 213b16f..e9cda72 100755
--- a/bin/getwhitespace.sh
+++ b/bin/getwhitespace.sh
@@ -1,12 +1,13 @@
 #!/bin/sh
 
-echo /* File generated on `date`
+echo /* File generated on `date`
+cat 'EOM'
 by getwhitespace UnicodeData.txt */
 
 #define SPACECASE8			\\
-   case ' ':case 't':case 'r':case 'n':case 'v':case 'f':	\\
+   case ' ':case '\\t':case '\\r':case '\\n':case '\\v':case '\\f':	\\
case 0x85:case 0xa0:
-
+EOM
 
 echo '#define SPACECASE16	SPACECASE8 \'
 sed -n -e '
-- 
1.7.10.4

Re: bash/dash

[Chris Angelico]

On Wed, Feb 26, 2014 at 5:08 AM, Arne Goedeke e...@laramies.com wrote:
 I wasnt sure whats a portable fix. Interestingly, any backslash
 in an argument to echo is undefined behavior, according to
 posix, so I suppose echo ought to be avoided in this case.

I'm not 100% sure about the portability 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 +1100
Subject: [PATCH] Rework bin/getwhitespace.sh to use a heredoc for dash/bash
 compatibility

---
 bin/getwhitespace.sh |9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/bin/getwhitespace.sh b/bin/getwhitespace.sh
index 213b16f..a210eb9 100755
--- a/bin/getwhitespace.sh
+++ b/bin/getwhitespace.sh
@@ -1,12 +1,13 @@
 #!/bin/sh
 
-echo /* File generated on `date`
+echo /* File generated on `date`
+cat 'EOM'
 by getwhitespace UnicodeData.txt */
 
-#define SPACECASE8			\\
-   case ' ':case 't':case 'r':case 'n':case 'v':case 'f':	\\
+#define SPACECASE8			\
+   case ' ':case '\t':case '\r':case '\n':case '\v':case '\f':	\
case 0x85:case 0xa0:
-
+EOM
 
 echo '#define SPACECASE16	SPACECASE8 \'
 sed -n -e '
-- 
1.7.10.4

Re: bash/dash

[Chris Angelico]

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

[Chris Angelico]

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)

[Chris Angelico]

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 generated. I
 have attached the log file of my compilation. My branch is also up-to-date.
 I have run git pull before and git fetch continuously. Any help will be
 appreciated. I also got the following warnings which seem not to be a big
 deal:

This bit looks odd, but I can't be sure that's a problem, and what
you're seeing is listed as a warning:

checking gtk/gtk.h usability... yes
checking gtk/gtk.h presence... no
checking for gtk/gtk.h... yes

It's usable but not present. Odd.

Anyway, see if you can run bin/pike - the executable is created deep
in the build directory, but there's a script ~/pike/bin/pike that
should find stuff and run it.

rosuav@sikorsky:~/pike$ bin/pike
Pike v8.0 release 1 running Hilfe v3.5 (Incremental Pike Frontend)


If that works, 'sudo make install' should also work.

ChrisA

Re: Concurrency in Pike

[Chris Angelico]

On Sat, May 3, 2014 at 1:14 AM, Danesh Daroui danesh.dar...@gmail.com wrote:
 I wanted to ask whether there is any library implemented for Pike to support
 concurrency or if it planed to do so as an embedded feature or added
 package? I think the language has a great potential to be widely used if
 such enhancements are done. I am reading the book Pike: an Introduction
 and have not seen any concept about concurrency yet (I am not done with the
 book yet).

Hi!

What exactly do you mean by concurrency? Pike comes with a Thread
module, which works very nicely for I/O-bound operations; though if
you can get your head around it, single-threaded callback handling
works beautifully there.

Chris Angelico

Re: Concurrency in Pike

[Chris Angelico]

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 mutex
 and semaphores which are apparently done in Pike (mutex is at least done)
 and also barrier and join threads, etc.

Yep! You should be able to do all that.

Pike's own internals are guaranteed to be thread-safe, so you can
happily work with all the refcounted objects from multiple threads.
(This will damage true concurrency, though, as accessing the same
object from two threads means they'll lock against each other. In
practice, this happens a lot, so you'll probably not be able to use
multiple cores to maximum efficiency without some alternative ways of
fiddling with things.) I run a MUD by the name of Minstrel Hall
(minstrelhall.com) where every connected client has a separate thread;
they all run very happily together. One can interact with another and
they don't have to worry about treading on each other's toes.

For actual explicit locking between threads, the Thread module
provides mutexes. They're a little odd to use at first, if you're used
to a more classic mutex system; but it's very handy because you can't
accidentally forget to unlock the semaphore (once the MutexKey goes
out of scope, the Mutex is automatically unlocked). I've used it
occasionally, but it's almost never necessary.

Operations like joining threads are provided as methods on the
Thread.Thread object (eg wait()). I'm not sure where barriers would be
needed, as I've never actually used them in any language, but I'm sure
there'll be a way to implement it.

ChrisA

Re: Concurrency in Pike

[Chris Angelico]

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.

 Well, most popular interpreter-based languages have the same problem as Pike:
 they do not use more than one CPU core per process (e.g. Perl, Python, Ruby,
 Javascript).

It's also worth noting that there are several Python interpreters, of
which not all use a Global Interpreter Lock; CPython (the most popular
one and the one most people think of as python) does, and there've
been periodic calls to rewrite things to not need it. So far, the
impetus to remove such a lock has been relatively weak; the advantages
of the GIL (simplicity and performance) majorly outweigh the
advantages of no-GIL (ability to use multiple cores simultaneously)
for most applications.

ChrisA

Three patches for review

[Chris Angelico]

I've posted each of these patches previously, but haven't heard a
certain word as to their acceptance or rejection. Can someone please
consider them?

1) Add a nodelay() function to Stdio.Files. There was some discussion
as to whether or not this should be done in a more general way, but
the discussion flagged and no conclusion was reached.

2) Represent a GTK G_TYPE_POINTER argument as an integer, rather than
as an object. Every example I can find of a G_TYPE_POINTER coming back
results in a segfault of Pike, which suggests that it's really not an
object. I haven't found any instances where it really is meant to be
an object, but that doesn't mean there aren't any. Does anyone know
for sure? In any case, returning integers is safe for cases like the
Notebook switch-page signal.

3) Ensure that something, at least, is pushed for every argument to a
GTK signal callback function. Currently, unrecognized types can be
simply skipped, resulting in stack mangling. My patch pushes the name
of the type, thus preventing segfaults.

The two GTK patches apply cleanly to 7.8 as well as 8.0, and can be
considered bugfixes. The nodelay() function is definitely a feature
addition, and is also 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() function to Stdio.File objects to control
 Nagling

---
 src/modules/_Stdio/file.c   |   52 +++
 src/modules/_Stdio/file_functions.h |6 
 2 files changed, 58 insertions(+)

diff --git a/src/modules/_Stdio/file.c b/src/modules/_Stdio/file.c
index 40378e8..81525dc 100644
--- a/src/modules/_Stdio/file.c
+++ b/src/modules/_Stdio/file.c
@@ -121,6 +121,10 @@
 #include net/netdb.h
 #endif /* HAVE_NET_NETDB_H */
 
+#ifdef HAVE_NETINET_TCP_H
+#include netinet/tcp.h
+#endif
+
 #include dmalloc.h
 
 
@@ -2395,6 +2399,54 @@ static void file_linger(INT32 args)
 }
 #endif
 
+#ifdef TCP_NODELAY
+/*! @decl int(0..1) nodelay(int(0..1)|void state)
+ *!
+ *! Control Nagle's Algorithm (RFC 896)
+ *!
+ *! @param state
+ *!   @int
+ *! @value 0
+ *!   Return to the normal state of using Nagle's Algorithm
+ *! @value 1
+ *!   (default) Disable Nagling - small writes will not be queued.
+ *!   @endint
+ *!
+ *! @returns
+ *!   Returns @expr{1@} on success, and @expr{0@} (zero) on failure.
+ *!
+ *! @note
+ *!   This operation is only valid on sockets.
+ */
+static void file_nodelay(INT32 args)
+{
+  int fd = FD;
+  int state = 1;
+
+  if(fd  0)
+Pike_error(File not open.\n);
+
+  get_all_args(Stdio.File-nodelay, args, .%d, state);
+
+  if (state  state != 1) {
+SIMPLE_BAD_ARG_ERROR(Stdio.File-nodelay(), 1, int(0..1));
+  }
+
+  errno = 0;
+  while ((fd_setsockopt(fd, IPPROTO_TCP, TCP_NODELAY,
+			state, sizeof(state))  0) 
+	 (errno == EINTR)) {
+errno = 0;
+  }
+  if (errno) {
+ERRNO = errno;
+push_int(0);
+  } else {
+push_int(1);
+  }
+}
+#endif
+
 static int do_close(int flags)
 {
   struct my_file *f = THIS;
diff --git a/src/modules/_Stdio/file_functions.h b/src/modules/_Stdio/file_functions.h
index 0898655..3ca3f60 100644
--- a/src/modules/_Stdio/file_functions.h
+++ b/src/modules/_Stdio/file_functions.h
@@ -44,6 +44,12 @@ FILE_FUNC(linger, file_linger,
 	  tFunc(tOr3(tInt_10, tWord, tVoid), tInt01))
 #endif
 
+#ifdef TCP_NODELAY
+/* function(int(0..1)|void:int(0..1)) */
+FILE_FUNC(nodelay, file_nodelay,
+	  tFunc(tOr(tInt01, tVoid), tInt01))
+#endif
+
 #ifdef HAVE_FSYNC
 /*  function(:int) */
 FILE_FUNC(sync, file_sync, tFunc(tNone,tInt))
-- 
1.7.10.4

From 23804eff162b8f104cef3abe2f516556484c8d3c Mon Sep 17 00:00:00 2001
From: Chris Angelico ros...@gmail.com
Date: Sat, 15 Mar 2014 11:11:05 +1100
Subject: [PATCH 2/3] Represent G_TYPE_POINTER as an integer to prevent
 segfaults

---
 src/post_modules/GTK2/source/support.c |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/src/post_modules/GTK2/source/support.c b/src/post_modules/GTK2/source/support.c
index 072eb7c..dfa5eb3 100644
--- a/src/post_modules/GTK2/source/support.c
+++ b/src/post_modules/GTK2/source/support.c
@@ -599,9 +599,7 @@ static int pgtk2_push_object_param(const GValue *a) {
 }
 
 static int pgtk2_push_pike_object_param(const GValue *a) {
-  struct object *o=g_value_get_pointer(a);
-  if (o)
-ref_push_object(o);
+  push_int64((LONGEST)g_value_get_pointer(a));
   return PUSHED_VALUE;
 }
 
-- 
1.7.10.4

From 3c0133375b65afa188fa1b119f234fc172d54743 Mon Sep 17 00:00:00 2001
From: Chris Angelico ros...@gmail.com
Date: Sat, 15 Mar 2014 23:08:34 +1100
Subject: [PATCH 3/3] Ensure something's pushed for every argument to a GTK2
 signal callback

---
 src/post_modules/GTK2/source/support.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/post_modules/GTK2/source/support.c

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

[Chris Angelico]

gcc on Linux is warning of an assignment that removes 'const', in a
situation where the function's argument is const and the function then
mutates via a local pointer. Removing 'const' from the argument
silences the warning and makes it clear that the argument may be
changed; or if that's not true, 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: [PATCH] Remove 'const' qualifier from non-const hashtable

---
 src/hashtable.c |2 +-
 src/hashtable.h |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/hashtable.c b/src/hashtable.c
index f9b0d96..454d749 100644
--- a/src/hashtable.c
+++ b/src/hashtable.c
@@ -23,7 +23,7 @@ static size_t gobble(const struct pike_string *s)
 /*
  * Search hash for a specific string.
  */
-struct hash_entry *hash_lookup(const struct hash_table *h,
+struct hash_entry *hash_lookup(struct hash_table *h,
const struct pike_string *s)
 {
   struct hash_entry *e, **prev, **base;
diff --git a/src/hashtable.h b/src/hashtable.h
index 14f68c9..2fd08dc 100644
--- a/src/hashtable.h
+++ b/src/hashtable.h
@@ -32,7 +32,7 @@ struct hash_table
 };
 
 /* Prototypes begin here */
-struct hash_entry *hash_lookup(const struct hash_table *h,
+struct hash_entry *hash_lookup(struct hash_table *h,
const struct pike_string *s);
 struct hash_table *create_hash_table(void);
 struct hash_table *hash_rehash(struct hash_table *h,int size);
-- 
1.7.10.4

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

[Chris Angelico]

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
 commit from ulpc.

And before that, to the first import of ulpc - the only changes, as
far as I can see, are the name lpc_string becoming pike_string, and
then (very recently) the pointers got tagged const. Now THAT is stable
code!

So the question is, what does a 'const struct hash_table *' imply? Is
the entire table constant, or is it allowed to have mutable entries?
And if the latter, at what point should the compiler be told that it's
no longer const?

ChrisA

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

[Chris Angelico]

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 in any way.  If the struct
 contains other pointers, the things these pointers point at can be
 modified, but not if they point back into the current struct hash_table.

 The C-standard doesn't say it (AFAIK), but it is good practice that
 if the struct is part of an array or linked list, none of the other
 array or linked list elements are being modified either.

I know what the C standard means, I was wondering what it meant in the
context of Pike's data structures :) Does it make sense to declare
this parameter as const and then tell the compiler that hey, this bit
over here isn't const, or is it better to mark it all as mutable?

Marking the entire argument as mutable doesn't add any warnings
anywhere else, but that just means that nothing else is taking
advantage of its constness in a way the compiler can recognize.

ChrisA

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

[Chris Angelico]

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 at will not be modified in any way.  If the struct
 contains other pointers, the things these pointers point at can be
 modified, but not if they point back into the current struct hash_table.

I know what the C standard means, I was wondering what it meant in the
context of Pike's data structures :) Does it make sense to declare
this parameter as const and then tell the compiler that hey, this bit
over here isn't const, or is it better to mark it all as mutable?

 Given the fact that we cannot seem to guarantee that even the pointed to
 element is not modified, it should not be marked as const.

That's what I thought when I did up the patch, but my knowledge of the
code is from a quarter-hour of reading it over, not a decade or so of
intimate experience with the project :)

ChrisA

sprintf optimizations have issues with %{ %} - segfault

[Chris Angelico]

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 emits a fatal sprintf: fs-fsp incorrect after
recursive sprintf.. Bisecting a non-debug build pointed to 7fdf94 as
the crash culprit, but I couldn't replicate that bisection on a debug
build for some reason (the build didn't finish for several commits).

The problem seems to occur when %{ %} results in a reallocation of the
format_info_stack at the top of low_pike_sprintf (sprintf.c:1026).
There's a ptrdiff_t that doesn't seem to be used anywhere, and which
could be connected. I'm not sure why 7fdf94 should bring in the
problem, though, as it looks like a direct - almost mechanical -
translation.

ChrisA

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

[Chris Angelico]

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 actual potential
problem that that was supposed to be catching?

ChrisA

Re: Memory use

[Chris Angelico]

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

[Chris Angelico]

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 that mixes int and
float, which does an equivalent cast implicitly. Fiddling around with
the corresponding code suggests it may be connected to the GCC warning
that also comes up:

warning: dereferencing type-punned pointer will break strict-aliasing
rules [-Wstrict-aliasing]

In SET_SVAL, two pointers to the same object with different types are
used. I think this violates the C standard, which is why sometimes
stuff isn't getting correctly written out - something's getting
optimized away. Is there a way to do the same job with a union inside
struct svalue, instead of the pointer casts? Or alternatively, can the
compiler be told not to optimize this out?

ChrisA

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

[Chris Angelico]

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 \
  * svalue in case EXPR throws. */   \
 struct svalue * _sv_ptr=( SVAL );  \
 _sv_ptr-u.FIELD = (EXPR);  \
 *((ptrdiff_t*)_sv_ptr-type) = TYPE_SUBTYPE(TYPE,SUBTYPE);\
   } while(0)

Has exactly the same result.

It's entirely possible I'm misdiagnosing this. To come to the
conclusion I did, I took the current 8.0 branch, reverted that one
commit, and then began applying it piece by piece. The change to
configure.in didn't break anything, the change to svalue.h did. Within
that, changing from INT16 to short had no effect (on my system, I
believe INT16 compiles to short anyway); adding structures and unused
defines, unsurprisingly, didn't break anything; and changing the
definition of SET_SVAL induced the error message. That's all the info
I have to offer.

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.

ChrisA

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

[Chris Angelico]

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.
Thanks Grubba! Looking good.

ChrisA

Re: Hello

[Chris Angelico]

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

Welcome! I love Pike, it's a great language. Updating code on the fly
is a huge feature for me. I'm right this moment talking to one of my
users, and working through some bugs; he tells me of trouble, I dig
into it and find out what the problem is, and then I just tell him to
use the Update Gypsum menu item, and it downloads and applies the
update... live, without disconnecting him or anything.

What sorts of programs are you looking at writing in Pike?

ChrisA

Re: Hello

[Chris Angelico]

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:
http://pike.lysator.liu.se/pub/pike/all/7.8.700/Pike-v7.8.700.msi

On Linux, I like to build my own Pike from source. (This is partly
because I have a few patches which haven't yet been accepted into the
core - preventing some obscure segfaults in GTK2, mainly.) You can get
Pike from several distros' repositories, or you can fetch the source
and build, whichever you're more comfortable with.

On a Mac, I'm not sure what's best to use. I have an unofficial build
that includes GTK, or you can use the prebuilt 7.8.700, or you can
build from source as with Linux.

http://pike.lysator.liu.se/download/pub/pike/all/7.8.700/

 But after that, I will try to write some bioinformatic codes of my own,
 currently in C++
 I want to see if I can get better performances with Pike.

 But the web server side is also interesting... in fact, I think I will try a
 little bit of many things ;)

Cool!

You probably won't get better performance with Pike than with C++, but
you may well get something comparable. Pike's more similar to Python
than to C/C++; it's a high level language, designed to be easy to
write reliable code in. It might well not run faster, but it'll be a
LOT faster to get something that won't crash - for one thing, Pike
takes care of memory management. You can simply work with strings,
instead of allocating buffers and making sure you have enough room.
And strings store Unicode, not just bytes; important in today's
international world. Integers store arbitrary precision, so you'll
never have to worry about wraparound. Arrays are real things that can
be passed around; so are mappings, which are like std::unordered_map
(I think; I never used unordered_map much), and multisets. Functions
are first-class objects too, which is HUGELY helpful.

Here's a handy reference for the object model Pike uses. It's written
about Python, but the two follow the same structure.

http://nedbatchelder.com/text/names.html

It's cheap and fast to pass objects around, nothing gets copied unless
you ask for it.

ChrisA

Re: Pike 7.8.866 for Windows

[Chris Angelico]

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 modules that would
 be advantageous to add.

Compared against the Pike 7.8.700 build that I had previously been
using, all that's missing is Bz2 and SDL, neither of which is critical
to me. (SDL.Music is a prereq for an optional feature for Gypsum, but
one that I don't think anyone actually uses.) It's looking good so
far; not seeing any problems.

Was this off a completely unmodified source tree? Of the changes I
made to get the MinGW build working, at least a couple look like
they'd be necessary on any compiler, like Nettle/nt.cmod needing
nettle_config.h included. If that works unmodified on the MS compiler,
I'll have to go back to the drawing board with those patches.

ChrisA

Possible bug in Gz with latest Pike 7.8.866 Windows?

[Chris Angelico]

Not sure how to diagnose this. Test case:

int main()
{
string 
zip=E\217Aj\31\fE\367s\212OV-\204\\\243\27\310\276(cMF\240X\306\226;8\247\217fh\323\225\340\363y\377\351\272JC\222\312\263[\35\230)\343\306\350\215\23\26\253P\233IQ\264\337%\2673\266U\346\25T\31\331\34\205\252\303\26\370\312x\220\344\351k\224\326\37\250\\\254\311\316\273\340\272\362\300\252;V\215R\200iq\256
}\203!\371\r\371\313\246\177\251\217\324\31nQ\t\327\33K\276\207\247j\220N\317\347\367\241x\2\345\24\205\336\320\254\372^Qj\376y\336\363\351\330\317\374\23\253aaq\267*\356\34\277\216(\f\364\222\310\217\215\337\27\304\33\353r\231^;
object infl=Gz.inflate(-15);
string data=infl-inflate(zip);
write(Inflated %d bytes to %d; end-of-stream ought to be \\:
%O\n,sizeof(zip),sizeof(data),infl-end_of_stream());
}

Yeah, that's hardly minimal, sorry. It does seem to be data-dependent.

On Pike 8.0 on Linux, this produces:

Inflated 185 bytes to 287; end-of-stream ought to be : 

This is correct. The given byte stream is a complete deflation
sequence, and end-of-stream is reached with no additional data. Pike
7.8.866 on Windows (the current .msi) says 0 at the end, instead -
implying that it's still looking for more data.

I'm no expert on compression algorithms, so I have no idea what's
going on here. Is it some kind of weird bug in zlib?

ChrisA

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

[Chris Angelico]

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 used for previous 
 pike builds (thought probably not recently). Seems odd that the lib would be 
 at fault, but what do I know?


Yeah, I had no problems with 7.8.700, but once my users started
upgrading to 866, I saw problems. It's really odd.

ChrisA

Codepage decoding tables have incorrect data

[Chris Angelico]

Was doing some codepage work (playing with CP437), and found that the
Pike CP-437 decoder actually produces wrong output, according to the
unicode.org template file. I'm not sure what's going on here; is there
some alternate standard that it's adhering to?

Here are two scripts to compare codepage decoding in Pike and Python:

int main(int argc,array(string) argv)
{
object decoder=Charset.decoder(argv[1]);
for (int byte=128;byte255;++byte)
write(%02x: %04x\n,byte,decoder-feed((string)({byte}))-drain()[0]);
}

import sys
for byte in range(128,255):
print(%02x:
%04x%(byte,ord(bytes([byte]).decode(sys.argv[1],errors=replace

$ diff (pike charsets.pike 437) (python3 charsets.py 437)

This should in theory be absolutely silent, but in practice it reports
a number of differences in the decode. Wikipedia cites a file on
www.unicode.org as its source:

http://en.wikipedia.org/wiki/Code_page_437
http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/PC/CP437.TXT

and that file agrees with Python's decoding. I've put together a
script to download a file from the above URL and patch the info into
the appropriate place in src/modules/_Charset/misc.c, and have run 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 codepage decoding tables based on
 www.unicode.org files

---
 src/modules/_Charset/misc.c |  212 +--
 1 file changed, 106 insertions(+), 106 deletions(-)

diff --git a/src/modules/_Charset/misc.c b/src/modules/_Charset/misc.c
index 51ed656..f561645 100644
--- a/src/modules/_Charset/misc.c
+++ b/src/modules/_Charset/misc.c
@@ -1010,16 +1010,16 @@ static const p_wchar1 map_IBM437[] = {
   0x00ff, 0x00d6, 0x00dc, 0x00a2, 0x00a3, 0x00a5, 0x20a7, 0x0192,
   0x00e1, 0x00ed, 0x00f3, 0x00fa, 0x00f1, 0x00d1, 0x00aa, 0x00ba,
   0x00bf, 0x2310, 0x00ac, 0x00bd, 0x00bc, 0x00a1, 0x00ab, 0x00bb,
-  0x2591, 0x2592, 0x2593, 0x2502, 0x2524, 0x2525, 0x2528, 0x2512,
-  0x2511, 0x252b, 0x2503, 0x2513, 0x251b, 0x251a, 0x2519, 0x2510,
-  0x2514, 0x2534, 0x252c, 0x251c, 0x2500, 0x253c, 0x251d, 0x2520,
-  0x2517, 0x250f, 0x253b, 0x2533, 0x2523, 0x2501, 0x254b, 0x2537,
-  0x2538, 0x252f, 0x2530, 0x2516, 0x2515, 0x250d, 0x250e, 0x2542,
-  0x253f, 0x2518, 0x250c, 0x2588, 0x2584, 0x258c, 0x2590, 0x2580,
-  0x03b1, 0x03b2, 0x0393, 0x03c0, 0x03a3, 0x03c3, 0x03bc, 0x03c4,
-  0x03a6, 0x0398, 0x03a9, 0x03b4, 0x221e, 0x2205, 0x03b5, 0x2229,
+  0x2591, 0x2592, 0x2593, 0x2502, 0x2524, 0x2561, 0x2562, 0x2556,
+  0x2555, 0x2563, 0x2551, 0x2557, 0x255d, 0x255c, 0x255b, 0x2510,
+  0x2514, 0x2534, 0x252c, 0x251c, 0x2500, 0x253c, 0x255e, 0x255f,
+  0x255a, 0x2554, 0x2569, 0x2566, 0x2560, 0x2550, 0x256c, 0x2567,
+  0x2568, 0x2564, 0x2565, 0x2559, 0x2558, 0x2552, 0x2553, 0x256b,
+  0x256a, 0x2518, 0x250c, 0x2588, 0x2584, 0x258c, 0x2590, 0x2580,
+  0x03b1, 0x00df, 0x0393, 0x03c0, 0x03a3, 0x03c3, 0x00b5, 0x03c4,
+  0x03a6, 0x0398, 0x03a9, 0x03b4, 0x221e, 0x03c6, 0x03b5, 0x2229,
   0x2261, 0x00b1, 0x2265, 0x2264, 0x2320, 0x2321, 0x00f7, 0x2248,
-  0x2218, 0x00b7, 0x2219, 0x221a, 0x207f, 0x00b2, 0x25a0, 0x00a0, };
+  0x00b0, 0x2219, 0x00b7, 0x221a, 0x207f, 0x00b2, 0x25a0, 0x00a0, };
 static const p_wchar1 map_IBM500[] = {
   0xfffd, 0xfffd, 0xfffd, 0xfffd, 0xfffd, 0xfffd, 0xfffd, 0xfffd,
   0xfffd, 0xfffd, 0xfffd, 0xfffd, 0xfffd, 0xfffd, 0xfffd, 0xfffd,
@@ -1057,15 +1057,15 @@ static const p_wchar1 map_IBM850[] = {
   0x00e1, 0x00ed, 0x00f3, 0x00fa, 0x00f1, 0x00d1, 0x00aa, 0x00ba,
   0x00bf, 0x00ae, 0x00ac, 0x00bd, 0x00bc, 0x00a1, 0x00ab, 0x00bb,
   0x2591, 0x2592, 0x2593, 0x2502, 0x2524, 0x00c1, 0x00c2, 0x00c0,
-  0x00a9, 0x252b, 0x2503, 0x2513, 0x251b, 0x00a2, 0x00a5, 0x2510,
+  0x00a9, 0x2563, 0x2551, 0x2557, 0x255d, 0x00a2, 0x00a5, 0x2510,
   0x2514, 0x2534, 0x252c, 0x251c, 0x2500, 0x253c, 0x00e3, 0x00c3,
-  0x2517, 0x250f, 0x253b, 0x2533, 0x2523, 0x2501, 0x254b, 0x00a4,
+  0x255a, 0x2554, 0x2569, 0x2566, 0x2560, 0x2550, 0x256c, 0x00a4,
   0x00f0, 0x00d0, 0x00ca, 0x00cb, 0x00c8, 0x0131, 0x00cd, 0x00ce,
   0x00cf, 0x2518, 0x250c, 0x2588, 0x2584, 0x00a6, 0x00cc, 0x2580,
-  0x00d3, 0x00df, 0x00d4, 0x00d2, 0x00f5, 0x00d5, 0x03bc, 0x00de,
-  0x00fe, 0x00da, 0x00db, 0x00d9, 0x00fd, 0x00dd, 0x2014, 0x00b4,
-  0x00ad, 0x00b1, 0x21d4, 0x00be, 0x00b6, 0x00a7, 0x00f7, 0x02db,
-  0x00b0, 0x00a8, 0x02d9, 0x00b9, 0x00b3, 0x00b2, 0x25a0, 0x00a0, };
+  0x00d3, 0x00df, 0x00d4, 0x00d2, 0x00f5, 0x00d5, 0x00b5, 0x00fe,
+  0x00de, 0x00da, 0x00db, 0x00d9, 0x00fd, 0x00dd, 0x00af, 0x00b4,
+  0x00ad, 0x00b1, 0x2017, 0x00be, 0x00b6, 0x00a7, 0x00f7, 0x00b8,
+  0x00b0, 0x00a8, 0x00b7, 0x00b9, 0x00b3, 0x00b2, 0x25a0, 0x00a0, };
 static const p_wchar1 map_IBM851[] = {
   0x00c7, 0x00fc, 0x00e9, 0x00e2, 0x00e4, 0x00e0, 0x0386, 0x00e7,
   0x00ea, 0x00eb, 0x00e8, 0x00ef

Re: Codepage decoding tables have incorrect data

[Chris Angelico]

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 not part of
 the Unicode standard, so they are no more a standard than RFC 1345 is.

Oh! Okay. What is the standard? Where would I find an authoritative
set of codepage-to-Unicode character set replacements?

All I can confirm is that, with the changes I put through, Pike agrees
with Python 3.4, and codepage 437 looks right, neither of which is
anything official.

ChrisA

Re: Codepage decoding tables have incorrect data

[Chris Angelico]

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 not part of your patch.

 Many of the remaining changes suggested are a bit dubious though.

 For example, in IBM 437 you proposed the following changes:

 0xe1: GREEK SMALL LETTER BETA - LATIN SMALL LETTER SHARP S
 0xe6: GREEK SMALL LETTER MU - MICRO SIGN
 0xed: EMPTY SET - GREEK SMALL LETTER PHI

Like I said, I didn't have an authoritative source (as I didn't know
where to find one), and so I used two non-authoritative sources, which
happened to agree: the unicode.org files, and Python 3. Up to you what
you want to apply; the part that I was most noticing was the box
drawing characters, which I thought was actually a font error (as I
wasn't seeing the double lines).

ChrisA

Re: Codepage decoding tables have incorrect data

[Chris Angelico]

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, so feel free to raise a new issue if you find
 something else which is a concrete problem.

Yeah, I agree. Codepages are a mess anyway; as long as there's some
kind of reasonably sane translation done, it's as good as it's going
to be.

 (As a side note, I think you were justified in assuming thick/double
  lines was a font issue.  There is no semantical difference, so I
  imagine the only reason why Unicode assigns separate codepoints to
  them instead of treating them as font variants is for compatibility
  with some other encoding that has both...)

No idea. To be quite honest, I wasn't even aware of those other
box-drawing characters' existence until I came across this... there's
so much Unicode that it's impossible to see it all.

ChrisA

Re: Hilfe-crash.

[Chris Angelico]

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 good-sized .hilfe_history. I was unable
to reproduce the crash with no history, or with just a couple of
lines. The crash happens as you describe if there are at least 9 lines
in history; if there are exactly 8, then pressing up won't crash, but
pressing down afterward will.

Don't know if that helps at all or not.

ChrisA

Re: zero_type of implicit return

[Chris Angelico]

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

ChrisA

Re: zero_type of implicit return

[Chris Angelico]

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 return, but never checking its zero_type.

ChrisA

Removal of 7.2 compat broke Stdio.read_file

[Chris Angelico]

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:

rosuav@sikorsky:~/pike$ pike readfileboom.pike
/home/rosuav/pike/src/cyclic.c:39: Fatal error:
Unlink cyclic on lost cyclic struct.
/usr/local/pike/8.0.3/lib/modules/Stdio.pmod/Terminfo.pmod:920:Indexing
on illegal type.
/usr/local/pike/8.0.3/lib/modules/Stdio.pmod/Terminfo.pmod:920:Got : zero.
/usr/local/pike/8.0.3/lib/modules/Stdio.pmod/Terminfo.pmod:920:Index
: string(97..116).
/usr/local/pike/8.0.3/lib/modules/Stdio.pmod/Terminfo.pmod:936:Placeholder
already has storage!
/usr/local/pike/8.0.3/lib/modules/Stdio.pmod/Readline.pike:220:Must
return a value for a non-void function.
/usr/local/pike/8.0.3/lib/modules/Stdio.pmod/Readline.pike:220:Expected: mixed.
/usr/local/pike/8.0.3/lib/modules/Stdio.pmod/Readline.pike:220:Got : void.
/usr/local/pike/8.0.3/lib/modules/Stdio.pmod/Readline.pike:279:Must
return a value for a non-void function.
/usr/local/pike/8.0.3/lib/modules/Stdio.pmod/Readline.pike:279:Expected: mixed.
/usr/local/pike/8.0.3/lib/modules/Stdio.pmod/Readline.pike:279:Got : void.
/usr/local/pike/8.0.3/lib/modules/Stdio.pmod/Readline.pike:289:Must
return a value for a non-void function.
/usr/local/pike/8.0.3/lib/modules/Stdio.pmod/Readline.pike:289:Expected: mixed.
/usr/local/pike/8.0.3/lib/modules/Stdio.pmod/Readline.pike:289:Got : void.
/usr/local/pike/8.0.3/lib/modules/Stdio.pmod/Readline.pike:299:Must
return a value for a non-void function.
/usr/local/pike/8.0.3/lib/modules/Stdio.pmod/Readline.pike:299:Expected: mixed.
/usr/local/pike/8.0.3/lib/modules/Stdio.pmod/Readline.pike:299:Got : void.
/usr/local/pike/8.0.3/lib/modules/Stdio.pmod/Readline.pike:321:Must
return a value for a non-void function.
/usr/local/pike/8.0.3/lib/modules/Stdio.pmod/Readline.pike:321:Expected: mixed.
/usr/local/pike/8.0.3/lib/modules/Stdio.pmod/Readline.pike:321:Got : void.
/usr/local/pike/8.0.3/lib/modules/Stdio.pmod/Readline.pike:406:Must
return a value for a non-void function.
/usr/local/pike/8.0.3/lib/modules/Stdio.pmod/Readline.pike:406:Expected: mixed.
/usr/local/pike/8.0.3/lib/modules/Stdio.pmod/Readline.pike:406:Got : void.
/usr/local/pike/8.0.3/lib/modules/Stdio.pmod/Readline.pike:1394:Must
return a value for a non-void function.
/usr/local/pike/8.0.3/lib/modules/Stdio.pmod/Readline.pike:1394:Expected: mixed.
/usr/local/pike/8.0.3/lib/modules/Stdio.pmod/Readline.pike:1394:Got : void.
/usr/local/pike/8.0.3/lib/modules/Stdio.pmod/Readline.pike:1437:Must
return a value for a non-void function.
/usr/local/pike/8.0.3/lib/modules/Stdio.pmod/Readline.pike:1437:Expected: mixed.
/usr/local/pike/8.0.3/lib/modules/Stdio.pmod/Readline.pike:1437:Got : void.
/usr/local/pike/8.0.3/lib/modules/Stdio.pmod.0:-: Warning: Compilation
failed: Compilation failed.
Backtrace at time of fatal:
-:1: PikeCompiler(, UNDEFINED, -1, -1, target, placeholder)-compile()
-:1: DefaultCompilerEnvironment-compile(PikeCompiler(, UNDEFINED,
-1, -1, target, placeholder))
/usr/local/pike/8.0.3/lib/master.pike:790:
compile_string(#pike __REAL_VERSION__\n\ninherit
_Stdio;\n\n#ifdef
+[94107],/usr/local/pike/8.0.3/lib/modules/Stdio.pmod/mod+[9],0,object_program(Stdio),object(/usr/local/pike/8.0.
3/lib/modules/Stdio.pmod/module.pmod),UNDEFINED)
/usr/local/pike/8.0.3/lib/master.pike:1533:
master()-low_findprog(/usr/local/pike/8.0.3/lib/modules/Stdio.pmod/module.pmod,,0,1)
/usr/local/pike/8.0.3/lib/master.pike:1656:
master()-findprog(/usr/local/pike/8.0.3/lib/modules/Stdio.pmod/module.pmod,.pmod,0,1)
/usr/local/pike/8.0.3/lib/master.pike:1690:
master()-low_cast_to_program(/usr/local/pike/8.0.3/lib/modules/Stdio.pmod/module,0,0,1)
/usr/local/pike/8.0.3/lib/master.pike:1939:
master()-low_cast_to_object(/usr/local/pike/8.0.3/lib/modules/Stdio.pmod/module.pmod,0,0)
/usr/local/pike/8.0.3/lib/master.pike:2157: Stdio-low_ind(module,1)
/usr/local/pike/8.0.3/lib/master.pike:2074: Stdio-module_checker()-`!()
/usr/local/pike/8.0.3/lib/master.pike:2214: Stdio-ind(read_file)
/usr/local/pike/8.0.3/lib/master.pike:2256: Stdio-`[](read_file)
/usr/local/pike/8.0.3/lib/master.pike:2432: Stdio-ind(read_file)
/usr/local/pike/8.0.3/lib/master.pike:2472: Stdio-`[](read_file)
-:1: PikeCompiler(, UNDEFINED, -1, -1, target, UNDEFINED)-compile()
-:1: DefaultCompilerEnvironment-compile(PikeCompiler(, UNDEFINED,
-1, -1, target, UNDEFINED))
/usr/local/pike/8.0.3/lib/master.pike:790:
compile_string(int main()
{write(Stdio.read_file(\readfileboom.pike\));}\n,/home/rosuav/pike/readfileboom.pike,UNDEFINED,/home/rosuav/pike/readfileboom,0,UNDEFINED)
/usr/local/pike/8.0.3/lib/master.pike:1533:
master()-low_findprog(/home/rosuav/pike/readfileboom,.pike,UNDEFINED,UNDEFINED)
/usr/local/pike/8.0.3/lib/master.pike:1651:

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

[Chris Angelico]

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 = String.Buffer();
foo = asdf;

Should that call foo-`=(asdf), or reassign foo? IMO it should
absolutely always reassign. Otherwise you get something like PHP's
references - a pain to work with.

ChrisA

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

[Chris Angelico]

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 dangerously magical. I'd much rather
mutation be done with methods (or augmented assignments).

ChrisA

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

[Chris Angelico]

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 to xy_to_index(). It'll be slower, as it has to do more work,
but it feels cleaner. Pike code constructs Pango layout objects using
Unicode strings, not UTF-8, so getting back character indexes makes
more sense than byte positions.

Branch: rosuav/naglingcontrol

Adds a new method nodelay() to Stdio.File to control the TCP_NODELAY
flag. This is definitely debatable, as there's now starting to be more
of a proliferation of flag-controlling methods. Would it be better to
have a single method to set/reset flags? How should detection of
available flags be done? (With the nodelay() method, the presence of
the function implies its callability.) If this were Python, we'd have
a lengthy python-ideas thread and probably a PEP to discuss this. :)

Thoughts?

ChrisA

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

[Chris Angelico]

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 call the
 one flag you want to set.

 Won't add too much, and make it easier for some people.  The individual
 methods could be nothing more than a wrapper around the setflag method with
 the appropriate flag.

Actually, that's a pretty cool way of doing it. I'll knock together a
new branch and see how it looks.

ChrisA

Setting socket options: so many, uhh, options!

[Chris Angelico]

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.

As to shortcut functions, though, there are a few ways they can be done.

1) set_keepalive() always exists, even if SO_KEEPALIVE isn't
available. If you call it when there's no SO_KEEPALIVE, it sets errno
and returns failure.
2) set_nodelay() exists only if TCP_NODELAY is available.
3) setsockopt() itself is useless without the constants, and
Stdio.TCP_NODELAY will exist only if TCP_NODELAY is available.

So in a Pike script, using setsockopt() requires either has_index()
run-time checks or #if compile-time checks for the options you want;
set_keepalive's model works easily if you know that the Pike version
you're targeting supports it; and set_nodelay's model lets you treat
older Pikes and systems without that feature the same way.

I'd rather make it as easy as possible on the Pike code. Which way
makes more sense?

ChrisA

Re: Refcounting gone wild?

[Chris Angelico]

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) Result: Stdio.File(0, 0, 777 /* fd=-1 */)
 _refs(c);
(5) Result: 4
 values(__);
(6) Result: ({ /* 5 elements */
2,
Stdio.File(0, 0, 777 /* fd=-1 */),
3,
Stdio.File(0, 0, 777 /* fd=-1 */),
4
})

ChrisA

Backport fix of program indexing

[Chris Angelico]

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 7.8, this fails with Indexing on illegal type.

ChrisA

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

[Chris Angelico]

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:

http://pike.lysator.liu.se/generated/manual/modref/ex/lfun_3A_3A/_backtick_add_eq.html

But it's a distinct difference from, say, the Python equivalent, so
it's worth making sure it's properly visible. Where would you go
looking for that info?

ChrisA

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

[Chris Angelico]

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 python-list:

 t = (Foo, [1,2], Bar)
 t[1] += [3]
Traceback (most recent call last):
  File pyshell#2, line 1, in module
t[1] += [3]
TypeError: 'tuple' object does not support item assignment
 t
('Foo', [1, 2, 3], 'Bar')

In Python, x += y becomes x = x.__iadd__(y), which means two things:

1) The object is asked to do an in-place addition with the new contents
2) Whatever is returned is stored back where x was.

The tuple rejects the second half of that (tuples are immutable, so
you can't assign to their members), but the first half has already
happened, and this causes some confusion.

With Pike's semantics, t[1] += whatever becomes t[1] = t[1] +
whatever, which won't change t[1] at all if the assignment fails.
There's a much stronger incentive to write explicit methods to do the
appending (in Python's case, lists have a .extend() method that's
better suited to this, but there's a temptation to use += anyway),
because it's guaranteed to be more efficient.

Personally, I think use of += for anything other than pure
optimization is a dangerous idea - the expected semantics aren't as
obvious as you might think. It's easy with immutables like strings and
integers (this is true in both Python and Pike, btw), but for
mutables, it's cleaner to work with methods.

ChrisA

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

[Chris Angelico]

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 
 http://pike.lysator.liu.se/generated/manual/modref/ex/lfun_3A_3A/_backtick_add.html

Neither of these is for the += case, though. If you click the link to
`+=, you get the info Tobias and I linked to.

ChrisA

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

[Chris Angelico]

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 conjunction with
 an `= lfun should result in an error reported to the programmer.

class Foo
{
mixed `=(Foo other) {...}
}

class Bar { }

int main()
{
string|Foo|Bar x=Foo();
x = Bar();
}


So this code would be illegal, then? What if x were declared as
mixed, or maybe as object instead of string|Foo|Bar?

Personally, I'm strongly against the idea of an assignment-replacement
operator. Assignment to a member is governed by the container (with
`[]= or `-=), and assignment to a simple name should just overwrite
it. Anything else would be extremely confusing.

(Side point: With the actual `=() line commented out, the above code
compiles and runs with no problems. But changing the declaration from
string|Foo|Bar to just Foo|Bar results in a compilation error,
syntax error, unexpected TOK_IDENTIFIER, expecting TOK_LEX_EOF or
';'. It seems the parser's unable to handle piped declarations that
don't start with a recognized name. I'd never noticed that till now,
which I guess means it's not much of a limitation!)

ChrisA

Editing the Pike tutorial - where is it?

[Chris Angelico]

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 source files in the main Pike tree. Poking around
with the code librarian didn't show me anything, though I may have
missed something. Where is the tutorial rendered from?

ChrisA

Re: Editing the Pike tutorial - where is it?

[Chris Angelico]

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 data for you, but the zip command isn’t 
 present on the new server, so I’ll have to defer to an admin on that server 
 to help you out. Can someone with privs on the pike web server help Chris, or 
 install zip so that I can?


I can handle many archive formats - do you have tar?

ChrisA

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

[Chris Angelico]

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 returning a flat array. Example
implementation in branch rosuav/pgm_all_inherits - what do you think?

ChrisA

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

[Chris Angelico]

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

 Not quite... Take a closer look at the loop -- It isn't a foreach()...

I could document it as such, but it strikes me that this should be
recursive, similar to inherit_tree but returning a flat array. Example
implementation in branch rosuav/pgm_all_inherits - what do you think?

 No need for a new implementation; the current already does it.

Ooh.. right. I looked at it and misread it as a
manually-implemented foreach. Okay. In that case, I'll document it
as-is, but also add an explanatory comment for the benefit of the next
person.

ChrisA

Re: Freeze of Debian 8.0 jessie

[Chris Angelico]

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

[Chris Angelico]

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 in 7.8 on Windows.
//In the latest 8.0, the first removal fails, so it shows ({ a })
and returns 1.
array(string) arr=({a,b,c});

int main()
{
add_constant(G,this);
compile_string(void x() {string z=\a\; G-arr-=({z});})()-x();
compile_string(void x() {string z=\b\; G-arr=G-arr-({z});})()-x();
compile_string(void x() {G-arr-=({\c\});})()-x();
write(%O\n,arr);
return sizeof(arr);
}


In theory, the three forms of element removal ought to be equivalent,
but the first one doesn't seem to be functional. I'm afraid the
details are a bit beyond me - the optimizer isn't something I'm
familiar with. All I know is, bisection points to that commit, and
reverting it on top of 8.0 makes the above script work correctly.
Sorry for the vagueness.

ChrisA

Re: Array augmented assignment doesn't always work

[Chris Angelico]

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.

It actually took me a while to make that test program. The failing
code was deep inside several levels of indirection, but when I tried
to do the same thing manually, I invariably used a string literal
instead of a string variable - and then it worked perfectly :)

But I'm glad there are these occasional over-optimization bugs.
They're part and parcel with a highly optimized interpreter, and
that's something I love about Pike.

ChrisA

Re: Pike 8.0

[Chris Angelico]

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 means we don't need to consider the
backporting of the program index bugfix, so I've deleted the branch.

Was having trouble building the latest, but a complete wipe-out (rm
-rf *; git checkout -f) fixed that. Not sure what the issue was,
doesn't much matter.

ChrisA

Re: Freeze of Debian 8.0 jessie

[Chris Angelico]

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.

ChrisA

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

[Chris Angelico]

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 stderr to stdout.) I
usually end up lifting the code of Process.run() and making a cut-down
version (as I don't need all its features); but the obvious
alternative would be to have Process.run itself provide this facility.

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(replace(data,\n,\r));}]));

Is this a feature worth adding?

ChrisA

Re: Text files

[Chris Angelico]

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 other people using?

ChrisA

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

[Chris Angelico]

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(replace(data,\n,\r));}]));

 Is this a feature worth adding?

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?

ChrisA

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

[Chris Angelico]

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 worth adding since it is
 something you often want.

Cool. Merged into 8.1. Should I put it into 8.0 as well?

ChrisA

Can Pike 8.0 drop string_to_unicode/unicode_to_string?

[Chris Angelico]

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 Pike 8.0 a good time to drop string_to_unicode() and unicode_to_string()?

ChrisA

Build failure when HAVE_NETTLE_ECDSA_H not set

[Chris Angelico]

/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 outside the HAVE_ block; branch
rosuav/survive_no_nettle_ecdsa does this. Is this the right approach,
or is there a better way?

ChrisA

Re: Build failure when HAVE_NETTLE_ECDSA_H not set

[Chris Angelico]

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 nicely!

ChrisA

Small tweak to Process.run() new feature

[Chris Angelico]

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}),
([stdout:({write,Stdio.File(output.txt,wct)-write}) ])
);

Maybe my idea of coolness is disrupted by the 36 degree weather we're
having here at the moment, but I just love the idea of putting
multiple outputs simply as multiple functions!

ChrisA

Unexpected and unused calls to resolv()

[Chris Angelico]

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 that above()
is never retrieved in that way.)

This normally wouldn't be a problem, but I use the resolv() calls to
detect dependencies, and this oddity was resulting in a file being
purportedly dependent on itself. (Was able to deal with that by
reordering code, fortunately.)

Any idea why this happens? Is it intended behaviour?

ChrisA


test.pike
Description: Binary data


main.pike
Description: Binary data

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

[Chris Angelico]

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 want? Dedicated functions for each job, or a thin
wrapper around setsockopt() itself?

ChrisA

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

[Chris Angelico]

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:

http://stackoverflow.com/questions/14388706/socket-options-so-reuseaddr-and-so-reuseport-how-do-they-differ-do-they-mean-t

ChrisA

Re: = Lambda shorthand syntax

[Chris Angelico]

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!

[Chris Angelico]

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 suggests that
nobody's particularly bothered one way or the other. Which version of
the API do you want? Dedicated functions for each job, or a thin
wrapper around setsockopt() itself?

 What about:
 a. A primary thin wrapper around setsockopt().
 b. Some secondary convenience functions for people unfamiliar with
setsockopt(2) only for those options which are commonly used.

aka both? Sure! Doesn't bother me! :)

ChrisA

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

[Chris Angelico]

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 -
although whether it actually improves performance or not is another
question. Example usage:

 Looks good.  Though it doubtful that setting this flag will have any
 noticeable effect on the current internet at large.

Maybe not on its own, but I can then apply traffic control rules on
the basis of TOS. At very least, patching this in allows me to play
around with the feature.

(Though it's looking like my current problem is better solved in other
ways anyway. Still nice to be able to experiment.)

ChrisA

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

[Chris Angelico]

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://stackoverflow.com/questions/14388706/socket-options-so-reuseaddr-and-so-reuseport-how-do-they-differ-do-they-mean-t

 Well, to be honest, I've only ever used and use REUSEADDR.
 I'd say reuseaddr is more useful than reuseport, because the difference
 will not be understood by the casual user, and reuseaddr has the
 DWIM advantage here.

Separately to the REUSE* questions, I've been experimenting today with
the IP_TOS settings, and to that end, dusted off this branch.

Changes today:

1) Rebased rosuav/sockopt onto the current 8.1, so it's now current again
2) Changed setsockopt() to take three parameters so the level can be specified
3) Added a bunch more constants, including some from a new header file.

The change is taking effect - I can see it in my outgoing logs -
although whether it actually improves performance or not is another
question. Example usage:

https://github.com/Rosuav/Gypsum/commit/945b88

ChrisA

Re: Possible parenthesization problem?

[Chris Angelico]

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?

[Chris Angelico]

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?

[Chris Angelico]

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 condition, not just
to the integer that's about to be compared to zero. Should this
become:

while(UNLIKELY(close(control_pipe[0])  0)  UNLIKELY(errno==EINTR));
while(UNLIKELY(close(control_pipe[1])  0)  UNLIKELY(errno==EINTR));

or is there something I'm not understanding about the nature of UNLIKELY()?

ChrisA

SSL curve ciphers

[Chris Angelico]

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

[Chris Angelico]

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 check for 0 size) is not one of the needed checks.

Ah cool! That would definitely be the cleanest form of the code, then.
I'll add it in and give it a try.

ChrisA

Re: split-string branch

[Chris Angelico]

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 ) )
   con-_writeme-output_to(con-_socket);

 This should be O(1) regardless of the buffer size, and in general
 slightly faster than strings even for short:ish buffers.

Presumably with the same check-and-trim behaviour, so it'd look like this:

conn-_writeme-consume(conn-_writeme-output_to(conn-_sock));

But the main problem is that, as far as I know, Stdio.Buffer is
available only in the newer Pikes. I guess it'll have to be guarded
with a #if constant(Stdio.Buffer), but that means maintaining another
code branch. Maybe I'll drop chunked mode in favour of automatically
using Stdio.Buffer if it's available, and just warn people On Pike
7.8, avoid outputting large amounts of data as it can cause
performance problems.

ChrisA

Re: split-string branch

[Chris Angelico]

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

[Chris Angelico]

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 S(str,1,2) from S(str,0,2) makes then be zero terminated.

 If you have a testcase, please try with that change.

Perfect! Thanks. This is why I didn't push anything to the main
branch. :) And yes, that makes sense; the error is about how
changedblahblahblahmassivelongstring isn't a recognized signal.

Since this change does fix the testcase, should I commit it to 8.1?

ChrisA

Re: split-string branch

[Chris Angelico]

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 seems aborting does not stop
 the commiting, and in this case a lot of the commits were not actually
 included).

 To fix this I just did a merge of the string split to 8.1. I assume
 there are alternative solutions, but there had been other commits done
 as well, and the merged commits are spread in time (some are merged),
 so in order to fix it quickly I just basically did the full commit.

It mostly works, but I did find one problem: some GTK signal
connections don't seem to work. Reverting part of the staticification
fixes it; I've committed such a reversion to branch
rosuav/nonstatic-gtk-strings if anyone wants to eyeball it. Is there
any way to verify that the reversion won't break anything?

ChrisA

Re: split-string branch

[Chris Angelico]

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

 The tail-string would be used for this somewhat unfortunate but rather
 common coding pattern:

 sscanf( str, %2c%s, part, str );

 and, in a similar manner:

 len = file-write(str);
 str = str[written..]

 These are both O(n^2), but if tail-of string are added they could both
 be about O(n), only reallocate the data if more than 50% is wasted.

This specific improvement would be useful to this code, although I'm
noticing the slowdown only when I do stupid stuff for benchmarking.

https://github.com/Rosuav/Hogan/blob/master/hogan.pike#L25

Figuring out a good chunk size in application code is hard. If I could
simply code idiomatically without chunking, and let the language worry
about efficiency, it'd be awesome.

ChrisA

C99, variadic macros, and rbtree.c

[Chris Angelico]

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, it'd be simple to change the definition
of rb_fatal to:

#define rb_fatal(NODE, ...) Pike_fatal(__VA_ARGS__)

What's the best way to go about this?

ChrisA

Re: switch and Math.nan

[Chris Angelico]

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 true. It would immediately fix all the inconsistencies with container
 types. The only purpose of NaN != NaN in the ieee standard seemed to
 have been to make it simple to detect NaN without having isnan().

 Would this be a compatibility problem? Do people detect Math.nan using x !=
 x?

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 isn't that it compares equal to itself, but that
container membership is based on a two-part check of identity and then
equality. Among other benefits, that allows automatic optimization of
the common case of iterating over the keys and retrieving the values,
since the keys will identity-match when you look them up. I think it'd
be a good model for Pike to imitate.

ChrisA

Re: switch and Math.nan

[Chris Angelico]

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 isn't that it compares equal to itself, but that
 container membership is based on a two-part check of identity and then
 equality. Among other benefits, that allows automatic optimization of
 the common case of iterating over the keys and retrieving the values,
 since the keys will identity-match when you look them up. I think it'd
 be a good model for Pike to imitate.


 The reason for NaN != NaN in IEEE is afaik the one I mentioned. Thanks
 for the clarification of what python does, I am not much of a python
 programmer.

 I am not so sure about the semantics of id(). It seems to be basically
 the pointer value of the storage location of the variable. Are floating
 point values in python passed by reference? Are they objects? This would
 not work in pike, because floats (as ints) are passed by value.

The semantics of id() in Python are deliberately nonspecific about any
precise meaning for that number; in CPython (the most common
interpreter) it's the address, but other Pythons use arbitrary
sequential numbers, or other schemes. All that matters is:

1) Every object has an identity.
2) If x is y, then id(x) == id(y)
3) If x is not y, then id(x) != id(y), as long as x and y exist
concurrently.

And yes, Python floats are objects - everything in Python is an
object. In Pike, with floats being value types, the notion of
identity might have to be expanded to bit-pattern, but that's
slightly less ideal, as it could result in two separately-generated
NaNs matching (which otherwise shouldn't happen). But stuffing two
different NaNs into a single mapping is going to be pretty rare.

ChrisA

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

[Chris Angelico]

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 through to this one.
> 1616   default:

Shouldn't Pike_fatal be marked as a non-returning function?

ChrisA

Re: C99, variadic macros, and rbtree.c

[Chris Angelico]

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 might be as an extension, not sure. But I have no
idea what compilers Pike supports and what C standards they support.

ChrisA

Re: 9233989: ecx and edx were mixed up

[Chris Angelico]

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 of course. Fixing that should make ia32 work with
> all compilers.

Ah, I didn't notice that it varied according to which assembler is
being used. What I saw was this:

#ifdef CL_X86_ASM_STYLE
__asm {
  mov eax, oper;
  mov edi, cpuid_ptr;
  cpuid;
  mov [edi], eax;
  mov [edi+4], ebx;
  mov [edi+8], edx;
  mov [edi+12], ecx;
};

which definitely stashes them into memory in order EAX/EBX/EDX/ECX,
which corresponds to the comment. I'm not familiar with the other
syntax, which uses =a, =r, =c, =d, but since you switched those, I'm
assuming they correspond to the Accumulator, Result??, Counter, and
Data registers.

Thanks!

ChrisA

Re: 9233989: ecx and edx were mixed up

[Chris Angelico]

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 output string is correct if called as ia32.c
> calls the code.

Heh, that's one way of making sure it's right :)

ChrisA

9233989: ecx and edx were mixed up

[Chris Angelico]

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, rather than warping other files around
the oddity of that operation. Thoughts?

ChrisA

Internal compiler error (push_compiler_frame0)

[Chris Angelico]

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

Re: Pike 8.0 beta

[Chris Angelico]

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

Awesome news! Soon as you have a Windows build, I'll start testing.
Can't wait to deprecate 7.8 support and start using new features.

Is the below information lifted straight from somewhere? There are a
couple of typos in it. If it was just for this email, no matter.

> o Added a shorthand syntax for integer rages: xbit, where x is a
>   number between 1 and 31. This can be used as an example to indicate
>   that a string is 8 bits wide only: string(8bit)

"integer rages" s/be "ranges".

> o Fixed interresting bug in the constant number parsing for octal
>   numbers in escapes.
>
>   For whatever reason 8:s were accepted for every location except the
>   first in octal numbers, so 078 was considered an alias for 0100.

"interresting" might be a mistake, or could be deliberate. Given the
context, I wouldn't be surprised if you intended it to be pronounced
"Interrresting". :)

So many cool new features.

ChrisA

Re: Pike 8.0 beta

[Chris Angelico]

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 email, no matter.
>
> It's straight from CHANGES, so feel free to fix them in git. :)

Done, thanks. Stupid me, I went searching for the text in the 8.1
branch - no wonder I couldn't find it :)

ChrisA

Re: Internal compiler error (push_compiler_frame0)

[Chris Angelico]

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 (string bad=x() //Missing close parenthesis
> {
> }
> };
> }
>

Thanks Grubba! Confirming that 648d9d fixes this, and also the
real-world case where I ran into this.

ChrisA

Over-eager optimization in Pike 8.1

[Chris Angelico]

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

Re: Promises in Pike vs other languages

[Chris Angelico]

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.
>
>
> And I definitely beg to differ that.
>
> Take this future-less code from a chat server:
>
> | void rpc_call_muc_join(ReturnCall x, mapping args )
> | {
> | [string muc,string who] = get_args(args,
> |"muc",stringp,
> |"inviter",ornull(stringp));
> |
> | Channel channel = get_destination( muc );
> | int when = now();
> |
> | channel->when_available()
> | {
> |   if( !channel->exists() )
> |  client_error(x, "No such channel" );
> |
> |   channel->joined( user->id, when ) {
> | me->join_channel( channel ) {
> |channel->add_message( msg( "joined",
> |   "user_ids",({format_destination(me)}),
> | "by",format_destination(me),
> |   "when", now)) {
> |  x(true); // return true.
> |};
> | };
> |   };
> |};
> | }
>
>
> Todays quiz: Is it really harder to read, and how many asynchronous levels
> do you think there is in it? :)

If you want your asynchronous code to look truly clean, the way
synchronous code does, there needs to be a way to have a function
pause its execution and let something else carry on. Python can do
this, either with generator functions or with the new async/await
keywords. Adapting the style to Pike syntax, it'd be something like
this:

async string talk_to_socket(string msg)
{
array(string) ips = await resolv("destination.ip.address");
foreach (ips, string ip)
{
Stdio.File sock = Stdio.File();
sock->open_socket();
if (await sock->connect(ip, 5678)) break;
}
await sock->write("helo\n");
await sock->write(msg + "\n");
string data = await sock->read(1024, 1);
sock->close();
return data;
}

Whenever you say "await", you trigger a sub-action, and the current
call gets suspended. It functions pretty much like cooperative
threading; effectively, any 'await' can result in a context switch.

Without language support like that, everything's going to be a pile of
(probably lambda) functions, one way or another.

ChrisA

Re: System.Memory and mmap()

[Chris Angelico]

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 periodically, until they get pinned
down and fixed. So Pike bugs _do_ happen, but you can ignore them in
mmap.

ChrisA

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

[Chris Angelico]

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
with the githelper hook using the 7.8/8.0 way of calling up Charset,
so I stuck in a #if to support the 8.0/8.1 way as well.

ChrisA

Re: Pike 8.0.162 release candidate

[Chris Angelico]

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 frustration. So Nettle, GMP, GTK and
> Freetype are all still versions from 2008 or so. That build will
> probably not be promoted to a real release. Use it at your own
> risk. I'll have another go at that in the coming weeks.
>

Hmm. I'd like to help out with GTK, at least - the regression against
current stable Pike (which is shipping 2.24.10 in the .msi) is a
problem for me, as I depend at least 2.16 for some features. The last
time I had GTK versioning issues on Windows, I put together this
collection of ready-to-go DLLs:

http://rosuav.com/gtk/

Dropping those files into the pike/bin directory makes GTK2.version()
return 2, 24, 10, but since the module wasn't actually built against
that version, functions like GTK2.Entry()->set_icon_from_stock simply
don't exist. So presumably it'll need to be done at an earlier step in
the build process.

ChrisA

Change of public key

[Chris Angelico]

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
-BEGIN PGP MESSAGE-
Version: GnuPG v1

owEBzgMx/JANAwAIAbNb8ssjWUwPAa0BnWIKaWRfcnNhLnB1YlapvG5zc2gtcnNh
IEFBQUFCM056YUMxeWMyRUFBQUFEQVFBQkFBQUJBUUNkNnFIakJqMU44UEF3Z1hC
elFIQ29sRHl2N1NYZW5lVzdFWnptbERtM2FHS2FJZFY3RnNiWS9MNTBScXQ1dHFn
NnlmSEI4YXB5cjc1L3NiS0tDM3loMStIUHVNSnI1U1FFTmRGQ3BQeDNmL3JKeml2
OGxNWXlzWWt5QVYzcjY0REg5Qm1KTUQ3SG5reElhYTlaMXVYODQ0RWQ0ZHNyYlND
SWV2YVV6bVJNMGEwSHlXRjdlQllEVkhwbkswR3NjVU1QNDJHdC9GOUVTaTM5WHdG
RytEVVZGVEwxSDV6YlliMG1BNXlhSG1HZmFBMXlmVVdHd0E0SUtta1MvYzdGaG5K
M2FWRmVpSm94ZHpmN1RLcVJPTG10S0FqeGVla0FjN2lLZVk5VUxObnMrcTFXTGlo
Mjl0R25ScDRqTGZYNURtUFFwS1IrSGFmbzQxQXBhbXpEVkIwRiByb3N1YXZAc2lr
b3Jza3kKiQIcBAABCAAGBQJWqbxuAAoJELNb8ssjWUwPDiQP/34g+o7riRAJYsPa
meFLUBoVz+hUwn3FRMLpV9U4aLzRtICHkYa7AF9sfFJvSs2ZgzNscSVMVXeZbj5F
Ol69jzmrRV1ifY7dgo617wG9m/yetMmvv6KA/SHA7p8U6ZZp0wHom1rpnyFt4jWX
iV4VvoihZcE6D/aJTGXy8dhIfNdOE/AR8OcqunmfjpLCLlUXofa+69t6VVnbYSuN
mYqbSZQy1xhTkFtp3X9WUBp4W/xQ3D4bomgMvBgc1zUii5usBrQ+MLoVWmixWwx2
GibcS2aggJWrYYet87s4VCZRZ6+RI6GoAB5QpTA2JsX9dRsB7/KBqCV8NV4TT5tV
+ljCtRM2fcpPVLvxmOARFFELELvhRCrVIkGUuDbDz+sZPECz2G2uWrUWjRDawW9n
dxaYZIZ5Y/tSogCDT7iMiZYhzLNR0F1Pq5LQHe7MNE++hbFdAzy4VqTlAoqMjaLv
DCf3A3yeCT0mCNubLjtjKo+rxxp5ha747jLku8G39oaaH9jezfnmzWuya99PnRtg
Ym40hoFnCewFE8ZG9ursLq/kp4GCj6DEmPY4iBQO2j5bQP2a+weiBZ/3kRS2D7L+
bm+lc2ZlkzLvDn3V5S9i6voADXsfIOMZR+bTdKrT71fchQWoy8bqtRPOIW0LAucI
9K1BCtz69uxoYqARW3BFI8bIdV8z
=zCIv
-END PGP MESSAGE-


id_rsa.pub
Description: application/vnd.ms-publisher