<waxysubs>davexunit: the gnutls guile bindings from trisquel 6 are probably meant to run with guile 1.8 <sneek>mark_weaver, you have 1 message. <sneek>mark_weaver, taylanub says: I remember you mentioning a psyntax rewrite; are there plans on what it will and won't support? I think immutable/sealed modules and the ability to "static import" them could be a huge help for performance-critical code. Shiro Kawai mentioned Gauche will be doing the same, which is otherwise like Guile in "all toplevels mutable"; I think it's the right solution. <davexunit>waxysubs: yeah, that makes sense. I got guile-curl to build so I'm using that for now instead of gnutls. <sbidin`>I'm trying to re-export all identifiers from a certain module. The following fails because re-export is a macro and `name` does not get evaluated. How to fix this? <sbidin`> (lambda (okay var) (re-export int)) <sbidin`> (lambda (name var) (re-export name)) <mark_weaver>sbidin`: IMO, it's a bad idea to export all identifiers from a module. the problem is that many macros define "hidden" variables that should never see the light of day, and they end up getting exported and then causing identifier collisions in importing modules. <sbidin`>mark_weaver: I understand. This is more an exercise than anything, since I'm still learning Scheme/Guile. <mark_weaver>sbidin`: instead, I recommend either creating macros in the spirit of 'define-public', or just list the exports explicitly. <ijp>anyway, there are procedures like module-export! <ijp>,a export will give you a list <sbidin`>mark_weaver: I'll end up doing it the explicit way, yes. <sbidin`>ijp: I had no idea about ,a. Thanks! <ijp>",help all" will give you the full list <sbidin`>I've noticed that (help any-symbol) almost never returns any documentation. For instance, (help re-export). Stdlib functions don't have docstrings? <mark_weaver>ijp: interesting! do you make any attempt at hygiene? <mark_weaver>tbh, I'm actually not even sure how hygiene can be done with dynamic scoping. it may be impossible. <davexunit>how do I capture what's printed to stdout when calling 'system'? <mark_weaver>ijp: you might consider adding at least some of the extensions in SRFI-46. <ijp>mark_weaver: I intend to, you can already see the variable for allowing a different ellipsis <mark_weaver>ijp: ah, yes! tail patterns are also occasionally useful. <sbidin`>Does the stdlib contain something like the following? <ijp>I call it push! in my own utilities module <sbidin`>Ah, so people do use it. Thanks! I'll name it push! as well. <ijp>and I'd suggest define-syntax-rule for these simple macros <sbidin`>I didn't know about define-syntax-rule, thanks. Much nicer. <mark_weaver>the thing is, modern scheme code tends to avoid mutating variables in most cases, so that kind of pattern is not used very often. <mark_weaver>and I should mention that mutable variables are less efficient <sbidin`>Really less efficient? My dirty secret is that I come from years of Haskell and am enjoying this sporadic in-place mutation. :) <mark_weaver>well, for one thing mutable variables need to be stored in heap-allocated "variable" objects, and most of the optimization passes in our compiler can't do much with mutable variables, but are able to do things like partial evaluation and CSE for non-mutable variables. <mark_weaver>don't get me wrong: I'm not shy to use mutable state when it is appropriate, and since you have experience with haskell I guess I don't have to tell you that mutable state is vastly overused among typical programmers. <mark_weaver>so maybe push! is reasonable. I've written code that defines and uses it myself :) <sbidin`>Ah, so it's not optimal for the compiler. I understand. <daviid>mark_weaver: hello! did you have any time to look further into the bug i mentionned here about threads? <ijp>hash-map->list + module-obarray <daviid>sbidin`: re-exporting a public interface is part of guile-gnome <sbidin`>Actually, scratch that, I found module-map. <mark_weaver>daviid: to be honest, I was very surprised that you ran into the same problem when using my alternative par-map. I don't see how that could be. <mark_weaver>there are definitely thread safety issues with the way that fluids are garbage-collected, though. <sbidin`>daviid: Thanks! I'm just learning still, so I try to avoid extra libs at the moment. I'll keep guile-gnome in mind. <daviid>sbidin`: i mentionned for you to look at the code :) <daviid>mark_weaver: it raises the bug far faster using alternate par-map, so that in the mean time, i am back using future [the stable-2.0 core par-map implementation] <mark_weaver>daviid: I really have no clue what's going on there. you got the same error message about '>' being applied to #f, and the code that does that is in (ice-9 futures), but my alternative par-map doesn't use futures at all. <daviid>mark_weaver: hum! is that in the stress and the hurry i could have run the wrong code then? <mark_weaver>daviid: I think it's likely that something went wrong with trying to use the alternative par-map. <mark_weaver>what exactly did you do to switch to the alternative par-map? <daviid>this bug puts a hight stress on me, the lab and some clients do stricktly depend on my code, extensively using par-map ... <daviid>mark_weaver: let me try again, i may have done a 'funny' things out there <mark_weaver>understood. I would like to help, I'm just very confused by the reports. <daviid>i was actually using the git branch 'thread-safe-popen' or something like that, but who knows ... <mark_weaver>well, you should use current stable-2.0 git with just that one patch I sent you applied. <daviid>ok, i will try carrefully and let you know, tx <mark_weaver>daviid: the other thing that might help, as a work-around, is to explicitly load the (ice-9 threads) module during initialization before any threads are created. <daviid>i beleive i do that already, let me check <sbidin`>Is there an easy way to jump to a stdlib function definition? I'm trying to see how module-map is implemented. (I'm guessing it uses hash-map->list + module-obarray, as ijp said, and I see the same thing being done in guile-gnome.) <daviid>mark_weaver: yes i import (ice-9 threads) as the very first lines of the script, far before to call par-map <mark_weaver>sbidin`: module-map is defined in module/ice-9/boot-9.scm <mark_weaver>sbidin`: Geiser's command to jump to a definition is M-., but it doesn't seem to work for things that are "built-in" as opposed to in a module. <sbidin`>mark_weaver: Thanks! So boot-9 is like the prelude. It seems this might be a nice patch for geiser, to search around in boot-9 (and similar locations?) if a symbol can't be found. <mark_weaver>sbidin`: if you run "make tags" in the guile source directory and then M-x visit-tags-table and select module/TAGS, then M-x find-tag will work. <mark_weaver>"make tags" produces several TAGS files, but the important ones are module/TAGS and libguile/TAGS <mark_weaver>module/TAGS for things defined in Scheme, and libguile/TAGS for things defined in C. <sbidin`>mark_weaver: Thanks! I'll be doing that. <sbidin`> (hash-map->list proc (module-obarray module))) <mark_weaver>to be honest, for a long time I avoided using Geiser because it rebinds M-. from find-tag (which works for these core definitions) to something Geiser-specific that does *not* work for many of my use cases. it would be great to get that fixed. <daviid>mark_weaver: i've just applied the patch, make, make install and running my script bugs with the same <daviid> ... ... 136: 0 [n-par-map 4 ...] <daviid>ice-9/threads.scm:136:4: In procedure n-par-map: <daviid>ice-9/threads.scm:136:4: In procedure >: Wrong type argument in position 1: #f <daviid>david@capac:/opt/share/guile/2.0/ice-9 2 $ ll threads.scm <daviid>8 -rw-r--r-- 1 david alto 6728 Sep 3 20:13 threads.scm <daviid>mark_weaver: ^^ is the content of my /opt/share/guile/2.0/ice-9/threads.scm, to make sure i did apply the patch correctly, so tired that i do not reject another mistake of mine here :) <daviid>i am also worried about the 'broken pipe' warnings, i've search guile's tree and did not find the text so i guess it's the kernel, and may be the cause of the problem? <daviid>mark_weaver: would an strace be usefull for you? <mark_weaver>daviid: probably not. in ice-9/futures.scm, in the procedure 'touch', there are two occurrences of "(> (%nesting-level " <mark_weaver>in both places, can you change (%nesting-level) to (or (%nesting-level) (error "%nesting-level is #f")) <mark_weaver>daviid: are you using any parallelism primitives aside from par-map ? <mark_weaver>then I don't understand how it's even getting to the futures code at all. I find this utterly baffling :-( <daviid>i really don't understand either. i just run the code with the modification but it prtins the same error <daviid>let me paste it will be nicer to others <mark_weaver>even after inserting those two calls to 'error' in futures.scm? <daviid>yu'll see that it recomplies future <daviid>the procedure that par-map runs on every 'particle' is defined starting at line 544 [i don't expect you to read neither 'understand' the details of course, but who knows that you spot a pattern that triggers an idea ... <daviid>i could comment the with-mutex, maybe <daviid>ok, i did try commenting with-mutex call but it does not change, it bugs <ijp>mark_weaver: tail patterns seem trickier, particularly because of patterns like (foo bar ... baz quuz . zot) <ijp>that isn't legal per srfi 46, but it is in r6rs <ijp>I'm wondering if I need to match in two directions <ijp>the wording there is looser than I'd have done, since it could imply that multiple ellipsis are valid <mark_weaver>daviid: I have to go, but I would consider the possibility that one of the calls to '>' in your own code (within the subthreads of the par-map) is actually the culprit. I would search for "(>" in your code, and consider whether it's possible that its first argument might ever be #f. and if that fails, then try annotating them with (or <FIRSTARG> (error "!!")) <ijp>fortunately, the template part of the macro requires no changes <davexunit>does guile come with any good procedures for converting strings in camel case to lisp case? FooBar -> foo-bar <ijp>that's clojure though <davexunit>it's morning for you when i'm about to go to bed. <nalaginrut>yeah, you can do the same to me when I'm going to bed ;-D <davexunit>we are on exact opposite sides of the world :) ***trifling_gnome is now known as JudgeDreadlock
***sbidin`` is now known as sbidin
<lloda>i never remember if fold takes (λ a ... seed) or (λ seed a ...). The help could at least say that :-/ ***DerGuteM1 is now known as DerGuteMoritz
<ijp>sneek: later tell lloda, it doesn't help that srfi 1 uses a different order for fold than is traditional for foldl, but the the trick to remembering form me is that it has the same order as cons. (fold-right cons '() x) = id and (fold cons '() x) = reverse <taylanub>sneek: later tell lloda if you just display the value of `fold' by e.g. typing it in at the REPL, the representation will include the parameter list <lloda>ha, neat. I hadn't seen that. <sneek>Welcome back lloda, you have 2 messages. <sneek>lloda, ijp says: it doesn't help that srfi 1 uses a different order for fold than is traditional for foldl, but the the trick to remembering form me is that it has the same order as cons. (fold-right cons '() x) = id and (fold cons '() x) = reverse <sneek>lloda, taylanub says: if you just display the value of `fold' by e.g. typing it in at the REPL, the representation will include the parameter list <lloda>ijp: yeah, I knew about the different orders. I got into Guile through libctl which defined its own fold with the order different from SRFI-1. <lloda>ah, taylanub, that doesn't help. It just says #<procedure fold (kons knil list1 . rest)>, but what I kept forgetting (now I hope I won't) is the args to kons, what ijp explained. <DerGuteMoritz>hello guiles! is (ice-9 match) based on foof's implementation? <taylanub>even the documentation is yanked straight out of it even though we don't support all the documented features :) <DerGuteMoritz>just ran into a situation with it that might be considered a bug (I at least do) <taylanub>(namely, boxes. might just be the only unsupported thing, not sure) <taylanub>DerGuteMoritz: that is expected behavior in Scheme :\\ <taylanub>any auxilliary syntax is still "bound" to something (or if its really unbound then you can think of that as a special binding), and lexical bindings that shadow it make it stop working <DerGuteMoritz>I mean, with cond it's no problem to work around even without changing the environment <taylanub>notably Kernel has dropped it .. in Scheme it's probably too late, and the merits dubious IMO; it is after all lexically apparent that you shadow them; you just need to know this tidbit about Scheme <taylanub>(Kernel has dropped all auxiliary syntax, I mean) <DerGuteMoritz>well this could be worked around in match via low-level macro facilities, of course <taylanub>"ideally" match would export all its auxiliary syntax bindings so you could import them with a prefix to prevent clashes. this ideal is not really practically ideal :P <DerGuteMoritz>it's especially annoying with _, as it is often used in lambda lists for arguments one doesn't care about <civodul>DerGuteMoritz: i use (define _ gettext), but i think this doesn't interfere when _ is a global, on 2.0.11 <DerGuteMoritz>civodul: indeed, same happens with chicken. I wonder if that is expected ... <civodul>i think that's because psyntax doesn't "see" it ***heroux_ is now known as heroux
***sethalve_ is now known as sethalves
<ArneBab>the talk starts at the time where he explains what I am missing in (use-modules) as default behavior. <ArneBab>taylanub: lack of namespaced import with the name of the module *by default* <ArneBab>I can add a renamer or use only some specific bindings, but they are harder to use (require more code) than just getting all bindings. <ArneBab>I think racket offers something to turn (object.method arg) into (method object arg) <paroneayea>I think the dot notation bit is my favorite part of Hy as a lisp <paroneayea>though I think it's mostly borrowed from clojure <paroneayea>the other module-related thing I wish would be improved in Guile is that I'd really love to see some aliases for the "robot serial number" packages, eg the srfi ones, but I've said that before :) <paroneayea>davexunit: dot notation is great, it means namespacing <ArneBab>davexunit: in python it’s very useful, because readline offers completion for the methods of objects. <taylanub>me neither. it's some trivial change that lets you write code as subject-verb-object instead of verb-subject-object, and in fact sometimes obscures things because you really have verb-object1-object2 ... <paroneayea>it seems like the packages have namespaces, but once you import them <taylanub>ah, code completion, OK that's an argument <ArneBab>taylanub: that’s how I actually use it ☺ <ArneBab>or rather what makes it most useful for me. <paroneayea>davexunit: but in python, there are never conflicts, and also I know exactly where things are coming from :) <paroneayea>it's immediately clear reading the code, oh right, this function comes from *that* package <paroneayea>and assuming nobody did the "from foo import *" asshattery <ArneBab>that’s what you get for that in guile: <ArneBab> #:select ((open-pipe . pipe-open) close-pipe) <ArneBab> #:renamer (symbol-prefix-proc 'unixy:))) <taylanub>paroneayea: it's a trade-off between clarity and terseness <ArneBab>paroneayea: you can use it in guile, but as the example shows: it’s not the easiest way (by far), so people don’t. <ArneBab>taylanub: I did not know that - that’s a bit nicer. <davexunit>ArneBab: (use-modules ((ice-9 popen) #:prefix 'unixy:)) <davexunit>I think it's useful that different modules can provide different implementations of the same procedure, for example. <ArneBab>and I could easily add some syntax which always uses the name of the module as prefix. <ArneBab>but, and that is the gist of all that, it is not the default. <ArneBab>all these things help the most, if they are in code you *read*. <davexunit>and like I said, there's always (@ (ice-9 popen) open-pipe) <ArneBab>(define open-pipe (@ (ice-9 popen) open-pipe)) <davexunit>I find that @ is mostly used inline to reference one variable that you want from a module without having to explicitly import it. <davexunit>and you can be evil and use @@ to fetch unexported variables, too. <davexunit>which can be useful for working with a private API. <ArneBab>yepp - just to have it written here: I think that guile can do much more than python. I know nothing in Python which I cannot do in Guile. <ArneBab>But in Python most of the time the *default way* of doing that looks nicer. <ArneBab>(use-modules (ice-9 popen)) ← this does what C normally does. It is what C-people are used to. But it clobbers the namespace and makes it hard to find where a variable comes from. <ArneBab>(use-modules (ice-9 popen) #:prefix 'ice-9:popen:) ← this would make it clear for every usage of the module where you find the source. <davexunit>just inspect the variable at the REPL, it will tell you where it comes from. <lloda>In Python exports are implicit, in Guile they're explicit. I almost never have collision problems. If I have them I get a warning and I add a minimum prefix to disambiguate. To require full path prefix by default sounds like a terrible idea to me. My 2c. <ArneBab>as I said: it’s not that there aren’t solutions to all these things. <davexunit>it's a very rare occasion that I get any conflicts. <ArneBab>it’s not about conflicts: It’s about always knowing where something comes from. <lloda>scheme@(guile-user)> (help fold) <lloda>`fold' is a procedure in the (srfi srfi-1) module. <ArneBab>so you read the source file, then you execute it to get it into your REPL (assuming that you have something like geiser set up) and then call (help <name>) <davexunit>I can't really recall a time when I didn't know where something came from. <ArneBab>it happened to me a few times. Though mostly because the REPL had imported something by default which wasn’t in the non-interactive execution. <ArneBab>correction: I regularly have to info/google which module to use <ArneBab>this disappears with module-name-in-variable. <ArneBab>(though partially due to auto-completion in the REPL) <ArneBab>“wait, that was in datetime somehow.” → import datetime; datetime.<TAB>; datetime.timedelta? <ArneBab>^ the above requires the ipython interpreter to work. <ArneBab>it’s the same operation for module.function as for object.method <ArneBab>and all in all it’s about remembering less <davexunit>I think just inspecting the variable or using help will give you everything you need. :) <ArneBab>Guile offers more *options* for that, but does much less *by default* <davexunit>when using geiser in emacs, you can also press M-. and jump to the definition of most things. ***gjanssens is now known as gjanssens_
<ArneBab>If a language is nice to use without a tool, then I can use different tools which solve different problems without having to provide the basic support for missing parts in the language. So there’s more space for experimentation. <ArneBab>guile scheme offers power, but I personally think it misses much of what’s possible by optimizing best practices. <ArneBab>#:prefix should help me a lot, though. <ArneBab>then finding out where and how I got something becomes a simple manner of C-r <'prefix:> <ArneBab>that saves me 2 operations, and the ' in front of the prefix ensures that I get to the use-modules call right away. <ArneBab>and I think I can actually remember #:prefix ☺ <DeeEff>Not that I'm entirely sure I'm up to date with the full conversation, but what's wrong with ",apropos <symbol>" at the terminal? <DeeEff>isn't that the normal way of finding out where a symbol comes from? <ArneBab>… it would not actually be an answer… <ArneBab>the quote would have been: so you read the source file, then you execute it to get it into your REPL (assuming that you have something like geiser set up) and then call (help <name>) <ArneBab>but the real answer is: I have to switch from my editor to the REPL. <DeeEff>this is not a problem if you're using slime or some variant <ArneBab>it’s still a context switch: from reading text to the REPL <ArneBab>(note that all this is not something debilitating. It’s polish - polish which matters but which isn’t essential) <ArneBab>does `,a symbol` work when you did not run the file yet? <ArneBab>so only the website is missing (if it provides extra modules) <DeeEff>certainly, but most of the time you'll have your dependencies installed if you're inspecting software <ArneBab>my setup seems to be not quite optimal ☺ <ArneBab>(I often read code samples for stuff which isn’t installed) *ArneBab more and more realizes that while the default way in Python is easier (import foo; foo.bar() # from file foo.py), the more complex case of renaming the import is nicer with #:prefix <DeeEff>actually, I may be wrong, you may need to run the imports on your own libraries before ,a works *ijp more and more realises how annoyint it is when people use /action for non actions *ArneBab looks at ijp’s annoyance and tries to remember to avoid that when he’s around ☺ <dsmith-work>ISTR that Oleg has written something about modules and namespaces. He uses the ' ' char instead of the '.' char. ;^) <lloda>Guile supports this simpler syntax that I use exclusively now <lloda>(import (prefix (module path) the-prefix.)) <DeeEff>are import and use-modules the same thing in guile? I know in Chicken it certainly isn't <ijp>I'm not sure why import got added to the default module, since it was really there for r6rs modules <sbidin>I don't want to install my modules, but work with them in the home dir. Is calling (add-to-load-path (dirname (current-filename))) common and the way to do this? <ArneBab>something I forgot again: How can I get all currently defined bindings in the REPL? <ArneBab>ijp: that’s what I thought, but it’s empty <ijp>are these functions *you* defined? or ones in guile <sbidin>Or do people just set their GUILE_LOAD_PATH? <ArneBab>ijp: I wanted to see what (import (ice-9 popen)) gets me <ijp>definitions at the repl get put in the module (guile-user) <ijp>this is what ,b shows <sbidin>ArneBab: Thanks! I like that option best. <ijp>normal guile bindings are in the module (guile) <ijp>otherwise you would get hundreds of functions when you typed ,b <ArneBab>and something which shows me that is what I want <ArneBab>I want to know what I have available right now. <ijp>extending ,b to take an optional argument might be a good idea <ijp>,a is fine if you have a module prefix <ArneBab>mv… use-modules ((ice-9 popen) #:prefix 'unixy:)) → (expecting symbol): (quote unixy:) <ArneBab>so that’s actually not simpler than python, but just as easy (and consistent) <ArneBab>(use-modules ((ice-9 popen) #:prefix unixy:)) <ArneBab>and what’s cool is that running a procedure as variable actually gives the arguments it takes. <ijp>may you live in interesting times <JudgeDreadlock>ijp, what is your opinion on the Scottish accent of Scottie from STar Trek? <davexunit>so, what's up with that long thread that guile-devel is CC'd on, as well as rms, theo, linus... ? <taylanub>Ritchie hack on compilers. might have infected GCC at some point. Ian Grant is trying to convince everyone that it's not implausible and should become a concrete concern of the FSF/GNU <ijp>JudgeDreadlock: I've heard worse <ijp>taylanub: bradley kuhn likes to go on about it too <davexunit>taylanub: I found the whole thread to be really hard to follow <taylanub>is it that long? I thought it was still rather short, though I mostly just skimmed through it and maybe missed some mails that weren't CC guile-devel <ijp>as a rule, the number of lists CCed is inversely proportional to credibility <davexunit>hmm, maybe I'm confusing it with another similar thread that is going on right now that involves the same people elsewhere <taylanub>ijp: actually just GNU Lightning and Guile, because it started as a question on whether they could cooperate; then this talk spun off with RMS joining. <ijp>I wasn't aware people still worked on gnu lightning <ijp>I suppose they probably thought the same about guile <taylanub>I sometimes mysteriously behave like a robot then question myself. *ijp loads his .44 magnum and blows taylanub's head clean off. <ijp>taylanub: what have you learned? *sneek picks up all the bits and glues taylanub's head back together <ijp>taylanub: github.com/aidalgol/erc-shoot ***linas__ is now known as linas
*tadni_ wonders if Guile will get docstring support, due to guilemacs. <ijp>guile has docstring support <ijp>(define (random) "chosen by fair dice roll" 4) <taylanub>I wish Guile documentation were as consistent as that of Emacs :( <tadni_>Had no idea. Is that in guile's manual? I didn't see skiming it. <ijp>it is mentioned in a few places <taylanub>civodul: it feels like many things lack docstrings, and the usage of texinfo(?) seems inconsistent. *tadni_ is shocked to see that it appears no guile projects are using skribillo for documenetation. <civodul>taylanub: ah docstrings are a problem, yes <civodul>tadni_: this is shocking, indeed ;-) <taylanub>Emacs guidelines for docstrings are also fairly clear, and C-q mostly handles them for one. maybe it would be useful to define clear guidelines for Guile docstrings too <taylanub>err, it actually just handles the line breaking, doesn't it? never mind, I don't know what I have in mind <dsmith-work>Guile docstrings in C and in Scheme are handled differently. <davexunit>I was entirely unaware of skribillo until a week or two ago. <tadni_>davexunit: Yeah, I've been aware of it for awhile. Haven't been motivated to try it out really. I tried once on my GNU distro install and it ended up borking everything due to some weird error with guile-reader. <davexunit>civodul: whoa, didn't realize there was a hardcopy of the guile manual *civodul is proud to have it *taylanub wishes it would automatically update with Guile releases :P *dsmith-work hugs his old paper GNU Make book <byte48>hi, people, good afternoon, i have 25 years old and i search a language for learn, i am not a computist but i want learn a language for contribute to free software ... <byte48>my eyes focus in lisp, common lisp initially, but research i see scheme and now guile, for learn guile your recommendation is read and learn first scheme? <davexunit>byte48: "The Little Schemer" is great for beginners. <daviid>byte48: to start with, this might be easier then sicp: git format-patch origin/devel <byte48>oh fine! great, thanks for recomendations :) <daviid>despite its name, it is an introduction to scheme with strong emphasis on functional programming [as its title says] 