00:00:00 --- log: started forth/04.04.20 02:19:54 --- join: qFox (C00K13S@cp12172-a.roose1.nb.home.nl) joined #forth 05:45:00 --- join: yeoh (~yeoh@219.95.11.128) joined #forth 05:45:18 Hello, everyone! :) 05:45:45 yeah! 05:46:16 Hi mur. 06:44:47 ss 06:44:49 Er 06:44:50 Hi 06:48:52 --- quit: hovil ("Leaving") 06:56:30 Hi Robert. :) 07:15:52 --- quit: yeoh ("Client exiting") 07:32:35 --- quit: cmeme ("Client terminated by server") 07:32:50 --- join: cmeme (~cmeme@216.184.11.30.unused.swcp.com) joined #forth 07:57:53 my parser seems to be working correct, including ' to lookup words 07:57:55 sweet :) 07:59:22 Congratulations 08:04:06 thanks :) 08:11:45 Duration: 4 sec. 08:11:45 Ran 562 instructions. 08:11:48 Average 140.5 instructions/sec. 08:11:58 seems to be about the max speed i can get 08:11:58 :) 08:12:19 Are you using a vacuum tube computer? 08:12:30 a what? :) 08:12:42 Nevermind... 08:12:49 no its an emulator 08:12:59 in mirc, for the p24 08:13:11 OK, heh. :) 08:13:25 and on that emu i'm trying to get forth working 08:13:39 which is not really usefull at this speed, but w/e 08:16:45 Hehe. :) 11:03:24 --- quit: warpzero ("Tried to warn you about Chino and Daddy Gee, but I can't seem to get to you through the U.S. Mail.") 11:17:18 --- join: slava (~slava@CPE00096ba44261-CM000e5cdfda14.cpe.net.cable.rogers.com) joined #forth 11:17:19 hi 11:19:54 Hi slava 12:01:44 --- join: warpzero (~warpzero@dsl.142.mt.onewest.net) joined #forth 12:06:02 hi 12:37:28 --- join: Sonarman (1000@adsl-64-160-165-184.dsl.snfc21.pacbell.net) joined #forth 12:47:30 --- join: kc5tja (~kc5tja@66-91-231-74.san.rr.com) joined #forth 12:47:37 --- mode: ChanServ set +o kc5tja 12:58:02 --- join: wossname (wossname@HSE-MTL-ppp60346.qc.sympatico.ca) joined #forth 12:59:06 Hmm... 12:59:49 * kc5tja is thinking of re-starting the qm text editor project. 12:59:59 hey kc5tja 13:00:01 what is qm? 13:00:11 I'm reminded of the extreme programmability of VIBE from trying to learn how to use XEmacs. 13:00:31 qm is a text editor project that I started, designed around humane interface concepts. 13:00:40 cool 13:00:51 qm, the name, is an acronym for "Quasi-mode," one of the central and defining characteristics of a humane interface. 13:01:05 yes 13:01:24 I was going to write it in C, because that's the lingua franca of the open source movement. 13:01:36 But, I'm thinking of changing that to Forth. 13:01:44 The rationale is as follows: 13:01:58 1. Emacs is primarily written in Lisp, but with an inner C core. 13:02:18 2. Forth, as a stand-alone language, will *never* find any consistent or standard representation. Even ANSI Forth fails miserably in this department. 13:02:33 3. Therefore, Forth is "most ideal as an embedded language," or as a "scripting language." 13:03:31 So if I were to re-start the qm project, it would be built around a small virtual machine implementation written in portable C, plus some C extension modules that tie it to specific system-level functionality (e.g., X11 and/or SDL bindings, etc). 13:03:49 I mean, think about it: 13:03:54 kc5tja> i finished ' ,succesfully :) 13:03:56 kc5tja: good thinking :) 13:03:58 every *successful* application of Forth has always been *very* application specific. 13:04:02 i'm a bit puzzled about NUMBER? though... 13:04:19 kc5tja, it would be cool 13:04:19 OKAD-II is written in ColorForth, which was designed primarily to support OKAD-II. 13:04:34 Ficl is designed to facilitate the booting of BSD operating systems. 13:04:38 OpenFirmware. 13:04:48 Each of these are Forths, yet all are distinct implementations of the concept. 13:04:54 kc5tja, before i wrote jedit, i tried writing an editor with a postfix extension language in 1997 or so 13:05:05 Thus, a program designed for OpenFirmware won't run natively on Ficl, unless some (small) shimmy is written. 13:05:54 slava: I think that is the fundamental problem: the editor is written in C, and extension languages are written in something else. 13:06:05 The real power of Emacs is that the bulk of the editor proper is itself written in Lisp. 13:06:10 kc5tja, why can't the whole thing be in something like gforth? 13:06:39 slava: gforth would work, but it's rather big. 13:06:40 how do you code POWER ? x^y ... i feel so stupid, but i cant freaking think of a way such so that x^0 = 1 13:06:57 qFox: You must explicitly check for the power of zero. 13:07:07 oh so thats why 13:08:25 slava: The other big problem I have with gforth is that its run-time environment is constantly changing around. Every 0.x version has a totally different means of accessing foreign modules, it seems. 13:08:36 i see 13:08:38 why not fts/forth then? 13:08:59 I agree that gforth would not be the best choice 13:09:03 slava: Well, . . . 13:09:11 slava: I'm not sure you grok'ed what I wrote above. 13:09:20 slava: What I'm saying is to implement a byte-code virtual machine. 13:09:26 ok 13:09:28 slava: Something that remains consistent across all platforms. 13:09:31 you ant portability? 13:09:33 And no, java is right out. 13:09:36 it needs a simple forth that will work the same on different platforms 13:09:42 slava: Yes, otherwise the editor is next to useless. 13:10:06 kc5tja, collaborate with madgarden on his bytecode forth 13:10:18 slava: Maybe. 13:10:34 But then, a bytecode virtual machine is not very hard to write either. 13:10:47 true 13:10:54 Especially if you rely on an existing MISC architecture as prior art. 13:10:55 kc5tja: will you make it so you make it so people can't write endian bugs? 13:11:25 eg the virtual machine always uses big endian 13:11:36 Herkamire: There are only two requirements for endian independence: you have guaranteed-big-endian fetches and stores, and guaranteed-little-endian fetches/stores. 13:12:06 Herkamire: Therefore, @ and ! would store information in the machine's most natural form, but B@/B! could be guaranteed big-endian, while L@/L! could be guaranteed little-endian. 13:12:50 I don't like the idea of always requiring multi-byte quantities to be stored in big-endian, because it creates a performance hit. 13:13:45 I don't see how that (B@/b!) helps 13:13:46 I prefer to have a proliferation of accessor words to handle the various cases, because then maximum performance is always guaranteed, it makes for clearer code (I think), and I feel it's more portable, actually. 13:13:55 you still have to know what endian your machine is right? 13:14:07 99.999999% of the time, no. 13:14:19 or do you mean that B@ would always fetch the least significant byte? 13:14:19 Why would you? 13:14:30 for a text editor extension language i would not allow direct pointer manipulation 13:14:32 I just explained: B@ would be a guaranteed-big-endian fetch. 13:14:34 --- join: tathi (~josh@pcp02123722pcs.milfrd01.pa.comcast.net) joined #forth 13:14:35 you don't want random macros crashin your editor 13:14:55 Likewise, L@ would be a guaranteed-little-endian fetch. 13:15:06 slava: With Forth, you really don't have a choice. 13:15:14 hmm... 13:15:16 Moreover, it really ought not to be an issue. 13:15:27 kc5tja: I don't understand how that would work 13:15:42 On big-endian machines, the C core would map B@ to @. 13:15:55 On little-endian machines, it'd map B@ to code that did byte-swapping automatically. 13:16:08 yay for standards! 13:16:09 :\ 13:16:35 Likewise with L@. 13:16:41 (and for B! and L!, etc) 13:16:53 so you still have to be careful only to use B@ or L@ on memory that you stored as a whole word 13:17:13 Well, endianness is irrelavent for individual bytes anyway. 13:17:13 You should really almost never have to worry about it though... 13:17:37 how often do you store a cell of data and then fetch a piece of it? 13:17:43 (or vice versa) 13:17:50 tathi: Almost never in any sanely written piece of code. 13:17:59 Even in Forth code, I *never* do that. 13:18:13 I do 13:18:28 but I could easily avoid it for a cross platform app 13:18:30 Well, umm... I have to say that that isn't my problem then. :-) 13:18:44 kc5tja: yeah, me neither. 13:18:57 ok, I see the use of B@ at L@. it's for people who want to store a word and fetch a byte of it. 13:19:04 Realistically speaking, though B@/B! and L@/L! family of words are primarily used only for importing or exporting data to file formats, or for accessing graphics memory. 13:19:06 it makes it so they can be easily cross-platform. 13:19:16 but it doesn't stop people from writing endian bugs 13:19:57 Herkamire: So what? That is not my problem. I cannot be the personal nanny of every Thom, Dick, and Harry who wants to write modules for qm. 13:20:23 that's fine 13:20:23 I mean, Emacs Lisp certainly doesn't prevent people from writing buggy software either. 13:20:32 I think this is a good solution. 13:20:52 I was just curious of you were going to try to make it so people couldn't write code that would work on one platform and not another. 13:20:55 There is one, and only one, way to eliminate the situation entirely: Use N-bit bytes, where N is the native word width of the host platform. 13:21:21 what? 13:21:42 Example: the F21 understands precisely one and only one fetch or store width: 20 bits. 13:21:46 No more, no less. 13:21:54 or you can only store/fetch bytes 13:21:54 Thus, it's "cell" is the same width as its "character": 20 bits. 13:22:14 Herkamire: That's not even possible. 13:22:22 sure it is 13:22:38 you write a version of ! for each endian. it breaks the word up into bytes and stores them to memory one at a time 13:22:41 Herkamire: If you can only store/fetch bytes, for some definition of a byte, then the program would be so god-awful slow as to make people wonder just what the hell you were smoking when writing it. 13:22:57 I know it's slow 13:23:09 that's why I agree with you choosing not to do it 13:23:14 slow... 13:23:16 This is why I have @, B@, and L@ -- @ is the machine-native word, so that it is niec and fast. 13:23:27 my p24 is a mean lean 140hz cpu :p 13:23:37 i tested it today 13:23:50 Woohoo! 140IPS! :D 13:23:55 hell yes 13:24:21 and that is WITHOUT any form of output or debugging :p 13:25:20 But if you make the character the same size as a cell, then you don't need any additional fetch or store words: a single @ and ! will suffice in this case. 13:25:27 And endianness becomes irrelavent. 13:25:50 B@ and friends only work properly if the words were stored aligned in memory right? 13:26:18 Herkamire: No, they'd be able to work anywhere in memory. 13:26:23 As with @ and !. 13:26:46 so you pass the address to the word, and you call B@ and it gives you the most significant byte 13:26:53 No. 13:26:58 It gives you a full 32-bit word. 13:27:06 BIG-ENDIAN FETCH. :) 13:27:17 It just treats the data as if it were stored in a big-endian layout. 13:27:31 Likewise, L@ does the same, but treats the 32-bit word as if it were stored in little-endian layout. 13:27:42 oh I get it 13:28:07 :) 13:28:12 so if you know you want to fetch the bytes independantly, you b! into memory, and fetch using the regular character fetch 13:28:37 I was getting confused partly because b@ is byte-fetch in herkforth 13:28:40 B! or L!, depending on your needs. 13:30:08 At any rate, Emacs just got me thinking about all this stuff, that's all. 13:30:39 I think it's a great idea 13:30:45 people would tinker with it and learn a little forth 13:30:47 Looking at the size of xemacs, the executable is a monsterous 8MB in size. 13:31:12 but a lot of functionality 13:31:19 8mb is nothing 13:31:25 8mb is huge 13:31:29 slava: Most of the functionality is coming from the 25MB of Lisp macros I have installed. 13:31:52 True, 8MB contains the Lisp core, and the pre-compiled modules comprising the core Emacs editor. 13:32:08 But the extensions for it, which are used more often than most people think, all come from the external Lisp macros. 13:32:16 s/macros/functions/ 13:32:22 only a minority of the code is Lisp macros i imagine 13:32:38 You know what I mean. Don't get overly pedantic. 13:32:38 :) 13:32:59 I wonder something... 13:34:37 xemacs is using 8MB or so of RAM for its code size, and another 4MB for the data space (which I'm assuming is the heap for the Lisp). 13:34:50 Hence, we're looking at about 12MB of total memory consumption, which is close to what I figured. 13:35:08 Not bad for a program that is essentially doing absolutely nothing at the moment. :) 13:37:59 OTOH, gvim, editing the same file, takes up 8MB. 13:38:07 my forth will only have 256k of system/user space :p i am not going to screw around with memmory pages 13:38:40 vim takes up 6MB (without running an X window) 13:39:29 how do you find out how much memory a program is using? 13:42:45 ask kindly. 13:42:48 :P 13:44:53 qFox: Would you be so kind as to tell me how much memory are you using? 13:48:11 I use 'top' personally. 13:50:39 uhm 13:50:48 3*userspace bytes :p 13:50:51 technically 13:51:41 Size boot-code: 1671 bytes. UA is at 557 13:51:55 that includes the input, eval, output buffers, and a few constants 13:52:22 but the bootcode isnt finished yet :) 13:52:46 I like top, but I don't know what column is memory usage, and what the units are 13:54:30 RSS is used to describe how many kilobytes are used for an executable's code and static data image. 13:54:49 The column immediately to the right (on my version at least) is used for dynamically allocated memory usage, also in kilobytes. 13:55:15 I guess RSS stands for Resident Software Size, but I'm not too sure on that. 13:55:22 I've never seen an explanation of its acronym. 13:55:52 ok, so you add RSS and SHARE 13:56:05 and that's KB 13:56:18 As far as I can tell, yes. 13:56:50 ok 13:56:56 I'll write that down 13:57:34 well, the help in top says "Resident Set Size" 13:57:39 whatever that means. 13:57:48 Oh, I was very close. 13:57:59 yup yup 13:57:59 It could be that RSS includes the dynamically allocated storage then. 13:58:16 The Working Set is a name describing all the bytes dedicated to an application. 13:59:01 so it is possible that the RSS includes only those chunks of memory belonging to a program that are resident in memory (e.g., not found in the swap space). 13:59:32 In which case, Emacs takes up less RAM than I expected. 13:59:53 However, the file size was also 8MB in size, so that's where my hypothesis came from. 14:19:19 slava, my Forth actually isn't a bytecode Forth. 14:19:46 --- nick: madwork_ -> madwork 14:34:07 should * return one or two numbers? like should you only return the lower part of the result of multiplication, or high-low? 14:34:25 winforth seems to only return one 14:34:53 * always returns a single cell. 14:34:58 oki 14:35:26 Of course, if you want, you could make * do whatever you want: return the lower part on the stack, and the upper part in the A register, or whatever. 14:35:42 (FTS/Forth does this, as a natural consequence of choosing EDX to be the A register) 14:38:41 --- quit: wossname ("gtg") 15:05:32 hm i think i did it, write NUMBER? ,now to test theory in practice :p its gonna be fuck slow too, since there are two *'s per digit.... and * is 34 instructions alone :p 15:28:52 Why two *'s per digit? 15:29:32 well, the way i currently designed it 15:29:54 take one digit 15:29:58 from right to left 15:30:08 check if digit is within range of current base 15:30:47 multiply digit-48 with 1 (first time its 1...) 15:31:00 add result to total 15:31:08 then multiply 1 with base 15:31:16 and take next char 15:31:23 hence, two * 15:31:24 Whoa. 15:31:33 ah, thats all wrong? ;) 15:31:36 If you parse numbers left to right, you need only one multiplication per digit. 15:31:40 no 15:31:41 oh 15:31:42 sorry 15:32:03 how do you figure? 15:32:12 Well, take the number 25. 15:32:21 Is this not (2*10)+5? 15:32:31 yes.. 15:32:50 Well, let's now look at 256: (((2*10)+5)*10)+6 15:33:13 hm 15:33:35 well i already figured there was a better way anyways :) 15:33:36 If you distribute the multiplication, you end up with (2*100)+50+6 15:34:01 that would save me reversing the whole thing too 15:34:36 (for right-to-left its easier to reverse, since there's no dec/inc instruction) 15:35:20 so i did this whole thing for nothing 15:35:22 grrr 15:35:33 :) 15:35:39 Learning experience. 15:35:56 you would've hated it anyways 15:36:17 i was juggling with 6 stack items on both stacks :p 15:36:26 but, on paper, it would work 15:36:39 Yes, your solution would have worked. 15:36:44 But it would have been big, and slow. 15:36:55 yea, compared to yours 15:37:00 :) 15:37:12 but for a first time, with no working example... i'm proud of it 15:37:12 :) 15:37:17 * kc5tja nods 15:39:16 so, take digit, check for validity, add to total, (begin), take next digit, check, total * base, total + digit, again. this untill the end of string is reached, or untill the check returns false 15:39:32 Still easier way to do it. 15:39:36 Set accumulator to zero. 15:39:42 Since zero times base is always zero anyway. 15:39:43 So: 15:40:20 set accumulator to zero. (begin) total * base, take next digit and check, total + digit, loop until end of number. 15:40:47 basicly the same, but mine would be considerably faster at 140hz... :) 15:41:32 Well, it's up to you, of course. 15:41:41 should perhaps tear down the base*1 as well 15:41:57 uhm.. well you know what i mean 15:42:00 but yea 15:42:09 * qFox goes about coding this 15:43:56 oh and my tick isnt working properly... apppearantly its not traversing thru the whole tree of the dictionary :p 15:44:11 i just hadnt noticed since i only tested the last dictionary entry 15:50:05 oh ye, and my check word, takes the char, substracts 48 from it, and checks either the result is < then base. returns true if <, false if not 15:50:33 that'll allow me to take just about any base up to 36, i believe, with no problems 15:50:53 perhaps even 64, since i'm not case sensitive (yet...) 15:55:26 remove the not. 15:59:20 Problem is, 'A' does not immediately follow '9'. 15:59:54 uhm, its not? ascii table has been too long then :\ 16:00:21 oh, ouch 16:00:43 gah that'll just make things harder 16:01:09 is there an easy way to check either the digit is within the range of BASE ? 16:01:37 : >digit ( ch -- n ) 48 - 7 over 9 > and - ; 16:01:43 48 - you already know about. 16:02:11 7 over 9 > is a phrase that returns either 0 or 7, depending on whether or not the `digit' is greater than 9. If it is, the value is 7. Otherwise, it's zero. 16:02:18 err, 7 over 9 > and 16:02:33 The final - subtracts the resulting value once more, thus yielding the final digit value. 16:03:10 ok, thats close to what i had in mind 16:57:11 --- quit: Sonarman (Connection reset by peer) 16:58:46 --- join: Sonarman (1000@adsl-64-169-94-126.dsl.snfc21.pacbell.net) joined #forth 17:07:41 --- join: ianp` (nobody@c-24-13-109-164.client.comcast.net) joined #forth 17:14:12 --- quit: Sonarman (Read error: 60 (Operation timed out)) 17:16:43 --- join: blockhead (default@dialin-605-tnt.nyc.bestweb.net) joined #forth 17:21:21 --- join: Sonarman (1000@adsl-66-124-255-158.dsl.snfc21.pacbell.net) joined #forth 17:25:42 --- quit: qFox ("this is mirc's last attempt of communication...") 18:35:08 --- join: lalalim (~lalalim@p508AB14C.dip.t-dialin.net) joined #forth 18:52:58 --- quit: lalalim_ (Read error: 110 (Connection timed out)) 19:44:58 --- part: blockhead left #forth 20:33:34 --- quit: Sonarman (Read error: 104 (Connection reset by peer)) 20:41:13 --- join: Sonarman (1000@adsl-64-160-165-20.dsl.snfc21.pacbell.net) joined #forth 22:11:43 --- quit: Sonarman ("leaving") 22:24:56 --- join: Serg (~z@212.34.52.140) joined #forth 22:32:31 * kc5tja is back. 22:41:07 hi 22:41:14 how's your comp ? 22:41:37 Haven't had any chance to work on it of late. 22:42:15 But since I'm basically dropping out of math class (I already failed it, no further point in continuing to attend classes, especially for stuff I already know), MAYBE I'll have more time for it. 22:42:20 Though I really doubt it. 22:42:39 Since I'm still working on that coding project for my client, which I basically am really losing interest in big-time. 22:43:52 hm... 22:44:39 do u know any hand-solderable CPU what is being produced now in big quantity, and is not likely to be ceased ? 22:46:36 Yes. 65816. 22:46:39 That's why I'm using it. 22:47:01 Motorola ? DIP ? 22:47:09 Western Design Center. 22:47:18 http://www.westerndesigncenter.com 22:47:30 It comes in either PLCC or DIP packages. 22:48:17 any big RAM in DIP ? 22:49:09 * Serg has idea-fix of comp makeable by any teenager - like RU Spectrum clones 22:49:39 No. 22:49:53 Nothing in large capacity is being offered in DIP form. 22:50:03 Nor is anything in the speed range that I'll be running the Kestrel at. 22:50:21 As I said, the motherboard logic of the Kestrel still ends up being in a surface mount package. 22:50:33 no matter what I do, that is the *only* way to make the product affordable. 22:50:49 speccy rulez, but it's weak sides are: 1) bad "OS" (really absence of OS) 2) Non-flat RAM, pages switch differently in different clones 22:51:19 Well, you can make a name for yourself, I'm sure, by offering an operating system for it. 22:51:41 It ought to be quite doable. Heck, if multitasking Unix clones can appear for the Commodore 64, something similar can definitely be done for the Spectrum. 22:53:02 i can make only infame for myself and idea, coz many antique devices gonna die in ROM resoldering 22:53:38 These Spectrum machines all use disk drives to store data, right? 22:53:59 And can therefore load and run programs from disk, yes? 22:54:11 yes, but 1) have too little RAM for an OS 2) many proggies use ALL RAM 22:54:18 There isn't a single OS for the Commodore 64 that replaces the built-in ROMs. Not a one. 22:54:36 Hogwash. 22:54:43 You are thinking too much inside the box. 22:54:50 ?? 22:55:06 I recommend doing some research on the OSes available for the Commodore 64 before you make such statements. 22:55:27 Remember the C64 had only 64KB of RAM. The Spectrum has at least that much. 22:55:33 hmmm... emu ? src ? 22:55:45 Google. 22:56:22 CHAOS, GEOS (and its myriad of clones), Lunix, etc. 22:56:35 Lunix is even open source, last I recalled. 22:56:48 i think, no multi user/task, but all BSD syscalls what applicable 22:57:01 Lunix did limited multitasking. 22:57:40 And I know it also supports multiple running processes (it'll swap out to disk when necessary), so CTRL-Z, bg, and fg all worked. 22:58:07 Of course, if you push it, it slowed down immensely (due to the sluggishness of the Commodore floppy drives more than anything else) 22:58:35 Remember that the original Unix ran on a machine with only 64KB of addressible memory. 22:59:28 Now, I'm not saying that you *should* do something like this. 22:59:33 I'm just saying that it is *possible*. 23:00:59 the bad thing: lotsa soft wrotten for ROM only ;( 23:01:14 Man, today was the first time I'd gone to aikido in a long time. I'm definitely going to be hurting tomorrow. :D 23:01:37 whom u gonna hurt ? ;) 23:01:50 Well, that comes with the territory; when GEOS first came out for the C64, it certainly didn't have very many applications either. 23:01:57 Huh? 23:02:04 I'm going to be hurting tomorrow. 23:02:22 I'd like to see you do several hundred rolls after a seven month hiatus. :) 23:02:41 And then not feel anything the day after. 23:03:08 --- join: hovil (~hovil@CommSecureAustPtyLtd.sb1.optus.net.au) joined #forth 23:03:28 --- quit: Herkamire ("off to bed") 23:11:42 --- quit: hovil ("Leaving") 23:22:45 dhamn, some RU guys wrote yet another ZX os, but it needs hardware mod ;(( 23:33:26 --- quit: Serg () 23:36:15 --- join: hovil (~hovil@CommSecureAustPtyLtd.sb1.optus.net.au) joined #forth 23:54:08 --- quit: warpzero ("Tried to warn you about Chino and Daddy Gee, but I can't seem to get to you through the U.S. Mail.") 23:58:09 --- join: warpzero (~warpzero@dsl.142.mt.onewest.net) joined #forth 23:59:59 --- log: ended forth/04.04.20