IRC channel logs

2016-10-28.log

back to list of logs

<paroneayea>I still find #:accessor in goops really weird
<paroneayea>(set! (foo-slot foo) 'val)
<paroneayea>seems really not scheme'y to me
<paroneayea>oh
<paroneayea>ACTION reads 6.9.8
<paroneayea>so "procedures with setters"; not just a CLOS utility
<paroneayea>funky
***ft_ is now known as ft
***unCork is now known as Cork
***micro` is now known as micro
<ArneBab_>is there an elegant way to take commandline arguments and directly call them as functions? (essentially take a list of strings, and if a function of the same name exists call the function)
***Kooda_ is now known as Kooda
<amz3>ArneBab_: I looked at solution to build cli and it's not good enough for me, I'd like to port docopt, wdyt?
<amz3>ArneBab_: the answer to yoiur question is no outside eval
<ArneBab_>amz3: I’m not sure - i.e. I like many things about argparse in Python, but it has too much overhead for me.
<ArneBab_>amz3: and eval raised unknown variable errors for me, though I define’d a function of the same name
<ArneBab_>amz3: it should be possible to create a really clean cli specifications with Scheme, but I didn’t see one yet (I also did not check the one from fosdem2016 yet)
<paroneayea>ArneBab_: getopt-long is pretty nice, but it does take some work to set up and understand
<paroneayea>ArneBab_: I use it in pubstrate
<davexunit>I like SRFI-37 for doing CLI stuff
<paroneayea>davexunit: I haven't tried that one; what do you like more about it?
<ArneBab_>amz3, paroneayea: do you have examples of how they look in practice?
<davexunit>the interface is quite nice
<davexunit>args-fold is cool
<paroneayea>ArneBab_: you can look at pubstrate/web/cli.scm and scripts/pubstrate-web.in in pubstrate's repo
<paroneayea> https://gitlab.com/dustyweb/pubstrate
<paroneayea>for getopt-long
<paroneayea>davexunit: cool I'll have to look more
<paroneayea>davexunit: is that what guix uses?
<amz3>ArneBab_: no I don't have an example for eval use
<paroneayea>I noticed "args-fold" and wondered where it came from.
<davexunit>paroneayea: yes
<davexunit>paroneayea: you can also take a look at haunt. I use it there.
<paroneayea>ArneBab_: you could always map an alist of symbols -> procedures and match on the first argument, as a "cheap start"
<paroneayea>davexunit: oh it uses conditions
<paroneayea>common lisp people talk up conditions, and I notice they *exist* in guile
<paroneayea>I would like to understand why they're preferred to other exception type systems
<paroneayea>oh no wait
<ArneBab_>amz3: I mean an example for docopt
<paroneayea>I just opened the wrong srfi :)
<paroneayea>I opened srfi-35
<davexunit>heh
<ArneBab_>paroneayea: that cheap start would be easy, but what I wanted was simply "I pass the function to call on the commandline"
<ArneBab_>and that is surprisingly hard
<amz3>ArneBab_: basically you write the doc string of the application as --help usage string and then it's processed by docopt which returns a dict with the options http://docopt.org/
<ArneBab_>"if a function of that name exists, call it, if not, then raise an error"
<ArneBab_>amz3: ah, I think I saw a presentation of that
<ArneBab_>though I remember that people said that it becomes problematic with corner-cases
<ArneBab_>paroneayea: my use case is: I want to have a script which holds my plot creation tasks. I want to call it like this:
<paroneayea>ArneBab_: you can also use guile's existing -e flag
<ArneBab_>./createplots --any option -- task1 task2 ...
<paroneayea>ah yeah
<paroneayea>ok
<paroneayea>ArneBab_: it feels a bit risky to do that kind of thing
<ArneBab_>and I would like the task definition to have no overhead at all: if I add a new function, it should automatically be included
<paroneayea>you're basically in "eval any input" territory
<amz3>yes... IIRC it doesn't support positional arguments or double dash kind of cli (I don't have example but imagine a cli that does: cmd foo bar baz -a -b -c -- ls -lar)
<ArneBab_>yes
<amz3>(no support for positional arguments means the order of provided option is not kept)
<ArneBab_>paroneayea: or rather, I’m in "run any input which corresponds to a function available in this module which takes no arguments"
<ArneBab_>I could always make define-task which adds to an alist of task names and functions
<ArneBab_>but thas feels inelegant, since Guile should already have that information with a simple define, I just do not know how to access it
<paroneayea>ArneBab_: you could do this:
<paroneayea>scheme@(guile-user)> (define (foo)
<paroneayea> (display "yup yup\\n"))
<paroneayea>scheme@(guile-user)> (let ((input "foo"))
<paroneayea> (eval (list (string->symbol input)) (interaction-environment)))
<paroneayea>yup yup
<paroneayea>it does use eval
<paroneayea>but it would work
<paroneayea>so you'd take "input" from the args
<davexunit>why use eval?
<paroneayea>again, it feels a bit icky to me, but seems like the easiest way to get there
<paroneayea>davexunit: ArneBab_ doesn't want to do a symbol->procedure mapping
<paroneayea>wants to use what's in the environment
<davexunit>modules are first-class
<paroneayea>oh well, I don't know much about them
<davexunit>the guix CLI takes advantage of this
<ArneBab_>paroneayea: that looks like what I tried - I wonder what I did wrong
<davexunit>for example, 'guix build' looks in the (guix scripts build) module for a procedure named 'guix-build'
<davexunit>using module-ref and such
<paroneayea>scheme@(guile-user)> ((variable-ref (module-variable (current-module) 'foo)))
<paroneayea>yup yup
<paroneayea>yeah that works too
<davexunit>module-ref is better
<paroneayea>((module-ref (current-module) 'foo))
<paroneayea>works
<paroneayea>yeah
<paroneayea>so there you go ArneBab_
<ArneBab_>paroneayea/davexunit: nice! thank you!
<davexunit>(module-ref (resolve-interface '(my module)) 'foo)
<ArneBab_>it works! Thank you!
<davexunit>np
<ArneBab_>the minimal version of what I want now looks like this:
<ArneBab_>(define (main args) (map (λ (x) ((module-ref (resolve-module '(createplots)) (string->symbol x)))) (cdr args)))
<ArneBab_>davexunit: getopt-long usage has too much syntax overhead for my taste - not very much, but more than seems necessary to encode the required information
<ArneBab_>^ that should have been for paroneayea
<ArneBab_>davexunit: this part looks really nice: https://git.dthompson.us/haunt.git/blob/HEAD:/haunt/ui.scm#l126
<davexunit>ArneBab_: thanks!
***moby is now known as djose
<rlb>paroneayea: possibly tangentially interesting - clojure has multimethods which are somewhat in the clos direction (and are fairly general), but in part because of the way the jvm is tuned, it also provides protocols, which only dispatch on the first type. For many purposes that's fine, and is much more efficient. Of course, multimethods are always available when you need them.
<paroneayea>rlb: cool
<paroneayea>I'd love to learn clojure some day
<paroneayea>though too bad about the license :\\
<rlb>Well, when I can get back to it, I was poking at providing what I thought were the interesting bits for guile, with a possible eye toward maybe even a clojure/guile dialect (if there were interest).
<rlb>i.e. more guile/scheme appropriate functions, etc. at one level (providing the relevant interesting ideas), that then might or might not be used to build a dialect on top.
<paroneayea>rlb: having more of the nice clojure facilities in Guile would be very interesting
<paroneayea>there seems to be a lot of nice stuff happening over there.
<rlb>I made progress, but got distracted.
<rlb>Current distraction (for this weekend) is trying to fix 2.0.13 on (Debian) powerpc and i386.
<rlb>Single failure only on those architectures in repl-server.test.
<rlb>Does anyone here know if guile might be affected by the -nopie changes. I ask not because I expect that, but just because (with bremner's help) I burned a weekend on that wrt Emacs last week...
<daviid>I personaly much prefer kawa, when I am forced to use java based stuff (imagej mainly), it is scheme, I can even use my grip (part) of, and the interaction with the java class system from kawa is, imo, a lot better
<rlb>wrt the "-nopie" issue: http://git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-25&id=99892eeec8990884ef38601f14038ec6dc227741
<daviid>for info, this post compares ABCL, Clojure and Kawa: https://www.reddit.com/r/lisp/comments/2df2rm/should_my_startup_attempt_to_use_abcl_in_a/
<daviid>and with kawa, no need to study a new ecosystem, fire emacs you're good to go. when your code is ready, 'kawa -D yourfile.scm' -> compiled, the java class file is ready, you're done.
<daviid>from kawa, using third party java libs is easy, using clojure I could not succeed and the folks keep repeating 'daviid to do this you need leiningen ...' terrible! kawa is an order of mag sup to clojure, imo, with all these respect, and it is scheme, full r7rs implementation, the support is the best ever, and the community is nice (clojure people are nice, but a bit condescendent imo)
<daviid>then last but not least, it is a GNU project and gpl (or lgpl) license
<daviid>voilà! :)
<daviid>I recommend guilers who have to interact with java to use kawa
<paroneayea>daviid: interesting
<daviid>paroneayea: tx
<daviid>paroneayea: http://www.alu.org/mop/contents.html
<daviid>for info...
<daviid>paroneayea: I should write a good mop example and patch our manual, the example in the mop section raises an exception :) (and I think it never worked actually)
<daviid>one or two examples, and one example could be your slot-fset ...
<paroneayea>daviid: do it!
<paroneayea>daviid: maybe we should get a slot-fset in guile proper, or something?
<paroneayea>or a metaclass for immutable goops classes
<daviid>paroneayea: yes, but I'd need to seriously study goops implementation first, on my todo list, but i'm overloaded now. but highlevel examples and man patches are ok...
<janneke>daviid: functional goops would be nice
<daviid>paroneayea: before this I want to implement correctly the clos protocol for setters (they are not inherited in goops), and slot inheritance as well, both to me are a lot more important then immut related functionality, especially inheriting setters, because the situation now forces what I consider very bad programing style
<daviid>paroneayea: but yes in the long run fgoops would be really cool!
<daviid>oh janneke, hi! yes it would be really nice
<paroneayea>daviid: what do you mean on CLOS protocol for setters?
<paroneayea>slot inheritance exists, right?
<paroneayea>oh, do you mean this
<paroneayea>(defclass <foo> ()
<paroneayea> (bar #:accessor foo-bar))
<paroneayea>(defclass <baz> (<foo>)
<paroneayea> (bar #:init-value 10))
<janneke>i like the idea of srfi-9 gnu, but i also very much like the conciseness of goops, inheritance
<paroneayea>and then you can't use (foo-bar (make <baz>))
<paroneayea>is thwat what you mean daviid ?
<daviid>setters are not inherited and slot are unless the have the same name
<paroneayea>you need to do
<paroneayea>(defclass <baz> (<foo>)
<paroneayea> (bar #:init-value 10
<paroneayea> #:accessor foo-bar))
<paroneayea>daviid: if you mean something else, could you show an example?
<daviid>paroneayea: the protocol says (in short) let me find a pointer
<daviid> http://www.aiai.ed.ac.uk/~jeff/clos-guide.html#slots
<paroneayea>daviid: right, so what I was saying above, right?
<paroneayea>the accessor is lost
<daviid>this is what stklos and gauche implements, guile decided to divert from the protocol, this is a mistake imo, not a big deal though, just copy paste the slot def and edit it on the subclass
<daviid>paroneayea: in guile, the slot is a new slot
<daviid>it is not 'the accessor is lost', there is just no inheritance
<paroneayea>daviid: yeah that's what I meant :P
<paroneayea><paroneayea> and then you can't use (foo-bar (make <baz>))
<paroneayea>so the answer was, "yes"
<paroneayea>:)
<daviid>ok :)
<manumanumanu>jeez. I hadn't seen the whole Nash thing. That is cool!
<stis>wdyt about my latest macth library > https://gitlab.com/tampe/guile-imatch
<stis>it compiles and runs
***holomorp1 is now known as holomorph
<daviid>stis: "You need to sign in or sign up before continuing..." this site requires login
<stis>why is it not viewable from the outside?
<stis>hmm there is something about visibility
<stis>darn changing the visibility is difficult
<stis>No I found it, heh, simple when you know it. No you can use the link supplied
<stis>see https://gitlab.com/tampe/guile-imatch
<stis>happy hacking!