<davexunit>what's the best way to deal with date math involving time zones in guile? <ijp>my initial response was srfi 19, but I don't know how well/if that handles timezones <ijp>I see a few mentions of a tz offset under date, but it seems to be in seconds <ijp>it's the final field in a date record <davexunit>a shared library "foo" depends on a function defined in shared library "bar" <davexunit>using 'dynamic-link' on both libraries apparently isn't enough for functions in foo to use functions in bar. <davexunit>am I doing something wrong, or did someone build the shared libraries incorrectly? <davexunit>looks like a linking error with the library I'm using <davexunit>I'm not sure how to link in the right library ***michel_mno_afk is now known as michel_mno
***michel_mno is now known as michel_mno_afk
<davexunit>please_help: libfoo is built without linking to libbar, but references symbols from it. <davexunit>(dynamic-link "libfoo") (dynamic-link "libbar") isn't enough to make functions from libfoo work. <davexunit>the program crashes with messages like "undefined symbol: xc_die_info" <davexunit>if this were a C program, I would just pass -lfoo -lbar to gcc and things would work. <paroneayea>so fluids/params defined outside a delimited continuation, but then set to a value within it, don't retain that value <paroneayea>and are dependent on whatever happens externally too <davexunit>paroneayea: they retain the value throughout the dynamic extent of the form that they are "parameterized" in <paroneayea>I thought that would be true but my test above seems lik it isn't? <davexunit>in Sly, I use a parameter called 'current-agenda', and the value is retained in my coroutines and such <paroneayea>davexunit: that's what I want, but I don't seem to be getting that behavior. Could you check whta I'm doing wrong? <paroneayea>mark_weaver: davexunit: perfect, I now have the behavior I want <paroneayea>I really wish python had similar fluids/parameters! <paroneayea>that would make writing asyncio stuff much easier <davexunit>they have their weaknesses, but they are very useful for certain things. <davexunit>parameters and lazy evaluation don't play nicely. <ijp>parameters in python would be pretty easy to do with the "with" statement <ijp>it basically boils down to a Box class <ijp>well, except it probably wouldn't interact with treads correctly <ijp>hmm, no, this would fail because with binds a new variable lexically <paroneayea>ijp: it wouldn't work with asyncio type coroutines stuff either <ijp>you can probably still fake it, by making parameter objects just mutate a shared "obarray" <ijp>which would ideally need to be weak <paroneayea>ijp: I have no idea how that would work, but will trust your judgement :) <mark_weaver>in guile, fluids are implemented as follows (slightly simplified): every thread has a thread-local array of fluid values. every fluid is assigned an integer, which is the index into those arrays. <mark_weaver>with-fluids and parameterize save the current values of the fluids being modified, and then modify them. <mark_weaver>and they arrange that if a non-local exit happens, the old values will be restored <mark_weaver>since scheme allows you to "re-enter" after a non-local exit, more is needed <mark_weaver>when the non-local exit happens though a 'with-fluids', the current values of the fluids are *swapped* with the saved values. <mark_weaver>because fluids+parameters can simply be modified in place, when the non-local exit happens, the fluids might not have the same values assigned to them by the 'with-fluids' <mark_weaver>so the current inner values are saved when the non-local exit happens, and then restored (by swapping again) if the 'with-fluids' is re-entered. <mark_weaver>although python doesn't have first-class continuations, it does have generators which are co-implementable with delimited continuations, iirc. <mark_weaver>so it may be that a proper implementation of fluids/parameters in python needs to take generators into account, dunno. <ijp>abusing __call__ but whatever <paroneayea>does this handle if something happens outside a coroutine? <paroneayea>eg, if a coroutine which binds the parameter suspends, the parameter gets changed, but then the coroutine wakes up again <paroneayea>will it keep the external parameter value or its internal one? <paroneayea>ijp: and no worries about abusing __call__, that's the python way ;) <ijp>I really doubt this works with coroutines <paroneayea>I want a way to specify the current language to gettext for instance <mark_weaver>ijp: could the approach in that sketch be used to handle exceptions, or would a different approach be needed? <paroneayea>and obviously globals fail in an asyncio environment <ijp>mark_weaver: maybe, but AFAIK with is just a wrapper on try/finally, so you'd really need the exceptions infrastructure to begin with *davexunit messes around with guile's ffi and fpgatools <djcb>i'd like to implement a parser for a little query language in guile <ijp>and how can we help you? <djcb>something like (define my-query '(or (contains foo "bar") (not (contains cuux "blurb")))) <djcb>and turn that into an sql-query <djcb>seems like a not-too-atypical thing to do, so perhaps there are some examples somewhere? <davexunit>djcb: I've been down this road and didn't get very far <davexunit>my first question, which SQL? each database has a similar, but different query language. <ijp>you can probably abuse the sxslt stuff to do it, but I may be the only person who uses that <djcb>for now, it'll be sqlite <davexunit>you need to somehow encode all of the possible syntax <davexunit>some keywords use prefix notation, some postfix, some infix <davexunit>that fact destroyed my dreams of having something like sxml for SQL <djcb>i think i'll just restrict myself to prefix for now <djcb>mapping a sexp into a WHERE clause should be quite portable, except for some extensions, like sqlite's REGEXP <djcb>ijp: oh, that looks interesting <ijp>.oO(I should go through my gists and remove all the nonhilarious entries) <davexunit>if you can go sql -> sexp, it would be nice to go sexp -> sql <davexunit>taylanub: every database has its own quirks and features <davexunit>so you can't expect to have a general purpose reader/writer for SQL, unfortunately <djcb>davexunit: it's a bit less general than that <djcb>i'd like to take some s-exp, parse it and turn it into some sql <davexunit>so it's not a sql parser, but a sexp->sql writer. <davexunit>so yeah, you'll have to know how to write out each expression <davexunit>(or (< id 10) (> id 100)) becomes "id < 10 OR id > 100" <djcb>that seems like not too hard for a non-pedestrian schemer like myself :-) <djcb>so, it'll be an interesting excercise <davexunit>djcb: I'm very interested in using such a thing if you come up with a good implementation <davexunit>call it guile-ssql and release it when you're done ;) <ijp>pre-post-order aside, I don't suspect there is much general "parser generators" for sexps, most of that work is focussed on strings/ports -> sexp <ijp>djcb: I think nalaginrut has something similar to this as part of artanis, but I don't know how far he got <davexunit>I'd like a parser combinator library for Guile <ijp>davexunit: riastradh's one (parscheme) is on guildhall <ijp>I started writing one based on iteratees, but iteratees aren't fashionable anyway... <davexunit>I want to try writing a markdown parser with it <ijp>I had used it once, but it was way overkill for my use case <davexunit>ijp: thanks for knowing about all the cool libs <zarac>so, anyway.. i'm new to guile. just testing it out.. following info guile.. <zarac>How come.. when i run `export HOSTNAME=foobar ./simple-guile` (my-hostname) prints 'foobar', but when i run `export HOSTNAME=foobar ./simple-guile simple-guile.guile` the expected 'foobar' is not displayed. (simple-guile.guile is just (my-hostname)). <zarac>that took a while to type.. ; ) <mark_weaver>you aren't doing anything to print the result of (my-hostname) <zarac>i have to (display (my-hostname)) ? <mark_weaver>the way you wrote that script, the result is being ignored <zarac>yeah, i fugred it did. and i was wondering what it was, thanks again. ; ) <zarac>some compiled / temporary files are stored somewhere (..?) where? <mark_weaver>btw, to specify environment variables while running a single command, you don't need to write 'export' there. <zarac>the first time i run a guile script it displays some compiling information.. but not the second time it's run.. <zarac>i actually didn't write export.. not sure why i did when i asked ; ) <mark_weaver>it should have told you where they were being stored when it did the compiles, no? <zarac>geez, can't belive i missed that : ) <zarac>actually read it.. guess i'm dyslectic <zarac>don't like opinion questions? : ) <mark_weaver>I'm overloaded, no time to try to answer such questions, sorry <zarac>hehe, np. thanks again for your help. much appreciated! <mark_weaver>it's my programming environment of choice, anyway... <zarac>: ) after just being introduced to it, i can understand. <zarac>what editor do you use/recommend? <zarac>i mean for interactive programming.. <daviid``>oftopic quiz: is there a gnu make way for: make uninstall --purge [or something like that] <daviid``>thta wuld lete the directories install created ? <davexunit>it is possible to pass a port to a C function via the FFI? <mark_weaver>daviid``: but I can tell you how to delete all directories in a tree that contain no non-directories <ArneBab_>daviid``: I think you’d have to add a purge command <davexunit>I see that I can get a port's file descriptor. Do I just create a foreign pointer containing it? <mark_weaver>davexunit: do you want the C function to receive the file descriptor or the SCM port? <davexunit>it's an existing function in a shared library <civodul>there's 'fileno' and 'port->fdes' but read the manual carefully *civodul always forgets which one does what <mark_weaver>davexunit: well, I guess you should use either port->fdes or dup->fdes and then it's just an integer, to pass like any other integer <mark_weaver>that's a bit squirrelly, to have two different buffered I/O implementations talking to the same underlying FD. <daviid``>mark_weaver: since there is no such purge target [per default], i'd like to write 1 configure.ac/Makefile.am, if possible <mark_weaver>I guess maybe it could be managed by making sure to flush before going back and forth, but there may be other issues when you close them. <mark_weaver>davexunit: the C library has 'fdopen' that allocates a FILE* based on an already-open file descriptor. <davexunit>so it would be best to use that new file descriptor for the foreign call? <daviid``>like: cd /your/prefix; find . -name yourproject -exec rm -rf {} \\; will talk to autoconf, someone prob has done this before... tx <mark_weaver>I don't remember off-hand whether closing a FILE created with 'fdopen' will call 'close' on the underlying FD. <mark_weaver>I also don't remember off-hand whether duplicating an FD leaves them each with an independent file position. <civodul>davexunit: if you want to use exclusively the FFI, you could try to make a custom binary port that uses fread, fwrite, & co. <mark_weaver>civodul: but if the C function he wants to call expects a FILE*, how could that be connected to a custom binary port? I suppose it could be done with a pipe. <mark_weaver>davexunit: my first guess is that you should dup->fdes and then call C 'fdopen' to create a FILE* and then pass that to the function. <mark_weaver>and then you need to call 'fclose' on that FILE* at some point. <mark_weaver>also, you'll probably also want to 'force-output' before calling the C function, to make sure that guile has flushed pending output to the port. <mark_weaver>and then whatever the C function wrote will need to be flushed before Guile writes anything more to the port. <mark_weaver>or use 'fflush' if you want to flush before closing. <mark_weaver>(before closing the FILE* and duplicated FD... the original FD will stay open after the 'fclose') <davexunit>I can't seem to keep the port open after closing it... <davexunit>there's a 'close' procedure, but not 'fclose' <mark_weaver>davexunit: out of curiosity, what are you working on? <davexunit>mark_weaver: I'm just messing around at this point, but I'm playing around with the fpgatools libraries with the FFI <mark_weaver>will guile actually be writing anything to this port? <davexunit>I'd like to create a wrapper that accepts any output port <davexunit>hmm, maybe I should just write to an output string and return that <mark_weaver>the issue with pipes is that if you try to write too much to them, it will block until the reading happens. so the writer and reader really need to be in different threads (or processes) <davexunit>mark_weaver: and then read the temp file and write it to a port? <mark_weaver>but the temporary file method is fine, even if it seems a bit clunky <mark_weaver>see section 12.21 of the libc manual (Other Kinds of Streams) <mark_weaver>I suppose we could use those to convert an arbitrary scheme port to a FILE*, but only on glibc. *mark_weaver never knew about 'fopencookie' before. *mark_weaver tries writing port->FILE* <civodul>yeah i think the trick is to use fopencookie to encapsulate a port, or a custom binary port to encapsulate a FILE* <mark_weaver>fopencookie to implement port->FILE*, and a cbp to implement FILE*->port <daviid``>it appears we don't (nobody does?) install LICENSE, COPYING, NEWS... in $pkgdatadir, is this right? it seems once 'make install' is done, if you delete $scrdir, then none of these files are 'visible' to the user <mark_weaver>^^ convert arbitrary scheme ports into FILE* (for glibc only) <davexunit>I'm eager to see if the floorplan generated from my guile-fpga program is exactly the one generated by one of the examples written in pure C. <mark_weaver>davexunit: so, with that, there's no need to flush the scheme port before calling into C. however, you *will* need to call 'fflush' after calling the C function. <davexunit>alright, I can do all of that from the wrapper procedure <mark_weaver>davexunit: the "modes" argument should be "r" or "w" for single-direction ports. <mark_weaver>or "r+" for bidirectional. it corresponds to the OPENTYPE argument of 'fopen'. <mark_weaver>also, I'm not sure if the existence of that FILE* will protect the associated port from the garbage collector.