IRC channel logs

2015-04-05.log

back to list of logs

<FracV>Is there somewhere I can get info on how to use ,profile?
<FracV>I've been using ,time and ,trace for a long time but I've never actually known what to do with ,profile
<daviid>FracV: not exactly answering your quizz, but I'd take a look at section 7.19 7.20 and 7.21 of the manual
<FracV>daviid: Cheers, I was just reading those actually
*paroneayea reading the metaobject protocol part of the guile docs
<paroneayea>okay, I like GOOPS a lot more than I thought I did :)
<paroneayea>hm
<paroneayea>how to do something like this
<paroneayea>(function-name (define (foo) 3)) => 'foo
<paroneayea>is there a way?
<paroneayea> http://pamrel.lu/822ef/ so I still can't figure out how to homogenize the bottom version of this (which is same as the top verison, but with support for optional docstrings) into not having such code duplication
<paroneayea>there must be a way!
<paroneayea>I know I'm missing something obvious.
<paroneayea>all that's different between them is whether the "docstring" thing gets dumped in there
<paroneayea>ohhh!
<paroneayea>maybe ,@
<paroneayea>will work
<davexunit>paroneayea: you could write a procedure that encapsulates the 'et'
<davexunit>let*
<paroneayea>davexunit: hurm? :)
<davexunit>it seems you like you could deduplicate the bulk of that by writing a regular procedure that the macro uses
<paroneayea>davexunit: oic.
<paroneayea>hmmm
<davexunit>also, this macro looks like it needs a guard clause
<paroneayea>davexunit: I don't understand what guard clauses do :)
<paroneayea>but it works as-is?
<paroneayea>what would the guard clause do?
<davexunit>well, it looks like, in the current state, the first case will only be used when the task body is a single expression
<paroneayea>davexunit: the only difference between the first and second cases is if there's a docstring...
<paroneayea>ie:
<davexunit>in fact, a single case might be enough here, because the lambda* macro handles that
<davexunit>paroneayea: but you haven't written a macro that expects a string literal for doc
<paroneayea>davexunit: oic, right, someone could put a non-string there
<davexunit>looks like this could be a syntax-rules macro
<davexunit>with a single rule
<paroneayea> http://pamrel.lu/92262/
<paroneayea>that's all that case does, is switch between those two
<davexunit>but in this case, there's really no difference
<paroneayea>and right, the simpler reference version above it is syntax-rules, I'd love to keep it simple and syntax-rules'y, the main issue is the docstring :\\
<paroneayea>oh?
<davexunit>can you even define a task whose body has more than 2 expressions?
<davexunit>(define-task (foo bar) (one) (two) (three))
<paroneayea>davexunit: that's now how they're defined anyway
<paroneayea> http://pamrel.lu/92262/
<paroneayea>davexunit: the task actually takes an argument, a context
<paroneayea>because tasks are like this
<davexunit>I see, so you actually use a lambda expression
<paroneayea>(let ((my-tasks (task-list (apt-get-update) (apt-get-install "guile"))))
<paroneayea> (run-task my-context))
<paroneayea>oops
<paroneayea>damn
<paroneayea>(let ((my-tasks (task-list (apt-get-update) (apt-get-install "guile"))))
<paroneayea> (run-task my-tasks my-context))
<davexunit>okay, but more still needs to be done to determine that 'doc' really is a string literal
<paroneayea>because there's a context that's passed between things
<paroneayea>davexunit: that seems like a nice idea
<davexunit>well, I guess not...
<davexunit>define* will throw if it isn't
<davexunit>so it's already done the hard work
<paroneayea>yeah
<davexunit>but you can simplify this to use syntax-rules
<paroneayea>davexunit: the tricky part of this
<paroneayea>is that the task doesn't run on instantiation
<paroneayea>it gets "called" later, kind of a custom force
<davexunit>yeah I see
<paroneayea>delay/force
<paroneayea>but extra metadata is kept
<davexunit>it would probably be a good idea to write a regular procedure for this wrapper, too.
<paroneayea>hence why it gets stuck in a task struct
<davexunit>and this define-task macro will just be sugar for it
<davexunit>that way there's still a programmatic API
<paroneayea>davexunit: I've tried doing it as in terms of that :\\
<paroneayea>I guess I haven't figured out how!
<paroneayea>there's probably a good way
<paroneayea>I just can't figure it out
<paroneayea>this is the only macro in opstimal :)
<davexunit>the body of the define* form can be extracted
<paroneayea>that can be done, yeah
<davexunit>the define* itself cannot because of the docstring stuff
<paroneayea>right
<paroneayea>hm okay, I'll give that a try
<davexunit>but you can easily write a procedure that accepts the task-lambda and builds a new task object
*paroneayea nods, true
<davexunit>I think with that, and a move to syntax-rules, you'll be a lot happier with the result.
<davexunit>:)
<paroneayea>okay, will try, thx davexunit :)
<paroneayea>davexunit: oh :( I forgot that it's not so simple!
<paroneayea> http://pamrel.lu/9ed24/
<paroneayea>davexunit: the trouble is the (lambda* (. args) part of http://pamrel.lu/822ef/
<paroneayea>that part actually expands out the (. args) in the macro
<paroneayea>so that it's able to fill out the arguments of the lambda that's built
<paroneayea>there's probably a way around it...
<davexunit>well, you could pull that part out of the procedure, and just accept an argument with the right thing
<paroneayea>I could, though at that point it does tart to result in a significant amount of duplicate code again in the cases of syntax-rules
<paroneayea>*does start
<davexunit>it would deduplicate a bunch still...
<davexunit>alternative: make one form of the macro a special case of the other
<davexunit>for example, the version without the docstring can be defined in terms of the version with a docstring
<davexunit>where the docstring is the empty string
<paroneayea>hm, ok..
<paroneayea>arg, I still don't get how to do it... hm.
<paroneayea>maybe let-syntax can do what you say above.
<davexunit>lemme cook up a contrived example
<davexunit>paroneayea: http://paste.lisp.org/display/146795
<paroneayea>davexunit: ohhhhh I see
<paroneayea>that's clever.
<paroneayea>davexunit: I think that will work
<paroneayea>thank you :)
<davexunit>you can use ,expand at the REPL to verify that the result is the same
<davexunit>yw!
<paroneayea>hm, define-syntax doesn't support a docstring?
<paroneayea>that's... strange
<paroneayea>oic
<paroneayea>it does, but you have to wrap in a lambda and use syntax-case?
<paroneayea>davexunit: https://gitlab.com/dustyweb/opstimal/commit/5fd041a02748df6ee8220164439e1e7669e1f69a :)
<paroneayea>4 additions, 43 deletions
<davexunit>paroneayea: nice!
<davexunit>now, syntax-rules! :P
<paroneayea>davexunit: it doesn't allow docstrings, does it?
<paroneayea>else I'd switch it :)
<paroneayea>I'd like to eventually document that macro well...
<davexunit>sure it does
<paroneayea>doeeeessss it? :)
<davexunit>syntax-case is for procedural macros
<davexunit>there's nothing procedural going on in yours
<paroneayea>davexunit: I mean
<davexunit>so you can use the much cleaner syntax-rules
<paroneayea>no, I know that :)
<davexunit>oh
<paroneayea>different docstring question
<paroneayea>you can't add a docstring via syntax-rules can you?
<paroneayea>to the macro.
<paroneayea>it doesn't support it afaict
<davexunit>syntax can't meaningfully have docstrings
<paroneayea>davexunit: http://pamrel.lu/cec1f/ errors out
<paroneayea>davexunit: but macros can
<davexunit>macros == syntax
<paroneayea>macros can have docstrings :P
<paroneayea>lots of macros have docstrings in guile!
<davexunit>I dunno then
<davexunit>I'm sure you can do it somehow
<paroneayea>or am I wrong???
<paroneayea>maybe they don't have docstrings
<paroneayea>now I'm checking a bucnh of them and they don't have docstrings!
<paroneayea>davexunit: anyway, the current way I'm doing it:
<paroneayea>has a docstring, and geiser shows it :)
<paroneayea>in fact!
<davexunit>I wouldn't use syntax-case over syntax-rules just for that
<davexunit>syntax-rules is really much more readable for this
<paroneayea>(define-syntax-rule)
<paroneayea>has a [docstring] space!
<paroneayea>of course I need rules, not rule
<paroneayea>I agree it's more readable
<paroneayea>I just really like docstrings.
<paroneayea>document all the things!
<davexunit>lol whoever wrote the macro documentation likes the ramones
<paroneayea>:)
<davexunit>(define-syntax foo (syntax-rules () "docstring here" ...))
<davexunit>there
<davexunit>docstring
<paroneayea>does that work?
<paroneayea>I thought I tried that.
<paroneayea>I guess it does!
<paroneayea>davexunit: okay, thanks
<davexunit>cool
<davexunit>define-syntax-rule is just sugar over syntax-rules
<davexunit>so I knew it *must* handle docstrings
<paroneayea>:)
<paroneayea>okay, now it's using syntax-rules
<davexunit>cool
<paroneayea>thanx again for your help davexunit :)
<davexunit>np!
<paroneayea>that was long bothering me :)
***healer` is now known as healer
<jmd`>Does anyone know how to properly use gettext with guile ?
<sneek>jmd`, you have 3 messages.
<sneek>jmd`, mark_weaver says: the same problem started happening with gccgo at some point, probably when some of gcc was split into a "lib" output. see http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18101
<sneek>jmd`, mark_weaver says: my guess is that there's a cycle of references between the "lib" and "out" outputs.
<sneek>jmd`, mark_weaver says: I fixed gccgo, and hopefully made it easy for you to produce a working gcj package. See http://git.savannah.gnu.org/cgit/guix.git/commit/?id=c4df90a594672042ae106730ab5ce07fe85cf46f
***jmd` is now known as jmd
<jmd>I have: (gettext "_~A" 8)
<jmd>which seems to produce a correct .pot file.
<jmd>But results in In unknown file:
<jmd> ?: 0 [gettext "_~A" 8 #<undefined>]
<jmd>at run time.
<taylanub>jmd: gettext doesn't seem to take a format string, does it?
<taylanub>maybe (format (gettext "_~A") 8) is the right way. that's how I'd be doing it in Objective-C with NSLocalizedString, not sure if gettext has more features.
<jmd>taylanub: Yeah. You're right. I made a thinko
<taylanub>:-)
***karswell` is now known as karswell