IRC channel logs


back to list of logs

<please_help>macros can't be used in lambda bodies?
<davexunit>of course they can
<please_help>(lambda (op) (proc-args op) ...) => wrong type to apply `syntax transformer proc-args` where proc-args is generated by define-record-type, what could be causing that?
<davexunit>you must be using proc-args incorrectly
<please_help>I'm using it the exact same way as everywhere else in the code.
<davexunit>I think we'd need to see more context to understand what's going wrong
<mark_weaver>please_help: macro keywords are not "first class" values in Scheme. you cannot pass a macro as an argument to a procedure and have it apply that macro.
<mark_weaver>this is a way in which macros are considerably more constrained than procedures
<mark_weaver>macro expansion is done at compile-time only
<please_help>I'm not passing a macro keyword, the macro is only used as shown above. I'm trying to get a minimal example to reproduce the behavior now
<mark_weaver>that kind of error can also occur if the macro is used before it is defined.
<mark_weaver>unlike procedures, macros must be defined before the compiler expands uses of that macro.
<mark_weaver>that error indicates that the compiler didn't know that 'proc-args' was a macro, and generated code that assumes it will be a normal procedure.
<please_help>I reduced the segment to the minimum without stripping any content from the functions, and it works. The only difference between the not-working and working case seems to be module separation. However, the #:use-module declaration should take care of that, right?
<please_help>wrt proc-args-related code being generated as if it were to be a procedure
<please_help>also, why does it think proc-args is a syntax-transformer when it really is the procedure #<procedure %proc-args-procedure (s)>?
<please_help>I have two modules with the same module separation, but only one of them has that problem, the other works just fine.
<mark_weaver>please_help: is there a cycle in the use-module graph?
<mark_weaver>if there is a cycle, in the module dependency graph, involving the module that defines 'proc-args', that could cause this problem
<please_help>no cycle
<please_help>I just found something even more impossible to understand: where *other-opt* is basically (lambda (op) (proc-args op) ...), and optimize another function, (*other-opt* x) -> OK, (optimize x) [should resolve to the same thing] -> fail. Redefine optimize to (define (optimize x) (*other-opt* x)): (*other-opt* x) -> fail and (optimize x) -> fail.
<please_help>Also the failure condition for the original definition of optimize is that proc-args has a length precisely 2.
<please_help>Here's some real code, maybe it can help: This works perfectly, but as soon as you split the record definitions and optimize in one module and the rest in another, even with correct exports, there's this nonsense behavior.
<mark_weaver>please_help: can you split that small example in such a way that it starts failing, and then paste the code that fails?
<mark_weaver>i.e. a minimal example showing the problem
<please_help> (/1 is the first file, /2 is the second file)
<please_help>so it seems the problem is exporting proc-args. The current version works (tests proc-args). Replace (display (proc-args proc)) with (display (optimize proc)) to make it die
<please_help>stop exporting proc-args to make it work again
<please_help>that's not a good solution though since I need proc-args for other purposes.
<mark_weaver>please_help: I tried your example, with both (display (proc-args proc)) and (display (optimize proc)), and it seemed to work. I didn't get an error anyway.
<please_help>what version of guile? I'm on 2.0.9 still
<nalaginrut>morning guilers~
<please_help>I tried reproducing the test case by simply undoing the latest changes that made the program pass and - surprise! - everything works now. The original case is still as broken as ever before though. I can no longer reproduce the test case, I tried clearing the cache too but to no avail.
<please_help>I know I'm not hallucinating it because I still have the command and output that show without a doubt that I had successfully reproduced the problem too
<please_help>I'll see if a more up-to-date guile solves the problem
<please_help>no, still the same problem even after updating.
<civodul>Hello Guilers!
<lloda>hello, is there a way to set the printer used in backtraces? like repl-print from (system repl common), but for backtraces
<civodul>lloda: i don't think so
<curryiser>in (system vm trap-state) there's a function install-trap-handler!
<curryiser>and trap handler is (lambda (frame idx trap-name) ...)
<curryiser>Oh but it looks like you have to handle the vm trace level if you do that
<curryiser>which is in (system vm vm)
<curryiser>Wait, I dunno
<lloda>ah I see set-exception-printer! in the NEWS, ice-9/boot-9.scm
<lloda>not sure if I need to override the whole thing
<ArneBab>taylanub: do I understand it correctly that this means that r7rs *small* should provide most of r6rs?
<taylanub>ArneBab: not most but some significant parts I guess. e.g. syntax-case can obviously not be implemented in r7rs-small
<taylanub>ArneBab: and some parts will be inefficient compatibility shims, like the fixnums library, unless the implementation supports them "properly"
<taylanub>(or maybe a pure-Scheme fixnum library that merely ensures that it doesn't produce bignums is also useful, dunno)
<ArneBab>that’s strange - I had thought that r7rs-small wanted to create a smaller spec than r6rs…
<ArneBab>but I’m just not deep enough in the process to really understand it
<taylanub>ArneBab: r7rs-small is long done, at 75 pages. these libraries Clinger proposes are to be part of r7rs-large, but some of them can be implemented as libraries on top of r7rs-small.
<ArneBab>ah, ok
<ArneBab>(just found the PDF)
<ArneBab>looking at Appendix A, there are roughly 200 functions in (scheme base)
<ArneBab>and ~⅓ of them are specializations of functions for specific datatypes (list/vector/bytevector/char/string)
<christoph_debian> says threads in guile mode must obey some rules
<christoph_debian>but doesn't reference or mention any
<please_help>I found the problem! <proc> was defined after the *other-opt* function!
<please_help>it sure could use a better error message.
<ijp>master is failing to build for me, I'm guessing wingo might be to blame
<ijp>'s my fault
<dsmith-work>Tuesday Greetings, Guilers
<dsmith-work>ijp: fwiw: master build fine for me over the weekend
<ijp>dsmith-work: my fault, I saved something I shouldn't have
<Tirifto>Not-programmer-yet here! Guile website calls Guile an extension language that can be used with programs. I'd like to ask if it's only suitable for extensions/being an additon to existing programs in other languages (and therefore I'm better off learning some other 'main' language to code in), or if it can function as well as 'normal' languages (Say Common Lisp or Python) for software development.
<ijp>you can use it as a main language
<paroneayea>one thing missing in GOOPS that might be nice
<paroneayea>similar to python having classmethods
<Tirifto>ijp: Thank you~
<ijp>paroneayea: which ones are classmethods? the ones that just use the class as a namespace?
<ijp>oh no, class is first argument, rather than object
<paroneayea>ijp: yeah
<paroneayea>so sometimes they're used as say, "construct an instance from json"
<paroneayea>in my case, I wanted to recursively check parent classes' class properties to build up some result (in this case, I'm defining availabe properties for activitystreams objects)
<paroneayea>but it turns out that in the activitystreams spec, it says "this type inherits all properties from the parent, except for this one field" for one of the classes
<paroneayea>so I wanted to handle that on a classmethod level, but no such concept exists in goops
<paroneayea>but as it turns out, I do also want classmethods for generating from json, etc
<ijp>the concept won't exist, but it will be handled somehow
<paroneayea>ijp: hm?
<mark_weaver>paroneayea: GOOPS classes are just normal objects. the class of a class is called a metaclass. you can define your own metaclasses, and add new slots to them, new methods, etc. see section 8.11 (The Metaobject Protocol) of the guile manual.
<paroneayea>mark_weaver: ah hm! ok!
<paroneayea>mark_weaver: I'll look at it.
<mark_weaver>guile also supports object properties, which allows you to effectively add new fields to existing objects (implemented using a weak-key hash table), which you could use to associate properties with class objects.
<mark_weaver>so there are at least a couple of ways to do this
<paroneayea>mark_weaver: I'm using (fields #:allocation #:each-subclass) as a slot and then (class-slot-set!
<paroneayea>for class properties
<mark_weaver>I seem to recall that unknown_lamer knows a lot about GOOPS and CLOS, so he might have some insight here.
<paroneayea>but not for methods themselves
<unknown_lamer>paroneayea: might be attacking this wrong
<unknown_lamer>paroneayea: check out the initialize generic in the MOP
<unknown_lamer>also allocate-instance
<paroneayea>unknown_lamer: ah ok! will look, thanks!
<unknown_lamer>the GOOPS MOP is not as expressive as the CLOS MOP, but "classmethods" in python sounds like something oyu'd implement using the MOP in guile
<paroneayea>unknown_lamer: cool... I'll try it!
<please_help>did the ffi change between 2.0.9 and git?
<unknown_lamer>customizing part of the class definition protocol would let you do things like removing a slot from one subclass
<paroneayea>unknown_lamer: neat
<unknown_lamer>(although, whether that is a sin or not is open to argument ;) )
<Tirifto>By the way, how much different is Guile from Scheme?
<unknown_lamer>guile implements r6rs IIRC, plus extensions
*unknown_lamer has been hacking SML lately, because of inheriting software writte in it
<ijp>Tirifto: guile implements scheme about as faithfully as any other implementioni does
<Tirifto>So learning Scheme is good/required for learning Guile?
<ijp>I don't see how you can use guile otherwise
<Tirifto>Ah, I see. Thank you very much! :)
<please_help>with the current git version of guile, I get segfaults when using the ffi. No problem on guile-2.0.9.
<please_help>So I have these macros: where expr-bind takes a quoted sexp and a set of let-like bindings. However, I'd like to evaluate the value part of the ((binding value) ...) let-like form rather than adding it literally. I can't seem to make it work right.
<please_help>so basically I'd like to pass a form of type (list (list 'b v)) as an argument to a ck-macro but such that (list (list 'b v)) isn't captured by the macro rather than ((b value-of-v))
<ijp>can you give a concrete example of how this macro should work?
<ijp>it looks just like a flipped let*
<ijp>and will evaluate the right hand sides
<ijp>well, except for the extra quote
<dsmith-work>Wow. Buildroot has guile support! Anyone here submit that?
<dsmith-work>I added that locally a while back but I can't remember submitting it.
<dsmith-work>Pedro Aguilar
<please_help>ijp: I managed to solve it, the macro worked by simply inserting a quoted sexp starting with a let* in front of a given expression, but needed to resolve names at expansion time.
<please_help>the solution was to trick the ck into evaluating a form to yield the quoted expression it expects
<please_help>If I have a guardian g, can (g) (g) yield the same garbage twice?
<ijp>it shouldn't
<please_help>It seems to. If I naively collect garbage and do (displays) of what I'm collecting, the same item is shown several times
<ijp>are you sure it is the same value, and not two similar ones with the same print syntax?
<ijp>could there be a collection in between your calls to g?
<please_help>can garbage collection happen during an after-gc-hook ?
<ijp>depends what the hooks do
<ijp>you probably want to minimise allocation in an after-gc-hook as a matter of course
<please_help>I'm not allocating anything beside a string to display what I'm currently collecting
<please_help>It now seems that it's really doing something asynchronous since despite maintaining a list of already-collected IDs and not processing if the item was already collected, I get the same ID displayed twice in a row still.
<please_help>alright so it doesn't look like a gc problem but "something else": I have (let ((ptr #u64(0))) (call-c-function (bytevector->pointer ptr)) (display ptr) (make-rec ptr)). Despite all displays showing different ptr, observing the <rec> records' ptr shows they end up being the same.
<please_help>also no setters are being used throughout the entire program that I'm aware of
<stis>hej guilers!
<please_help>so it looks like arrays get collected at some point even if I keep a reference to them in a record...