Re: [PATCH] Bindings for ‘sendfile’

[Mark H Weaver]

Hi Ludovic,

The sendfile commit (fbac7c6113056bc6ee85996b10bdc08325c742a5) has
caused the following build failures on Hydra.

Thanks,
  Mark


==
On GNU/Linux: (both i686-linux and x86_64-linux without threads)




checking sys/sendfile.h usability... yes
checking sys/sendfile.h presence... yes
checking for sys/sendfile.h... yes
[...]
checking for sendfile... yes

ERROR: filesys.test: sendfile: pipe - arguments: ((system-error #f "~A" 
("Function not implemented") (38)))
ERROR: filesys.test: sendfile: pipe with offset - arguments: ((system-error #f 
"~A" ("Function not implemented") (38)))

==
On FreeBSD: (x86_64-freebsd without threads)



checking sys/sendfile.h usability... no
checking sys/sendfile.h presence... no
checking for sys/sendfile.h... no
[...]
checking for sendfile... yes

filesys.c: In function 'scm_sendfile':
filesys.c:1140: warning: implicit declaration of function 'sendfile'

ERROR: filesys.test: sendfile: file - arguments: ((system-error "sendfile" "~A" 
("Bad file descriptor") (9)))
ERROR: filesys.test: sendfile: file with offset - arguments: ((system-error 
"sendfile" "~A" ("Bad file descriptor") (9)))
ERROR: filesys.test: sendfile: pipe - arguments: ((system-error #f "~A" 
("Function not implemented") (78)))
ERROR: filesys.test: sendfile: pipe with offset - arguments: ((system-error #f 
"~A" ("Function not implemented") (78)))

==
On Darwin: (x86_64-darwin, both with and without threads)




checking sys/sendfile.h usability... no
checking sys/sendfile.h presence... no
checking for sys/sendfile.h... no
[...]
checking for sendfile... yes

../../guile-2.0.7.227-86faf-dirty/libguile/filesys.c: In function 
'scm_sendfile':
../../guile-2.0.7.227-86faf-dirty/libguile/filesys.c:1142:8: warning: passing 
argument 3 of 'sendfile' makes integer from pointer without a cast [enabled by 
default]
/usr/include/sys/socket.h:619:5: note: expected 'off_t' but argument is of type 
'scm_t_off *'
../../guile-2.0.7.227-86faf-dirty/libguile/filesys.c:1142:8: warning: passing 
argument 4 of 'sendfile' makes pointer from integer without a cast [enabled by 
default]
/usr/include/sys/socket.h:619:5: note: expected 'off_t *' but argument is of 
type 'size_t'
../../guile-2.0.7.227-86faf-dirty/libguile/filesys.c:1142:8: error: too few 
arguments to function 'sendfile'
/usr/include/sys/socket.h:619:5: note: declared here
make[3]: *** [libguile_2.0_la-filesys.lo] Error 1

Re: Special variables to relax boxing

[Stefan Israelsson Tampe]

There are some bugs in the semantics. I try to fix them here


Consider
* k, the r5rs continuation
* dynamic-wind, r5rs dynamic wind with the addition that continuation
k is an argument
   to the rewinder.

 Introduce (with-special ((a:id kind:object) ...) code ...) and
(set~  a:id v:obj)

Introduce
(special-set! i k value)
(special-ref i k)
A setter and a getter of an object indexed by i and k

Also define
(guard-special? k kind)

That index an object on k, wich depedning on kind ask to restore the value
of the old saved state.

Let (make-id) generate a unique object

Then the semantic for with-special in guard mode would be

(let ((last #f)
  (i  (make-id)))
   (dynamic-wind
  (lambda (k)
 (set! last #f)
 (when (guard-special? k kind)
 (set! a (special-ref i k
  (lambda ()
 (call-with-values (lambda () (begin code ...))
(lambda ret
   (set! last #t)
   (apply values ret
  (lambda (k . l)
 (unless last
 (special-set! i k a

 Guard mode is entered only if a is referenced with set~ and never with
 set! if it can be proved
 Otherwise guard mode is never entered. The semantics of set~ is the
 same as with set! otherwise.

 if with-special is not in guard-mode then it behaves just as (let ()
code )

Hope that I don't spam the list but guile is a cooperative effort.

/Stefan

Re: TeXInfo-related build failure

[Mark H Weaver]

Dmitry Bogatov  writes:
> Hello, list. I encountered following error, trying to build guile
> from git with `makeinfo (GNU texinfo) 5.1`.

I believe these problems have been fixed on the stable-2.0 branch of the
Guile git repo, but the fixes have not yet been merged into master.

 Mark

Re: Special variables to relax boxing

[Stefan Israelsson Tampe]

Ok, I have felt your punches against the idea and have thought about it
somewhat more.

1. I can only conclude that today it's already difficult to reason about code
with respect to multiple restarts of continuation and the main reason is that
at least I have been sloppy to add a ! to the macros that use set! internally.

To a fun example:

I have been pondering to poer common-lisp iterate for fun to learn and enjoy
guile. In there they have generators e.g. (generati i ...) and then take out the
values with (next i) construct. For a simple i = 1 ... one would expand next i
to (begin (set! i (+ i 1)) i). So next is really next!. So this will
not mix well with
undo and redo. It's possible to define i as a special variable though
and you will
get the feature of proper undo redo support but now another problem appears
we will as Mark and Daniel introduce i into any uses of next i in user
and can get
hard to reason about properties when the value is put into a lambda. So next
is not next or next! but what? maybe next~ To indicate that lambdas that include
this must expect to mutate when one does a redo!. Conventions like this is
problematic because coders will most certainly be sloppy to follow
this convention
resulting in a mess. One really long for a type system to help clarify
the matters here.

Typically macro writers that post a binding a, might want users to use
the underlying
a~, variable as well and it would probably be good practice to let
users refer to this
at will e.g. reference it with (~ a), set it with (set~ a 1) as well
as (set! a 1) and refer
to it with e.g. a just as ordinary scheme. I would suggest that both
reference a variable
with set!,a, and with set~, (~ a) should be an error. Otherwise if the
macro writer
manages the macro  correct and basically uses a user guard that we
should provide
e.g. (with-user (a) user-code ...) especially this means that if a is
set! ed then we know
that redo undo cannot work and we will force the underlying variable
to be a usual
variable.

To accomplish this I would formulate the semantics as follows.

Consider
* k, the r5rs continuation
* dynamic-wind, r5rs dynamic wind with the addition that k is an argument
  to the rewinder.

Introduce (with-special ((a:id kind:object) ...) code ...) and (set~
a:id v:obj)

Let self identifying the dynamic wind object lexically

Introduce
(special-set! self k value)
(special-ref self k)

Also define
(guard-special? k kind)
A setter and a getter of an object indexed by self and k

Then the semantic for with-special in guard mode would be

(let ((last #f))
  (dynamic-wind
 (lambda (k)
(when (guard-special? k kind)
(set! a (special-ref self k
 (lambda ()
(call-with-values (lambda () (begin code ...))
   (lambda ret
  (set! last #t)
  (apply values ret
 (lambda (k . l)
(unless last
(special-set! self k a

Guard mode is entered only if a is referenced with set~ and never with
set! if it can be proved
Otherwise guard mode is never entered. The semantics of set~ is the
same as with set! otherwise.

if with-special is not in guard-mode then it behaves just as (let ()  code )

I really hope that I mange to converge a good concept with this discussion!

WDYT










On Thu, Mar 21, 2013 at 8:03 PM, Mark H Weaver  wrote:
> Stefan, you're still describing your proposal in terms of low-level
> implementation details such as stacks.  In the general case, we cannot
> store environment structures on the stack.  Furthermore, in the general
> case *all* variables in scheme are bound to locations, not values.  Only
> in special cases can we use stacks, and only in special cases can we
> avoid boxing variables.  These are only _optimizations_.
>
> If you're serious about this proposal, please read sections 3.1 and 3.4
> of the R5RS carefully.  Explain your proposed _semantics_ (not the
> implementation details) in those terms, where *all* variables are bound
> to _locations_, and where there is no stack at all (everything is
> conceptually stored in a garbage-collected heap).
>
> We need to understand the *semantics* in the simplest possible terms
> before we even begin to think about how to implement it.
>
> Thanks,
>   Mark

Re: GOOPS and hash-tables - ie.

[Daniel Hartwig]

On 23 March 2013 23:19, Daniel Hartwig  wrote:
> On 23 March 2013 23:15, Brent Pinkney  wrote:
>> Ok, so you have confirmed that you can merrily make my enumerate! method ?
>>
>> I still fail to.
>
> Which hash tables are you using?
>
> scheme@(guile-user)> (define t (make-hash-table))
> scheme@(guile-user)> (define-method (enumerate! (o ) env)
>(list o env))
> scheme@(guile-user)> (enumerate! t #t)
> $2 = (# #t)

$ guile --version
guile (GNU Guile) 2.0.7.71-1260f

Re: GOOPS and hash-tables - ie.

[Daniel Hartwig]

On 23 March 2013 23:15, Brent Pinkney  wrote:
> On 23/03/2013 16:09, Daniel Hartwig wrote:
>>
>> On 23 March 2013 19:18, Brent Pinkney  wrote:
>>>
>>> Hi,
>>>
>>> I desperately need to write a generic method that binds to a hash-table.
>>>
>>> I have noticed that native scheme types like pair, list, and vector are
>>> automagically recognised in GOOPS as , , and .
>>> Even SRFI-19 dates are recognised as .
>
>
>>> How did you spot those classes?
>
>
> I read the guile vm and module source code :)
>
>
>>
>>>
>>> How then to add similar goodness so that I can write:
>>>
>>> (define-method (enumerate! (o ) env)
>>>  ...
>>> )
>>>
>> A quick investigation using ‘class-of’ and the various constructors:
>>
>> scheme@(guile-user)> (class-of (make-hash-table))
>> $1 = #<  9f96780>
>> scheme@(guile-user)> (use-modules (srfi srfi-69))
>> scheme@(guile-user)> (class-of (make-hash-table))
>> $2 = #<  a115000>
>>
>> Regards
>
> Ok, so you have confirmed that you can merrily make my enumerate! method ?
>
> I still fail to.

Which hash tables are you using?

scheme@(guile-user)> (define t (make-hash-table))
scheme@(guile-user)> (define-method (enumerate! (o ) env)
   (list o env))
scheme@(guile-user)> (enumerate! t #t)
$2 = (# #t)

Re: GOOPS and hash-tables - ie.

[Brent Pinkney]

On 23/03/2013 16:09, Daniel Hartwig wrote:

On 23 March 2013 19:18, Brent Pinkney  wrote:

Hi,

I desperately need to write a generic method that binds to a hash-table.

I have noticed that native scheme types like pair, list, and vector are
automagically recognised in GOOPS as , , and .
Even SRFI-19 dates are recognised as .



How did you spot those classes?


I read the guile vm and module source code :)





How then to add similar goodness so that I can write:

(define-method (enumerate! (o ) env)
 ...
)


A quick investigation using ‘class-of’ and the various constructors:

scheme@(guile-user)> (class-of (make-hash-table))
$1 = #<  9f96780>
scheme@(guile-user)> (use-modules (srfi srfi-69))
scheme@(guile-user)> (class-of (make-hash-table))
$2 = #<  a115000>

Regards

Ok, so you have confirmed that you can merrily make my enumerate! method ?

I still fail to.


Cheers

Brent

Re: GOOPS and hash-tables - ie.

[Daniel Hartwig]

On 23 March 2013 19:18, Brent Pinkney  wrote:
> Hi,
>
> I desperately need to write a generic method that binds to a hash-table.
>
> I have noticed that native scheme types like pair, list, and vector are
> automagically recognised in GOOPS as , , and .
> Even SRFI-19 dates are recognised as .

How did you spot those classes?

>
>
> How then to add similar goodness so that I can write:
>
> (define-method (enumerate! (o ) env)
> ...
> )
>

A quick investigation using ‘class-of’ and the various constructors:

scheme@(guile-user)> (class-of (make-hash-table))
$1 = #<  9f96780>
scheme@(guile-user)> (use-modules (srfi srfi-69))
scheme@(guile-user)> (class-of (make-hash-table))
$2 = #<  a115000>

Regards

GOOPS and hash-tables - ie.

[Brent Pinkney]

Hi,

I desperately need to write a generic method that binds to a hash-table.

I have noticed that native scheme types like pair, list, and vector are 
automagically recognised in GOOPS as , , and .

Even SRFI-19 dates are recognised as .


How then to add similar goodness so that I can write:

(define-method (enumerate! (o ) env)
...
)


Thanks

Brent

Re: Do you recognize these modules?

[Thien-Thi Nguyen]

() Andy Wingo 
() Tue, 15 May 2012 22:14:31 +0200

   2.0 is the current stable branch, so any changes should go
   there first.  If it's a build fix or some other fix related to
   forward-compatibility with 2.0, it can go on 1.8 as well.  We
   should avoid adding interfaces to 1.8, though.

   When in doubt, it's best (and much appreciated) to mail the
   list.  If no one responds in a few days, go ahead and push it
   of course.

   Does that sound sensible to you?

Yes, thanks for the guidelines.  I hope to pop enough stacks to
get back to Guile (proper) hacking this year.  Fingers crossed...

-- 
Thien-Thi Nguyen
GPG key: 4C807502


pgpimsIEWdFl1.pgp
Description: PGP signature

Re: Special variables to relax boxing

[Stefan Israelsson Tampe]

Hi guiler, Hi Daniel.

I lost this thread in my mail application, sorry, so I try to continue
this way instead.

* This feature for scheme is mainly for macro writers which knows what 
  they are doing and which only guard state varibles not seen to the 
  application programmer. This is how I use this feature in guile-log 
  so it will not change how most people need to reason about scheme, the 
beuty 
  remains. It makes insanly difficult tasks possible and simple things
  works as before.

* I really like guile to cater for advanced users. Not only
  noobs. Although we should hide this feature really deep and put some
  serious warnings in the documentatin about the use. I actually hate
  using set! and if you look at e.g. guile-syntax-parse you will see
  that I rewrote everything with let loops, e.g. I really prefere that
  way of looping. I do understand your worry to let people loose on
  writing set! heavy code - that is not scheme. I also ported common
  lisp code to scheme and It was a horrible experience to see all set!
  ing in the code and I just had to rewrite quite a lot of the common
  lisp with rewriting the loops. But then a new version comes out and
  you are smoked.

* If we are serious about combining emacs-lisp with guile we should
  really aim to have this feature added with deep support. The reason is 
that
  using set! in lisp world is a style of programming and is very
  common. For this reason I don't expect much emacs-lisp to combine
  well with undo redo additions via prompts. This hearts me really
  hard because it would be so cool to be able and schime in to a
  emacs-lisp project, add  a few lines of code and show of a well 
  functioning redo and undo addition to the complex emacs lisp code - 
  this would be a really good selling point for guile-emacs and as I
  said, I hate that we don't have a nice support for it.

* The proposed semantics piggy packs ontop of fluids sematics so
  everything we have done incorporating fluids carry over directly to
  special variables. And the extra stuff is really not that
  much. E.g. the maintainance burden is probably much less that your
  perception of it.

* We need 2 extra VM op's if we are serious ablut implementing this
  though but they are simply essentially a copy paste of the fluid
  code so one could factor out the code somewhat. Another possibility
  is to add an option to the current fluid vm ops.

* If you don't redo and undo nothing in the way scheme works changes
  it's only when you undo and redo stuff that the semantics becomes 
  important.

I really think that this is an important addition of guile and it would
really be a dissapointment not having it's support considering the
great gain you can get via optimizations with really not much extra
work in guile. Also I think that I managed to get the semantics and
implementation in a really beutiful state where a lot of effort have
been in making it mix well and be consistant in what it does and
actually get it into a state where it _is_ much simpler to reason
about the code considering other way's of implementing the 
optimisations.
Albait more difficult than before.

Have fun
/Stefan