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
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] [PATCH] Fix #1133
> Depending on how large the subset of procedures is we could perhaps pull
> a simplified version of them into core and optimise that to hell, and
> excise the slow remaining crap from core and move it to an egg (we
> already have some duplication like foldl vs fold and string-intersperse
> vs string-join). But I'm really not sure, I'd have to investigate.
That might be a good idea. Some of the SRFI-procedures are more
general than we need.
> The ##-things and such. If it's already exported by a module like
> chicken or scheme that's fine. But it might make more sense to put
> it in scheme.scm in that case, if that's doable. We'd probably have to
> split up core a bit in order to avoid having an overlap between files
> and modules like we do now (eg, eval.scm, module.scm and library.scm
> define things that are exported by the chicken module, but other things
> from library.scm are exported by the scheme module).
>
> We could still keep eval.scm and module.scm for example, if they strictly
> export things for chicken. If that's undoable we could define lower-level
> modules and compose the chicken and scheme modules from them, like it
> more-or-less works right now. This could be the simplest thing to start
> out with, anyway.
The scheme module is created by hand, there is no file corresponding
to it. I would propose to keep as much as possible in "chicken", even
if there is file overlap. These internal modules do not map to
specific files anyway. This means basically all the stuff in
"modules", "expand", "library", "eval" and "chicken-syntax".
It's the library-units that need to be heavily restructured, I think.
> The biggest problem I have is the different abstraction levels of the
> "posix" unit. Some are extremely thin wrappers (like for example
> file-select and file-{open,read,write}, which block the entire process
> instead of handling I/O in a nonblocking way and integrating with
> the scheduler like the rest of the system does; file-read just returns
> -1 and sets errno if you try to make it nonblocking), whereas others are
> pretty sophisticated library procedures which provide a more high-level
> API (like for example find-files and the signal handling stuff).
Yes, I agree.
>
>> Take windows into the equation and things get even worse. POSIX is not
>> the most ideal API "standard", but at least it is something one can
>> start with, even if Windows support is somewhat painful.
>
> Hehehe, "somewhat" :) But you're right, most of what POSIX offers is
> valuable and needs to be deeply integrated in core in order to provide
> good support so it makes sense. Still, I like the idea of having only
> completely portable stuff in core, so that programmers know that if it's
> in core, it's going to work everywhere. That can save a lot of headaches
> when porting an application to Windows, or CHICKEN to a completely new
> platform.
I would propose something like this:
- identify stuff that's not used in core and move that to eggs, for example:
memory-mapped files
binary-search (this screams out to be implemented as a functor)
queues
... much more, of possible ...
- Completely restructure all library units (extras, data-structures, files,
ports, lolevel, posix, utils). tcp and foreign stay as they are.
- irregex is used in core and will benefit from as much core-support as
it can get, so leave it as it is, as well.
- re-implement/copy stuff from SRFI-1/13/14 for internal use only,
move the rest into eggs.
- I would like to move srfi-18 to an egg as well, only keep the scheduler
and the internal threading-stuff in library.scm in core.
- srfi-69 can go to an egg. It is only used in chicken-profile, and
can be done using internal (symbol) hash-tables.
- I think srfi-4 can be eggified, too.
- Provide wrapper eggs for all the library units that are gone
(extras, ports, files, data-structures).
- I'm not sure about posix. Perhaps split this into higher-level
modules (eggify, if not needed in core) and keep a lower-level
interface in core.
- Use modules for the compiler. It is not used externally (well,
with the exception of user-passes, which nobody uses, I guess)
and would need some restructuring as well. But this may be a
first attempt at using modules internally.
Does this make sense?
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
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
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
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
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] [PATCH] Fix #1133
On 06/26/14 16:33, Peter Bex wrote: > On Mon, Jun 23, 2014 at 04:02:59AM +0400, Oleg Kolosov wrote: >> On 06/19/14 23:27, Peter Bex wrote: >> Units are also used for separate compilation of large code bases. It is >> not always make sense to separate everything into modules. This is >> useful, but should be build only matter. AFAIK, current system does not >> allow to transparently switch between module and unit mode for the given >> source file. We can try to add an option for chicken to mostly ignore >> module declarations and just issue some useful warnings but compile as a >> unit. This approach will enable incremental migration. > > That's an interesting idea. It might work, but I'm also unsure of the > added benefit; if the code is always compiled separately in the "ignore > modules" mode, it won't add the intended benefits of additional checking > of dependencies and exports. I mean an option to compile like: internally convert (module ) to (declare ), hook import somehow into this for rename and such, issue warnings for names still unresolved but just continue and generate a unit. This will allow having something working during conversion to modules and not require to declare and resolve everything at once. This is all hand wavy, I have not investigated technical details too much, but it seemed not so hard to do at first sight. >> ...cific details, maybe it is already improved. An ability to split up >> the Chicken runtime might will be helpful, currently it is too big and >> contains many unnecessary things (can be moved into eggs). Windows ... > > I'm unsure how much further we can strip down the core. Perhaps we can > drop SRFI-1, SRFI-13 and SRFI-14, which would be just fine as eggs. But > currently core is using some procedures from these. I think that this is > a separate issue, though. Refactoring stuff as modules is a shitload of > work which is not yet certain to be feasible, and we should not drag more > work into this project. Eggs was not the right word. I meant to just split it up more and make most components optional. I was under an impression somehow that this was the point of "call to arms". The motivation here is that we found out that Chicken works surprisingly well on embedded devices and want to integrate it even deeper (like initramfs, firmware updater and such). An experiments show it is possible to reduce runtime size to at least half of it's current size and still have something usable. But it is too troublesome to do manually, modularization will definitely help here and looks like good thing in general. >> What do you think about Chibi Scheme approach >> (http://synthcode.com/scheme/chibi/#h2_ModuleSystem)? >> Also, having compatible (and standard compliant) >> module system is a huge selling point IMO. > > We already support this syntax through the R7RS egg. We can't just > switch to the R7RS module system in core because it would break 100% of > the user code out there, for no technical gain whatsoever. CHICKEN core > is an R5RS system, and adding an R7RS module system to it adds no > benefit if everything else from R7RS is only available as an extension. > > We have already too many people asking about the difference between use, > require, require-extension, uses etc. Adding a second module system to > core would only add to the confusion (and *replacing* it would break the > world). The idea is: require and friends are not necessary at all (and confusing). The user should just use import and let the runtime system figure it out. Like John mentioned earlier. The only real use case for detailed control over library loading I can imagine is the support for module hot reload. >>> Indeed, bootstrapping is an ever-present pitfall. And there's also >>> library.scm which does not really correspond to a particular module. >>> Perhaps to "scheme", but not exactly. > > Yeah. Especially the stuff from posix should be cleaned up. There are > plenty of things unrelated things in there at varying abstraction levels, > which is only stuffed in there because it's somehow related to an > underlying syscall that's defined by POSIX. This is a little too > system-specific for me; it would make more sense to group those things > together into things like files, process-control, user-management etc, > and define modules in that way. > That got me thinking: maybe we could implement module versioning? Not just put everything into lib/chicken/ but proper module.so.1.2.3 like other shared libraries? And somehow add this to imported namespace (##module#1.2.3#procedure or so). In theory this should allow to move stuff around, but can open a whole can of worms, but still, what do you think? -- Regards, Oleg ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Fix #1133
On 06/27/14 18:41, Felix Winkelmann wrote: >> Depending on how large the subset of procedures is we could perhaps pull >> a simplified version of them into core and optimise that to hell, and >> excise the slow remaining crap from core and move it to an egg (we >> already have some duplication like foldl vs fold and string-intersperse >> vs string-join). But I'm really not sure, I'd have to investigate. > > That might be a good idea. Some of the SRFI-procedures are more > general than we need. Sounds like candidates for "lolevel subset" APIs. There are also a room for leveraging Chicken close relationship with C when optimizing code. We have some bottlenecks where Scheme is "too high level" but using its C API directly is too troublesome. It would be nice to have some more low level stuff conveniently exposed to Scheme side. >>> Take windows into the equation and things get even worse. POSIX is not >>> the most ideal API "standard", but at least it is something one can >>> start with, even if Windows support is somewhat painful. >> >> Hehehe, "somewhat" :) But you're right, most of what POSIX offers is >> valuable and needs to be deeply integrated in core in order to provide >> good support so it makes sense. Still, I like the idea of having only >> completely portable stuff in core, so that programmers know that if it's >> in core, it's going to work everywhere. That can save a lot of headaches >> when porting an application to Windows, or CHICKEN to a completely new >> platform. Looks like it is mostly setup api that pulls POSIX. Making it optional along with csc and friends will allow us to strip the core much more. And they are hard to port to Windows (native) anyway. I have an experimental CMake based Chicken branch where these are not needed. Basically, the agenda is to use CMake to detect as much as it can during compilation, generate bigger chicken-config.h, and get rid of the most platform specific stuff in the core. Write dumb versions of csc, chicken-install, etc. which just generate CMakeLists with predefined macros to provide smooth migration path. Does it sounds worthwhile? > I would propose something like this: > > - identify stuff that's not used in core and move that to eggs, for example: > > memory-mapped files > binary-search (this screams out to be implemented as a functor) > queues > ... much more, of possible ... > > - Completely restructure all library units (extras, data-structures, files, > ports, lolevel, posix, utils). tcp and foreign stay as they are. > > - irregex is used in core and will benefit from as much core-support as > it can get, so leave it as it is, as well. > > - re-implement/copy stuff from SRFI-1/13/14 for internal use only, > move the rest into eggs. > > - I would like to move srfi-18 to an egg as well, only keep the scheduler > and the internal threading-stuff in library.scm in core. Maybe it makes sense to expose some of that to make it easier to implement stuff like concurrent-native-callbacks? I briefly investigated the possibility to integrate it with libuv event loop and the internals looked quite nasty. > - srfi-69 can go to an egg. It is only used in chicken-profile, and > can be done using internal (symbol) hash-tables. > > - I think srfi-4 can be eggified, too. > > - Provide wrapper eggs for all the library units that are gone > (extras, ports, files, data-structures). > > - I'm not sure about posix. Perhaps split this into higher-level > modules (eggify, if not needed in core) and keep a lower-level > interface in core. > > - Use modules for the compiler. It is not used externally (well, > with the exception of user-passes, which nobody uses, I guess) > and would need some restructuring as well. But this may be a > first attempt at using modules internally. We are hooking logging system (extracting file, line number information basically) through user-passes. There are also potential use cases like externally getting module dependency information (sort of like gcc -M options). It is a nice feature to abuse. > > Does this make sense? > Looks like great plan overall. -- Regards, Oleg ___ 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] [PATCH] Fix #1133
> Sounds like candidates for "lolevel subset" APIs. There are also a room > for leveraging Chicken close relationship with C when optimizing code. > We have some bottlenecks where Scheme is "too high level" but using its > C API directly is too troublesome. It would be nice to have some more > low level stuff conveniently exposed to Scheme side. What stuff would you like to see? > We are hooking logging system (extracting file, line number information > basically) through user-passes. There are also potential use cases like > externally getting module dependency information (sort of like gcc -M > options). It is a nice feature to abuse. Ah, ok. Good to know. 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
