IRC channel logs


back to list of logs

***KM4MBG is now known as Jack-KM4MBG
<jgart>When using the basic http server module, how do I parse a request body?
<jgart>Hi cwebber, will you continue to develop Spritely Goblins racket implementation in parallel to the guile implementation?
<rlb>mfiano: I don't think there's any enforced mapping, but if you say (use-modules (foo bar)), then unless there's a foo/bar.scm file in your GUILE_LOAD_PATH that has a (define-module (foo bar) ...) in it, guile won't know how to find it. But nothing prevents any given file from defining multiple modules, and if you've already defined the module, then guile won't go looking for it.
<rlb>(already defined, perhaps programmatically via the functions in boot-9.scm, etc.)
<rlb>(or whatever)
***Jack-KM4MBG is now known as jackhill
<cwebber>jgart: yes
<cwebber>part of the reason I'm doing both is to demonstrate compatibility across two runtimes
<daviid>vijaymarupudi: i found what causes the problem, will push a solution in an hour or so ... it is 'funny to note that you both 'hit the exact same g-golf few lines of code :), though both reported problems need a different fix ...
<vijaymarupudi>I'm glad you didn't have to hunt down two distant bugs :)
<vijaymarupudi>Thank you very much!
<daviid>vijaymarupudi: the fix triggered a(nother) gtk-tree-path related bug, and the other problem reported by clone needs more thinking, so it will take more time then initially said here earlier, probably a day or two, sorry, but will ping you both when something to test is ready ...
<mfiano>rlb: Ok. What is the recommended solution to automatically fetching third-party scheme libraries to your load path, perhaps some even shared between multiple local projects?
<mfiano>I am really liking Guile coming from CL as my first Scheme, but I often work with very large projects in CL, so just trying to get an idea of a proper workflow for managing/loading large projects and their transitive dependencies
<clone>daviid: thanks for working on it!
<clone>When I was looking for the bug I thought a little about solving it. I'm not very experienced so I don't know how good of an idea it is.
<clone>but I thought about making a <gc-safe-pointer> class that has slots for a pointer and a bytevector, and making all of the pointer functions in (system foreign) generic over pointers and gc-safe-pointers. you'd really need to make the generic pointer functions were included everywhere though.
<vijaymarupudi>daviid: Sounds good, thanks for taking a look at it!
<vijaymarupudi>In the past, I've faced a problem with Guile FFI where I'd send a pointer to a closure to C, and then the closure would get GCed I think and I'd get a segfault when I called it later. I had expected that libgc would take care of it, but it did not. You can't scm_gc_protect from Scheme, so there was no way around it without using a C extension.
<vijaymarupudi>Unless I used an internal hash-table combined with a mutex, but that seemed like it was duplicating scm_gc_protect
<tohoyn>I'm making a call tree of a large program with statprof. Now I have procedure A calling procedure B once but I have two nodes for this call in the call tree. Why is this so?
<mfiano>Does anyone use geiser here? I'm running into an issue that completely prevents me from learning Guile :(
<mfiano>With geiser's guile repl and one of my guile module source buffers open, attempting to evaluate anything in my source buffer with C-c C-c, or using company to complete any symbols results in Emacs hanging forever until I cancel the hung operation with C-g
<mfiano>Googling a bit seems to indicate this is an issue with the repl package changing or something, and a proper regexp needs to be added to guile-geiser--prompt-regexp. I tried a few things and I just can't get any work done
<tohoyn>mfiano: I have set guile readline not active when using guile from emacs
<mfiano>How do I do that? Sorry I'm just trying to get set up to learn Scheme
<leoprikler>vijaymarupudi: there are guardians, which work sort of like gc_protect
<tohoyn>mfiano: do you activate guile readline somewhere?
<mfiano>in my .guile
<tohoyn>mfiano: then pass option -q to the guile command in emacs
<tohoyn>mfiano: it suppresses loading the init file
<mfiano>What if I want to evaluate the rest of that file?
<leoprikler>well, you could jump into that buffer and evaluate it on your own
<tohoyn>mfiano: use the -l option in guile
<tohoyn>mfiano: and write a separate guile init file for emacs
<leoprikler>mfiano: regarding the 1:1 file mapping, no, they aren't necessarily bound to files (see the (guile) module for example), but when they are not, you need to do some special things to ensure those non-file modules exist before you want to access them
<leoprikler>that's how Guile-GI works internally
<mfiano>Not seeing how to supply arguments to the guile binary. it is erroring when applying them to the geiser-guile-binary string. but i suppose i could just set geiser-guile-init-file
<mfiano>That seemed to do the trick! and wow, completion and everything is much snappier now too
<mfiano>Thanks all
<tohoyn>I use the following code in statprof to track callers to a Scheme procedure:
<tohoyn>could someone check it?
<tohoyn>The purpose of the code is to measure the time used in procedure check-if-subtype? for each caller
<tohoyn>I.e. I want to know where the most time consuming calls are made
<tohoyn>are there any statprof gurus here?
***rt is now known as robin
<tohoyn>it looks like same procedure call may have different procedure addresses
<manumanumanu>tohoyn: I do not understand what is going on there, but are you relying on procedure equality?
<tohoyn>no, I'm just profiling the procedure calls
<lloda>wingo: i really want to remove the array handling in vector-copy / vector->list / vector-move-left! / vector-move-right!. It is undocumented and vector-fill! / vector-ref / vector-set! / vector? are already type strict, so i'm 99% sure no one will miss the old behavior
<lloda>plus the move functions are bugged, they accept nonzero lower bounds and just ignore them
<wingo>lloda: do any other vector- functions operate on arrays?
<lloda>those I listed are the only ones
<manumanumanu>lloda: what exactly is going on with the vector patches. Just cleanup? I am curious :)
<lloda>i want to layer the array impl on top of the various vectors so that it can be replaced eventually
<lloda>arrays depend on the various vector types but the vector types shouldn't depend on arrays
<lloda>that is already true for all of the vector types, the srfi-4 types, strings, the bitvectors
<lloda>I could do something like this;a=blob;f=libguile/bitvectors.c;h=3a279e40111253380a59b22920aee48263e00de5;hb=HEAD#l456
<lloda>that looks like the way to go
<vijaymarupudi>leoprikler: thanks for the suggestion on guardians, I was not aware of them. They wouldn't have solved the issue I described because I needed precise control on when to free certain closures that I retrieved from C, however I can think of many other uses for guardians.
<dsmith-work>UGT Greetings, Guilers
<manumanumanu>good day!
<pizzapal>hi, is it expected that using hash-clear! on a srfi-69 hash table would produce a "wrong type argument" error?
<manumanumanu>srfi-69 hash tables are not the same as the built-in ones
<pizzapal>ah, i see
<manumanumanu>you will have to roll your own using hash-table-delete! from srfi-69
<pizzapal>do you know an efficient way to clear out a srfi-69 hash table?
<pizzapal>so just iterate over it?
<manumanumanu>(hash-table-walk hash-table (lambda (k v) (hash-table-delete! hash-table k))
<manumanumanu>but a named let over (hash-table-keys hash-table) will probably avoud the procedure call overhead and will be ever so slightly faster
<pizzapal>oh really?
<manumanumanu>the difference isn't huge
<manumanumanu>and you won't notice it unless you have several thousand keys
<pizzapal>it is usually only a few dozen keys, but i have to wipe it very frequently
<pizzapal>so that seems to be my bottleneck
<manumanumanu>did you benchmark the different hash-tables? I believe srfi-69 is built upon guiles built-in hashtables
<pizzapal>yeah, i am using statprof to do a comparison at the moment
<pizzapal>i was just using set! with make-hash-table to clear it out and that was not fast haha
<manumanumanu>set! is almost always a code smell.
<mfiano>Can someone tell a newbie why I don't have access to the program-arities procedure in (system vm program) ?
<manumanumanu>guile implicitly boxes everything touched by set!, which will make it slower
<manumanumanu>chez does the same
<manumanumanu>mfiano: it seems to not exist anymore...
<mfiano>Hmm, it's in the documentation
<manumanumanu>I know. I'm trying to figure it out now
<manumanumanu>oh, even more weird
<manumanumanu>try (program-arity + 0) and it will complain there is no program-arities
<mfiano>sounds like a bug
<mfiano>can confirm
<manumanumanu>It seems like program-argument-alist might be what you want
<mfiano>manumanumanu: I'm following along Software Design for Flexibility, Sussman's new book, and I need MIT Scheme's procedure-arity-min and procedure-arity-max
<mfiano>and procedure-arity it seems
<manumanumanu>mfiano: you can implement that from program-arities-alist without much fuzz unless you want to define a nice heuristics for keyword args
<mfiano>Fair enough, thanks. Hopefully Andy and the team can update the docs for other confused newbies :)
<rlb>mfiano: not sure what's "common" wrt external dependencies. Most of my uses of guile for a while have been fairly self-contained, i.e. as an extension, or as the foundation underneath lokke, or for things that can mostly get-by with what's built-in, and/or in debian. That said, I think there are probably a number of options.
<rlb>mfiano: ...and if you're needs are simple enough, just arranging for the deps you need to be in the load-path might suffice, whether via explicit (build-system) clones, or submodules, or...
<dsmith-work>mfiano: You were asking the other day about module <-> file relationships?
<dsmith-work>mfiano: Generally, as rlb said, though it is possible to use load or include withing a module file.
<dsmith-work>But that's not usual.
<mfiano>I see. Thanks everyone
<mfiano>I'm a long time Common Lisper and trying to unlearn lots
<dsmith-work>mfiano: Cool. I'll be having some questions or you. ;^}