00:00:00 --- log: started forth/20.03.02
00:00:30 <proteus-guy> ncurses is probably the ultimate in non-GUI visual expression. ;-) and it's fairly scary when you wade into it very deep.
00:00:55 <rdrop-exit> I consider error handling the hardest, UI second
00:01:41 --- join: mtsd joined #forth
00:02:15 <rdrop-exit> I avoided curses, just used a subset of ECMA-48 directly
00:03:04 <rdrop-exit> The problem with any terminal compatible UI is the lack of key-press/key-release events
00:04:35 <rdrop-exit> this is why I'm planning on switching out the ECMA-48 stuff with x11, not to convert the UI to GUI, just to get the keyboard events
00:06:42 <rdrop-exit> curses is completely avoidable, only a handfull of terminal escape codes are actually necessary
00:07:16 <rdrop-exit> but the lack of key release events is really constraining
00:12:31 <rdrop-exit> The only terminal escape sequences I currently use are CUP, RIS, GRCM SET, SGR, DECSCUSR, DECTCEM, DECAWM
00:13:38 <rdrop-exit> that's really all you need for a portable TUI
00:16:27 <rdrop-exit> CUP puts the cursor where you want it
00:16:33 <rdrop-exit> RIS resets the terminal
00:17:38 <rdrop-exit> GRCM sets the rendition combination mode
00:17:52 <proteus-guy> rdrop-exit, error handling is not difficult at all - best solution is generally to fail fast and provide useful information about the failure. of course the UX aspect of error handling is the most difficult UX bit typically but, again, that's cause it's UX work.
00:18:34 <rdrop-exit> well you're assuming desktop software
00:18:48 <rdrop-exit> SGR sets the current rendition mode
00:18:50 <proteus-guy> I'm not familiar with ECMA-48. Is that actual a practical standard with common support?
00:19:02 <proteus-guy> I'm not assuming desktop software at all - quite the opposite.
00:19:18 <rdrop-exit> it's the latest version of ANSI codes
00:19:52 <proteus-guy> Ah yes - ANSI codes don't get you key presses, right? So not a fully useful terminal standard-  just a display standard.
00:20:38 <proteus-guy> curses will give you that.
00:20:50 <rdrop-exit> it's a combination of most of the common features of physical terminals
00:21:07 <rdrop-exit> don't need curses for that
00:21:51 <proteus-guy> rdrop-exit, let's make sure we're talking the same goals - you want real-time keypress interactivity (ala it's a terminal) or not (ala it's just a display)?
00:22:34 <rdrop-exit> a terminal doesn't give you separate key press & release events
00:23:14 <proteus-guy> well given my above differentiation it does - that was my point of consideration anyway. Which one are you looking for?
00:24:26 <rdrop-exit> terminals, as normally defined, don't send separate events for key presses and key releases
00:24:56 <proteus-guy> to be pedantic you're correct - but it ignores the point I was trying to make clear...
00:25:23 * proteus-guy is away for a bit...
00:25:59 <rdrop-exit> I'm not being pedantic, this is the reason why something like curses doesn't provide them, because the underlying terminals (real or emulated) don't provide them
00:32:01 <rdrop-exit> the core of curses is sending out and receiving terminal escape codes.
00:39:10 --- join: dys joined #forth
00:43:23 <rdrop-exit> If you want somewhat portable access to press/release events you need x11 or something similar.
00:50:05 <rdrop-exit> At least that's my understanding, if there's a simpler way I'd be happy to hear about it.
01:50:17 --- join: john_cephalopoda joined #forth
01:54:15 --- quit: john_cephalopoda (Remote host closed the connection)
01:54:29 --- join: john_cephalopoda joined #forth
02:07:21 --- join: iyzsong joined #forth
02:24:18 --- quit: mtsd (Ping timeout: 256 seconds)
02:53:01 --- join: mtsd joined #forth
03:07:55 --- quit: rdrop-exit (Quit: Lost terminal)
03:55:24 --- quit: proteus-guy (Ping timeout: 255 seconds)
03:58:25 --- join: dave0 joined #forth
04:14:41 --- quit: jsoft (Ping timeout: 258 seconds)
04:21:08 --- quit: iyzsong (Ping timeout: 240 seconds)
04:24:11 --- quit: mtsd (Ping timeout: 255 seconds)
04:31:25 --- join: mtsd joined #forth
05:42:09 --- quit: jedb (Remote host closed the connection)
05:42:29 --- join: jedb joined #forth
05:59:22 --- quit: mtsd (Quit: Leaving)
06:19:39 --- quit: jn__ (Ping timeout: 248 seconds)
06:23:05 --- join: jn__ joined #forth
07:28:50 --- quit: dave0 (Quit: dave's not here)
07:31:08 --- quit: tabemann (Ping timeout: 240 seconds)
08:17:00 --- join: proteus-guy joined #forth
08:25:53 --- join: dddddd joined #forth
09:28:08 --- quit: dys (Ping timeout: 240 seconds)
09:34:37 --- join: dys joined #forth
10:37:56 --- join: DKordic joined #forth
11:10:08 <DKordic> [Re: keyboard events] ""$ max xinput"", ""$ xinput --list --short"" (Keyboard id=11), ""$ xinput --list-props 11"" (Device Node: "/dev/input/event4"), ""$ hd -x /dev/input/event4"".  
11:11:25 <veltas> tpbsd: I had a good read of that article at work
11:11:52 <veltas> And now I have decided to do Direct Threaded Code
11:12:03 <veltas> And put my parameter stack in SP
11:12:12 <veltas> It was a good read
11:13:18 <DKordic> veltas: Why not Subroutine Threaded Code (STC)?  Would it not be straightforward?  
11:13:59 <veltas> Not much more, and it would take up more space
11:14:50 <DKordic> I don't think so :3 .  
11:15:38 <DKordic> Think again :3 .  
11:16:11 * DKordic . o O ( Art for the sake of Art...  )
11:23:57 <veltas> DKordic: Did you read the article?
11:24:03 <veltas> It says on Z80 it takes up more space
11:24:12 <veltas> Not that I need it to say so because I know how big a CALL is
11:27:13 <DKordic> Oh Z80...  
11:28:16 <veltas> Yes well typically when one implements a forth they have a target platform :P
11:29:19 <DKordic> Z80 in 2020 _AD_!?  
11:30:23 <patrickg> it's well known and battle hardened. that new 8086 family still need to prove that they're not just a fad ;-)
11:30:52 <veltas> Forth in 2020 AD etc
11:53:14 --- quit: dys (Ping timeout: 256 seconds)
12:49:53 <john_cephalopoda> Z80 is a pretty popular platform with many fans. There's the pretty recent RC2014 platform and the Z80-focused CollapseOS.
12:54:08 --- join: dys joined #forth
13:00:24 --- join: WickedShell joined #forth
13:23:48 <DKordic> Well You all deserve Windooze.  
13:27:54 --- quit: Lord_Nightmare (Read error: Connection reset by peer)
13:33:48 --- quit: gravicappa (Ping timeout: 240 seconds)
13:49:11 --- quit: john_cephalopoda (Quit: Leaving)
13:54:50 --- join: jfe joined #forth
13:55:01 <jfe> hi all
13:57:08 <DKordic> Greetings.  
13:58:10 <jfe> i've been reading "thinking forth" and i'm becoming interested in the forth language. i'm wondering what you all like about it?
13:59:10 <jfe> second, i'm wondering why forth has never seemed to gain acceptance in academia (unless it has and i'm just mistaken)?
14:01:58 <DKordic> jfe: ""I am a design chauvinist.  I believe that good design is magical and not to be lightly tinkered with.  The difference between a great design and a lousy one is in the meshing of the thousand details that either fit or don't, and the spirit of the passionate intellect that has tied them together, or tried.  That's why programming---or buying software---on the basis of "lists of features" is a doomed and misguided effort.  The
14:01:58 <DKordic> features can be thrown together, as in a garbage can, or carefully laid together and interwoven in elegant unification, as in APL, or the Forth language, or the game of chess.  "" -- Ted Nelson
14:02:36 <veltas> I have been learning Forth over the last few weeks and it is some of the most fun I've had with a programming language
14:02:54 <veltas> I still feel like I don't 'get it' but I am on the cusp of understanding it completely
14:04:09 <veltas> I think from a mathematical standpoint it is interesting for being so small, implementations are often a few KB and can come with an interpreter, editor, self-modifying language etc
14:04:53 <veltas> It means it is necessarily a highly *factored* language, and that also the language-building features themselves are also highly factored and hence available to you in a powerful fasion
14:05:31 <veltas> It is worth learning just by merit of how unconventional it is, if you think you know programming you should try Forth out to make sure
14:07:19 <jfe> i like that data is passed implicitly through the stack. i can imagine some debugging headaches but it also seems like it would save typing. in languages like C/C++, a lot of typing is spent storing the results of intermediate computations, which become arguments to functions, etc.
14:08:20 <veltas> I think there is something worth saying about how much detail is available in Forth that isn't made available in a language like C or C++
14:09:03 <veltas> Like when you use ." to output a string, when you compile that you are specifically compiling that text into your definition and you know where it is
14:09:37 <jfe> how many lines of code is a typical industrial-strength forth application?
14:09:57 <veltas> In C or C++ if you output a string literal the string goes 'somewhere', probably in your .text section, the compiler will try to fold it into another string if it can
14:10:08 <veltas> But in C or C++ that is a one of a kind feature
14:10:20 <veltas> In Forth that is syntax you can program yourself
14:12:25 <jfe> part of me wonders if nassim taleb's "intellectual yet idiot" argument captures the reason academia dislikes forth -- maybe it's too practical to be mathematically beautiful?
14:13:22 <jfe> but in industry it's practicality that matters, not mathematical beauty.
14:15:08 <veltas> Well look at what Forth has done maybe, I don't see much of it
14:15:18 <veltas> I want to try it for myself and see for myself if it has that kind of applicability
14:15:29 <veltas> But so far I've been learning it because it has a kind of attractiveness to me
14:17:41 <jfe> in a theoretical sense, forth seems like a really simple way to extend the alphabet of the underlying universal turing machine.
14:28:58 <remexre> jfe: wrt academia, there's been other concatenative languages (e.g. Joy) that academia likes slightly more
14:30:13 --- join: dave0 joined #forth
14:31:03 <remexre> there's also a nice category-theoretic connection, but I think most of the programming languages <-> category theory stuff has been lambda calculi and sequent calculi
14:33:41 <tpbsd> veltas, congratulations on your choice, it will be awesome to have another embedded Forth underway here, and we want to hear all about your development as it happens!
14:34:16 <tpbsd> jfe, I think Forth is unpopular because it's impossible to understand ;-)
14:34:52 <tpbsd> jfe, and that makes Forth impossible to sell in pretty shrink wrapped boxes like C
14:51:46 <DKordic> remexre: What do You mean about Category Theory?  
14:53:07 <remexre> DKordic: you can kinda-sorta turn your head and see words that only have stack effects as being morphisms, and concatenation of lists of words as being composition
14:54:02 <remexre> and I think in Joy you can treat its functions as exponentials in a cartesian closed category
14:55:30 <DKordic> I am not sure I am following.  I honestly prefer assembly explanation to that one.  
14:56:15 <DKordic> I meant to say, it is still not better than assembly definition.  
15:09:47 <veltas> tpbsd: thanks
15:30:55 <remexre> DKordic: er yeah, this isn't a useful description of Forth for understanding it; it might be useful for formally proving properties of Joy code, though
15:51:43 --- join: rdrop-exit joined #forth
16:13:12 --- join: X-Scale` joined #forth
16:14:58 --- quit: X-Scale (Ping timeout: 260 seconds)
16:14:58 --- nick: X-Scale` -> X-Scale
16:15:50 --- join: Lord_Nightmare joined #forth
16:19:29 --- join: X-Scale` joined #forth
16:20:06 --- quit: X-Scale (Ping timeout: 260 seconds)
16:20:12 --- nick: X-Scale` -> X-Scale
16:34:05 <siraben> remexre:  Do you know of any languages that combine concatenative programming with effects?
16:34:12 <siraben> Layered effects, that is.
16:35:26 <remexre> siraben: like e.g. Eff has?
16:35:33 <siraben> remexre:  Yes.
16:35:56 <remexre> siraben: no, sadly; I might try to do one some day, but that's pretty far down the TODO list
16:36:18 <siraben> remexre:  I see. What are your interests wrt. to programming languages?
16:36:54 <siraben> Interesting, you're on various FP channels as well.
16:37:05 <remexre> siraben: researcher in the field; mainly I do dependently-typed lambda calculi, but I'm massively preferring Forth to anything else low-level
16:37:35 <siraben> remexre: Re: CT, heh, if only one could treat Forth words as exponential objects.
16:38:09 <siraben> Ah, nice. Dependent types are really neat. I'm studying Coq myself.
16:38:49 <remexre> nice, I'm in a reading group going through Logical Foundations
16:38:53 <siraben> remexre: do you know of formalization efforts for languages like Forth?
16:39:22 <remexre> if I need to do a proof on a Forth program /today/, I'm probably more likely to do some sort of model-checking approach, or maybe something with symbolic execution?
16:39:30 <remexre> I don't know of any work in the field
16:39:57 <siraben> Ah. Yes, LF is a classic. I'm trying to read through Volume 2, Programming Language Foundations.
16:40:30 <siraben> remexre:  Have you read Algebra of Programming? That's another good book on program calculation.
16:42:04 <remexre> siraben: no,though I've seen the squiggol / bird-merteens stuff before
16:42:10 <remexre> havent' had a chance to go too deep in it
16:42:20 <remexre> I'll add it to our list of "books to read next," thx
16:42:58 <siraben> I'm currently reading it with an algebraist, it gets tricky to read starting with chapter 4 or so.
16:43:08 <siraben> Even though the book says "a first course in FP is assumed" in the beginning!
16:43:42 <remexre> oof, okay; we're trying to stay away from books that require too much math knowledge, in the interest of not scaring off undergrads
16:44:35 <siraben> Haha. I'm an undergraduate myself, and it can be intimidating. Of course it pays off well.
16:44:38 <remexre> gotta go; great talking to you! (should be back later tonight if there was smth else you wanted to discuss)
16:44:46 <siraben> I wonder how calculating Forth programs might look, haven't had a chance to explore much.
16:44:48 <siraben> cya
17:04:48 --- join: tabemann joined #forth
17:23:17 --- quit: jedb (Ping timeout: 265 seconds)
17:27:18 <tabemann> hey guys
17:27:35 <tpbsd> heyhey
17:27:44 <rdrop-exit> c[] good morning
17:28:18 <tabemann> I need to figure out how to make CREATE and <BUILD work
17:28:35 <tabemann> including in Flash
17:29:16 <rdrop-exit> isn't <BUILD fig-forth?
17:30:23 <rdrop-exit> <BUILDS
17:32:34 <tabemann> thanks for the correction
17:32:54 <tabemann> I'm using it because it fits how my forth works with flash better than CREATE
17:33:14 <tabemann> CREATE is only to be used for allocating arbitrary blocks of memory, together with ALLOT
17:34:56 <tabemann> screw it
17:35:05 <tabemann> I'm not going to define these in assembly
17:35:21 <tabemann> rather I'm going to force the user to upload routines for these
17:36:03 <tabemann> but I will provide support routines in assembly, such as that needed to implement DOES>
17:38:25 <rdrop-exit> If you have inlining then CREATE would lay down a header and a literal
17:39:26 <tpbsd> tabemann, why not build them with forth, you can always do it in assembly later if you want ?
17:39:41 <rdrop-exit> |header|lit|<addr>|ret|
17:39:44 <tabemann> tpbsd: that's what I'm gonna do
17:40:01 <tpbsd> thats gotta be one of the big advantages
17:40:03 <rdrop-exit> (assumes inlining)
17:40:27 <tpbsd> I tend to test my mods in Forth first, then do it in assembly later
17:40:46 <tabemann> this isn't going to be inlined, because it will require dynamically changing the code, but rather it will be written with the assembler routines built into zeptoforth
17:41:09 <tpbsd> frankzappaforth
17:42:13 <tpbsd> why do STM even bother calling their redacted, incomplete code snippets "examples" ?
17:42:23 <tpbsd> I think the summer interns must do them
17:43:22 <tpbsd> if STM had a example of a "automotive" it would just be a chassis with a engine, no wheels or drivetrain, no seats or steeringwheel
17:43:36 <rdrop-exit> just make sure you leave enough space to patch the code
17:44:18 <rdrop-exit> initial: |header|lit|addr|ret|<padding>
17:44:53 <tpbsd> rdrop-exit, is that dynamic patching ?
17:44:58 <rdrop-exit> patched:|header|call|<addr>|ret|<leftover>|
17:45:14 <rdrop-exit> that's what DOES> implies
17:45:23 <tabemann> like : create : current-here <offset> + <align> dup 0 literal, 0 bx, end-compile, current-here begin over over > while 0 current, 1 + repeat drop drop ;
17:45:38 * tpbsd brain explodes
17:45:50 <rdrop-exit> why do complicated?
17:46:02 <tpbsd> because it's easiest ?
17:46:10 <rdrop-exit> just patch with a call to the new code
17:46:33 <tabemann> because it needs to provide room for the code before the buffer, it needs to align the buffer to a word boundary, and it needs to write out the padding explicitly (in case it is writing to flash)
17:47:14 <tabemann> well wait
17:47:17 <tabemann> my code's wrong
17:47:52 <tabemann> : create : 6 push, current-here <offset> + <align> dup 6 literal, end-compile, current-here begin over over > while 0 current, 1 + repeat drop drop ;
17:47:53 <rdrop-exit> DOES> is a hack
17:49:22 <rdrop-exit> you're using combined code and data spaces?
17:49:37 <rdrop-exit> on the target?
17:49:42 <tabemann> yes
17:50:13 <tabemann> the main dichotomy on my forth is between RAM space and Flash space
17:50:29 <tabemann> and in RAM between system variables, dictionary space, data stack, and return stack
17:51:39 <rdrop-exit> ok then you need to calculate where the data will start in advance
17:51:57 <tabemann> system variables and return stack are allocated upon bootup, dictionary space and data stack grow at each other from opposite directions (with no real border between the two)
17:52:10 <rdrop-exit> if your literals are variable sized you have to take that into account too
17:52:31 <tabemann> my literals are variable sized
17:52:46 <tabemann> they can be 16, 32, or 64 bit (for 8 bit, 16 bit, or 32 bit literals)
17:53:47 <tabemann> but that's ignoring the code needed to push the current TOS onto the data stack
17:53:52 <tpbsd> tabemann, Mecrisp-Stellaris has a system.s that configures memory per target, also allowing error messages when ram and flash are running low
17:54:29 <rdrop-exit> in this case its an address literal so that limits which of those might apply
17:54:30 <tabemann> tpbsd: I have configurations for these things, but I haven't implemented checks for them yet
17:54:42 <tpbsd> cool
17:55:20 <tpbsd> tabemann, there is also a M4 Forth for Amforth
17:55:36 <rdrop-exit> |header|lit|addr|ret|padding|<data>
17:55:58 <tpbsd> it looks much reduced compared to Mecrisp-Stellaris and sadly the comments are also in German
17:56:15 <tabemann> mein Deutsch ist nicht so gut!
17:56:18 <tpbsd> tabemann, it also reuses some Mecrisp-Stellaris code and mentions that
17:56:28 <tpbsd> mine is non existant
17:56:47 <rdrop-exit> gesundheit
17:56:59 <tpbsd> matthias has helped the author with some cortex-m problems
17:57:40 <tabemann> know what, I'm gonna implement some things I need like said checks
17:57:49 <tabemann> I'm not gonna bother with CREATE or <BUILDS right now
17:58:22 <tabemann> because I can always build them in Forth were I to need them
17:58:44 <tpbsd> I dont blame you, they have to be among the most complex definitions ?
17:59:16 <tpbsd> CREATE or <BUILDS ... the jewel of Forth
17:59:29 <tpbsd> or was that CREATE or <DOES ?
17:59:47 <rdrop-exit> <BUILDS was used by Fig-Forth
17:59:51 <tabemann> <BUILDS and DOES>
18:00:28 <rdrop-exit> DOES> is pretty useless IMO
18:00:42 <rdrop-exit> it's a hack and leads to bad factoring
18:01:32 <tpbsd> says the Mecrisp-Stellaris dictionary .. create name 	( - - ) 	Create a definition with default action which cannot be changed later. Use <builds does> instead. Equivalent to : create <builds does> ;
18:02:40 <rdrop-exit> back to the future
18:02:41 <tabemann> I have thought of another way of doing CREATE - HERE <n> ALLOT CONSTANT FOO
18:03:16 <tabemann> this has the advantage that I don't have to figure out how big FOO will be in memory
18:03:20 <rdrop-exit> won't work
18:04:02 <rdrop-exit> I think ANS calls that BUFFER: IIRC
18:04:06 <tabemann> well, yes, it doesn't allow you to have arbitrarily sized buffers
18:04:56 <rdrop-exit> it won't allow you to do CREATE THINGIES 1 , 2 , 3 ,
18:06:59 <rdrop-exit> there also RESERVE
18:07:10 <rdrop-exit> * there's
18:07:23 <rdrop-exit> reserve ( # -- a )
18:08:35 <rdrop-exit> that's equivalent to your HERE <n> ALLOT
18:08:48 <tabemann> I actually implemened that, under that name!
18:09:19 <rdrop-exit> :)
18:11:38 <rdrop-exit> tpbsd, that's the first time I've seen <BUILDS since Fig-Forth
18:12:37 <rdrop-exit> it was removed in the 83 standard
18:12:46 <rdrop-exit> IIRC
18:14:58 <rdrop-exit> just checked, it was demoted to an "uncontrolled reference word"
18:15:27 <rdrop-exit> kinda cool to see it reappear
18:15:52 <tpbsd> Mecrisp-Stellaris is all about innovation ;-)
18:16:53 <rdrop-exit> I imagine he wanted to make does> less hacky by having a dedicated <builds
18:17:59 <tabemann> I don't see how you implement ANS CREATE in a system which writes to flash
18:18:09 <tpbsd> i remain mostly clueless about this area, it's my last mountain to climb
18:18:15 --- join: jedb joined #forth
18:18:52 <tpbsd> tabemann, the only things one can create in flash are arrays and constants in Mecrisp-Stellaris 
18:20:07 --- join: boru` joined #forth
18:20:11 --- quit: boru (Disconnected by services)
18:20:13 --- nick: boru` -> boru
18:21:11 <tpbsd> there is a interesting hack to create a uninitialized array from flash but then it cant be seen in the dictionary ...
18:22:17 <rdrop-exit> tabemann, focus on what is layed down
18:22:43 <rdrop-exit> |header|lit|<addr>|ret|<padding>|
18:22:56 <rdrop-exit> (assumes inlining)
18:23:30 <rdrop-exit> you need carnal knowledge to calculate the forward address, that's the only special thing about it
18:24:30 <rdrop-exit> (assuming your code and data spaces are combined)
18:29:21 <rdrop-exit> it's similar to how forward references are resolved in control flow words
18:30:05 <tpbsd> matthias has mentioned the difficulty in reserving space for unknown forward references
18:30:26 <tpbsd> it's why Mecrisp-Stellaris has the short conditional jump limitation
18:31:22 <rdrop-exit> if your address is 32 bits, you do a HERE, then you allot 4 bytes, then you comma the ret, then you align your dictionary to a cell boundary, then you resolve the forward reference
18:31:22 <tpbsd> he mainly didnt want to waste memory reserving it for long jumps when in many cases only short ones are needed
18:32:12 <tpbsd> i guess it was the 4 bytes compared to one
18:32:24 <tpbsd> he said thats not a issue with risc-v however
18:32:31 <rdrop-exit> tpbsd, that's an extra twist, but not hard to do
18:33:03 <tpbsd> rdrop-exit, I think that the workaround for the short conditional jump is to replace it with a branch for 32 bit range
18:33:07 <rdrop-exit> e.g. you start with 16-bit addresses, then eventually switch to wider ones
18:33:32 <tpbsd> as thumb conditional jumps have a very limited range
18:33:38 <rdrop-exit> (in the case of CREATE I mean)
18:34:24 <rdrop-exit> tpbsd, conditional jumps are a different problem, but also easy to handle
18:34:52 <tabemann> back
18:37:25 <rdrop-exit> my alternative to CREATE is a little more sophisticated as it can handle arbitrary alignments
18:39:10 <rdrop-exit> and variable sized lits
18:39:55 <tpbsd> rdrop-exit, matthias seemed to think it was a problem with cortex-m, but hes very fussy about resource wastage atc
18:40:00 <tpbsd> etc
18:40:01 <rdrop-exit> it switches from 16-bit address lits to 32-bit address lits as the dictionary grows
18:40:50 <rdrop-exit> so your early creates use shorter lits than your later ones
18:42:35 <rdrop-exit> tpbsd, the best way not to waste target resources is to go tethered ;-)
18:42:54 <rdrop-exit> but you know that already :)
18:50:41 <tpbsd> yeah, but I'm not a Forth writer
18:50:58 <tpbsd> we have a tethered one and it's very nice, just not cortex-m
18:51:15 <tpbsd> well the host is cortex-m, the target is MSP430
18:51:46 <tpbsd> lol, it's a Mecrisp-Stellaris tethered Forth but the target is not cortex-m
18:51:51 <rdrop-exit> I wonder why he didn't use a PC as the host
18:51:53 <tpbsd> bbl folks
18:52:04 <rdrop-exit> ciao tpbsd!
18:52:04 <tpbsd> jtag
18:52:22 <rdrop-exit> jtag?
18:52:33 <tpbsd> he should have used rdrop-exits method
18:53:01 <tpbsd> yeah, he used a arm cortex-m4 for as the host for it's jtag facilities
18:53:13 <tpbsd> jtag is the umbilical
18:53:13 <rdrop-exit> ah I see
18:53:20 <tpbsd> anyway, bbl :)
18:53:58 <tabemann> lol
18:54:20 <tabemann> I just write CREATE in Forth
18:54:29 <tabemann> it looks so much simplier in Forth than it did in assembly
18:54:33 <tabemann> *wrote
18:54:36 <rdrop-exit> cool
18:56:54 --- join: jsoft joined #forth
18:58:03 <tabemann> now I need to see if e4thcom as  mode that works with zeptoforth
18:58:22 <tabemann> i.e. no hardware flow control, ok as a line end, CRLF for newlines
18:59:03 <tabemann> okay, I'm gonna get kicked out of this coffee shop - they're closing
18:59:10 <tabemann> bbiab
18:59:15 <rdrop-exit> have fun
19:03:54 --- quit: tabemann (Ping timeout: 256 seconds)
19:27:34 --- join: tabemann joined #forth
19:41:08 --- quit: proteus-guy (Ping timeout: 240 seconds)
19:51:16 --- join: deesix_ joined #forth
19:51:48 --- join: dddddd_ joined #forth
19:54:22 --- quit: deesix (Ping timeout: 272 seconds)
19:54:34 --- quit: dddddd (Ping timeout: 265 seconds)
21:00:58 --- join: gravicappa joined #forth
21:21:25 --- quit: _whitelogger (Remote host closed the connection)
21:24:28 --- join: _whitelogger joined #forth
22:11:52 --- join: proteus-guy joined #forth
22:13:27 <tpbsd> nice, e4thcom!
22:20:10 --- quit: dave0 (Ping timeout: 268 seconds)
22:21:32 --- join: dave0 joined #forth
22:51:56 --- quit: WickedShell (Remote host closed the connection)
22:54:26 --- quit: dddddd_ (Ping timeout: 260 seconds)
22:56:42 --- quit: jpsamaroo (Ping timeout: 258 seconds)
23:55:21 --- quit: dys (Ping timeout: 258 seconds)
23:59:59 --- log: ended forth/20.03.02