IRC channel logs


back to list of logs

<mark_weaver>daviid: ah, thanks very much to bisecting it!
<mark_weaver>I think I'm just going to pass this along to wingo.
<mark_weaver>daviid: could you email about it?
<daviid>mark_weaver: yes, I was assuming you might say so, which make sence. I reallt need to study goops source code, but now I don't have sufficient available time. I will report the bug, ok.
<mark_weaver>hopefully wingo still remembers enough of the relevant details that he can fix the problem in much less time than either of us could.
<daviid>i agree, let's just hope he aceppts to raise a short priority change
<mark_weaver>sneek: later ask wingo could you please take a look at ? looks like guile-gnome was broken by 48ad85fb
<sneek>Got it.
<mark_weaver>sneek: botsnack
<mark_weaver>sneek: later tell wingo (that was the result of git bisect)
<paroneayea>so I guess you can't do:
<paroneayea>#!/usr/bin/env guile \\
<paroneayea>-e main -s
<paroneayea>so you have to pretty much guarantee that there's a /usr/bin/guile right?
<paroneayea>because of shell limitations
<taylanub>paroneayea: yes :(
<taylanub>there's no problem writing plain top-level programs to be executed as scripts, but if you want something that's a library and can be called as a program at the same time, you're out of luck, for now.
*paroneayea nods
<paroneayea>taylanub: got it, I understand
<paroneayea>thanks for clarifying!
<paroneayea>taylanub: worst comes to worst and one needs to use env to find the guile interpreter, it's not hard to write a shell script wrapper that passes everything along anyway... that's a one-liner.
<paroneayea>so, not so bad.
<wingo>mark_weaver: i think the case is (1) allocate an object with a mark function; (2) object becomes dead, gc runs; (3) object placed on free list for that object type; (4) next GC will see the object as "live", sorta
<sneek>wingo, you have 2 messages.
<sneek>wingo, mark_weaver says: could you please take a look at ? looks like guile-gnome was broken by 48ad85fb
<sneek>wingo, mark_weaver says: (that was the result of git bisect)
<wingo>sure, can fix
<wingo>hoo, quite a backlog of things...
<daviid>heya guilers!
<bipt>hi daviid
<daviid>hello bipt
<daviid>DeeEff: since you help me yesterday... <- it is CL/python based, would be nice to have 1 for guile. the benchmark would be a cool thing to have I think. for the info I need, a combination of this and [removing all curried and 'tutorial' based stuff would be ideal... just sharing ideas laudly here, sorry for the noise
<mark_weaver>greetings guilers!
<daviid>it'd be nice to add guile:
<daviid>hi mark_weaver
<mark_weaver>wingo: hi! thanks for the quick reply, but I still don't understand. if the object is on the free list, then the scm_tc7_smob type check at the beginning of 'smob_mark' should detect that and not call the user's mark function, right?
<mark_weaver>wingo: you later clarified that the problematic case was when the object passed to 'smob_mark' is actually still live (not on the free list), but that the marking function accesses some _other_ SCM object that's been freed.
<mark_weaver>but I don't understand how that can happen either, because you'd have to get the pointer from somewhere and if such a pointer exists, this other SCM object should not have been reclaimed.
<wingo>mark_weaver: dunno; is it possible for an object to be collectable but not yet on a free list? i think perhaps so.
<wingo>in that case you would have a collectable smob that could reference another collectable object
<wingo>and that second object could be on a free list, or not
<wingo>but that sounds a bit bogus
<wingo>i will think about it in a bit. off for a run, ttyl
<mark_weaver>okay, thanks!
<mark_weaver>hi daviid!
<mark_weaver>sneek: later tell wingo regarding the case you outlined just before your run: if a marking function is called on an object that's collectable and not on the free list, then that seems to indicate to me that the object is not actually collectable. I mean, this is what marking is all about, right?
<sneek>Got it.
<taylanub>bipt: emacs-devel/Kastrup is talking about whether there's any performance hit due to having separate Elisp and Scheme strings. you might want to chime in...
<taylanub>my understanding was that you don't generally need to convert between the two so there's no issue with it, but not sure how e.g. symbol names are handled
<mark_weaver>taylanub, bipt: regarding that, it might be worth mentioning that we plan to switch to UTF-8 (or some variant) as the internal representation of guile strings.
<taylanub>ah, interesting. Kastrup was saying that Guile might need to do that for Emacs integration...
<mark_weaver>however, I'm not sure we'll want guile strings to include all of the stuff that emacs strings have.
<mark_weaver>but I'd like for emacs strings to use a guile string internally for the actual character data.
<bipt>taylanub, yeah, not sure where he got that from. going to reply in a bit
<Ulrar>Anybody knows if guile-curl has active contributor ? looks like there was no commit for two years
<Ulrar>It's freeing non malloc'd addresses :(
<rlb>Having a build problem (ffi test actually) on m68k, and I wondered if it might ring any bells here (see the end here):
<bipt>mark_weaver, a switch to utf-8 would be very helpful for guile-emacs (beyond the typical advantages). the emacs maintainers probably don't want to start using utf-64 internally (:
<daviid>mark_weaver: building clutter, git reports changes for almost all .texi files that are generated while building the doc and for which I did not change anything. some are changes [2 spaces after a dot, paragraph reorginazation as if M-q] but a lot seems 'no change'. All this is probably due to texinfo 5.2, and I am under the idea that it would be fine to commit all these changes in 1 commit saying that these files have changed as a
<daviid>result of using texinfo 5.x [as oposed to 4.x] wdyt? They are in 'my way' and there is nothing I can do anyway...
<rlb>(...and the final error in the m68k test is:
<rlb>ERROR: In procedure pointer->procedure:
<rlb>ERROR: In procedure make-program: Wrong type argument in position 1 (expecting OBJCODE_P): #<unknown-immediate (0x335 . 0xc019f708) @ 0xc01b7744>)
<rlb>from test-ffi
<mark_weaver>rlb: what version of libffi are you using?
<mark_weaver>daviid: hmm, texinfo isn't involved in creating the .texi files, is it?
<rlb>I would imagine it's debian unstable's -- which he mentions has a patch (hang on).
<rlb>mark_weaver: 3.1-2
<daviid>mark_weaver: ah yes, I ment the doc generater [forgot its name now]
<mark_weaver>rlb: okay, sounds good, and actually, on a second look, it's probably irrelevant anyway.
*mark_weaver looks
<rlb>mark_weaver: thanks
<mark_weaver>rlb: so, it looks like 'get_object_trampoline' in foreign.c is probably has a bug on 68k. not sure whether it's the (nargs < 10) case (which uses statically-allocated 'objcode_trampolines') or the other case for large nargs that uses 'make_objcode_trampoline'
<mark_weaver>rlb: if you haven't already cherry-picked it, you probably want 156119b (Do not assume that 64-bit integers will be 64-bit aligned). I don't know whether GCC on m68k guarantees that uint64_t will be 64-bit aligned or not.
<daviid>here is short extract of such changes you can see changes as I just mentionned here above and 'no changes': would these caused by a different git config here? don't know
<rlb>here are the current patches: -- 0003 might be relevant (have to check)
<rlb>mark_weaver: ok, 0003 is similar
<mark_weaver>daviid: the changes of 'rotation-z-angle' to 'rotation-angle-z' indicate to me that it's not because the documentation translation tools changed, but rather than the sources used by that translation have changed.
<daviid>ok, i'd like to commit all thses in 1, not sure about the commit mesg, how about:
<mark_weaver>rlb: 0003 is similar, but doesn't include all the fixes. it doesn't include the fixes to foreign, which could explain the problem you're seeing.
<mark_weaver>rlb: in general, it would be good if you could use our upstream patches where possible.
<rlb>ahh -- ok, hadn't finished checking. I'll see if I can just switch to the upstream patch.
<mark_weaver>rlb: I also split 0003 into two separate upstream commits: 156119b is the alignment fix (with more than 0003 had), and 97c520f is the m68k register name change
<rlb>mark_weaver: great -- thanks
<mark_weaver>0004 could be replaced with 76a8db2, and 0007 with a85c78e
<daviid>hum, I'm not good at this but how about: 'generated documentation file changes following their respective source'
<rlb>mark_weaver: ok, thanks -- hadn't gotten around to that yet
<mark_weaver>daviid: or maybe "Update generated documentation." ?
*rlb hugs git-dpm
<rlb>too bad it can't also add all the dep-3 headers for me (
<daviid>ok, will do that, tx
<mark_weaver>rlb: you should also add bed025b, which should fix a build failure you reported on ARM.
<mark_weaver>(reported here on #guile)
<rlb>hmm, I thought I had that -- odd.
<mark_weaver>rlb: if we were to release 2.0.12 soonish, would it be feasible to get it into jessie? I confess I have no idea where jessie is, freeze-wise.
<rlb>maybe -- but the sooner the better (I think first-week nov is fairly hard-deadline, and there's going to be a mandatory 10-day migration to testing shortly)
<mark_weaver>hmm, well, maybe best to stick with 2.0.11, although I might look through the commits for cherry-pick candidates.
<rlb>well, by all means, ping me directly when it's released (so there's no delay), and I can see where we stand.
<mark_weaver>sounds good, thanks!
*rlb has had similar questions from emacs upstream
<rlb>(we'll see)
<rlb>wrt 24.4
<taylanub>did I get it right that we use 3 bytes for characters, since a whole byte is used for the tc8 type tag? what character encoding do those 3 bytes use?
<mark_weaver>taylanub: characters are immediates in guile
<taylanub>yeah, and immediates occupy 4 bytes including the type bits, no?
<mark_weaver>immediates use the same size as a pointer on the platform.
<mark_weaver>but basically, the SCM value itself contains the character, there's no other storage needed.
<mark_weaver>currently, for characters, the low 8 bits of the SCM are the type tag, and the upper bits are just the unicode code point.
<mark_weaver>so yeah, we can represent code points up to 2^24 on 32-bit.
<mark_weaver>well, up to 2^24-1
<mark_weaver>we could increase that if needed.
<mark_weaver>(in master)
<taylanub>oh, I didn't realize the bits could simply be an unsigned integer representing the Unicode code point. thanks :)
<mark_weaver>they are represented similarly to fixnums, in other words.
<mark_weaver>taylanub: what is the "Subject" for this discussion on emacs-devel?
<taylanub>'Re: Emacs Lisp's future'
<rlb>mark_weaver: thanks for the help -- uploading -6 soon, we'll see if it works.
<rlb>(though I think it takes days(?) to build on m68k...)
<rlb>mark_weaver: feel free to answer this with EBUSY, but is there any chance emacs' string rep (or some improved version thereof) might be suitable for guile (i.e. the reverse)?
<paroneayea>you can set properties on procedures in guile? super great :)
<paroneayea>I might be able to do away with using goops now that I know that
<davexunit>I have never used those, actually.
<davexunit>not sure what the use-case is.
<paroneayea>well, for my case, I want a way for a task to be able to dictate how it is described when running, such as "=> Copying file from a to b... done"
<paroneayea>though not all will probably change the default behavior
<paroneayea>would be nice to have the option
<davexunit>it would likely make more sense to use srfi-9 to define a record type that bundles the procedure + metadata like that
<paroneayea>heh :) yeah I'm using goops for it for now
<paroneayea>davexunit: any reason you think sfri-9 over goops?
<davexunit>I always use srfi-9 for defining new types. I find that I never really need OOP in Guile, but GOOPS also solves the problem.
<davexunit>typically I can get by with a few well-defined data types. :)
<mark_weaver>rlb: I'd like to change Guile's string rep to use UTF-8 or some superset, similar to emacs, but I don't think Guile's strings should include property lists and things like that.
<mark_weaver>I've done some thinking about it, but more is required.
<paroneayea>utf-8 everywhere \\o/
<paroneayea>mark_weaver: port encoding currently defaults to ISO-8859-1 right?
<paroneayea>might that change?