bug#24818: Clean up socket files set up by --listen=/path/to/socket-file

2017-03-08 Thread Christopher Allan Webber
Andy Wingo writes:

> I agree :)  Thanks for the patch!
>
> The patch goes in a direction that I'm a bit hesitant about though --
> this command-line processing is getting a bit intense.  Would it be
> possible to add a #:cleanup? argument to the spawn-server function
> instead?

I agree that my previous patch makes things more complicated, so I tried
the route you suggested, but...

> My only doubt would be whether all threads unwind when the program
> ends.  (And if they don't, is that a bug?  I am not sure but I would
> guess so; dunno.)

... and it doesn't seem to work for that reason.  The thread never seems
to unwind.  I put a print statement (not in this patch) at the very part
of the out guard but it never seems to run.  Too bad...

So I guess the question is whether or not addressing the thread issue as
a potential bug should be done or applying the previous patch version
which worked but made the command line processing more complex?  Or
something else?

From 79ab483a872638abe311c521c3467c060566b39c Mon Sep 17 00:00:00 2001
From: Christopher Allan Webber 
Date: Wed, 8 Mar 2017 12:04:55 -0600
Subject: [PATCH] Clean up socket file set up by --listen

[Unfortunately, this patch does not work because the thread doesn't seem
to unwind.  Submitted for demonstrative purposes, or in the hope that
could be fixed.]

* module/ice-9/command-line.scm (compile-shell-switches):
* module/system/repl/server.scm (run-server, run-server*, spawn-server):
  Clean up socket file set up by --listen on exit, if it exists.
---
 module/ice-9/command-line.scm |  3 ++-
 module/system/repl/server.scm | 44 +++
 2 files changed, 30 insertions(+), 17 deletions(-)

diff --git a/module/ice-9/command-line.scm b/module/ice-9/command-line.scm
index 98d385569..3305c671d 100644
--- a/module/ice-9/command-line.scm
+++ b/module/ice-9/command-line.scm
@@ -388,7 +388,8 @@ If FILE begins with `-' the -s switch is mandatory.
(error "invalid port for --listen"
  ((string-prefix? "/" where) ; --listen=/PATH/TO/SOCKET
   `((@@ (system repl server) spawn-server)
-((@@ (system repl server) make-unix-domain-server-socket) #:path ,where)))
+((@@ (system repl server) make-unix-domain-server-socket) #:path ,where)
+#:cleanup? #t))
  (else
   (error "unknown argument to --listen"
   out)))
diff --git a/module/system/repl/server.scm b/module/system/repl/server.scm
index 725eb4eda..1ced8e8d1 100644
--- a/module/system/repl/server.scm
+++ b/module/system/repl/server.scm
@@ -21,6 +21,7 @@
 
 (define-module (system repl server)
   #:use-module (system repl repl)
+  #:use-module (ice-9 and-let-star)
   #:use-module (ice-9 threads)
   #:use-module (ice-9 rdelim)
   #:use-module (ice-9 match)
@@ -84,11 +85,12 @@
 (bind sock AF_UNIX path)
 sock))
 
-(define* (run-server #:optional (server-socket (make-tcp-server-socket)))
-  (run-server* server-socket serve-client))
+(define* (run-server #:optional (server-socket (make-tcp-server-socket))
+ #:key (cleanup? #f))
+  (run-server* server-socket serve-client #:cleanup? cleanup?))
 
 ;; Note: although not exported, this is used by (system repl coop-server)
-(define (run-server* server-socket serve-client)
+(define* (run-server* server-socket serve-client #:key (cleanup? #f))
   ;; We use a pipe to notify the server when it should shut down.
   (define shutdown-pipes  (pipe))
   (define shutdown-read-pipe  (car shutdown-pipes))
@@ -122,19 +124,29 @@
   (sigaction SIGPIPE SIG_IGN)
   (add-open-socket! server-socket shutdown-server)
   (listen server-socket 5)
-  (let lp ()
-(match (accept-new-client)
-  (#f
-   ;; If client is false, we are shutting down.
-   (close shutdown-write-pipe)
-   (close shutdown-read-pipe)
-   (close server-socket))
-  ((client-socket . client-addr)
-   (make-thread serve-client client-socket client-addr)
-   (lp)
-
-(define* (spawn-server #:optional (server-socket (make-tcp-server-socket)))
-  (make-thread run-server server-socket))
+  (dynamic-wind
+(const #f)
+(lambda ()
+  (let lp ()
+(match (accept-new-client)
+  (#f
+   ;; If client is false, we are shutting down.
+   (close shutdown-write-pipe)
+   (close shutdown-read-pipe)
+   (close server-socket))
+  ((client-socket . client-addr)
+   (make-thread serve-client client-socket client-addr)
+   (lp)
+(lambda ()
+  (and-let* (cleanup?
+ (sa (getsockname server-socket))
+ (path (sockaddr:path sa))
+ ((file-exists? path)))
+(delete-file path)
+
+(define* (spawn-server #:optional (server-socket (make-tcp-server-socket))
+   #:key (cleanup? #f))
+  (make-thread run-server server-socket 

bug#26027: (system vm trace) creates no output

2017-03-08 Thread Mike Gran
Hi-
I created the following file, which I ran under guile-2.0 and master.
There is no tracing output. What am I misunderstanding?
(use-modules 
(system vm trace)) 

(define (write-hi) 
(write "hi")) 

(define (outer) 
(write-hi)) 

(trace-calls-to-procedure write-hi) 
(trace-calls-in-procedure write-hi) 
(trace-instructions-in-procedure write-hi) 
(outer) 

Thanks,
Mike Gran





bug#25912: 2.1.7 segfaults on cygwin

2017-03-08 Thread szgyg
On Mon, Mar 06, 2017 at 08:41:56PM +0100, Andy Wingo wrote:
> On Thu 02 Mar 2017 10:13, szgyg  writes:
> 
> > load_thunk_from_memory doesn't call mprotect because in loader.c
> > line 436 the ELF segment is aligned to 4k while page size is 64k.
> 
> Ah, thank you for tracking this down.  I think we were going to just
> change the page size to 64K for .go files but I can't remember.  I think
> libc's loader doesn't actually align the pages on disk but projects
> segments of the file onto the memory image.

Changing *page-size* to 64k in linker.scm solves the problem. Size of
bootstrap/ goes from 17MB to 20MB.


> What platform is this that has 64K pages?  IIUC cygwin's usual size is
> 4096 bytes.

Pagesize is 4k on windows, but we can't allocate a single page, only
batches of 16 pages. Cygwin is hiding this abomination by using 64k
as pagesize.





bug#26026: Defining a method named zero? breaks primitive zero?

2017-03-08 Thread Alejandro Sanchez
If I define a ‘zero?’ predicate method for a custom class the primitive ‘zero?’ 
is lost. Here is a simple vector module:

;;; File vector2.scm
(define-module (vector2)
  #:use-module (oop goops)
  #:export ( get-x get-y zero?))

(define-class  ()
  (x #:init-value 0 #:getter get-x #:init-keyword #:x)
  (y #:init-value 0 #:getter get-y #:init-keyword #:y) )

(define-generic zero?)
(define-method (zero? (v ))
  (and (zero? (get-x v))
   (zero? (get-y v

In the Guile REPL try executing the following code:

scheme@(guile-user)> (use-modules (oop goops) (vector2))
scheme@(guile-user)> (zero? (make ))

This will display 

WARNING: (guile-user): `zero?' imported from both (ice-9 r5rs) and 
(vector2)
ERROR: In procedure scm-error:
ERROR: No applicable method for #< zero? (1)> in call (zero? 0)

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
scheme@(guile-user) [1]> ,bt
In vector2.scm:
 11:7  2 (_ #< 105e87e00>)
In oop/goops.scm:
   1438:4  1 (cache-miss 0)
In unknown file:
   0 (scm-error goops-error #f "No applicable method for ~S in 
call ~S" (#< …) …)

Apparently the problem is that ‘zero?’ is defined in two modules and the 
vector2 definition overrides it. This isn’t the case with other primitives like 
‘+’ or ‘*’, so this seems like a bug? I had built Guile from HEAD a few days 
ago, my package manager shows 6fff84d as the version number, so I guess that 
must be the hash of the commit HEAD was pointing to at that time.