<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> 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>all that's different between them is whether the "docstring" thing gets dumped in there <davexunit>paroneayea: you could write a procedure that encapsulates the 'et' <davexunit>it seems you like you could deduplicate the bulk of that by writing a regular procedure that the macro uses <davexunit>also, this macro looks like it needs a guard clause <paroneayea>davexunit: I don't understand what guard clauses 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... <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 <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 :\\ <davexunit>can you even define a task whose body has more than 2 expressions? <paroneayea>davexunit: that's now how they're defined anyway <paroneayea>davexunit: the task actually takes an argument, a context <davexunit>I see, so you actually use a lambda expression <paroneayea>(let ((my-tasks (task-list (apt-get-update) (apt-get-install "guile")))) <paroneayea>(let ((my-tasks (task-list (apt-get-update) (apt-get-install "guile")))) <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 <davexunit>but you can simplify this to use syntax-rules <davexunit>it would probably be a good idea to write a regular procedure for this wrapper, too. <davexunit>and this define-task macro will just be sugar for it <paroneayea>davexunit: I've tried doing it as in terms of that :\\ <davexunit>the body of the define* form can be extracted <davexunit>the define* itself cannot because of the docstring stuff <davexunit>but you can easily write a procedure that accepts the task-lambda and builds a new task object <davexunit>I think with that, and a move to syntax-rules, you'll be a lot happier with the result. <paroneayea>davexunit: oh :( I forgot that it's not so simple! <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 <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 <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>you can use ,expand at the REPL to verify that the result is the same <paroneayea>it does, but you have to wrap in a lambda and use syntax-case? <paroneayea>davexunit: it doesn't allow docstrings, does it? <paroneayea>I'd like to eventually document that macro well... <davexunit>there's nothing procedural going on in yours <davexunit>so you can use the much cleaner syntax-rules <paroneayea>you can't add a docstring via syntax-rules can you? <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: <davexunit>I wouldn't use syntax-case over syntax-rules just for that <davexunit>syntax-rules is really much more readable for this <davexunit>lol whoever wrote the macro documentation likes the ramones <davexunit>(define-syntax foo (syntax-rules () "docstring here" ...)) <davexunit>define-syntax-rule is just sugar over syntax-rules ***healer` is now known as healer
<jmd`>Does anyone know how to properly use gettext with guile ? <sneek>jmd`, mark_weaver says: my guess is that there's a cycle of references between the "lib" and "out" outputs. ***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>] <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 ***karswell` is now known as karswell