00:00:00 --- log: started forth/06.09.06 00:43:45 --- join: Cheery (n=Cheery@a81-197-19-23.elisa-laajakaista.fi) joined #forth 01:04:13 fission you're in a church, and you're not allowed to gaze upon the idols. get busy and obey or quit and move on. 03:51:22 --- quit: Snoopy42 (niven.freenode.net irc.freenode.net) 03:54:13 b00 03:54:15 --- join: Snoopy42 (i=snoopy_1@dslb-084-058-119-000.pools.arcor-ip.net) joined #forth 03:54:22 re 03:54:24 --- join: snoopy_1711 (i=snoopy_1@dslb-084-058-119-000.pools.arcor-ip.net) joined #forth 03:58:19 --- quit: Snoopy42 (Read error: 145 (Connection timed out)) 03:58:34 --- nick: snoopy_1711 -> Snoopy42 04:37:02 --- join: PoppaVic (n=pete@0-1pool47-116.nas30.chicago4.il.us.da.qwest.net) joined #forth 04:57:34 --- join: vatic (n=chatzill@ool-45740b1c.dyn.optonline.net) joined #forth 05:23:54 --- quit: TreyB (Read error: 110 (Connection timed out)) 06:14:58 --- join: Ray_work (n=Raystm2@199.227.227.26) joined #forth 06:15:46 Good morning. 06:15:53 howdy 06:16:15 hey PoppaVic. How's things? 06:16:44 so'k, the sneezing spell just stopped.. 06:17:03 God bless you. :) 06:17:22 Notice I don't just say bless you, it's because I'm not the lord. :) 06:17:34 yeah - I had a spell there where I lost my glasses AND sight ;-) 06:17:59 Yikes, that's a bad one. Dust? 06:18:20 nooo idea, just started - BANG - although, I "smell" dust 06:18:44 Your fan motor prob'ly passed a big one. :) 06:19:54 heh 06:20:24 or, the weather and bopping thru the house induced the fit and I'm smelling old cigs ;-) 06:20:59 I hate that smell, and I smoke. 06:21:15 Ashtrays make me ill. 06:21:24 No idea, anyway.. But, it's stopped - so I can glare at code and whimper. 06:21:42 * Ray_work nods* 06:22:45 --- join: geneven (n=geneven@70-32-206-42.ontrca.adelphia.net) joined #forth 07:29:04 --- join: TreyB (n=trey@cpe-66-87-192-27.tx.sprintbbd.net) joined #forth 07:30:54 --- quit: TreyB (Client Quit) 07:31:23 --- join: TreyB (n=trey@cpe-66-87-192-27.tx.sprintbbd.net) joined #forth 07:39:48 --- join: virl (n=virl@chello062178085149.1.12.vie.surfer.at) joined #forth 07:54:59 --- quit: PoppaVic ("Pulls the pin...") 07:56:36 --- join: PoppaVic (n=pete@0-1pool74-65.nas24.chicago4.il.us.da.qwest.net) joined #forth 08:27:47 --- quit: virsys (Remote closed the connection) 08:31:51 --- join: virsys (n=virsys@or-71-53-74-48.dhcp.embarqhsd.net) joined #forth 09:09:14 --- nick: segher_ -> segher 09:11:33 --- join: saon (i=1000@c-71-199-235-144.hsd1.fl.comcast.net) joined #forth 09:47:15 --- join: rabbitwhite (n=roger@136.160.196.114) joined #forth 09:55:41 --- quit: rabbitwhite () 10:01:34 --- join: JasonWoof (n=jason@unaffiliated/herkamire) joined #forth 10:01:34 --- mode: ChanServ set +o JasonWoof 10:09:00 who remembers how fig-model vocabularies were? 10:09:17 predated wordlists 10:09:24 fixed-form and searches 10:09:40 15 minutes with some FIG source will show you 10:09:45 using tree analogy; (hey Vic) the main trunk is where core-words are linked 10:09:57 yeah, all RAM 10:10:13 Not even a generic llist 10:10:35 new vocs are created temporally in the current voc 10:10:45 no 10:10:54 so that (using `.' to separate newer vocs like a path. 10:11:07 forth.x.y.z 10:11:11 vocs are CREATE 'd and you are adding DEFINITION 's and such 10:11:14 forth cant see y or z 10:11:18 right 10:11:25 and x cant see z 10:11:40 yeah, it would - because of all the other assumptions of char, word, line 10:12:02 i dont frankly know why that kind of namspacing was abandoned 10:12:22 PoppaVic this is what i think of since you said `namespaces' to me 10:12:36 --- quit: vatic ("Chatzilla 0.9.74 [Firefox 1.5.0.6/2006072814]") 10:12:45 in that voc/branch scheme, there's protection and privacy 10:13:10 and it's just the normal way of doing things in that scheme 10:13:15 no stack, no fuss no muss 10:13:33 simplified their lives 10:13:33 ..let them skip all the lower issues 10:13:33 ..trust me, I've been glaring too 10:13:35 I'm beginning to believe at least WORDLISTS (vocs) should inherit or overload "scanning" 10:13:52 and with vocs, it becomes easier to save branches to a file 10:14:14 ..not remotely sure what to do with these gut-feels, though 10:14:19 as a whole voc per file that can be loaded on an aligned boundary 10:14:26 maybe 10:14:36 aligned is ANOTHER issue - binary 10:14:40 that might help ld.so too 10:14:53 don't think .so and such 10:15:00 swithcing to ponder non-forth executable binaries: 10:15:27 ld.so loads them on 4k alignment iinm and then fills in their rdynamics and loads libs 10:15:28 unless yer writing a collection of libs to r/w .o, .foo, .bar, .snafu - don't bother. 10:15:29 k? 10:16:13 it could be easier to develope a private threading model, since only 4 or 5 register values need to be saved in a forth vm 10:16:17 that's fast 10:16:20 I've about concluded that reinterpreting source is best.. NOW, if you can conceive of an INTERMEDIATE format, fine. 10:16:47 first you'd have to use 32bit relofs for links and pointers 10:16:52 ..and, yeah - the I format suggests an engine 10:16:56 nope 10:17:05 well you cant use abs ptrs 10:17:12 bingo 10:17:14 for an INTERMEDIATE format 10:17:21 so use relofs 10:17:36 Quiznos: yer still thinking mixed-mode and level. BUT, you will get there. 10:18:06 ...I'm about pooped-out at this point, though - catch me tomorrow. 10:18:06 also, as host-os native code is rewritten in forth, fewer and fewer packages need to be installed 10:18:30 ok nn 10:18:51 final thought 10:18:57 stay well.. I need a snooze... Back in MY am ;-) 10:18:57 --- quit: PoppaVic ("Pulls the pin...") 10:19:10 he's on the east coast 10:19:12 with me 10:19:16 1300h 10:19:18 now 10:19:49 He's right, though, keep at it and you will get there -- right where he is, completely mired in misunderstanding and confusion. 10:21:00 FIG vocabularies are a primitive outcropping of a single linked-list; I can't imagine how you'd implement them in a more sophisticated dictionary-lookup scheme, or in other words in any modern Forth. I also can't imagine why you'd want to. 10:21:05 nah 10:21:35 ok, i'm heading towards fp style of coding. 10:22:06 Dictionary structure has what to do with fp, or fig vocabularies? 10:22:09 ie, as Backus's 1979 functional programming described it 10:22:36 more flexibility, fewer limits, fewer "boxes" to deal with 10:22:57 FIG vocabularies are not more flexible; they depend upon a specific implementation technique and are quite limited. 10:23:03 howso? 10:23:58 a voc word is just two cells for ptrs and one runtime word to select current-voc and/or the voc in which new words are linked to 10:23:59 Each is a branch from a given point on a linked list. They cannot be re-ordered such that you can search one branch ahead of another. Again, I cannot see how you would implement them in any structure more sophisticated than a linked list. 10:24:24 perhaps with a double-linked list 10:24:46 which would also assist with a better forget word 10:24:51 Which is taking your primitive linked list and making it take more space in memory. Any optimized approach to dictionary searching would make it tremendously difficult to implement. 10:25:11 i'm not writing for resource-limited computers 10:25:28 i'm writing for linux hosted computers 10:25:28 Come up with some reason why the FIG model is more flexible or provides a better facility than the search-order model, and you'll have a leg to stand on. 10:26:05 i didnt say FIG was ``more flexible'' i'm just pondering one or a couple of aspects of various models that i've seen 10:26:31 quartus, one big diff tween Vic and I is that i'm more than willing and able to make decisions; in contrast to Voc 10:26:34 vic 10:26:56 i'm picking and choosing concepts and ideas for implementing in my Forth to test them 10:27:07 I already know what I want to be able to do 10:27:20 You would do well to understand how each model works before painting yourself into an implementation corner by deciding on an antiquated model out of ignorance of the alternatives. 10:27:55 and while I agree with some of the comments from you folks here that Vic is kind of in a cloud in what he wants to do, i do have several things/concepts/idears that i want to implement and play with. 10:28:26 of course, thats correct and I'm doin alot of reading and pondering in the area of what i want to do and how to do it 10:28:53 i've written some pseudo/real code to see how it looks (several idears) and i'm gettin there 10:29:20 so, if you're going to compare me to Vic, do so only in the most general sense. 10:29:50 anything else? 10:30:47 ok. 10:34:41 --- join: rabbitwhite (n=roger@136.160.196.114) joined #forth 10:35:08 re rabbitwhite 10:50:15 I've found for me the best way to test my ideas is to implement them 10:50:30 it gives me a pretty good idea if they are any good, and what they are good for 10:52:51 agreed 10:53:20 what!? A practical approach?! What about the obviously-required endless maundering about voc + semantic!? 10:53:36 it's part of the process 10:53:49 i just go through it faster than Vic 10:53:51 best thing i've heard someone else say in this channel so far 10:53:59 rabbitwhite which? 10:54:26 --- quit: uiuiuiu (Remote closed the connection) 10:54:28 --- join: uiuiuiu (i=ian@dslb-084-056-233-172.pools.arcor-ip.net) joined #forth 10:55:10 i like how forth lets you 'feel your way' into an idea by building it slowly starting with a kind of sketchy skeleton 10:55:39 it lets you feel like real men.. ;-P 10:55:52 that's one way of putting it i guess 10:56:28 forth is too addicting though, i get so focused on how fun it is to implement that i forget about other stuff 10:56:58 and the best part is, i think that if more people were using it, i probably wouldnt focus so much attention on that aspect 10:59:04 people are using it -- but not very many students, so the web isn't littered with Forth source. 10:59:56 but it does help to have a goal. 11:01:42 lisp is more interesting for students 11:03:48 i'm turned off by the apparent fetish for parentheses 11:05:13 yeah. me too, for me it's a reason to not using it. 11:07:24 yesterday my C++ professor tried to guide the class through a Hello World program .. 11:08:04 can you believe that two versions of Bloodsheed Dev-C++, 4.0 and 4.9, are not even source compatible 11:08:54 source code for Hello world was 12+ lines 11:09:00 resulting binary 75 kilobytes 11:09:05 =/ 11:09:16 must be statically linked? 11:09:19 it was embaressing, i felt it was embaressing for both the teacher and the students 11:09:24 i guess so 11:10:47 but the really amazing part was here is this widely used compiler - VERY widely used - and you cannot compile source code written for one version in the same x.0 with another. part of those 12+ lines was trying to get it to work on everyone's machine 11:12:05 how are they incompatible? 11:13:50 the protocol for getting the standard routines to be compiled was different. 11:14:10 ah okay 11:14:13 not only that but the library names were different too 11:14:44 stdio in 4.9 was stdlib in 4.0 11:15:12 --- quit: geneven (Read error: 54 (Connection reset by peer)) 11:15:18 and its like .. WHY make such a big change? when you've got so many users. 11:15:56 doesn't seem like too bad of a change since a quick pass through sed would fix it 11:16:43 if you're working on a single project, sure 11:17:06 but the change seemed superficial. just adding problems. 11:17:30 hmm yeah 11:18:06 and what's worse is, we can never know when theyre going to change up on us again 11:18:34 so it's like theyre teaching this thing that the students cannot be certain will be true in any other context than the computer they use in class 11:19:11 is it C++? well, not quite, because it's not guaranteed to always be standard compliant 11:19:43 not that that really matters ... the part that concerns me is really just the fact that Dev-C++ is ill-defined 11:20:37 the programmers of dev-c++ didn't seem to have their shit together when they created this compiler ... at least at the time around version 4.0 and 4.9 11:20:45 i'm done my rant 11:20:55 heh 11:21:44 and i'm not really angry, just worried for the students, and aware of the huge waste of time 11:22:11 hmm why isn't forth taught in school? 11:23:49 that's right why isn't it. if i get the job the school is telling me they might have for me soon, they be doing just that, and with my forth to boot >:P 11:23:55 *might 11:24:35 i guess it's hard for people to grasp a language that somehow is halfway between assembler and lisp =p 11:26:32 most people i show forth to have a really hard time grasping it it seems (people that are already programmers in OO or imperative langs) 11:27:32 particularly when i try to show them examples because the algorithm isn't really clear amidst the stack movement 11:29:32 they just need to get those top 3 stack slots ingrained into their brains 11:30:07 is there any way to really teach stack juggling? 11:30:10 i wouldn't show newcomers code that had more than a dup or an over in it 11:30:16 it seems to only come from experience 11:30:26 well, i'd teach them to not do it 11:30:42 i try to avoid to use swap or rot for instance 11:30:57 i use swap a bit, try to avoid rot mostly 11:31:15 --- quit: Snoopy42 (Read error: 131 (Connection reset by peer)) 11:31:22 well.. it's a nice obfuscation tool 11:31:44 i guess you could just make them write practice routines over and over again 11:31:54 --- join: Snoopy42 (i=snoopy_1@dslb-084-058-108-185.pools.arcor-ip.net) joined #forth 11:32:43 assignment would be to write a certain algorithm in 30 characters or less 11:43:23 i don't know how much could actually be taught in a short amount of time though 11:43:37 unless it was like, really intense 11:44:11 does most of this seem obvious? 11:48:18 --- quit: rabbitwhite () 11:55:35 --- join: Astrobe (n=Astrobe@c-real.rouen-wireless.net) joined #forth 11:56:47 --- quit: Astrobe (Remote closed the connection) 11:57:51 --- join: astrobe (n=fred@c-real.rouen-wireless.net) joined #forth 12:14:55 Unless you're going to use the return-stack a hell of a lot, swap and rot are pretty handy. Coding to avoid them would involve globals, or locals, or something. 12:17:00 so the other language stuff... 12:17:32 Using stack-juggling to compensate for a poorly-chosen stack-order, that's another issue. 12:17:41 in my humble experience, a few well-chosen globals are not that bad 12:17:54 Sure, sometimes you need a global. But not to avoid swap, or rot. 12:18:37 Seems to me as silly as avoiding dup by variable temp ... temp ! temp @ temp @ 12:18:59 you don't select what you avoid when using globals 12:19:18 but, yes for one less swap, no 12:19:48 for a rot, well I have no rot, so I suppose, yes. 12:20:04 If I have to choose between rot and putting something on the return stack and retrieving it, rot wins. It's cleaner and easier to read. 12:21:12 I would say that my POV is the exact opposite, but that's probably a matter of practice and usage 12:21:20 You don't have ROT in your language, so. 12:23:01 Beginners have trouble remembering the difference between >r and r>. I did, and I've heard it many times from beginners since. With that in mind, I code where possible to minimize the use of the return stack. Sometimes it can't be avoided, of course. 12:23:45 For instance, if you're about to add an unknown number of elements to the stack, you may well need to preserve an item on the return stack. 12:24:15 in your experience, it is easier for beginners to update there mental stack picture when a ROT happens? 12:24:26 Yes, rot is very simple. Third item to the top. 12:24:57 but it's a mneumonic for "rotate" which doesn't have an implicit direction 12:25:11 so mentally I renamed it to "dig" 12:25:18 It's a forward direction. Common usage has a -rot, which goes the other way. 12:25:28 otoh >R and r> are not the best names. push and pop are probably better 12:26:17 >R and R> are what we have. They're not all that spectacularly hard to differentiate between, but rot is arguably a simpler concept, and stays within the bounds of the maximum-four-items that you are preferably dealing with at any one time. 12:28:14 In my quicksort implementation, I have a 'swap rot' at the end of one word. In return-stack terms, that's... really hard. 12:29:36 moving items from stack to stack isn't hard. It's like, putting an object in your other free hand; anyway as you said you need >r r> anyway sometimes, so one has to learn the concept and get used with it. 12:30:30 Sure. But where you simply need to bring the third item to the top, using the return stack instead is overkill. rabbitwhite would have us avoid swap and rot both -- how would I code the sequence 'swap rot' without using either? 12:31:40 swap rot: one point. 12:32:11 He might say 're-code the whole routine so you don't need swap rot', but that just moves the necessity for re-ordering elsewhere in the word. 12:32:23 3 rev 12:32:56 I have no idea what 'rev' is or does, but it has to embody the concept of swap or rot, and I hardly think anyone arguing against swap would find it a more acceptable alternative. 12:33:34 'swap rot' is equivalent to 'swap >r swap r> swap' or 'over rot drop rot', and neither are better. 12:34:25 "reverse top three elements" is the concept. perhaps the name isn't usually rev. 12:34:40 I've seen that called 'spin', but it isn't a common thing. 12:37:18 Well, "re-code" is an easy answer to end a debate. I would have to look at your quicksort, recode myself to eventually prove it can be done. So I'll avoid this answer 12:37:40 or maybe I should raise the challenge for my own education. 12:38:02 I can assure you that recoding would not avoid this. It could be done with locals, but again, sledgehammer to kill a gnat. 12:38:20 heh, yeah 12:38:24 or globals :) 12:39:14 I could not be done with globals, as this requires reentrancy. You'd have to preserve the previous contents of the globals on the return stack for each invocation, and you'd have locals again, only now in much more cumbersome fashion. 12:42:39 In my experience, if too much stack juggling is going on, one or more of my words have poor stack-order requirements. 12:43:09 Or (this happened to me a lot when I was starting out) I was trying to move too much stuff around on the stack. 12:43:29 That usually came of poor factoring. 12:43:56 what's your opinion about Pick and Rol? 12:44:03 To be avoided at all costs. 12:44:15 There are rare occasions when pick is useful. 12:45:06 There's cs-roll, but the only time I can remember seeing it used is as '1 cs-roll', which is the same as a 'cs-swap'. 12:45:59 so rot is is your "deepest" stack word, and is enough to handle complex algorithms like QS? 12:46:02 Looking at my collection of sources, I see Baden uses CS-ROLL more generally (and unavoidably) in his 'goto' package. 12:46:17 2swap and 2over I also use. 12:46:49 Cell-pairs are not uncommon things, I consider them conceptually a single stack unit, so I don't get frantic if I have three cell-pairs on the stack. 12:47:28 yes they are an exception. 12:48:03 remember me, cs-roll is for control-flow words isn't it? 12:48:14 I had occasion to use '2 pick' in an implementation of the Standard SEARCH word recently. It was actually the simplest solution. But that's a rare thing. 12:48:20 Yes, cs-roll rolls the control-flow stack. 12:52:52 These words you use once in 10,000 blocks, but that simplify things 2 orders of magnitudes when you have them. 12:53:13 I suppose my '2 pick' could as easily be '>r over r> swap'. In the particular context of what I was coding, '2 pick' was more efficient. 12:55:44 And, I think, easier to follow in that specific case. But I did try to not use it. :) 12:56:52 astrobe, more than 10,000 blocks for me -- I use those newfangled, named, variable-sized blocks called 'files'. :) 12:57:36 I knew you would pick that... :) 12:57:41 blasphemy! :) 12:58:26 It must be that I'm getting old, I prefer to remember the name of my program, rather than what block number it's written at. :) 12:58:41 blocks are good for rookies like me. Things are so easy to do with them. 12:58:52 Files don't present an additional challenge. 13:00:30 funny how "words" are named and variable-sized as well. 13:00:36 a fgets in forth is a challenge for me (which I raised) 13:01:02 how so, astrobe? 13:01:10 lukeparrish, you mean forth words? 13:01:14 yeah 13:01:40 Yes, I don't see anybody coding anonymous words, remembering the xts, and using those instead of names. :) 13:04:14 my sentences are too complex for my english I guess. I mean writing forth code to fetch efficiently a file line by line is not trivial. I needed a whole block to code that. 13:05:40 open-file, read-line, close-file -- a whole block? 13:05:52 anymous words: I do. my variant of :noname stores to a global, IT, and IDEM is an immediate word that compiles the xt in IT. 13:05:52 How small are your blocks? 13:06:15 astrobe, that's just a way of making a temporary word over and over called IDEM. Not the same as working with the xt number itself. 13:06:59 yes, when buffering the file by chunks of 1K 13:07:58 --- quit: Cheery ("Download Gaim: http://gaim.sourceforge.net/") 13:08:12 Quartus: remembering xt: yes, that would be an interesting concept :) 13:09:12 In a way, that's what chuck does with it's huffman encoding stuff, i think 13:13:48 astrobe, http://forth.pastebin.ca/162730 13:14:04 I managed to bring that in at 287 bytes, even with cr/lf and extravagant naming conventions. 13:17:29 I wasn't clear enough. I coded the read-line part. 13:17:48 So it's read-line that takes you more than 1K of source to implement? 13:21:32 not exactly. first because blocks are well-known to waste space. I guess it would be half-sized if the block was converted to a file 13:21:59 there's also a few other utility things in it 13:22:00 So not that much code. Perhaps it can be written even more efficiently. 13:22:45 in the block I have the word GETLN (read-line) GETC (sort of fgetc, on which GETLN relies) 13:23:03 and ?EOF, which tests the end of the file. 13:23:45 The standard has read-file, which meets all of those needs, with read-line being an abstraction over read-file. 13:24:14 where is the fun? :) 13:24:23 Right there beside the simple. :) 13:26:11 But blocks were candy when I started coding my Forth in assembly language. 13:26:26 And it's still candy. 13:27:01 loading Forth source in files requires another layer, because you want to nest includes. 13:27:14 Ok. It's your private hobby implementation. But read-file isn't a lengthy or difficult word to implement; your particular compiler may make it more difficult. 13:27:24 You need save-input and restore-input in order to nest. The standard has those too. 13:27:27 Blocks give many things for allmost free 13:27:59 Neither more nor less than do files, save that blocks don't have names unless you define a wrapper around the block number. I let the filesystem do that for me. 13:28:51 It also handles moving those pesky blocks around if I need more or less space. I can even delete whole ranges of these blocks in 'file' form without losing track of any of the others, or leaving an unsightly gap! :) 13:28:55 I'm working on that. 113 LOAD tells nothing indeed. 13:29:47 Did I say that first, my system was a standalone system? 13:29:53 You could build a filesystem on top of a block system, and if I were trapped in a machine where I wasn't running under a host OS, I might do that. If there's a host OS, use a host filesystem. 13:31:04 watch out, the sysop is coming! :) 13:31:23 sysop? 13:31:52 system operator. Moderator (?) 13:32:08 I am an op here in the channel, so if I get out of hand I'll deal with me. 13:32:31 Quite sternly, I might add. 13:32:37 That's real perverse. E-eew. 13:32:40 hehehe 13:33:10 --- quit: Quartus_ ("used jmIrc") 13:35:49 Something as useful a FAT16 filesystem can be implemented in very little code. 13:36:07 Probably improved on at the same time. :) 13:39:02 Perhaps, but I wanted the most simple approach at that time. blocks were simpler than a FAT. A block editor was simpler than a text editor. 13:40:16 Personally I'd use both just as long as it took to abstract a filesystem overtop. 13:41:21 That'd be a useful bit of code, a simple filesystem that rides on top of blocks. Might have some applicability in native Forth implementations. 13:44:05 Now I have both -- now that I work with the hosted version, but I'm still using blocks. I can use several block files "ala Pygmy" 13:44:18 And I have tools to move blocs around 13:45:12 well, if you enjoy being your own filesystem, who am I to say you shouldn't? :) 13:49:29 Well, that's just a hobby. 13:49:52 True. I am perhaps biased by the fact that I use Forth for actual work. 13:50:28 I could switch to files easily, but I still use my old block editor because it's more convenient for me. 13:50:53 --- join: vatic (n=chatzill@pool-162-84-156-148.ny5030.east.verizon.net) joined #forth 13:51:16 I would say that it would be easier for you to share code with files, but your system is peculiar to you anyway. 13:52:15 For myself, I avoided studying Forth to any degree until I heard it was being put through a standardization process. I had no interest in learning and re-learning repeated dialects. 13:52:17 yes, autism was in my intial list of features :) 13:52:33 you have an autistic Forth? How unfortunate for it. :) 13:55:42 hey, some autists (agreed, very little of them) are genius. 13:57:22 I don't know if I would take a forth job if I had the chance. 13:57:38 Have you made any additonal changes to the tag/recover code from yesterday? 13:59:00 well, no. The problem is that I start my system, then start my IRC client, and I write more in this window than in the other one. 13:59:17 :) 13:59:46 I'm doing a little, "post-it"-like app. 14:00:52 I include Forth code in the header of each note so that later, I can do advanced things like auto-pop a note at a particular day if I want to. 14:01:09 Hmm. 14:01:38 Currently this trick serves to memorize size and positions of the notes. 14:01:39 --- quit: saon (Read error: 104 (Connection reset by peer)) 14:01:44 --- join: saon (i=1000@c-71-199-235-144.hsd1.fl.comcast.net) joined #forth 14:03:13 Positions? You mean what block number they are in? 14:04:46 you ain't kind :) I use a regular text file to store the content of the notes. 14:05:46 :) 14:06:57 I suppose I wanted to experiment with files a bit. 14:07:20 Then you can free up the 'filesystem lobe' of your brain, let the computer take care of that for you. :) 14:18:05 : RECOVER THERE @ DUP TO HERE @ THERE ! ; seems to work for me. 14:18:44 For your value-based HERE, that looks like it'd be ok. 14:19:41 I prefer that ordering to : recover there @ dup @ there ! to here ; -- I think yours is clearer. First we retrieve there, then update here, then update there. 14:22:46 If THERE were also a value ... : recover there dup to here @ to there ; 14:22:50 I'm left-handed, I read the code and kind of draw pictures of what happens in my mind. The meaning is less important to me than how big has to be the bitmap in my mind :) 14:22:58 I'm also left-handed. 14:23:21 * ayrnieu : left-eye dominant, but right-handed. 14:23:30 --- quit: virl (Remote closed the connection) 14:23:46 * TreyB writes right-handed but fences left-handed. 14:24:13 I'm ambidextrous, but have far more experience at writing with my left hand. 14:24:13 ok, that's just me... 14:24:33 inded it make more sense for THERE to be a value now 14:24:57 astrobe, I don't prefer VALUEs in general terms, but if you have HERE as a value, it makes the code a little clearer. 14:26:28 Another, possibly clearer (though slightly less efficient) definition would be : recover there to here there @ to there ; 14:26:45 again, with a value for there 14:29:15 On the other hand I would probably not build it as a linked list in this way, but instead use a simple stack facility. 16 stack tag-stack : tag here tag-stack push ; : recover tag-stack pop to here ; 14:29:50 (with appropriate HERE-adjusting code for a standard system) 14:30:37 : here! here - allot ; I think would do the trick, so : recover tag-stack pop here! ; 14:31:28 yes, but you have to pre-alloc the stack space. 14:31:40 Yes, though that's trivial. 14:32:03 but it eats bytes... 14:32:20 Are you working on an 8051 with 2K of RAM or something? :) 14:33:02 :) no, but Miss universe with big feet cannot be Miss Universe :) 14:33:19 A 16-cell stack is hardly rampant and extravagant memory waste. 14:33:54 The definintions of tag and recover themselves occupy space; if it is such a concern, better to manage the facility yourself without using any memory-wasting abstractions! 14:35:12 However, I kept the old 64Kb limit for the workspace of the VM. Now you can name me looney. 14:36:05 64K is room enough to write appreciable applications. I wouldn't call it a benefit, though. Is your Forth 16-bit? 14:37:41 yes and no. Currently I'm working with the Linux/windows, C-based reimplementation of the original 16bits system. 14:37:54 I could have 1M in a snap I guess 14:38:13 astrobe: with big feet, she would be the Michigan Apple Queen. 14:38:21 It depends on whether you actually use your language, as opposed to just fiddle with the implementation. 14:39:07 Now Quartus, that's an insightful distinction... 14:40:22 I do both. I used to only work on implementation, but I'm trying to develop useful apps to me now that I have access to GUI 14:40:40 hence this apps I'm making 14:40:50 How is fgets difficult to implement if your Forth is written in C? 14:42:44 cause I didn't want to use fgets... because I plan to backport one day to the original 16-bit written in assembly language. 14:43:26 Correction: the original stuff metacompiles itself. 14:43:47 only primitves are assembly code. 14:43:50 But that's what abstraction is for. You write read-line, or read-file, or what-have you, as best as is suitable for the platform you're on now. If you need a 16-bit assembly version at some future and unfortunate date, write it then. 14:44:30 You're unlikely to as long as your native version doesn't have files, anyway. :) 14:45:44 the native version was 2: dos and standalone; but yes, I don't even know if I will ever touch it again. 14:46:09 granted, that's not very consistent. 14:46:54 If I were working on a Forth built in C, I'd be using the C library to its best advantage at ever turn; absolutely nothing would be gained by re-inventing the wheel when the wheel is right there a-lookin' at you. 14:47:21 I'd build read-file out of fgets, or whatever is the best fit (I'd have to look up fgets to be sure it'd do the trick). 14:49:15 For the retroforth ANS layer under windows, I built allocate/resize/free directly on top of the win32 heap allocation calls. Could I have written each of the three to work of a heap I managed directly? Sure. But why? 14:50:00 Well, the advantage is that I can leave it in it's block if I don't need it. I also have the source at hand, so I can adapt it if needed 14:50:23 "its" 14:51:07 i.e. the file buffer is 1K. I can modify the source and change it to 10 or 100K if needed, and I don't have to have a C compiler at hand for that 14:51:37 which is valuable when you're in a windows machine, away from your dev machine. 14:51:42 If you made fgets available in your dictionary, you could do the same. 14:51:58 At any rate, read-file takes a buffer argument. 14:52:19 if you're at a windows machine, cygwin32 is your friend. 14:52:34 i hear you can even compile gforth on it. *runs* 14:52:41 now, I would need set_buffer_size or something to do one tenth of what I can do by having it in forth source. 14:52:42 Yes, and under gforth or retroforth, etc., you can open cygwin and import gets and away you go. 14:52:45 I run gforth under cygwin. 14:53:10 astrobe, if you built read-file on top of fgets, you would not need to set a buffer size, as you pass a buffer directly to read-file when you call it. 14:54:03 juri_ I can put my system on my usb key and work on my parent's pc when I visit them, without installing anything. BTW I use MinGW 14:54:24 astrobe: its possible to make a cygwin CD. i've seen it done. 14:54:36 "it's" 14:54:42 If you've built some other method of reading file data that depends on an internal buffer that you wish to change, but have somehow denied yourself access to inside your Forth, I suggest redefining your file-reading words along the lines of read-file and read-line. 15:02:34 --- quit: Ray_work ("User pushed the X - because it's Xtra, baby") 15:06:18 that's just a cache. Changing it only impacts speed. The C lib doesn't even seem to provide a way direct way to change its size. By writing myself in forth, I can, and furthermore, I don't even have to provide an extra method for that: I just change the source code. I can alter in whatever way it fits my needs. 15:06:59 but I did it for the fun in that particular case actually 15:07:45 But I see this debate is actually about two opposite approaches. 15:08:16 Gimme the night to think about it. 15:09:33 Ok. 15:09:48 Have a good day or night, all. 15:09:50 --- part: astrobe left #forth 15:13:46 I cannot imagine how being able to alter a cache size in a Forth-written fgets would in any way improve performance over using the native-code C library version. Perhaps as a programming exercise? 15:17:58 Perhaps: "cause I didn't want to use fgets... because I plan to backport one day to the original 16-bit written in assembly language."? 15:18:05 --- join: Quartus_ (n=Quartus_@209.167.5.1) joined #forth 15:18:36 His standalone version doesn't have files. 15:18:45 So fgets would be kind of useless there. 15:20:49 Dunno. If there had been an interpreted Forth for the chip I'm interested in, I wouldn't be trying to write a Forth. Much better writing WITH Forth. 15:22:29 true. It's entirely possible to write a forth and still know nothing about writing in forth. 15:28:18 re fgets, though -- you can't read from a file unless there's a filesystem. Your code will always be bound to that at some level. 15:51:52 Quartus: do you have an opinion about the eForth model? I remember van der Horst having not nice things to say about it, but have never gotten any details... 15:53:16 eForth is kind of a parlour trick to show that Forth can be build mostly in Forth. 15:53:23 built, rather. 15:53:51 possibly educational for a new implementor. 15:53:59 it's also an example of the negative effects of someone's particular optimization goal: having KEY not act like KEY 15:54:25 I'd direct you to MAF before eForth though. 15:54:35 eforthl for linux 15:55:37 Quartus: yes thanks for MAF. re eForth, just trying to prioritize my ignorance. ;-) 15:55:55 heh 15:57:17 my retro ans layer might well be of interest, there's a create/does, do/loop and friends, and other bits + pieces that aren't too heavily rf-ified. 15:57:37 "rified" 15:59:04 Quartus: is it mostly baked now? 15:59:29 toothpick come out clean? ;-) 15:59:36 for 9.2.9. Working with crc to accomodate the changes in his newest build. 16:00:39 Quartus: I suppose if I was really dedicated, I would've read the version differences... 16:01:28 9.2.10 that is. Works fine with 9.2.10. It's 9.3 that is in progress. 16:05:05 it was fun to write. I may add locals. 16:09:14 gforth uses {} for locals syntax, so I'd like to replace { -> } for inline tests. Any suggestions instead of {} ? 16:10:26 [ ] < > and ( ) are used already. 16:11:14 « » are available (are those showing up here?) but I don't think all that universally available. 16:11:42 as \253 \273 , yes. Not UTF8? 16:12:15 standard forth isn't full utf-8. 16:12:41 I'm talking about the encoding you give to IRC. 16:12:51 (answering your parenthetical question) 16:13:31 I'm on a mobile gadget, so I have no idea what it's sending. :) 16:16:06 {{ -> }} is my first thought. 16:17:48 it seems a shame, since I don't use locals, not to be able to portably use { } that are in fairly common use for that, but I suppose {{ isn't much of a sacrifice. 16:18:35 If you can follow all that. This gadget doesn't help me express myself clearly. :) 16:19:07 --- nick: nanstm -> Raystm2 16:25:50 --- quit: TreyB (Read error: 110 (Connection timed out)) 16:54:24 --- quit: Quartus_ ("used jmIrc") 17:39:17 --- join: TreyB (n=trey@cpe-66-87-192-27.tx.sprintbbd.net) joined #forth 18:08:23 --- quit: vatic ("*poof*") 21:12:02 --- join: segher_ (n=segher@dslb-084-056-128-014.pools.arcor-ip.net) joined #forth 21:19:50 --- quit: segher (Read error: 110 (Connection timed out)) 23:39:31 --- quit: Quartus (Read error: 110 (Connection timed out)) 23:59:59 --- log: ended forth/06.09.06