<rlb>is lalr-scm "reasonable"? <ijp>I guess so, but remember the parsers are stateful, and so new parsers need to be created in a function <ijp>but you'd have figured that out pretty quickly <rlb>ok -- just wondering if it would be a plausible choice for a guile language, or if (as with elisp) it'd be better to "do it by hand" <rlb>(as the elisp lexer claims, for example) <rlb>hmm, though really in this case I'm actually thinking more of the lexer right now, so perhaps not lalr-scm's territory yet <ijp>the emacscript parser is lalr <rlb>pondering idomatic guile for clj-ish: <rlb> (take-while #(not (eof-object? %)) (repeatedly read)) <rlb>I can do it more explicitly -- just wondered if there might have been relevant srfis, etc. since I've been somewhat away from scheme/guile. <rlb>(maybe just a do/cons/reverse! for now...) <mark_weaver>rlb: SRFI-42 (eager comprehensions), which is included in guile, might be worth looking at. <mark_weaver>I've come to think that foof-loop is preferable for many things, but it's not yet included in guile. <mark_weaver>both of them can read from a file as one of the possible generators. <mark_weaver>I plan to add foof-loop at some point, possibly with a slightly improved API for adding new generator types. <mark_weaver>(I don't feel bad about changing the API for adding new generators, because there are already two variants of foof-loop whose APIs differ on that point) *davexunit needs to try out foof-loop sometime <rlb>does guile have anything like clojure's trivial test functions atm? <rlb>just want it to check the guard and then print the expected vs actual values if/when it fails. <rlb>wait -- of course it probably does *rlb goes to refresh wrt the test suite <rlb>user=> (test/is (= (+ 5 2) 13)) <rlb>FAIL in clojure.lang.PersistentList$EmptyList@1 (NO_SOURCE_FILE:3) <rlb>expected: (= (+ 5 2) 13) <rlb> actual: (not (= 7 13)) <mark_weaver>which is included in guile 2.0.11, but the most recent reference implementation also works on earlier versions of guile <mark_weaver>(in fact, we simply use the reference implementation, after I updated it to work well with guile 2) ***jao` is now known as jao
***_zxq9_ is now known as zxq9
<daviid>the [my] problem is that initialize is written in C ... <daviid>note that i verified that in both case (class-slots <clus-text>) is correct and contains the text slot definition, which is a <clutter-text> slot, which comes from clutter [gobject] and is defined like this: (text #:allocation #:gproperty) <daviid><clus-apple> does _not_ have a text slot, so what seems to happen [because the bt point to my gravity.scm module, then prints the error [and does not point to my text.scm module]] is that the slot list is not complete at <clus-apple> initialize method time, it only contains what <clus-apple> has... <daviid>wingo: does what I just wrote make sence? like the instance slots are added while executing intialize methods... <daviid>wingo: I do undertand it's not your cup of tea anymore :) and as you write 'our' near future fantastic compiler, we'll be abble to rewrite goops entirely in scheme, hopefully, one day, but for now your opinion would be very precious, not to say sokme debug time on goops related bugs, or am I dreaming :) <wingo>daviid: does multiple inheritance work with gobject types? <wingo>anyway i don't think multiple inheritance should work with gobject types; dunno <daviid>wingo: well, with all due respect, what you say does not make sence to me [and it works if i revert the order]: (1) (class-slots <clus-text>) returns the exact same and proper slot list in both cases, (2) inheritance is determined by goops, not gobject <wingo>daviid: the problem is that you have a diamond inheritance graph <wingo>gobject doesn't support that kind of inheritance diagram -- so the gtype that is allocated to ClusApple and the gtype allocated for ClutterText can't be used to create a derived type for ClusText <daviid>ah! i thought all happened in goops, i mean in scheme memory... [not sure i am clear here] <wingo>yeah types derived from gobject types get their own gtypes <wingo>which is often what you want but it seems not always what you want :) <daviid>hum, i see, not much we can do then <wingo>e.g. a clusapple that doesn't inherit from clutteractor <wingo>and which is never directly instantiated, only used to "mix in" with other superclasses <daviid>yes, but then all that inherit would have to define the gravity constraints initialization, instead of what is now <daviid>in this updated paste you see that the setter !orientation does manipulate the layout-manager of self... i'd have to write that for every class that inherit clus-apple instead of 1 only ... <daviid>anyway, this is a terrible gobject limitation, but at least it works by inheriting ClutterText first, and I now hope i won't have more complicated inheritance needs in the future :) <daviid>when i write goops code i tend to forget completely that clutter, gnome, ... it all happen in a strage C memory, manipulating C functions ... :) :) <daviid>wingo: i real goops bug is that i have to redefine method for all subclasses for all setter(s) that have been defined at parent level, like in this toolbarmodule extract: http://paste.lisp.org/display/143738#2 quick look at class def then at the end, 3 out of the 4 method should not be necessary <daviid>if i don't redefine, it does raise a bug but nothing happens <daviid>s/it does raise a bug/it does not raise a bug <lloda>wingo, how do I do arithmetic with labels? like (static-patch! ,label 3 ,(+ label 4)) I guess. Here (+ label 4) should be (scm_t_array_dim *). <lloda>well I don't really want an asm label, but an actual C pointer. But the pointer should point at label+4. <davexunit>Profpatsch: it's a reference to a Kurt Vonnegut book called "Cat's Cradle" <Profpatsch>davexunit: It’s the general guile namespace, right? <Profpatsch>Now that I know about that, finding it on page 762 of the manual. :) <Profpatsch>Might be worth mentioning it when it’s first introduced. <Profpatsch>That it is the name of the guile namespace, that is. ***jao` is now known as jao
<daviid>wingo: 'biab', which of course means 'be in a bath', man, you take very long bath :) :) [needed to relax a bit... haha]. seriously, it would be nice if you could have a look and debug the getters/setters/accessors problem pasted here above. as it is now, it makes goops difficult to use [and trust] when playing with large scale s/w like guile-gnome, guile-clutter ... [and I beleive impossible to use for a beginner] <richi235>Hi, im using the command line repl of guile 2.0.9 <richi235>And I want a colored promt like in my BASH or zsh <richi235>and the official doku seems to use the term "prompt" very frequently and also for something else <janneke>richi235: geiser colors your prompt... <taylanub>mark_weaver: FYI David Kastrup seems a little bitter about the way http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17485 was handled. I'm responding to a mail of his on emacs-devel; was that bug report "abandoned" for now, or is it because you were too busy?.. He wrote "the proposed fix is rejected, but no alternative fix is done" and I thought that might be painting a wrong picture of the <mark_weaver>David Kastrup is totally unwilling to compromise on anything in my experience. We disagreed and he's unhappy that I didn't like his solution. <mark_weaver>I should note that wingo banned David from posting to guile-devel because he was so abusive and insulting. <mark_weaver>I'm not aware of anyone else ever being banned from guile-devel. <ijp>richi235: there is no easy way to change the prompt <mark_weaver>well, wingo asked him not to post anymore to guile-devel, and he decided to comply with that request. <mark_weaver>funny thing is, I initially sympathized with david, and talked to him privately about trying to get the decision reversed if he would just try to be less insulting, but he was totally uninterested in even trying. <mark_weaver>and since then, he and I have had a number of unpleasant interactions on the bug tracker and he seems to hate me now too. <ijp>richi235: actually, tell a lie, look for repl-default-prompt-set! in (system repl common) <ijp>maybe it is using the other meaning of prompt <mark_weaver>well, "hate" might be too strong a word, but still.. <ijp>ah no, it expects a function <taylanub>oh well. I'll respond to some of the points he raised because he's painting a rather bad pad picture of Guile on emacs-devel, but I guess I should be careful not to ignite worse responses... <ijp>richi235: ,option prompt (const "asdf> ") works at the repl, but repl-default-prompt-set! fails, not sure why yet <mark_weaver>taylanub: david will just keep responding, and it will turn into a huge thread. might be better to let it lie for now. <ijp>(the procedure is unnecessary to the repl command, you can just use a string, but I did it as a procedure because it should have worked for the function) <ijp>default options are copied when the repl is made, not referenced directly <ijp>but that means ^^ should work in a .guile <taylanub>mark_weaver: hm, I think responding at least once would be appropriate, to make people realize there's emotions involved rather than let them get the impression that Guile is badly maintained abandonware. for people on emacs-devel who aren't otherwise familiar with Guile. <ijp>richi235: the function gets a repl as an argument, which is how the default one figures out the language, see repl-prompt in system/repl/common.scm if you are interested <richi235>with "the function" you mean "repl-default-prompt-set" ? <ijp>richi235: no, the function which is given as an argument to repl-default-prompt-set <richi235>ahh i understand, so with ,option prompt you define the function which is given to repl-default-prompt-set per default ? <mark_weaver>taylanub: David is a very aggressive arguer, and often fairly convincing. <ijp>richi235: no, there are two different interfaces <mark_weaver>taylanub: I have my doubts that you'll be able to respond effectively. <richi235>but since im learning scheme atm im interested in the inner workings <ijp>while at the repl, you can change your prompt with ',option prompt \\"foo\\" ' <richi235>all commands starting with , are repl specific ? <ijp>but ,commands won't work in a guile <ijp>from a .guile, you would use the (repl-default-prompt-set! (const "foo")) for a string <ijp>a convention for mutators <ijp>remember to (use-modules (system repl common)) in your .guile first <richi235>the path you mentioned before (system/repl/common.scm), i'm on debian, do you mean /usr/share/guile/system..... ? <richi235>i will try arround a bit and ask again if i can't figure it out <davexunit>"Emacs Lisp's future (was: Guile emacs thread (again))" <davexunit>in which Stefan Monnier seems to doubt the feasibility of guilemacs <richi235>ijp: thank you, now i got a colored prompt inside and outside of emacs :) <richi235>ijp: if i have questions during learning scheme/guile, is this the right channel to ask? <taylanub>davexunit: we just talked about that with mark_weaver :) apparently David Kastrup has a bit of a thing against Guile, and the best thing is not to respond because he will probably just become worse <davexunit>fighting for software freedom is already an uphill battle, and it seems that guile has another uphill battle to fight to convince people that it's a serious project. <richi235>davexunit, taylanub : it's interesting to see that you also have problems with personal opinions and human/social stuff <richi235>This seems to be very common in many open source projects^^ <taylanub>richi235: I'd say, in this case, it's one person being a problem, and the others trying to deal with that problem... <davexunit>a lot happens when I'm on my home from work! <davexunit>well, I hope things go well between the guile and emacs communities in the future. I'd really like to see guilemacs make it to mainline. <rlb>(may be an issue for the arm porters, but thought I'd ask)