core-updates on Hurd

[rennes]

Good day,

currently the guix core-updates branch on GNU/Hurd, after start  
guix-daemon and issue the command './pre-inst-env guix build hello'  
fails with:

--
guix build: error: lstat: No such file or directory:  
"/home/jin/guix/gnu/packages/zation.scm"

--

At the moment I only see this error.

Re: RPC performance

[Ludovic Courtès]

Heya,

Andy Wingo  skribis:

> On Mon 19 Jun 2017 10:15, ludovic.cour...@inria.fr (Ludovic Courtès) writes:
>
>> +(define (buffering-output-port port buffer)
>> +  ;; Note: In Guile 2.2.2, custom binary output ports already have their own
>> +  ;; 4K internal buffer.
>> +  (define size
>> +(bytevector-length buffer))
>> +
>> +  (define total 0)
>> +
>> +  (define (flush)
>> +(put-bytevector port buffer 0 total)
>> +(set! total 0))
>> +
>> +  (define (write bv offset count)
>> +(if (zero? count) ;end of file
>> +(flush)
>> +(let loop ((offset offset)
>> +   (count count)
>> +   (written 0))
>> +  (cond ((= total size)
>> + (flush)
>> + (loop offset count written))
>> +((zero? count)
>> + written)
>> +(else
>> + (let ((to-copy (min count (- size total
>> +   (bytevector-copy! bv offset buffer total to-copy)
>> +   (set! total (+ total to-copy))
>> +   (loop (+ offset to-copy) (- count to-copy)
>> + (+ written to-copy
>> +
>> +  (let ((port (make-custom-binary-output-port "buffering-output-port"
>> +  write #f #f flush)))
>> +(setvbuf port _IONBF)
>> +port))
>> +
>
> Why not just set to _IOFBF and let Guile 2.2's buffering handle it?

Because we want controlled buffering when writing (we need to flush
pending output when we’re done writing the RPC request), and no
buffering at all when reading.

In C/C++ the way to do that is to have unbuffered streams and to do
application-level buffering by allocating output buffers of the right
size.

Thoughts?

Ludo’.

Re: RPC performance

[Andy Wingo]

On Mon 19 Jun 2017 10:15, ludovic.cour...@inria.fr (Ludovic Courtès) writes:

> +(define (buffering-output-port port buffer)
> +  ;; Note: In Guile 2.2.2, custom binary output ports already have their own
> +  ;; 4K internal buffer.
> +  (define size
> +(bytevector-length buffer))
> +
> +  (define total 0)
> +
> +  (define (flush)
> +(put-bytevector port buffer 0 total)
> +(set! total 0))
> +
> +  (define (write bv offset count)
> +(if (zero? count) ;end of file
> +(flush)
> +(let loop ((offset offset)
> +   (count count)
> +   (written 0))
> +  (cond ((= total size)
> + (flush)
> + (loop offset count written))
> +((zero? count)
> + written)
> +(else
> + (let ((to-copy (min count (- size total
> +   (bytevector-copy! bv offset buffer total to-copy)
> +   (set! total (+ total to-copy))
> +   (loop (+ offset to-copy) (- count to-copy)
> + (+ written to-copy
> +
> +  (let ((port (make-custom-binary-output-port "buffering-output-port"
> +  write #f #f flush)))
> +(setvbuf port _IONBF)
> +port))
> +

Why not just set to _IOFBF and let Guile 2.2's buffering handle it?

Andy

Re: (guix git) and guile-git finalizers.

[Andy Wingo]

Hi :)

Just some code review.

On Mon 19 Jun 2017 18:01, Mathieu Othacehe  writes:

> The idea here is to create a guardian per pointer-type to finalize. A
> pumper function that operates on this guardian is also created. This
> pumper function knows the git_libgit2_xxx function to call to free the
> pointers stored in guardians.

Neat.  A couple problems though.

  (1) All finalizable objects will be kept alive until they are removed
  from the guardian.  With guardians, you usually want to incrementally
  visit it during program execution: say, every time you allocate a new
  repository object.  Or via after-gc-hook.

  (2) Whether an object is visible in the guardian is not a very
  deterministic property.  It won't be returned from a guardian until
  all other references are gone, but there's no guarantee about when it
  will be returned -- depends on GC and many other factors.  So it's
  possible that repository objects are still "alive" after you shut down
  libgit.

Why do you feel the need to "shut down" libgit?  Honestly I would punt.
Most other libraries aren't like that.

Andy

Re: RPC performance

[Ricardo Wurmus]

Ludovic Courtès  writes:

> ludovic.cour...@inria.fr (Ludovic Courtès) skribis:
>
>> There are several ways we can improve it, and over time we should try to
>> implement all of them:
>>
>>   1. Buffer writes to the server socket (currently it’s terrible if you
>>  look at the ‘write’ calls in ‘strace’).
>
> Done in commit e037e9dbec1ab5a8cfaf65d73aa3afb2eeb98d71.  It doesn’t
> significantly improve performance, probably because the other problems
> are more acute, but it’s good to have.

Thanks!  I’m looking forward to getting the new NFS server ready and
benefiting from these improvemets.

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net