IRC channel logs


back to list of logs

<nalaginrut>happy Chinese year guilers!
***Guest56559 is now known as `micro
***`micro is now known as micro
<civodul>Hello Guilers!
<civodul>howdy wingo
<b4283>nalaginrut: happy chinese newyear
<civodul>b4283: Emacs tells me Chinese new year's day is tomorrow
<b4283>civodul: nice, what command is that
<civodul>org-agenda, which itself uses calendar.el :-)
<b4283>i've entered M-x org-agenda, is it the h command ?
<civodul>actually i think i have some customization for that, hmm
<b4283>anyway, we sometimes congratulate each other beforehand :P
<civodul>M-x holidays should do it out of the box
<b4283>oh good
<b4283>very cool, it evens shows what year is it
<civodul>yeah, Emacs is this great
<b4283>Jia-Wu is famous for a war between British and China
<b4283>it's cause is as common as modern wars: money
<b4283>ohoh, wrong, it's japanese not british
<nalaginrut>civodul: yes, it's tomorrow, but tonight is the most important, just like Christmas Eve ;-)
<nalaginrut>b4283: yeah~新年快乐
<wingo>nalaginrut: nice, enjoy the festivities :-)
<nalaginrut>;-D thanks
<civodul>nalaginrut: right, enjoy :-)
<jmd>I wondered if there was a guile libary to process/parse zip files?
<civodul>not that i know of
<civodul>(hello jmd, BTW :-))
<jmd>Are you in Brussels?
<civodul>not yet, tomorrow
<jmd>I guess it's not too far for you.
<wingo>i think weinholt has a zip library
<civodul>oh right:
<civodul>i suspect it may be a bit slow on 2.0
<wingo>could be, yeah
<wingo>it's what the guildhall uses iirc
<taylanub>Why would something be slow on 2.0 specifically ?
<civodul>i was thinking that if it does a lot of arithmetic, it may be slow
<civodul>perhaps that would hold for 2.2 as well though
<civodul>but i'm just speculating
<taylanub>due to boxed floats, or is our integer arithmetic also slow for some reason ?
<civodul>integer arithmetic is slow, see 'scm_sum' for instance
<civodul>though normally it goes through the assembly version
<civodul>well anyway, really speculating :-)
<taylanub>ok, was just curious :)
<taylanub>How can I make a record type have its memory address printed ? I'd like to distinguish their identity while debugging.
<civodul>taylanub: make a record type printer that shows (object-address foo)
<civodul>where foo is an object of that type
<taylanub>Ah, `object-address' is neat, thanks.
<taylanub>I was looking into the FFI stuff, but that only seems to have (or document) `bytevector->pointer'.
<mark_weaver>I suspect that weinholt's industria library uses R6RS fixnum and flonum operations, which in theory can be made faster than generic numeric ops, but currently on Guile it is quite a bit slower than the generic ops.
<mark_weaver>I hope to find the time to fix that in master before 2.2 is released.
<wingo>i'd rather fix it with unboxed values...
<wingo>maybe not tho
<mark_weaver>well, within a procedure, some values will be able to be unboxed, and that's a good thing to do of course where possible. but in many cases we'll have to deal with the boxed values too.
<mark_weaver>basically, if a given value can only come from a fixnum procedure, and is used only in fixnum procedures, then it can be unboxed.
<mark_weaver>but there are many cases where a value comes from the outside and then goes to a fixnum procedure.
<mark_weaver>or the result of a fixnum procedure escapes.
<mark_weaver>we may not be able to make those fixnum ops faster than generic ops in the common case, but at least we can make them not be any slower.
<mark_weaver>right now they're a *lot* slower.
<wingo>the most important case is in loops, and that case should be unboxed in general.
<mark_weaver>yes, one hopes so. but there are still cases where you can't unbox it all, e.g. if the fixnums are coming from a vector, or using a procedure that's not statically known.
<mark_weaver>obviously we should unbox wherever we can. I think think it's a shame if people avoid the fixnum ops simply because they are much slower in some cases.
<mark_weaver>s/think think/just think/
<mark_weaver>the fixnum ops could share opcodes with the generic ops, if we just had one spare bit to use; a bit that would only be checked if it's not a fixnum.
<mark_weaver>*if any operand is not a fixnum or if the result overflows.
<mark_weaver>well, we've had this conversation before. at the time you were okay with the idea, and agreed that 128 registers were enough for the relevant numeric ops.
<mark_weaver>sneek: seen weinholt?
<sneek>I last saw weinholt on Sep 20 at 04:12 pm UTC, saying: :).
<mark_weaver>well, I dunno. I just want the fixnum/flonums ops to not suck from a performance perspective in practice. if you have a better plan that doesn't involve them sucking in 2.2, I'm all ears.
<wingo>i don't have the brain for it right now, can we talk on it later?
<mark_weaver>I'm concerned that Guile apparently no longer works with modern clang, at least according to hydra. it would be good to get that sorted out before 2.0.10 is released.
<civodul>mark_weaver: i'll see what i can do after FOSDEM
<civodul>however, is there really no Clang user around? :-)
<mark_weaver>There are MacOS users, but we'll only hear from them after we release and they can't build.
<mark_weaver>We've gotten several bug reports from MacOS users over the last year or so.
<mark_weaver>the libffi problem, for example, and the 'noreturn' thing.
<mark_weaver>and the multiplication overflow check bug, that only affected clang users (so far).
<civodul>debbugs should have a button to ping all previous reporters using a specific OS/compiler
<mark_weaver>heh :)
<mark_weaver>actually, the problem might be with a clang that's not yet deployed in macos.
<mark_weaver>the problem affects guile-1.8, guile-2.0, and master equally. they all started failing when nixos changed to a new LLVM.
<mark_weaver>specifically, I think this was the change that broke everything:
<civodul>i can also ping 'em
<mark_weaver>it may be that one of us will have to build the latest LLVM to track this down.
<mark_weaver>probably easiest for a nixos user.
<mark_weaver>well, nixos is the only place we know that the problem happens, so far.
<mark_weaver>the problem being that guile (1.8/2.0/master) segfaults on its first run.
<mark_weaver>(while generating guile-procedures.texi)
<dsmith-work>Hey hey!