00:25:20 -!- Qworkescence [~quad@unaffiliated/quadrescence] has quit [Quit: Leaving] 00:37:52 -!- LiamH [~none@pdp8.nrl.navy.mil] has quit [Quit: Leaving.] 02:16:56 tsuru`` [~charlie@adsl-74-179-25-87.bna.bellsouth.net] has joined #sbcl 02:18:30 -!- tsuru` [~charlie@adsl-74-179-30-61.bna.bellsouth.net] has quit [Ping timeout: 240 seconds] 02:27:16 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 03:11:29 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Read error: Connection reset by peer] 03:13:38 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 04:35:10 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 258 seconds] 04:44:39 attila_lendvai [~attila_le@62-84-55-107.customers.almanet.kz] has joined #sbcl 04:44:39 -!- attila_lendvai [~attila_le@62-84-55-107.customers.almanet.kz] has quit [Changing host] 04:44:39 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 05:05:18 -!- slyrus [~chatzilla@adsl-99-190-98-219.dsl.pltn13.sbcglobal.net] has quit [Ping timeout: 240 seconds] 05:10:15 -!- antgreen [~user@bas3-toronto06-1177889969.dsl.bell.ca] has quit [Ping timeout: 276 seconds] 05:14:43 slyrus [~chatzilla@adsl-99-190-98-219.dsl.pltn13.sbcglobal.net] has joined #sbcl 05:33:27 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Read error: Connection reset by peer] 05:35:46 attila_lendvai [~attila_le@62-84-55-107.customers.almanet.kz] has joined #sbcl 05:35:46 -!- attila_lendvai [~attila_le@62-84-55-107.customers.almanet.kz] has quit [Changing host] 05:35:46 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 05:41:44 -!- homie` [~levgue@xdsl-84-44-153-252.netcologne.de] has quit [Remote host closed the connection] 07:11:34 sdemarre [~serge@91.176.142.68] has joined #sbcl 07:15:42 -!- sdemarre [~serge@91.176.142.68] has quit [Ping timeout: 240 seconds] 07:16:05 sdemarre [~serge@91.176.146.160] has joined #sbcl 07:21:15 sdemarre1 [~serge@91.176.146.133] has joined #sbcl 07:22:30 -!- sdemarre [~serge@91.176.146.160] has quit [Ping timeout: 240 seconds] 08:19:37 angavrilov [~angavrilo@217.71.227.181] has joined #sbcl 09:33:39 Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has joined #sbcl 09:36:48 good morning everyone 09:47:09 tsuru``` [~charlie@adsl-74-179-250-113.bna.bellsouth.net] has joined #sbcl 09:49:15 -!- tsuru`` [~charlie@adsl-74-179-25-87.bna.bellsouth.net] has quit [Ping timeout: 260 seconds] 10:04:45 hlavaty [~user@91-65-217-112-dynip.superkabel.de] has joined #sbcl 11:01:48 nikodemus: are you there? 11:29:45 i am 11:30:04 just catching up on email while waiting for builds to finish 11:30:21 ...and browsing your patches 11:30:26 many thanks! 11:33:12 no, thank you for taking an interest! :) 11:50:27 -!- flip214 [~marek@unaffiliated/flip214] has quit [Remote host closed the connection] 11:51:36 flip214 [~marek@86.59.100.100] has joined #sbcl 11:51:36 -!- flip214 [~marek@86.59.100.100] has quit [Changing host] 11:51:36 flip214 [~marek@unaffiliated/flip214] has joined #sbcl 13:47:18 -!- sdemarre1 [~serge@91.176.146.133] has quit [Ping timeout: 240 seconds] 13:56:35 sdemarre [~serge@91.176.155.43] has joined #sbcl 14:12:06 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 240 seconds] 14:13:37 nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has joined #sbcl 14:13:48 G'morning all. 14:27:17 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 14:32:23 -!- tsuru``` is now known as tsuru` 14:48:48 Wonderful. I now have TWO lines of work that need me to do some GC hacking. 14:51:28 *slyrus* read that as "two lines of code" 14:51:37 Heh. 14:51:54 No, more two branches in different git trees. 14:52:47 I have stack-allocatable-fixed-objects on PPC, but it needs some changes to the stack scavenger to be properly reliable. 14:53:13 And said changes turn around and break stack-allocatable-vectors on MIPS even worse than they always were. 14:54:04 And the other line is the disassembly thing. 15:20:25 antgreen [~user@bas3-toronto06-1176449892.dsl.bell.ca] has joined #sbcl 15:23:15 ... Three. Three lines of work that need some GC hacking doing. Forgot about the scrub_control_stack() disaster. 15:29:45 homie [~levgue@xdsl-78-35-138-7.netcologne.de] has joined #sbcl 15:32:19 Hunh. Found a bug in looks_like_valid_lisp_pointer_p(). Lovely. 15:42:03 hey, that's /good/ news 15:42:24 found bugs are the second best kind there is 15:43:10 Fixed bugs being the best kind? 15:44:26 It turns out that you can round-trip a function object through get-lisp-obj-address and make-lisp-obj on cheneygc, but not on gencgc, due to a bug in the extra validation that gencgc does. 15:54:26 What's the general feeling about having more, smaller, internal packages? 15:55:35 +1 15:55:47 -1/2 15:56:05 0 15:56:31 when they have good and obvious boundaries, +1 15:56:52 akovalenko: Why half-against? 15:56:54 when the boundaries get muddy, -1 15:57:07 nikodemus: So, an SSET package could be worth a +1? 15:57:38 nyef: "when the boundaries get muddy..." remark is pretty much what I think of it 15:57:51 is it used outside sb-c? if not, why does it need a separate package? 15:58:33 It's used in SB-ASSEM, I believe. 15:58:35 sb!impl::i-can\'t-recall-where-it-was-but-it\'s-accessible-here 15:58:52 of the current packages, i think sb-bignum, sb-c, sb-int, sb-pcl/mop, sb-thread are ok 15:59:00 it doesn't get muddier than currently. 15:59:32 sb-kernel, sb-vm, sb-impl, sb-sys, sb-debug, sb-di at least are a mess 16:00:08 sb!unix => sb!os, sb!unix ;; should be split 16:00:16 yeah 16:00:28 sb-c is arguably too big, and there's some stuff that doesn't fit comfortably in -vm nor in -c. 16:02:25 I'm sortof looking at SB-DI right now, and I'm thinking that things like breakpoints are logically separable. 16:03:01 nyef: do you think sb-di is public or internal? 16:03:44 it's a trick question :) 16:03:51 It -should- be public, actually. It's the API for writing debuggers. 16:03:56 exactly 16:04:20 sb-debug is more user-level, but arguably sb-di is more heavily used by third parties -- eg. slime 16:04:22 But we can split out the actual functionality into another package, and reexport the symbols. 16:05:57 re. sb-unix/sb-os. i think whatever refactoring is done there should either name the package so that it's obviously internal "sb-dont-use-this", or make it public 16:07:00 Packages have docstrings, most of which indicate if a given package is public or not. 16:07:06 yeap 16:07:15 not all of them quite up to date, though 16:07:24 iirc 16:07:26 ... which ones aren't? 16:08:42 sb-sys has parts that are public, and parts that are definitely internal 16:09:05 sb-impl should be put out of our misery. 16:11:49 i kind of like as the default workspace from which nothing is exported 16:12:13 ... like CL-USER? 16:12:41 no, like (in-package :sb-impl) ;; stuff that doesn't have an obviously better package to implement it in 16:12:51 So... like CL-USER? 16:13:12 no, like (in-package :library-impl) 16:13:48 (defpackage :library (:use) (:export ...)) (defpackage :library-impl (:use :cl :library)) 16:13:49 Somewhat less egregious, I suppose. 16:14:14 Qworkescence [~quad@unaffiliated/quadrescence] has joined #sbcl 16:15:06 but: if you have a refactoring plan that improves the really muddy waters like sb-kernel and sb-sys, i'm probably not going to complain very much even if i disagree on some particulars 16:16:04 at the other extreme, if we just get more packages without clearly improving the consistency of current export lists i'm likely to pick nits a lot more 16:16:05 the default workspace which is empty before we start and from which nothing is exported 16:23:42 -!- sdemarre [~serge@91.176.155.43] has quit [Ping timeout: 240 seconds] 16:25:01 Fare [Adium@nat/google/x-rlcoxrnzzeyvggts] has joined #sbcl 16:26:34 Hum. I get a weird error message from sbcl 1.0.45.34 that I wasn't getting from 1.0.41: # datum: #>) 16:29:02 That's massively unfamiliar to me, I'm afraid. 16:29:10 apparently while declaring the reader method for a slot owner in a class point-of-contact 16:30:48 i think that's fixed in HEAD 16:31:05 where does the error occur? 16:31:31 ok, I'll be trying with a more recent sbcl 16:32:09 oh, yet another error with a sbcl 1.0.53.1  fun 16:33:24 (but this time a legit error: finding a (format "foo" ) without a stream argument) 16:33:37 Just trying to compile QRes with a more recent sbcl 16:33:52 prompted by a recent usocket not liking our ancient sbcl 16:36:22 oh no, now fixing qres for sbcl requires a sbcl upgrade beyond the broken versions currently packaged as rpms (inside ita), which requires a new sbcl being packaged as rpm, which cracauer will do if I make QPX run with the newest sbcl nice dependency chain 16:37:02 Invalid, unfinalizeable class # (classoid #). 16:37:14 looks like SBCL is less forgiving than it used to be 16:37:19 or than CCL is 16:38:17 just before that: ; caught WARNING: illegal type specifier for TYPEP: (OR HOSTED-PNR-PAX-LEG FOREIGN-PNR-PAX-SEAT) 16:38:21 sdemarre [~serge@91.176.210.70] has joined #sbcl 16:38:44 Let me guess, using types before they're defined? 16:39:32 yup 16:39:35 looks like it 16:39:52 while compiling a check-type 16:41:49 are the classes defined after the check-type is compiled? 16:45:21 a cursory reading of the .asd file says they are already there, but lemme query the debugger 16:45:50 Package problems, maybe? 16:46:44 the classes seem to be defined 16:46:56 no package problem - CCL compiles that code fine. 16:47:07 and so does SBCL 1.0.41 16:47:18 (except it doesn't like the usocket upgrade) 16:49:18 I suppose I could disable the :serve-events nil flag that makes usocket bork on 1.0.41 16:49:39 but it would be nice to get qres to compile with a recent sbcl. 16:49:46 Let me try to isolate the problem... 16:49:53 or add :allow-other-keys t to usocket? 16:50:04 Fare: can you pull a dozen-or-so frame of backtraces for those warnings? 16:50:49 nikodemus: you mean to sb-bsd-sockets in sbcl 1.0.41 ? 16:51:14 Fare: any caller can supply :allow-other-keys t 16:51:27 wow - a *different* error, now which suggests that building from clean vs with loading fasls yields different results (!) 16:51:33 i mean that if usocket used :allow-other-keys t, it would not break on older sbcls 16:51:49 what is :allow-other-keys t ? 16:52:41 it's standard. (defun foo (&key bar) ...) (foo :quux t) is an error (foo :quux t :allow-other-keys t) is ok -- it means that unknown keywords should just be ignored 16:52:54 can you add that to call to a any function with keyword arguments???? 16:52:59 yes 16:53:09 wow, I didn't know that. You learn every day. 16:53:11 clhs 3.4.1.4.1 16:54:30 so you can do things like (lambda (&rest args &key my) (apply #'foo :yours (something my) :allow-other-keys t args)), etc 16:57:36 wonderful. I'll use that in my code in the future. Adding that to usocket for now and compiling with the old SBCL. When I'm past that stage, I'll try to debug compiling QRes with a newer SBCL. 16:57:43 Thanks a lot for your help. 16:58:02 Should I open launchpad bugs? Come here and discuss the issues? Send them to sbcl-devel? 16:58:20 (I suppose QRes is one of the biggest CLOS applications being developed) 16:59:03 for things that you think should work that you can provide test-cases for, launchpad is ideal 17:00:03 for things that you think should work, but can't produce a test-case for, here / sbcl-devel sounds about right 17:00:36 for things that might not be kosher but you can't figure out the complains, here / sbcl-devel -- or lp if you have a test-case 17:17:22 ... why is there a 16-octet alignment for the fun_end_breakpoint_trap on x86-64? 17:22:00 nyef: if it's not for a fixnum pun (which is unlikely), it's probably just an instinct to align all code (thankfully, 0x90=NOP is used in this instance) 17:22:51 Mmm. It's technically a branch target, but it's almost certainly pointless to optimize for execution speed given what's going on there. 17:22:59 Oh well. 17:23:31 it's not real code that gets called, iirc: it's copied to other places.. 17:25:26 I know. 17:25:38 The actually-explained version is in ppc-assem.S. 17:26:42 -!- Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has quit [Quit: GOGOGO!] 17:27:09 I'm putting pointers to that explanation in all of the other arch-assem.S files, and fixing up the RETURN_PC_HEADER_WIDETAG bit on the other platforms that have them. 17:48:43 -!- sdemarre [~serge@91.176.210.70] has left #sbcl 17:55:05 ; caught STYLE-WARNING: 17:55:05 ; :ALLOW-OTHER-KEYS is not a known argument keyword. 17:55:44 I believe SBCL should not warn when this is passed. 18:01:09 akovalen` [~anton@77.51.40.53] has joined #sbcl 18:02:30 -!- akovalenko [~anton@95.73.107.146] has quit [Ping timeout: 240 seconds] 18:02:38 -!- akovalen` is now known as akovalenko 18:02:54 -!- angavrilov [~angavrilo@217.71.227.181] has quit [Ping timeout: 240 seconds] 18:04:46 -!- slyrus [~chatzilla@adsl-99-190-98-219.dsl.pltn13.sbcglobal.net] has quit [Ping timeout: 260 seconds] 18:12:20 angavrilov [~angavrilo@217.71.227.181] has joined #sbcl 18:17:06 -!- angavrilov [~angavrilo@217.71.227.181] has quit [Ping timeout: 256 seconds] 18:19:53 prxq [~mommer@mnhm-5f75e66f.pool.mediaWays.net] has joined #sbcl 18:38:44 pchrist [~spirit@gentoo/developer/pchrist] has joined #sbcl 18:45:14 Do we really need all of these if (gencgc_verbose) { FSHOW ... } bits in looks_like_valid_lisp_pointer_p() ? 18:46:21 Is anyone able to know in advance whether we really need some debug output? 18:47:12 i don't remember having ever needed them, and they're easier to add back in when you need them, than say all the signal FSHOW stuff 18:47:38 *shrug* 18:48:57 Okay, so we can safely dispose of them? I'm asking because I need the function itself to be in gc-common.c, which doesn't have access to gencgc_verbose, and even more doesn't have access to it on cheneygc targets. 18:50:05 ok by me 18:52:11 eff. finishing touches on this patch keep taking up inordinate amounts of time 18:53:21 Isn't that always the case? Either for a single patch, or for some important change that is easy to get the basics working, but requires supporting changes to make things work long-term. 18:57:52 -!- antgreen [~user@bas3-toronto06-1176449892.dsl.bell.ca] has quit [Remote host closed the connection] 19:14:18 -!- prxq [~mommer@mnhm-5f75e66f.pool.mediaWays.net] has quit [Quit: Leaving] 19:32:46 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 260 seconds] 19:36:07 homie` [~levgue@xdsl-78-35-180-60.netcologne.de] has joined #sbcl 19:36:18 -!- hlavaty [~user@91-65-217-112-dynip.superkabel.de] has quit [Ping timeout: 260 seconds] 19:38:13 -!- homie [~levgue@xdsl-78-35-138-7.netcologne.de] has quit [Ping timeout: 240 seconds] 19:45:10 Oops. Building with :sb-thread and :cheneygc doesn't quite work. 19:45:52 Is there a precise garbage collector for x86-64 ? 19:47:40 nope 19:47:42 <_8david> no. it would be very nice to have though, especially if not done the naive way (register partitioning). 19:47:47 -!- antoszka [~antoszka@unaffiliated/antoszka] has quit [Read error: Operation timed out] 19:49:38 even naive would be nice -- or even precise on stack but conservative on registers 19:52:03 give me backtrace, it's a tiny patch for registers. 19:52:08 erh, for on-stack 19:58:50 We could do precise stack scav fairly easily if we split the control stack from the C stack. 19:59:48 Of course, that would break stack-allocatable-non-conses, but whatever. 20:01:04 (I'm planning to knock that down to just breaking stack-allocatable-unboxed-vectors at some point.) 20:07:34 antoszka [~antoszka@unaffiliated/antoszka] has joined #sbcl 20:08:24 Is there a way, by adding declarations only (DECLARE/DECLAIM), to get this to not use GENERIC-*: (defun *5 (x) (* 5 x)) 20:09:03 Sure. Declaring X to be of some known type would be a good start. 20:09:47 I've tried: (declare (type fixnum x)) in the body 20:10:06 The only way I could get it to truly boil down is by doing (the fixnum (* 5 x)) 20:10:39 How about using (signed-byte 25)? 20:11:58 (defun *5 (x) (declare (fixnum x)) (logand most-positive-fixnum (* x 5))) ; the modular version 20:12:15 remove the logand for one that can return bignums 20:12:43 Ah, but does it still do the multiplication inline? 20:12:53 nyef, signed-byte did work 20:13:34 Qworkescence: Right, because it means that the result was small enough that it wouldn't overflow a something-or-other. 20:13:50 (Either a fixnum or a word, not sure which.) 20:13:53 what, no vop for inline multiplication and bignum-alloc? 20:13:58 wow 20:14:07 That's what I suspected, nyef 20:14:10 fixnum 20:15:15 Someone is asking me, in the disassembly of a function, "why do they never push ebp, or mov ebp, esp" 20:15:31 Does anyone have an answer (x86 SBCL) 20:15:42 "Because our stack frames aren't laid out that way." 20:17:54 Fair enough. :) 20:19:17 Hrm. Actually, modulo UVLs and such, we probably could lay our stack frames out so that that would work. 20:19:37 Making it work out for UVLs as well, though, would be a bit of a pain. 20:45:56 antgreen [~user@bas3-toronto06-1176449892.dsl.bell.ca] has joined #sbcl 20:57:02 -!- homie` [~levgue@xdsl-78-35-180-60.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 21:30:28 nikodemus/nyef: thanks! 21:33:08 drdo [~drdo@85.207.54.77.rev.vodafone.pt] has joined #sbcl 21:40:37 Wait, what? Context? 21:40:52 Oh, right. 21:41:13 And, on that note, it's time for me to vanish for the evening. 21:41:17 -!- nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has quit [Quit: G'night all.] 23:25:10 -!- nikodemus [~nikodemus@cs181056239.pp.htv.fi] has quit [Quit: This computer has gone to sleep]