Re: [Chicken-hackers] incorrect warning during compilation

2014-07-11 Thread Michele La Monaca
On Fri, Jul 11, 2014 at 10:37 AM, Peter Bex  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

2014-07-11 Thread 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

2014-07-11 Thread 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

2014-07-11 Thread Evan Hanson
On 2014-07-11  8:55, Peter Bex wrote:
> 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.

I figure that's just our way of getting more tests out of the tests.

Evan

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


Re: [Chicken-hackers] incorrect warning during compilation

2014-07-10 Thread Peter Bex
On Wed, Jul 09, 2014 at 12:00:38PM +0200, Kristian Lein-Mathisen wrote:
> 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.

Yeah, git, for all its flaws, performs the tasks it was designed for
very well.

> 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?

I was wondering about a test too, but decided it's not really worth it.
We have very few tests for the FFI, only a few basic tests and a few
regression tests for bugs that have cropped up in the past.
There's no official test policy except "try to test as much as is
reasonable" and "try to add a regression test when fixing nasty bugs".

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

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.

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"

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

2014-07-09 Thread Peter Bex
On Fri, Jun 27, 2014 at 10:56:15PM +0200, Felix Winkelmann wrote:
> From: Kristian Lein-Mathisen 
> 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

2014-07-09 Thread 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  wrote:

> On Fri, Jun 27, 2014 at 10:56:15PM +0200, Felix Winkelmann wrote:
> > From: Kristian Lein-Mathisen 
> > 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

2014-07-01 Thread 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

2014-07-01 Thread 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 
> 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

2014-06-27 Thread Felix Winkelmann
From: Kristian Lein-Mathisen 
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 
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]].
 
 scheme-pointer
-nonnull-scheme-pointer
+(scheme-pointer TYPE)
+nonnull-scheme-pointer
+(nonnull-scheme-pointer 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.
 {{symbol}}{{char *}}
 {{void}}{{void}}
 {{([nonnull-]c-pointer TYPE)}}{{TYPE *}}
+{{([nonnull-]scheme-pointer TYPE)}}{{TYPE *}}
 {{(enum NAME)}}{{enum NAME}}
 {{(struct NAME)}}{{struct NAME}}
 {{(ref TYPE)}}{{TYPE &}}
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

2014-06-27 Thread Felix Winkelmann
From: Moritz Heidkamp 
Subject: Re: [Chicken-hackers] incorrect warning during compilation
Date: Fri, 27 Jun 2014 18:01:51 +0200

> Hi,
> 
> Felix Winkelmann  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?

A nice generalization, indeed! Let me try 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

2014-06-27 Thread 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 
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

2014-06-27 Thread 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

2014-06-27 Thread Moritz Heidkamp
Hi,

Felix Winkelmann  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

2014-06-27 Thread 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

2014-06-27 Thread 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 
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.
 
+string-buffer
+nonnull-string-buffer
+unsigned-string-buffer
+nonnull-unsigned-string-buffer
+
+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.
+
 c-string-list
 c-string-list*
 
@@ -378,6 +387,8 @@ The foreign type {{TYPE}} with an additional {{const}} qualifier.
 {{[nonnull-]f64vector}}{{double *}}
 {{[nonnull-]c-string}}{{char *}}
 {{[nonnull-]unsigned-c-string}}{{unsigned char *}}
+{{[nonnull-]string-buffer}}{{char *}}
+{{[nonnull-]unsigned-string-buffer}}{{unsigned char *}}
 {{c-string-list}}{{char **}}
 {{symbol}}{{char *}}
 {{void}}{{void}}
diff --git a/support.scm b/support.scm
index d47afb1..6e9a750 100644
--- a/support.scm
+++ b/support.scm
@@ -1091,6 +1091,16 @@
 	  (if u

Re: [Chicken-hackers] incorrect warning during compilation

2014-06-27 Thread 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

2014-06-27 Thread Felix Winkelmann
> 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

2014-06-25 Thread 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


Re: [Chicken-hackers] incorrect warning during compilation

2014-06-25 Thread 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