00:00:11 antoszka: after rebuild? 00:00:28 So it seems. 00:01:13 ls -l output/sbcl.core and see if it's regenerated recently 00:01:39 A, the core is old. 00:01:43 if it's stale, rebuild completely with make.sh 00:01:56 Yeah, I will. 00:02:26 It'll take a while, so I really need to get some sleep now. 00:02:29 Thanks for helping. 00:02:31 'night 00:08:15 heh, my troubleshooting seems to succeed /only/ because "/bin/true" is 8 characters long (the problem won't go away with :env nil otherwise). Glad I've not suggested /bin/false :) 00:08:33 ..scratch that, it's 9 character 00:12:35 memory access with sap-ref-32 _should_ be aligned -- now I know 00:30:11 ..wouldn't it be great to have swank-initiated connection support in SLIME for a case like this? (well, not when sb-bsd-sockets fail to build, of course) 01:29:55 pipping [~pipping@exherbo/developer/pipping] has joined #sbcl 01:46:59 borkman` [~user@S0106001111de1fc8.cg.shawcable.net] has joined #sbcl 01:48:21 -!- borkman [~user@S0106001111de1fc8.cg.shawcable.net] has quit [Ping timeout: 252 seconds] 02:17:14 borkman`` [~user@S0106001111de1fc8.cg.shawcable.net] has joined #sbcl 02:19:22 -!- borkman` [~user@S0106001111de1fc8.cg.shawcable.net] has quit [Ping timeout: 276 seconds] 03:00:31 -!- antgreen [~user@12.232.236.2] has quit [Ping timeout: 248 seconds] 03:07:01 |3b|` [foobar@cpe-72-179-19-4.austin.res.rr.com] has joined #sbcl 03:07:04 -!- blumbri [~blumbri@c-67-181-176-186.hsd1.ca.comcast.net] has quit [*.net *.split] 03:07:04 -!- |3b| [foobar@cpe-72-179-19-4.austin.res.rr.com] has quit [*.net *.split] 03:21:54 blumbri [~blumbri@c-67-181-176-186.hsd1.ca.comcast.net] has joined #sbcl 03:42:35 -!- cmm [~cmm@bzq-79-183-206-63.red.bezeqint.net] has quit [Ping timeout: 252 seconds] 03:42:47 cmm [~cmm@bzq-79-183-206-63.red.bezeqint.net] has joined #sbcl 03:55:46 https://github.com/akovalenko/sb-bluetooth 03:55:54 decided to make it public 03:56:09 (unsure whether it's suitable as a contrib...) 03:56:38 maybe we'd just add it all to SB-BSD-SOCKET 03:59:50 -!- jfletcher [jf@jamesfletcher.org] has quit [Remote host closed the connection] 05:08:57 -!- |3b|` is now known as |3b| 05:11:38 Quadrescence [~quad@unaffiliated/quadrescence] has joined #sbcl 05:14:02 -!- drl [~lat@110.139.229.172] has quit [Quit: Leaving] 05:37:00 -!- Quadrescence [~quad@unaffiliated/quadrescence] has quit [Quit: Quadrescence] 05:44:09 Quadrescence [~quad@unaffiliated/quadrescence] has joined #sbcl 05:47:54 sdemarre [~serge@91.176.125.157] has joined #sbcl 06:38:59 slyrus_ [~chatzilla@207.190.0.11] has joined #sbcl 07:18:31 akovalenko: Seems to have built correctly with all the contribs. 07:18:55 akovalenko: Just testing quicklisp with some libraries. 07:21:20 antoszka: yeah, I've concluded that it should work, while you were asleep :) 07:21:34 :) 07:21:49 akovalenko: Which timezone are you in? 07:23:59 Damn, osicat-posix won't build. 07:24:18 A, easy, cause there's no cc in path. 07:24:25 -!- pkhuong [~pkhuong@gravelga.xen.prgmr.com] has quit [Ping timeout: 252 seconds] 07:38:42 pkhuong [~pkhuong@gravelga.xen.prgmr.com] has joined #sbcl 07:49:21 akovalen` [~user@95.72.172.36] has joined #sbcl 07:49:46 -!- akovalenko [~user@95.73.220.203] has quit [Read error: Operation timed out] 07:52:55 -!- akovalen` is now known as akovalenko 07:55:22 antoszka: physically I'm in MSD timezone, but it doesn't mean that I sleep according to it :) 08:02:35 antoszka: btw, do you have DT_DIR in your /usr/include? 08:02:58 antoszka: if it is there, then dt_type should be around that place 08:03:22 antoszka: and if it's not, some part of osicat's dirent code is unusable on your system 08:03:50 (I mean greap -r DT_DIR /usr/include, of course ) 08:03:59 *grep 08:11:16 -!- slyrus_ [~chatzilla@207.190.0.11] has quit [Read error: Connection reset by peer] 08:11:48 slyrus_ [~chatzilla@207.190.0.11] has joined #sbcl 08:15:41 akovalenko: I've got something in: /usr/include/sys/fs/ufs_trans.h 08:15:51 akovalenko: typedef enum delta_type { 08:15:55  08:16:00 DT_DIR, /* 6 directory */ 08:16:09 antoszka: looks like a random coincidence 08:16:55 Wonder, if any code actually uses that dt_type struct part and if I could safely #+solaris that out 08:17:16 antoszka: then you probably have to comment out offending pieces of osicat (in unixint.LISP, not in generated C) 08:17:26 yeah, sure. 08:18:28 antoszka: dt-things seems not to be used by osicat *itself*, 08:18:39 but some caller may eventually expect them 08:19:12 btw, if you need osicat for linedit, I guess it's okay to comment dt-*stuff out 08:19:45 Yeah, just for linedit for now. 08:19:49 Trying that. 08:20:55 antoszka: notice also that rlwrap may make "lineditless" SBCL more convenient (not to a level of linedit, but in that direction) 08:21:45 Ah, I remembered there was that except I got the name mangled in my memory (looked for cl-readline). 08:21:59 Let's see if linedit works, though. 08:22:42 rlwrap is an external program -- it can be used with just about any line-oriented interpreter 08:22:59 ..even around telnet some.router.with.a.dumb.shell 08:24:06 Right. But wasn't there a linedit precursor called something along the lines of cl-readline? 08:24:48 antoszka: IIRC there was something with a name like this. Unsure if it was a precursor/ancestor/inspiration for linedit, though 08:25:24 Inspiration mostly, I suppose. Doesn't seem to be used anymore, not available in QL. 08:26:05 maybe we should look inside linedit and figure out what part of osicat does it need. if it's something like a couple of tcsetattrs (as I suppose) -- maybe make it use sb-posix on sbcl.. 08:28:03 antoszka: even better, it seems to use just osicat:kill() (for sigint forwarding) 08:28:44 That isn't much. 08:29:38 antoszka: and you should have sb-unix:unix-kill and sb-unix:unix-killpg in unixish sbcl 08:31:00 *I'm probably wrong -- :linedit package uses :osicat 08:31:16 Hm. There's no :solaris in *features*. 08:31:32 Just using :sparc seems a bit dumb/unsafe. 08:32:07 Anyway, another fuckup shows up, in posix/wrappers.c 08:32:17 Have to go to work now for the day. 08:32:18 BBL 08:32:49 /home/antoni/.cache/common-lisp/sbcl-1.0.51-solaris-sparc32/home/antoni/quicklisp/dists/quicklisp/software/osicat-20110619-git/posix/wrappers.c: In function 'readdir_r_cffi_wrap': 08:32:52 /home/antoni/.cache/common-lisp/sbcl-1.0.51-solaris-sparc32/home/antoni/quicklisp/dists/quicklisp/software/osicat-20110619-git/posix/wrappers.c:72:3: error: too many arguments to function 'readdir_r' 08:34:19 antoszka: leave osicat alone, look at linedit :) 08:34:39 antoszka: works like a charm with osicat removed (except two kill calls) 08:35:13 what I've done: 1. removed :osicat from defpackage (packages.lisp) 08:35:31 2. removed dependency on osicat from linedit.asd 08:35:50 3. disabled (commented out) these two osicat:kill's for now 08:38:51 antoszka: and sb-unix:unix-kill works like a charm 08:39:02 (with sb-unix:sigint and sb-unix:sigtstp) 08:46:54 antoszka: as of the features, solaris is :sunos 08:48:37 antoszka: IIRC, solaris means "by (the) Sun" in latin :) 10:09:13 attila_lendvai [~attila_le@catv-80-98-25-142.catv.broadband.hu] has joined #sbcl 10:09:13 -!- attila_lendvai [~attila_le@catv-80-98-25-142.catv.broadband.hu] has quit [Changing host] 10:09:13 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 10:30:09 tcr [~tcr@84-72-21-32.dclient.hispeed.ch] has joined #sbcl 10:51:08 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 10:52:43 attila_lendvai [~attila_le@catv-80-98-25-142.catv.broadband.hu] has joined #sbcl 10:52:43 -!- attila_lendvai [~attila_le@catv-80-98-25-142.catv.broadband.hu] has quit [Changing host] 10:52:43 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 10:59:16 -!- tcr [~tcr@84-72-21-32.dclient.hispeed.ch] has quit [Quit: Leaving.] 11:10:14 tcr [~tcr@84-72-21-32.dclient.hispeed.ch] has joined #sbcl 11:10:14 -!- tcr [~tcr@84-72-21-32.dclient.hispeed.ch] has quit [Client Quit] 11:15:49 homie [~levgue@xdsl-78-35-136-117.netcologne.de] has joined #sbcl 11:16:10 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 12:41:27 akovalenko: Thanks, I'll try that. However it might be useful to push upstream some solaris fixes. After all it will hit someone else sooner or later. 12:41:43 akovalenko: Do you know if your fix to run-program will be pushed upstream? 12:44:42 antoszka: I think it will eventually get there (maybe very soon, actually). But I have no control over it :) 12:45:23 Thanks. Where can I watch the code get there? subscribe to some sbcl-devel ml? 12:45:25 I hope you're not counting on me, since I've lost track of your discussion :-). Where is the fix and what does it do? Is there a launchpad entry? 12:45:57 lichtblau: 01:50:26 < akovalenko> try replacing (setf (sap-ref-32 string-sap size) 0) with (sb-kernel:system-area-ub8-fill 0 string-sap size 4) in run-program.lisp 12:45:59 (Is it a regression, or is it broken in the current release already?) 12:46:10 lichtblau: it's a one-line replacement in run-program.lisp 12:46:12 lichtblau: That's the fix. Fixes run-program.lisp on sunos. 12:46:33 lichtblau: It's broken in the release. 12:46:44 lichtblau: no launchpad entry yet. Don't know when it got there.. 12:47:05 ok, actually s/on sunos/on sparc/, I presume, if it's an alignment issue? 12:47:08 lichtblau: it's actually necessary for all platforms disallowing misaligned access 12:48:40 (sap-ref-32 compiles to real int32-sized access, hence it can't be used for loading/storing some *arbitrary* misaligned bytes, except when the platform doesn't require alignment) 12:49:19 OK, it's a bad bug, but since it's not new, I'll take of it only after the freeze is over; don't want to accidentally break run-program everwhere. 12:49:39 lichtblau: how can that be? 12:50:00 lichtblau: maybe repeating sap-ref-8 four times will be more obviously safe? 12:51:07 (then go for repeated sap-ref-8, of course. It seems to be exactly the kind of conservative bugfix that I'd expect to be welcomed even during the freeze) 12:52:39 commit edd4f6337f9955c34716ff87a50e4cb20e8a8521 12:52:40 Author: Paul Khuong 12:52:40 Date: Fri Jun 10 23:33:04 2011 -0400 12:52:40 12:53:22 now I would expect pkhuong to take care of it :) 12:54:38 *akovalenko* just used "git blame" for the first time in his life 12:57:16 As a side note, linedit will still not quickload: 12:57:17 Error while invoking # on 12:57:17 # 12:57:47 Can't see the error itself, though. 12:58:15 antoszka: please try compiling terminal_glue.c by hand 12:58:18 if we're rounding up, and if we're assuming that memory isn't zero-filled already, wouldn't it be better to zero-fill the padding bytes, too? 12:59:32 lichtblau: can't see any rounding up around there 12:59:48 (if we /were/ rounding up, that would be aligned access!) 13:01:40 well, I was going to be as conservative as possible (just replaced a line of code with its almost full equivalent) -- but if the fix won't get to 1.0.52 anyway, maybe we could come up with something better.. 13:05:03 lichtblau: frankly, I don't understand why it's not a /single/ sap-ref-8 instead of sap-ref-32.. 13:05:04 we unconditionally add 4 zero bytes, plus up to (n-word-bytes - 1) of padding (the LOGANDC2). The beginning of each string is aligned; the first zero byte at the end usually isn't. 13:05:12 akovalenko: gcc -c -o /tmp/foo terminal_glue.c  compiles just fine. 13:05:25 not a single because of "Multibyte encodings may need more than a single byte of zeros; assume 4 byte is enough" 13:05:55 lichtblau: as of rounding up, now I see it 13:06:18 lichtblau: as of more-than-one-null, it seems to be "posixly incorrent" in a gross way 13:06:39 but it errs on the safe side, so we can left it alone 13:06:41 Fans of djb-style "offensive programming" might propose to fill the pad bytes with non-zero junk :-). 13:08:04 lichtblau: btw, sometimes I wish that alien-stack-allocated regions would be filled with random junk.. 13:08:54 akovalenko: your proposed fix was fine. 13:10:43 my original patch had a sigle null byte, and then I went paranoid: 16 bit chars would have 2 bytes of null, for instance. 13:11:38 pkhuong: I assume it means that POSIX is incompatible with UCS-2 locales, and nothing more 13:13:02 pkhuong: (well, really, *C non-wchar strings* are incompatible with UCS-2/UCS-4/UTF-16 ) 13:15:27 yet we'll happily encode strings as such. In the event that it works, might as well make sure it doesn't die due to fauly null termination. 13:21:47 ok, then let's put sb-kernel:system-area-ub8-fill in that place without changing the logic 13:25:13 (perhaps it would be cleaner to reencode #\Nul after each string-vector element -- guaranteed to work consistently even if we accept 8-byte encoding eventually :) 13:27:40 perhaps. If I were to redo everything from scratch, strings would be utf-8 streams. You want something else? tough luck. 13:28:26 pkhuong: btw, if one has something like :ucs-2 as his default external format, there are countless other problems anyway 13:28:42 pkhuong: like, being unable to open /dev/tty and /dev/null... 13:29:07 defense in depth ;) 13:30:26 pkhuong: can I assume that you'll take care on this micro-patch? Or should I open a bug at launchpad and continue to pester *all* SBCL developers about it regularly? :) 13:31:34 let me open a private ticket. 15:05:07 -!- slyrus_ [~chatzilla@207.190.0.11] has quit [Ping timeout: 255 seconds] 16:04:42 Krystof [~user@81.174.155.115] has joined #sbcl 17:04:02 christop` [~user@oteiza.siccegge.de] has joined #sbcl 17:58:12 attila_lendvai [~attila_le@adsl-89-132-53-119.monradsl.monornet.hu] has joined #sbcl 17:58:12 -!- attila_lendvai [~attila_le@adsl-89-132-53-119.monradsl.monornet.hu] has quit [Changing host] 17:58:12 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 18:32:05 I wonder if we could support some form of stochastic code review. 18:32:58 just pick commits at random, give them 5 minutes' worth of attention, and, at some point, come back to those commits that were too complex to check. 18:35:10 pkhuong: i'm unsure if anything non-trivial can be spotted this way 18:37:15 me neither. 18:38:11 but: trivial bugs exist (c.f. eric marsden's latest bug), and some forms of subtle bugs are trivial to detect when we explicitly look for a pattern. 18:38:42 pkhuong: btw, windows seems to be broken w.r.t run-program recently (haven't really checked, but...) 18:39:42 I don't understand run-program. I only worked around an awful failure mode on large strings. 18:40:39 https://github.com/akovalenko/sbcl-win32-threads/commit/b168a3f1035ff46d1a58eb72e3c0c9e1019bdf06 18:41:31 ah. how are "FDs" cleaned up on windows? 18:41:40 pkhuong: they aren't 18:41:52 pkhuong: it's just a dead code 18:42:27 pkhuong: basically, fd-handlers are broken on Windows beyond any hope 18:43:08 there has to be a better place to push the haandler. 18:43:15 pkhuong: the one-liner fix has to do with undeclared-but-used variable, not with anything real that the run-program *does* 18:44:18 right. 18:44:39 It may be local to my fork, after all, but (just in case) -- if someone decides to build mainline SBCL for win32 soon and sees problems with run-program -- let him look at the commit above 18:45:46 no, needs fixing as well. 18:49:28 whoops, sorry 18:49:40 the introduction of that form did fix a real bug, though 18:52:15 Krystof: of course, but not for platform(s) where this machinery doesn't work at all :) 18:53:05 yeah :-) 18:53:56 it seems that something like a build farm with a whole zoo of OSes would be beneficial 18:54:56 *akovalenko* can't decide if the recent Solaris story tells anything about SPARC popularity, or SBCL popularity.. 18:55:28 -!- christop` is now known as christoph_debian 18:55:29 it tells us what happens to !x86oids. 18:57:44 pkhuong: well, nothing? (within my small room at home, there are 3 MIPS/Linux devices and 3 x86oids now. whopping 50% of non-intels :) 18:59:57 btw, am I right that SBCL's gencgc is x86oid-only now? it would be interesting to hear /why/ it's so (if it is). 19:00:23 it's ppc as well, iirc. 19:01:21 as for why? nobody ported it, I think. 19:02:42 and IIRC cmucl has gencgc ported to sparc, might be worth stealing 19:49:48 pchrist_ [~spirit@gentoo/developer/pchrist] has joined #sbcl 20:17:51 -!- sdemarre [~serge@91.176.125.157] has quit [Ping timeout: 248 seconds] 20:58:09 hargettp [~hargettp@pool-71-184-183-74.bstnma.east.verizon.net] has joined #sbcl 21:30:48 -!- hargettp [~hargettp@pool-71-184-183-74.bstnma.east.verizon.net] has quit [Quit: Leaving...] 21:31:05 hargettp [~hargettp@pool-71-184-183-74.bstnma.east.verizon.net] has joined #sbcl 21:34:43 -!- hargettp [~hargettp@pool-71-184-183-74.bstnma.east.verizon.net] has quit [Client Quit] 21:38:23 -!- Phoodus [~foo@68.107.217.139] has quit [Ping timeout: 252 seconds] 22:02:07 attila_lendvai1 [~attila_le@adsl-89-132-54-12.monradsl.monornet.hu] has joined #sbcl 22:02:07 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Disconnected by services] 22:26:36 -!- homie [~levgue@xdsl-78-35-136-117.netcologne.de] has quit [Read error: Connection reset by peer] 22:27:45 homie [~levgue@xdsl-78-35-185-136.netcologne.de] has joined #sbcl 22:30:52 homie` [~levgue@xdsl-78-35-185-136.netcologne.de] has joined #sbcl 22:31:35 -!- homie [~levgue@xdsl-78-35-185-136.netcologne.de] has quit [Client Quit] 22:56:29 hargettp [~hargettp@pool-71-184-183-74.bstnma.east.verizon.net] has joined #sbcl 23:33:08 -!- hargettp [~hargettp@pool-71-184-183-74.bstnma.east.verizon.net] has quit [Quit: Leaving...] 23:35:32 hargettp [~hargettp@pool-71-184-183-74.bstnma.east.verizon.net] has joined #sbcl 23:38:29 -!- hargettp [~hargettp@pool-71-184-183-74.bstnma.east.verizon.net] has quit [Client Quit]