00:00:00 --- log: started forth/14.03.24 00:20:24 --- quit: bstates (Ping timeout: 240 seconds) 00:20:25 --- join: bstates_ (~ln@xw.fi) joined #forth 00:23:39 --- join: nisstyre (~yourstrul@oftn/member/Nisstyre) joined #forth 00:35:41 --- quit: nisstyre (Quit: WeeChat 0.4.3) 00:53:06 --- quit: CopingWithBliss () 01:08:33 --- join: DGASAU (~user@p50993595.dip0.t-ipconnect.de) joined #forth 02:30:58 --- quit: kludge` (Ping timeout: 240 seconds) 02:35:01 --- join: kludge` (~comet@unaffiliated/espiral) joined #forth 02:39:33 --- join: true-grue (~quassel@95-25-18-93.broadband.corbina.ru) joined #forth 02:43:43 --- join: aksr (~aksr@unaffiliated/aksr) joined #forth 03:37:01 --- join: pvt_petey (~pvt_petey@host-92-16-158-80.as13285.net) joined #forth 03:49:46 --- join: pvt_pete_ (~pvt_petey@host-92-16-158-80.as13285.net) joined #forth 03:50:15 --- quit: pvt_petey (Ping timeout: 240 seconds) 03:58:27 --- join: john_metcalf (~digital_w@228.15.125.91.dyn.plus.net) joined #forth 04:22:26 --- join: Zarutian (~zarutian@194-144-84-110.du.xdsl.is) joined #forth 04:29:05 --- quit: pvt_pete_ (Ping timeout: 252 seconds) 04:30:03 --- join: pvt_petey (~pvt_petey@host-92-16-158-80.as13285.net) joined #forth 04:43:15 --- quit: pvt_petey (Ping timeout: 240 seconds) 04:46:04 --- join: pvt_petey (~pvt_petey@host-92-16-158-80.as13285.net) joined #forth 04:46:47 --- quit: mnemnion (Remote host closed the connection) 05:41:21 --- join: nighty-_ (~nighty@lns-bzn-49f-62-147-170-46.adsl.proxad.net) joined #forth 05:47:42 --- join: subtleq (~subtleq@c-50-184-215-123.hsd1.ca.comcast.net) joined #forth 06:05:02 --- join: overdamped (~overdampe@unaffiliated/overdamped) joined #forth 06:48:02 --- join: mnemnion (~mnemnion@c-98-210-219-91.hsd1.ca.comcast.net) joined #forth 06:52:42 --- quit: mnemnion (Ping timeout: 268 seconds) 07:14:27 --- quit: pvt_petey (Ping timeout: 252 seconds) 07:16:38 --- join: pvt_petey (~pvt_petey@host-92-16-158-80.as13285.net) joined #forth 08:33:21 --- quit: Zarutian (Quit: Zarutian) 08:35:55 --- join: aranhoide (~aranhoide@45.Red-79-157-100.dynamicIP.rima-tde.net) joined #forth 08:47:37 --- join: mnemnion (~mnemnion@c-98-210-219-91.hsd1.ca.comcast.net) joined #forth 08:51:56 --- quit: mnemnion (Ping timeout: 240 seconds) 08:52:57 --- join: Zarutian (~zarutian@194-144-84-110.du.xdsl.is) joined #forth 09:22:59 --- quit: joneshf-laptop (Ping timeout: 240 seconds) 09:30:31 --- join: joneshf-laptop (~joneshf@98.255.30.38) joined #forth 09:41:04 --- join: pvt_pete_ (~pvt_petey@host-92-16-158-80.as13285.net) joined #forth 09:42:03 --- quit: pvt_petey (Ping timeout: 246 seconds) 10:00:05 --- join: kumul (~mool@adsl-64-237-225-122.prtc.net) joined #forth 10:16:13 --- quit: I440r (Ping timeout: 268 seconds) 10:29:40 --- join: ASau (~user@46.115.126.150) joined #forth 10:31:55 --- quit: pvt_pete_ (Ping timeout: 252 seconds) 10:32:41 --- join: pvt_petey (~pvt_petey@host-92-16-158-80.as13285.net) joined #forth 10:33:46 --- join: mark4 (~mark4@cpe-68-203-183-77.tx.res.rr.com) joined #forth 11:13:36 --- nick: mark4 -> I440r 11:13:39 --- mode: ChanServ set +o I440r 11:41:10 --- join: mnemnion (~mnemnion@c-98-210-219-91.hsd1.ca.comcast.net) joined #forth 11:54:24 --- join: Mat3 (~claude@91-64-127-6-dynip.superkabel.de) joined #forth 11:54:29 Good Day 11:54:54 hi 11:55:07 my arm forth has a serious bug 11:55:16 my / /mod and mod words are wrong 11:55:39 i need a nice 64/32 signed divide routine :/ 11:55:48 NOT c, not gpl 11:57:50 l440r: they do not work properly? pastebin the code you have atm 11:58:40 simply take a look at a Z80 assembly book of your choice 11:58:58 http://pastebin.com/tnxqDqBp 11:59:12 thats my um/mod but im not sure its 100% right 11:59:14 and its unsigned 11:59:33 i was using it as a primitive for my / /mod mod words but those are supposed to be signed 11:59:42 its an I not an L btw :) 12:00:36 I'm assuming / and mod both use /mod to implement their functionality. 12:00:57 Change /mod to just manually check the signs, and flip the sign of the result according to the input's signs. 12:01:10 mod is /mod drop 12:01:25 and / is /mod nip 12:01:26 That way, you isolate any bugs to just um/mod and that becomes easier to fix. (and more portable) 12:01:50 kc5 erm. how would i do that? 12:02:35 A positive times a negative gives a negative. A negative times a negative gives a positive. These also apply for division. 12:02:44 (since division is just multiplication by the reciprocal.) 12:02:51 ya 12:03:52 Remind me via e-mail, and I'll reply with eForth's implementation of UM/MOD. I don't have the source handy right now. 12:03:59 * kc5tja will brb in about an hour or so -- lunch time here. 12:04:21 kc5tja, the eforth version is not in asm 12:04:51 it also uses fm/mod or fm/rem or some wacky crap like that 12:05:14 i still have no freeking idea what EFF EMM slash mod is 12:05:32 yea brb, sammich time! 12:36:27 Not the source listing I have. 12:36:46 Though, the reason why should be patently clear -- on modern CPUs, floating point is at least as fast (sometimes faster) than integer operations. 12:37:22 kc5 except where there is no fpu :) 12:37:47 i pinged one of your email accounts, not sure if it was the right one, might be your rackspace account or something 12:44:59 gordonjcp: hey, I've heard you've done some work with forth on AVRs? 12:45:13 technomancy: a tiny tiny amount 12:45:17 and a long time ago 12:45:23 <-- wrote his own avr forth 12:45:30 I440r: oh cool 12:45:34 I've read that amforth puts the dictionary in flash, but all the docs I could find on avrs seem to imply the flash is read-only at runtime 12:45:43 incuding writing the avr assembler FIRST lol 12:48:03 I440r: so did your forth keep dictionaries in the flash or in sram? 12:48:16 s/dictionaries/the dictionary/ 12:48:43 on the host 12:48:45 not on the target 12:49:37 yes, flash is (as far as I'm aware) only writable from the bootloader 12:50:06 ok, I must be misunderstanding the amforth docs then 12:50:07 the fignition gets around this by having SPI RAM and EEPROM chips, and running from them 12:50:26 im not using armforth 12:50:30 but I don't think there can be any way to run "native" words from it 12:50:48 armforth is utter crap, took one look at it and knew i had to write my own 12:51:09 That's the way I feel about almost all existing Forths... 12:51:13 gordonjcp, that is correct which is why the forth kernel is in the boot sector with my forth 12:51:18 * gordonjcp is more into Forth on the 6809 ;-) 12:51:21 No one seems to cleave to simplicty as thoroughly as they ought... 12:51:30 6809 is a WONDERFUL little processor. 12:51:38 * KipIngram learned assembly on that one... 12:51:43 KipIngram: it's almost ridiculously suitable for Forth 12:51:47 not as nice as an 8051 tho :P 12:51:54 * KipIngram wrote his first Forth on a 6809. 12:52:18 I "borrowed" Dave Dunfield's Forth for mine 12:52:24 although I really need to write my own 12:52:36 I440r: amforth or armforth? 12:52:38 or at least tidy it up so I can read in from disk 12:52:49 technomancy, amforth i meant 12:53:02 KipIngram: Agree (two stack pointers avariable) 12:53:27 the R was injected by my brain which is working 99 hours a day on my android game which is using my android NDK version of my arm forth 12:56:29 technomancy: I believe that the AVR bootloader is just a special section of memory and not a processor state, so things like amforth run their kernel out of the bootloader segment in order to write to the non-bootloader segment (to add definitions, for example). 12:56:53 malyn: oh gotcha, so that's why amforth has to blow away the arduino bootloader in order to operate 12:56:59 malyn, it is and you also have control over how big it is 12:57:09 neat trick, but that's not going to fly for what I want 12:57:11 i think i used the entier 4k max but you can set it to 2k or i think 1k 12:57:18 I440r: If there's no FPU, don't use the FPU instructions. That's common sense. 12:57:34 kc5tja, im not :) 12:57:35 That's why my eForth listing doesn't use it. 12:57:54 technomancy: Correct. I440r, right, and I think that's why amforth is not compatible with most (any?) other bootloaders. 12:59:11 malyn, my HOPE was to be able to fit in a USB CDC driver in the kernel space, i think im a HAIR too big to do that 12:59:23 kc5 see my email? 13:01:37 Yes. 13:02:00 kk 13:02:03 And, I'm not sure what other e-mail you had, but kc5tja@arrl.net is the only e-mail I give out to people outside of my work community. 13:02:04 so the main weird thing I don't understand about my implementation is that avr-size claims that the .text section is zero bytes but .data is 3.7k 13:02:23 kk :) that might have been the one i used previously 13:02:26 my understanding is that .data gets copied from .text at boot, so I don't understand how it can be bigger 13:02:47 but i dont seem to have u in the "let me put this in the contacts FOR you" list and dont seem to have any previous emails from you lol 13:02:57 also, the entire .c source for the implementation is under 3.7k, so I don't understand how .data can be bigger than that 13:03:18 technomancy, actually what if .data is compressed and decompressed at boot? probably not but that could explain it 13:03:34 not all .data needs to be initialized 13:03:37 I440r: I just don't get how .text can be completely empty 13:03:43 wtf? 13:03:57 I proactively avoid confrontation and disagreement especially when it comes to Forth. So, if I disappear again... 13:04:05 oh hang on... I was running avr-size on the .hex file 13:04:08 Life is too short to argue over trivialities. 13:04:29 I440r: if I run it on the pre-objcopy file it gives numbers that actually make sense 13:05:12 yea objcopy can bugger things up lol 13:05:31 whew; that leaves me with some breathing room. only 132 bytes of .data at the moment. 13:09:41 dumb newbie question: I'm writing my forth in C, which means I have to leave room for the C stack on top of my forth stack and dictionary. the C stack seems to grow down from the top of the memory, and my forth stack is growing from __malloc_heap_start. is there a good way to keep my dictionary separate from both these stacks, or does it make sense to place it on the forth stack? 13:10:42 i would keep data stac, return stack and user code in separate maps 13:10:44 I suppose this is why you're supposed to do it in asm rather than C? =) 13:11:07 eah 13:11:19 writing a high level language in a very high level language, madness 13:11:37 writing a forth in c is a good academic kinda thing to do 13:11:45 wont produce a forth i would ever use tho lol 13:11:55 hah. I've been doing mostly erlang and clojure before this, so writing C is giving me turing vertigo. 13:11:58 do you code asm tho 13:11:59 --- quit: overdamped (Ping timeout: 268 seconds) 13:12:02 if not.. do it in asm 13:12:12 LEARN asm AND FORTH by coding a forth in asm 13:12:20 I440r: before two weeks ago I hadn't done any C, asm, or forth. 13:12:21 You can totally use the C stack for holding things, as long as they're allocated in main() and referenced via globals. 13:12:36 but I found the docs for avr asm to be atrocious 13:12:39 However, be aware that not all OSes allow ginormous stacks, so it's best to malloc() the dictionary space anyway. 13:12:52 technomancy, welcome to the real world :) 13:13:19 I should add that this is a very special-purpose forth; I want to use it for writing firmware for my keyboard and probably not really anything else 13:13:21 What GForth does is malloc() a dictionary of some finite size, and then places the data and return stacks inside the dictionary, just as asm would do. 13:13:46 (my keyboard has a teensy (atmega32u4) on it) 13:13:48 (at least, it _used_ to do that.) 13:14:13 kc5 for my android version if my arm forth i allocate user code space and return stac in JNI_OnLoad() 13:14:39 I know nothing about Android. 13:14:40 my forth just uses sp for parameter stack 13:14:41 or JNI. 13:15:13 so when java calls forth to DO something.. it saves the stack state on entry. now i can abort with a sp = saved stack... and return to java 13:15:48 kc5 JNI is HORRENDOUS lol 13:16:34 I think after the Kestrel, I'm going to move away from Forth and into other language runtimes. It's been years and years since I touched Haskell. I'd like to get back into it. 13:16:42 technomancy: There are a ton of options here and you should pick the easiest one. :) For a C Forth, maybe keep the dictionary in a linked list and your stacks in a couple of fixed-size arrays somewhere? 13:17:15 What do you mean by keep the dictionary in a linked list? 13:17:20 have you seen how long it takes GHC to compile? 13:17:29 You don't have to do the whole dictionary-grows-up, stacks-grow-down thing; that's just historical. MFORTH allocates separate stacks for each task in high memory, for example, and then has a normal grow-up dictionary. 13:17:31 I440r: Yes, and that doesn't concern me. 13:17:41 malyn: that's more or less how I started, but I thought it might be simpler to do all my own allocation and avoid malloc entirely 13:18:04 maybe I'm getting ahead of myself 13:18:05 if isforth had everything ghc had it would take 3 seconds for isforth to compile 13:18:06 I've been hacking with/in/using Forth for over 15 years now. It's time to learn something new. 13:18:18 No it wouldn't. It'd take much longer. 13:18:21 kc5 its never not time to learn something new 13:18:24 You could probably avoid all allocation completely if you just hardcode some RAM addresses. MFORTH never does allocations, it just picks addresses at boot time. 13:18:39 which is why im doing android dev too :) 13:19:04 malyn: yeah, the compiler exposes the point at which the .data and .bss sections end 13:19:12 "calculates addresses" is more correct, I guess. 13:19:25 I440r: I'm working with Go right now, quite extensively. It's my new favorite language. It's Oberon-2, but with C syntax. I'd prefer the original Oberon-2 syntax, but, I'll take what I can get. It's about time the Unix community recognizes a good language. 13:19:42 Cool, that's basically what I get in MFORTH: the Tandy firmware tells me the start/end of free RAM and then I just slice-and-dice from there. 13:19:49 malyn: so if I set s0 to that I think I'm in good shape for the stack, but I don't really know what to do with the dictionary other than allocate entries on the stack too. 13:20:05 and I'm not sure that's a sane approach? 13:20:42 kc5 ive heared good things about go actually 13:21:01 but its still a moving platform. the devs will code the rug right out from under you still 13:21:11 technomancy: You might take a look at the comments in the MFORTH kernel, I have 'pictures' and stuff that explain the various RAM areas and how they grow: http://www.strangegizmo.com/products/mforth/source/main.asm.html 13:21:40 malyn: cool; thanks 13:21:58 I don't think that you want to allocate dictionary entries on the stack... that sounds weird, but maybe I am misunderstanding you. Perhaps you want some sort of C interop and if so then you might look at how something like FICL works. 13:22:37 yeah, actually I think my whole motivation for wanting to avoid malloc was probably based on a misunderstanding of how the C stack was allocated 13:23:12 if I can rely on it always growing from the top down, avoiding stomping on it shouldn't be difficult 13:23:41 I think that you will have trouble sharing the two stacks (for back-and-forth calling of C and Forth words) unless you are using a subroutine-threaded Forth. But I am not an expert there. 13:23:42 I440r: No, that's flat out false. Go 1 is out, and they have a strict compatibility process in place. 13:24:26 They're up to Go 1.2.1, with 1.3 around the corner (if not out already -- I have not checked). No backward incompatibilities to date. My Go 1.0 code still compiles and runs just fine. 13:25:00 oooh cool. was not aware of that :) 13:25:04 malyn: right; I'm fine handling the back-and-forth between the two stacks manually 13:25:26 Yep. Lots have changed in the Go community, including its stability. :) 13:25:49 well its instability was NOT a negative thing to count against them 13:26:30 technomancy: In that case I would probably just create a couple of fixed arrays in RAM for your dictionary and stacks. 13:26:33 im not a fan of google but i do like android as a development platform. and wtf im doing javaish OOP? 13:26:55 malyn: hm; fixed arrays for the dictionary too? 13:26:56 Nope. The biggest contentious non-issue in the community now is how to handle standardized package management. 13:27:17 I've currently got a linked list. 13:27:19 heh 13:27:25 I440r: I looked into Android development once. I ran away screaming. Refuse to touch it. Ever. 13:27:33 kc5tja: why? 13:27:45 I'm not young enough to understand its ecosystem. 13:27:47 apart from "java" 13:27:58 it's just Java, with a non-sucky UI library 13:28:03 Display management is a total mess. 13:28:16 Or at least was. But, listening to mobile-devs next to me, it still is. 13:28:19 technomancy: We might be talking about the same thing. I'm thinking of a big, empty array that you then spam linked-list entries into as you define words. And if you hit the top of the array then you have filled up the dictionary. 13:28:30 kc5tja: not really 13:28:31 Over-reliance on XML, as per any Java environment. 13:28:54 kc5tja: if you're determined to overthink the whole thing and misunderstand how OOP works in creative ways, it's a total mess 13:28:56 malyn: sure, but pre-allocating everything instead of mallocing on every entry? 13:28:57 And APIs that are half-assed and demonstrably incomplete. 13:29:24 "how OOP works in creative ways" -- that doesn't even make _sense_. 13:29:52 I understand how OOP works, having used Smalltalk, C++, Python, Ruby, Java, and many other OO-systems. 13:29:58 kc5tja: right 13:30:03 technomancy: Right. You said you wanted to avoid malloc, and a giant pre-created array for your dictionary is one way to do that. But a normal linked list with per-entry malloc is fine too. I didn't have a memory manager available when I wrote MFORTH, so I just pre-allocated my dictionary space. 13:30:04 I did some android work briefly, but the whole compile/upload/test cycle drove me off; very tedious 13:30:09 If Android abuses Java's OO architecture to do unnatural things, that's a good reason why I won't touch it. 13:30:10 so you understand how it works in Java as applied to Android, thne 13:30:11 *then 13:30:23 But that's not what I'm talking about. 13:30:30 malyn: oh, I think my motivation for avoiding malloc was flawed, but I see what you mean 13:30:33 kc5tja: you have to come up with innovative new ways of misunderstanding OOP to think that Android is a "mess" 13:30:47 uhh, no, I don't. 13:30:57 I just need to read the Javadocs for the existing APIs to know I want no part of it. 13:31:17 13:35:36 last question (for now): I'm getting a ton of warnings about pointers not getting properly casted to cells when pushing, etc from C: http://p.hagelb.org/orestes-warnings.html 13:35:51 are those worth fixing? isn't the whole point of the stack to be untyped? 13:36:41 --- join: overdamped (~overdampe@unaffiliated/overdamped) joined #forth 13:36:41 forth in general is untyped 13:37:03 yet another reason I should be using asm I suppose? =) 13:37:26 it seems like a fair bit of conceptual mismatch is unavoidable 13:37:30 technomancy: union { int i; void *p; } 13:37:59 kc5tja: ah, interesting; that could help. thanks. 13:38:03 That is guaranteed to be the larger of the two sizes, and you can then reference each without the need to cast. 13:38:55 lol kc5 ive done similar things :) 13:39:41 It's rare to find things that C cannot do that asm can. And when that case comes up, there's almost always some means to perform inline assembly. :) 13:40:23 oh sure; I mean I could just add casts everywhere too 13:40:28 it's just awkward 13:40:29 kc5 the ONLY thing i bitch about C not being able to do is "test the state of the carry flag" etc lol 13:40:36 anything else can be done in C and done efficiently 13:41:07 but casting just adds visual clutter. c is a very very visually cluttered way of expressing a problem solution 13:41:17 My big beef with C is its inability to return multiple values. You have to "fake it" by using pointers to out-values in the function's signature. 13:41:42 actually yea that too, any attempt to make it do so is just a KLUDGE 13:42:05 heh 13:42:15 Well, it's what Go does under the hood. a, b, c := foo(d, e, f) is basically encoded in assembly las foo(&a, &b, &c, d, e, f) behind your back. 13:42:19 I always thought of multiple return values as being a huge kludge on top of lacking pattern matching 13:42:22 kc5 i spoke with Linus T a few years back, he said he had a buddy working on a 2 stack C implementation. my guess is that if he ever produced it it would SOLVE that problem 13:42:24 except 13:42:32 how do you express multiple return values? 13:42:42 int int long float blah(....) 13:42:42 ? 13:42:55 You'd need to change the syntax. 13:42:57 but you also need a tuple type for that to make sense, so it's hard to fault C specifically for that 13:43:03 This problem is why Go uses the syntax that it does. 13:43:05 scheme, on the other hand... come on you guys 13:43:17 Probably something like this: (int int char) foo(int, int, int) {....} 13:43:33 i think the ONLY clean way of returning multiple values is the way FORTH does it 13:43:37 un named items 13:43:39 that are just there 13:44:02 I440r: have you used any ML derivatives? 13:44:25 erlang actually does a great job of this too 13:44:39 Scheme's approach to deconstructing a list into individual variables is surprisingly verbose, as is Lisp's. 13:44:41 well my game is now spawning random mobs and despawning them after 6 minuts... left it running for 20 minuts and nothing bad happnd yet :P 13:44:42 ML? 13:45:20 family of functional programming languages. ML stands for Meta-Language, although, it's evolved well beyond that now. 13:45:21 kc5tja: right; I find it odd that they included multiple return values in the standard rather than pattern matching, which is a much cleaner, more orthogonal solution 13:45:32 I440r: SML, haskell, OCaml 13:45:46 oh. none of the above 13:45:54 I hear Clojure is quite nice as Lisps go. I might want to study that in the future. 13:46:30 kc5tja: it has destructuring built-in, which makes multiple return values also nice. but it's not as nice as pattern-matching, since it can't branch depending on whether there's a match. 13:46:53 Yeah. I do miss Haskell's case-construct. :) 13:47:22 I440r: just meant to say that forth's isn't the only way to do it cleanly 13:47:24 i dont like forths case statements... 13:47:24 AND, the nice thing about Haskell's optimizer, if it knows a function is returning directly into a case-construct, it will return values in a Forth data-stack like manner. 13:47:32 case 1 of 2854628654 lines of code endof 13:47:57 I440r: Forth's CASE is not even a consideration. Don't even think of associating Forth's CASE (or even C's) and Haskell's case in the same sentence. TOOOOOOOOOOOOOOOOOOOOOOOOTALLLY different things. 13:48:08 heh 13:48:23 kc5 lol 13:48:24 yeah, that's like when you compare C macros and lisp macros, lispers always get annoyed by that =) 13:48:35 Yep. 13:49:04 isforths case is a bit better, case 1 opt DOTHIS <-- no "endof" and "of" was renamed to opt because mrreach didnt like me using OF when my case construct was that different 13:49:43 and "dothis" is a FORCED factored out totally separate word 13:50:23 i also dont allow falling throu from one case to the next the way C does 13:50:23 Well, if that's the case, why not use: case: 1 DOTHIS 2 DOTHAT 3 ... default errOut ; 13:50:45 actually becaose "opt" does something 13:50:59 case: leaves stuff on the stack and switches to INTERPRET mode 13:51:03 1 OPT blah 13:51:03 I440r: In Go, you can do that but you must explicitly use the "passthru" keyword. 13:51:10 opt does a ' , , sort of thing 13:51:36 OK, so it's building the same layout in memory. 13:51:54 and ;case switches complets the construct and switches back to compile mode 13:52:37 it compiles as a "docase" followed by a integer # cases, followed by the case exit point, followed by the default vector followed by N number/vector pairs for each case 13:53:04 and default can be null of course 14:00:17 --- part: b_jonas left #forth 14:04:25 github seems pretty confused about forth... .fs gets it treated as F#, and .f gets it treated as fortran =\ 14:06:20 technomancy: I know, it's really annoying. It also only knows about Pascal as .pas (which it calls "Delphi" since that was the popular Pascal on Windows), but .p was more standard on Macs. 14:06:50 derp 14:10:31 technomancy: Oh! *.fth works, I forgot about that. But that's not compatible with SwiftX, so I have to use *.f and then be writing Fortran code. :( 14:11:20 good to know 14:46:46 --- quit: Mat3 (Quit: Verlassend) 14:51:15 --- quit: true-grue (Read error: Connection reset by peer) 14:56:58 I440r: Nor sure what your e-mail is reporting. Can you clarify? 14:58:55 --- quit: aksr (Read error: Operation timed out) 15:01:48 --- quit: overdamped (Ping timeout: 265 seconds) 15:04:13 --- quit: madphilosopher (Quit: Leaving) 15:16:22 --- join: sdegutis (~sdegutis@unaffiliated/futile) joined #forth 15:16:25 Hi. 15:16:49 Is there a good Forth tutorial for polyglots? 15:17:44 as in people who already know other programming languages? 15:18:11 Yes. 15:18:20 well, there's a good tutorial for pretty much anyone here: http://www.forth.com/starting-forth/ :) 15:18:21 I've heard us called 'polyglots' by people in San Francisco before. 15:18:49 yeah. :) it also applies to people who speak multiple natural languages. :) 15:19:35 I basically meant a tutorial that skips basic programming intros. 15:19:56 dunno, but i'd still start there. 15:20:14 Most tutorials I've seen have several chapters of "this is an anonymous function, and here's what that means and how they're useful and what they're good at" etc. 15:20:16 Okay thanks. 15:20:37 yeah forth is pretty different from most languages. 15:20:42 forth is like lisp in that most of the challenge of learning it is un-learning what you already know 15:21:33 That's what all the languages say :P 15:21:41 forth doesn't really have anonymous functions, for example, although you could make something like them. 15:23:39 sdegutis: Forth delivers on that promise. 15:24:30 sdegutis: After all, what other language has a BEGIN...IF...WHILE...AGAIN...THEN...UNTIL...ELSE loop? ;-) 15:24:46 wow 15:24:50 (kind of made up, but not too far from the truth. eForth's implementation of NUMBER has a rather spectacular loop construct in it.) 15:25:00 That scares me away. 15:25:09 These loops aren't used often. 15:25:23 But, they exist because of how much detail the Forth compiler exposes to the programmer, which is one of thost mind-bending things. 15:25:27 those even. 15:25:41 the secret is that it's not really a predefined construct like a 'for' loop in c. 15:25:52 Such an ungooglable. 15:26:08 It should have been named xcufliupas. 15:26:21 Heheh 15:26:25 Never mind, I'm taking that name. 15:26:26 it's just the words BEGIN,IF,WHILE,AGAIN,UNTIL, and ELSE used in a custom order. 15:26:27 You can't have it. 15:26:32 er 15:26:37 what am i trying to say? :) 15:26:57 forth is really just one word after another. 15:27:22 there's no abstract syntax tree with a 'for' node. 15:27:43 So it's like assembly. 15:27:46 Right -- Forth doesn't have the concept of "inside a loop" like other languages do. IF and WHILE both leave things on the control-flow stack (depending on the Forth, data stack), which you can manipulate to get custom control flow. 15:27:50 i guess the forth equivalent of 'for' is DO ... LOOP 15:28:07 tangentstorm: There's also FOR and NEXT in more modern dialects. 15:28:13 ah cool 15:28:21 but you could use DO without LOOP or NEXT without FOR if you wanted to be clever. 15:28:31 Yeah. 15:28:35 sdegutis: If it helps, I find Forth to be the ultimate build-your-own-DSL language. You want to spend most of your time thinking about the vocabulary that defines your problem and solution; then you just code up those words. 15:28:40 NOT recommended, but it can be done if you really need it. 15:28:42 you'd just have to set the stack up the right way. 15:28:52 What problems would you say Forth is strongest at? 15:29:03 compressing code into a very very small space. 15:29:25 sdegutis: I'd say Forth is strongest at solving "instructional" type problems -- procedural descriptions, control applications, etc. 15:29:47 also things where you need the application to be extensible. 15:30:15 I'd argue it's not the strongest at mathematics due to how inconvenient it is to access variables randomly (e.g., try solving the quadratic formula without once using stack permutation or fetches or stores), but it's quite apropos for most other tasks. 15:31:04 It's also great for code that needs to be compact. Because of its concatenative nature, you can "refactor" a Forth excerpt with nothing more sophisticated than cut-n-paste. 15:31:20 Also, you can factor out common control flow constructs which you cannot do in other languages easily, if at all. 15:31:31 I envision using Forth as a scripting language to embed in my app, much like how other people use Lua. 15:31:36 Does this use-case seem appropriate? 15:31:42 very much so 15:31:48 For example, in C, you often have guards that return an error given invalid input. In Forth, you can write those words once, and refer to them repeatedly in each API entry. 15:32:00 Yep, Forth works pretty well for that. 15:32:03 sdegutis: Yes, FICL ( http://ficl.sf.net ) is exactly that. 15:32:05 Also as a configuration file format too. 15:32:23 However my app is written in ObjC, which is mostly just C with a few extra types. 15:32:34 Ah. 15:33:33 sdegutis: Maybe just embed FICL into your app then? It's pretty nice for the purpose that you just described. You can add your own C-backed words and stuff, for example. 15:33:54 i hadn't seen ficl before. is that yours, malyn? 15:34:03 Sounds like a good idea. 15:34:25 --- join: ASau` (~user@46.115.126.150) joined #forth 15:34:28 tangentstorm: No, but I have embedded it into apps before and extended it for a variety of purposes (which I need to make public...). 15:34:40 --- quit: ASau (Remote host closed the connection) 15:35:29 I added cooperative multi-tasking support to my FICL branch, for example, so that you could use FICL in environments without threading. (old-school 68k Mac OS FTW!) 15:35:45 :) nice 15:35:54 --- nick: ASau` -> ASau 15:37:02 i'm working on an app in free pascal at the moment, and i'm trying to restructure it as a forthlike command interpreter. 15:37:15 I added BLOCK support as well -- I'm a big fan of using blocks with Forth -- and then made it work with kc5tja's Vi-inspired text editor. I can actually program my app from inside of my app. It's like Inception. :) 15:37:51 lol 15:37:51 haha yeah exactly! 15:37:53 good movie 15:38:27 * I440r is now implementing Dijkstras path finding algorithm 15:38:39 Thank you all for your time, and may God bless you and yours in abundance. 15:38:45 Whoa, people still use VIBE?! Nice!! 15:38:46 its basically just a flood fill :) 15:38:51 --- part: sdegutis left #forth 15:38:51 come back any time, sdegutis :) 15:38:52 Not even *I* have the source to it anymore. 15:39:20 is this the text editor you were describing in that article? 15:39:30 kc5tja: Yeah, I have this 95%-complete extension system built for my app and it includes a modified version of VIBE. I have a TODO to send you the link if/when I ever finish the thing. :) 15:39:46 Hehe :) 15:39:57 kc5tja, do like Linus who "never keeps backups but just publishes it to the net" lol 15:40:27 this one? https://web.archive.org/web/20120930010713/http://www.falvotech.com/blog2/blog.fs/articles/1051 15:40:30 Who knew that my most impacting open-source creation would have been a simple block editor that fits in 3 screens. Now, if only I can write an OS to do the same... 15:41:00 tangentstorm: No, that's a different text editor -- more Emacs/VI-like. 15:41:10 VIBE is a screen editor (only edits 1024-byte blocks at a time). 15:41:12 if CM can write a 3 line IDE driver im sure you can fit an entire os into 3 blocks :))) 15:41:19 VI-like Block Editor, the name stands for. 15:41:21 oh. i really like that article. you should rescue it. :) 15:41:24 maybe it was more than 3 lines :P 15:42:03 I440r: It was more than that. 6 lines. It has to read AND write, you know. :) 15:42:09 tangentstorm: I've heard that from several people now. 15:42:15 duh my bad :) 15:42:38 tangentstorm: Problem is, I can't focus on a given project for very long. Even the Kestrel is suffering right at the moment. 15:42:54 On the plus side, I'm about to embark on a hardware-related project involving the GA144. 15:43:17 there's not a lot of information on the web about actually programming with proofs and formal methods. 15:43:34 (although i've recently discovered this course, which is fantastic: http://www.cs.toronto.edu/~hehner/FMSD/ ) 15:43:38 oh? 15:44:14 Yep. My current vision is an Arduino-like device, but with a GA144 instead of an ATmega microcontroller. 15:44:29 aren't those pretty pricey? 15:44:32 i like the atmega :P 15:45:11 technomancy: Define "pricey." 15:45:25 right now that == anything above $0 15:45:46 I thought they were over USD100 15:45:52 but I could be confusing it with something else 15:46:04 ttmrichter was working on something like this as a commercial venture, but green arrays stopped talking to them for some reason. :/ 15:46:45 technomancy: $20 per chip, but with a minimum quantity of 10. 15:46:45 would it have been for some academic purpose that didnt include revinue generation for green arrays? 15:46:52 So $200 *total*, but per chip, it's only $20. 15:46:53 ga144 costs about $20 for the chip, retail, but if you buy from them you have to buy in blocks of 10. 15:47:10 gotcha 15:47:11 oh maybe not blocks then. 15:47:22 you can buy them individually from schmartboard 15:48:02 from what i understand they'll event solder it onto one of their boards (which are $10 i think) for $3 15:48:03 The problem with Schmartboard is that they provide too little capacitance on the board, so the voltage sags when you try to use all the cores at once. 15:48:30 Otherwise, Schmartboard would be the best route to go. 15:48:35 can you add more caps elsewhere to prevent brown out? 15:48:39 No. 15:48:51 oh. that's really bad then :) 15:48:52 Not enough space on the board. If you try, you'll short an I/O pin. 15:48:57 Yeah, it's a board layout issue. 15:49:32 bummer. i thoguht maybe you could put oen across the board's gnd and vcc pins. 15:49:44 ugh. thought* .. put one* 15:50:25 bluekelp: You can, but it'd be so far from the chip that transients still happen. You'll introduce ringing in the supply due to lead inductance. 15:51:04 ...this is why i'm not an EE ;) 15:51:34 Yeah, I'm no expert either, but I do have some experience working with RF-grade circuits as an amateur radio operator. 15:51:42 RF is _really_ finicky. 15:52:08 indeed. i'm a ham too but haven't put in the time to figure enough of this out for myself 15:52:24 The ARRL handbook is a damn fine place to learn some hard-to-find electronics knowledge. 15:52:26 so while it makes sense when i read it, i don't have any practical or theoretical underpinning 15:52:28 It saddens me that GA stopped talking with ttmrichter though. That's disturbing. 15:53:05 OTOH, it could also be that they recognized that it'd cut sales of their development board too. So there is that. :) 15:53:12 unfort i think GA is a non-starter for anything other than die-hards. it's like they don't want to succeed 15:53:28 if your business plan is "seel demo boards but not chips" then you're in trouble 15:53:39 bluekelp: That's actually not the case. 15:53:45 They want to find customers for the chips badly. 15:53:54 What they don't understand, though, is the value of the hacker community. 15:54:13 Actually I got an email from GA last week. 15:54:18 I haven't responded to it yet, though. 15:54:35 Like they were, I'm "too busy" to even acknowledge receipt. 15:54:36 yes. without hackers the AVR/atmel would languish compared to its popularity in the adruino 15:54:56 (except in cars, perhaps) 15:55:09 Well, that and I'm probably going to use a chip other than the GA144 for this because of the months-long turnaround on emails. 15:55:10 Yep; without the Arduino, the world would still be using that retched PIC architecture. 15:55:39 retarded arch 15:55:48