***Guest56559 is now known as `micro
***`micro is now known as micro
<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>very cool, it evens shows what year is it <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 ;-) <wingo>nalaginrut: nice, enjoy the festivities :-) <jmd>I wondered if there was a guile libary to process/parse zip files? <jmd>Are you in Brussels? <jmd>I guess it's not too far for you. <wingo>i think weinholt has a zip library <civodul>i suspect it may be a bit slow on 2.0 <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 <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 <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) <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... <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>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. <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>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. <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>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>it may be that one of us will have to build the latest LLVM to track this down. <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.