00:00:00 --- log: started forth/12.01.10 00:00:31 Where does one even find swank by itself without being paired with Lisps and/or emacs? 00:02:56 ttmrichter: well, as I said, for example in R: http://common-lisp.net/~crhodes/swankr/ 00:03:23 So swank is a protocol, not an actual piece of software? 00:12:32 --- quit: karswell (Read error: Connection reset by peer) 00:12:55 --- join: karswell (~coat@93-97-29-243.zone5.bethere.co.uk) joined #forth 00:16:24 flip214: what makes you think that anyone would implement this server in a language with community where strong attitude against complex protocols prevails? 00:16:42 ttmrichter: yes, swank can also be understood as a protocol 00:17:57 DGASAU: I wouldn't see the swank protocol as complex ... a 6-digit hex number telling number of characters (for ascii = bytes), then a string that should be evaluated ... 00:19:09 I wouldn't need all features -- although it would be nice to have a debugger, inspector, stack trace, etc. available directly in the text editor during development 00:37:15 flip214: that's too complex already :) 00:37:34 well, is there some other protocol available? 00:37:41 Are you kidding? 00:38:04 There's strong attitude against _any_ complex protocols. 00:39:04 look, I'd like to use forth in a µC, and develop/debug via my text editor. 00:39:22 Similar things are already possible with slim[ev]/swank and various lisps, R, etc. 00:39:32 What is the symbol \265? 00:39:39 so I just asked whether there's something similar for forth 00:39:49 Well... 00:39:50 that should have been a mu, for micro(Controller) 00:40:01 You should have known the attitude in community. 00:40:14 I don't _want_ to use "complex" protocols, I just want something that works (TM) ;) 00:40:16 It is clearly expressed in beginner books as well. 00:40:26 tty works :) 00:41:02 So I'd have to write my own debugger/tracer/inspector etc.? 00:41:07 Yes. 00:41:13 I cannot believe that there's nothing already there in forth ... 00:41:36 Well... You may not believe it, I don't mind. :) 00:41:51 having a line-based protocol is fine 00:42:17 Run Forth interpreter in shell buffer in your Emacs. :) 00:42:53 I'm running vim, but never mind 00:43:15 This has its benefits. 00:43:49 In particular, it brings history and more or less sane editing facilities. 00:44:08 well, the most important thing is to be able to send things to the forth implementation ... like EvalExpr and EvalDefun... 00:44:30 having clickable stack traces etc. would be nice, too, of course 00:45:05 What do you want to click there? 00:45:13 Numbers? 00:46:00 ".s" prints your stack. 00:46:10 Return stack isn't useful when in REPL. 00:46:19 You can safely ignore it. 00:47:02 REPL isn't reentrant, thus all you have is top level. 00:48:36 What you might want is a facility to print floating point stack, 00:48:45 if you work with FPNs. 00:50:15 well, if I'm playing around with eg. gforth I can get this: 00:50:17 :30: Stack underflow 00:50:17 >>>c<<< 00:50:17 Backtrace: 00:50:17 $7F553B90D320 + 00:50:18 $7F553B90D360 a 00:50:20 $7F553B90D458 b 00:50:41 so there's a stack trace with words, and these could be "clickable" (ie. jump to the definition in another buffer) 00:50:58 and hovering over a word could try to show its value, etc 00:51:05 so there are some things that can be done 00:51:07 This isn't guaranteed, since (IIRC) gforth guesses those words. 00:51:41 I don't care _how_ the implementation does it ... it eases debugging 00:52:13 in the microcontroller I won't have it, too, but that doesn't mean that I have to entirely avoid using stacktraces during development 00:52:14 Anyway, gforth doesn't store source position of definition. 00:52:47 (Unless they suddenly made very huge progress in few last months.) 00:52:57 not, but either the editor does, or it sends the position into some extra dictionary 00:54:26 Then why M-. doesn't work for you? 00:55:24 If you maintain it in tags, then tags are the solution. 00:55:55 Alternatively, use "see". 00:57:34 In any case there's very little that can be done with open stack. 01:00:07 I'll check what can be done with SLIME. 01:00:26 Maybe there's at least some marginal benefit. 01:15:07 DGASAU: I'm on VIM, no meta here 01:15:27 exuberant-tags doesn't understand forth (it says) ... what are you using? 01:15:56 swank/slime has debugging, pretty printing for inspect, etc, too; thread list, thread kill, ... 03:49:21 There're no threads in Forth. :) 03:50:29 DGASAU: Not in *standard* Forth. 03:50:41 Lots of Forth environments add concurrency in some form or another, including threads. 03:51:57 Part of the problem in making the kind of took flip214 is envisioning is that the first question that leaps to mind is 'whose Forth'? 03:52:05 By which I don't even mean (just) which implementation. 03:52:27 Forth, more than any other language I know, is an intensely personal environment. It would be decidedly non-trivial to do what he's asking. 03:52:54 "Lots" is an exaggeration. 03:53:35 Also note that those "lots" usually use coroutines and call them "threads". 03:53:45 ttmrichter: there are quite a few implementations for CL ... and there's a swank for scheme, and one for R (which doesn't even has S-expressions!), and so on 03:53:54 Sure. 03:54:00 I know that. 03:54:14 You're missing the point. 03:54:22 Forth is not CL. 03:54:27 Forth isn't even Scheme. 03:54:43 R is neither, too 03:55:07 Forth is much much simpler. 03:55:23 There're no threads. 03:55:27 Not even call frames. 03:56:23 And community finds it perfectly acceptable if interpreter crashes on first error. 03:56:30 R has no threads, either ... and some implementations at least _guess_ call-frames, as you said 03:56:42 That's not call frames. 03:56:44 crashing is not an issue if the whole work is in a text-editor anyway 03:57:03 Those are numbers that look similar to return addresses. 03:57:21 well, never mind ... perhaps I'll start something, although I'm not sure when I've got the time 03:57:48 "good enough" is worse than "perfect", but better than "nothing" 03:58:17 The problem is I doubt if it's even "good enough" given how Forth is implemented. 03:58:22 Consider that the interpreter crashed than printed guessed backtrace. 03:58:42 For example if somewhere in your software stack someone used the three-line module system there will be huge swaths of words JUST PLAIN MISSING. 03:59:10 They'll be 100% invisible to outside probing unless the system knows a *lot* about the internals of the implementation. 03:59:19 And that's one, solitary, simple feature. 03:59:40 And before you say "that's good enough", keep in mind that those missing words may have been shadowing other words. 03:59:44 Which are once again visible. 03:59:56 So not only will your system not see the missing words, they'll see the *WRONG* words entirely. 04:00:02 Anonymous words are more problematic. 04:00:11 So it's not "good enough" because it's damagingly misleading. 04:00:24 DGASAU: Anonymous words aren't going to mislead you. They'll just not be visible. 04:00:34 It's the renamed and then hidden words that are a problem. 04:01:03 Well... 04:01:05 Not at all. 04:01:40 * ttmrichter raises an eyebrow. 04:01:46 There's high chance that anonymous word will be called as some preceding or succeding word. 04:01:53 Ah, I see what you mean. 04:02:03 So yeah, they're just as damaging in an entirely different and frustrating way. 04:02:38 With properly named words you have chance at least going through all definitions and find some roots. 04:02:55 With the three-line module system you can't do that. 04:03:00 It stubs out the words in the dictionary links. 04:03:16 You still have word name. 04:03:17 The words aren't reachable in the dictionary any longer. 04:03:27 You can just go through all tags in your database. 04:03:41 Well... 04:03:55 Well, yeah. Which is what I said about having to have your server know the internals of every Forth environment that could be plugged into it. 04:04:03 If you kill headers you essentially make all words anonymous. 04:04:13 The approach used is this: 04:04:45 I understand that you mean "wordlist >order ... order> drop" 04:04:55 OLD -> WORDS -> FOO -> -> HIDDEN -> WORDS -> HERE -> FOO -> -> AND -> SO -> ON 04:05:23 When the final word of the module system is invoked, the link from is shorted to skipping all the intervening words. 04:05:41 Well... 04:05:46 So the shadowing FOO is no longer visible without Deep Knowledge™ of the dictionary layout. 04:06:22 Guessing "frames" as above is done with dictionary structure knowledge. 04:06:35 I have vague memory of looking at the source. :) 04:07:56 But you couldn't make a general-purpose server like what flip214 wants that could do it. 04:08:00 Sure. 04:08:02 You'd have to make one for each and every Forth implementation. 04:08:13 Forth isn't actually introspective. 04:08:31 You can't even iterate over words in your wordlist. :) 04:08:45 And you'd have to be very, very, very careful because of the painfully weird things people can do with ease that can't be predicted without Deep Knowledge™ of that trick. 04:09:13 Like the 700-line garbage collector. 04:09:17 The 3-line module system. 04:09:22 The 25-line object system. 04:09:24 Etc. etc. etc. 04:09:30 Sure. 04:10:05 The attitude is to keep Forth minimal to the point of uselessness. 04:59:17 --- quit: xpolol (Ping timeout: 240 seconds) 05:31:10 --- join: nighty- (~nighty@static-68-179-124-161.ptr.terago.net) joined #forth 06:49:46 --- join: xpolol (~xpololz@50.80-203-124.nextgentel.com) joined #forth 07:37:57 --- quit: ttmrichter (Quit: Leaving) 07:38:14 --- join: ttmrichter (~ttmrichte@2001:41c8:1:5696::169) joined #forth 07:38:53 --- quit: ttmrichter (Remote host closed the connection) 07:39:43 "The major efficiency improvement of the CPU/16 over the Canonical Stack Machine is the replacement of the Memory Address Register with the Program Counter." - http://www.ece.cmu.edu/~koopman/stack_computers/sec4_2.html (source) 07:39:54 As I know it, the PC and MAR has two quite different tasks; PC would point to the instruction being executed and MAR would be written and interrogated to fetch the instruction. 08:39:36 --- quit: segher (Ping timeout: 252 seconds) 08:54:51 --- join: segher (~segher@5ED3C8DF.cm-7-4d.dynamic.ziggo.nl) joined #forth 09:18:35 --- join: haole (~chatzilla@2001:1291:262:1:b4f2:53e6:91f5:5d02) joined #forth 10:11:44 --- quit: haole (Read error: Connection reset by peer) 10:40:32 --- quit: ASau (Read error: Connection reset by peer) 10:42:45 --- join: ASau (~user@95-28-56-159.broadband.corbina.ru) joined #forth 12:56:02 --- quit: flip214 (Remote host closed the connection) 13:00:51 --- join: flip214 (~marek@unaffiliated/flip214) joined #forth 13:29:43 --- join: _spt_ (~postmaste@host-92-4-56-21.as43234.net) joined #forth 13:29:43 --- quit: _spt_ (Changing host) 13:29:44 --- join: _spt_ (~postmaste@unaffiliated/-spt-/x-5624824) joined #forth 14:10:45 --- quit: nighty- (Ping timeout: 248 seconds) 14:27:00 --- quit: karswell (Read error: Connection reset by peer) 15:21:13 --- join: xpololz (~xpol@50.80-203-124.nextgentel.com) joined #forth 15:21:34 --- quit: xpololz (Client Quit) 15:55:28 --- quit: _spt_ (Quit: leaving ..) 17:21:43 --- join: Snoopy_1711 (Snoopy_161@dslb-178-004-064-059.pools.arcor-ip.net) joined #forth 17:23:09 --- quit: Snoopy_1611 (Ping timeout: 252 seconds) 17:25:54 --- quit: Snoopy_1711 (Ping timeout: 252 seconds) 17:30:09 --- join: Snoopy_1611 (Snoopy_161@dslb-178-004-219-008.pools.arcor-ip.net) joined #forth 17:32:38 --- join: Snoopy_1711 (Snoopy_161@dslb-188-107-168-062.pools.arcor-ip.net) joined #forth 17:34:41 --- quit: Snoopy_1611 (Ping timeout: 252 seconds) 17:35:44 --- join: ASau` (~user@89-178-244-244.broadband.corbina.ru) joined #forth 17:39:02 --- quit: ASau (Ping timeout: 240 seconds) 17:54:45 --- nick: ASau` -> ASau 18:06:47 --- join: ttmrichter (~ttmrichte@2001:41c8:1:5696::169) joined #forth 18:10:31 --- join: Snoopy_1611 (Snoopy_161@dslb-178-004-077-243.pools.arcor-ip.net) joined #forth 18:10:59 --- quit: Snoopy_1711 (Ping timeout: 252 seconds) 20:09:20 --- quit: segher (Ping timeout: 240 seconds) 21:06:30 --- join: segher (~segher@5ED3C8DF.cm-7-4d.dynamic.ziggo.nl) joined #forth 21:14:49 --- join: karswell (~coat@93-97-29-243.zone5.bethere.co.uk) joined #forth 23:59:59 --- log: ended forth/12.01.10