<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? <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>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 <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>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) <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>what makes you think it isn't cyclic? example? <galex-713>it seems geiser has problem with cyclic lists x) <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>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>oh wow, it even has the function cyclic-list <ijp>so er, yeah, shows how often I use that <galex-713>I mean, I had one emacs, and one I’ve two, with exact same buffers <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>ijp: where? I can’t find it in manual, is it recent? <ijp>sorry, circular-list and circular-list? <galex-713>ijp: why no cycle! function? or does it exist? <ijp>what would cycle! do <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)) <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 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!… <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>(define-syntax-rule (cycle! list) (set! list (cdr list))) <galex-713>oh I was searching for define-syntax usage x) <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>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 <ijp>galex-713: sure and it has done probably since 1984 when gnu emacs was written, this was for a different elisp project <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 <ijp>yes, except for when it's not :) <galex-713>ah you mean when you change that buffer-local variable <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? <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) <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 <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? <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>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 <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) <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>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>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? <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>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 <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>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? <mejja>sure. that is a record predicate. trivial. <mejja>how about: (lambda (object) (and (%record? object) (eq? (%record-ref object 0) tag))) or some such <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>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 <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 <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>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. <turbofail>yeah. one semi-decent use i've seen for a macro like that was for making serializable closures to transmit over a network <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: 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 <dsmith>scheme@(guile-user)> (use-modules (web uri)) <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>jlicht: Seems to be ok in 2.1. What version is your guile? <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 <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? <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 <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 is now known as amz3`
***dsmith is now known as dsmith-work