00:00:00 --- log: started forth/14.10.19 00:07:26 --- join: samrat (~samrat@49.244.72.106) joined #forth 00:25:20 --- quit: joneshf-laptop (Ping timeout: 258 seconds) 00:50:46 --- join: Azel (~Azel@ter75-5-78-233-220-89.fbx.proxad.net) joined #forth 00:55:35 --- quit: Azel (Ping timeout: 272 seconds) 01:14:44 --- quit: true-grue (Read error: Connection reset by peer) 01:40:24 --- join: joneshf-laptop (~joneshf@98.208.35.89) joined #forth 01:43:59 --- quit: samrat (Ping timeout: 240 seconds) 02:39:21 --- join: ttmrichter_xm (~ttmrichte@113.57.244.69) joined #forth 02:39:45 --- quit: ttmrichter__xm (Ping timeout: 260 seconds) 02:44:31 --- join: Azel (~Azel@ter75-5-78-233-220-89.fbx.proxad.net) joined #forth 02:48:58 --- join: Azel_ (~Azel@ter75-5-78-233-220-89.fbx.proxad.net) joined #forth 02:49:10 --- quit: Azel (Ping timeout: 260 seconds) 02:59:01 --- join: xyh (~xieyuheng@113.119.215.128) joined #forth 03:05:56 --- quit: Azel_ (Read error: Connection timed out) 03:15:23 --- join: _spt_ (~jaat@unaffiliated/-spt-/x-5624824) joined #forth 03:24:09 --- join: Guest52352 (~Azel@ter75-5-78-233-220-89.fbx.proxad.net) joined #forth 03:24:09 --- quit: Guest52352 (Read error: Connection reset by peer) 03:27:06 --- quit: proteusguy (Read error: Connection reset by peer) 03:36:11 --- join: ttmrichter__xm (~ttmrichte@114.111.167.13) joined #forth 03:38:02 --- quit: ttmrichter_xm (Ping timeout: 255 seconds) 03:44:29 --- join: proteusguy (~proteusgu@ppp-110-168-229-152.revip5.asianet.co.th) joined #forth 03:44:58 --- join: spt_1 (~jaat@host-92-12-214-82.as43234.net) joined #forth 03:46:33 --- quit: _spt_ (Ping timeout: 240 seconds) 03:49:41 --- join: _spt_ (~jaat@host-92-12-214-240.as43234.net) joined #forth 03:49:48 --- quit: _spt_ (Changing host) 03:49:48 --- join: _spt_ (~jaat@unaffiliated/-spt-/x-5624824) joined #forth 03:52:31 --- quit: xyh (Remote host closed the connection) 03:52:33 --- quit: spt_1 (Ping timeout: 240 seconds) 04:17:34 --- quit: ttmrichter__xm (Quit: ttmrichter__xm) 04:17:49 --- join: ttmrichter_xm (~ttmrichte@114.111.167.13) joined #forth 04:34:00 --- join: Azel (~Azel@ter75-5-78-233-220-89.fbx.proxad.net) joined #forth 04:34:13 --- quit: Azel (Read error: Connection reset by peer) 04:35:24 --- join: Azel (~Azel@ter75-5-78-233-220-89.fbx.proxad.net) joined #forth 04:35:28 --- quit: Azel (Read error: Connection reset by peer) 04:40:01 --- join: Azel (~Azel@ter75-5-78-233-220-89.fbx.proxad.net) joined #forth 04:40:11 --- quit: Azel (Read error: Connection reset by peer) 05:21:42 --- join: xyh (~xieyuheng@113.119.215.128) joined #forth 05:24:25 is it really a good feature that ``the order of function definitions can be arbitrary'' ??? 05:25:16 or "in what situations this feature is not wished?" 05:48:10 --- quit: ttmrichter_xm (Read error: Connection reset by peer) 05:48:26 --- join: ttmrichter_xm (~ttmrichte@222.242.224.90) joined #forth 05:59:24 --- join: Zarutian (~zarutian@168-110-22-46.fiber.hringdu.is) joined #forth 06:00:23 --- join: Zarutian_ (~zarutian@168-110-22-46.fiber.hringdu.is) joined #forth 06:00:23 --- quit: Zarutian (Read error: Connection reset by peer) 06:00:24 --- nick: Zarutian_ -> Zarutian 06:04:04 --- join: samrat (~samrat@49.244.15.0) joined #forth 06:08:42 xyh: Context? 06:13:35 in forth, the function-call-graph must be sorted by user, and must be a tree. 06:13:38 I am trying to make some design decisions in my implementation. 06:14:36 Well one of the strengths of the tree structure is that it permits redefinitions of words without breaking pre-existing words. 06:16:15 I think I can achieve this good feature by sorting the function-call-graph incrementally in an interpreter 06:33:39 ttmrichter: actually, I have implemented the "interpreter works as a compiler" stuff I mentioned the other day. I am trying to add more good features about compiler into it. 06:57:51 --- part: xyh left #forth 07:10:18 --- join: vanila (~user@unaffiliated/vanila) joined #forth 07:21:34 --- quit: samrat (Quit: Computer has gone to sleep.) 07:43:36 --- join: xyh (~xieyuheng@2001:250:3002:5550:6ea1:cc0f:bcb2:b187) joined #forth 07:47:55 xyh: interesting...so you don't have a REPL?...or I guess you could still have one...it all depends 07:48:09 xyh: do you have to compile /everything/ ? 07:48:17 xyh: like call the compiler on the file? 07:51:24 protist: when you type ``1 2 + .'' in my repl, it defines a function of which the function-body is ``1 2 + .'' and call it. 07:52:00 that is weird 07:52:05 what is the advantage 07:52:12 I want more low level details 07:52:17 define what "compile" means for ou 07:52:19 you* 07:52:24 threaded code? 07:54:37 yeah, indirected threaded code 07:55:38 then I don't see why you would compile that 07:55:47 you will just end up deallocating it after 07:55:52 right? 07:56:05 or do you have a gc and some cool ideas? 07:59:30 --- quit: xyh (Ping timeout: 265 seconds) 08:00:49 --- join: xyh (~xieyuheng@2001:250:3002:5550:6ea1:cc0f:bcb2:b187) joined #forth 08:02:55 about the advantages, otherwise one has to handle some syntax-key-words (such as "if" "then") twice, once for compilation once for interpreting 08:04:28 I use a buffer, over write it on each call 08:04:58 protist: One clear advantage that I can see is that it makes the equivalent of closures very easy to implement. 08:05:10 Higher-order programming in normal Forth is a bitch. 08:05:29 ttmrichter: a bitch mostly because of garbage collection 08:05:45 xyh: ah makes sense for that 08:05:59 I have a conservative collector for Forth lying around somewhere that's just a few blocks of code. 08:06:46 ttmrichter: i have one mostly written...but it is about what it will collect...and don't collect things that are on the stack, either 08:06:55 ttmrichter: gets complicated when you try to make it all seemless 08:07:21 Indeed it would be. 08:07:32 My own reaction to that would be "don't make it seamless". 08:07:43 Seamlessness is a trap. 08:07:49 Leads to ugly, leaking abstractions. 08:08:06 (I'm similarly opposed to making remote procedure calls the same as a local function call.) 08:11:02 ttmrichter: about remote procedure calls. That stuff is badly ping dependent if implemented naively. Better to use eventual sends and promise pipelining which force far/near reference semantics into your code. 08:12:01 ttmrichter: I should know as I hang around a channel called #erights (has nothing to do with DRM) on freenode that is about, among other interesting stuff, that. 08:12:03 Zarutian: In short don't disguise the fact that the remote procedure is a network call. 08:12:17 yeb 08:12:27 Make it easy. Make it nice. Give it good, clean semantics. BUT DO NOT CONFLATE IT WITH A LOCAL FUNCTION. 08:13:10 I have a incremental-gc for list (lisp-like list, with "cons" "car" "cdr") and string. the list is just a array of "cons-entries" I use a "marking-algorithm" on it, but the string need a "copy-algorithm". makes it hard to be seamless. 08:13:54 but something like: ble := bla <- ding("42", otherStuff) \n ble <- song() \n would be streamed out in the same packet. Though ble would a promise fore the eventual result of bla <- ding("42", otherStuff) 08:14:35 xyh: you intern the strings somewhere when parseing? 08:15:06 ttmrichter: exactly. 08:16:24 though I do not see how one wouldnt get away with semi-local/semi-remote procedure calls on multicore chips that follow greenarrays style 08:16:48 Well, there you're not really doing "remote" so much as you're doing actors. 08:17:13 --- quit: bbloom (Read error: Connection reset by peer) 08:17:18 (where you dont have much space at each core and you want to use traditional forth on it. Other cores might just act as memory.) 08:17:18 Zarutian: no, two string heaps with a copy-and-compress algorithm 08:17:22 Admittedly very low-level, very primitive actors, but still recognizably actors. 08:17:50 (this is when one hasent quite grasped yet how to program such chip) 08:17:53 --- join: bbloom (~bbloom@cpe-68-175-72-82.nyc.res.rr.com) joined #forth 08:18:14 The secret sauce is the built-in ROMs. 08:18:23 That's where you get a clue how you're expected to use the cores. 08:18:36 but stuff like greenarrays GA144 seems to fit with Flow Based Programming perfectly 08:18:56 Flow-based, actor model, etc. Yeah, basically anything in that vein. 08:19:18 One of my engineer friends said it sounded like, and I quote, "FPGAs for people who don't understand FPGAs." :) 08:19:37 which imo should be tought in programming 203 (the next after programming 101) 08:20:01 Concurrency should be a central concept in CS these days, yes. 08:20:20 It would be nice to see us exceed the knowledge of the late '60s and early '70s for a change. 08:20:39 ttmrichter: on FPGAs. Why the hell do I want my stuff to be clocked? But then again I would happy with a programmable NOR gate matrix 08:20:55 (I'm not joking. Much of what we think of now as nifty new concepts in concurrency was pionerred in Buroughs Large Systems in the SIXTIES.) 08:21:08 Zarutian: There's nothing that demands an FPGA be clocked beyond tradition. 08:21:34 s/pionerred/pioneered/ 08:22:45 ttmrichter: I like to dig around and read old computer science papers and point them out to people when they think they have discovered something neat. People often like that. Specially when they get to the sections on pitfalls the original authors foresaw and steered clear of. 08:23:12 * ttmrichter is a programming archaeologist, fundamentally. 08:23:36 I keep seeing the kiddies create "new" things and wince because I remember when those new things were old hat that we left behind for a reason. 08:23:45 Like using reactors for concurrency. 08:23:49 (Node.js) 08:23:58 ttmrichter: nice to meat you Pham Neuen -Deepness in the sky reference 08:24:02 Or using hierarchical schemaless databases. 08:24:06 * ttmrichter grins. 08:24:17 I can't believe someone finally spotted that reference! 08:24:24 reactors? you mean like in event-loops? 08:24:38 I've been calling myself a programming archaeologist for over a decade and NOBODY CAUGHT ON! 08:24:44 Yes. Event loops with callbacks. 08:24:59 Node.js being the "big new thing" right now in replicating 1950s technology. 08:25:06 well, promises and promise pipelining can help with the 'callback hell' 08:25:28 Promises and futures both are a good mechanism to deal with callback hell, yes. 08:25:35 my programming language of choice after QBASIC was for a long while Tcl and Tk 08:25:42 But ... they're also a great way to deal with PARALLELISM with your concurrency. 08:25:55 Oldest language I still use daily: Rexx. 08:26:04 Oldest language I still crack open for fun: SNOBOL4. 08:26:24 ttmrichter: Rexx, I think I saw a cheatsheet somewhere one the net for Tcl'ers ;-) 08:26:48 oh, how does one deal with parallelism with promises? 08:27:31 When you set up your promise, nothing says that the runtime can't allocate some time or a core for the job while your mainline code continues to run. 08:27:41 So when you access the value in the promise it may already be there for you, so no wait. 08:27:56 That's how Mercury deals with it (now). 08:28:10 --- join: samrat (~samrat@49.244.15.0) joined #forth 08:28:26 ttmrichter: indeed. This is how intervat messaging and computation happens in E vats (concurrent event loops with local heaps) 08:29:44 ttmrichter: re FPGA clocking tradition: it means to me that there is an assumption there that one day will bite one in the arse. 08:29:53 There always is. 08:30:31 ttmrichter: this is often how I do hacking: I sniff out assumptions that the programmer made and violate them. Has served me well so far. 08:30:42 Anyway, closing in on midnight here. Wife is giving me some of the evil eye stuff. Chat later. 08:30:51 substitute systems designer for programmer and so on. 08:31:15 aah, that is why I dont see you much around here when I am awake. Quite the timezone difference. 08:31:18 good night then. 08:55:08 --- quit: ttmrichter_xm (Ping timeout: 260 seconds) 09:03:14 --- quit: samrat (Quit: Computer has gone to sleep.) 09:14:36 --- join: robdubya (~robdubya@108-218-139-74.lightspeed.austtx.sbcglobal.net) joined #forth 09:16:01 --- quit: Zarutian (Quit: Zarutian) 09:23:06 --- join: samrat (~samrat@49.244.15.0) joined #forth 09:24:13 --- quit: xyh (Remote host closed the connection) 09:32:47 --- join: Mat3 (~Mat@91.64.103.149) joined #forth 09:32:49 hello 09:39:02 Mat3: Greetings. 09:47:57 hi DKordic` 09:52:30 howdy 09:52:50 <_spt_> hello from the UK 09:53:37 * _spt_ just updated the JupiterACE's Forth site 09:55:21 --- join: Zarutian (~zarutian@46.22.110.168) joined #forth 09:55:43 --- quit: Zarutian (Read error: Connection reset by peer) 09:55:49 I'm reasoning about wheather structures should be first class elements of concatenative stack language (like for example reforth parses them) or not 09:55:57 --- join: Zarutian (~zarutian@168-110-22-46.fiber.hringdu.is) joined #forth 09:56:25 ^languages 09:58:37 I think because the question implicy some kind of value-format differentiation the answer is yes 10:02:34 --- quit: protist (Quit: Konversation terminated!) 10:08:34 --- quit: samrat (Quit: Computer has gone to sleep.) 10:10:27 _spt_: Do you know the AX81 ? This self build computer has a Jupiter ACE mode 10:10:52 (beside ZX80 and 81) 10:12:58 --- quit: dys (Remote host closed the connection) 10:24:57 im reading that forth has two stacks 10:25:01 but where are they? 10:25:10 opposite sides or interleaved or something? 10:27:19 some Forths will have more than two 10:27:32 the two that every Forth will have, are data and return 10:28:20 --- join: samrat (~samrat@49.244.15.0) joined #forth 10:30:05 --- quit: joneshf-laptop (*.net *.split) 10:30:06 --- quit: klltkr (*.net *.split) 10:30:06 --- quit: u-ou (*.net *.split) 10:30:09 --- quit: nisstyre (*.net *.split) 10:30:43 --- join: klltkr (~klltkr@unaffiliated/klltkr) joined #forth 10:31:19 --- join: joneshf-laptop (~joneshf@98.208.35.89) joined #forth 10:31:50 --- join: nisstyre (~yourstrul@li611-52.members.linode.com) joined #forth 10:37:45 --- join: u-ou (no-n@that.bitch.stole-your.info) joined #forth 10:37:55 --- nick: u-ou -> Guest44326 10:40:31 --- join: elaforest (~elaforest@unaffiliated/elaforest) joined #forth 10:41:13 <_spt_> Mat3: No I don't got a linky? 10:48:47 http://www.jcwolfram.de/projekte/avr/ax81/main.php 10:50:21 <_spt_> ah German not my favourite! thanks for the link 10:50:44 well, try Google translate 10:51:10 <_spt_> I think I can just about read it.. 11:00:47 <_spt_> Mat3: ax81 - neat, if I had more time I would have ago at building one for fun. 11:01:59 --- join: true-grue (~grue@128-68-26-170.broadband.corbina.ru) joined #forth 11:06:09 --- quit: elaforest (Remote host closed the connection) 11:06:38 --- quit: samrat (Quit: Computer has gone to sleep.) 11:28:24 you will need some hours, not more 11:29:27 however, I think you can buy alos prebuilded versions 11:29:31 also 12:27:37 is there an OS writen in forth I can boot on x86 computers? 12:29:30 --- join: Azel (~Thunderbi@ANice-653-1-507-169.w86-205.abo.wanadoo.fr) joined #forth 12:33:20 --- join: spt_1 (~jaat@92.12.214.240) joined #forth 12:36:52 --- quit: _spt_ (Ping timeout: 240 seconds) 12:57:38 --- quit: spt_1 (Quit: irc- et) 13:00:04 --- quit: nisstyre (Changing host) 13:00:04 --- join: nisstyre (~yourstrul@oftn/member/Nisstyre) joined #forth 13:04:02 vanila: Yes, ForthOS 13:04:36 http://www.forthos.org/ 13:05:39 or FOS: https://sites.google.com/site/forthoperatingsystem/ 13:10:15 thanks cool! 13:12:25 you can also try retroforth priour to 10.x (there exist a bare-metal port for the 9'er versions) 13:14:55 also FreeBSD include a Forth system (FICL) as boot manager so if you install the FreeBSD bootloader inclusive minimal kernel you get a bare-metal Forth system 13:15:35 that's so neat 13:16:11 something related exist in form of GNU Forth (gforth) EC as kernel modul for recent Linux versions 13:17:05 you can also try Colorforth 14:08:40 *shudder* colorForth 14:16:48 --- quit: robdubya (Remote host closed the connection) 14:17:04 --- join: robdubya (~robdubya@108-218-139-74.lightspeed.austtx.sbcglobal.net) joined #forth 14:22:02 well, I see some advantages (it's way simplier to implement than the classic Forth model) 14:26:44 principle, it's one idea for combination of edit and compilation (which brings up possibilities of code analysis at edit time), reducing dictionary searches as side effect 14:37:44 sorry for my english, late time here 14:39:14 anyhow; Colorforth does not advances in these topics: Edit time analysis and code optimization (I do not know why because both are obvious) 14:46:29 vanila, old macs and sun boxes had something like FICL too. 15:00:57 bjorkintosh: you talking about OpenFirmware that is tokenized forth? 15:02:42 yeah. 15:17:36 ciao 15:17:51 --- quit: Mat3 (Quit: Verlassend) 15:42:52 --- quit: true-grue (Read error: Connection reset by peer) 16:24:39 forth is amazing i love it 16:24:47 thi sis so clever 16:32:56 * Zarutian wonders why the fuck x86 is so damn shitty 16:37:38 oh that is right. Shitty design methodology. 17:34:19 --- part: Guest44326 left #forth 17:34:23 --- quit: vanila (Quit: Leaving) 17:39:05 --- join: u-ou (no-n@unaffiliated/no-n) joined #forth 17:59:22 --- join: mark4 (~mark4@cpe-68-203-183-77.tx.res.rr.com) joined #forth 18:13:28 --- quit: Zarutian (Quit: Zarutian) 18:32:06 --- join: saml_ (~saml@pool-71-190-3-251.nycmny.east.verizon.net) joined #forth 18:53:28 --- join: samrat (~samrat@49.244.118.158) joined #forth 19:21:48 --- join: ehaliewicz (~user@50-0-50-37.dsl.dynamic.fusionbroadband.com) joined #forth 19:25:55 --- quit: ehaliewicz (Remote host closed the connection) 20:11:48 --- quit: saml_ (Quit: Leaving) 20:14:14 --- quit: mark4 (Quit: Leaving) 20:37:03 --- quit: samrat (Ping timeout: 244 seconds) 20:40:49 --- join: samrat (~samrat@49.244.37.227) joined #forth 20:42:58 --- quit: bluekelp (Ping timeout: 260 seconds) 20:46:51 --- join: bluekelp (~bluekelp@2001:470:1:41:1de:4434:bfd6:e974) joined #forth 20:46:51 --- mode: ChanServ set +v bluekelp 20:50:29 --- quit: MrMobius (Ping timeout: 255 seconds) 21:43:09 --- join: MrMobius (~Joey@c-98-223-189-47.hsd1.in.comcast.net) joined #forth 21:53:55 --- quit: proteusguy (Remote host closed the connection) 22:17:12 --- join: protist (~javery@207.225.69.111.dynamic.snap.net.nz) joined #forth 22:25:29 --- quit: Azel (Ping timeout: 255 seconds) 23:12:07 --- quit: cataska (Read error: Connection reset by peer) 23:29:43 --- quit: samrat (Ping timeout: 245 seconds) 23:30:19 --- join: proteusguy (~proteusgu@180.183.43.157) joined #forth 23:32:11 --- join: cataska (~cataska@118-163-69-1.HINET-IP.hinet.net) joined #forth 23:33:15 --- join: samrat (~samrat@49.244.1.124) joined #forth 23:37:55 --- join: ttmrichter_xm (~ttmrichte@113.57.246.241) joined #forth 23:43:36 --- join: ttmrichter__xm (~ttmrichte@113.57.183.79) joined #forth 23:45:23 --- quit: ttmrichter_xm (Ping timeout: 265 seconds) 23:47:30 --- quit: proteusguy (Ping timeout: 258 seconds) 23:49:18 --- join: proteusguy (~proteusgu@180.183.43.157) joined #forth 23:59:59 --- log: ended forth/14.10.19