<richi235>Profpatsch: it's "Guile Reference" in Emacs don't know why *davexunit flails with utter confusion and disbelief <joolean>although I bet it'll be cool and exciting to watch the FSF "fall down around [our] ears." <joolean>there'll probably be explosions and stuff <davexunit>I'm at the FSF office most days, and it's still quite sturdy. <davexunit>yup, we get fed and watered a few times a day <joolean>what about the violent, periodic raids from the EFF and ACLU <ijp>the straw gets changed twice a week, and the wheel checked once a month <joolean>stacks of amicus briefs going up in flames <davexunit>joolean: do you remember that katana that was sent to RMS? I need not say anything more. <ijp>the US just lets you post swords? <joolean>davexunit: offtopic, but: I remember you having an interest in 2d rendering. I wonder if you've ever played with Clutter (via guile-clutter or C) in the context of game development <joolean>It's quite nice and has a featureset that's roughly comparable to Flash <davexunit>joolean: I think a scene graph is useful, but I'm not really interested in clutter <davexunit>I'm writing a pure scheme game engine with 2d and 3d rendering. <daviid>with a variable l3 being a ClutterText instance, if I call (set-markup l3 "<span foreground=\\"Red\\">Hello red world!</span>") from a spawned server it segfault saying: Pango:ERROR:/tmp/buildd/pango1.0-1.36.7/./pango/pango-layout.c:3916:pango_layout_check_lines: assertion failed: (!layout->log_attrs) <daviid>this does not happen if I use set-markup from the app code, like doing it as clicking the right button onthe stage <daviid>I am facing an unexpected clutter behavior with respect to text, that leaves me perplex, and for which I wonder how I could possibly track the problem down. <daviid> here is the problem: I create (1) a <clutter-text> [core clutter gobject] ClutterText] and (2) a <clus-text> [a goops class of mine based on ClutterActoe] and both change their markup text upon a right click on stage, like <daviid>first time i click (set-markup l2 "<span foreground=\\"Red\\">Hello red world!</span>") [l2 is the ClutterText instance] <daviid>and the same for l3, with l3 my <clus-text> instance. <clus-text> holds and handle a ClutterText instance has its child [because I nedd to for other characteritics] and therefore redefine the core method as this: <daviid>(define-method (set-markup (self <clus-text>) text) <daviid> (let ((clutter-text (get-first-child self))) <daviid> (set! (!text self) (get-text clutter-text)))) <daviid>now on first rightclick both change their text, but only the ClutterText instance gets the right colour, on seconf click [which just changes the color], the ClutterText is sync, the <clus-instance> then updates with the colour specified in the first rightclick source code ... <daviid>both instance execute the same code: <daviid>and both show the right text upon click, which as the code above shows, do ask for a span with the apropriate colour <daviid>then all happens as if the text is updated, the colour 'saved' <daviid>for the <clus-text> instance, and clour executed for the ClutterText instance <daviid>I wonder how I could possiblky track this down? on the screen I see both text, the ClutterText instance is the text i the right colour, the <clus-instance> is the right text with the colour of the previous click <daviid>is this the Thomson Virus? haha [could not resist] <dsmith-work>Whoo. Got my ADC inputs working. Poor docs from Microchip. Bah. <dsmith-work>Is anyone going to be a AutoTest in St. Louis tomorrow? <Fuuzetsu>Is someone going to sort that Ian Grant person out? <daviid>this clutter problem drives me crazy! I can't possibly accept "Hello red world!" written in white :) and it's not very good for our guile-clutter reputation either :) <ijp>communism is dead daviid, time to move on <daviid>yes! but the green comes in red, the blue in green, and then it cycles, nothing white anymore [except, another funny side effect, that when using the red colour, the last 2 letters are white, which does not happen with the blue neither the green] ... <daviid>how come thet it changes the text but span with the previous colur? <davexunit>Fuuzetsu: I don't think you can reason with him. mark and ludo both tried and still he writes long winded, confusing emails. <Fuuzetsu>I certainly don't plan to reason with him. <rlb>ok, could someone remind where the scheme persistent data structures project is? <rlb>oops -- sorry, I mean immutable persistent, not storage persistent <rlb>i.e. clojure-ish map/set/list/vector... <rlb>it was pointed out to me a bit back, but I'm just finally getting to the point where I might need it <mark_weaver>rlb: you might be thinking of ijp's pfds library (purely functional data structures) <mark_weaver>guile core also includes vlist and vhash data structures <lloda>wingo, I've seen that bytevectors.h also assumes sizeof(ssize_t)==sizeof(void *). (e.g. SCM_BYTEVECTOR_LENGTH). given that, it seems a bit pointless to avoid the assumption elsewhere. would you accept yesterday's patch if I just add a verify() ? <wingo>lloda: doesn't that assume that sizeof(size_t) <= sizeof(scm_t_bits) ? <lloda>right. But it's the same for using words for ssize_t in the array SCM, isn't it? or is there a signed<->unsigned conversion issue? <wingo>in the array SCM they are referenced in a struct dim { size_t, size_t, size_t } which could be packed in different ways <wingo>(signedness is not the issue here) <lloda>ah ah, right you are. sorry then. <wingo>just add a verify() that sizeof scm_t_array_dim is 3 * sizeof(scm_t_bits) <wingo>i don't think the verify holds on all platforms, but it's easy enough to fix, and it will be an early bug for those people <lloda>if that's ok for you, it is for me, too. will do. <lloda>I also wonder, if I used scm_gc_alloc directly, would I need the volatile/remember_upto thing that scm_words does()? <wingo>lloda: well since you're returning the value and not destructuring an argument, there's no issue -- the value must be live <lloda>hello civodul. wingo, is there an example of that destructuring somewhere? scm_i_make_array is alloc + set some words + return, which is exactly what scm_words does afaics. <lloda>anyway I don't hope to grok gc on irc, I rather don't waste your time with this. *wingo looks at scm_words <lloda>so I tried master with our internal code and I get segfaults. but then I saw that the compiler isn't actually exercised in most of the test suite, so I think that should be done first before I worry about having bugs in my code. <lloda>yeah, you told me 'use scm_gc_alloc' and I didn't dare <wingo>civodul: we're talking about fusing some allocations in arrays <wingo>and now looking at initialization <wingo>and wondering whether a barrier was needed like the one in scm_words; i'm trying to convince myself that scm_words shouldn't need that barrier <wingo>and that terrible comment about strict aliasing <lloda>only when scm_words is inlined, right? so for doing scm_gc_alloc in a function that shouldn't matter. which is what you said. <wingo>i guess that's right. but i want to inline too! thinking about that problem. <wingo>there are scary harmful comments in gc.h :( <civodul>but if everything is an SCM, everything can alias anyway, no? <wingo>those functions take scm_t_bits as args <wingo>and access the words as scm_t_bits <wingo>and really, there's a lot of casting going on and i don't know what the implication is <civodul>well, at some point scm_cell should be changed to take SCMs instead <wingo>e.g. ((struct foo*) SCM_WORD_2(x)) <wingo>which is totally legit from guile's POV, and it is incorrect to represent that value as a SCM <civodul>so you were looking to remove the indirection in scm_i_make_array, for instance? <wingo>or keep the indirection if needed (probably not), but fuse the allocations <civodul>i don't think there's much to worry about here <civodul>this is done for vectors and bytevectors <wingo>i think the hazard is if you use scm_words() then re-initialize word 0 using some other pointer <wingo>e.g. SCM x = scm_words (0, 2) <wingo>(struct foo*)(SCM_WORD_0_LOC (x)) = bar <wingo>then the initialization of word 0 to 0 and setting it to bar could be interchanged <wingo>because the location is first accessed as a (scm_t_bits*) and secondly as a (struct foo*) <wingo>and the compiler says "hey, that means these locations can't be the same" <civodul>i think it's better to not use scm_words here <wingo>civodul: sure, just trying to understand the issues :) <lloda>ok, so the segfault I had with master is b/c of writing over an interned array. Those are read-only I imagine but I don't think there's any kind of check. We need one. <wingo>lloda: how did it segfault? you would think that it would change the shared value but it wouldn't segfault <wingo>or was it a segfault due to permissions of the page... <wingo>yeah agreed wrt warnings, but not sure how to do it -- ideal is actually via sigsegv handler <wingo>that's probably doable actually... <wingo>check the address that's being accessed, and if it's in a mapped elf image but a read-only section, then raise some error <wingo>otherwise delegate to the next sigsegv handler <lloda>this is with guile-ploy, which is in Gitorious. No C, just Scheme. <lloda>the segfault is in (define r1 #f64(0 0 0)) <lloda>(array-map-rows-1! r1 v-norm #2f64((1 1 1) (2 2 2) (3 3 3))) <lloda>this writes to r1. If I replace r1 by (array-copy #f64(0 0 0)), all is good. <lloda>bottom of the stack is scm_bytevector_ieee_double_native_set_x <lloda>I don't know if it's permissions, I can't get it to happen at will. <lloda>I mean scheme@(guile-user)> (array-set! a 9 0 0) <lloda>$1 = #2f64((9.0 2.0) (3.0 4.0)) <lloda>it might be a problem with my patch. It's weird. <lloda>sorry, after [12:22] scheme@(guile-user)> (define a #2f64((1 2) (3 4))) <bipt>(an update on guile-emacs for the recent emacs-devel thread, of course) <taylanub>it stresses much better a point I seem to have failed to make: first and foremost it will make Elisp a lot greater <bipt>taylanub, thanks. i always worry that i'm not explaining things in a way that makes sense to someone not deeply immersed in the project <taylanub>hm, I'm also a bit deeper involved than the lay Emacser I guess <taylanub>The nil/#f/() issue is a little difficult to explain every time <bipt>yeah, i was about to add that i didn't mean to imply that (: i noticed that you've done quite a bit of PR work on reddit and elsewhere, so have more experience explaining it to random people <taylanub>but your text seems fine when I look at it from a lay perspective too <wingo>my only qualm is that you give me too much credit for "supervision"; i am the sloppiest mentor ever ;) <wingo>but whatever, it sounds great to me <bipt>User-Agent: Gnus/5.13 (Gnus v5.13) Guile-Emacs/24.4 (gnu/linux) ^_____^ <davexunit>bipt: yay! thanks for posting in that thread. reading now... <davexunit>bipt: great post. I hope this can quell some of the arguments and outrage that have occurred. <ft>I'm sure that trolls will be trolls, though. :) <civodul>bipt: does Guile-Emacs work with 2.0? <bipt>civodul, not at present. it wouldn't be terribly difficult to port it back though; the only notable vm-dependent change is that my branch supports arbitrary constants in programs <civodul>bipt: what kind of arbitrary constant do you have in mind? :-) <civodul>wingo: guile-charting is broken on >1.8, isn't it? <bipt>in the medium term, elisp strings are likely to remain a smob type or similar. elisp vectors, hash tables and so on are also smobs atm. also uninterned symbols from macroexpansion <civodul>and SMOBs can be serialized to .go, in your branch? <bipt>i'll also note that for our future common lisp implementation, we'll need (eval 'x) => x for all objects x :-) <bipt>oh, not to .go, it only saves a constant table when the program is not being compiled to a file <bipt>it may very well work to just add support for serializing elisp strings and uninterned symbols (and use guile vectors etc.), but this was the simplest way to ensure compatibility <civodul>because SMOB type numbers are assigned at run time <civodul>and because there would need to be a way to identify SMOB types <bipt>yeah, i considered adding some kind of extensible serialization protocol but it seemed...complicated <civodul>my gut reaction would be to veto it ;-) <stis>Re emacs guile thread, why can't people just underestand that guile is a VM that implements especially continuations and delimeted continuations <stis>you can creat common lisp if you like (I have implemented CL's go statement) <stis>you can implement javascript <stis>The only lack is the ability to do this effectively like compiling CL's goto statements effectively <stis>It's a good technology, and it connects to C in a lovely way. <stis>if people want to go to CL, they can do that. It's (rather trivial) to get a version of CL in guile running compared to templetons job <davexunit>stis: I guess people that aren't familiar with Guile think it's only a Scheme implementation, not a general VM. <stis>Then we need to stress that over and over again, it's stupid for gnu not to combine them if I my say so <davexunit>stis: RMS chimed in at one point and said that Guile should be used if possible. <davexunit>though I know there are people that don't like RMS' push for guile. <stis>yes I saw that, but the masses seams be unaware. <davexunit>yeah, they are. I wish they would become aware, but I understand why they aren't aware: guile isn't very popular. <ft>The masses, sadly, notice the loud people, that contribute 60% of the mails to the thread, not the one mail by rms. <stis>wingo does a fantastic job with the VM and tempelton has marched quite well. It is obvious that now is the time to push for guile and stear up the merge. Guile 2.2 would be a great start for this. <davexunit>ft: yes, the loudest ones are the ones attacking guile, like the lilypond maintainer. *stis thinks we need to mail bomb the subthreads to make sure lazy readers who just follows a subthread or two get the point. <ft>davexunit: Yeah, that's the guy I was mainly refering to. :) <davexunit>I don't know if that's very wise. we should take the high road and not feed the trolls. <davexunit>it is unfortunate that lilypond still hasn't upgraded to guile 2.0, though. <davexunit>and perhaps those devs should get more help, but that doesn't excuse david's behavior. <ft>True. But it's kind of hard for a maintainer to get help from guile-folks, if he's a dick constantly. :) <ft>I mean, people do this for fun, AFAIK. And being yelled at isn't fun. <davexunit>and in one of his responses it seems like he is blaming the guile devs for lilypond potentially being left out of the next debian release. <davexunit>but it's also been about 3 1/2 years since guile 2.0's release... <stis>guile-devs has actually helped the lillypond folks alot during these years he doesn't mention that <stis>only the negative parts that is on his agenda atm <ft>stis: Of course not. That wouldn't support his atgument. :) <stis>Tell me why doesn't lilypond work on guile 2.0 <stis>what's the show stopper? <stis>fear of robustness problems? <stis>e.g. API changes that falls through the dev net and get unoticed until a bug report appears? <davexunit>I think there is a legimitate guile blunder that is partly responsible. <davexunit>stis: "`define-public' is no a longer curried definition by default" <stis>Why can't they use their own define-public? <stis>is it hard wired as a symbol match in compilation to tree-il? <stis>Well I think they worked around it, but they got bitten by the bug, right! <stis>or are they waiting for a new version of guile 2 to pop up? <rlb>repeat question (lost my backlog) -- where's the project that's creating persistent (immutable) scheme structures? <taylanub>(mark_weaver linked that above, you seem to have missed it) <rlb>taylanub: yes -- that sounds right <rlb>any idea how good guile's garbage collector is these days, when presented with a lot of ephemeral (very short lifespan) garbage? <bipt>rlb, it should be pretty good, as the bdw-gc is generational, AFAIK <rlb>bipt: ok, right -- thanks. Was using some immutable approaches, and wanted to see if that was likely to work well, even in somewhat intensive areas (as opposed to use of set-*! to cut down on garbage) <davexunit>rlb: I'm in a similar position with a game engine I'm writing. a lot of short lived objects being created at 60FPS. <davexunit>right now, performance isn't very good. but I haven't profiled and optimized. <rlb>davexunit: fair enough -- definitely a relevant concern if I keep poking at a clj dialect <davexunit>my problems likely also stem from floating point ops. <davexunit>but since I haven't taken the time to gather real data, who knows. <rlb>so I'm new to r6rs libs -- say I've dropped pfds into modules/, how do I reference it from other files i.e. (use-modules (pfds set))? <rlb>(which as-is doesn't work) <davexunit>I'm not sure, never used a r6rs lib, always guile modules. <lloda>don't know about R6RS, but for (use-modules (pdfs set)) to work, 1. there has to be a directory pdfs in your load path, 2. there has to be a set.scm file in that directory, and 3. the set.scm file must contain a (define-module (pdfs set) ...) declaration. <rlb>lloda: sure -- I just didn't know if use-modules had been extended to handle r6rs somehow (which the info pages seem to suggest) <lloda>(import) does work with Guile modules, that surprised some people here, so I don't know if that's 'proper' ***Fuuzetsu is now known as Guest83782
***Guest83782 is now known as Fuuzetsu`
<mark_weaver>rlb: (use-modules (pfds set)) is going to look for a file DIR/pfds/set.scm for some DIR in %load-path (which is initialized to GUILE_LOAD_PATH) <mark_weaver>(actually %load-path includes both compiled-in defaults plus the contents of GUILE_LOAD_PATH) <rlb>right -- I know how use-modules worked (pre r6rs), just didn't know if anything had changed there, and/or what pfds meant but "you're done". <mark_weaver>davexunit: the curried-definitions issue, while admittedly a blunder, is not a serious difficulty for getting lilypond to work. a bigger problem is that their language is a weird mix of scheme and their own language that cannot be parsed ahead of time, IIRC. the very design of the language requires interleaved lexing/parsing/macro-expansion/evaluation. <mark_weaver>so basically, it depended on the fact that we were a pure evaluator before with lazy macro expansion, etc. <davexunit>mark_weaver: thanks for the explanation. I knew that there was more than was mentioned in the thread. <mark_weaver>or something like that. I might have the details slightly wrong. <mark_weaver>so, the switch to a modern hygienic macro expander (psyntax) was a big part of the problem. <davexunit>ah, so they have a huge architecture issue on their hands. <mark_weaver>taylanub: I appreciate your efforts, but it might be better to let me respond to Kastrup. the problem is, you don't know enough of the relevant details to argue effectively with him. <mark_weaver>wingo suggested that I look into rewriting our macro expander, and I've been giving some thought to supporting lazy expansion of macros as part of that, to help lilypond. <rlb>mark_weaver: would lazy macro expansion have implications for potential future performance improvements? <mark_weaver>btw, Kastrup is not the only maintainer of lilypond. he's one of three. another is jenneke, who is much more friendly, hangs out here on #guile and has been working on things like Guile/GUD integration. *rlb asks knowing nothing about the specific context/situation <mark_weaver>rlb: when compiling, all the macro expansion would be done ahead of time, as it is now. but I'm considering supporting a mode that defers expansion until the first evaluation of an expression, as was done in guile 1.8. ***Fuuzetsu` is now known as Fuuzetsu
<rlb>ok, so do get back to my previous question, how do I load this? <mark_weaver>the best thing to do is to rename all the *.sls files to *.scm <mark_weaver>you can also configure guile to search for *.sls files, but that slows down module loading, because it means more stat calls. <rlb>mark_weaver: yeah -- but I was wondering why ijp thought it would "just work" -- maybe assuming the .sls config you just mentioned? <rlb>(yeah, wrt GUILE_LOAD_PATH) <rlb>"maybe ijp was assuming" <mark_weaver>rlb: if you use ijp's guildhall repo, then you can easily install a lot of guile libraries including pfds, foof-loop, and many others <mark_weaver>*.sls is a defacto standard extension for R6RS libraries, but guile doesn't support it by default, because our current module searching mechanism involves doing a stat(2) call for every DIR/EXT combination, where DIR is a directory in %load-path and EXT is one of the supported extensions. currently, the default supported extensions are ".scm" and "". best not rely on the "" one, but it's there for historical reasons. <mark_weaver>I'm thinking about changing it to use readdir instead, which would allow us to add more default extensions without increasing the number of syscalls. <rlb>ok thanks again -- for now: for f in *.sls; do ln -s "$f" "$(basename $f .sls)".scm; done <mark_weaver>if you're willing to pay the cost of extra stat calls to find *.sls, then you could add ".sls" to %load-extensions, but I don't recommand it <rlb>perhaps even remove ""? Would that break anything in guile itself (if you know)? <rlb>i.e. in projects where I know I don't have any code that depends on it <mark_weaver>and maybe individual users should consider removing "" from %load-extensions in their .guile <rlb>maybe -- unless that might break various third-party guile programs <mark_weaver>I suspect (hope?) that hardly anything depends on "" being there. <mark_weaver>I've never heard of anything depending on it, anyway. <mark_weaver>I *have* heard of people getting tripped up by it, though, e.g. when they add "." to their %load-path and happen to have a file the same name as some module they're trying to load. <mark_weaver>I'm afraid that you made some mistakes, and Kastrup took full advantage of that fact. he's very good at finding flaws in the arguments of his opponents. <mark_weaver>actually, it's probably best to just ignore him at this point. <rlb>so does use-modules support a shorthand for an import :prefix, or is "#:renamer (symbol-prefix-proc 'unixy:)" the normal approach? <rlb>i.e. thinking of :require (foo :as bar) <mark_weaver>sorry, we need to document that. the existence of that keyword is barely mentioned in the docs. <rlb>mark_weaver: great -- thanks -- now that I search for it, I see that it's mentioned in "info guile", but we might want to... (what you just said) <rlb>I thought I remembered it from back when, but wasn't sure... <rlb>hmm -- pondering how/if you might build clj-style hash-set (the default) on what pfds provides... <rlb>wonder to what extent clj relies on the java-world's expectation that "effectively every object has a hashcode" <rlb>(i.e. every Object provides hashCode(), which generally caches a value in the absence of modifications) <rlb>got a good bit of an edn/clj lexer working -- might consider forking that into an edn module that just generates "normal" guile structures if I get time (so that even if this clj business goes no further, we'll get something useful out of it -- for some definition of useful) <rlb>i.e. providing edn support in guile is only partially related to parsing clojure (slightly different syntaxes, and the former's going to produce guile lists/vectors/etc, where the latter's going to produce immutable structures) <taylanub>mark_weaver: in my latest e-mail I wrote that I might stop replying; I'll do that then <mark_weaver>taylanub: sounds good. I'm going to stop replying in my earlier threads with him as wel. <mark_weaver>rlb: yeah, when I looked into implemented HAMTs, the trickiest bit was to generate a potentially unlimited stream of hash bits, guaranteed to diverge eventually if the objects they're based are unequal (according to the chosen hash function). <mark_weaver>I asked ijp about that, and he said that he just uses the current hash functions and falls back to an alist upon hash collisions. <mark_weaver>taylanub: while he has managed to tarnish our image somewhat, I suspect he has done more damage to his own image. <mark_weaver>rlb: what problem are you having, implementing on top of ijp's library? <mark_weaver>rlb: if you're looking for hash functions that work on guile's data types, see 'hash', 'hashq', and 'hashv' in the guile manual. <mark_weaver>the hash functions are much improved in 'master', btw. <mark_weaver><bipt> bremner, i don't know, but someday i hope to be running guile-emacs on the hurd with a system managed by guix (; <mark_weaver>I'll add to that list "on hardware with 100% free designs down to the silicon", but I wonder if I'll live to see it :-? <mark_weaver>btw, thanks everyone for the kind words yesterday. that cheered me up :) <mark_weaver>Here's a funny interaction I had with my 3.5-year-old nephew (Julian): <mark_weaver>Julian: I know ALL the words. Mark: on really, can I test that? Julian: okay. Mark: What does "eccentric" mean? Julian: I know ALL the words that you DON'T know. <davexunit>mark_weaver: I live with a 4 year old girl. when I answer a question she asks, she often says "I knew you were gonna say <answer>" <davexunit>and if I question it, she knew I was going to question it, and recur. <mark_weaver>davexunit: children are so funny. for all the time they soak up, it is a joyful experience (or can be, depending on the kid I suppose) <davexunit>the time spent with my niece and my girlfriend's daughter has been quite joyful, minus the usual stretches of fussing. <mark_weaver>yeah, they can certainly be, um, challenging sometimes :-/ <davexunit>but yeah, sometimes you're doing some awesome guile hacking and they want to play candy land. <mark_weaver>I have no idea how civodul finds so much time to work on Guix, with both work and two children at home. <davexunit>I didn't know he had 2 kids. I knew he had one. <mark_weaver>I _thought_ he had two, but maybe I'm misremembering. <davexunit>he's never told me how many he has. I just heard him mention a kid once, so I know he has > 0 :P <rlb>mark_weaver: just thinking through the "issues" a bit -- i.e. how does the fact that hashCode() is ubiquitous in java affect/relate to what we'd want/need to elsewhere. I'm guessing that it's often caching the hashCode for all persistent collections, etc.