IRC channel logs
2014-09-27.log
back to list of logs
<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 tell wingo (that was the result of git bisect) <paroneayea>so you have to pretty much guarantee that there's a /usr/bin/guile right? <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>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. <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, mark_weaver says: (that was the result of git bisect) <wingo>hoo, quite a backlog of things... <daviid>DeeEff: since you help me yesterday... http://www.norvig.com/python-lisp.html <- 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 http://draketo.de/proj/py2guile/ [removing all curried and 'tutorial' based stuff would be ideal... just sharing ideas laudly here, sorry for the noise <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>i will think about it in a bit. off for a run, ttyl <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? <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 :( <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>) <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). <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>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 http://paste.lisp.org/+330D 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>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." ? <mark_weaver>rlb: you should also add bed025b, which should fix a build failure you reported on ARM. <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. *rlb has had similar questions from emacs upstream <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? <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. <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? <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 <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 <davexunit>it would likely make more sense to use srfi-9 to define a record type that bundles the procedure + metadata like that <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>mark_weaver: port encoding currently defaults to ISO-8859-1 right?