Re: [Chicken-hackers] incorrect warning during compilation

[Kristian Lein-Mathisen]

 We can't use the test egg in core.  However, there are so many hand-
 rolled assertion/test-like macros that I've often wondered if it would
 benefit us to make a simple test library part of core.  Core itself
 could benefit from an improved test suite library, and eggs wouldn't
 need an additional dependency for testing.  I don't think I want to
 literally put the test egg into core.  I like the simplicity of the API
 but the implementation is a bit messy and it's a bit hard to modify
 the way it writes its output (try changing it to output some HTML,
 for example).  This may just be a documentation problem, though.


I've tried to modify the way test works, too, I've concluded it's very
messy. It's not very modular, so you have to copy-paste parts of the
original and do your modifications there. It gave me the idea to write a
new test egg with the same simple API but where it somehow was easier to
modify the output like you describe.

Is your proposal to create a new test-egg-inspired test unit in core?



 Anyway, your test would probably succeed even if the pointer type would
 be incorrect.  It would just compile with a warning (which gets lost
 in the noise).  If you change the index to 1 or 2, it might be a better
 test since it would fail when the pointer type would be anything larger
 than a char due to the address calculation ending up somewhere beyond
 the string.  Additionally, we could compile the test with -Wall -Werror
 for example, to catch C type errors.  Would you care to write a complete
 patch to add FFI tests?  You can mail it with git format-patch


Of course, how silly of me! That should have been x[1]='B' and change input
to AxC. Writing good tests, I guess, is always a challenge.

I could put some tests down, but I wouldn't know where to start. What would
be complete? Perhaps we could put this on the agenda for T-DOSE? I think
that could be fun!


 Cheers,
 Peter
 --
 http://www.more-magic.net

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] incorrect warning during compilation

[Peter Bex]

On Fri, Jul 11, 2014 at 10:32:23AM +0200, Kristian Lein-Mathisen wrote:
 I've tried to modify the way test works, too, I've concluded it's very
 messy. It's not very modular, so you have to copy-paste parts of the
 original and do your modifications there. It gave me the idea to write a
 new test egg with the same simple API but where it somehow was easier to
 modify the output like you describe.
 
 Is your proposal to create a new test-egg-inspired test unit in core?

Yes.

  Anyway, your test would probably succeed even if the pointer type would
  be incorrect.  It would just compile with a warning (which gets lost
  in the noise).  If you change the index to 1 or 2, it might be a better
  test since it would fail when the pointer type would be anything larger
  than a char due to the address calculation ending up somewhere beyond
  the string.  Additionally, we could compile the test with -Wall -Werror
  for example, to catch C type errors.  Would you care to write a complete
  patch to add FFI tests?  You can mail it with git format-patch
 
 Of course, how silly of me! That should have been x[1]='B' and change input
 to AxC. Writing good tests, I guess, is always a challenge.

It's never easy :)

 I could put some tests down, but I wouldn't know where to start.

Well, the test you posted is a good start.  Just work your way through
the various type specifiers.

 What would be complete?

Don't worry about being absolutely complete; we never do that anywhere.
It's good to have at least the basics covered, we can always add more
tests later.  Besides, running the tests should not take ages.

 Perhaps we could put this on the agenda for T-DOSE? I think
 that could be fun!

Sure, we could work on that together.

Cheers,
Peter
-- 
http://www.more-magic.net

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] incorrect warning during compilation

[Michele La Monaca]

On Fri, Jul 11, 2014 at 10:37 AM, Peter Bex peter@xs4all.nl wrote:
 On Fri, Jul 11, 2014 at 10:32:23AM +0200, Kristian Lein-Mathisen wrote:
 I've tried to modify the way test works, too, I've concluded it's very
 messy. It's not very modular, so you have to copy-paste parts of the
 original and do your modifications there. It gave me the idea to write a
 new test egg with the same simple API but where it somehow was easier to
 modify the output like you describe.

 Is your proposal to create a new test-egg-inspired test unit in core?

 Yes.

+1

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] incorrect warning during compilation

[Kristian Lein-Mathisen]

Cool! And the commit even shows up with Felix as the author. This
pathes-over-email thing works really nicely :) Never seen it in action like
this before.

So I'm curious, are there no tests for things like this? Might it be a good
idea? Is there an official test-policy for chicken-core anywhere I can read
up on?

(use test)
(test parameterized scheme-pointer
  ABC
  ((foreign-lambda* c-string (((scheme-pointer unsigned-char) x))
x[0] = 65; return(x);)
   xBC))

K.


On Wed, Jul 9, 2014 at 10:45 AM, Peter Bex peter@xs4all.nl wrote:

 On Fri, Jun 27, 2014 at 10:56:15PM +0200, Felix Winkelmann wrote:
  From: Kristian Lein-Mathisen krist...@adellica.com
  Subject: Re: [Chicken-hackers] incorrect warning during compilation
  Date: Fri, 27 Jun 2014 17:13:21 +0200
 
   Actually, that's really cool! A string-buffer type! I wouldn't mind
   seeing this in core. So how does this work, Felix, do we vote and
 things?
 
  Here is an attempt at Moritzens proposal.
 

 Thanks for the patch!  I finally had some time to take a proper look and
 it looks fine (of course).  This has been pushed (with an added NEWS
 entry).

 Cheers,
 Peter
 --
 http://www.more-magic.net

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] incorrect warning during compilation

[Peter Bex]

On Fri, Jun 27, 2014 at 10:56:15PM +0200, Felix Winkelmann wrote:
 From: Kristian Lein-Mathisen krist...@adellica.com
 Subject: Re: [Chicken-hackers] incorrect warning during compilation
 Date: Fri, 27 Jun 2014 17:13:21 +0200
 
  Actually, that's really cool! A string-buffer type! I wouldn't mind
  seeing this in core. So how does this work, Felix, do we vote and things?
 
 Here is an attempt at Moritzens proposal.
 

Thanks for the patch!  I finally had some time to take a proper look and
it looks fine (of course).  This has been pushed (with an added NEWS entry).

Cheers,
Peter
-- 
http://www.more-magic.net

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] incorrect warning during compilation

[Kristian Lein-Mathisen]

I am watching these patches with great interest. They are surprisingly
small, nice and comprehensible :)

I think this is a really nice foreign-type extension! And it's
backward-compatible, right?

(let ((str xBC))
  ((foreign-lambda* c-string (((scheme-pointer unsigned-char) x)) x[0] =
65; return(x);)
   str)
  (print str))

which produces

unsigned C_char *x=(unsigned C_char *)C_data_pointer_or_null(C_a0);
x[0] = 65; return(x);

which prints

ABC

I'm happy and would love to see this committed somewhere :)
K.



On Fri, Jun 27, 2014 at 10:56 PM, Felix Winkelmann 
felix.winkelm...@bevuta.com wrote:

 From: Kristian Lein-Mathisen krist...@adellica.com
 Subject: Re: [Chicken-hackers] incorrect warning during compilation
 Date: Fri, 27 Jun 2014 17:13:21 +0200

  Actually, that's really cool! A string-buffer type! I wouldn't mind
  seeing this in core. So how does this work, Felix, do we vote and things?

 Here is an attempt at Moritzens proposal.


 felix

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] incorrect warning during compilation

[Peter Bex]

On Tue, Jul 01, 2014 at 12:07:35PM +0200, Kristian Lein-Mathisen wrote:
 I am watching these patches with great interest. They are surprisingly
 small, nice and comprehensible :)
 
 I'm happy and would love to see this committed somewhere :)

I also like the patch.  I haven't had time to look into it, due to being
afk in the weekend and having the srfi-13 and move-memory bugs.  There
are also a few of my patches waiting to be committed.  It would be great
if any of the other core hackers could help out.

Cheers,
Peter
-- 
http://www.more-magic.net

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] incorrect warning during compilation

[Kristian Lein-Mathisen]

Thanks for you feedback Felix,

I talked to Peter on #chicken and he wasn't happy about another
foreign-type. I suppose I agree with him, there are quite a few already and
maybe it'll just be confusing: having a c-string and a string foreign
type would probably do more harm than gain.

I decided to do a (c-pointer char) and wrap the string argument in
(location ...) which isn't all that bad. I couldn't use scheme-pointer
because my C-function argument is already declared as char* and not void*.

And I guess string-blob/shared isn't all that useful if no other Schemes
support it and we have plenty of other workarounds. I never really got
blobs anyway, when do you *not* just want to use a string instead? They
print so much nicer than blobs, even with binary data that's escaped with
\x!

K.


On Fri, Jun 27, 2014 at 11:05 AM, Felix Winkelmann 
felix.winkelm...@bevuta.com wrote:

  Oh, I see. I though it was meant to be used interchangeably. I can't use
  string-blob, though, because that will copy the data and I need to
 modify
  it from C. What foreign type should I use for this sort of thing?
 
  - (c-pointer char) with (location string) works, but is a lot of typing
 
  - scheme-pointer seems to work, but:
 
  requires type cast in C:
 
  (print ((foreign-lambda* c-string ((scheme-pointer x)) ((char*)x)[0] =
 65;
  return(x);) xBC))
 
  allows all types, I just want blob/string:
 
  (print ((foreign-lambda* c-string ((scheme-pointer x)) ((char*)x)[0] =
 65;
  return(x);) 45.0))
 
  is there a string foreign type that works like blob, that provides a
  (char*) argument and checks that argument is a string? Or is there a
  string-blob/shared procedure anywhere?

 You could also keep everything as it is and ignore the warning, but I
 understand that it isn't the cleanest solution. I'm not aware of any
 documented interchangability between strings and blobs, it is an
 implementation artefact. string-blob/shared would make sense but is
 not possible in the current implementation (srfi-4 vectors have an
 indirection to the raw data buffer, there this conversion only changes
 the wrapper object, but strings and blobs contain the data without the
 indirection.)

 So, I can't think of a solution that answers all of your questions.
 I would go with the scheme-pointer.

 We could add another foreign type, that accepts strings but doesn't
 copy. I'll look into that.


 felix

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] incorrect warning during compilation

[Felix Winkelmann]

 I talked to Peter on #chicken and he wasn't happy about another
 foreign-type. I suppose I agree with him, there are quite a few already and
 maybe it'll just be confusing: having a c-string and a string foreign
 type would probably do more harm than gain.

Well, no problem. Attached a patch for the string-buffer type, just
in case someone is interested.


felix
From 979a967c6e923391dfed5cb225dd20ec4aac6bbb Mon Sep 17 00:00:00 2001
From: felix fe...@call-with-current-continuation.org
Date: Fri, 27 Jun 2014 13:52:50 +0200
Subject: [PATCH] Added foreign types [nonnull-][unsigned-]string-buffer.

---
 c-backend.scm  |   19 ---
 compiler.scm   |4 
 manual/Foreign type specifiers |   11 +++
 support.scm|   10 ++
 4 files changed, 37 insertions(+), 7 deletions(-)

diff --git a/c-backend.scm b/c-backend.scm
index 28efda1..df3df11 100644
--- a/c-backend.scm
+++ b/c-backend.scm
@@ -1092,9 +1092,11 @@
 		   nonnull-c-pointer number unsigned-integer64 integer64 c-string-list
 		   c-string-list*)
 	(string-append ns +3) ]
-	   [(c-string c-string* unsigned-c-string unsigned-c-string unsigned-c-string*)
+	   [(c-string c-string* unsigned-c-string unsigned-c-string unsigned-c-string*
+		  string-buffer unsigned-string-buffer)
 	(string-append ns +2+( var ==NULL?1:C_bytestowords(C_strlen( var  ]
-	   [(nonnull-c-string nonnull-c-string* nonnull-unsigned-c-string nonnull-unsigned-c-string* symbol)
+	   [(nonnull-c-string nonnull-c-string* nonnull-unsigned-c-string nonnull-unsigned-c-string* symbol
+			  nonnull-string-buffer nonnull-unsigned-string-buffer)
 	(string-append ns +2+C_bytestowords(C_strlen( var ))) ]
 	   [else
 	(cond [(and (symbol? type) (##sys#hash-table-ref foreign-type-table type)) 
@@ -1179,9 +1181,10 @@
   [(f32vector nonnull-f32vector) (str float *)]
   [(f64vector nonnull-f64vector) (str double *)]
   ((pointer-vector nonnull-pointer-vector) (str void **))
-  [(nonnull-c-string c-string nonnull-c-string* c-string* symbol) 
+  [(nonnull-c-string c-string nonnull-c-string* c-string* string-buffer nonnull-string-buffer symbol) 
(str char *)]
-  [(nonnull-unsigned-c-string nonnull-unsigned-c-string* unsigned-c-string unsigned-c-string*)
+  [(nonnull-unsigned-c-string nonnull-unsigned-c-string* unsigned-c-string unsigned-c-string*
+  unsigned-string-buffer nonnull-unsigned-string-buffer)
(str unsigned char *)]
   [(void) (str void)]
   [else
@@ -1283,9 +1286,11 @@
   ((nonnull-f64vector) C_c_f64vector()
   ((pointer-vector) C_c_pointer_vector_or_null()
   ((nonnull-pointer-vector) C_c_pointer_vector()
-  ((c-string c-string* unsigned-c-string unsigned-c-string*) C_string_or_null()
-  ((nonnull-c-string nonnull-c-string* nonnull-unsigned-c-string 
-			 nonnull-unsigned-c-string* symbol) C_c_string()
+  ((c-string c-string* unsigned-c-string unsigned-c-string* string-buffer unsigned-string-buffer)
+   C_string_or_null()
+  ((nonnull-c-string nonnull-c-string* nonnull-unsigned-c-string nonnull-string-buffer
+			 nonnull-unsigned-string-buffer nonnull-unsigned-c-string* symbol) 
+   C_c_string()
   ((bool) C_truep()
   (else
(cond [(and (symbol? type) (##sys#hash-table-ref foreign-type-table type))
diff --git a/compiler.scm b/compiler.scm
index 9fc9f1a..c0fdc9b 100644
--- a/compiler.scm
+++ b/compiler.scm
@@ -1215,6 +1215,10 @@
 		  '((const c-string*)
 		(const unsigned-c-string*)
 		unsigned-c-string*
+		string-buffer 
+		unsigned-string-buffer
+		nonnull-string-buffer
+		nonnull-unsigned-string-buffer
 		c-string*
 		c-string-list
 		c-string-list*))
diff --git a/manual/Foreign type specifiers b/manual/Foreign type specifiers
index 19351be..63e9a0f 100644
--- a/manual/Foreign type specifiers	
+++ b/manual/Foreign type specifiers	
@@ -164,6 +164,15 @@ defined with {{define-external}}.
 Same as {{c-string}}, {{nonnull-c-string}}, etc. but mapping to C's
 {{unsigned char *}} type.
 
+typestring-buffer/type/br
+typenonnull-string-buffer/type/br
+typeunsigned-string-buffer/type/br/br
+typenonnull-unsigned-string-buffer/type
+
+Similar to {{[unsigned-]c-string}}, but doesn't copy the string, nor
+does it append a zero byte. Use this type to pass strings that are
+intended to be modified from foreign code.
+
 typec-string-list/typebr
 typec-string-list*/type
 
@@ -378,6 +387,8 @@ The foreign type {{TYPE}} with an additional {{const}} qualifier.
 trtd{{[nonnull-]f64vector}}/tdtd{{double *}}/td/tr
 trtd{{[nonnull-]c-string}}/tdtd{{char *}}/td/tr
 trtd{{[nonnull-]unsigned-c-string}}/tdtd{{unsigned char *}}/td/tr
+trtd{{[nonnull-]string-buffer}}/tdtd{{char *}}/td/tr
+trtd{{[nonnull-]unsigned-string-buffer}}/tdtd{{unsigned char *}}/td/tr
 trtd{{c-string-list}}/tdtd{{char **}}/td/tr
 trtd{{symbol}}/tdtd{{char 

Re: [Chicken-hackers] incorrect warning during compilation

[Kristian Lein-Mathisen]

Actually, that's really cool! A string-buffer type! I wouldn't mind
seeing this in core. So how does this work, Felix, do we vote and things?

K.


On Fri, Jun 27, 2014 at 4:43 PM, Felix Winkelmann 
felix.winkelm...@bevuta.com wrote:

  I talked to Peter on #chicken and he wasn't happy about another
  foreign-type. I suppose I agree with him, there are quite a few already
 and
  maybe it'll just be confusing: having a c-string and a string foreign
  type would probably do more harm than gain.

 Well, no problem. Attached a patch for the string-buffer type, just
 in case someone is interested.


 felix

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] incorrect warning during compilation

[Moritz Heidkamp]

Hi,

Felix Winkelmann felix.winkelm...@bevuta.com writes:
 So, I can't think of a solution that answers all of your questions.
 I would go with the scheme-pointer. 

 We could add another foreign type, that accepts strings but doesn't
 copy. I'll look into that.

how about extending the [nonnull-]scheme-pointer type to be
parameterizable like [nonnull-]c-pointer so that Kristian could use
(scheme-pointer char) for his case? Would that be possible somehow?

Moritz
-- 
bevuta IT GmbH - professionelle IT-Lösungen
Marktstraße 10 | http://www.bevuta.com/ | HRB 62476 AG Köln
50968 Köln | Tel.: +49 221 282678-0 | Geschäftsführer: Pablo Beyen

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] incorrect warning during compilation

[John Cowan]

Kristian Lein-Mathisen scripsit:

 And I guess string-blob/shared isn't all that useful if no other Schemes
 support it and we have plenty of other workarounds. I never really got
 blobs anyway, when do you *not* just want to use a string instead? They
 print so much nicer than blobs, even with binary data that's escaped with
 \x!

Strings have definite semantics as a sequence of characters, even if you
need to know the encoding.  Blobs have no semantics at all: they can be
logically strings, or SRFI 4 vectors, or arrays of C structs, or whatever.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
Samuel Johnson on playing the violin: Difficult do you call it, Sir?
I wish it were impossible.

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] incorrect warning during compilation

[Jörg F. Wittenberger]

This one I'd like.  Currently using the scheme-pointer plus type cast 
in C approach.  Quite often actually.


Am 27.06.2014 17:13, schrieb Kristian Lein-Mathisen:


Actually, that's really cool! A string-buffer type! I wouldn't mind 
seeing this in core. So how does this work, Felix, do we vote and things?


K.


On Fri, Jun 27, 2014 at 4:43 PM, Felix Winkelmann 
felix.winkelm...@bevuta.com mailto:felix.winkelm...@bevuta.com wrote:


 I talked to Peter on #chicken and he wasn't happy about another
 foreign-type. I suppose I agree with him, there are quite a few
already and
 maybe it'll just be confusing: having a c-string and a
string foreign
 type would probably do more harm than gain.

Well, no problem. Attached a patch for the string-buffer type, just
in case someone is interested.


felix





___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] incorrect warning during compilation

[Felix Winkelmann]

From: Kristian Lein-Mathisen krist...@adellica.com
Subject: Re: [Chicken-hackers] incorrect warning during compilation
Date: Fri, 27 Jun 2014 17:13:21 +0200

 Actually, that's really cool! A string-buffer type! I wouldn't mind
 seeing this in core. So how does this work, Felix, do we vote and things?

Here is an attempt at Moritzens proposal.


felix
From f043f6d0811d255483eca03c7eb55583fd852f21 Mon Sep 17 00:00:00 2001
From: felix fe...@call-with-current-continuation.org
Date: Fri, 27 Jun 2014 22:55:12 +0200
Subject: [PATCH] Generalize scheme-pointer foreign type to allow giving a
 type for the generated pointer variable holding the
 argument.

---
 c-backend.scm  |3 +++
 manual/Foreign type specifiers |9 -
 support.scm|   16 +++-
 3 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/c-backend.scm b/c-backend.scm
index 28efda1..dbb2b30 100644
--- a/c-backend.scm
+++ b/c-backend.scm
@@ -1194,6 +1194,7 @@
 		(cond 
 		 ((and (= 2 len)
 		   (memq (car type) '(pointer nonnull-pointer c-pointer 
+		  scheme-pointer nonnull-scheme-pointer
 		  nonnull-c-pointer) ) )
 		  (foreign-type-declaration (cadr type) (string-append * target)) )
 		 ((and (= 2 len)
@@ -1297,6 +1298,8 @@
 	   ((nonnull-c-pointer) C_c_pointer_nn()
 	   ((instance) C_c_pointer_or_null()
 	   ((nonnull-instance) C_c_pointer_nn()
+	   ((scheme-pointer) C_data_pointer_or_null()
+	   ((nonnull-scheme-pointer) C_data_pointer()
 	   ((function) C_c_pointer_or_null()
 	   ((const) (foreign-argument-conversion (cadr type)))
 	   ((enum) C_num_to_int()
diff --git a/manual/Foreign type specifiers b/manual/Foreign type specifiers
index 19351be..6422e78 100644
--- a/manual/Foreign type specifiers	
+++ b/manual/Foreign type specifiers	
@@ -274,12 +274,18 @@ such objects using the core library routines in {{chicken.h}} and
 More information on object structure can be found in [[Data representation]].
 
 typescheme-pointer/typebr
-typenonnull-scheme-pointer/type
+type(scheme-pointer TYPE)/typebr
+typenonnull-scheme-pointer/typebr
+type(nonnull-scheme-pointer TYPE)/type
 
 An untyped pointer to the ''contents'' of a non-immediate Scheme
 object; for example, the raw byte contents of a string. Only allowed
 as an argument type, not a return type.  
 
+The optional element type {{TYPE}} may be used to specify what C
+type should be used in the generated code. This avoids the need
+to cast the argument.
+
 The value {{#f}} is also allowed and is passed as a {{NULL}} pointer.
 For the {{nonnull-}} variant, passing {{#f}} will raise an exception.
 
@@ -382,6 +388,7 @@ The foreign type {{TYPE}} with an additional {{const}} qualifier.
 trtd{{symbol}}/tdtd{{char *}}/td/tr
 trtd{{void}}/tdtd{{void}}/td/tr
 trtd{{([nonnull-]c-pointer TYPE)}}/tdtd{{TYPE *}}/td/tr
+trtd{{([nonnull-]scheme-pointer TYPE)}}/tdtd{{TYPE *}}/td/tr
 trtd{{(enum NAME)}}/tdtd{{enum NAME}}/td/tr
 trtd{{(struct NAME)}}/tdtd{{struct NAME}}/td/tr
 trtd{{(ref TYPE)}}/tdtd{{TYPE }}/td/tr
diff --git a/support.scm b/support.scm
index d47afb1..dc8a22c 100644
--- a/support.scm
+++ b/support.scm
@@ -1113,6 +1113,18 @@
 			 (if ,tmp
  (slot-ref ,param 'this)
  '#f) ) ) ]
+		   [(scheme-pointer)
+			(let ([tmp (gensym)])
+			  `(let ([,tmp ,param])
+			 (if ,tmp
+ ,(if unsafe
+  tmp
+  `(##sys#foreign-block-argument ,tmp) )
+ '#f) ) ) ]
+		   [(nonnull-scheme-pointer)
+			(if unsafe
+			param
+			`(##sys#foreign-block-argument ,param) ) ]
 		   [(nonnull-instance)
 			`(slot-ref ,param 'this) ]
 		   [(const) (repeat (cadr t))]
@@ -1203,7 +1215,9 @@
 		(next (if (vector? t2) (vector-ref t2 0) t2)) ) ]
 	  [(pair? t)
 	   (case (car t)
-		 [(ref nonnull-pointer pointer c-pointer nonnull-c-pointer function) (words-bytes 1)]
+		 [(ref nonnull-pointer pointer c-pointer nonnull-c-pointer function
+		   scheme-pointer nonnull-scheme-pointer)
+		  (words-bytes 1)]
 		 [else (err t)] ) ]
 	  [else (err t)] ) ) ) )
(lambda () (quit foreign type `~S' refers to itself type)) ) )
-- 
1.7.9.5

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] incorrect warning during compilation

[Felix Winkelmann]

 I think I may have found a tiny bug in core. So instead of going on IRC and
 crying to Peter, I though I'd try it myself this time. I have a file like
 this:
 
 (print ((foreign-lambda* c-string ((blob x)) x[0] = 65; return(x);)
 xBC))
 
 When I run this, everything works:
 $ ./type-test
 ABC
 
 However, I see a warning during compilation which I do not expect:
 
 $ csc type-test.scm
 
 Warning: at toplevel:
   (type-test.scm:2) in procedure call to `g01', expected argument #1 of
 type `(or boolean blob)', but was given an argument of type `string'
 

You specify blob as foreign type but pass a string as the
argument. That the generated code works is just a coincedence - blobs
and strings have the same internal representation. You can use
string-blob to convert the argument to a blob object.


felix

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] incorrect warning during compilation

[Kristian Lein-Mathisen]

Oh, I see. I though it was meant to be used interchangeably. I can't use
string-blob, though, because that will copy the data and I need to modify
it from C. What foreign type should I use for this sort of thing?

- (c-pointer char) with (location string) works, but is a lot of typing

- scheme-pointer seems to work, but:

requires type cast in C:

(print ((foreign-lambda* c-string ((scheme-pointer x)) ((char*)x)[0] = 65;
return(x);) xBC))

allows all types, I just want blob/string:

(print ((foreign-lambda* c-string ((scheme-pointer x)) ((char*)x)[0] = 65;
return(x);) 45.0))

is there a string foreign type that works like blob, that provides a
(char*) argument and checks that argument is a string? Or is there a
string-blob/shared procedure anywhere?

Thanks,
K.
(should this be moved to chicken-users, perhaps?)



On Wed, Jun 25, 2014 at 3:50 PM, Felix Winkelmann 
felix.winkelm...@bevuta.com wrote:

  I think I may have found a tiny bug in core. So instead of going on IRC
 and
  crying to Peter, I though I'd try it myself this time. I have a file like
  this:
 
  (print ((foreign-lambda* c-string ((blob x)) x[0] = 65; return(x);)
  xBC))
 
  When I run this, everything works:
  $ ./type-test
  ABC
 
  However, I see a warning during compilation which I do not expect:
 
  $ csc type-test.scm
 
  Warning: at toplevel:
(type-test.scm:2) in procedure call to `g01', expected argument #1 of
  type `(or boolean blob)', but was given an argument of type `string'
 

 You specify blob as foreign type but pass a string as the
 argument. That the generated code works is just a coincedence - blobs
 and strings have the same internal representation. You can use
 string-blob to convert the argument to a blob object.


 felix

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] incorrect warning during compilation

[Kristian Lein-Mathisen]

Hi folks,

I think I may have found a tiny bug in core. So instead of going on IRC and
crying to Peter, I though I'd try it myself this time. I have a file like
this:

(print ((foreign-lambda* c-string ((blob x)) x[0] = 65; return(x);)
xBC))

When I run this, everything works:
$ ./type-test
ABC

However, I see a warning during compilation which I do not expect:

$ csc type-test.scm

Warning: at toplevel:
  (type-test.scm:2) in procedure call to `g01', expected argument #1 of
type `(or boolean blob)', but was given an argument of type `string'

This is what I've come up with:

diff --git a/support.scm b/support.scm
index 11b71bb..f7d7b85 100644
--- a/support.scm
+++ b/support.scm
@@ -1261,7 +1261,7 @@
   ((scheme-pointer nonnull-scheme-pointer) '*)
   ((blob)
(case mode
- ((arg) '(or boolean blob))
+ ((arg) '(or boolean blob string))
  (else 'blob)))
   ((nonnull-blob) 'blob)
   ((pointer-vector)


And the warning disappears. Since the blob-type supports strings too, I
think it makes sense to add this to support.scm. What do you think?

Thanks!
K.
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers