IRC channel logs


back to list of logs

<Profpatsch>How do I set options in .guilerc?
<Profpatsch>Ugh, I just now discovered the line that says it.
<nalaginrut>morning guilers~
<artyom-poptsov>Hi nalaginrut
***ldthien0 is now known as anon4422
<civodul>Hello Guilers!
<janneke>Hi civodul!
<civodul>hey janneke
<dsmith-work>Hey hey
<lloda>hey wingo, segfault on master if you load this from a file:
<lloda>but if you enter the lines in the REPL, no problem.
<lloda>this is what happened with my patches, so I really think that those are fine and the reason is the read-only data.
<lloda>but I don't understand why loading would be different than the REPL. Doesn't the compiler get used in either case?
<wingo>lloda: interesting story there :)
<wingo>let me dig up a link describing the reason
<wingo>lloda: from the repl, the elf image is #:page-aligned? #f
<wingo>lloda: files are #:page-aligned? #t
<wingo>so constant literals are only properly read-only in page aligned files
<wingo>properly read-only == the page is not writable
<lloda>but thanks; I'll waste less time debugging now.
<lloda>is it worth it to file a bug about this? you know the problem of course
<wingo>lloda: probably the right thing to do is to turn the segfault into an exception -- you'd still get the difference though
<lloda-2>exception looks good for the segfault
<lloda-2>but I find the different behaviors confusing, also between the interpreter and the compiler...
<lloda-2>I know the read-only thing has come up before where people write to a list literal without diagnostic and that causes bugs later on
<stis>evening guilers!
<paroneayea>I'd love to do (some-class init-parameters-here) to init the class, rather than (make some-class)
<paroneayea>though I guess if I wanted to make that happen, I should probably write a macro like
<paroneayea> - define the class with <> wrapped around the name
<paroneayea> - make some-class be a lambda that calls <some-class> with remaining args
<mark_weaver>I have sometimes defined my own custom constructor procedure, outside of goops, that calls 'make', etc.
<mark_weaver>unknown_lamer or daviid might have some opinions on this, as they have more experience with CLOS/GOOPS.
<daviid>mark_weaver: be with you or who ever would like some info/help in a little while, busy with another task now but will be happy to help
<paroneayea>the reason for this is I'm playing on the side with writing a mini DSL that probably would use GOOPS for deployment (so that it can track state/results there)
<paroneayea> something like this
<paroneayea>I figure it would be nice to be able to have this be classes so that it can store additional data like dependency ordering, etc
<paroneayea>so add-user would probably actually be calling (make <add-user> ...)
<davexunit>paroneayea: yeah, just write a wrapper around make.
<paroneayea>so I guess I'll make a macro to construct the wrapper and the class simultaneously.
<paroneayea>that's what I was doing, though was kind of struggl8ig to learn define-syntax stuff :)
<paroneayea>I'm used to defmacro in other languages, and I know that exists here, but
<paroneayea>I should probably learn how to do it in a guileish manner
<davexunit>gotta go. interested in where this goes.
<mark_weaver>defmacro has lots of problems with inadvertent name collisions. the modern hygienic macros are far superior
<paroneayea>mark_weaver: yeah, I'm getting that sense
<paroneayea>it's just new stuff, so trying to wrap my brain around it
<mark_weaver>the macro you're proposing would need to create a new identifier based on the one given by the user, which is not hygienic, so you'd need to use 'syntax->datum' and 'datum->syntax' to make it unhygienic in the way you wish.
<paroneayea>I think that's where I was getting stuck :)
<paroneayea>I'll look at that
<mark_weaver>personally, I probably wouldn't bother with a macro for this, but if you want to, you'd want something like this:
<paroneayea>(I guess run-tasks could actually do all the construction itself...)
<mark_weaver>(define-syntax my-define-class (lambda (form) (syntax-case form () ((_ constructor-name <blah blah>) (with-syntax ((class-name (datum->syntax constructor-name (symbol-append '< (syntax->datum constructor-name) '>)))) #'(begin (define-class class-name <blah blah>) (define (constructor-name . args) <blah blah>)))))))
<paroneayea>mark_weaver: hey thanks!
<mark_weaver>of course, you'll want to paste that into an editor and insert newlines and indent properly.
<mark_weaver>but keep in mind that there are disadvantages to doing this. if someone is searching for code for <your-class>, that won't help them to find the class definition, because that identifier is not in the source code for the class def'n.
*paroneayea nods
<paroneayea>makes sense
<mark_weaver>oh, sorry, there's a mistake in that code. (syntax->datum constructor-name) should be (syntax->datum #'constructor-name)
<paroneayea>okay... I'll think some more about this... maybe there are some nicer ways to pull this off.
<paroneayea>mark_weaver: okay... thank you! I will play with this.
<paroneayea>maybe there's a more functional way I could pull this off
<paroneayea>I'll think about it
<paroneayea>might make sense if (add-user) and friends actually return some kind of structure with a curried function, or something
<paroneayea>though... at that point I guess it's back to oop anyway
<mark_weaver>another mistake: the "constructor-name" right after "datum->syntax" also should be changed to "#'constructor-name"
<mark_weaver>the simple solution is simply to include both the constructor name and the class name in the macro call.
<paroneayea>mark_weaver: you mean, keep the (make)s? :)
<paroneayea>certainly easier I guess, just less pretty...
<mark_weaver>no, I'm saying that instead of automatically constructing "<class-name>" from "class-name" in your macro, have your macro accept both of those identifiers as operands.
<paroneayea>oh I see
<mark_weaver>then it could be a purely hygienic macro
<paroneayea>that is easier I suppose
<mark_weaver>which has lots of advantages, some of which might not be immediately obvious
<mark_weaver>and you could use the super-simple 'define-syntax-rule' syntax to define the macro
<paroneayea>mark_weaver: okay, I'll just do that for now, thanks
<mark_weaver>you're welcome!
<paroneayea>mark_weaver: sorry, dumb question... any idea why I'm hitting this error?
<mark_weaver>paroneayea: the ... after 'class' indicates that the 'class' pattern variable could be bound zero or more datums. then, every occurrence of 'class' in the template has to have '...' after it as well.
<mark_weaver>(though the '...' doesn't have to be immediately after 'class')
<mark_weaver>paroneayea: I guess you expected '...' itself to match some set of stuff, but rather it's a kind of modifier of the thing preceeding it.
<mark_weaver>paroneayea: also, instead of (apply make (cons class rest)) you can simply do (apply make class rest)
<paroneayea>mark_weaver: ah, okay!
<mark_weaver>paroneayea: but I guess the fix is in come up with another name for the things after 'class', and put that chosen name before the two occurrences of '...' in your macro. the name should reflect the things being matched there.
*mark_weaver goes afk for a bit...