10:31:25 ccl-logbot [~ccl-logbo@setf.clozure.com] has joined #sbcl 10:31:25 10:31:25 -!- names: ccl-logbot oiiii deepfire 10:33:30 sshirokov [~sshirokov@ghanima.slavasaur.com] has joined #sbcl 10:33:30 MikeSeth [~me@unaffiliated/mikeseth] has joined #sbcl 10:33:30 pkhuong [~pkhuong@gravelga.xen.prgmr.com] has joined #sbcl 10:33:30 spacebat [~spacebat@ubermonkey.net] has joined #sbcl 10:33:30 |3b| [foobar@cpe-72-179-19-4.austin.res.rr.com] has joined #sbcl 10:33:30 redline6561 [~redline65@li69-162.members.linode.com] has joined #sbcl 10:33:30 cow-orker [~foobar@pogostick.net] has joined #sbcl 10:33:30 foom [~jknight@ita4fw1.itasoftware.com] has joined #sbcl 10:33:30 Xof [~crhodes@158.223.51.79] has joined #sbcl 10:33:30 kanru [~kanru@kanru-1-pt.tunnel.tserv15.lax1.ipv6.he.net] has joined #sbcl 10:33:30 daimrod [~daimrod@sbrk.org] has joined #sbcl 10:33:30 ljos [~mozzyb@login1.uib.no] has joined #sbcl 10:33:30 antifuchs [~foobar@care.boinkor.net] has joined #sbcl 10:33:30 blumbri [~blumbri@c-67-181-176-186.hsd1.ca.comcast.net] has joined #sbcl 10:33:30 Phoodus [~foo@68.107.217.139] has joined #sbcl 10:33:30 whoops [u549@gateway/web/irccloud.com/x-frlregqmysierdqx] has joined #sbcl 10:33:30 sbryant [~freenode@ghanima.slavasaur.com] has joined #sbcl 10:33:30 christoph_debian [~user@oteiza.siccegge.de] has joined #sbcl 10:33:30 reb` [user@nat/google/x-vpowsaservkjvren] has joined #sbcl 10:33:30 cmm [~cmm@109.67.212.191] has joined #sbcl 10:33:30 jiacobucci [~jiacobucc@gw-asdl.ae.gatech.edu] has joined #sbcl 10:33:30 sdemarre [~serge@91.176.50.149] has joined #sbcl 10:33:30 Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has joined #sbcl 10:33:30 hlavaty [~user@91-65-217-112-dynip.superkabel.de] has joined #sbcl 10:33:30 drdo`` [~drdo@85.207.54.77.rev.vodafone.pt] has joined #sbcl 10:33:30 pchrist_ [~spirit@static062038158100.dsl.hol.gr] has joined #sbcl 10:33:30 akovalen` [~anton@95.72.168.23] has joined #sbcl 10:33:30 nikodemus [~nikodemus@cs181056239.pp.htv.fi] has joined #sbcl 10:33:30 loke [~elias@bb115-66-85-121.singnet.com.sg] has joined #sbcl 10:33:30 dsp_ [~tt@lebesgue.cowpig.ca] has joined #sbcl 10:33:30 danlarkin [~dan@danlarkin.org] has joined #sbcl 10:33:30 antoszka [~antoszka@unaffiliated/antoszka] has joined #sbcl 10:33:30 flip214 [~marek@unaffiliated/flip214] has joined #sbcl 10:33:30 fe[nl]ix [~quassel@pdpc/supporter/professional/fenlix] has joined #sbcl 10:33:30 luis [~luis@nhop.r42.eu] has joined #sbcl 10:33:30 -!- hubbard.freenode.net has set mode +oo Xof nikodemus 10:34:14 jsnell [~jsnell@ash.snellman.net] has joined #sbcl 10:36:10 Quadrescence [~quad@71-215-124-37.hlrn.qwest.net] has joined #sbcl 10:37:39 slyrus [~chatzilla@adsl-76-254-45-26.dsl.pltn13.sbcglobal.net] has joined #sbcl 10:42:21 -!- akovalen` is now known as akovalenko 11:03:05 -!- Quadrescence is now known as Guest30207 11:15:41 attila_lendvai [~attila_le@62-84-51-137.customers.almanet.kz] has joined #sbcl 11:17:07 -!- attila_lendvai [~attila_le@62-84-51-137.customers.almanet.kz] has quit [Changing host] 11:17:07 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 11:43:56 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 276 seconds] 12:33:40 lichtblau [~user@port-92-195-81-17.dynamic.qsc.de] has joined #sbcl 12:52:04 LiamH [~none@pdp8.nrl.navy.mil] has joined #sbcl 13:36:58 tsuru [~charlie@adsl-98-87-51-128.bna.bellsouth.net] has joined #sbcl 13:42:02 akovalenko: does Windows have a Futex-style API, or would it lose OS-based locking with Nikodemus' changes? 13:42:48 which changes? There is my emulation of futexes in pthreads_win32.c.. 13:43:15 akovalenko: do you provide futex_wait, or does your fork you lutexes? 13:43:23 use, even 13:43:27 I provide futex_wait 13:43:45 then my stuff should not affect you 13:44:13 (in the sense of losing os-backed locking) 13:47:28 -!- fe[nl]ix [~quassel@pdpc/supporter/professional/fenlix] has quit [Remote host closed the connection] 13:47:36 fe[nl]ix [~quassel@pdpc/supporter/professional/fenlix] has joined #sbcl 13:48:13 zyg [58833446@gateway/web/freenode/ip.88.131.52.70] has joined #sbcl 13:49:05 during asdf-load-op of sb-cga: debugger invoked ... unknown &KEY argument: :RESULT-ARG ... 0: (SB-C::%DEFKNOWN (%COPY-VEC) (SB-INT:SFUNCTION (VEC VEC) VEC) 15) 13:53:59 OK, so basically I don't understand the code. :-) 13:54:13 Let me put my question like this: 13:54:24 (Why) is it possible to implement/simulate futex_wait on Windows reliably, and not on POSIX? 13:56:21 lichtblau: pthread-futex.c is an attempt of the latter, and it would be perfect on a system without async unwinds. Windows is such a system. We used pthread-futex.c for several months, then I went on to more direct implementation -- but w/o async unwinds and signals, it's no rocket science either. 14:09:21 suppose we used safepoints on Darwin, and rigorously cut down on user-visible signals, suchthat signal use is limited to carefully waking up threads. Would that make correct futex-like code easier then? 14:09:58 so it seems. 14:10:19 btw, does it have sigwaitinfo()? 14:11:22 *akovalenko* was thinking of a separate thread for handling asynchronous signals 14:14:58 lichtblau: yes. 14:15:58 afaict, the issue is that we do things like implement our own condition variables, but use the host's directly. 14:16:23 so we short windows of strangeness when the host thinks we own the lock and we don't, or vice versa. 14:16:29 *we have short windows 14:17:14 another way would be to stop doing that and use mutex/condvar to really implement our own primitives. 14:19:44 given that we want to play nice with interrupts, doing things like we currently do means that we have long critical sections that possibly invoke arbitrary code. 14:20:07 hmm.. is pthread_mutex_timedlock available on all SBCL platforms? 14:20:16 not on darwin 14:20:41 well, not way back when. It may have made it in 10.5 or 10.6 14:21:05 that's the reason to prefer our own locks (done with futexes) over using OS mutexes directoly. 14:21:07 I'm pretty sure 10.4 and older only had timed version of the mach semaphore ops. 14:21:08 *directly. 14:22:10 akovalenko: no. 14:22:34 akovalenko: we have timedlock where we have futexes. 14:24:19 pkhuong: I'm aware of that, but I didn't realize that you discuss lutex platforms (i.e. I misunderstood that you propose to get rid of futexes where we have them). Glad to be mistaken here :) 14:25:05 *akovalenko* doesn't know much of lutex builds -- never tried to run one, only read some code.. 14:25:09 no. My beef is with using the host's mutex to implement mutexes 14:25:33 We try to be clever and match acquire/release between Lisp and the OS 14:34:06 zyg: (lisp-implementation-version)? 14:35:22 nikodemus: "1.0.28" 14:37:02 that sbcl has a very long beard! so long that sb-cga trips over it :) you need at least 1.0.29, i think -- but i'd recommend going straight to 1.0.52 14:45:46 nikodemus: :) thanks.. I'll install 1.0.52 then. 15:07:11 -!- zyg [58833446@gateway/web/freenode/ip.88.131.52.70] has quit [Ping timeout: 265 seconds] 15:21:21 attila_lendvai [~attila_le@62-84-51-137.customers.almanet.kz] has joined #sbcl 15:21:21 -!- attila_lendvai [~attila_le@62-84-51-137.customers.almanet.kz] has quit [Changing host] 15:21:21 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 15:21:48 antgreen [~user@bas3-toronto06-1177698375.dsl.bell.ca] has joined #sbcl 15:43:12 nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has joined #sbcl 15:43:24 G'morning all. 16:08:27 -!- LiamH [~none@pdp8.nrl.navy.mil] has quit [Quit: Leaving.] 16:17:33 tsuru` [~charlie@adsl-98-87-47-198.bna.bellsouth.net] has joined #sbcl 16:18:19 homie [~levgue@xdsl-78-35-143-123.netcologne.de] has joined #sbcl 16:19:41 -!- tsuru [~charlie@adsl-98-87-51-128.bna.bellsouth.net] has quit [Ping timeout: 240 seconds] 16:24:18 joshe [~joshe@opal.elsasser.org] has joined #sbcl 16:42:01 ok. i have at least 5 divergent copies of docstrings.lisp around... this is not good 16:42:25 Heh. 16:42:43 I probably have as many wildly divergent hacks on src/compiler/generic/genesis.lisp. 16:45:33 i've been copying it to various projects and extending it based on their needs 16:45:50 i think it's time to turn it into a proper contrib 16:48:53 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 240 seconds] 17:01:45 -!- oiiii [~oiiii@82.71.241.25] has quit [Remote host closed the connection] 17:03:26 -!- Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has quit [Quit: Foo] 17:25:17 Qworkescence [~quad@unaffiliated/quadrescence] has joined #sbcl 17:33:43 antgreen` [~user@bas3-toronto06-1177698375.dsl.bell.ca] has joined #sbcl 17:33:54 -!- antgreen` [~user@bas3-toronto06-1177698375.dsl.bell.ca] has quit [Read error: Connection reset by peer] 17:33:54 -!- antgreen [~user@bas3-toronto06-1177698375.dsl.bell.ca] has quit [Read error: Connection reset by peer] 17:35:17 antgreen [~user@bas3-toronto06-1177698375.dsl.bell.ca] has joined #sbcl 17:42:53 -!- hlavaty [~user@91-65-217-112-dynip.superkabel.de] has quit [Ping timeout: 245 seconds] 14:16:53 ccl-logbot [~ccl-logbo@setf.clozure.com] has joined #sbcl 14:16:53 14:16:53 -!- names: ccl-logbot spacebat @Xof jiacobucci antoszka sdemarre christop` antifuchs @nikodemus angavrilov @Kryztof ljos flip214 hlavaty Blkt Iceland_jack attila_lendvai akovalenko Quadrescence _8david whoops loke cmm natesm jsnell deepfire luis danlarkin dsp_ sshirokov MikeSeth cow-orker daimrod sbryant 14:17:05 -!- hlavaty [~user@91-65-217-112-dynip.superkabel.de] has quit [Ping timeout: 258 seconds] 14:17:29 homie` [~levgue@xdsl-78-35-181-49.netcologne.de] has joined #sbcl 14:17:29 reb``` [user@nat/google/x-ccxrbdwrizxxnkdi] has joined #sbcl 14:17:29 fe[nl]ix [~quassel@pdpc/supporter/professional/fenlix] has joined #sbcl 14:17:29 kanru [~kanru@kanru-1-pt.tunnel.tserv15.lax1.ipv6.he.net] has joined #sbcl 14:17:29 peddie [~peddie@repl.esden.net] has joined #sbcl 14:17:29 joshe [~joshe@opal.elsasser.org] has joined #sbcl 14:17:29 redline6561 [~redline65@li69-162.members.linode.com] has joined #sbcl 14:17:29 pkhuong [~pkhuong@gravelga.xen.prgmr.com] has joined #sbcl 14:17:33 -!- joshe [~joshe@opal.elsasser.org] has quit [Ping timeout: 243 seconds] 14:17:33 -!- pkhuong [~pkhuong@gravelga.xen.prgmr.com] has quit [Ping timeout: 243 seconds] 14:18:13 LiamH [~none@pdp8.nrl.navy.mil] has joined #sbcl 14:18:25 pkhuong [~pkhuong@gravelga.xen.prgmr.com] has joined #sbcl 14:19:19 hlavaty [~user@91-65-217-112-dynip.superkabel.de] has joined #sbcl 14:19:33 blumbri [~blumbri@c-67-181-176-186.hsd1.ca.comcast.net] has joined #sbcl 14:22:28 |3b| [foobar@cpe-72-179-19-4.austin.res.rr.com] has joined #sbcl 14:22:59 foom [~jknight@ita4fw1.itasoftware.com] has joined #sbcl 14:37:51 nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has joined #sbcl 14:38:10 G'morning all. 14:50:16 morning nyef 14:50:42 Anything interesting going on? 14:51:41 i'm trying to get my keyboard mapping right on mcclim, that's all and people fed up with my messages..... 14:51:41 lol 14:51:54 taking another run at the gc/signal deadlocks on darwin 14:52:12 and me is fedup with hunchentoot or whatever messages in lisp.... 14:52:17 yet do they stop! 14:52:20 lol 14:52:22 ... That reminds me, I need to take another run at the GC stack scavenging soon. 14:58:46 i think i know what causes it now. it hangs whenever i think "hey, great, looks like i nailed it!" 14:58:47 what is darwin ? 14:58:47 another linux ? 14:58:47 os x 14:58:47 ah 14:58:47 porting stuff must be hard.... 14:58:47 drl [~lat@110.139.229.172] has joined #sbcl 14:58:48 Porting stuff to platforms that don't support posix signal semantics properly is a royal pain. 14:58:48 homie`: It's pretty much a BSD. 14:58:48 Or not. 14:58:48 -!- reb``` [user@nat/google/x-ccxrbdwrizxxnkdi] has quit [Remote host closed the connection] 14:58:48 reb``` [user@nat/google/x-xuflivnmbxfaasgm] has joined #sbcl 15:00:05 It's a mach system with the BSD emulation layer, but it's somewhat broken. 15:00:22 the userland /looks like/ a BSD, but when you sratch it you find mach and all manner of insanity 15:01:19 nikodemus: You know that we're using the FP traps via the emulated signals now, right? 15:01:30 My first Linux was a Linux on top of Mach (MkLinux DR1) back in about 1995. 15:01:37 On a PowerPC. 15:01:59 Not that I understood much of that at the time. 15:02:17 nyef: vaguely 15:08:39 hm. i seem to have the actual GC deadlock under control -- but interrupt-consing-child can still hang because at some point the allocating thread stops accepting signals 15:08:58 time to poke at sigmask, i think 15:09:23 antgreen [user@nat/redhat/x-vhmexwssmikltigv] has joined #sbcl 15:10:20 Wait, why do we block signals, again? 15:11:01 Oh, right. Resource constraints. 15:11:05 Nevermind. 15:11:38 and re-entrancy 15:13:34 Can we show that something that we're doing is breaking the rules, or that it's a problem with the underlying implementation? 15:14:55 Oh! And we probably shouldn't be deferring interrupts that we don't handle. If someone disables SIGPIPE from user code, for example, we should be removing it from the block and defer sets. 15:15:19 (And we shouldn't ADD it to the sets until the handler is added lisp-side.) 15:17:04 we /use/ SIGPIPE 15:18:22 but! it seems that what's happening is that some signals are being blocked, but not unblocked on some code path 15:18:30 Yes, yes. For INTERRUPT-THREAD, IIRC. 15:19:24 But for non-threaded SBCL, or if someone is willing to forgo the use of INTERRUPT-THREAD, then the user should be able to do whatever. 15:20:27 darwin doesn't have any notable problems currently without threads 15:21:00 -!- drl [~lat@110.139.229.172] has quit [Read error: Connection reset by peer] 15:21:01 the blocked signals issue (and the apparently-now-fixed) gc deadlock is threads-only 15:21:40 Sure, in terms of thread-stability. 15:21:57 But what about if someone actually needs to block SIGPIPE or some other signal that we normally handle internally? 15:22:05 SIGCHLD, as another example? 15:22:27 Actually, SIGCHLD is a better example. We ONLY handle it for RUN-PROGRAM. 15:22:59 tsuru [~charlie@adsl-98-87-48-164.bna.bellsouth.net] has joined #sbcl 15:26:15 ok. so my rogue thread has all deferrable signals blocked 15:26:26 but not SIG_STOP_FOR_GC 15:26:42 slyrus [~chatzilla@adsl-99-190-98-219.dsl.pltn13.sbcglobal.net] has joined #sbcl 15:38:43 hm, i think i have a theory 15:38:51 let's see if this fixes it... 15:41:17 Qworkescence [~quad@unaffiliated/quadrescence] has joined #sbcl 15:41:33 "I haz a theory but this kitteh of death haz pulled on its stringz?" 15:45:30 trying to make interrupt-consing-child test reliable on darwin has been an exiting adventure. every time i think i've figured out and rebuild... it still hangs, but when i study to see /how/ it hangs, it's different after every fix 15:46:19 Heisenbug? 15:46:37 rather multiple bugs 15:46:44 first there was the lutex signal unsafety 15:46:59 then there was pthread_cond_broadcast not being signal handler safe 15:47:31 now there's this... deferrable blocking mystery, unless my last change fixed it and this is something else again 15:51:41 aha, missed one place... /me rebuilds 16:13:02 -!- Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has quit [Quit: gogogo] 16:21:45 What kind of effort would go into getting native threads on Darwin PPC? 16:22:35 Qworkescence: We don't know. At worst, the same as getting them working on Darwin x86. 16:22:57 (Well, best-guess worst.) 16:23:14 They already work on Linux PPC, after all, and that took some doing. 16:25:04 -!- fe[nl]ix [~quassel@pdpc/supporter/professional/fenlix] has quit [Remote host closed the connection] 16:25:11 fe[nl]ix [~quassel@pdpc/supporter/professional/fenlix] has joined #sbcl 16:25:33 Are there any SBCL devs that even actively test Darwin PPC? Or have they died out/moved on to a better life? 16:26:41 I certainly don't. I have a box which could possibly have Darwin PPC, but I disconnected that drive, threw a new one in, and loaded Linux. 16:27:55 darwin ppc is dead; it's been abandoned at the OS level, I don't see much point in continuing to support it at the app level. 16:28:28 nyef: re. our mach stuff. how confident are we that frobbing os_context_sigmask_addr(context) in a signal handler will cause those changes to take effect on return from handler? 16:30:24 I have no confidence in any of the mach stuff at all. 16:31:48 I understand a few of the games we play on mach, because slyrus and I wrote them in the first place, but beyond that I have no real clue what goes on. 16:33:44 Oh, for the love of... 16:34:10 I have a stack of fourteen crash reports from SBCL, all for exception type EXC_ARITHMETIC. 16:35:37 All from the 24th, and all for 32-bit x86. 16:50:00 foom, Maybe so. The only computer I have is a Power Mac G5 with OS X (10.5). A good friend of mine has a G4 and G5. 16:50:23 (and only uses those machines) 16:52:37 I'm considering getting a G4 laptop, but I'd almost-certainly run linux on it. 16:53:46 I've never run Linux on the G5. I have no idea how well it works/would work. 16:54:27 -!- Xof [~crhodes@dunstaple.doc.gold.ac.uk] has quit [Quit: Ex-Chat] 16:54:44 Video can be tricky, as can suspend-to-ram. 16:55:15 Umm... suspend-to-disk tends to work if the video card driver doesn't get in the way. 16:55:59 Actually, I take that back. You may need to hack the kernel to get CPU hotplug to work. 16:56:11 ISTR something went in a few months ago to fix it, but that was after my G5 died. 16:57:30 Radeon seems to work a bit better than nvidia on PPC, but neither seem to be particularly good at suspend-to-ram. 16:58:05 I would expect it to be easier to get KMS+accel working on radeon. 22:42:20 ccl-logbot [~ccl-logbo@setf.clozure.com] has joined #sbcl 22:42:20 22:42:20 -!- names: ccl-logbot foom redline6561_ cow-orker deepfire blackwol` chp LiamH lichtblau drdo homie tsuru` pchrist Phoodus whoops @Kryztof antoszka antifuchs ASau rpg slyrus Intensity @nikodemus_ |3b| sshirokov daimrod fe[nl]ix ljos danlarkin luis jsnell sbryant Quadrescence pkhuong cmm natesm kanru ottergwc flip214 christoph_debian MikeSeth reb```` dsp_ 22:42:20 -barjavel.freenode.net:#sbcl- [freenode-info] if you're at a conference and other people are having trouble connecting, please mention it to staff: http://freenode.net/faq.shtml#gettinghelp 22:42:21 jiacobucci [~jiacobucc@gw-asdl.ae.gatech.edu] has joined #sbcl 22:42:41 peddie [~peddie@88.198.40.136] has joined #sbcl 22:46:18 spacebat [~spacebat@ubermonkey.net] has joined #sbcl 22:58:37 -!- ASau [~user@89-178-12-27.broadband.corbina.ru] has quit [Ping timeout: 240 seconds] 23:01:44 wbooze [~beirc-use@xdsl-87-79-198-84.netcologne.de] has joined #sbcl 23:14:45 homie` [~levgue@xdsl-78-35-129-132.netcologne.de] has joined #sbcl 23:16:38 akovalenko [~akovalenk@95.73.50.234] has joined #sbcl 23:16:44 -!- wbooze [~beirc-use@xdsl-87-79-198-84.netcologne.de] has quit [Ping timeout: 245 seconds] 23:17:04 -!- homie [~levgue@xdsl-87-79-198-84.netcologne.de] has quit [Ping timeout: 244 seconds] 23:18:09 -!- homie` [~levgue@xdsl-78-35-129-132.netcologne.de] has quit [Client Quit] 23:20:34 homie [~levgue@xdsl-78-35-129-132.netcologne.de] has joined #sbcl 23:46:59 drdo` [~drdo@85.207.54.77.rev.vodafone.pt] has joined #sbcl 23:48:51 -!- drdo [~drdo@85.207.54.77.rev.vodafone.pt] has quit [Ping timeout: 244 seconds] 00:12:44 -!- drdo` [~drdo@85.207.54.77.rev.vodafone.pt] has quit [Remote host closed the connection] 00:27:28 -!- LiamH [~healy@pool-108-18-166-81.washdc.east.verizon.net] has quit [Ping timeout: 248 seconds] 00:31:09 -!- cmm [~cmm@109.67.65.220] has quit [Ping timeout: 260 seconds] 00:41:52 cmm [~cmm@109.67.208.140] has joined #sbcl 01:03:46 -!- cmm [~cmm@109.67.208.140] has quit [Ping timeout: 258 seconds] 01:14:37 cmm [~cmm@bzq-79-182-208-83.red.bezeqint.net] has joined #sbcl 01:32:35 -!- cmm [~cmm@bzq-79-182-208-83.red.bezeqint.net] has quit [Ping timeout: 255 seconds] 01:37:21 -!- Phoodus [~foo@ip72-223-116-248.ph.ph.cox.net] has quit [Ping timeout: 244 seconds] 01:44:01 cmm [~cmm@109.64.210.140] has joined #sbcl 01:57:54 -!- rpg [~rpg@216.243.156.16.real-time.com] has quit [Quit: rpg] 02:02:45 drdo [~drdo@85.207.54.77.rev.vodafone.pt] has joined #sbcl 02:50:16 attila_lendvai [~attila_le@87.247.52.86] has joined #sbcl 02:50:16 -!- attila_lendvai [~attila_le@87.247.52.86] has quit [Changing host] 02:50:16 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 03:33:26 Phoodus [~foo@68.107.217.139] has joined #sbcl 03:47:22 attila_lendvai1 [~attila_le@87.247.52.86] has joined #sbcl 03:47:22 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Disconnected by services] 03:47:23 -!- attila_lendvai1 is now known as attila_lendvai 03:47:23 -!- attila_lendvai [~attila_le@87.247.52.86] has quit [Changing host] 03:47:23 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 03:50:59 -!- drdo [~drdo@85.207.54.77.rev.vodafone.pt] has quit [Ping timeout: 252 seconds] 05:12:21 ASau [~user@89-178-106-102.broadband.corbina.ru] has joined #sbcl 05:23:20 attila_lendvai1 [~attila_le@87.247.52.86] has joined #sbcl 05:23:20 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Disconnected by services] 05:23:23 -!- attila_lendvai1 is now known as attila_lendvai 05:23:23 -!- attila_lendvai [~attila_le@87.247.52.86] has quit [Changing host] 05:23:23 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 05:25:27 attila_lendvai1 [~attila_le@87.247.52.86] has joined #sbcl 05:25:35 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Disconnected by services] 05:26:37 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 05:27:24 -!- attila_lendvai1 [~attila_le@87.247.52.86] has quit [Client Quit] 05:54:42 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Disconnected by services] 05:54:42 attila_lendvai1 [~attila_le@87.247.52.86] has joined #sbcl 05:54:42 -!- attila_lendvai1 is now known as attila_lendvai 05:54:43 -!- attila_lendvai [~attila_le@87.247.52.86] has quit [Changing host] 05:54:43 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 05:54:52 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Client Quit] 05:55:20 attila_lendvai [~attila_le@87.247.52.86] has joined #sbcl 05:55:20 -!- attila_lendvai [~attila_le@87.247.52.86] has quit [Changing host] 05:55:20 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 06:13:04 -!- chp [~user@dyn-carl-202-105.dyn.columbia.edu] has quit [Ping timeout: 248 seconds] 06:49:40 angavrilov [~angavrilo@217.71.227.181] has joined #sbcl 06:51:14 sdemarre [~serge@91.176.42.187] has joined #sbcl 07:35:01 -!- sdemarre [~serge@91.176.42.187] has quit [Ping timeout: 252 seconds] 07:37:07 samebchase [~samuel@76.73.121.203] has joined #sbcl 07:37:11 jingtao [~jingtaozf@220.181.151.11] has joined #sbcl 07:46:24 nikodemus [~nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 07:46:24 -!- ChanServ has set mode +o nikodemus 08:31:33 Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has joined #sbcl 08:58:30 -!- jingtao [~jingtaozf@220.181.151.11] has quit [Quit: bye] 09:24:35 -!- antifuchs [~foobar@care.boinkor.net] has quit [Ping timeout: 244 seconds] 09:35:36 pon1980 [~pon@195-67-88-105.customer.telia.com] has joined #sbcl 09:35:55 -!- pon1980 [~pon@195-67-88-105.customer.telia.com] has left #sbcl 09:41:52 milanj [~milanj_@109-93-103-7.dynamic.isp.telekom.rs] has joined #sbcl 09:53:31 -!- |3b| [foobar@cpe-72-179-19-4.austin.res.rr.com] has quit [Ping timeout: 244 seconds] 10:10:13 good morning everyone 10:15:10 |3b| [foobar@cpe-72-179-19-4.austin.res.rr.com] has joined #sbcl 11:29:37 -!- milanj [~milanj_@109-93-103-7.dynamic.isp.telekom.rs] has quit [Ping timeout: 244 seconds] 11:32:09 -!- homie [~levgue@xdsl-78-35-129-132.netcologne.de] has quit [Read error: Connection reset by peer] 11:33:22 homie [~levgue@xdsl-78-35-188-125.netcologne.de] has joined #sbcl 12:23:10 milanj [~milanj_@178-223-168-143.dynamic.isp.telekom.rs] has joined #sbcl 12:41:52 -!- milanj [~milanj_@178-223-168-143.dynamic.isp.telekom.rs] has quit [Ping timeout: 248 seconds] 12:43:16 -!- homie [~levgue@xdsl-78-35-188-125.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 12:45:50 homie [~levgue@xdsl-78-35-188-125.netcologne.de] has joined #sbcl 12:46:21 milanj [~milanj_@77-46-169-35.dynamic.isp.telekom.rs] has joined #sbcl 13:03:11 -!- akovalenko [~akovalenk@95.73.50.234] has quit [Ping timeout: 252 seconds] 13:07:05 akovalenko [~akovalenk@95.72.42.3] has joined #sbcl 13:39:36 nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has joined #sbcl 13:39:42 G'morning all. 13:41:12 -!- akovalenko [~akovalenk@95.72.42.3] has quit [Ping timeout: 244 seconds] 13:59:49 LiamH [~none@pdp8.nrl.navy.mil] has joined #sbcl 14:19:11 akovalenko [~akovalenk@95.73.218.80] has joined #sbcl 14:20:43 -!- Kryztof [~user@81.174.155.115] has quit [Ping timeout: 258 seconds] 14:36:39 nikodemus_: btw, may large object have a size which is an exact multiple of GENCGC_CARD_BYTES? Looks like it could cause remaining_bytes==0 in general_copy_large_object, and then strange things could happen.. 14:40:19 ... should be fairly easy to test, right? You could probably do it with a careful use of MAKE-ARRAY... 14:46:02 nyef: well, the problem is that strange things will not always get noticed. I think, only if the freeish page is reused for boxed object (and that has to do with thread region etc)... 14:47:13 akovalenko: where in there do you see the boundary issue? 14:48:56 nikodemus: gencgc.c line 1495; can it be that remaining_bytes == 0 at that point (after the loop), and next_page is freeish (or worse: reused)? 14:50:53 that's only a speculation, of course (i.e. I didn't actually see any problem, I'm just trying to figure out the cause of Marsden's report by reading the code) 14:54:22 akovalenko: the proximate cause is that i changed a condition in the last loop to an assert inside it 14:55:36 (by accident, that is) 14:59:37 oh, i see what you mean. if an object shrinks by exactly one page, the last page isn't freed 14:59:59 (at least not when copying) 15:00:10 thanks, good to know. Sorry for the intervention :-/ 15:02:07 um, i mean, yes, that doesn't look right. not "yeah, this is known" :) 15:06:11 what i don't actually understand is how the assertion can fail 15:06:46 antgreen [~user@bas3-toronto06-1177890745.dsl.bell.ca] has joined #sbcl 15:06:49 since by the time we assert page_boxed_p, we've already checked that page_table[next_page].region_start_offset == npage_bytes(next_page - first_page) 15:07:08 which means that it should be part of the same allocation region 15:08:19 oh! wait, what if... yeah. if the next page /looks/ like that, but is actually a leftover when an object shrunk by exactly one page? 15:11:12 hmm. Maybe it's possible to get rid of FREE_PAGE_FLAG altogether, or else it's redundant w.r.t. .bytes_used == 0 15:15:05 Would there be any benefit to having genesis emit a page-table and store code objects in appropriately-typed pages? 15:16:03 nyef: doesn't the first dump from a "warm" sbcl get it right, anyway? 15:16:23 I have no idea? 15:17:10 akovalenko: it's not redundant at all. we also use it to mark pages boxed, unboxed, or containing only code objects 15:17:54 nyef: i don't see a huge benefit right now at least 15:18:11 if we had more page types and stronger guarantees than curently, then yes 15:18:35 nikodemus: I know full well that page flag is not redundant generally. Only a particular FREE_PAGE_FLAG for "freenees" seems to have the same meaning as .bytes_used == 0 (well, almost) 15:18:52 Do we /want/ stronger guarantees? 15:19:10 Would genesis following the rules be a necessary precursor to stronger guarantees? 15:19:48 probably 15:20:10 (re genesis) 15:20:38 And, while we're on the subject of genesis and code-objects, the x86 code-object relocation information is currently stored in a separate array per code-object. 15:20:57 don't know about wanting. maybe read-only pages in the dynamic space could be useful 15:21:28 What if we re-purposed the trace-table machinery for that, and persuaded the compiler to emit the appropriate values, so that all of the envectorization stuff can go away? 15:26:24 ... then again, I think I want the trace-table area for something else. 15:32:33 i have no idea, really 15:36:08 I also have a tree that I may put up for review that renames packages from SB! to SB- as their re-creation data is added to the cold-core by genesis, and then turns around and removes all of the *IN-PACKAGE-INIT* damage. 15:37:40 doh. i rejoiced too early remaining_bytes can't be zero at the end 15:37:50 so my theory is wrong