<taylanub>ijp`: I re-wrote big parts of procedural.scm. <taylanub>Updated. I really don't like the way I have to do (make-bytestructure-descriptor (list bsd:vector n (list ...))) by the way; that's an open issue. Also I define int8, uint8, etc., which are also defined in the FFI libraries I think. All subject to change/clean. <taylanub>Or maybe with full quasiquote-usage it isn't so bad .. in fact let me just updated the README to use that style. <taylanub>Done. Could be better yet, but not without a separate namespace, and I guess that's worse. ***ijp` is now known as ijp
<ijp>hmm, when did we change tree-il to use call instead of application, and seq instead of sequence? <ijp>okay, so that's language/lua/compile-tree-il.scm fixed, I think <ijp>oh I see, make-seq doesn't expect an expression, and a list of expressions, but two expressions *ijp travels back in time, and shouts at 2011 wingo <ijp>good, now I'm down to only 7 errros <ijp>okay, down to a problem with an unbound variable <ijp>as an aside, it's a PITA when someone mixes "sexp" tree-il with the actual scheme, because the former doesn't give me compile time warnings :( <ijp>okay, simple scoping issue. Used a let instead of a letrec <ijp>okay, I now have the lua branch passing all tests <ijp>I'll bring it up on the list tomorrow <ozzloy>anyone in here participate in FIRST robotics? <ozzloy>high school robotics competition started by dean kamen <mark_weaver>ozzloy: I'd not heard of it before. Looking at the wikipedia page, I see that teams are provided a control system, as well as programming and design software. Is it free software? <lloda>this array stuff is a total mess <wingo>multiple days of "wtf is going on here" <wingo>i think it's important to start with bugs <wingo>we agree that a behavior is bad, we agree what the behavior should be <wingo>then we figure out how to fix it <wingo>sometimes it's difficult to think of these things when working on a patch <wingo>bugs also document why changes are made, which will be useful to lloda+3 years ;) <lloda>do you know what is the point of the array acquire-release mechanism? <lloda>currently scm_array_handle_release does nothing <lloda>it clutters every array function <lloda>why would an array need to be reserved? ***brendyyn is now known as brendyn
<wingo>lloda: i think it's so that you can pass around an array handle and work with it without worrying about the array itself being collected <wingo>if we had a moving GC it could pin the array, though that would be pretty far out... <lloda>the array handle contains an SCM array field, isn't that enough to prevent the array from being collected? <lloda>then can we get rid of all the release calls (!) <wingo>currently as you say the release calls do nothing <wingo>i can imagine situations in which they could do something <wingo>and passing the pointer to the array to a release does prevent the compiler from optimizing out the SCM reference <lloda>I see that last point in principle <mark_weaver>wingo: I've run into a very mysterious problem trying to merge the ports stuff into master. <mark_weaver>wingo: I have this little patch that moves three fields from scm_t_ports into the internal ports structure, and that's all it does. and a bunch of tests break. <mark_weaver>I'm at a loss.. something in master having to do with popen is very fragile. <wingo>did you rebuild guile-readline? <mark_weaver>wingo: yes, that got rebuilt automatically (I see from my shell history) <mark_weaver>(though I don't know what readline would have to do with popen) <mark_weaver>wingo: aside from popen, it also breaks a few other tests: FAIL: posix.test: ttyname: non-tty argument <mark_weaver>wingo: and a bunch of tests in 00-socket.test, e.g.: ERROR: 00-socket.test: AF_UNIX/SOCK_DGRAM: bind - arguments: ((system-error "bind" "~A" ("Socket operation on non-socket") (88))) <mark_weaver>I've looked carefully over this little patch about 5 times, and I just can't imagine how it could break so many things. <wingo>mark_weaver: it's a separate library that uses ports; dunno <mark_weaver>but yeah, maybe clearing out all the .o and .lo files is worth a try. <mark_weaver>all I can think of is that it has something to do with finalizers, because some things that used to hold a reference to the main ports structure, now only hold a reference to the internal one. <mark_weaver>but I added an fprintf to the port finalizers (both the main one and the iconv one), and at least in the popen tests, no finalizers are triggered before the new hangs. <mark_weaver>I think I'll focus on the 00-socket.test errors for now. seems easier to debug, and maybe it'll lead to an "aha". <mark_weaver>ha! a full rebuild of the C code fixed the problems. <mark_weaver>well, that makes me happy, but I'm curious what failed in our build system. do I have to explicitly ask for dependencies to be recomputed or something? <mark_weaver>well, apparently that wasn't the problem at all. it was just a thought, while I was grasping at straws. <mark_weaver>but I agree that finalizers are pretty nasty in general. <mark_weaver>I guess I should try to figure out what needed to be rebuilt, but wasn't being automatically rebuilt. <mark_weaver>civodul: why are there two copies of every *.o file? (one in .libs and outside of .libs) <civodul>i thought one is fPIC and not the other <civodul>mark_weaver: oh yes, the one in .libs is -fPIC, and not the other one <civodul>configure with --disable-static to avoid that *civodul goes back into stealth mode :-) <mark_weaver>(and to simplify this binary-search I'll have to do to figure out what didn't get rebuilt) <mark_weaver>civodul, wingo: so I debugged the build system problem. in master at least, modifying ports.h fails to rebuild socket.o or posix.o. rebuilding those by hand fixes the problems. <mark_weaver>socket.c includes fports.h which includes ports.h, so it should have been rebuilt automatically. <wingo>it could be something related to --enable-posix / --enable-networking <mark_weaver>same issue with posix.c: it includes fports.h which includes ports.h <mark_weaver>I suspect the reason this affects master and not stable-2.0 is because in master I changed some members of scm_t_ports near the beginning of the port structure. <mark_weaver>(in stable-2.0 I didn't change scm_t_ports at all, as you know) <civodul>mark_weaver: yes, those files are not built via libtool, which is Bad <mark_weaver>is there a straightforward fix to get those object files rebuilt automatically? <mark_weaver>how about always compiling those files, but putting the whole file within #if ? <mark_weaver>and then they could be handled in the standard way, right? <civodul>mark_weaver: rather use AM_CONDITIONAL, remove the AC_LIBOBJ, and add an if BUILD_FOO in Makefile.am <mark_weaver>civodul: would you be willing to do it? I don't know what I'm doing with automake/autoconf. I could learn by seeing your patch though :) <mark_weaver>(I'm sure I could figure it out, but it would take me a lot longer) <mark_weaver>bitdiddle: I saw your question about trouble running ./autogen.sh, but you had already left. <civodul>mark_weaver: if you file a bug report, i'll do it eventually (just not right now ;-)) <mark_weaver>bitdiddle: in general, if you get errors like that, it's because you were missing *.m4 files in /usr/share/aclocal while running autoconf/automake. <mark_weaver>bitdiddle: you need the 'gettext' and 'libtool' packages. <mark_weaver>bitdiddle: note that this issue only arises when building from git. when building from a release tarball, ./autogen.sh has already been run before the tarball was made. <ijp>hmm, guild lint seems superfluous to me <mark_weaver>sneek: later tell bitdiddle regarding your problem running ./autogen.sh: install the 'gettext' and 'libtool' packages and rerun ./autogen.sh. <mark_weaver>sneek: later tell bitdiddle in general, if you get errors like that, it's because <mark_weaver> you were missing *.m4 files in /usr/share/aclocal while running <mark_weaver>sneek: later tell bitdiddle in general, if you get errors like that, it's because you were missing *.m4 files in /usr/share/aclocal while running autoconf/automake. note that this issue only arises when building from git. when building from a release tarball, ./autogen.sh has already been run before the tarball was made. <ijp>how do I add additional warnings? <mark_weaver>ijp: will the warnings be generated from C or from scheme? <ijp>well, I want to add some additional sanity checks on my scheme when compiling <ijp>there is %warning-passes in compile-glil.scm <mark_weaver>yeah, if you want to change the default set of warnings, that needs to be done in several places as I recall. it's a bit of a mess IMO. <ijp>okay, those two files look like a start <mark_weaver>(and yes, I need to write another message explaining the issue more clearly) <mark_weaver>ijp: also see %auto-compilation-options in boot-9.scm <mark_weaver>ijp: also, anything that calls "guild compile" has to hard-code the list of warnings, iirc <mark_weaver>ditto for anything that calls 'compile' or 'compile-file' <bitdiddle>mark_weaver: thanks, yea I had both of those installed, which threw me off, what seemed to get it all working finally was moving from automake 1.11 to 1.12 <sneek>Welcome back bitdiddle, you have 3 messages. <sneek>bitdiddle, mark_weaver says: regarding your problem running ./autogen.sh: install the 'gettext' and 'libtool' packages and rerun ./autogen.sh. <sneek>bitdiddle, mark_weaver says: in general, if you get errors like that, it's because <sneek>bitdiddle, mark_weaver says: in general, if you get errors like that, it's because you were missing *.m4 files in /usr/share/aclocal while running autoconf/automake. note that this issue only arises when building from git. when building from a release tarball, ./autogen.sh has already been run before the tarball was made. <bitdiddle>I'm slowing working my way through the autotools madness in the info browser <mark_weaver>bitdiddle: very strange. that is indeed needed now, but I don't see how that would affect the problem you reported. <mark_weaver>bitdiddle: all I can think of is that you didn't rerun automake/autoconf until after you upgraded automake <bitdiddle>was more likely my mucking with gettext, libtool, etc.. <mark_weaver>bitdiddle: basically, those are macros that are expanded into shell code when automake/autoconf is run. if you ever see things like that in the resulting ./configure, that's because the macros weren't available when you ran automake/autoconf <ozzloy>mark_weaver, it is a mixture of free and not free software <ozzloy>mark_weaver, my goal is to make free software replacements for the not-free parts <mark_weaver>bitdiddle: also, I recommend upgrading libgc to 7.2d. although I generally prefer apt-get, in my case I simply built it from source and installed to /usr/local/ <davexunit>mark_weaver: off-topic, but what debian repos do you use? stable, testing, unstable? <mark_weaver>in my laptop I use testing. on my server I use stable <davexunit>mark_weaver: thanks. I think I might switch to debian testing soon. <davexunit>I run testing on my media center pc. I would run stable but I get a more up-to-date xbmc on testing. <davexunit>I'm so used to arch's bleeding edge packages, but I'll give debian testing another shot on my main dev machine. <ozzloy>mark_weaver, the driver station, the robot imager <tupi`>for what it's worth, debian testing has 7.1-9.1 <_1126>Hello! I'm trying to build 2.0.9 on Debian Wheezy, but it fails for me with the following error during "make": libguile-2.0.so.22: undefined symbol: GC_set_all_interior_pointers ... What can I do about that? Does anyone know by chance? <mark_weaver>_1126: It's interesting that it failed. We'll have to look into that. But I can tell you how to fix it anyway. <mark_weaver>_1126: then rerun ./configure in Guile's build directory and continue from there. <_1126>I got that already.. The only thing I didn't do is "make check" ;) <mark_weaver>_1126: did you rerun Guile's ./configure after installing gc-7.2d ? <_1126>mark_weaver: I guess, I did. But to be sure I'll do it again :) <mark_weaver>_1126: I suspect you forgot to rerun ./configure. If it still doesn't work, try wiping the whole build directory and starting over. <mark_weaver>_1126: and please let us know if rerunning ./configure fixed the problem. <_1126>mark_weaver: It did not fix the problem. Same error again. <_1126>I'll wipe and rerun everything. Maybe that helps. I'll let you know. <mark_weaver>_1126: oh, did you remember to run "sudo ldconfig" after installing gc-7.2d? <_1126>mark_weaver: I wasn't aware that I am supposed to do that .. *ouch* <_1126>mark_weaver: I'll do it now. <mark_weaver>_1126: whenever you install libraries from source, you need to do that. <mark_weaver>_1126: and then rerun Guile's configure and try again. (you shouldn't have to wipe) <mark_weaver>also remember to run ldconfig after installing guile too. <_1126>mark_weaver: Good to know, thanks. I'm still new to Debian. <mark_weaver>this is not debian specific. on *any* system you need to do that when installing libraries outside of the package manager. <_1126>You're right, I guess, but I didn't felt the need too, coming Arch with bleeding-edge and AUR and all ;) <_1126>Still learning.. that's great. <tupi`>i need a text file search/replace facility [in guile], any hint ? <mark_weaver>_1126: heh, that's true, with Arch I guess you rarely need to install libraries outside of the package manager. <_1126>mark_weaver: there were some "Missing or errenous"-warnings in pairs.doc, but apart from that it seems to work. Great! <mark_weaver>_1126: yeah, there are still some warnings during the build <mark_weaver>tupi`: granted, they are kind of crufty. It's on my TODO list :) <tupi`>yes, tx, i use them already [in kisê] but i am looking for some code that would already exists doing the dir/file 'hard' work :) <ijp>hmm, I thought I'd covered all the bases, but I'm still getting "warning: unknown warning type ijp-warning" <ijp>I'll leave it for now, but I agree that it isn't very convenient to add new warnings at the moment <_1126>mark_weaver: it worked, thanks! <mark_weaver>tupi`: what's the dir/file hard work? do you want to traverse a directory structure and do a find/replace on every file within? <add^_>Hum, for some reason I can't install geiser through 'M-x package-install' anymore. (emacs version 24.3.1) <add^_>Maybe marmalade isn't used anymore? <mark_weaver>marmalade isn't enabled by default. you have to add it. <add^_>I wonder why it wasn't working until now.. <galex-713>How can I simply work with a drawable surface in guile simply (like with SDL) <taylanub>Did you read my remarks from yesterday ? <ijp>looking at them right now <ijp>I'm not sure I understand <taylanub>Did you get the whole "descriptor type" mechanism ? <taylanub>See the "Simple" type in the current implementation and how it's used to define the numeric types .. <taylanub>Basically *all* non-compound descriptors could be defined as instances of this "simple" type, I think. So the system for creating non-compound types is redundant, since one is sufficient. <ijp>I don't think you need distinct types for each descriptor <ijp>well, you need at least two <taylanub>Compound and non-compound ? I.e. all compound descriptors could be of the same type ? <ijp>but really, they would all answer to one descriptor? predicate <taylanub>Hrm, we can't have a plain "vector" descriptor by the way, it must be the vector of another descriptor .. like in C, you know. (I'm really implementing C's typing system here, I think. :P) <taylanub>Same for union and struct, and all other compound types .. <taylanub>So the "things" like vector, struct, and union can't be of the descriptor type. <ijp>no, I would suggest making them functions, that return a descriptor <ijp>one thing that bothers me about the current implementation, is that you have an awful lot of exported macros for a "procedural" interface <taylanub>Hehe, yes, I turned some things into macros after mark_weaver made me aware that rest-arguments require allocation thus are inefficient .. <taylanub>I'm not sure if any of those macros would be desired to be procedures instead. <ijp>hmph, I've just realised that this is roughly a lens library <ijp>at least, that's how I'm envisioning it <taylanub>"Lens" ?.. Is that what JS calls "views" and all that ? <taylanub>Or "typed arrays" .. Because that's what inspired me. <ijp>a lens is a compbination of a getter, and a setter. That you can compose to create more complicated getters and setters <ijp>hmmph, what the hell was I thinking at line 45 <taylanub>Interesting. Yes, this library could be implemented as lenses, but perhaps some of the more special-purpose features would be lost. <ijp>I was mostly speaking at a conceptual level <taylanub>(Back to the "descriptor-composers as functions" idea ...) <taylanub>Where does the index-dereferencing fall there ?.. Do all descriptors offer an indexed-access function ? What do the "simple" types do with that ? Hrm, just accept zero indices perhaps. <ijp>well, the referencing functions for indexed types (structs, arrays, etc) would need an additional argument <taylanub>So it's just 0 or 1, so back to non-compound or compound. <ijp>hmm, js typed array views don't have this sort of nesting <taylanub>Interesting. I think our lowest common denominator should be C's types by the way. <ijp>as specified, they seem to be directly analogous to the bytevector-*-ref/set! procedures <taylanub>ijp: Eh, I think I'll keep the current strategy of allowing other non-compound types. Think of it like GOOPS .. how often do you actually use meta-classes ? :P <ijp>I've never used metaclasses, but I never use goops either <taylanub>I see a similarity between descriptors/descriptor-types and classes/meta-classes. The use-cases of the latters are limited, but there's no reason not to have them, and to implement the default/standard case in terms of them .. it's a neat thing to do. :P <taylanub>(I'm really too lazy to overhaul the implementation again ..) <taylanub>union {char birthday[9]; int age; float weight;} people = { .age = 14 }; /* C99 feature. Otherwise you can only initialize to the first member. */ <taylanub>Wonder if I should try to implement it .. <ijp>taylanub: well, are you also planning on using these descriptors to create new structures? <taylanub>ijp: `bytestructure' does that, yes: (define desc (make-bytestructure-descriptor `(,bsd:vector 3 ,int8))) (bytestructure desc (255 42 0)) => #vu8(-1 42 0) <taylanub>It's quite stupid currently, I'm not even sure what it accepts but see the "constructor-helper" kinds of procedures; those exist to support this. <taylanub>Well, what it accepts depends on your implementation of the constructor-helper for your compound-type .. <fbs>why does 'add-to-load-path' add stuff twice, is it because I also got geiser running? <taylanub>fbs: See `geiser-guile-init-file' etc. ?.. <taylanub>`geiser-guile-load-init-file-p' is interesting too, just found out about it .. <ijp`>add-to-load-path happens at both compile time, and run time ***ijp` is now known as ijp
<ijp>this is essential for it to work properly when compiling, but less useful if you are at the repl <ijp>it won't (usually) harm you, just slow things down a bit