IRC channel logs


back to list of logs

<paroneayea>I wonder if is true if that also means that some of my intentional indirection-for-live-hacking might not work :)
<fhmgufs>Is it right that you need to use (set! list (delete 'item list)) instead of (delete! 'item list) to be able to destructively delete the first list element?
<janneke`>ACTION wonders what `destructively delete' really means
<fhmgufs>I thought that's the right term for how these expressions behave.
<fhmgufs>The docs say:
<fhmgufs>"Like other destructive list functions, these functions cannot modify the binding of lst, and so cannot be used to delete the first element of lst destructively."
<janneke`>yeah, I read that
<fhmgufs>concerning delete!
<janneke`>i was wondering if you needed a GOOPS destructor or whatnot
<janneke`>it seems, though, that delete! is an utterly useless function
<janneke`>scheme@(guile-user)> (define lst '(a b c))
<janneke`>scheme@(guile-user)> (delete! 'a lst)
<janneke`>$3 = (b c)
<janneke`>scheme@(guile-user)> lst
<janneke`>$4 = (a b c)
<janneke`>I don't understand why it hasn't been dropped
<janneke`>or at least raise an excption when ELT is CAR
<fhmgufs>But using set! it works fine. So I'll use that instead.
<fhmgufs>Why isn't delete! implemented as (set! list (delete ... ?
<df_>it's a function, it can't see the variable binding, just the data
<df_>it would need to be a macro to work like that
<amz3>Good Morning #guile!
<wingo>paroneayea: re: indirection and live-hacking: guile will not inline top-level definitions. that's the usual way to preserve live-hackability.
<amz3>so, chez scheme is very fast
<amz3>does anyone has a small snippet telling how to http-get something over 'https', please?
<nalaginrut>the similar implementation will be appear in Artanis-0.2+
<amz3>good!!! thanks nalaginrut!
<amz3>you rock nalaginrut
<amz3>my script works now both in http and https
<amz3>FWIW here's a https-get module, for your convenience (it requires guile-gnutls)
<amz3>here is small snippet to make a list unique:
<amz3>to remove duplicates... wait...
<kristofer>amz3, I always use the guix download example
<amz3>kristofer: I prefer https-get, easier to read
<amz3>yeah! I can now index and search stuff! it lakes a few bells but I'm happy of the result so far
<paroneayea>wingo: ah, great to know!
<Bobbejaantje>Is there any safe way to fork-exec from a thread obtaining the pid of the child?
<mark_weaver>amz3, wingo: exporting 'open-process' from (ice-9 popen) sounds good to me!
<mark_weaver>Bobbejaantje: 'open-process' is what you need
<mark_weaver>it's currently private to (ice-9 popen)
<mark_weaver>for now, you can get it this way: (@@ (ice-9 popen) open-process)
<mark_weaver>you could do this: (define open-process (@@ (ice-9 popen) open-process))
<Bobbejaantje>mark_weaver, ahh.
<Bobbejaantje>And that basically fork-execs in a safe way from a thread and returns the pid?
<mark_weaver>see 'scm_open_process' in posix.c
<Bobbejaantje>Yeah, I found it, it returns three values it seems
<mark_weaver>bah, there's a problem with this API
<mark_weaver>it doesn't allow passing a different argv[0] than the program
<mark_weaver>it takes three arguments: the mode (string), the program to exec (string), and the arguments (string)
<mark_weaver>but the arguments passed in is not the argv. it automatically prepends the program name
<mark_weaver>wingo: ^^
<mark_weaver>well, it's okay, this was never meant to be a public API anyway
<mark_weaver>I think the public API should be more general, allowing arbitrary file descriptors to be passed to the child
<mark_weaver>not just 0 and 1
<mark_weaver>this requires more thought
<fhmgufs>There's no concept like pointers or references in Guile, right?
<davexunit>fhmgufs: right
<fhmgufs>vector-ref just returns the value then?
<fhmgufs>Ok, thanks.
<mark_weaver>semantically, scheme variables are bound to /locations/ in the store
<mark_weaver>and a location is just another word or a pointer or reference.
<fhmgufs>What I would like to have is an variable which is at the same time member of a vector and if I change one, the other one is changed, too.
<fhmgufs>This isn't very functional, I know.
<mark_weaver>no, we can't do that.
<mark_weaver>we do not expose references to vector elements
<davexunit>you'd need some sort of a box. so that rather than mutating the vector element, you mutate what's inside the box.
<mark_weaver>fhmgufs: however, guile allows you to define /identifier syntax/ which can essentially simulate variables at the syntactic level
<jmd>Why might SCM_SMOB_DATA return 0x0 ?
<mark_weaver>so you could have an identifier that expands to a /procedure with setter/ that allows reading or writing to that vector element
<fhmgufs>mark_weaver: Ok, cool, where can I find that in the manual?
<mark_weaver>fhmgufs: section 6.9.8 (procedures with setters) and 6.10.6 (identifier macros)
<fhmgufs>Ok, thanks for your help.
<mark_weaver>fhmgufs: the other thing you could do is have a vector of boxes
<mark_weaver>for the boxes themselves, you could use either SRFI-111 or Guile's first-class variable objects, which are used to implement Guile's top-level module variables
<fhmgufs>Sounds simpler, but I'm not sure what to do. I'll try around what fits better.
<Bobbejaantje>Is there any way to get exceptions inside srfi 18 threads to just bubble to the top level and immediately crash the entire program when unhandled lie unthreaded exceptions do?
<amz3>Bobbejaantje: can you re-phrase your question?
<Bobbejaantje>amz3, certianly.
<Bobbejaantje>When an excption is signalled inside an srfi 18 thread, essentially nothing happens if the process is multithreaded, the thread just seems to behave as if it goes asleep indefinitely.
<Bobbejaantje>Which includes things like wrong applications of arguments so it makes debugging a nightmare.
<Bobbejaantje>Well, basically unhandled exceptions don't show, and I'm not sure how to handle them, I tried to just install a handler and print the esception to the stdout but that doesn't seem to do anything
<wingo>golfed my peek-char-in-scheme loop down to 1e7 peeks/second; the c implementation is more like 2.8e7 peeks/second
<daviid>wingo: that is already prety good!
<ozzloy>for skribilo, is there a way to suppress the number next to the title of a chapter?
<ozzloy>damnit, right after i ask i find it
<ozzloy>is there a way to make chapter default that way? so i don't have to keep doing :number #f ?