IRC channel logs


back to list of logs

***karswell` is now known as karswell
<paroneayea>bipt: around?
<nalaginrut>morning guilers~
<zacts>hi guilers
***michel_mno_afk is now known as michel_mno
<koz_>I'm trying to create a closure in Guile (as part of Autogen), and it doesn't seem to like my efforts much.
<koz_>Could someone tell me what I'm not doing right?
<lloda>you may be missing ... ) struct-name) at the end instead of ... ))
<lloda>you need to put something in the let body after the define
<lloda>but I don't see the point of that define
<koz_>lloda: I just realized.
<koz_>I'm basically generating a constant.
<koz_>So yeah, I'm failing a bit there.
<lloda>you can do just (let (...) (lambda () ...))
<please_help>is there a way to get the address of a primitive to pass to C code or do I have to make a single-element bytevector for that?
<lloda>what is a primitive?
<please_help>3, #\\a, etc
<taylanub>(pointer->scm (make-pointer (object-address 2))) => 2 ;this seems to work not really through addresses, but through the fact that using `object-address' on an "immediate" value yields some number that corresponds its bit-pattern, and pointer->scm does the reverse of this conversion
<taylanub>not sure if one should rely on this
<please_help>I need the actual address so it can be passed to a C program via the ffi though
<please_help>with make-pointer, will that give me something sensible?
<please_help>also what's the signed array-typed that corresponds to 'u32? For some reason I can't find the list of valid array types.
<please_help>oh right, s32, nevermind
<taylanub>please_help: the C function probably takes an SCM value, right? in that case it should be fine giving it a value that is a valid SCM even if it's not an address to an existing SCM
<taylanub>("immediate" values are immutable anyway so there won't be any difference between passing a reference to an existing one, and a new one with the same value)
<please_help>the C function takes... an int pointer!
<taylanub>as in a pointer to an int? in that case you'd convert an SCM integer to a C integer and take a pointer to that, no?
<please_help>I'm using the ffi to wrap C code, I'm not using guile.h in the C code or whatever
<please_help>is it possible to go scm_int -> int in scheme code?
<taylanub>if the function works with C ints, then it wouldn't work with a Scheme integer anyway. I think the right way here is to make a bytevector and write a Scheme integer into it via bytevector-*-native-set! or so
<please_help>via c using guile.h certainly, but in scheme?
<please_help>rather what I'm doing is (bytevector->pointer (array-contents the-single-element-bytevector))
<please_help>this works as expected.
<please_help>where the-single-elemnt-bytevector is really an array*
<please_help>the reason for that being that the bytevector interface is painful to use when the type of data being handled might change at runtime, whereas the array interface doesn't have that problem
<taylanub>is the 'array-contents' call necessary there?
<lloda>you can convert a scheme int to actual int with (make-s64vector your-integer) and pass that to bytevector->pointer
<lloda>no array-contents is necessary with a bytevector, only with a general array
<lloda>all srfi-4 types are bytevectors
<taylanub>weren't SRFI-4 vectors possibly going to be disjoined from bytevectors, except making the u8vector type synonymous to bytevectors?
<lloda>not that I know.
<lloda>you can pass any SRFI-4 vector to any of the bytevector-... functions.
<lloda>they will simply ignore the type tag.
<taylanub>never mind, I'm probably confusing something, though there was some talk about how SRFI-4 and bytevectors interact IIRC
<taylanub>I see
<lloda>sorry, where I said (make-s64vector ...) -> (s64vector ...) ofc
<dsmith-work>Tuesday Greetings, Guilers
<please_help>is there an overhead difference in using arrays instead of vectors?
<lloda>yes. don't worry about it.
<taylanub>seems what I said was just my expectation at one point :P
<lloda>there is a type-specific api, that's SRFI-4
<lloda>like u8vector-ref will only work on #u8() etc
<lloda>but the bytevector- api doesn't look at that
<lloda>I wouldn't say it's type generic (like the array api actually is), it just ignores the type tag and goes directly to the bytes
<taylanub>type-mixing like this always scares me, but I guess it's fine here
<lloda>I guess so, it's about bytes after all
<lloda>I think it's a problem if people use it for typed vectors, though
<lloda>if you do a lot of bytevector-ieee-double-native-ref, that sort of thing
<please_help>how large is the difference in overhead?
<lloda>the overhead is because of type dispatch. So, it depends on what you do.
<lloda>when in doubt, test.
<lloda>for what is worth, myself I use the array interface almost exclusively.
***michel_mno is now known as michel_mno_afk
<paroneayea>everything becomes turing complete eventually... including css, it seems
<paroneayea> <- via tsyesika
<ijp>html + css was shown to be turing complete a good while back
<ijp>nice to see css finally manages it on its own
<linas>anything like a "python notebook" for guile? I want to stick guile examples into a web page, and "just run them" by clicking.
<ArneBab_>ijp: I know why Freenet filters CSS with a strict whitelist…
<ArneBab_>can’t really have privacy and turing complete third party programs at the same time ☺
<ijp>linas: no