IRC channel logs


back to list of logs

<galex-713>Hi, I’ve too cpu but using future it seems guile only accept to create on thread a time (while it works using make-thread): what’s wrong?
<ijp>galex-713: going back to ,bs for a second. Did you have a particular issue that I could have helped with? because it does work a lot of the time
<ijp>and failing that, you can work around it by making a top level function (break) that does nothing, and setting a breakpoint on that
<galex-713>ijp: oh, not stupid, even if that sounds a lot like the good’ol lot of printfs all around the code to debug it…
<galex-713>ijp: I don’t need it anymore (solved the problem, was a let inside a do instead of a do inside the let, so a variable got reinitialized at each iteration), was in the case I would need it in the future
<galex-713>But I’d liked if it worked :( have a guile debugger sounded like cool
<daviid>galex-713: look for par-map and friends in the manual
<ijp>galex-713: the debugger does work, it's just I know ,bs sometimes fails mysteriuosly
<galex-713>daviid: don’t say why future use only one thread while I’ve two CPUs
<galex-713>daviid: although I looked that, it’s implemented in terms of futures
<daviid>galex-713: galex-713 you have a pool of procedures to have control over exactly what you want, just read the fine manual: par-map, par-for-each, n-par-map ... (current-processor-count)
<ijp>guile also spawns a thread for handling finalisation, so that might factor into it if you are only seeing n-1 future threads for n processors
<galex-713>daviid: in facts it returns 2, but I already knew that
<galex-713>ijp: what do you mean by finalisation? and is that thread used all the time to justify to “disable” multithreading on dualcore computers when using high-level multithreading within guile?
<ijp>(define %worker-count (if (provided? 'threads) (- (current-processor-count) 1) 0))
<ijp>so what I said was a red herring, but guile is still only going to create n-1 workers
<ijp>because that's what the code I just posted says
<galex-713>No I don’t mean “why by code” but “why that this implemented this way”?
<galex-713>although, isn’t thread number meant to be proc-number+1 in order to handle async I/O?
<galex-713>or stuff like that
<ijp>galex-713: well, with n processors you can have n threads running. I presume this choice was made so that you always have the main thread running
<ijp>but I'm not the person to ask, I'm just making guesses and half remembering things
<galex-713>But it’s not I can’t create two thread, I can’t even create one
<galex-713>Currently I’m making one thread for making computation to calculate prime-numbers, and another to refresh the sdl display
<ijp>and those are worker threads, which take futures off the queue. it isn't one thread per future
<galex-713>yeah I know that thing
<galex-713>that futures pills on the threads queue
<galex-713>ijp: anyway, what did you meant by finalization and is it used all the program life along?
<ijp>galex-713: some objects need an action to be performed on them when they are garbage collected, e.g. closing file ports
<ijp>these get handled in a special thread to a particular issue
<ijp>galex-713: this probably doesn't matter for you anyway, since I this appears to be a 2.2 series related change
<galex-713>oh yeah of course
<galex-713>gc needs a thread
<galex-713>ijp: I’m on 2.0
<ijp>right, it doesn't matter
<galex-713>Anyway here I realized I needed a thread for handling refreshing while computing, so anyway I need lower level stuff than future, and make-thread is fune
<galex-713>(although it can be fun too x))
<galex-713>Using 2.0, while manual talk about srfi-31 if my version of guile says it’s visibly not implemented? “unbound variable ‘rec’”, and no module (srfi srfi-31)
<ijp>wfm in 2.0.11
<galex-713>Oh, never mind, there *is* a srfi-31 module
<galex-713>*How do you make simply cyclic lists with guile? I thought rec could help that but know
<galex-713>I used to do that in a rather complex way with elisp, using setcdr and setcar, do these exist in scheme?
<ijp>they do and are called set-car! and set-cdr!
<ijp>rec is not going to work for lists, though it would for streams
<galex-713>how sad :( I thought I found a simple unique form to make cyclic lists
<ijp>yeah, rec is really just a shorthand for a specific use of letrec
<ijp>racket has a form that lets you do cyclic lists, I think it is called "shared", but I think it produces mlists, so it probably doesn't get as much use in racket for that reason
<ijp>it could be an interesting macro to write, since I think it could lead to weird interaction with call/cc
<galex-713>do last-pair return a copy of last pair of a list or the real last pair? because setting its cdr to the original list doesn’t make it cyclic
<ijp>the real last pair
<ijp>what makes you think it isn't cyclic? example?
<galex-713>no #0
<galex-713>oh wait no it works
<galex-713>it seems geiser has problem with cyclic lists x)
<ijp>that is possible
<galex-713>Ok done
<galex-713>ijp: any idea of how to test a list is cyclic?
<ijp>tortoise and the hare?
<ijp>that's how our printer does it
<galex-713>Oh, found
<galex-713>First I implement it myself, then I look at your link :p
<ijp>essentially you have two pointers travelling at different speeds. If they ever meet there is a cycle, if you reach the end, you're done.
<ijp>actually I think srfi has a cycle test
<ijp>srfi 1*
<ijp>oh wow, it even has the function cyclic-list
<ijp>so er, yeah, shows how often I use that
<galex-713>wtf my emacs forked inexpectedly
<galex-713>I mean, I had one emacs, and one I’ve two, with exact same buffers
<galex-713>help, my emacs is doing mithosis!
<galex-713>omg they have common buffers
<galex-713>it’s the same emacs split in two X window
<galex-713>that’s… awesome…
<spk121>Hello guile. What is a good way to get the contents of a png or jpeg, which is to say to get the a rectangular array of RGBA values?
<galex-713>you mean the raw?
<galex-713>ijp: where? I can’t find it in manual, is it recent?
<spk121>Yeah, the uncompressed data.
<galex-713>ijp: I can’t find cyclic-list
<ijp>sorry, circular-list and circular-list?
<ijp>both srfi 1
<galex-713>ijp: why no cycle! function? or does it exist?
<ijp>what would cycle! do
<galex-713>(set! var (cdr var))
<galex-713>so you can cycle on the circular list
<ijp>well, that wouldn't be a function, but no, there is no such form
<galex-713>(cycle direction) is more readable than explicitly associating a number per direction then doing (setq! direction (modulo (1+ direction) direction-number))
<galex-713>ijp: why not a function?
<ijp>have a think about it for a minute or two
<ijp>well, there is a sort of way of writing it as a function, but it's really hideous
<galex-713>I just did (define (cycle! list) (set! list (cdr list)))
<galex-713>Oh wait
<galex-713>doesn’t work, list is a copy of arg
<galex-713>oh I get it, only a macro can be destructive
<galex-713>I thought it was directly passing the pointer to the function
<galex-713>Ohhhh maybe it does pass the pointer of the value but since it’s another symbol I should do set-car! then set-cdr!…
<galex-713>Then yes a macro is better
<ijp>it's not a copy, but a different name
<ijp>anyway, if you want to write that as a function, you would need to be modifying the initial pair (code forthcoming) or have a sentinel value
<galex-713>yes yes, the same pointer, but different symbol
<galex-713>oh but, macro defining in scheme seems more complex than in elisp…
<ijp>not really
<ijp>(define-syntax-rule (cycle! list) (set! list (cdr list)))
<galex-713>oh I was searching for define-syntax usage x)
<galex-713>Ok cool
<ijp>true fact: I reimplemented part of schemes macro system in elisp so I didn't have to use defmacro
<ijp>because using patterns is way easier than processing the list
<galex-713>(have to say I myself have so much subverted elisp I can understand x)
<galex-713>I see
<holomorph>was that mbe.el
<ijp>it was
<galex-713>Let’s write an elisp implementation of scheme and vice versa xD
<ijp>the actual reason is nicferrier wanted an implementation of let* for his js emacs thing, and I started writing one and thought it would be easier to write in scheme, so I wrote mbe to write that macro
<galex-713>One day I’ll find the smallest way to make a lisp interpreter in any language, for the next time someone takes the risk to order me to code in another language :>
<galex-713>ijp: but is elisp let* still implemented in scheme today?
<holomorph>heh, hygienic macros in elisp would be nice indeed
<ijp>galex-713: this was never part of emacs proper
<galex-713>ah ok, because today elisp includes let*
<galex-713>holomorph: what’s hygienic?
<ijp>galex-713: sure and it has done probably since 1984 when gnu emacs was written, this was for a different elisp project
<galex-713>ahh ok
<ijp>galex-713: do you understand the difference between lexical and dynamic scoping?
<ijp>one analogy is that hygiene is like lexical scoping for identifiers used in macros
<ijp>but don't worry about hygiene too much until you start writing non-trivial macros
<galex-713>ijp: yes I understand but have to concentrate to remember each time
<galex-713>ijp: elisp is dynamically scoped right?
<ijp>yes, except for when it's not :)
<galex-713>ah you mean when you change that buffer-local variable
<galex-713>but by default it’s dynamically?
<galex-713>that’s why my brain is sometimes doing garbage
<galex-713>ijp: what’s the proper way to call a function whose you just got the symbol from symbol-append?
<galex-713>and what’s an obarray?
<ijp>well, the way you generally do it is you look it up in the module with module-ref
<ijp>e.g. (module-ref (current-module) 'car)
<galex-713>wow that begin to becomes verbose
<ijp>the proper proper way is you don't do it, but people don't find that a helpful answer
<galex-713>Did you already had this tendancy to write twice longer code just to factorize 4 lines?
<ijp>there are shorthand macros for doing it when you know the modules name and the identifier, but those obviously don't take symbols
<ijp>galex-713: scheme code often seems long because of the paucity of syntax
<ijp>as for factoring code, you eventually learn a sweet spot
<mark_weaver>galex-713: srfi-1 exports a 'circular-list?' predicate
<galex-713>mark_weaver: yeah I noticed it since then ;)
<mark_weaver>galex-713: also see 'length+' which returns the length of a finite list, or #f for a circular one
<ijp>mark_weaver: I hope it took you less than 20 minutes to remember, like it took me
<galex-713>sweet pot?
<mark_weaver>ah right, I should have read the entire log before responding
<mark_weaver>ijp: I immediately remembered that srfi-1 had the necessary tools, but needed to look up the details
<ijp>mark_weaver: do you know if guile scmutils is up to date?
<galex-713>ijp: what’s a sweet pot?
<ijp>sweet spot
<mark_weaver>ijp: I vaguely remember seeing that guile-scmutils had been updated to guile 2.0.x, but that's all I remember
<ijp>fair enough
<ijp>btw, do you have any good resources for basic numerical analysis?
<mark_weaver>ijp: not really. I've dabbled, but it's not something I've done much of. in the scheme world, I get the impression that scmutils running on MIT/GNU scheme is the best thing we have right now, but that might be a result of my ignorance.
<ijp>I'm not opposed to installing MIT/GNU, but having 3 different schemes on a computer gets to feel excessive :)
<mark_weaver>it might be better to use guile's ffi to use GSL, or something
<mark_weaver>s/better/more practical/
<galex-713>ijp: but what did you mean by “learn a sweet spot”?
<galex-713>(also I found solution to my problem not using symbol-append but making one of procedures in a let-bound var which I car/cdr when needed)
<galex-713>(that’s more lines but factorized)
<ijp>galex-713: essentially I'm just saying that getting the right factorisation comes with experience
<galex-713>what do you mean by right factorization? you mean when you have to choose between factorizations or you mean how to to factorize properly or you mean when it is accurate to factorize?
<galex-713>ijp: ^
<galex-713>What is the proper way to get a list of each decimal digit making a number in guile? I myself made two functions: one which operates with log10, powers of 10 and quotients, and another which split in chars the number->string, strangely the second is the faster one, and I find that ugly: is there any function to do that?
<wleslie>do *--buflim = digits[value % Base]; while (value /= Base) != 0);
<wleslie>a few reasons this code from glibc itoa might be faster than your implementation include the fact that value doesn't need to change register, and there's actually only one division operation there on x86/x86_64
<galex-713>I see
<galex-713>ijp: is there something like elisp’s (macro () …) so you can bound macros to variables inside a let along with normal procedures?
<galex-713>Also, can guile use dynamically scoping if we want to? like elisp?
<wleslie>it has fluids for that purpose
<mark_weaver>galex-713: see 'let-syntax'
<galex-713>mark_weaver: so I have to use two let one inside the other?
<galex-713>I found scheme useful because in only one let I could define functions as well as variables but it seems it doesn’t cover macros :/
<mark_weaver>yes, or alternatively, use internal 'define' and 'define-syntax'
<mark_weaver>well, macros are expanded at compile time, so the bindings are technically not 'variables'
<mark_weaver>there is no trace of them left by the time the code is run
<galex-713>mark_weaver: also is there a way to access the code of a procedure from the code? as it is possible in elisp? (if you do “car” on a function-cell you get “lambda” symbol)
<mark_weaver>sorry, we don't have that
<galex-713>oh :()
<galex-713>oh :(*
<mark_weaver>out of curiosity, how were you planning to use this?
<galex-713>mark_weaver: is it guile which don’t have that or scheme?
<mark_weaver>in the general case, it can be rather unclear what the "code" is
<mark_weaver>scheme doesn't have it either
<galex-713>mark_weaver: I asked this by curiosity, even if I used that some times for fixing functions the ugly way in elisp, but I thought that could be used for clean&useful things maybe
<mark_weaver>for example, you might ask what is the code for the 'pipe-info?' procedure defined in module/ice-9/popen.scm line 31
<mark_weaver>or maybe it would be better to point at module/srfi/srfi-9.scm line 324
<mark_weaver>or perhaps line 116 of srfi-9.scm
<mark_weaver>galex-713: in your opinion, if we provided a way to return the code of a procedure, what would you expect us to return for 'pipe-info?' ?
<galex-713>mark_weaver: the code that would be processed if you applied this procedure at the moment you ask the code?
<mark_weaver>well, for guile 2.0.x that would be code for the stack-based virtual machine
<mark_weaver>for guile 2.2.x it will be a register-based virtual machine
<mejja>It should return the code for pipe-info? in ice/popen.scm of course... this ain't rocket science. (he is not asking for a disassembly of the bytecode)
<mark_weaver>mejja: what precisely do you think it should return?
<mark_weaver>did you look for 'pipe-info?' in popen.scm?
<mejja>sure. that is a record predicate. trivial.
<mark_weaver>tell me what you think it should return, please
<mark_weaver>(procedure-code pipe-info?) ==> ?
<mejja>how about: (lambda (object) (and (%record? object) (eq? (%record-ref object 0) tag))) or some such
<mark_weaver>mejja: where is that code?
<mark_weaver>another issue is that the code itself is meaningless without knowing the free variable bindings in effect in the lexical environment surrounding the procedure
<galex-713>oh yeah lexical scope…
<galex-713>mark_weaver: ok you made a point, that makes less sense inside guile
<galex-713>mark_weaver: although elisp gives you (closure () [var bindings] […]) for functions defined inside lexical scope
<mark_weaver>*nod* that is a partial solution, but many problems remain
<turbofail>elisp only does that for interpreted code
<galex-713>oh yeah, for byte-code elisp return strange stuff though, right
<turbofail>in any case, even in elisp you shouldn't ever rely on being able to access the "code" of a procedure
<mark_weaver>I like the idea of being able to retrieve the code of a procedure, in a form that is unambiguous, suitable for automatic processing, etc.
<mark_weaver>but for a language like scheme, with its lexical scope and macros, that seems to me a non-trivial task
<mark_weaver>even designing the API is non-trivial
<turbofail>i feel like programmatic access to things like the arity and source location and whatnot is probably just as good IMO
<turbofail>i mean... what would you REALLY do with the procedure code at runtime?
<mark_weaver>good question
<mark_weaver>in theory, you could try to automatically deduce properties of the procedure, such as 'pure-function?', etc, in order to optimize code that uses the procedure.
<mark_weaver>I should mention one thing that *is* possible and quite easy: you could create a macro 'define-with-source' that is like 'define' but also saves the quoted code of the procedure and associates it with the procedure object using 'procedure-properties' or 'object-properties' or whatever.
<mark_weaver>but it doesn't solve the more general problem
<turbofail>yeah. one semi-decent use i've seen for a macro like that was for making serializable closures to transmit over a network
<amz3>héllooo :)
<dsmith-work>Happy Friday, Guilers!!
<cbaines>How would I go about creating a quoted list of variable length? e.g. I can do '(1 2 3) but what if I wanted to get 1 to n, for some n?
<random-nick>cbaines: well that wouldn't be a literal list then
<random-nick>cbaines: if you want a list containing numbers from 1 to some number check out iota from (srfi srfi-1)
<cbaines>random-nick, ok, thanks, I've just realised that for my usecase, what I was trying to do just works, but thanks anyway :)
<jlicht>hello Guilers! I am having some trouble with the (web uri) module, and to be more specific with fragments
<jlicht>It seems that my fragment (e.g. #foo) in a string, gets parsed as a fragment ##foo when using the string->uri function
<jlicht>repeating the (uri->string (string->uri (uri->string (string->uri (uri->string (string->uri "")))))) will give $19 = ""
<dsmith>scheme@(guile-user)> (use-modules (web uri))
<dsmith>scheme@(guile-user)> (string->uri "http://host/page#frag")
<dsmith>$1 = #<<uri> scheme: http userinfo: #f host: "host" port: #f path: "/page" query: #f fragment: "frag">
<dsmith>scheme@(guile-user)> (uri->string $1)
<dsmith>$2 = "http://host/page#frag"
<dsmith>jlicht: Seems to be ok in 2.1. What version is your guile?
<davexunit>I see the same problem on 2.0.11
<davexunit>2.0.11 was released a long time ago so if 2.1 works then someone found and fixed the error in the past couple of years
<jlicht>hmm okay, at least I know I'm not going insane, which is nice
<jlicht>thanks davexunit, dsmith
<dsmith>jlicht: There is quite a few commits to the stable-2.0 branch beyond the 2.0.11 release. Probably is in there.
<jlicht>is there an idiomatic way to create a copy of a record, yet with one field changed?
<davexunit>jlicht: no
<davexunit>things are more abstract than that
<jlicht>davexunit: actually found what I wanted
<jlicht>set-fields in (srfi srfi-9 gnu) is _exactly_ what I was looking for :-)
<jlicht>"functional setters", quite a nice description
<davexunit>jlicht: you can't use that with any arbitrary record
<davexunit>which is what I thought you were asking about
<jlicht>davexunit: Before I run head-first into something I did not think of, what kind of instances are you talking about? The documentation at imho seems to say that it should work :O
<mark_weaver>jlicht: functional setters should work for SRFI-9 records
<mark_weaver>just be aware that not all records/structs in Guile are SRFI-9 records
<jlicht>mark_weaver: that is a bit disconcerting to hear, although in this case things should work out
<davexunit>jlicht: it's important to keep in mind that you may break someone's data abstraction if you set field values with set-fields
<davexunit>I often do not expose any setters for my record types, and sometimes I don't even expose accessors for certain fields.
<davexunit>other times, I write setters that wrap the record type setter and do additional things
<davexunit>basically, don't think of them like javascript objects
<galex-713>Is it possible with scheme/guile to *restrict* syntax? like disallowing all side-effects procedures
<davexunit>I wouldn't say that it is impossible, but that would be quite the challenge.
<davexunit>also, procedures and syntax are different things.
<davexunit>if you had a system that disabled the use of set! or something, things would break.
<davexunit>programs written in a purely functional style are built upon an imperative foundation.
<amz31>paroneayea: did you read this
<amz31>paroneayea: ?
***amz31 is now known as amz3`
<amz3`>o/ ijp
<dsmith>sneek: botsnack
***dsmith is now known as dsmith-work