Re: [racket-dev] cstruct and properties

2012-11-12 Thread Tobias Hammer
On Sun, 11 Nov 2012 17:39:07 +0100, Matthew Flatt mfl...@cs.utah.edu  
wrote:



At Wed, 7 Nov 2012 20:00:51 +0100, Tobias Hammer wrote:
i am currently playing around with properties attached to cstructs and  
ran

into some problems.

Normally, with racket structs, i can access a property without an  
instance
of the struct via the struct type descriptor (struct:S). There seems to  
be

nothing similar for cstructs, so the only way i found to check for or
access a property is to create a dummy instance solely for this purpose.
Would it be possible to add a similar type descriptor for cstructs? To
account for the incompatibility with the one for structs it might make
sense to name it different, maybe cstruct:S or similar.


I've added it as `struct:cpointer:S' --- sticking with struct:
because it is a structure type in the usual sense, but adding
cpointer: because it corresponds to the wrapper struct, and not
really to `S' instances.


The naming is perfectly reasonable and now everything works as expected.
Thanks!



If such a descriptor would exists it should be included in the  
transformer

bindings for cstructs. Another info i am really missing there is the
super-type field. As far as i can see, it would be a valid semantic to  
set

it to the identifier if the cstruct was created by type and to set it #f
if it got its super-type by cpointer.


After looking into this, I'm not sure what you had in mind after all.

I fixed a related issue, which is that a cstruct subtype now inherits
its parent's wrapper and properties. For example,

 (define-values (p p? p-ref) (make-struct-type-property 'my-p))
 (define-cstruct _S ([a (_array _byte 23)])
#:property p (lambda () _S))
 (define-cstruct (_T _S) ())
 (p? (ptr-ref (malloc _T) _T))

produces #t.

But I think that's not all that you were getting at, so maybe an
example would help.


You are right, that not what i had in mind. What i tried to suggest is to
adjust the transformer time information for cstructs to bring them closer
to the ones of normal structs. I got a bit confused by the code, so scratch
that last part about super-type by cpointer.

Example:

#lang racket
(require (for-syntax racket/list
 racket/struct-info)
 ffi/unsafe)
;; 1
(struct A (a))
(struct B A ())

;; 2
(define-cstruct _S ([a _int]))
(define-cstruct (_T _S) ())

(define-syntax (a stx)
  (printf 1: ~a\n2: ~a\n
  (sixth (extract-struct-info (syntax-local-value #'B)))
  (sixth (extract-struct-info (syntax-local-value #'T
  #'(void))
(a)

=
1: #syntax:/home/hamm_to/tmp/racket-testing/cstruct-super-info.rkt:7:10 A
2: #t

I would expect the syntax-object for identifier S at 2. #t says T has no
super-type and thats clearly not the case.



But one more thing on properties. A source of really nasty bugs is if  
you

try to use the ctype of a cstruct inside the property:

(define-values (p p? p-ref) (make-struct-type-property 'my-p))
(define-cstruct _S ([a (_array _byte 23)])
   #:property p _S)


Fixed in a way that turns that into an error for a too-early use of
`_S', as we discussed.


Great, one less source of ugly segfaults.



--
-
Tobias Hammer
DLR / Institute of Robotics and Mechatronics
Muenchner Str. 20, D-82234 Wessling
Tel.: 08153/28-1487
Mail: tobias.ham...@dlr.de
_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] cstruct and properties

2012-11-11 Thread Matthew Flatt
At Wed, 7 Nov 2012 20:00:51 +0100, Tobias Hammer wrote:
 i am currently playing around with properties attached to cstructs and ran  
 into some problems.
 
 Normally, with racket structs, i can access a property without an instance  
 of the struct via the struct type descriptor (struct:S). There seems to be  
 nothing similar for cstructs, so the only way i found to check for or  
 access a property is to create a dummy instance solely for this purpose.
 Would it be possible to add a similar type descriptor for cstructs? To  
 account for the incompatibility with the one for structs it might make  
 sense to name it different, maybe cstruct:S or similar.

I've added it as `struct:cpointer:S' --- sticking with struct:
because it is a structure type in the usual sense, but adding
cpointer: because it corresponds to the wrapper struct, and not
really to `S' instances.

 If such a descriptor would exists it should be included in the transformer  
 bindings for cstructs. Another info i am really missing there is the  
 super-type field. As far as i can see, it would be a valid semantic to set  
 it to the identifier if the cstruct was created by type and to set it #f  
 if it got its super-type by cpointer.

After looking into this, I'm not sure what you had in mind after all.

I fixed a related issue, which is that a cstruct subtype now inherits
its parent's wrapper and properties. For example,

 (define-values (p p? p-ref) (make-struct-type-property 'my-p))
 (define-cstruct _S ([a (_array _byte 23)])
#:property p (lambda () _S))
 (define-cstruct (_T _S) ())
 (p? (ptr-ref (malloc _T) _T))

produces #t.

But I think that's not all that you were getting at, so maybe an
example would help.

 But one more thing on properties. A source of really nasty bugs is if you  
 try to use the ctype of a cstruct inside the property:
 
 (define-values (p p? p-ref) (make-struct-type-property 'my-p))
 (define-cstruct _S ([a (_array _byte 23)])
#:property p _S)

Fixed in a way that turns that into an error for a too-early use of
`_S', as we discussed.

_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] cstruct and properties

2012-11-08 Thread Matthew Flatt
At Wed, 7 Nov 2012 20:00:51 +0100, Tobias Hammer wrote:
 i am currently playing around with properties attached to cstructs and ran  
 into some problems.
 
 Normally, with racket structs, i can access a property without an instance  
 of the struct via the struct type descriptor (struct:S). There seems to be  
 nothing similar for cstructs, so the only way i found to check for or  
 access a property is to create a dummy instance solely for this purpose.
 Would it be possible to add a similar type descriptor for cstructs? To  
 account for the incompatibility with the one for structs it might make  
 sense to name it different, maybe cstruct:S or similar.

 If such a descriptor would exists it should be included in the transformer  
 bindings for cstructs.

Yes, that makes sense.

 Another info i am really missing there is the  
 super-type field. As far as i can see, it would be a valid semantic to set  
 it to the identifier if the cstruct was created by type and to set it #f  
 if it got its super-type by cpointer.

Right.

 But one more thing on properties. A source of really nasty bugs is if you  
 try to use the ctype of a cstruct inside the property:
 
 (define-values (p p? p-ref) (make-struct-type-property 'my-p))
 (define-cstruct _S ([a (_array _byte 23)])
#:property p _S)
 (define s (ptr-ref (malloc _S) _S)) ; dummy instance
 
 Getting the value results in:
 (p-ref s)
  #ctype
 (ctype-sizeof (p-ref s))
  4
 
 Checking ffi/unsafe.rkt shows that i get a temporary cpointer as ctype.  
 The real type already exists at the time the wrapper-struct is created but  
 it is not yet accessible by the name _S.
 The following small patch should solve this by locally introducing the  
 correct name during the struct creation.

It's interesting that you can make that work in the current
implementation, but I worry about guaranteeing that order for the
future. I'm inclined instead to say that the above declaration should
have signaled an error due to an too-early use of `_S', just like

  (struct a () #:property prop:procedure struct:a)

The repair to `define-cstruct', then, would be to lift the property and
property-value expressions out of the nested scope where they currently
are evaluated.

Is it important for your purposes that the `define-cstruct' declaration
above works? Or could you use a thunk to delay reference, as in

 (define-cstruct _S ([a (_array _byte 23)])
#:property p (lambda () _S))

?
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] cstruct and properties

2012-11-08 Thread Matthew Flatt
At Thu, 8 Nov 2012 15:20:33 +0100, Tobias Hammer wrote:
 On Thu, 08 Nov 2012 14:55:21 +0100, Matthew Flatt mfl...@cs.utah.edu  
 wrote:
 
 [ ... ]
  It's interesting that you can make that work in the current
  implementation, but I worry about guaranteeing that order for the
  future. I'm inclined instead to say that the above declaration should
  have signaled an error due to an too-early use of `_S', just like
 
(struct a () #:property prop:procedure struct:a)
 
  The repair to `define-cstruct', then, would be to lift the property and
  property-value expressions out of the nested scope where they currently
  are evaluated.
 
  Is it important for your purposes that the `define-cstruct' declaration
  above works? Or could you use a thunk to delay reference, as in
 
   (define-cstruct _S ([a (_array _byte 23)])
  #:property p (lambda () _S))
 
  ?
 
 That was a possibility i also tried, but with the same erroneous result.

Yes, it's broken right now. But would it be good enough if we made that
work (as opposed to making the variant without the thunk wrapper),
which I think would be consistent with other forms?

_
  Racket Developers list:
  http://lists.racket-lang.org/dev


[racket-dev] cstruct and properties

2012-11-07 Thread Tobias Hammer

Hi,

i am currently playing around with properties attached to cstructs and ran  
into some problems.


Normally, with racket structs, i can access a property without an instance  
of the struct via the struct type descriptor (struct:S). There seems to be  
nothing similar for cstructs, so the only way i found to check for or  
access a property is to create a dummy instance solely for this purpose.
Would it be possible to add a similar type descriptor for cstructs? To  
account for the incompatibility with the one for structs it might make  
sense to name it different, maybe cstruct:S or similar.


If such a descriptor would exists it should be included in the transformer  
bindings for cstructs. Another info i am really missing there is the  
super-type field. As far as i can see, it would be a valid semantic to set  
it to the identifier if the cstruct was created by type and to set it #f  
if it got its super-type by cpointer.


But one more thing on properties. A source of really nasty bugs is if you  
try to use the ctype of a cstruct inside the property:


(define-values (p p? p-ref) (make-struct-type-property 'my-p))
(define-cstruct _S ([a (_array _byte 23)])
  #:property p _S)
(define s (ptr-ref (malloc _S) _S)) ; dummy instance

Getting the value results in:
(p-ref s)

#ctype

(ctype-sizeof (p-ref s))

4


Checking ffi/unsafe.rkt shows that i get a temporary cpointer as ctype.  
The real type already exists at the time the wrapper-struct is created but  
it is not yet accessible by the name _S.
The following small patch should solve this by locally introducing the  
correct name during the struct creation.


diff --git a/collects/ffi/unsafe.rkt b/collects/ffi/unsafe.rkt
index 37ffc7c..4842e87 100644
--- a/collects/ffi/unsafe.rkt
+++ b/collects/ffi/unsafe.rkt
@@ -1384,7 +1384,7 @@
#'(begin)
(with-syntax ([(prop ...)  
property-stxes])

  #'(define make-wrap-TYPE
- (let ()
+ (let ([_TYPE _TYPE*])
(struct  
cpointer:TYPE (ptr)
  #:property  
prop:cpointer 0

  prop ...)




--
-
Tobias Hammer
DLR / Institute of Robotics and Mechatronics
Muenchner Str. 20, D-82234 Wessling
Tel.: 08153/28-1487
Mail: tobias.ham...@dlr.de
_
 Racket Developers list:
 http://lists.racket-lang.org/dev