***nate_ is now known as nathaniel
***nathaniel is now known as n8a
<ecraven>how do people usually distribute "programs" with guile? is there some sort of "create executable"? <amz3>ecraven: there guildhall <amz3>mind the fact that even if the «Getting Started» has no word about shipping software, it does. <ecraven>does the dynamic ffi support struct parameters and return values? <ecraven>specifically, on page 407 of the manual it says "arg_types should be a list of foreign types". but how do I define a new "foreign type" for an existing C struct type? <ecraven>ah, sorry, page 408 even has an example, I think <ecraven>taylanub: I've been playing around with guile, but it's FFI doesn't seem so good either.. [like *all* Scheme FFIs I've tried so far :(] <ecraven>maybe I should try clasp, that should integrate fine with c++ :) <taylanub>ecraven: OOC, what do you find to be lacking in Guile's FFI? <ecraven>taylanub: it might be entirely my fault, due to not understanding the FFI very well, but there seems no convenient way to access struct members, for example <ecraven>ideally, I'd like (define-foreign-struct timeval (tv_sec time_t) (tv_usec suseconds_t)) and have that take care of the internals <ecraven>(with proper typedefs for time_t and suseconds_t) <ecraven>then I want to use timeval as a foreign type in my own pointer->procedure's <ecraven>this should also give me timeval-tv_sec (and similar for all other members) to access the member fields <taylanub>(define timeval (bs:strut `((tv_sec ,time_t) (tv_usec ,useconds_t)))) ;you'll need to define time_t and useconds_t first though, as e.g. int64, uint64, etc. <taylanub>oh and I forgot the #t argument to bs:struct <taylanub>(I think I'll change that part of the API; it's annoying having to pass #t/#f every time; I think I'll sanction #t as the default) <ecraven>taylanub: can I then write (pointer->procedure timeval (dynamic-fun ..) (list timeval int))? <taylanub>somewhat different, since Guile's own FFI doesn't know anything about my library <taylanub>hm, I could define my own version of pointer->procedure in my lib or so <ecraven>is there no way to define new foreign types for guile? <taylanub>there's that make-c-struct, parse-c-struct thing... <ecraven>yes, but that cannot be used as a type in pointer->procedure either, as far as I understand it <taylanub>ecraven: in any case it should be fairly easy to tie together my library with Guile's FFI. maybe nontrivial for someone who just jumped in; I wish I'd have time to look into it right now... <taylanub>ACTION really wants users for the bytestructures library <taylanub>ugh, one can't just get a bytevector to the return value of a function it seems <taylanub>I hope I'm missing something. otherwise that's nasty :( <taylanub>ecraven: if a C function takes/returns structs directly, that doesn't play well with my library. if it takes/returns pointers to structs, that will work... <ecraven>I do understand that due to the way struct parameters and return values are implemented this is non-trivial, but almost every C library I've tried to use with an FFI in the different Schemes I've tried takes direct struct parameters and return values <ecraven>taylanub: that is the "limitation" that almost all FFIs seem to have <ecraven>but most libraries don't follow that limitation :-/ <civodul>fun: lambda expressions in Python (1) must fit on one line, and (2) must not contain statements <ecraven>hehe, well, you just have to write some very long lines... <ecraven>these seem two very arbitrary restrictions <taylanub>something along the lines of http://sprunge.us/TXOQ (untested) should probably do to allow using bytestructure descriptors instead of pointers for the return and argument types in pointer->procedure (using bs:pointer->proc instead, that is) <taylanub>oh and, passing bytestructures instead of pointers to the procedure, and getting a bytestructure instead of a pointer from it <taylanub>ecraven: but as you say, the pointer limitation applies :\\ I'll look into Guile's FFI code later to see if I could make it use my library directly <ArneBab_>civodul: in Python you just create temporary named functions. Local defines. <rekado_>I sent a minimal patch a while ago to bug-guile in response to a bug report. Should I have sent it to guile-devel instead or is bug-guile the proper place for the patch? <taylanub>rekado_: AFAIK the bug report is the right place; reports can be tagged as "patch available"... <rekado_>in this case I'll just wait for someone to pick it up then. <civodul>rekado_: no that's ok, it's just that maintainers and developers are, ahem, unresponsive <crodjer>civodul: Python isn't too favoured for functional programming. <crodjer>Recently, I wrote a Python library at work inspired from a few Haskell concepts I learnt. <crodjer>Had to pretty much rewrite the utilities functools provided. <crodjer>But in Python functions are first class, so theoretically one could "do" everything. Won't be as fun as Haskell/Lisp though. <rekado_>civodul: that's okay. I was just wondering if I did something wrong. <davexunit>rekado_: mark had asked me to look at your sxml patch. <rekado_>davexunit: oh, good. I'm not emotionally attached to the patch, so if you have a better idea, feel free to replace it :) <rekado_>I'd just like sxml support to be a little less frustrating. <davexunit>I wasn't subscribed to bug-guile at the time the patch was sent <davexunit>so if I have you on the line I can apply it and better understand the changes. <davexunit>rekado_: okay, so this same interface is available for xml->sxml <davexunit>and your patch makes it work in both directions <rekado_>it doesn't help in cases where the namespaces are unknown. <rekado_>but it allows users to use the same mapping of namespace abbreviations in both directions. <davexunit>rekado_: I feel like the generated sxml should have notation for such things <davexunit>if it was able to parse out namespace information, why didn't it represent that in the output? <rekado_>when it generates sxml the namespaces are kept. They appear in front of the tags. <rekado_>since they are URLs in most cases, though, they end up containing invalid characters. <rekado_>so the conversion back to XML fails. <davexunit>I guess I need to get some code in my REPL to see it in action <lloda`>I always make this mistake (format #t "a ~a b ~b" a b) <daviid>ecraven: wrt distributing apps, I'd use the autool chain, since it is exactly made for that <davexunit>yes, the autotools make it easy to build from source. as far as distributing pre-built stuff: that is for package managers to take care of. <davexunit>does a good explaining why I don't like templating languages <amz3>there is a dsl in scheme of sql that worth looking at? <paroneayea>davexunit: the "sql garmmar is so complicated" I think is spot on. <paroneayea>I think it might be nice if there was a grammar that was actually s-expressions on the backend? It's possible in postgresql. <davexunit>I think that simple s-expressions may not be the best format <daviid>I'd like sxml->html to include a bracket reader per default ala skribilo <davexunit>a "select" query has a few distinct segments: the columns to select, the filters to apply, the sort order, etc. <davexunit>rather than keep those in an ordered list, a record type would be better to work with <daviid>davexunit: what amz3 provided, but w/o his kw 'simplification' (I really do prefer ther s-exprtession kept wrt that) do you remeber ? <daviid>amz3: don't you have an example somewhere? I can't find the link out of my head <paroneayea>davexunit: that post makes me feel that for now, it's best just to stick to writing SQL expressions that are like (query "SELECT name, animal FROM zoo WHERE food_pref = $1" "banana") <paroneayea>which is basically the only thing I support in guile-squee so far!... <davexunit>that's what postgresql supports out-of-the-box, so yeah, that's a reasonable first step. <paroneayea>eventually I'd like a nice DSL, maybe looking back at how sqlalchemy does things again <paroneayea>I think it's true that making a decent DSL that's not some highly constrained ORM like thing is going to be hard. <davexunit>but if you define a few types you can represent the AST quite easily and write procedures that can be composed to form complex queries. <daviid>davexunit: so we could write things like (p [Guile-Gnome is a ,(%guile-a) wrapper collection for the following ,(%gnome-core-libs-ref-a):]) <daviid>instaed of (p "Guile-Gnome is a " ,(%guile-a) " wrapper ..." ,(%gnome-core-libs-ref-a) ":") <davexunit>a special reader could create SXML from this <daviid>davexunit: yes, as i said, a bracket reader inculded... <davexunit>daviid: yes, but that is beyond the scope of SXML <daviid>davexunit: but it would be nice to have ot and not have have to parse in a diff way so that, if it was 'there', we could still 'just' call sxml->html ? <davexunit>I wouldn't want to mix the interfaces like that <davexunit>paroneayea: I think you could make something that supports all of the PostgreSQL syntax without making it constrained <davexunit>I think the author was talking more about how ORMs tend to code for the LCD of databases <davexunit>in an attempt make it trivial to swap between databases, but we both know thatis silly because despite the similar language, they are all quite different. <daviid>davexunit: it would not change anything to the sxml language def as it is, would it? <daviid>a change in sxml spec would introduce and/or change tag(s), the way they are processed ... but not a #\\[ reder, afaict, it would just be syntactic sugar <davexunit>daviid: my point is that xml->sxml shouldn't invoke such a reader <davexunit>sxml->xml takes an s-expression and produces an XML string <mark_weaver>SXML is an existing language. david is proposing a different language, and it should have a different name. <mark_weaver>and the other complication is that it involves changing the reader, which can have far reaching effects to other code in the same process <davexunit>I think a reader that read in a more "human-friendly" language like Skribe or Pollen and produced an sxml expression would be cool. <mark_weaver>we don't have a way to limit the change in lexical syntax that daviid is suggesting to just the bits that are fed into sxml->html <amz3>daviid: I agree the simplification with keyword is not helpful <mark_weaver>the whole idea of sxml is that they are s-expressions, and that's a great advantage. using some different syntax than s-expressions causes a lot of complications. <daviid>i don't agree with the 'different language' qualification here :) I'm just saying that we could do with [automatic] reader, since it would be auto and precisly would not change the language :) <amz3>not of much help, it's another style <davexunit>mark_weaver: sorry if I'm not being clear, but what I'm trying to say is that something like what Skribilo provides as a layer built on top of SXML would be useful to some. <daviid>it is not, by no mean a diff language I'm talking about, I woudn't dare :) <amz3>sorry but skribe syntax is not prose <mark_weaver>and I don't see how you can claim that it's not a different language. <daviid>mark_weaver: I don't see why you claim it is <mark_weaver>if you need to change 'read', then it's a different language. <davexunit>both Skribe and Pollen are languages i.e. not Scheme whose associated reader could produce SXML that Scheme programmers are well equipped to manipulate. <mark_weaver>one way to define a language is that it's a set of valid strings. <davexunit>people write blogs with Racket by writing in Pollen and writing Racket programs to manipulate their evaluated form. <mark_weaver>daviid: what definition of "language" are you using that equates (p [Guile-Gnome is a ,(%guile-a) wrapper collection for the following ,(%gnome-core-libs-ref-a):]) with (p "Guile-Gnome is a " ,(%guile-a) " wrapper ..." ,(%gnome-core-libs-ref-a) ":") ? <taylanub>paroneayea: Guile's FFI doesn't know a "string" type FWICT. you'd represent it as a pointer. <mark_weaver>actually, by the way I usually use the term "language", it's not just a set of strings but a mapping of strings to meanings. <mark_weaver>paroneayea: yes, 'string->pointer' checks for that. it raises an exception if there's a NUL in the string. <mark_weaver>daviid: anyway, the problem is that (p [Guile-Gnome is a ,(%guile-a) wrapper collection for the following ,(%gnome-core-libs-ref-a):]) is already part of the well-defined syntax of R6RS and Guile, but it maps to something different than you're proposing. <mark_weaver>in R6RS, square brackets are treated exactly the same as parentheses, and many people make use of that syntax throughout their code. <daviid>ah, that would be a problem indeed, I forgot about that <daviid>mark_weaver: tx, will change our output-html to accept another #:transform-rules [output-html is part of our webpages sxml->html business :) <daviid>our I mean guile-gnome, guile-clutter, g-wrap ... <mark_weaver>daviid: how will you make it work? 'read' loses the information about whether square brackets or parentheses were used. <davexunit>paroneayea: I have too many things on my plate, but I think writing a PostgreSQL-only EDSL for Guile is well within reason. my current question would be if the number of data types needed would be too crazy or not. <davexunit>I'm somewhat convinced that plain sexps don't fit this problem well because of how hard it would make writing combinators that operated on them. <davexunit>a 'select' expression may have a 'where' clause, but it might not. it may have an 'order by' clause, but it might not. the number of cases to consider when pattern matching would be daunting and likely slow. <mark_weaver>davexunit: sounds vaguely reminiscent of XML attributes <mark_weaver>davexunit: how will adding more data types help in a way that can't be done with s-expressions? <davexunit>mark_weaver: a little bit, but this is more complex, let me see if I can explain. <ecraven>{} are still unused, aren't they? :P <davexunit>mark_weaver: one difference: the order of xml attributes is not important, but the order of SQL clauses are. <ecraven>ah, sorry, I'm ignoring all the "s-exps aren't good, here is a better syntax" SRFIs as totally useless to me :) <amz3>sorry taylanub I have a bug in my library regarding ffi and pointer->string, are you aware of any such bug? maybe I'm corrupting memory? wdyt? <taylanub>ecraven: right, except stock sexprs simply aren't good for some things, and SRFI-105 offers a better sexpr syntax for those things ;-) <davexunit>mark_weaver: you might be saying "well how about an alist?" now and maybe that could work, but I still picture implementation difficulties along the way when writing combinators. <mark_weaver>ecraven: I usually don't like the syntax extensions either, but IMO, curly-infix could be a real improvement to readability without sacrificing the nice properties of S-expressions, when used very selectively. <taylanub>ecraven: compare (+ (vector-ref v 1) (vector-ref v 2)) to {v[1] + v[2]}, and imagine your code contains a ton of such forms (and more complicated variants thereof). <mark_weaver>but most inventors of these things go crazy and use them *as-much-as-possible*, which I find in very poor taste. <taylanub>agreed; SRFI-105 (and e.g. SRFI-123) should be used only in code-bases whose overall style is suitable for that sort of thing, IMO <mark_weaver>davexunit: the portability and convenient serializability of s-expressions is a big advantage <davexunit>mark_weaver: yes, which is why I want to think hard about this. <davexunit>but for certain things, you really do want record types. we wouldn't want guix package expressions to be just lists, for example. <mark_weaver>yes, I agree that record types are the right thing in most cases <davexunit>I guess it comes down to what is the easiest to work with. s-expressions are a perfect fit for xml, which has very uniform rules. SQL is a more complex langugae. <mark_weaver>ecraven, taylanub: to my eyes, I don't even find taylanub's example a very compelling one. for me, it's things like this: (> (string-length x) 0) <mark_weaver>I find things like {(string-length x) > 0} and {(string-length x) - 1} much more readable <taylanub>I sometimes turn around the > to < or vice versa in situations like that, now that I think of it <mark_weaver>when avoiding curly-infix, I end up writing things like this instead: (< 0 (string-length x)) and (+ -1 (string-length x)) <mark_weaver>but those are not so pleasing to my eyes either, and sometimes a bit confusing. <ecraven>mark_weaver: 1+ and 1-, positive? and negative? <ecraven>I find myself using lots and lots of "small" functions <ecraven>but of course, giving proper names to these is very hard <mark_weaver>ecraven: sure, those work in some cases, although personally I *refuse* to use 1-, because (1- x) looks like the negation of what it actually is. <daviid>wingo: could you handle my 2 first [yesterday] requests asap pleaaase :) thanks! until you do so, I'm in a dead-end wrt these 2 projects <ecraven>mark_weaver: sorry, I've seen something better, I dislike 1- too.. just don't remember what it was.. <ecraven>mark_weaver: 1- is just plain wrong :) <davexunit>I rather like 1- and 1+, but I can see the arguments against. :) <ecraven>I guess the point I'm trying to make is, I don't see sexprs as "worse" than infix, even for maths, you just need the right functions (and a lot of exposure) <davexunit>or 'increment' and 'decrement' to avoid abbreviations <ecraven>for example, 1/2+3+5-4/5*3-5 is a lot less readable than properly indented sexprs <wingo>abbreviations are great for math <ecraven>davexunit: but the main point for math is brevity :) <mark_weaver>well, Paul Graham and I are in agreement about one thing: although both of us have had *plenty* of exposure to prefix notation, I still find it rather unnatural to the eye in some cases. <ecraven>mark_weaver: like in mathematical expressions? what others, if I may ask? <mark_weaver>if I'm adding a bunch of complex things together, I find prefix very natural. <davexunit>so does most everyone else, and here wer are... a niche language. <daviid>what I don't/am bad at is to mix notations. if I read scheme, all has to be preifx for me, but I guess it's habbit <mark_weaver>well, I gave some examples. I think that binary operators can be hard to read in prefix when the first argument is sufficiently long or complex. <daviid>and I can't read curly, no matter what <mark_weaver>it's about the distance between the binary operator and its second operand, and about the visual processing necessary to skip past the first operand. <daviid>mark_weaver: even in your example, I still prefer the prefix notationb, by far <davexunit>for binary operators, I see the appeal for sure. <ecraven>mark_weaver: for that distance, I find myself breaking things up with only one thing in each line, so the operator is easily visible due to indentation. have you found that to help? <mark_weaver>ecraven: yes, I often do that, but it seems like a waste of a line when the second argument is something very short, like '1' or '0'. <ecraven>I just recently learned about C-M-t (transpose-sexps) in emacs <mark_weaver>I'm also interested in trying to make Scheme more palatable for people who prefer infix, if it can be done without losing the important properties of s-expressions. curly-infix does that. <daviid>can't find maintainers at gnu dot org archives any one knows ? <mark_weaver>I was not aware of any such list. I guess I should be on it? <daviid>mark_weaver: I didn't either, but a gnu maintainer emailed me about the guile-clutter split request [specific savannah gnu project page ...] and I wanted to posted here for wingo <daviid>mark_weaver: neither did i hence my quizz <daviid>davexunit: don't know. I initally wrote to gnueval [as suggested by the savannah volunteere] then Brandon rerouted it to this maintainers ... <saper>ACTION prefers postfix notation :) <saper>daviid: To see the collection of prior postings to the list, visit the maintainers Archives. (The current archive is only available to the list members.) <saper>mailman has ability to hide some lists from the general "listinfo" view <saper>I like Forth, but I will try to learn guile <amz3>taylanub: sorry for saying guile was buggy, I'm now sure that I messed too much with pointers :/ <roelj>I'm looking to write a C program with a Guile command interpreter to write behavior rules for the running program (so it's self-learning). Would that be possible with GNU Guile? <davexunit>roelj: guile may be embedded in a C application, yes. <roelj>Kind of like this: C program outputs Scheme, then calls the outputted Scheme code for a yes or no answer? <davexunit>you would typically expose C functions to Scheme and write Scheme scripts that manipulate the C program. <roelj>The point is, I'm not sure if I can program in Scheme/Guile well enough to write the entire program. It's a school assignment for writing an AI for a game, and I'm constrained to 10 weeks of time. <daviid>saper: yes, do learn scheme in general anf guile in particular, cool thing to do for who ever have to program :) <roelj>Is it possible to evaluate scheme code from within the C program? (Possibly, using a socket or pipe?) <mark_weaver>Guile has a very extensive C interface, the function I just mentioned is just one of many. <saper>daviid: My lisp knowledge is "Tried reading <<On Lisp>> may times" <davexunit>paroneayea: tox is interesting, but I'm not optimistic for their success. <davexunit>I wrote guile wrappers for some of their API once <roelj>davexunit and mark_weaver: Thanks! <amz3>I found the bug i was chasing, so, I am passing pointers to a variadic function, hence the number of pointers is dynamic, I was initializing the pointers with the following code (map (lambda (_) #u64(0)) (iota number)) the thing i did not know is that the #u64(0) was a single entity for the life time of the procedure where the lambda is defined <amz3>I was retriving 'number' of times the same value, because the pointer was the same for all values <mark_weaver>amz3: not only that, but the compiler is allowed to combine all the #u64(0) in your entire program! <mark_weaver>in scheme, all literals are immutable. unfortunately, we don't currently detect attempts to mutate them in most cases. <mark_weaver>I believe that in 2.2 the literals will be in read-only memory, at least for compiled code, so such errors will be detected. <mark_weaver>use 'make-u64vector' or 'u64vector' instead, to create a vector that will be mutated. <amz3>ok thanks, I looking up the correct way <amz3>this leads to much more c code in my library. <amz3>especially since it's no really intersting code ;) <mark_weaver>so, but modifying #u64(0) is the moral equivalent to modifying 's' in the C code: char *s = "hello" <mark_weaver>the explicit creation of a new string, or array, cannot be avoided. <mark_weaver>at least not without radically changing the semantics of the language, and I think you'd find those new semantics to be intolerable. <ecraven>copy-on-write for mutated literals :) <mark_weaver>we had a long discussion about this, in the context of strings, on guile-devel a few years ago. <mark_weaver>copy-on-write was suggested in that thread as well, and I explained the very serious problems with that approach. <mark_weaver>I don't feel like explaining again, so let me try to dig up a link. <mark_weaver>it was a mega-thread, but that message explains the fundamental problem with trying to do copy-on-write at the level that would be required to automatically handle code that would mutate literals. <amz3>I don't have any particular point of view regarding this feature <amz3>(I was saying that I reworked my library to use more code of the library, because before I was not using variadic functions, which lead me to duplicate code in scheme) <amz3>in python one never use list or map as optional arguments default value, because of that immutable/mutable behavior. And arrays are immutable, I think it's copy-on-write <amz3>s/more code of the library/more code of the c library wiredtiger/ <taylanub>amz3: ah, sorry for not responding earlier, I got distracted. and nope, I'm not aware of bugs there, though I haven't used the FFI much yet <amz3>taylanub: the bug was it was in my code, I was using #vu64(0) to init a pointer instead of u64vector(0)