Re: [Chicken-hackers] incorrect warning during compilation
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
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
> > 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
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
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
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
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
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
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
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
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
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
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
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
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
> 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
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
> 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
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
> 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
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
