00:00:00 --- log: started forth/19.02.15 00:00:00 --- quit: dys (Ping timeout: 245 seconds) 00:11:51 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 00:16:05 --- quit: spestov (Ping timeout: 244 seconds) 01:05:45 --- join: xek (~xek@apn-31-0-23-81.dynamic.gprs.plus.pl) joined #forth 02:02:49 --- quit: ashirase_ (Ping timeout: 246 seconds) 02:07:58 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth 02:12:33 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 02:17:05 --- quit: spestov (Ping timeout: 245 seconds) 03:10:57 ``B didn't believe in type­checking, period. There was only one type, the machine word, and the programmer was responsible for applying to a variable only such operators as made sense.'' 03:11:00 could the same be said of forth? 03:25:19 Yeah, basically. 03:27:16 It works a lot like assembly. You haven't got things in the way to stop you from doing dumb things. 04:13:46 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 04:18:02 --- quit: spestov (Ping timeout: 246 seconds) 04:18:15 --- join: rdrop-exit (~markwilli@112.201.168.172) joined #forth 04:33:14 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 04:55:25 --- quit: gravicappa (Ping timeout: 245 seconds) 05:18:44 regarding type checking: there is this confusion around what it means 05:20:46 I usually split type stuff into three stuff: record layout, which bits are part of which field; semantics, both low and high level (u32 and it is a length in centimeters); and lastly boolean checks to see if a value fullfills a set of criterions 05:21:49 this applies both to values and pointers/references 05:22:52 one can have offset compressed pointer (say internal to a datablock) that points to a struct/record of spefic kind. 06:58:58 To me "type" is just a label that I've decided to associate with some segment of memory, or file content. Obviously it would be nice if you can interpret that data in a way that gives that label useful meaning. 06:59:21 It can just be something I have in my mind, to help me select the operations I perform on that data, or it can be tracked in some way by your system. 06:59:33 Either way that seems to me to be all it is - just a label. 07:00:05 That is all a type is. 07:00:31 The issue is that some languages will check for you that the type you're using is being used the way you've identified as possible. 07:00:58 those languages also make operator overloading possible, which is probably the number one feature i miss from forth 07:01:11 Which *does* have some benefits, but most type systems aren't sufficiently expressive in a small enough space for it to be worth using them in many (often most) cases. 07:01:47 zy]x[yz: Well, it would kinda be possible. As long as you got type information stored somewhere. 07:02:35 i don't know how to do it without runtime dispatch, which i would say is an unacceptable cost 07:02:58 zy]x[yz: E.g. : + 2DUP 2IS_CSTRINGS IF CSTRING_APPEND ELSE + THEN ; 07:03:24 Using + for string concatenation is evil. 07:03:30 yeah, i wouldn't want it for that 07:03:35 I really want it for @ and ! 07:03:40 It was the first example that came to mind. 07:04:03 john_cephalopoda: The problem with that is you start getting massive chains. 07:04:29 You have, say, complex numbers and overload + to check for complex numbers otherwise directing to the previous +. 07:04:32 Now quaternions. 07:04:48 Again, you'll have to carry type information somewhere. If you want to handle @ and ! different for floats, ints and other stuff you'll have to identify them somehow. 07:04:49 Oops. Now we've got sets. 07:04:59 Now there's ... 07:05:02 zy]x[yz: Yes - I do eventually intend to have word overloading possible in mine. 07:05:12 So now every use of + is potentially a long chain of checks. 07:05:21 This isn't really feasible. 07:05:27 I prefer not to have a type system, just deal with the bits and their meaning myself. 07:05:29 I'm going to have an alternate interpreter that will maintain a "type stack," and it will look for a word that not only matches in name, but also matches in terms of its argument types with what's currently on the stack. 07:05:54 Forth was not meant to solve the unsolvable problems of computer science. 07:06:12 this is not an unsolvable problem. it's just nasty in forth 07:06:20 The idea is that it will be compile time only - the compiler, as it compiles, will use the type delta info of the component words to track through what the type delta info for the new word should be. 07:06:33 KipIngram, how are you going to track this type stack at compile time though? 07:06:36 But once compiled, words will run exactly as always. 07:07:06 in trying to track the types, you'll basically end up having to execute every word 07:07:11 Well, as the compiler picks up each word it will look up its type effect and update a "compilation copy" of what the stack will look like at run-time. 07:07:20 Honestly, I don't see why just renaming operators won't be enough. c@, f@, c!, f! etc. 07:07:28 Obviously I'll have to tell the compiler what a word EXPECTS to be on the stack, but from there it can track how it evolves. 07:07:31 "When a programming language evolves a more elaborate type system, it gains a more finely grained rule set than basic type checking, but this comes at a price when the type inferences (and other properties) become undecidable, and when more attention must be paid by the programmer to annotate code or to consider computer-related operations and functioning." 07:07:41 There are some gotchas with this - multiple paths that produce multiple possible changes. 07:07:49 john_cephalopoda, because that puts a burden on the user to know what the size of what he's reading or writing is 07:08:14 Words that can affect the stack in different ways present sort of a problem. 07:08:18 john_cephalopoda, it's not a scalable way of development 07:08:21 I don't know if they're totally avoidable or not. 07:09:24 KipIngram, so your plan is to just tell the compile the input and output types for each word? 07:10:40 that would work, but it would get pretty complicated if your word can change the stack differently depending on branches taken, like ( n -- 0 | x 1 ) 07:12:06 Well, the input types. It should figure out the output types itself. 07:12:14 Yes, multiple paths is a problem. 07:12:27 So this is still something I'm just rolling around in my head - long term plan. 07:12:42 yeah, determining output types is where i mentioned you're basically simulating program execution at that point 07:13:04 Another perk of something like this is pre-execution detection of stack under/over flow. 07:13:22 As the compiler traced through the word it would know how it was changing the stack depth at every point. 07:13:35 So the system could just refuse to execute a word that would under or overflow the stack. 07:13:41 seems like it would be easier to just make the coder define output types and then try to use static analysis to make sure they did what they said... or a more forthy solution is you don't check their code at all and just take their word for it 07:13:52 That seems like an improvement on the "detection" that most systems do. 07:27:10 Yes, I'm quite aware this is a deviation from Forth. 07:27:28 It's not something I plan to weave into the system itself - it will be an "alternate" compiler that I can run when I want to. 07:27:51 So you could think of it instead as a framework to support type intelligent applications. Say you wanted a Matlab/Octave like environment. 07:28:09 So I think of it as application code and thus assauge my guilt over "corrupting Forth." :-) 07:28:27 That and also the fact that it has no run-time effect. 07:28:41 I guard Forth runtime efficiency rather jealously. 07:29:25 People suggest alternatives to, say, IF THEN, and I take their idea and look at it and see that it will run a little slower, and balk. 07:29:27 :-) 07:32:04 --- quit: rdrop-exit (Quit: Lost terminal) 07:50:38 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 08:48:45 --- quit: spestov (Ping timeout: 245 seconds) 09:27:34 --- quit: pierpal (Quit: Poof) 09:27:54 --- join: pierpal (~pierpal@host132-240-dynamic.52-79-r.retail.telecomitalia.it) joined #forth 10:27:42 --- quit: Zarutian (Read error: Connection reset by peer) 10:30:37 --- quit: nighty- (Quit: Disappears in a puff of smoke) 10:32:48 --- join: dys (~dys@tmo-102-218.customers.d1-online.com) joined #forth 10:46:17 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 10:50:37 --- quit: spestov (Ping timeout: 246 seconds) 11:21:16 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 11:26:22 --- quit: pierpal (Quit: Poof) 11:26:43 --- join: pierpal (~pierpal@host132-240-dynamic.52-79-r.retail.telecomitalia.it) joined #forth 11:37:52 --- quit: spestov (Ping timeout: 246 seconds) 11:40:27 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 14:45:23 --- join: dave0 (~dave0@193.060.dsl.syd.iprimus.net.au) joined #forth 14:45:41 hi 14:45:53 --- join: Zarutian (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth 14:50:01 --- quit: spestov (Ping timeout: 246 seconds) 14:52:52 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 14:55:35 morning forthniter 15:01:18 Hey hey 15:09:29 --- quit: spestov (Ping timeout: 240 seconds) 15:18:09 Afternoon guys. 15:18:41 I should look at some Forth implementations. 15:18:52 for? 15:18:57 inspiration? 15:19:33 hi KipIngram 15:19:57 corecode: For ideas of how a forth system is created. 15:20:19 I got something semi-running but it feels complex. 15:21:40 --- quit: xek (Ping timeout: 245 seconds) 15:30:38 i have a very very minimal forth 15:31:17 not an OS, just kernel: primitives, parse/compile/execute loop 15:44:49 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 15:49:11 --- quit: spestov (Ping timeout: 244 seconds) 15:54:26 john_cephalopoda, someone the other day linked me jonesforth repo, which quite iluminating I must say. 15:54:54 john_cephalopoda, https://github.com/nornagon/jonesforth/blob/master/jonesforth.S 15:55:06 A sometimes minimal FORTH compiler and tutorial for Linux / i386 systems. 15:56:15 i didn't find it very useful 15:57:13 * Zarutian always suggests eForth when jonesforth is mentioned. 15:57:45 eForth? 16:01:55 anyway, as an introductory material for understanding the machinery behind this specific implementation of forth, I find jonesforth is quite good 16:02:37 there might be better text that I'm not aware of, tho 16:03:35 https://github.com/corecode/forth/blob/master/x86.fs 16:03:41 what do you think about this 16:07:28 I mean by introductory material is something that also explain what's actually happening, why it's done this way, an accompanied diagram, how the building block are put together, etc. 16:07:58 yea i read brad rodriguez 16:08:40 brad & loeliger; the f-pc manuals were super techie, and the F83 manual was almost usable. 16:23:03 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 16:27:30 --- quit: spestov (Ping timeout: 245 seconds) 16:44:28 --- quit: john_cephalopoda (Ping timeout: 268 seconds) 16:46:00 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth 17:00:47 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 17:21:35 --- join: rdrop-exit (~markwilli@112.201.168.172) joined #forth 17:53:18 Good morning Forthwrights 17:54:36 hey - however, I'm gonna eat dinner in a sec 17:54:53 * tabemann should now write some documentation for hashforth 17:54:54 Hi tabemann, bon appetit 17:56:15 there's already VM documentation, but no "userspace" documentation exists 17:56:59 of course that's not necessary if the goal is just to have a VM, but I personally have the goal of having a useful Forth on top of it 17:57:30 anyways, dinnertime 17:57:36 :) 18:25:09 back 18:30:33 good evening 18:35:47 wb 18:36:15 Hi crc 18:50:38 I'm about half finished on a new block editor for retro 18:51:26 The basic basic editing works, but I still need a few words for capturing and moving data around 18:52:08 I should also prepare a variant for qwerty keyboards 18:53:17 Is it terminal based or graphical? 18:53:58 terminal, needs vt100/ansi escape sequence support 18:55:10 Same here 18:56:59 Editors are fun 18:57:15 steady box cursor 18:57:16 blinking underline cursor 18:57:59 etc... 18:59:26 0 source Host VDT - Control - Sequences - DECSCUSR 18:59:27 1 18:59:27 2 0 constant blinking compiled 18:59:27 3 $ 10000 constant steady compiled 18:59:27 4 18:59:29 5 : box ( blink - style ) $ 1b5b312071 + ;inline compiled 18:59:31 6 18:59:34 7 : underline ( blink - style ) $ 1b5b332071 + ;inline compiled 18:59:36 8 18:59:39 9 : cursor ( style -- ) #>vcb ;inline compiled 19:00:13 http://forth.works/57a8e7c56bb704ab5dccbf4654b85bcd 19:01:05 Cool 19:01:53 I'm thinking of rereading Raskin's book for somee ideas on how to improve my UI 19:02:55 * some 19:05:09 I want to have the editor up at all times in the umbilical host 19:07:33 dedicate a pane to it 19:16:02 Have the terminal looking something like this: 19:16:08 +------------------------+-------+ 19:16:08 | | | 19:16:08 | Viewport Pane | Panel | 19:16:08 | 64x16 | Pane | 19:16:08 | | 16x24 | 19:16:10 +------------------------+ | 19:16:13 | Console Pane | | 19:16:15 | 64x8 | | 19:16:18 +------------------------+-------+ 19:16:52 rdrop-exit: where is this beast at? 19:17:34 That's just an idea I'm toying with 19:18:15 well, I'd love a copy.. In many ways F-PC, Turbo Pascal/C and F83 were similar. 19:18:30 The editor would (almost) always be up on the viewport pane 19:18:36 of course, there is no chance on earth I will grok gui-bullshit. 19:19:25 I'll let you know when I get around to it and am ready to share 19:19:49 You can likely coerce the Terminator termwin thing to do the job - kip has more time on it than I do, but I am forever splitting the screen and recovering 19:20:07 that is pretty much the same layout I'm planning :) 19:20:22 crc: it's sorta' a natural for all older hands 19:20:42 arduino IDE does it, geany does it.. 19:21:06 This would just be an 80x24 terminal screen, no special tech required 19:21:45 well, ncurses anyway 19:21:51 The panes are just fixed sub-divisions of the screen space 19:22:15 I don't use curses, just ECMA-48 and some DEC codes 19:22:22 rdrop-exit: very difficult to keep that all in synch w/o something like curses. 19:22:35 but, sure - it's been done 19:24:00 ncurses is a pain, I prefer to just do it myself 19:24:28 I agree it's painful, but still less pain the gtk or qt or any of a dozen nastier things 19:24:48 I prefer to "just do it" 19:25:17 Me too, minimize dependencies 19:25:33 PoppaVic : I just redraw everthing on screen after each keystroke 19:25:50 I have to wonder if yer program could leverage Zenity or xdialog to throw up little subwins of, oh.. register/stack state, block/file/context, etc 19:26:08 "keep the shit out of the damned way" 19:26:51 this is usually where some chucklehead suggests python or tcl for "graphics" 19:26:56 crc: Me too, although I do a delta first 19:29:20 I agree PoppaVic, I like spartan interfaces, I don't need anything fancy 19:31:22 I think there are potential benefits to having a block displayed at all times 19:32:08 well, that and I refuse to dive into tcl and python just strikes me as slacker-C 19:33:02 And ,yes.. If yer gonna' have persistent source, then sure - display an edit block - even if that is part of the stupid HISTORY you are tinkering 19:33:43 I never did figure out if gforth even allows you to list the last N recent history, although you can SCROLL them 19:34:57 I haven't studied Gforth's user interface features 19:37:20 I also want to reread the Canon Cat docs for inspiration 19:39:47 I have a soft spot for old school full screen Text UIs 19:40:45 Now that I think about, I should take a look at some of the old Borland stuff too 19:41:33 I still have some of the old TASM and Turbo Prolog manuals 19:42:49 Although I don't care for old shool lightbar menu-ing systems, just control keys and commands 19:46:40 --- quit: dddddd (Remote host closed the connection) 19:47:43 Anyway more stuff for the To Do pile 19:48:51 Turbo Prolog? not Turbo Pascal? 19:50:19 I only kept the TASM (Turbo Assembler) and Turbo Prolog manuals, probably gave away the Turbo Pascal and Turbo C ones. 19:51:19 rdrop-exit: I enjoyed the turbo editor, since I was also a WordStar user, and I still use joe - ^KH is always nice. 19:51:29 I always have too many books 19:52:19 I was also a Wordstar user, CPM and DOS, then Wordperfect for a while. 19:54:04 I'll look into joe 19:54:40 On DOS I used kedit as my editor, it was a DOS port of IBM's xedit. 19:54:42 I drive other programmers nuts - I'll switchhit between joe and geany ;-) 19:55:44 I don't know geany either, is it an editor? 19:56:45 yeah, a gtk thing - I hate the command-code crap and never remember it, but it's great for reading alien code in good fonts, and the column/vertical extensions do a few things joe can't do in column-mode 19:59:29 The column oriented features were the reason I used kedit on DOS back in the day, it was basically a port of a mainframe editor. 20:06:18 My main work PC back then was a Compaq Portable (Luggagle) with a 9 inch green screen. I learned to appreciate simple clean user interfaces using that thing. 20:08:37 yeah, I had the kaypro 4-64.. Built like a bloody tank.. I really wish I still had that case - man it could be packed full of impressive today ;-) 20:10:44 One of my teachers had a Kaypro, that was a beast. 20:11:50 it was great.. Until you tried to walk a couple blocks with it to a UG meeting ;-) 20:12:04 ..that damned thing got heavier every step. 20:12:14 (it needed shoulder-straps) 20:14:33 I used to travel with my Compaq, the keyboard would detach and fall out the bottom at the worst times, with that loopy telephone-cord like cable. 20:16:33 heh.. the kaypro latched all but watertight.. In fact I recall reading some had been purchased and retrofitted for wet/dry/sand/snow conditions ;-) 20:16:44 But it was worth it, a computer you could travel with was the coolest kit you could have. 20:17:26 well, it tied up nearly as much space as my bed; so I bought about 20' of countertop for it, some books and the printer 20:20:21 Gotta go, chat again soon, keep on Forthin' :) 20:20:32 --- quit: rdrop-exit (Quit: Lost terminal) 20:43:46 --- join: gravicappa (~gravicapp@h109-187-236-118.dyn.bashtel.ru) joined #forth 21:05:28 I've finished the output capture, so the interface now displays output below the editor. http://forth.works/bb5000a7efd51d61d382c9a3666bc64b 21:32:13 --- join: markweston (~markwesto@193.219.171.1) joined #forth 21:33:28 What's the largest program/project/system written entirely/mostly in FORTH? 21:35:33 --- quit: pierpal (Quit: Poof) 21:35:52 --- join: pierpal (~pierpal@host132-240-dynamic.52-79-r.retail.telecomitalia.it) joined #forth 21:35:57 airline scheduling and flights.. NDA stuff, and I believe Forth, Inc (if not NASA) are your two largest players. 21:40:55 --- join: lchvdlch_ (~nestr0@191.98.151.137) joined #forth 21:41:08 --- join: rprimus_ (~micro@a9.lence.net) joined #forth 21:41:32 --- nick: rprimus_ -> Guest18112 21:41:40 --- quit: rprimus (Ping timeout: 246 seconds) 21:41:40 --- quit: dave9 (Ping timeout: 246 seconds) 21:41:41 --- quit: lchvdlch (Remote host closed the connection) 21:42:21 Any big open-source projects? So far the largest I found was this self-hosted FORTH compiler: github.com/larsbrinkhoff/lbForth 21:44:22 you forgot gforth, iforth, linforth, pfe, pforth, eforth, and a number of others 21:52:03 --- quit: spestov (Ping timeout: 258 seconds) 22:19:10 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 22:23:30 --- quit: spestov (Ping timeout: 250 seconds) 22:36:07 KipIngram, I'm doing a strongly typed forth-ish. So far looks like I'm able to handle the whole thing at compile time. I considered a "type stack" and found it wasn't needed. 22:38:31 PoppaVic, hahaha joe is still my local text editor on all my systems. Due to the old Turbo Pascal days. 22:47:17 Yeah, joe just works w/o fuckaround 22:47:36 That and MC are are the first things I install 23:23:14 --- join: presi-den (~presiden@unaffiliated/matematikaadit) joined #forth 23:31:33 --- join: mtsd (~mtsd@94-137-100-130.customers.ownit.se) joined #forth 23:36:03 --- join: dave9 (~dave@193.060.dsl.syd.iprimus.net.au) joined #forth 23:47:58 --- quit: mtsd (Ping timeout: 255 seconds) 23:53:24 --- quit: pierpal (Quit: Poof) 23:53:43 --- join: pierpal (~pierpal@host132-240-dynamic.52-79-r.retail.telecomitalia.it) joined #forth 23:59:59 --- log: ended forth/19.02.15