<rlb>mark_weaver: for now, pretend like it's not going to be in jessie. <cluck>tadni: gnu already has two emacsen, mit gnu scheme packs edwin <cluck>it's only fair that guile should pack the better half :) <bipt>cluck, three emacsen, if you count zile ("zile is lossy emacs") *wleslie should definitely try zile at work <cluck>bipt: i refuse to consider zile an emacsen, it's not programmable *cluck *grumpy face* *gtml wavy arm brandishing cane* <rlb>mark_weaver: also planning to remove emacs23 if possible (and *finally* guile-1.6 -- think that's more or less out now) <elzair>Would anyone help me with a programming problem? <elzair>I am trying to define objects that take a name and a variable list of (key values) and store themselves in a specified global object. <elzair>(define-syntax new-object (syntax-rules () ((new-object name value value* ...) (let ((location (cadr (assoc 'loc '(value value* ...))))) (push! location (cons 'name '((value value* ...)))))))) <elzair>However, I keep getting the following error: In procedure setter: Wrong type argument in position 1: #<procedure cadr (_)> <elzair>Do I need to call eval? If so, how? <mark_weaver>looks like you're trying to modify a literal list, which is bad. <mark_weaver>location ends up being bound to a part of '(value value* ...) which is a literal, part of the source code essentially. <mark_weaver>when you modify it, you are actually changing the source code itself (hopefully we will detect this error in the future). <elzair>I am trying to specify an object using the following syntax (new-object test-object (loc objects) (desc "Test Object") (additional properties)) <mark_weaver>shouldn't the second argument to assoc be some global variable instead? <elzair>That was the syntax ZIL used for defining rooms and objects, so I assumed it was good enough. Should I just declare the variables global? *dsmith-work has fond memories <mark_weaver>it might be sufficient to change '(value value* ...) to (list value value* ...) <mark_weaver>that would make it a freshly allocated list instead of a literal list. <mark_weaver>and you might also need the same thing in the second argument to 'cons'. <mark_weaver>(depends whether you'll ever modify the data associated with 'name or not. <mark_weaver>I take back what I said about the "thinko". I didn't understand. <mark_weaver>elzair: also, fwiw, with guile 2 you can use 'define-syntax-rule' in simple cases like this (no syntax literals, only one pattern clause). <elzair>Hmm, I just tried your suggesting to replace '(value value* ...) with (list value value* ...), but now it thinks I want to evaluate the loc and desc properties. <elzair>(define-syntax push! (syntax-rules () ((push! alist obj) (set! alist (cons obj alist))))) <elzair>I actually got it from someone when I asked about this problem on #scheme yesterday. <mark_weaver>have you rebound 'let' or any other core syntactic keywords? <mark_weaver>your initial report sounds as if somehow the expression on the right side of the 'let' for 'location' were ending up in the first argument of 'set!'. <mark_weaver>and I don't see how that could happen unless you were doing something very funny. <mark_weaver>I may need to have a self-contained test case that I can try to reproduce on my end. <elzair>Alright. I am whipping up one now. <mark_weaver>but keep in mind that with your previous code for 'new-object', you'd been essentially modifying the source code literals, and so at this point some things may not be what they seem. <mark_weaver>elzair: another problem with that 'new-object' macro: the 'push!' only modifies the 'location' variable, which is then immediately discarded, so it's essentially a no-op. <elzair>Just (load "world.scm") and call (new-object test (loc rooms) (desc "Test")) <mark_weaver>ah right, changing '(...) to (list ...) is not enough, you also have to quote each subitem. <mark_weaver>btw, you may find the ,expand REPL command useful. type ",expand (new-object ...)" and it will show you what it expands into. <mark_weaver>but you can't really quote each subitem either, because you are wanting to modify those assoc pairs. <mark_weaver>there are several problems here, let me try to implement 'new-object' and show you. <mark_weaver>well, now I'm confused. the 'push!' only modifies the 'location' variable, and that's no good. but what _do_ you want to modify exactly? there's no global variable to modify, it seems. <mark_weaver>also are the operands of 'new-object' after the name always of the form (key value) ? <elzair>Well, I was thinking that an object could be owned by any room or other objects, so I would define an alist for each object and room to put sub-objects in. <elzair>I think the full code for the global objects property would then need to be (define objects '((objects ()))) <elzair>Sorry: (define rooms '((objects ()))') <elzair>I just figured out a problem. You were right, it was a thinko. <elzair>It seems like the original code wants to define a global object but also wantes to store the object inside another. <elzair>It seems like it would be better to just go with global variables and only maintain the (loc property) as a weak reference to what object is currently holding that specific object. <mark_weaver>okay, sounds like you need to do some rethinking and come back, but I want to call your attention to a few guile features that might be helpful here: <mark_weaver>first, make sure you never use '(...) for any substructure that you will later mutate. <mark_weaver>see 'make-object-property' in the manual, may be a convenient way to make your weak map. <elzair>What was that syntax-rule case you mentioned earlier? <mark_weaver>also, if you want these definitions to be added to some local context, then maybe syntax parameters may be useful (see 'define-syntax-parameter') <mark_weaver>'define-syntax-rule' is a convenient shorthand for syntax-rules macros that have an empty literals list and only one pattern clause. <elzair>Cool. Thanks! I will get right on that. <mark_weaver>e.g. (define-syntax-rule (push! v obj) (set! v (cons obj v))) <mark_weaver>(though I'm not sure you'll end up using 'push!' here anyway) <mark_weaver>feel free to come back with more questions when you've got something closer <paroneayea>I'm trying to see how to do this with getops... am I right that the best way is to take the car of the args as the subcommand <davexunit>but yeah, you can take the first option and process the rest with getops <davexunit>iirc, in guix the first option is checked to see if its --version, -h, or --help. if it isn't one of those then we dispatch on the subcommand name <davexunit>thousands of ray-traced spheres at 60FPS? holy hell. <cluck>and all with a functional api/interface <davexunit>this guy is obviously light-years ahead of me, though. <cluck>that playlist is full of gems. so much talent.. <davexunit>cluck: wow moving around the scene within drracket... <paroneayea>davexunit: maybe you could take advantage of emacs' gobject introspect binidngs <paroneayea>if you can embed a x window inside a gtk window... <cluck>davexunit: yeah, that bit really felt like the genera listener <davexunit>paroneayea: might need to wait for the x-widgets branch to get merged, if ever <cluck>paroneayea: you'd need jave's xwidget patches to be able to do stuff like that in emacs <davexunit>a separate window is still alright because I have the REPL server <davexunit>I'm going to see what ideas I can steal from this guy :) <cluck>the code is lgpl v3 so in theory you can take it all *cluck walks away in shame of the lousy pun <davexunit>if I could get a fraction of this performance. <cluck>tbh i think he might be "cheating" a little by only having rendered what's in view, still a scene with that many actors and light sources is impressive <cluck>better have some nice hw too, all those shaders aren't going to render themselves <davexunit>most people don't have cards that support higher. <DeeEff>IIRC the author of this uses OpenGL 3.0 specifically <davexunit>it's not really an option for me to go higher. <taylanub>Ian Grant is stepping on some zones I would call paranoia grey-zones, but I think he's really on to something with the 'semantic fixed-point' idea. if his voice will go unheard and there are no other people out there pursuing the same idea, that would be very unfortunate... <mark_weaver>but if you think he's on to something, by all means I would encourage you to try to work together with him. <mark_weaver>it seems to me that he's been thinking in isolation for far too long. <mark_weaver>he's obviously a smart guy, but even smart guys can lose their way, especially when isolated from others. <mark_weaver>I'd rather the conversation happen somewhere other than guile-devel though. <DeeEff>I would agree strongly on that last point. I don't think guile-devel is where Ian should be discussing issues that may be more pertinent to gcc <mark_weaver>I don't think the GCC devs are going to want to deal with him there either. <mark_weaver>he should probably start his own project to establish his semantic fixed-point, and see if he can attract outside help. <paroneayea>because the package I'm working on, I want to support the full gnu configure/makefile specification, but <paroneayea>I kind of don't want to use automake... doing things like wildcards in makefiles is just so *nice* ***dsmith-w` is now known as dsmith-work
<paroneayea>that and I'm still not sure how all this stuff works or how to figure it out ;) <dsmith-work>A simple makefile (maybe using pkg-config) often is less than 50 lines. More like about q5 <dsmith-work>But add automake, and the thing bloats up to over a meg. <mark_weaver>fwiw, for all people complain about autotools, every build system I've seen that uses something different causes *lots* of problems for anything out of the ordinary, such as for experimental distros such as GNU Guix, or cross-compilation, etc. <rlb>no idea what y'all are talking about -- but yes -- autotools is the only one I know of that handles cross-building deeply... <rlb>(been a pain point in debian lately...)