IRC log started Mon Sep 27 00:00:00 1999 [msg(TUNES)] permlog 1999.0927 yeah what's broken now? i think bochs is (897, 442, 1) x /1wx 0xFDD4 --- 0xfdd4 : 0x00000000 (898, 443, 0) x /1wx 0xFDD8 --- 0xfdd8 : 0x00000000 (899, 443, 1) x /1wx 0xFDDC --- when i try to dump a large structure it stops 899 is the step number shruggish trying to figure out how to easily implement read-write locks :) it prints out 443 out of 512 entries and then gets no more input and not having much success because it's hardly to implement them atomically and i don't really want to use cli or mutexes heh -:- eihrul [lee@usr5-ppp109.lvdi.net] has left #tunes [] so, u think its bochs fault or my codes? -:- eihrul [lee@usr5-ppp109.lvdi.net] has joined #tunes so, u think its bochs fault or my codes? how many more lines was it supposed to print out? total of 512 and it got 442 oh wait er, it got half way thru the 443 hmm hrmm, where's core at? odd mmm, segmentation fault when i start bochs and then display that struc it starts on step 12 and goes to 899 but if i do some stepping in bochs i got it upto 340 when it started to display the struc and it stopped at step 947 with only 303 entries read i can't help you... cuz your code is segfaulting :) its gotta be bochs right? 12:10am oh u need the new code hold on i fixed alot of bugs it had with the new bochs u do have the new bochs installed right? yes the problem is in updates.c in update_structure() it just exits what? oh, n'm damn it... i don't have enough time to do this right now i gotta go to bed anyway would have to play around with source trying to get it to compikle, then compile eh? bochs wasn't compiling remember :) oh i know how to make it compile even so... i don't have enough time to compile it :) write this down configure --help will give u a list u want the --enable for debugger and disasm whatever there names are then add that -I. in fpu?makefile kevin fixed the fpu thing in the newest version 990925a i already fixed that but the instrumentation stuff was still fucking up 12:20am only use those 2 options for configure hrmm, really gotta go now though... see ya -:- SignOff eihrul: #TUNES (Leaving) -:- SignOff liar: #TUNES (BRiX [http://www.qzx.com/brix] :: sleep) 12:30am -:- Insane_Inc [Wolfe_Syst@pool-207-205-180-40.phnx.grid.net] has joined #Tunes -:- Insane_Inc [Wolfe_Syst@pool-207-205-180-40.phnx.grid.net] has left #Tunes [Bye] -:- SignOff td: #TUNES (td has no reason) -:- SignOff smkl: #TUNES (Ping timeout for smkl[glubimox.yok.utu.fi]) -:- SignOff Zhivago: #TUNES (Ping timeout for Zhivago[th.merddin.com.au]) -:- Zhivago [brian@th.merddin.com.au] has joined #tunes -:- smkl [sami@glubimox.yok.utu.fi] has joined #tunes -:- SignOff Crimson: #TUNES (Ping timeout for Crimson[chaosdev.org]) -:- hcf [nef@me-portland-us247.javanet.com] has joined #tunes -:- SignOff hcf: #TUNES (Leaving) -:- Downix [down@d-gnaps-202.ici.net] has joined #tunes -:- [wAx] [euoltb@reggae-13-158.nv.iinet.net.au] has joined #Tunes -:- [wAx] [euoltb@reggae-13-158.nv.iinet.net.au] has left #Tunes [] -:- hcf [nef@me-portland-us740.javanet.com] has joined #tunes -:- hcf_ [nef@me-portland-us717.javanet.com] has joined #tunes -:- SignOff hcf: #TUNES (Ping timeout for hcf[me-portland-us740.javanet.com]) -:- hcf_ is now known as hcf hey hey 10:50am what's up? nothing same here talking parallel computing on #stampede 11:00am -:- SignOff Downix: #TUNES (Ping timeout for Downix[d-gnaps-202.ici.net]) -:- hcf has changed the topic on channel #Tunes to: Free Reflective Computing System || http://www.aftersleeves.org/apostle/ || http://www.netpedia.net/sites.html -:- SignOff hcf: #TUNES (Leaving) -:- eihrul [eihrul@usr5-ppp109.lvdi.net] has joined #tunes -:- SignOff eihrul: #TUNES (Ping timeout for eihrul[usr5-ppp109.lvdi.net]) -:- eihrul [eihrul@usr5-ppp114.lvdi.net] has joined #tunes -:- SignOff eihrul: #TUNES (Ping timeout for eihrul[usr5-ppp114.lvdi.net]) -:- eihrul [eihrul@usr5-ppp81.lvdi.net] has joined #tunes -:- water [water@tnt-9-223.tscnet.net] has joined #tunes hello, folks hello i installed linux again, perhaps for good how are things for tunes and you? been reading a lot of papers on thread migration and synchronization lately ok much more practical than the synchronous transactions i was implementing before where're the papers from (univ)? i've just been hunting around on cora a lot oh ok very useful tool yep core has been helpful in letting me know papers about such things exist though :) oh good i'm glad he's helping anything new with tunes? i'm still downloading the last month of email 04:10pm channel's been rather dead lately i suspected that 04:20pm :P eh? this is way too quiet not right now it isn't eh? 04:50pm at the moment i said that statement, it wasn't :P :) ya know, it's interesting that windows crashes drove me back to linux * eihrul/#tunes needs to find papers on practical alternatives to mutexes... co-routines? :) eh? ever used co-routines? not familiar with the term, no so far as it applies to synchronization it's simple... you generalize the idea of sub-routine by not making the return address implicit example? in other words, thread synchronization "co-operative" hmm basically, the threads pass control to each other when they have the necessary data n/m it's been too long since i dealt with that stuff the idea is that there is a shared resource so the data is not necessarily private, and access to this resource must be synchronized but that sounds vaguely like thread migration :) or vaguely like some of the optimistic synchronization methods i've read about thus far there's not a simple way to do it without some sort of meta-programming, imo you could "axiomatize" thread behavior so that the synchronized data access is provided implicitly define "axiomatize" but that would require a (high-level) formally-verifiable language axiomatize = declare via speciying high-level properties like constraints but the something would still have to create mechanisms to meet those constraints co-routines do something like that by being only able to explicitly pass around control yeah, the hll compiler 05:00pm don't know of any such systems programming languages well, you could argue that 'call/cc' could do that thing for scheme or vlisp (since it 's formally-verified) bleh... i'm rambling now since we're the only two people in the channel actually talking, it's not really detremental i suppose i'm trying to do synchronization within the constraint of assembly language (no pun intended) i know that i've heard of a functional hll implementation that handles synchronization pretty well oh unless i could be directed to a suitable language as you describe for static systems and that would be able to interface with assembly (for essential parts of the system that need to interface with the hardware) i went with pure assembly because C was becoming cumbersome sorry i was away for writing an os, right? yessir abi: SLK? i heard SLK was the safe language no-kernel research project at http://www.cs.cornell.edu/slk/ thank you, abi my pleasure water 05:10pm that is a definite option... hopefully they will consider a language like lisp or self though there are still some niceties of paging niceties? it reduces the effects of memory fragmentation since you don't need to allocate runs of pages, but can just map them linearly er.. ok. i follow gc-like ideas more closely but i guess the compiler could anticipate it -:- liar [brand@p0wer.qzx.com] has joined #tunes and generate code to deal with those situations but based on what semantics? wb water hey liar * water/#tunes is about one-third done with email cath-up water: i said 'i guess' s/cath/catch ack, this is java it's not perfect :) i'd rather make my own language than use java they're considering ml, too eihrul: how do u find out where the code is stopping in gdb? bt - backtrace 05:20pm 0x2ac9a534 in __libc_read () water: could ml be suitable for my purposes, or no? look for the last frame inside your application bt doesnt seem to work in xxgdb it could... it's a typed functional language (very similar to typed lambda-calc) or what about caml? most of it's compilers are pretty fast, too i haven't tried caml or ocaml fare pointed it out to me a bit ago haven't looked at it thoroughly yet the concurrency stuff would probably address your questions pretty easily the compiler has to solve it somehow though :) well, sure the ml compiler just happens to have a system for handling it based on language primitives s/ml/caml * eihrul/#tunes is examining an ML tutorial now. * water/#tunes is contemplating how to pare down the remaining 500 messages he has to sift through to the bare essentials sed/grep/etc? * liar/#tunes thinks eihrul and water should find out whats wrong with bfe :) my incoming mail is very eclectic bfe? bfe is probably a graphical frontend for bochs developed by liar and eihrul, http://www.qzx.com/bfe/ eek uuh... no thanks 05:30pm -:- lar1 [LarMan@1Cust25.tnt26.sfo3.da.uu.net] has joined #tunes Hey hey lar1 abi: x to spanish autumn Hey water lar1: babel chunk 62.> lar1: i got some more code u can work on abi: caml? eihrul: bugger all, i dunno damn liar: Ooo! Cool! What is it? lar1: a bug :) liar: uh oh.. :) hrmm, i wonder if any of the local bookstores would carry any ML books not unless it's a university bookshop sigh ML? ML is a family of functional programming languages. SML and OCAML are two examples thanks abi 05:40pm Cómo se dice "autumn" en espanol? onton~o er.. no I thought that was fall? autumn = fall Oh hey! Autumn is a month not a season! * lar1/#tunes feels very stupid autumn IS a season How can it be 2 seasons at once? invierno (winter), primavera (spring), verano (summer), oton~o (fall or autumn) they are synonyms Ohhhhh same meaning, different words I should have payed more attention in kindergarden :) fall -> "falling of the leaves from the trees" very inadequate name... * eihrul/#tunes lives in a desert. which one? nevada cool live near Groom Lake? ;) nah, Las Vegas (deserted in geography as well as intellectually) oh well Well, I am gonna call it Autumn... :) :) :) 05:50pm Anyone ever run a sun 3/50? 06:00pm sorry, no well, i will be going soon Ok, ciao water tell people that i'm back heh ok :) like hcf, tril, beh, fare, ... thanks np bye for now. i will be on again late tonight ok, bye oh yes, and i have a lot of things that i want to do and write darn it, bye! :) -:- water [water@tnt-9-223.tscnet.net] has left #tunes [] :) liar: What do you suguest for a cheap low distortion, 5w audio amp? (not prebuilt) 06:10pm -:- lar1 is now known as lar_away -:- lar_away is now known as lar1 -:- lar1 is now known as lar_away -:- Downix [down@d-gnaps-104.ici.net] has joined #tunes hey hey * Downix/#tunes is getting more info on? -:- water [water@tnt-10-50.tscnet.net] has joined #tunes what a certain former Amiga engineer has been working on which I am looking at using in my companies own product -:- water [water@tnt-10-50.tscnet.net] has left #tunes [] 07:10pm u hear from gw2k yet? have not contacted them yet. Getting a good lawyer first 07:20pm -:- SignOff lar_away: #TUNES (Leaving) -:- td [x@1Cust250.tnt1.wilmington.nc.da.uu.net] has joined #tunes !lilo:*! Hmmmm, apparently a timestamp problem with moore, checking it now. !lilo:*! problem resolved -:- SignOff eihrul: #TUNES ([x]chat) -:- eihrul [lee@usr5-ppp81.lvdi.net] has joined #tunes hey did u get a chance to look at bfe? nope... haven't even had time to work on my microkernel much well i didnt want u to work on yer uk :) i wanted to, however well i want to work on brix but need bfe to do that 09:40pm what's wrong with bfe? i dont know if its bfe or bochs im thinking bochs but i cant proove it if u exceed 899 steps it stops sending output but i did get it to 947 once it doesnt matter how either, u can press step 400 times or load a large structure or a series of small structures and stepping etc... -:- hcf [nef@me-portland-us938.javanet.com] has joined #tunes so i dont see how it can be bfe so try using the bochs debugger without bfe and see if you can duplicate it but i manually (yes it sucked) typed in a combination of 1100 steps, dump_cpu's and memory dumps into bochs and it worked fine hrmm.... buffering perhaps? er, no, that couldn't be it buffering? define 'stops sending output' do you mean it blocks upon trying to read a character? 09:50pm i send a command to writepipe and i get nothing from readpipe xxgdb said it was in __libc_read() in other words... i't blocked ya if u run bfe u will see i have it outputing everything * eihrul/#tunes compiles bochs... it just exists for me what? 10:00pm it's locking up in update_stack () i didn't write that code, so you're on your own :) what did u do? i just stepped right and bfe got blocked in update_stack () line 298 thats cuz it didnt get anything from bochs now try something different so figure out why :P it doesnt matter what part of the code its in, when it reaches somewhere around 900 steps it stops why? open the io_list structure window it will display noralling, then press refresh normally line 92... 10:10pm !devlin.openprojects.net!! Remote CONNECT zsoldos.openprojects.net 8005 from lilo so what u think? i'm debugging, hold on umm, that "Do you really want to quit?" dialog is annoying -:- _ruiner_ [nate@ppp130.wi.centurytel.net] has joined #tunes i know <_ruiner_> I know i should remove it until we're done debugging * _ruiner_/#tunes yawns * liar/#tunes smacks _ruiner_, stay awake -:- Downix [down@d-gnaps-104.ici.net] has left #tunes [] <_ruiner_> whats new? <_ruiner_> or as they say on the streets 'snew? you have some weird streets then, man man the IEEE computer society just wont give up on me <_ruiner_> nah, they changed whats up to sup, I changed whats new to snew i get junk mail from them once a month for the past couple years <_ruiner_> I'm on some ms mailing list im talking about snail mail <_ruiner_> oh <_ruiner_> I keep getting stuff about my parking ticket its only like $150 to join and i get a 1 year subscription to the magazine too :) 10:20pm interesting.... i forced bochs to quit.... or wait.. could have been EOF :) what? u wont get an eof from bochs sigchld should make bfe quit before u can read the eof somethings messing up i just don't know what heh going to try something 10:30pm okay... this should be fun what in popen2 (), i forked off a third process, that intercepts the pipe from bochs, prints it to output, then writes it to the bfe readpipe :) hrmm, kinks hmm] hmm i had it print out the step number for each call to update_xforms() and when i just press step, repeated, it stops at 1034 successfull the context switching makes it work real slow, but it reroutes output :) kewl 10:40pm u should intercept writepipe too so it would display everything :) it's still locking in same place u think its bochs fault? but that's not a bad idea... lemme tyr that i am gonna email kevin if this writepipe thing doesnt tell us anything okay, no idea what's going on could be weird buffering problems but i doubt it since it's going through an intermediate process :) well the old bochs worked so i think its a bug in the new bochs hrmm leemme try putting a usleep () :) and see what happens this is gonna take 3 or 4 minutes :) im gonna try and adapt the code to work with 990923 and 981102 with the flip of a define up to 220 steps so far :) only 600 or so more till we know hahaha dump a structure the io_list that will suck up 800 i did the io_list but it takes a while ah with 5000 microseconds per character :) 10:50pm plus a context switch ouch at 640 now i put the pause in there, but i didn't realize how slow it was :) i should have done 50 microseconds 800... hehhe something definitely fucking up... somewhere because it's getting the command echoed back by bochs... but bochs isn't doing anythign after that i.e. on #899, it prints the command again after the -- but nothing after that er wait... that echo isn't bochs :) what is it? my process it's just fucking up at 899, dunno why dude i'm going to sleep :) did u only modify popen2? yeah, only modified popen2 () can i get a copy -:- SignOff _ruiner_: #TUNES (Leaving) wow u got it down to 1 byte thanks 11:00pm -:- core [core@core.suntech.fr] has joined #tunes core! people hi liar! :) did i tell u that kevin fixed yer e9 in configure? :) everybody-else-who's-dead! liar: no, did he? i didn't have time to download 990925a yet coolness :) core! hey eihrul :) so, did you read *IT*? he fixed it with the other bugs i told him about 'IT' ? you know... it liar: cool.. i guess bugging from users works more than from other developers :-) the thing your girlfriend wouldn't let you read eihrul: the book? :P eihrul: oh. that you were supposed to summarize for me :) eihrul: yeah, but there isn't that much info eihrul: just talks about "intsafe" data what is "intsafe" data? data that can safely be accessed without fear of a context switch on a MP system some way or other i guess :) that i gather... but why is it signifigant? well, somehow it's just safe without using any sync primitives like semaphores or spinlocks but again... that's obvious, if the data isn't modified, then you don't need to sync it i don't know, i have to interrogate the guy again :) my guess is that accesses are done with ints disabled and the scheduler somehow compensates for the time, but it's just me :) or does he talk of ways to "intsafe" writeable data? oh, no, you can modify it :) yeah how do you do that? don't ask me :) is it just like optimistic synchronization? you modify your own temporary copy, then try and commit it? if you can't commit, you re-do everything? maybe :) it's designed for monoprocessor systems interrupts disabled? that defeats the purpose of "intsafe" i don't know how it's done at the low level; the paper never says it. probably on purpose. i'll have to interrogate him :) there must be enough high level descriptions to atleast guess at it no, it just says that the entire system uses intsafe data, therefore it doesn't need semaphores 120 pages!?!? to say that? he must have had a lot of pictures hehe.. well it describes everything - memory management, scheduling, etc lol.. well, there are excerpts of 68K and ARM7 code even :P so he must say more than "intsafe" see above, the entire system behavior is described. so this document had nothing to do with synchronization... it's just an OS outline? yeah, it just mentions, oh, 200 times that his new way obsoletes semaphores :P but never tells the how. i'll find out tho :) we have to figure it out before hand... 11:10pm just so he can feel stupid about not telling :) heheh or even worse, we could accidently guess something better really the only info he gives is that all global data structures are "intsafe" hehe.. that too something like that happened with vga cards, no? :) maybe he forgot, like in medicine man :-) that would suck nah.. i'm just kidding he's 50something but he's not stupid :) global data structures aren't intsafe well, his are :P the only way you could do it is to make sure that two threads aren't stepping on eachother or possibly using really really fine-grained locked or something or perhaps not :) mm.. he doesn't use locks, that i'm sure of. if you locked linked list traversals down to the node though :) maybe he does use a lock but yield()s or somesuch instead of spinning, i don't know but he said the focus was on the data... yup so couldn't be it HA 981102 doesnt lockup its a friggin bug in 990923 so he has to structure the data so that it's either impossible for two threads to access the same data at once i new that bfe was perfect or so that it is safe for two threads to modify the same global data at once time to break the bad news to kevin the previous wouldn't work too well, so it's gotta be the latter :) liar: didn't he just change something? eihrul: right, good deduction i guess :) eihrul: still don't know how you can do that, but it's a start :) core: i doubt 990925a would have fixed it but maybe i should download it before telling him kevin is gonna love tracking down this bug ;) so much that he will probably add my email address to his kill list core: well, there's gotta be a way... :) if he can do it, so can i/we/whoever eihrul: probably :) eihrul: hmm, even using read-modify-write safe instructions like xchg on x86, it's still hard to do :) or if you made the data re-entrant-ish liar: i mean, maybe the new version does something differently, that breaks or desync bfe.. eihrul: reentrant implies private data. yeah... but you could allocate private contexts to modify public data which would be committed at a later time not necessarily immediately you still need global data to manage allocation of private contexts :) 11:20pm well, you don't want your threads to be desync'ed a queue of pending modifications to global data :) still, if the threads read the data, they won't get the right copy until it is commited not necessarily... because when the thread reads the data it's expected the state of the system to be as it was when it "acquired the lock" so you just make sure none of the data gets committed until all reading is finished mmm.. interesting :) these are just half-assed theories i'm throwing off the top of my head :) hehe.. yeah, but it's interesting :) but... as to how it would work for things that need resources attained immediately.... like allocating memory right.. :) unless you put the thread to sleep until it's changes were committed that'd be worse than locking but the committing of resources itself would have to happen exclusively/atomically/whatever which would take a great amount of time depending on how many resources you needed to commit so you'd have to do it 1 by 1 i don't know he makes it explicit that this is a MP system and therefore threads do not execute in parallel :) core: are u aware of the bug im talking about? liar: some problem in bfe? liar: i skimmed through the logs :) core: hrmm, well, it was a fun rant, and i have another one forming in my mind :) core: no, bochs stops sending output after 900-1100 prompts core: i just shot the old bochs beyond 5000 prompts with no problems liar: yeah.. maybe the latest bochs do something differently, that break your front-end ? liar: since you said it works on its own. core: already fixed all that liar: race condition, bad way of reading data, special case that got triggered? core: hmm... what if you only saved the state of the thread upon entering some critical section liar: from what i gather, bfe relies on quite unsafe communication with bochs :) and upon preemption, didn't resave the state :) core: bfe uses 2 pipes core: how is that unsafe? something weird like that... liar: hmm, you rely on bochs not to change its debugger outputs? :) eihrul:that too :) how else is it supposed to talk to bochs? oh, without patching bochs, no other way i guess :) core: bochs did change output format from 981102 to 990925 but i have patched that liar: maybe you triggered a special case? special case? core: only problem becomes that if it's in the middle of playing with some resouurce at the moment it gets preempted, then things are left dangling... so that couldn't work either... 11:30pm but if all it did was read, it'd work fine almost but the writing of data would still have to happen atomically well, reading isn't a problem per se :) so that means just structuring data such that all reads are grouped up front i differentiate read and write locks in clementine even :) and then writing the results atomically in a very dense, timely manner -:- SignOff hcf: #TUNES (Leaving) which would still suck... because then you still have to turn off interrupts i don't know.. judging from the guy it's probably a simple solution, but i might be mistaken. i just don't see a guy who writes code instruction after instruction on paper, come up with something that convoluted :) and your data really isn't interrupt safe :) well i'm getting progressively simpler... first we went form queues of needed changes that suspend the changer, to bulk reads/writes :) but bulk read-writes aren't possible with interrupts on :) you can read all you want with interrupts on maybe he does some scheduler magic when he's about to change data? but you have to turn em off for the writes like, instead of locking, asking more time to the scheduler? that isn't interrupt safe data though... that'd amount to an interrupt safe scheduler.... sure, you don't have to turn interrupts off, just ask the scheduler to delay multiplexing you out just an idea :) but then there's another problem... read data... disable interrupts... write data but what's to guarentee you don't get interrupt, between 1 and 2 only way to prevent that race condition is: disable interrupts, read data, write data so that can't be it no.. ask scheduler to delay switch; read data; write data; say it's ok to switch now but doesn't cli do the same thing? yeah, but it disables ALL interrupts so... what good are interrupts if you can't switch to an interrupt handler? so when you allocate gobs of memory in linux the mouse is strugglish for a second :) you can, not just to the scheduler's s/not\ just/just\ not/ s/linux/amigaos/ i can speak :) say it's a user levle interrupt handler... in another thread :) then what happens? ah, bah, uK's :) you can't get to that thread without going through the scheduler or switching some how yeah i gathered :) so that can't be it either i don't know then :) we must be overlooking something... as you said, it must be simple :) yeah.. would be funny if we did come up with something simple and his solution is more convoluted too :) 990925 locks up just like 990923 that would be cool if i could get rid of test-and-set locks, i'd be happy :) liar: race condition of sorts? either in bochs or bfe eihrul: me too, me too then i wouldn't need dynamic priorities :) 11:40pm since we wouldn't have deadlocks... and the world would be a better, happier place deadlocks are easily avoidable, but no locks would be good :) core: how so? how do you avoid deadlocks then caused by locks? eihrul: by bailing out as soon as you tried to lock something and it failed :) liar: i don't know.. some event that causes bochs to stop accepting commands that was way too obvious.... core: bochs bug :) liar: perhaps.. bug bochs bochs of bugs does your code actually stop on reading the pipe? yup it waits in __libc_read() it blocks on it, or returns 0? blocks on it ahh.. hmm :) and you did write the command? yes write() returned the right number of chars? :) i use fprintf * eihrul/#tunes ponders how to make the data iteself not need locks... what would an interrupt safe linked list be? :) you use a buffered file stream on a pipe? do you fflush() ? no buffering... sure, fprintf uses FILE* which is buffered. nope... sure. setbuf (file, NULL); is that guaranteed to do immediate writes? liar: if you fflush() your stream after the fprintf, what happens? who cares it works liar: it doesn't work, obviously. thats cuz bochs has a bug what's the point of using f*() if you don't want buffering? liar: try the fflush() ? core: fprintf (), fscanf () :) 11:50pm why? liar: that'll make sure the data is actually sent. try it, it costs you 2 minutes. eihrul: hmm, sprintf, sscanf() ? :) it is sent... i put a process between bochs and bfe ya it is sent that intercepted all writes liar: try the flush though? and it even used write () and read () we have already checked everything and i distinctly saw it print the data bfe sent out :) its bochs fault :) i don't think you understand what i mean, but it's okay, i have to go to work :) maybe it isn't actually... see ya :) maybe it is just the lack of buffering -:- SignOff core: #TUNES (ircII EPIC4pre2.003 -- Accept no limitations) how? if there's not enough room in the buffers, it could just "drop" data silently in what buffers? and why doenst 981102 do it? i dunno, maybe it is a bug... wow... there's a dprintf () that operates on a descriptor heh just not a dscanf () hrmm, i'm going to sleep... see ya cya -:- SignOff eihrul: #TUNES (Leaving) [msg(TUNES)] newlog 1999.0928 IRC log ended Tue Sep 28 00:00:00 1999