00:00:00 --- log: started forth/00.12.04 00:40:56 * aaronl is away: juhaha 06:59:15 --- quit: ult (Read error to ult[149.149.201.30]: Connection reset by peer) 08:16:22 --- join: ult (ultima@149.149.201.30) joined #forth 08:30:59 --- join: hcf_ (nef@207-172-225-25.s25.tnt1.pld.me.dialup.rcn.com) joined #forth 08:35:24 --- nick: hcf_ -> hcf 09:04:55 --- part: hcf left #forth 10:36:45 --- join: aaronl_ (aaronl@vitelus.com) joined #forth 10:37:33 --- quit: aaronl (Read error to aaronl[vitelus.com]: EOF from client) 10:45:05 --- quit: I440r (barnes.openprojects.net adams.openprojects.net) 10:45:05 --- quit: aaronl_ (barnes.openprojects.net adams.openprojects.net) 10:45:18 --- join: aaronl_ (aaronl@vitelus.com) joined #forth 10:45:24 --- join: I440r (mark4@purplecoder.com) joined #forth 10:55:15 --- mode: ChanServ set mode: +o ult 11:05:22 --- topic: set to 'http://isforth.sourceforge.net -- http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/isforth/?cvsroot=isforth' by ChanServ 11:05:27 --- mode: ChanServ set mode: -o ult 11:11:45 --- join: hcf (nef@207-172-225-25.s25.tnt1.pld.me.dialup.rcn.com) joined #forth 11:11:51 I440r: u here? 11:13:17 hi 11:13:17 yea 11:13:20 sorta 11:14:08 r u still expecting clog to respond? 11:14:42 i dunno hehe 11:14:45 is clog a bot ? 11:14:52 do '/whois clog' 11:15:03 aha hehehe 11:15:05 #lisp did and realized, i expect u to do the same 11:15:30 who is the log for ? 11:18:15 http://www.tunes.org/~nef/logs/forth/ 11:18:32 the logs for sorta for tunes 11:19:14 k :) 11:22:40 ok, bye 11:22:42 --- part: hcf left #forth 11:27:17 oh no... were in trouble now, everything we say is LOGGED argh hehe 11:45:32 --- quit: ult (Leaving) 12:08:34 --- mode: ChanServ set mode: +o clog 12:08:38 --- mode: ChanServ set mode: +o aaronl_ 12:08:42 --- mode: ChanServ set mode: +o I440r 16:39:39 --- nick: aaronl_ -> | 16:40:04 --- nick: | -> aaronl 16:58:55 --- join: edrx (edrx@200.240.18.88) joined #forth 17:56:41 --- quit: edrx (Ping timeout for edrx[200.240.18.88]) 18:30:10 --- join: MrReach (mrreach@209.181.43.190) joined #forth 18:30:18 hihi! 18:31:07 * MrReach rereads I4's statement/question carefully. 18:31:22 aha there u r :) 18:31:27 --- mode: I440r set mode: +o MrReach 18:31:31 ok heres my delema 18:31:47 yes, it should break 18:31:58 hrm thats what i thunked hehe 18:32:05 executing the instruction will cause the MPU to read that memory location 18:32:12 yes 18:32:19 ergo, break 18:32:32 thats what i thunked, just wanted a second opinion :) 18:32:57 it sounds like you have decided to include the ability 18:33:10 to set seperate read and write breaks? 18:33:12 oh i knew i would be adding this rite from the start 18:33:35 but i dont know if i should distinguish between code reads, external ram reads and internal ram reads 18:33:43 have you implemented a "watch" function? 18:33:53 a read of address 0 from any could be a break... 18:34:03 heh, too bad you're not wring for Win32 or XWin 18:34:04 or i could set the breaks up tp be specific to each area 18:34:14 slighly more compecated but not overly so :) 18:34:23 * MrReach nods. 18:34:42 if i could guarantee a million a year income from a win32 version of this priogram i would NOT write it 18:34:46 i wont support doze 18:34:47 at all 18:34:48 grrr 18:34:55 ill code ans forth first :P 18:35:15 (that shud get a laff or 2 :) 18:35:16 hey, I restumbled across something today that I'd like to kick a few ideas around 18:35:20 are you game? 18:35:27 sure 18:35:29 fire away 18:35:36 have you seen lib4th yet? 18:35:58 ive seen it but not investicated it, i dont like using other peoples libraries 18:36:12 ok, fair enough 18:36:30 if i need a function i can generally write a better version of it than exists in any libaray 18:36:42 libraries are written to be general 18:36:44 have you considered the implications of what would happen if if one were to wrap the entire forth system as a shared library? 18:36:48 i think every routine should be specific 18:37:00 wouldnt work 18:37:04 not for me... 18:37:06 oh? 18:38:01 why do u think im writing isforth with NO library calls 18:38:01 please think general programming systems ... not whatever project you're currently using 18:38:01 i could include stdlib and bloat my code 18:38:01 or i can write the small parts of it that i need from scratch 18:38:03 i am totally against ALL "general" code 18:38:03 not calling a library ... keeping the system as shared memory image 18:38:14 changes the rules quite a bit if you think about it 18:38:45 u thihnk very high level, i think very low level 18:39:01 i think every function should be re-written from scratch every time u need it 18:39:26 imagine an ELF file (or .EXE for that matter) only 1k in size that is the ETIRE forth system 18:39:40 i do not like the idea of my code using someone elses possibly buggy code 18:39:44 ETIRE=ENTIRE 18:39:49 i would rather limit my bugs to MY bugs :) 18:39:58 one has to trust whatever kernel they're using 18:40:12 granted 18:40:14 even if it's your own code 18:40:29 you could say that by using syscalls im in effect using a library of someone elses code 18:40:47 but im not wrapping that up with 6 or 7 levels of libraries 18:40:56 this lib calls taht lib calls that lib calls the kernel... 18:41:00 im calling the kernel 18:41:17 i have to draw the line somewhere, or else completely bypass linux hehe 18:41:21 linux wouldnt like that :P 18:41:55 when i coded for the amiga the first thing i did was disable all interrupts, disable all task switching 18:42:01 call main 18:42:06 re-enable both 18:42:08 exit 18:42:14 ok, what I realized ... 18:42:44 is that the executable only needs ONE call, to something like "get kernel image" 18:43:13 a library consumes memory and clocks when its first loaded 18:43:23 but after that, it's completely free 18:43:29 ? 18:44:13 ok, a typical program has basically two parts ... a static part and a dynamic part 18:44:25 k 18:44:28 the static part is what goes into the bin file, right? 18:44:58 and, often, the loader needs to load 3-12 shared libraries before it loads the bin 18:45:20 erm load shared libs BEFORE loading the bin ??? 18:45:20 in forth, things are a bit different ... 18:45:21 erm no 18:45:23 thats wrong 18:45:32 load bin and the BIN loads the shared libs 18:45:54 yes, ldd loads libraries and does linking fixups before the process starts, as part of loading the bin file 18:46:08 erm no i dont get it 18:46:28 the bin file loads all its shared libs when it executes 18:46:32 they arent loaded for it before it even loads 18:46:35 are they ? 18:46:53 heh, if you look at the format of the ELF file, most of the shared libs are listed in the headers, and are loaded BEFORE the code seg starts executing 18:47:16 erm 18:47:20 hehe 18:47:23 i knew that.... 18:47:23 honest,... 18:47:27 hehe 18:47:27 ok 18:47:27 continue 18:47:29 there *IS* a libc call to load a library manually ... but that is usually not used 18:48:03 ok, now in most forths, anything below FENCE simply CANNOT be changed 18:48:19 or forgotten 18:48:37 words like AND OR NOT colon , etc 18:48:51 the base system is nearly always protected 18:48:56 yes 18:49:24 ok, so if one were to move all this into a relocatable memory image 18:49:24 erm u mean have the kernel as a shared libaray and have executables not include the kernel ?????????? 18:49:28 wow!!!!!!!!!!!!!! 18:49:33 HAHAHA! 18:49:43 you got it! 18:49:53 im not as think as you dumb i am 18:49:56 hehe 18:49:57 instant load time ... only a handful of fixups, at most 18:49:58 argh 18:50:20 ok... 18:50:23 ZERO memory usage for each interpreter (practically) 18:50:29 can shared libs be executed directly ? 18:50:47 new defs would have to go into conventional program memory, of course 18:50:48 forth-kernel.so.1.0.5 18:50:54 yes, they can 18:50:55 can u run that as an executable ? 18:51:02 no, you cant 18:51:05 erm 18:51:08 thats no good then 18:51:15 there needs to be a stub for a base system 18:51:26 because wnat if all i want to do is interpret a file as if it were a script 18:51:35 ok, I said there would have to be one conventional lib call 18:51:48 i would need a forth executable that loads the kernel 18:52:38 hrm 18:53:21 ok, we need to setup the user data area, the dictionary area, and another stack before we can start 18:53:28 how would primatives be called by the application code 18:53:30 all these have to go in r/w memory 18:53:34 it would slow things down alot 18:53:43 the same exact way forth would call them 18:53:58 there woluld need to be a jmp table 18:54:36 we wouldnt call 1+ dup drop ect directly 18:54:37 once the user data, dictionary, and stack are set up .... we can call the "COLD" entry point ... IN THE LIB IMAGE 18:54:43 yes, we could 18:54:46 we would call the nth jmp of the jump table 18:54:52 no 18:54:54 we couldnt 18:54:58 heh 18:55:03 because when we updated the forth kernel 18:55:13 the location of dup or drop mite change 18:55:21 but the location of the JMP to dup wouldnt change 18:55:26 is that the executable only needs ONE call, to something like "get kernel image" 18:55:34 i.e. we wouldnt break forth aps when the kernel changed 18:56:02 ok, that's quite true ... however ... how often does the stable kernel actually change? 18:56:13 quite often 18:56:25 saving an APPLICATION only writes a slightly larger ELF file 18:56:26 and even if it only changes once every year or so 18:56:48 that change would be catastrofic to all the applications that use the kernel at that time 18:56:50 the new ELF file contains only our new definitions, and loads the same old kernel 18:56:51 THAT would be bad 18:57:21 it would be like direct-indirect threading ehhehe 18:57:29 directly threaded to an indirect :P 18:57:31 hehehe 18:57:31 erm 18:57:32 no, each new kernel gets it's own version ... /usr/lib/forthlib1.2.23 18:57:55 well then every single app would REQUIRE a specific version of the forth kernel 18:58:13 i wouldnt want to break all forth apps just because of a forth kernel update 18:58:20 an app using a specific kernel version MUST load that particular kernel version or fail ... granted 18:58:36 no 18:58:38 bad 18:58:43 no, just fine 18:58:51 most kernel updates would be the adition of a new word 18:58:55 because kernels are only 50-80k or so 18:59:00 not the removal of one 18:59:02 that is correct 18:59:11 so if my app calls the a specific word in the kernel 18:59:21 that would would prolly still be there and still function identically 18:59:26 BUT the new words would not neccessarily be at exactly the same offeset in the kernel image 18:59:33 why break that app just because that word moved within the kernel 18:59:49 unless you wanted to do some time of runtime lookup or indirection 18:59:59 the apps wouldn't break, though 19:00:04 --- join: TheBlueWizard (TheBlueWiz@216.25.203.26) joined #forth 19:00:08 hiya all 19:00:18 because NEW kernel versions install beside current kernel versions 19:00:24 greets, wiz 19:00:34 hiya MrReach 19:00:53 if an app works now, it will still work when the new forth kernel lib is installed 19:01:00 mrreach no, i dont like the idea of breaking every forht app just because dup moved within the kernel 19:01:14 please reread 19:01:14 there should be call vectors at a known location within the kernel 19:01:33 and the vector to dup would not change between versions 19:01:43 erm 19:01:56 so we would have 2984562937845 different versiuons of the forth kernel 19:01:58 bad bad bad 19:02:09 kernels seldom change 19:02:19 maybe once a year, as you said 19:02:41 so in ten years ... maybe 10 kernel images in /usr/lib 19:02:53 erm 19:02:53 no 19:02:59 i do not like this 19:02:59 each one has a 50-100k memory footprint 19:03:17 an application should not be dependant on a specific version of the kernel unless it realy is 19:03:23 * TheBlueWizard is wondering exactly what MrReach and I440r are talking about.... 19:03:25 dup didnt change, it jsut moved 19:03:32 and, for god's sake, if you're using an app that was compiled 10 years ago, time to recompile the silly thing 19:03:36 a dynamicaly loaded forth kernel 19:03:46 each app would use a shared lib kernel 19:04:02 Wiz: a system like lib4th ... where the entire system is in a shared lib, except for new defs 19:04:03 mrreach erm do you still run a 10 year old app 19:04:05 ? 19:04:09 any 10 year old apps ? 19:04:26 I might, but I can guarantee it's been recompiled sometime since then 19:04:36 actually, I don't think so 19:04:50 because I upgrade systems every two years 19:04:51 hmm...I assume this lib4th would be run under Linux, eh? 19:05:17 Blue: theoretically, it could run equally as well under Linux or Windoze 19:05:32 the current lib4th runs under linux, yes 19:05:54 I was looking at how it was built, and discussing the dis/advantages 19:05:55 the idea is a very good one but i still say that there should be a vector table for every word in the kernel 19:06:02 ok 19:06:04 ah....hmm....it'd be an unusual lib4th thingie in the sense that its interface would be unique.... 19:06:07 and the vectors should NOT change at all 19:06:08 a design issue 19:06:26 that way no apps will break on kernel update 19:06:33 I hold the the kernel will change so seldomly (once stable) that direct calls can be made 19:07:01 but then the kernel changes and the user has to reconmpile all 29846528376542 of his forht apps 19:07:04 not good pr 19:07:17 also, an already running app will still run after a new kernel is installed, it just won't use it 19:07:50 yes 19:07:57 it will still use the old kernel 19:08:04 it will continue to use the old lib 19:08:11 then the user updates the old application and the old kernel becomes deadwood 19:08:17 and deadwood would accumulate 19:08:17 yep 19:08:26 bad bad bad 19:08:27 unless he got another old app 19:08:29 um...what type of Forth (subroutine threading, direct threading, ....) would your Forth app use? 19:08:33 the jmp table would prevent all this 19:08:45 HAHA! 100k of deadwood on the HD is a fatal flaw? 19:08:50 ther are only two real types of threading 19:08:54 direct 19:08:54 indirect 19:09:02 most binaries ship with MUCH more debug info than that 19:09:04 the rest dont exist 19:09:13 so dont try convince me otherwise:P 19:09:14 hmm...and lib4th would support both threading types, eh? 19:09:28 sure, threading doesn't matter 19:09:29 erm isforth executables will ahve ZERO debug info in them 19:09:51 go look at a typical ELF binary produced by GCC 19:10:02 there's GOBs of debug and link-up info 19:10:08 none used at runtime 19:10:25 MrReach: exactly the reason i say that c in general and gcc in particular are crap 19:10:26 but anyway ... the lib idea has serious merit 19:10:46 mrreach it definatly does have merit hehe 19:10:58 but not if an update would break a single app when it doesnt realy have to 19:10:58 nearly instant load time (comparatively), and nearly zero memory footprint 19:11:19 imagine rewriting every single linux app in forth :)))))) 19:11:36 ok....assuming Forth apps would use such threading, one scheme is to "reverse thread" the kernel level words, and upon loading, the app would get "rewoven" by walking thru those "reverse threaded" addresses, replacing each cell with the actual address...just my 2 cents 19:11:38 actually, that might be easier than expected 19:11:58 blue: actually, it doesn't have to be that complex 19:12:23 when the app starts, it makes one "regular" lib call, to something like "get image address" 19:12:48 that adr is stuffed into an index register ... and all kernel words are called relative to it 19:13:14 tbw in other words have the kernel report to the app the address of every primative and then the app could relocate all the calls 19:13:24 at fixed adresses, just like any other forth 19:13:37 slow the initial loading down and add complecation but would solve the problem also 19:13:50 which problem? 19:14:02 breaking of apps when kernel is updated 19:14:21 people are already pissed off enough with libc on that score 19:14:22 your assuming that a kernel update must supplant the old kernel? 19:14:32 every time libc changes all apps that use it break 19:14:35 prity much 19:14:41 YES 19:14:42 i am 19:14:44 I'm holding that when a kernel is "published" ... it's fixed for life 19:14:57 no changes, ever 19:14:59 because the apps wouldnt load forth-kernel.s0-2.0.5.3 19:15:06 they would load forth-kernel.so 19:15:13 but, because they're so tiny to start with, it's not a big loss 19:15:13 which would be a sym link 19:15:58 actually, the stub should do that ... but not a saved application 19:16:07 the idea is actually simple....example: : myword1 .... dup ... dup ... ; : myword2 ... dup ... ; would get compiled to [reverse threaded kernel word table] (myword1 header) .... (ptr to 2nd instance of dup) .... (ptr to 3rd instance of dup) .... ;s (myword2 header) .... (ptr to 4th instance of dup) ... ;s so to fix up dup addr, just walk thru those each pointer cells, writing in the actual address of dup as it goes.... 19:16:17 * TheBlueWizard ducks 19:16:31 yes 19:16:44 i understand taht tbw but its an over complecation 19:16:45 that is what ldd does now, actually 19:16:46 i would rather have 19:16:48 jmp dup 19:16:52 jmp drop 19:16:53 jmp rot 19:16:57 jmp nip 19:16:57 so would I 19:17:04 NO YOU WOULDN"T! 19:17:08 at static locations within the kernel 19:17:19 that's STC and it's NOT Forth! 19:17:27 no 19:17:27 * MrReach chuckles. 19:17:49 the kernel wouldnt need to call the jmp table 19:17:56 IT knows the addresses already 19:18:13 anyway, the threading method is irrelevant to the library 19:18:14 but apps that share the kernel will NEED a static reference to the words within that kernel 19:18:25 or else they would break every time the kernel changed 19:18:25 not acceptable 19:18:39 the apps would directly thread within themselves 19:18:39 only if the current kernel were changed 19:18:44 erm 19:18:45 dood 19:18:48 i already said 19:19:03 applications will not call on a SPECIFIC version of the kernel 19:19:09 they would load forth-kernel.so 19:19:27 not forth-kernel.so.2.0.54-blah 19:19:27 yes, but you didn't make it clear why they shouldn't call a specific version 19:19:33 yes i did 19:19:44 oh, could you repeat? 19:19:47 old versons of the kernel would become deadwood 19:19:58 i have 28937456238479 apps that use a specific version 19:20:00 ok, how much deadwood is that, worst case? 19:20:03 i update 27864 of them to a new version 19:20:08 * TheBlueWizard thinks he is losing the thread (pun intended :) 19:20:10 238746589 of the rest to another version 19:20:16 then the rest to a more recent version 19:20:21 etc,etc,etc 19:20:25 ok, so three versions, so far 19:20:33 i now have 28947652893745 different forth-kernel.so versions installed 19:20:35 and what is the calculated loss? 19:20:42 and i cant tell which ones i can safely delete 19:20:55 accumulated deadwood 19:21:02 bad bad bad 19:21:04 yes, but how much deadwood? 19:21:11 over the years ????? 19:21:16 alot moer than is acceptable 19:21:42 tell me how much ... I'll give an ipinion if it's too much 19:22:02 having a jmp table at the head of the kernel image bypasses the need for apps to depend on a specific version of the kernel 19:22:06 you, of course, will have a somewhat different opinion, hopefully not too different 19:22:21 unless words were dropped or changed 19:22:38 dropped, changed, moved 19:22:45 --- join: Fare (fare@ppp28-net1-idf2-bas1.isdnet.net) joined #forth 19:22:46 or the threading model changed because of a new processor 19:22:53 the only one there that has a right to break an app is the second one 19:22:54 hiya Fare 19:22:59 hi 19:23:03 hi fare 19:23:10 --- mode: I440r set mode: +o Fare 19:23:50 --- mode: I440r set mode: +o TheBlueWizard 19:23:50 fare is ur nick registered ? 19:23:50 I agree, i4, current apps should NEVER break, whatever the cost 19:23:50 (hence DOSEMU) 19:23:50 yes, it is 19:24:06 but, a table causes a bit of slowdown with every nest 19:24:25 and strict versioning causes images on the disk that might not be needed 19:24:44 it's the lessor of two evils 19:24:49 fare... exit and re-enter 19:25:15 i think the jmp table is the only acceptable solution 19:25:18 it solves ALL that 19:25:39 it adds a little overhead to the size of the forth kernel and to the execution speed 19:25:53 be back in 1/2 hour 19:25:57 --- nick: MrReach -> MrEating 19:25:57 but ONLY when making calls between the app and the kernel 19:25:58 k 19:26:00 :) 19:26:14 fare exit #forth and re-enter 19:28:40 --- part: Fare left #forth 19:28:42 --- join: Fare (fare@ppp28-net1-idf2-bas1.isdnet.net) joined #forth 19:28:51 --- part: Fare left #forth 19:28:52 --- join: Fare (fare@ppp28-net1-idf2-bas1.isdnet.net) joined #forth 19:28:52 --- mode: ChanServ set mode: +o Fare 19:29:07 :) 19:29:09 ok 19:29:12 that werked hehe 19:29:16 :) 19:29:23 tbw is your nick regged ? 19:29:36 my nick is registered, yes 19:29:47 ok do same :P 19:29:53 you can type /msg nickserv info TheBlueWizard to see the whole scoop hehe 19:30:03 --- part: TheBlueWizard left #forth 19:30:04 hehe 19:30:11 --- join: TheBlueWizard (TheBlueWiz@216.25.203.26) joined #forth 19:30:12 --- mode: ChanServ set mode: +o TheBlueWizard 19:30:19 :P~ 19:30:19 works :) 19:30:29 * TheBlueWizard shrugs 19:30:58 ops dont mean anythinbg ti me either 19:31:08 they used to tho hehe 19:31:21 i was a high access channel op in 9 channels on undernet once 19:31:37 well, op do give you the rights to set /topic, kick-ban some jerks, etc. hehe 19:31:39 then i saw the way ops behaved there and dropped all access 19:31:50 (it don't mean a thing if it ain't got that swing) 19:31:55 hehehe 19:31:58 fare :P 19:32:25 ops isnt power, its responsibility 19:32:31 when u look at it that way 19:32:38 yup 19:32:46 i op just about anyone that comes in here hehe 19:32:53 if they come in here they deserve ops hehehe 19:33:46 hehe....this IRC community is generally very well behaved...I've seen a lot worse hehe...like in #sex for example lol 19:34:38 :) 19:34:38 TBW: asl? Will you have sex with me? 19:34:38 then again not many ppl care about Forth (I know, I know...it's the reality!) 19:34:38 fare... ur an expert i see :) 19:34:43 u know the drill hehe 19:34:46 lsa? me with sex have you will? 19:34:48 * TheBlueWizard laughs uproariously re: Fare's query 19:34:54 by the way... gore lost 19:34:57 AGAIN!!!!!!!!!!!!!!! 19:34:59 hahahah 19:36:13 Gush and Bore are the same. 19:36:13 has the last two judicial trials been completed re: election lawsuits? 19:36:13 Republocrats, demoblicans: reapers of the nation 19:36:13 florida circuit judge found against gore on ALL COUNTS 19:36:16 gore is gona take it to florida supreme court 19:36:25 saw that on TV already 3 hours ago 19:36:46 but they wont change a thing because the us supreme court has already reversed the florida supreme courts previous ruling 19:36:49 yeah....though I won't hold my breath on this appeal 19:36:52 any partitioning expert around? When to use tags 0C 0D or 0F ? 19:36:57 the appeal will fale 19:37:07 erm no idea 19:37:21 * TheBlueWizard is no partitioning expert...sorry! 19:41:20 my ultimate political fantasy: US Supreme Court rules that both Bush and Gore be disqualified on technical grounds, so the winner goes to....Nader! And watch the political chaos ensues 19:41:46