<nalaginrut>since I used 'format' a lot in ORM for object->sql issues, I start to worry about the efficient of 'format'... <lamefun>(define-syntax (lambda (syn) .. what do I do with syn? ..)) <lamefun>can I navigate it manually or only with syntax-case? <nalaginrut>you may just use syntax-rules, it's easier, unless you have to do some complicated <wingo>(define (syntax-car x) (syntax-case x () ((car . cdr) #'car)))) <lloda>hello wingo, sorry to bother you again with this, but is there any chance of having the array stuff reviewed before christmas? <wingo>i went to do it one day but i didn't have internet then, and it was a github url <wingo>what is the url again? i will fetch it now <lloda>there's a branch on top of stable-2.0 (ra0) and a branch on top of master of some time ago before the register vm (master-ra0) ***goto is now known as anderson
<jcca>Hi all, I am newbie in guile. How can I use serial ports? How I can improve this code? <jcca> (lambda (port-name baud) <jcca>Does not work, I have tried connect with (define out (serial "/dev/ttyACM0" "115200")) <TaylanUB>jcca: First of all I'd refrain from using `system', and prefer (ice-9 popen). <TaylanUB>(Or maybe not something from the popen module, but in any case something that builds up an argv and launches a command itself, instead of calling the shell.) <jcca>TaylanUB: Thanks, I will try it <TaylanUB>Well it probably won't solve your actual issue. What does "does not work" mean by the way, e.g. do you get an error or so ? <jcca>there are no errors, I try e.g (write "1" out) and nothing happens (should light a led) <TaylanUB>Hrm, sure you want to write an ASCII 1 and not a byte 0x00000001 ? <TaylanUB>Oh and `write' will actually quote the string in the output, no ? <TaylanUB>(It's meant for transmitting s-expressions.) <jcca>Oh, Thanks, I will try write a byte. <TaylanUB>Might want to try `simple-format'. Strangely there seems to be no (documented) `write-string' procedure. Though perhaps bytevectors are more appropriate for that ... <TaylanUB>jcca: You might want to read (info "(guile) R6RS Binary Output") <TaylanUB>(If you want to write a byte with numeric value 1.) <jcca>TaylanUB: yep, I am reading guile doc, is my second day learning scheme... <jcca>i found (string->bytevector "1" "utf-8") <jcca>I think something was wrong with my serial function, I will check it, Thanks a lot for help me TaylanUB <TaylanUB>Strange, I can't figure out in what module that is. (Importing (rnrs bytevectors) and (rnrs io ports) didn't do.) <mark_weaver>TaylanUB: to write a string to a port without the quotes, use 'display'. <mark_weaver>if what you want to write a text, I see no reason to convert it to a bytevector first. just display the string to it. <TaylanUB>mark_weaver: Ah OK, the name makes one think that it's meant for displaying text meant for humans to see, but I suppose it guarantees that the string's exact contents (according to a certain encoding) are written ? <mark_weaver>I think it's possible that the serial port settings he made using 'stty' are reset before he opens the device. It might work better to call 'stty' after opening the serial port, but I'm not sure. When I've written code to talk to a serial port, I've used tcsetattr, cfsetispeed, cfsetospeed, etc. <mark_weaver>TaylanUB: yes, display doesn't do anything fancy. it just writes out the object, whether a string, character, number, etc. <mark_weaver>display is precisely the right thing to use to write a string or character to a port without any adornment. <mark_weaver>(well, for characters I suppose there is 'write-char' also) <dsmith>mark_weaver, Thanks for the links <davexunit>wingo: reading your latest blog post about guile 2.2. it's a very good read! <wingo>got a couple more queued up, once i fix guile docs <tromey>guile scripting is going to go into gdb soon <tromey>from what I remember the patch adds a new module and then just a bunch of new functions <tromey>I was wondering if this is typical for guile extensions <tromey>I mean as opposed to, say, something more OO-like <wingo>yes i think that is the usual interface <wingo>do you have a link to the patch? <tromey>not sure how close that is to what will eventually go in <tromey>the reason I'm asking is just for review purposes <tromey>I wanted to make sure that at the grossest level gdb isn't going off the rails <tromey>next question - is guile-gnome the up-to-date way to write a gui? <wingo>yes i think that is idiomatic guile style, for better and for worse :) <tromey>and whatever happened to guildhall? <wingo>tromey: guile-gnome is the thing, also for better and for worse -- it is a pretty good gtk2 wrapper, but not updated to gtk3, and there are not many users <wingo>guildhall exists, currently curated by ijp <wingo>right, not very well advertised, but you can guild install things and it seems to work for people <wingo>scheme-only things for the moment <wingo>so there's no support for e.g. guile-gnome <tromey>I thought gtk 3 had a better approach to bindings, maybe possibly scheme-only? <tromey>I didn't look under the hood at the python gi.repository stuff yet <wingo>but i have been perhaps too conservative <wingo>and introspection was a big big mess from the gtk side for a while <wingo>i stopped writing guis about the time gtk3 came out ;) <tromey>yeah, I don't really write them, I just mess around <tromey>I was curious if I could replicate my gdb/python hacks in guile <wingo>could be, yeah -- i imagine you could replicate some of it though with an installed guile-gnome from a distro or so <wingo>hum, currently depends on guile 1.8 in debian <tromey>I'm on F18 so I only have guile 1.8 <wingo>but i imagine that the gdb bindings also work with guile 1.8 <tromey>I probably won't be able to build it without upgrading this machine <tromey>well, or building guile myeslf I suppose <wingo>perhaps you can get the contributor to make it guile 1.8 compatible <tromey>funny how that doesn't seem like an option any more <mark_weaver>does it really make sense to work on 1.8 compatibility at this point? I wonder. <tromey>well, Fedora 18 isn't exactly ancient <wingo>if it makes it easier for tromey to try it out, i would say sure <tromey>gdb supports Python back to 2.4, which is positively ancient <wingo>especially with a distro guile and guile-gnome, it's attractive to avoid building things, if anyone else would use it <tromey>the plus side is - pretty much everybody gets python <wingo>i love the python gdb things when i hack on firefox <wingo>just worked from the beginning <tromey>anyway, I will ask about 1.8 support ***fangism-ctrl-Z is now known as fangism1
<mark_weaver>The problem is, supporting 1.8 mostly means limiting oneself to what's available in 1.8. I gave Doug a bunch of support during his work on the gdb bindings, and I'm pretty sure that he ended up using some things that aren't available in 1.8. <wingo>surely there could be some shims? <tromey>it's been an issue for python as well. we've had to write some bits a bit strangely <wingo>for things like scm_from_utf8_string and such <mark_weaver>normally, I'm in favor of supporting old versions of things, but Guile 2 is a very substantial improvement over 1.8. *wingo defers to mark_weaver here <tromey>does the 2.x series give any ABI stability guarantees? <mark_weaver>I guess I'd have to look the code to see how painful it would be to add 1.8 support to it, but my inclination would be that it should not be a high priority. <tromey>I wonder what the futures hold here <tromey>does guile use symbol versioning ? <wingo>it is also parallel installable with future versions <wingo>not symbol versioning, but name versioning -- libguile-2.0.so, /usr/include/guile/2.0, etc <mark_weaver>I think that things will be a lot better moving forward. the 1.8 -> 2.0 transition was particularly painful because it changed from a pure interpreter to a compiler-based system, and also made some other important changes such as: strings are now sequences of unicode code points, not merely byte strings, etc. <tromey>gdb supports python 2.x and 3.x which had similar issues <wingo>so 2.2 will have an incompatible abi and deprecated api removed, but parallel installable, so it shouldn't disrupt gdb <tromey>from my perspective it's about shipping features to users <wingo>when people want to update guile in gdb they can do it as they want, not as they need to do so ;) <tromey>in this case it limits guile adoption, but again, if you think it is ok, it's fine by me, I won't add that to my review <tromey>I guess so, but that's not really a common scenario, at least in the distro world <tromey>I was wrong to ask about ABI really, since I actually care more about source compatibility <wingo>by that you mean that you choose e.g. a version of python <tromey>like will guile 2.N mean we can't easily work with 2.0 or something <tromey>gdb builds against a wide range of python libraries, but only one at a time <wingo>well, we try to keep things compatible, and anything that changes incompatibly changes by replacement rather than modification, preceded by deprecation <wingo>with the ld deprecation thing, so hopefully it shouldn't be too much of a burden <wingo>actually we will release 2.2 sometime around april i think, and the c api changes are minimal <wingo>deprecated stuff is gone and there are a few new things, but c code using non-deprecated things shouldn't need to change <tromey>I'm kind of dismayed by this 1.8 thing. but I guess I will just upgrade my machines and hopefully forget about it <wingo>the problem is, what do you do about strings? it's difficult to be correct <tromey>for python we just have #ifs controlling it -- ugly but it works <wingo>if you are ok with something like that, then probably it is possible to work with 1.8 <tromey>I guess it's a question of whether anybody will be willing to implement it <wingo>will see if i can get to it tomorrow in one of the many firefox-is-building phases :) <tromey>I think guile just showed me a bug in readelf <civodul>good that we have an additional ELF producer/consumer <tromey>I think it is a Mach-O workaround in readelf that erroneously gets applied here; partly because for some reason the guile-generated DWARF sections have non-zero addresses <tromey>why do they have non-zero addresses? <tromey>right now I think it is a readelf bug <civodul>you could post to bug-guile@gnu.org for future reference <tromey>I guess guile makes these debug sections PROGBITS since it wants them at runtime <civodul>i'm sure wingo will be happy to know that it's allowed you to uncover a Binutils bug ;-) <mark_weaver>sorry, I know very little about DWARF. This is wingo's area. <civodul>ijp: indeed, sorta like Coccinelle, only on a syntactic level <ijp>I didn't know about coccinelle <mark_weaver>I could probably learn anything in Guile that I needed to know, but each thing takes time. <civodul>it's a great idea, for a poor language <tromey>ok, it seems the binutils hack for mach-o was then partially removed