00:24:35 -!- alms [n=alms@146-115-42-237.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has quit [] 01:04:40 alms [n=alms@146-115-42-237.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has joined #ccl 01:13:55 -!- billstclair [n=billstcl@unaffiliated/billstclair] has quit [] 01:26:27 billstclair [n=billstcl@unaffiliated/billstclair] has joined #ccl 02:11:09 -!- gbyers [n=gbyers@c-68-35-15-143.hsd1.nm.comcast.net] has quit [] 02:19:06 jauaor [n=araujo@gentoo/developer/araujo] has joined #ccl 03:33:05 bfulgham_ [n=brent@adsl-69-234-109-59.dsl.irvnca.pacbell.net] has joined #ccl 05:10:42 -!- rme [n=rme@pool-70-105-112-40.chi.dsl-w.verizon.net] has quit [] 05:35:40 -!- bfulgham_ [n=brent@adsl-69-234-109-59.dsl.irvnca.pacbell.net] has quit [] 05:48:37 bfulgham_ [n=brent@adsl-69-234-109-59.dsl.irvnca.pacbell.net] has joined #ccl 06:36:59 -!- bfulgham_ [n=brent@adsl-69-234-109-59.dsl.irvnca.pacbell.net] has left #ccl 07:03:39 -!- jauaor [n=araujo@gentoo/developer/araujo] has quit [] 07:06:46 vy`` [n=user@nbvyazici.cs.bilkent.edu.tr] has joined #ccl 07:06:50 -!- vy` [n=user@nbvyazici.cs.bilkent.edu.tr] has quit [Read error: 104 (Connection reset by peer)] 07:18:29 -!- vy`` is now known as vy 08:40:36 -!- Modius_ [n=Modius@24.174.112.56] has quit [Read error: 110 (Connection timed out)] 09:38:11 jauaor [n=araujo@gentoo/developer/araujo] has joined #ccl 14:50:00 -!- vy [n=user@nbvyazici.cs.bilkent.edu.tr] has quit [Remote closed the connection] 15:21:31 -!- jauaor [n=araujo@gentoo/developer/araujo] has quit [] 15:30:33 i have a question: is there a lot of lisp code that needs to be added/modified when preparing a port? 15:30:40 especially, low-level lisp things? 15:31:11 or is it enough with the kernel-loader (that is in C)? 15:31:43 There's the OS-specific stuff, and the compiler. 15:31:55 i can hack C and i can deal with low-level cpu-specific stuff in it as well, but i can't deal with low-level lisp code. 15:32:00 So it depends on how much changes in teh port from an existing port 15:32:35 If you're porting to a different machine, you'll have lots of compiler changes 15:32:47 It took quite a while to add 32-bit Intel, for example 15:33:13 It being so different from 64-bit Intel. Practically a whole different machine 15:33:15 well, i've mostly been trying to add support for netbsd/x86 based on the freebsd/x86 code, but everything i've played with has been in C or ASM so far. 15:34:10 gb or rme would be the guys to talk with. Neither here right now 15:34:43 yupp. i'll wait for them, thanks. 15:48:50 rme [n=rme@pool-70-105-112-40.chi.dsl-w.verizon.net] has joined #ccl 15:53:27 rme: ah, i've been waiting for you to join. :) 15:53:39 rme: you did the freebsd port right? 15:54:21 I did the x8632 backend and the Darwin/x8632 port. 15:55:07 well, you know if i would be forced into low-level lisp code if i was to port from freebsd/x86 to netbsd/x86? 15:55:35 i can handle C and ASM, but i might just as well drop it if it includes a lot of low-level lisp hacking. 15:57:44 I don't think there is very much. 15:58:22 ok. good. thanks. :) 15:59:15 You'll need to define a new "foreign type data" structure and possibly mess with ffi stuff. 16:00:08 I would expect that the netbsd ffi stuff would be similar to freebsd, so you'd probably escape having to deal with any really low-level gunk there. 16:01:45 hmm, ok. 16:03:04 See, for instance, ccl:compiler;X86;X8632;x8632-backend.lisp. That's where you'd define the :netbsdx8632 FTD. 16:03:56 You'd define *netbsdx8632-backend* there, as well. 16:04:00 ok. i'll look into that. 16:04:48 Or, if you'd rather do the 64-bit port first, look at the corresponding files in ccl:compiler;X86;X8664; 16:05:20 heh. i'll try with x32 first. i am more familiar with the i386 cpu then the new stuff. 16:05:26 segv [n=mb@ita4fw1.itasoftware.com] has joined #ccl 16:06:31 Note that we want to use a segment register to point to thread local data (the "thread context record" or TCR. Operating systems differ on how to do that; we use i386_set_ldt() on freebsd; I assume netbsd has that, too. 16:12:00 I've never ported to just a new OS, but I think I'd probably start by trying to get a netbsd lisp kernel to the point where it will try to load, say, a freebsd heap image. 16:12:21 that is pretty much what i am trying to do. :) 16:12:36 i just make in the lisp-kernel and fix all errors. 16:12:53 i'll have to fix cpu-context stuff that differs, etc. 16:15:11 Well, don't hesitate to send mail to the list if you have questions. 16:15:48 i'll just give it a shoot. it would be /so/ darn nice to have a production ready common lisp on netbsd. 16:15:53 there really is none at the moment. :( 16:16:33 and i've even tryied to emulate the linux binary, but only GLIB_2.3.3 complaints with that. 16:28:13 jauaor [n=araujo@gentoo/developer/araujo] has joined #ccl 17:01:25 -!- segv [n=mb@ita4fw1.itasoftware.com] has quit [] 17:51:19 segv [n=mb@ita4fw1.itasoftware.com] has joined #ccl 18:02:26 milanj [n=milan@93.87.194.237] has joined #ccl 18:31:12 heh. the kernel didnt approciate the freebsd image. :) 18:35:56 -!- jauaor [n=araujo@gentoo/developer/araujo] has quit [] 18:46:14 It might be useful to set a gdb breakpoint on toplevel_loop. When you get there, you are about to start running lisp code. 19:42:08 malsyned [n=malsyned@adsl-75-35-185-146.dsl.wlfrct.sbcglobal.net] has joined #ccl 19:42:46 How come :UTF-32BE with a dash but :UTF32LE without one? 19:43:38 Actually, how come :UTF32LE (no dash) if #-big-endian-target but :UTF-32LE (with dash) if #+big-endian-target 19:45:43 And also, and harder to fix, how come: 19:45:43 CL-USER> (string #\Greek_Capital_Letter_Epsilon) 19:45:43 "^Z" 20:02:20 Good catch on :UTF32LE without a dash; it should have one. Will fix. 20:03:18 rme: yeah. #3 0x08055f4d in toplevel_loop () at ../x86-subprims32.s:46 20:03:43 Also, and this is minor, the docstring on :UTF-32 is not line-wrapped so it looks weird in the output of (describe-character-encodings) 20:09:50 malsyned: the #\greek_capital_letter_epsilon thing is due to the lisp and your terminal/emacs/whatever not agreeing on the encoding. 20:12:01 (will also wrap the docstring) 20:12:55 hypno: so you ran some lisp code? 20:14:33 rme: depends on how you define that, heh. i've yet to get a repl. 20:14:45 rme: i think this is likely to be a out of my league. 20:14:58 rme: so it's totally an output error, and the string is actually holding #\Greek_Capital_Letter_Epsilon internally? ah, yes, I've just verified that with encode-string-to-octets, and you're right. 20:15:02 hypno: heh. 20:20:19 hypno: Getting the lisp running on another x86 unix is not too bad for someone who has been there before, but since you're new to the process, it's probably true that you're looking at a time investment that you might not be all that interested in making. 20:20:52 Although if you are, I'll try to help as best as I can, for what it's worth. 20:22:33 is it possible to build without threads? 20:22:39 ie, some define somewhere? 20:23:30 No, there's no flag to leave threads out. 20:24:19 ok. 20:46:48 -!- segv [n=mb@ita4fw1.itasoftware.com] has quit [Read error: 110 (Connection timed out)] 21:34:08 anRch [n=markmill@nmd.sbx07258.melroma.wayport.net] has joined #ccl 21:46:12 -!- malsyned [n=malsyned@adsl-75-35-185-146.dsl.wlfrct.sbcglobal.net] has left #ccl 22:25:46 -!- anRch [n=markmill@nmd.sbx07258.melroma.wayport.net] has quit [] 22:39:06 -!- milanj [n=milan@93.87.194.237] has quit ["Leaving"]