IRC channel logs

2013-04-12.log

back to list of logs

<taylanub>ijp`: I re-wrote big parts of procedural.scm.
<taylanub>( https://github.com/taylanub/scheme-bytestructures/ is the topic, for interested third-parties.)
<taylanub>Oh, README is badly outdated now ..
<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.
<taylanub>Now SLEEP!
***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>hmm, 2011
<ijp>okay, so that's language/lua/compile-tree-il.scm fixed, I think
<ijp>hmm, not quite
<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>errors
<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
<ijp>well, today
<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?
<nalaginrut>morning guilers~
<b4283>hiya
<nalaginrut>heya
<dsmith> http://freecode.com/projects/guile/releases/353827
<nalaginrut>dsmith: nice~
<wingo>moin
<lloda>hello wingo
<lloda>this array stuff is a total mess
<lloda>i'm tearing my hair out
<wingo>heh
<wingo>i have done that too
<wingo>multiple days of "wtf is going on here"
<lloda>:-(
<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>right.
<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?
<DerGuteMoritz>heya guilers
<DerGuteMoritz>happy friday!
<davexunit>happy friday!
<wingo>lloda: yes that's enough
<lloda>then can we get rid of all the release calls (!)
<wingo>yes and no :)
<wingo>currently as you say the release calls do nothing
<DerGuteMoritz>... and lloda was enlightened
<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.
<wingo>spooky!
<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>most notably, several of the popen tests hang
<wingo>exciting
<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)
<civodul>hey, happy Friday!
<mark_weaver>hi civodul!
<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.
<wingo>humm!
<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".
<dsmith>mark_weaver, Wow. very curious
<mark_weaver>ha! a full rebuild of the C code fixed the problems.
<dsmith>Heh.
<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?
<DerGuteMoritz>ah so finalizers hairy in guile, too :-)
<DerGuteMoritz>+are
<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.
<DerGuteMoritz>ah then all is well :-)
<DerGuteMoritz>debugging finalizer related stuff is annoying indeed
<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)
<mark_weaver>s/outside/out outside/
<mark_weaver>s/outside/one outside/ (ugh)
<civodul>good question
<civodul>i thought one is fPIC and not the other
<civodul>not sure
<mark_weaver>yeah, they're not the same length
<mark_weaver>I guess it's a libtool thing
<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>(and reduce build time)
<mark_weaver>okay, thanks!
*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)
<ijp>afternoon
<dsmith-work>Happy Friday, Guilers!!
<ijp>yes, happy friday
<mark_weaver>hi ijp, dsmith-work!
<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>interesting
<wingo>it could be something related to --enable-posix / --enable-networking
<mark_weaver>makes sense.
<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)
<mark_weaver>I'll file a bug report.
<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?
<wingo>sounds sensible to me
<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.
<mark_weaver>bitdiddle: you need some additional packages.
<civodul>mark_weaver: if you file a bug report, i'll do it eventually (just not right now ;-))
<mark_weaver>civodul: great, thanks! (no rush)
<mark_weaver>I've already filed the bug report.
<civodul>good
<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.
<sneek>Got it.
<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> autoconf/automake.
<sneek>Got it.
<mark_weaver>damn
<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.
<sneek>Will do.
<ijp>how do I add additional warnings?
<mark_weaver>ijp: will the warnings be generated from C or from scheme?
<mark_weaver>nvm, it doesn't matter, sorry.
<ijp>well, I want to add some additional sanity checks on my scheme when compiling
<mark_weaver>ijp: see %warning-types in system/base/message.scm
<mark_weaver>ijp: and 'warning' in the same file
<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>this reminds me of http://lists.gnu.org/archive/html/guile-devel/2012-02/msg00080.html
<mark_weaver>but that's another story :)
<mark_weaver>(and yes, I need to write another message explaining the issue more clearly)
<ijp>yeah, it is related
<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.
<bitdiddle>probably didn't
<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
<bitdiddle>I've been trying to stick to apt-get
<bitdiddle>good to know
<ozzloy>mark_weaver, it is a mixture of free and not free software
<mark_weaver>ozzloy: pity :-(
<ozzloy>mark_weaver, my goal is to make free software replacements for the not-free parts
<mark_weaver>ozzloy: sounds good :)
<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/
<mark_weaver> http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/gc-7.2d.tar.gz
<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
<mark_weaver>ozzloy: what are the non-free parts?
<davexunit>mark_weaver: thanks. I think I might switch to debian testing soon.
<mark_weaver>testing has been very solid for me.
<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
<mark_weaver>tupi`: I know. Very sad :-(
<_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: Get http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/gc-7.2d.tar.gz and do the standard "./configure && make && make check && sudo make install"
<mark_weaver>_1126: (it will install into /usr/local)
<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: hmm. okay. please let us know how it goes.
<mark_weaver>_1126: oh, did you remember to run "sudo ldconfig" after installing gc-7.2d?
<mark_weaver>_1126: if not, I suspect that's the problem.
<_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.
<mark_weaver>well, any GNU/Linux system anyway.
<_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`: Guile includes regexp functions.
<mark_weaver>tupi`: granted, they are kind of crufty. It's on my TODO list :)
<mark_weaver>I have to go offline for a while. ttyl!
<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!
<dsmith-work>sneek: libgc is http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/gc-7.2d.tar.gz
<sneek>So noted.
<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?
<mark_weaver>dsmith-work: good idea :)
<dsmith-work>mark_weaver: That's what it's there for.
<tupi`>mark_weaver: bb soon
<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^_>Uh, now it works. Strange.
<add^_>mark_weaver: yeah
<add^_>I wonder why it wasn't working until now..
<add^_>Whatever :-)
<davexunit>marmalade + melpa = awesomeness
<galex-713>How can I simply work with a drawable surface in guile simply (like with SDL)
<mark_weaver>galex-713: take a look at guile-cairo
<mark_weaver>galex-713: there's also guile-sdl if you prefer
<mark_weaver> http://www.gnu.org/software/guile-sdl/ http://www.nongnu.org/guile-cairo/
<galex-713>cool :) thx
<mark_weaver>galex-713: happy hacking!
<galex-713>:) thx again
<taylanub>ijp: Ping.
<ijp>syn ack
<taylanub>Ack.
<ijp>pong
<ijp>or something
<taylanub>LOL
<taylanub>Did you read my remarks from yesterday ?
<ijp>looking at them right now
<taylanub>OK
<ijp>I'm not sure I understand
<taylanub>Which part(s) ?
<ijp>the examples
<taylanub>Did you get the whole "descriptor type" mechanism ?
<ijp>I think so
<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>oh right
<ijp>I don't think you need distinct types for each descriptor
<taylanub>I think compound ones need them ..
<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 ..
<ijp>well right
<taylanub>So the "things" like vector, struct, and union can't be of the descriptor type.
<taylanub>More like, descriptor-composer.
<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> https://github.com/ijp/ijputils/blob/master/lens.sls
<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>Ah OK.
<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>Multiple-index descriptors, yes/no ?
<taylanub>I say no. :P
<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>Indeed the main use-case will be FFI ..
<ijp>only, better for js
<ijp>(syntactically)
<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>BTW TIL of "designated initializers."
<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
<fbs>ah
<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