00:00:00 --- log: started forth/19.03.06
00:25:25 <the_cuckoo> switched to the -1 for the results of the comparisons and redefined true accordingly - tripped some unit test failures which were explictly looking for 1 of course, but otherwise all fine
00:38:42 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
00:48:27 <rdrop-exit> Good move, -1 is a more useful flag value
00:49:27 <the_cuckoo> hmm - yeah - think i need to extend to the results of && and || as well
00:50:17 --- join: xek (~xek@user-94-254-224-236.play-internet.pl) joined #forth
00:50:52 <the_cuckoo> these are boolean tests as opposed to bit wise operators (which i have as & and | rather than 'and', 'or' - there's xor as ^ too of course)
00:52:47 <rdrop-exit> That's one advantage of -1, no need for two versions of the boolean operators
00:53:26 <rdrop-exit> Just the bitwise ones
00:55:23 <the_cuckoo> yeah - was considering that too - just dropping them
00:55:45 <rdrop-exit> I have all 16 two-argument bitwise operators, plus all 4 single-argument ones
00:58:14 <rdrop-exit> correction 3 single argument ones, and the comparisons with 0, i.e. 0=, 0<>, etc...
01:01:20 <rdrop-exit> * 16 bitwise boolean operators that is
01:05:47 <rdrop-exit> https://www.reddit.com/r/Forth/comments/957i86/fun_with_circular_stacks/
01:06:35 <the_cuckoo> sure - but in the c++ world, any non-zero numeric is true - hence 1 && 2 is true - while 1 & 2 would be 0 
01:09:44 <the_cuckoo> and, yes, throwing in the 0= or 0<> isn't a huge ordeal, but it's jarring when moving from the internal language to the external iyswim
01:10:50 <the_cuckoo> if i keep the bool specifics and just negate the result, i cover the cases and the operators behave identically in both 
01:11:07 <rdrop-exit> Just think of a cell as an array of truth values
01:11:18 <the_cuckoo> yeah
01:11:48 <WilhelmVonWeiner> KipIngram: his forth works far differently
01:12:29 <the_cuckoo> true enough :)
01:12:29 <WilhelmVonWeiner> [ ] create a anonymous definition
01:12:40 <rdrop-exit> Or better yet forget "truth values" and think of bits :)
01:13:38 <the_cuckoo> sure - i have no issue with it :) - i'm just thinking of others - there's no real hardship on my side to carry both bools and bits
01:13:40 <WilhelmVonWeiner> : dip >r execute r> ; basically
01:18:53 <the_cuckoo> am going for the hybrid - both can coexist without issue and it should be clear to the user which one is being used in any given situation (any c/c++ coder will know the difference between & and && after all)
01:21:05 <the_cuckoo> also, if i use names (and, or etc) it becomes less clear what it's doing 
01:22:03 <rdrop-exit> Any coder should be right at home with bits, even C++ programmers :)
01:22:13 <the_cuckoo> :)
01:23:09 <the_cuckoo> i don't disagree, and they have them with this approach
01:35:15 --- join: gravicappa (~gravicapp@h109-187-217-49.dyn.bashtel.ru) joined #forth
01:36:23 --- join: dddddd_ (~dddddd@unaffiliated/dddddd) joined #forth
01:36:59 --- quit: dddddd (Ping timeout: 252 seconds)
01:37:24 --- nick: dddddd_ -> dddddd
01:40:26 <the_cuckoo> hmm - there is one other disadvantage with this approach - when the library is expanded (like i do in rpany-comms and vml-batch), then every word which places bools on the data stack should always them as negative - i don't think there's a simple/safe way for me to enforce it in the core
01:40:50 <the_cuckoo> *always add
01:41:47 <the_cuckoo> if they don't, well, it won't affect the && use, but bit wise stuff will fail
01:43:04 <the_cuckoo> hmm
01:48:18 <`presiden> trying out https://ghidra-sre.org/
01:49:06 <`presiden> on my forth implementation
01:49:20 <`presiden> looks good so far
01:50:14 <`presiden> now figuring out how to make it recognize forth dictionary
01:50:21 <the_cuckoo> what's a 'bat' file? :p
01:50:23 <WilhelmVonWeiner> that's the nsa competitor to IDA right?
01:51:31 <the_cuckoo> ah - it has both bash and bat
02:02:25 <`presiden> yeah, it's IDA competitor
02:02:38 <`presiden> tho, I never use IDA
02:03:37 <`presiden> hm... the doc says it support dynamic data type
02:03:56 <WilhelmVonWeiner> IDA is proprietary so no ta
02:04:20 --- quit: ashirase (Ping timeout: 252 seconds)
02:05:19 <`presiden> > Dynamic data types adapt to the underlying bytes to which they are applied.  These data types can only be created by writing a new Java class.
02:05:32 <`presiden> ah, so you need to write a class first then
02:12:38 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth
02:47:26 <the_cuckoo> hmm - it's kinda funny i guess - c++ doesn't provide a boolean xor (which i guess should be be ^^ to mirror the ^ bit wise operator) - guess i could add one in mine - would be something like ( b1 || b2 ) && !( b1 && b2 ) in infix notation i guess?
02:48:16 <the_cuckoo> never really thought about it, but it's awkward to construct in c/c++
02:48:28 <corecode> you can't ^?
02:51:02 <corecode> bool operator ^(bool a, bool b){return (bool)((int)!!a ^ (int)!!b);}
02:51:02 <the_cuckoo> well, with with bools in the language - strictly speaking, yes, but it would break if you don't first coerce to a boolean first
02:52:55 <the_cuckoo> as in a = 1, b = 2 - if ( a && b ) is fine - but clearly not the same as a & b - it follows that if ( a ^ b ) isn't what you want, but if ( bool( a ) ^ bool( b ) ) is probably fine
02:53:31 <corecode> ah yea then just use !!a ^ !!b
02:53:38 <corecode> !! is the bool operator
02:53:45 <the_cuckoo> ah - yeah - cleaner - thanks :)
02:58:15 <the_cuckoo> in my case, the ^^ would actually pull and coerce the top two items to bools anyway (ie: a = s.pull< bool >( ), b = s.pull< bool >( ) in which case i believe i get 0 or 1 for both, regardless of whether the stack contained ints, doubles or whatever - hence, s += a ^ b is probably all i need - if the object can't be coerced to a bool, it throws while pulling and stops)
02:59:03 --- quit: xek (Read error: Connection reset by peer)
02:59:11 --- join: xek_ (~xek@user-94-254-224-236.play-internet.pl) joined #forth
02:59:20 <the_cuckoo> and to honour the negative - s += - ( a ^ b ) is probably fine
02:59:50 <rdrop-exit> !a^!b
03:00:01 <corecode> yes rdrop-exit is right
03:00:08 <the_cuckoo> yes indeed 
03:00:09 <corecode> but confusing :)
03:00:14 <the_cuckoo> :)
03:00:25 <rdrop-exit> :)
03:03:19 <dave0> the_cuckoo: the objection to ^^ in c is that it doesn't short-circuit like && or ||
03:03:33 <the_cuckoo> ah - yes
03:03:36 <corecode> aha
03:03:39 <the_cuckoo> good point :)
03:04:18 <rdrop-exit> correctamundo
03:04:23 <dave0> this is dennis ritchie talking about it: https://yarchive.net/comp/logical_xor.html
03:05:08 <rdrop-exit> The C boolean operators are true boolean operations
03:05:56 <the_cuckoo> dave0: yeah - good link - appreciated
03:06:10 <rdrop-exit> They're control-flow
03:11:58 <rdrop-exit> I prefer the Forth approach
03:12:48 <the_cuckoo> but it's a little more work to do the short cirtcuit thing i guess
03:13:53 <the_cuckoo> ie: <something> <something-else> || would always evaluate both 'somethings'
03:15:53 <the_cuckoo> and sure, making something-else conditional itself and removing the || works, but it's not quite the same in terms of brevity
03:16:02 <rdrop-exit> If those somethings are already on the stack they need to be consumed anyway
03:16:14 <the_cuckoo> yup
03:16:39 <rdrop-exit> If there's a lot of work involved in generating those somethings then I would do an early exit.
03:17:00 <rdrop-exit> (i.e. deal with one at a time).
03:17:13 <rdrop-exit> * with them one
03:17:47 <the_cuckoo> yeah - all doable - but when you have a few conditions to check, the syntactical sugar that c/c++ provides is quite nice
03:19:11 <rdrop-exit> You can always add syntactical sugar if you really want it, be careful you don't get diabetes
03:19:45 <the_cuckoo> pros and cons to all such approaches anyway - mostly it's about people understanding the constructs and implications of the use of && and || - and i quite frequently run into experienced developers who will question the construct when presented with it 
03:20:23 <the_cuckoo> so, yeah - it's definitely possible to over sugar stuff :)
03:21:43 <rdrop-exit> C makes it appear like a boolean combination when it's not, too much sugar IMO
03:22:06 <the_cuckoo> still convenient though :)
03:24:12 <rdrop-exit> Yes it can be
03:28:40 <KipIngram> Conditional exit works great for that sort thing.  If I need several things to be true before I do foo, then I factor the whole thing into a word and say 
03:29:01 <KipIngram> ..A.. 0=; ..B.. 0=;  ..C.. 0=; foo ;
03:29:45 <KipIngram> Obviously put the things in decreasing order of "likely to fail."
03:32:08 <rdrop-exit> I do the same thing (using "0;"), it's the || case that's more verbose
03:33:30 <KipIngram> Oh, um, let me see.
03:34:12 <KipIngram> : (test) ..A.. 0<>; ..B.. 0<>; ..C.. 0<>; ;;
03:34:20 <KipIngram> : test (test) foo ;
03:34:42 <KipIngram> Any success returns to test to do foo - if they all fail you return double to test's caller.
03:35:16 <KipIngram> So yes - more verbose, but not by a whole lot.
03:38:51 <rdrop-exit> Yes, same here except the names
03:40:38 <rdrop-exit> : (test) ... ?; ... ?; ... 0bail; ;
03:40:40 <KipIngram> I think I may have a couple of places in my system where booleans are &&'d or ||'d, because I needed to make a traditional word work the way it was supposed to.
03:40:55 <KipIngram> For the most part, though, I do those things above and do almost no && or ||.
03:42:01 <rdrop-exit> I handle most early exit situations with either "?;" "0;" or "if ... then;"
03:44:53 * siraben uploaded an image: screenshot.png (263KB) < https://matrix.org/_matrix/media/v1/download/matrix.org/GklyuElbKgjJIiWzRfAUINKk >
03:44:55 <siraben> Added number reading to R216 Forth
03:46:00 <rdrop-exit> kudos
03:47:00 <siraben> thanks
03:47:19 <siraben> See those pixels on the red area? That's the memory, each cell is 16 bits
03:47:25 <KipIngram> Nice siraben.
03:47:43 <siraben> This Forth barely occupies 1/3 of the memory and can do a lot
03:47:53 <siraben> Thank you KipIngram .
03:48:53 <KipIngram> rdrop-exit: Me too; far and away most of mine are 0=; or 0<>;
03:49:06 <siraben> Huge kudos to the guy who made it too, it's amazing what you can do with quirks in a powder simulation game
03:49:10 <siraben> made the computer*
03:49:30 <KipIngram> A few places I use =; and so on, and with all three of those I might use the variant that retains an argument ( .0=; .0<>; .=; )
03:50:08 <siraben> It was previously impossible to get a computational device to perform 1 op/frame but around two or three years ago someone discovered this unexpected property
03:50:18 <rdrop-exit> Me too, "if .. then;" is mainly for "if ... else ... then" situations
03:50:18 <KipIngram> .0=; and .0<>; are faster primitives than 0=; and 0<>; since they don't have to pop the stack.
03:50:22 <rdrop-exit> e.g.
03:50:28 <rdrop-exit> b
03:50:29 <rdrop-exit> c -row        Console pane cursor up one row.
03:50:29 <rdrop-exit> d
03:50:39 <rdrop-exit> 8
03:50:40 <rdrop-exit> 9 : -row ( -- )
03:50:41 <rdrop-exit> a   top-row? if  -scroll  then;  b/row console# -! ; compiled
03:50:52 <rdrop-exit> b
03:51:04 <KipIngram> I think I'd do that as 
03:51:29 <KipIngram> : -row  ( --)  top-row? 0<>; -scroll ;
03:51:56 <KipIngram> Oh wait.
03:51:59 <KipIngram> stuff comes after.
03:51:59 <rdrop-exit> You're missing the else part
03:52:02 <KipIngram> Sorry.
03:52:05 <rdrop-exit> np
03:52:44 <KipIngram> Ok, so then I'd do
03:53:10 <rdrop-exit> drumroll...
03:53:39 <KipIngram> :-)
03:53:45 <KipIngram> I'm looking at it a minute.
03:53:51 <rdrop-exit> :)
03:54:08 <KipIngram> : (-row)  top-row? 0<>; scroll ;;
03:54:25 <KipIngram> : -row  (-row) b/row console# -! ;
03:54:34 --- quit: xek_ (Ping timeout: 255 seconds)
03:55:17 <rdrop-exit> That'll work too, slightly slower probably
03:55:36 <KipIngram> I guess it has an extra call/return in it.
03:55:47 <rdrop-exit> (not that it matters in this case)
03:59:02 <KipIngram> I can do your then; as well - I write it as ;, then
03:59:53 <rdrop-exit> Mines like this:
03:59:54 <rdrop-exit> 9
03:59:55 <rdrop-exit> a then; Resolve a pending forward reference and compile an |exit|.
03:59:55 <rdrop-exit> b
03:59:58 <KipIngram> But I think I get precisely the same code - then; just compiles (;) and finishes the if, right?
04:00:11 <rdrop-exit> 7
04:00:11 <rdrop-exit> 8 : then; { a -- }( -- )( r: a -- ) & exit resolve ; directive
04:00:11 <rdrop-exit> 9
04:00:32 <KipIngram> Oh, fancy...  :-)
04:01:01 <rdrop-exit> The exit can do tail call elimination
04:01:12 <KipIngram> Yes, my ;, does that.
04:01:30 <KipIngram> In fact, ; just invokes ;, at compile time; ;, does all the real work.
04:01:34 <rdrop-exit> So pretty much equivalent, matter of personal taste
04:02:00 <KipIngram> : ;  POSTPONE ;, POSTPONE [ [ ; IMMEDIATE
04:02:05 <KipIngram> if I recall correctly.
04:02:15 <KipIngram> Is "directive" different from "immediate"?
04:02:50 <rdrop-exit> It also makes the word a compilation only word.
04:03:02 <KipIngram> Aha.  Nice.
04:03:34 --- quit: nighty- (Quit: Disappears in a puff of smoke)
04:03:34 <rdrop-exit> 1
04:03:34 <rdrop-exit> 2 directive  Set the precedence flag and reset the
04:03:34 <rdrop-exit> 3            interpretation flag of the last word.
04:03:35 <KipIngram> Oh, I do like that.
04:03:45 <rdrop-exit> 1
04:03:46 <rdrop-exit> 2 : directive ( -- ) immediate compiled ;
04:03:46 <rdrop-exit> 3
04:03:53 <KipIngram> I have always done that the much uglier way of having STATE @ tests in the definition.
04:03:57 <KipIngram> Very slick.
04:04:02 <rdrop-exit> Thanks
04:05:21 <rdrop-exit> a
04:05:21 <rdrop-exit> b : compiled    ( -- ) interpretation last @ -flags ;
04:05:22 <rdrop-exit> c : interpreted ( -- ) compilation    last @ -flags ;
04:05:22 <rdrop-exit> d : immediate   ( -- ) precedence     last @ +flags ;
04:05:22 <rdrop-exit> e
04:06:08 <rdrop-exit> 2 precedence     Indicates if the entry is immediate.
04:06:08 <rdrop-exit> 3 compilation    Indicates the entry has compilation behaviour.
04:06:08 <rdrop-exit> 4 interpretation Indicates the entry has interpretation behavior.
04:06:14 <KipIngram> Yes.  I have plenty of room for those flags - I'd just never thought to have them.
04:06:40 <the_cuckoo> the 0; stuff is new on me - like it though
04:06:47 <KipIngram> I allocate the flag space and then never got around to considering ways of using htem.
04:06:49 <KipIngram> them
04:06:58 <rdrop-exit> It enabled me to factor the interpreter and compiler into their own words
04:07:03 <KipIngram> the_cuckoo I love that stuff - it has changed the way I code.
04:07:26 <the_cuckoo> yeah - it's pretty :)
04:07:45 <rdrop-exit> brb
04:08:29 <KipIngram> the_cuckoo: the other "unusual" thing I have in mine is what I refer to as the ME word group.
04:08:54 <KipIngram> ME is an immediate word - it compiles an unconditional jump tot he latest definition in the dictionary (which of course is the word you're compiling).
04:08:59 <KipIngram> So it loops back to the start.
04:09:19 <KipIngram> But I also have conditional variants of it such as 0=ME 0<>ME and so on.
04:09:26 <the_cuckoo> ah - yeah - makes sense
04:09:45 <rdrop-exit> I do the same thing, the address is called MYSELF and the jump is layed down by RECUR
04:09:47 <KipIngram> And I can put : <name> in the middle of words because I have my headers separate from my definitions.
04:09:59 <KipIngram> That creates a new "latest name" to be the target of the ME words.
04:10:24 <KipIngram> So with those and the conditional returns, I can create just about any construct without using IF ... THEN, BEGIN ... AGAIN, and so on.
04:10:58 <KipIngram> I thought about SELF instead of ME, but ME is shorter.
04:11:33 <rdrop-exit> I explain the header flags in a reddit post if you're interest, some of the names have changed, but the principals are the same
04:11:39 <KipIngram> The honest truth is I haven't even put all those constructs in my system yet (IF THEN, BEGIN AGAIN, etc.)  I've just found that I haven't needed them.
04:11:46 <rdrop-exit> https://www.reddit.com/r/Forth/comments/9izdtq/a_simple_approach_to_dual_words/
04:12:03 <KipIngram> Thank you - I am going to look into that; it would make a number of definitions much cleaner.
04:12:18 <rdrop-exit> Cool
04:12:32 <KipIngram> I might go backa and change my assembly, or I might wait until I work on meta-compiling, but it's a win.
04:13:16 <rdrop-exit> Gotta run, some unexpected guests just arrived. Ciao
04:13:26 <KipIngram> Oh, have fun.
04:13:27 --- quit: rdrop-exit (Quit: Lost terminal)
04:13:54 <the_cuckoo> ah - was reading his article there :) - looked good i think
04:17:26 --- join: nighty- (~nighty@b157153.ppp.asahi-net.or.jp) joined #forth
04:23:52 <the_cuckoo> > 0 0 ^^ , space 1 0 ^^ , space 0 1 ^^ , space 1 1 ^^ .
04:23:55 <the_cuckoo> 0 -1 -1 0
04:23:57 <the_cuckoo> > 2 1 ^^ , space 2 0 ^^ , space 0 2 ^^ , space 2 2 ^^ , space 2 1 ^^ .
04:23:59 <the_cuckoo> 0 -1 -1 0 0
04:24:08 <the_cuckoo> think that seems right to me anyway
04:25:21 <crc> KipIngram: as WilhelmVonWeiner said, [ ] in retro make a nestable, anonymous function. In the assembly versions, the as{ }as act similarly to [ ] in traditional Forth
04:25:54 <the_cuckoo> and i had it right - it s += - ( a ^ b ) where a and b are pulled from the stack as s.pull< bool >( )
04:26:12 <KipIngram> Oh yes - I remember that now.
04:26:14 <KipIngram> Thanks.
04:26:16 <crc> : mux ( x1 x2 mask -- x )  tuck and >r swap not and r> or ;
04:26:25 <KipIngram> Yes, I get it now.
04:26:44 <KipIngram> It really made no sense trying to interpret those as the usual Forth [ and ].
04:28:05 <siraben> Does anyone know what chip this is?
04:28:05 <siraben> https://rounded.com/images/detailed/120/krups-power-board-gsm-0300-114-ms-5945308.png
04:35:22 <KipIngram> Which one?
04:36:00 <KipIngram> Oh, never mind.
04:36:03 <corecode> stm32
04:36:09 <KipIngram> One thing I thought was a chip I don't think is.
04:36:28 <corecode> or something like it
04:36:33 <corecode> picture is too low res
04:37:04 <KipIngram> Try this:
04:37:06 <KipIngram> http://chipmanuals.com/datasheets/search/go/
04:37:17 <KipIngram> Oh wait.
04:37:23 <KipIngram> That's a generic entry.  Damn it.
04:37:28 <crc> siraben: http://elcodis.com/parts/1291139/ST72F324BJ6T6.html#datasheet
04:37:57 <corecode> https://www.st.com/content/ccc/resource/technical/document/datasheet/a3/ff/ee/cf/95/f6/4a/90/CD00158271.pdf/files/CD00158271.pdf/jcr:content/translations/en.CD00158271.pdf
04:38:55 <corecode> maybe the question is about a different chip
04:39:00 <corecode> because that one is clearly labeled
04:39:06 <KipIngram> https://www.st.com/content/ccc/resource/technical/document/datasheet/a3/ff/ee/cf/95/f6/4a/90/CD00158271.pdf/files/CD00158271.pdf/jcr:content/translations/en.CD00158271.pdf
04:39:19 <KipIngram> Ah, you beat me.
04:39:28 <corecode> pro :)
04:39:41 <KipIngram> I was fighting for a couple of minutes with one of those damn "data sheet archives" that doesn't really make it very easy to find the actual pdf.
04:39:48 <corecode> yea never use those
04:39:50 <KipIngram> Finally gave up on that and went to Digikey.
04:40:00 <corecode> octopart is the only one that works well
04:40:28 <siraben> Interesting.
04:40:42 <siraben> Thanks a lot crc , KipIngram 
04:40:51 <corecode> :(
04:40:52 <siraben> and corecode 
04:40:56 <corecode> :)
04:41:04 <siraben> haha
04:41:10 <corecode> what are you up to?
04:41:20 <siraben> Can't find any assembly examples except for that in the last few pages of the PDF
04:41:33 <siraben> I was trying to see what chip my parent's coffee machine used
04:41:34 <corecode> ah you want to write your own firmware?
04:42:03 <corecode> we have a cheap nespresso-alike, it has an attiny85 in it :)
04:42:29 <siraben> Would be interesting to see if I could get the assembly code and modify it
04:42:41 <corecode> almost certainly firmware protection
04:42:52 <siraben> There's an annoyance with the machine, we disconnect from power most of the time but when we need it it asks for the current date and time.
04:42:55 <corecode> so you would have to bulk erase and write your own
04:43:03 <corecode> aha
04:43:07 <siraben> Have you modified firmware before?
04:43:20 <corecode> i develop firmware professionally
04:43:26 <corecode> and i've modified binaries before
04:43:27 <siraben> I might try a low-risk device first since this is a little costly for a machine
04:43:32 <siraben> Ah I see.
04:43:48 <corecode> i think the solution would be to add a battery
04:43:49 <corecode> sec
04:46:33 <corecode> so it doesn't have a dedicated rtc backup
04:46:59 <corecode> do you know whether it is normal that it asks for the time?
04:47:12 <corecode> or is this something that only developed after a while
04:47:33 <crc> siraben: https://www.st.com/content/ccc/resource/technical/document/user_manual/00/69/94/42/92/11/40/a4/CD00004536.pdf/files/CD00004536.pdf/jcr:content/translations/en.CD00004536.pdf has some details on assembly language for this
04:47:50 <KipIngram> siraben: the datasheet says it comes in a rom option - if that's the case it won't be modifiable.
04:48:52 <corecode> yea, it has an external eeprom
04:51:49 <siraben> Hm.
04:52:53 <corecode> i'd put it at 90% chance that you need to spend >100 hours to modify/recreate the firmware
04:53:05 <KipIngram> I guess which they chose to use would depend on their volume.  Though I don't even know for sure if the rom is cheaper - I didn't price check.  Another reason for the rom option might be for reliability; it said this is an automotive device.
04:53:31 <KipIngram> I presume the rom would have superior data retention performance.
04:53:34 <corecode> even if it isn't, most likely it has firmware protection
04:59:34 --- quit: dave0 (Quit: dave's not here)
05:11:53 <siraben> What sort of consumer product is hackable?
05:14:04 <KipIngram> Well, I'd think that A) it would have to use a flash memory for its code storage, and B) it would have to be viable to reprogram that flash.
05:14:31 <KipIngram> That seems kind of like an tautological answer, but I can't think of anything else that would be required.
05:14:49 <KipIngram> Some really interesting things have been done hacking alternate firmware for routers.
05:15:02 <KipIngram> You know, the relatively inexpensive consumer ones.
05:15:33 <KipIngram> There's a fairly well-known open-source project for one of those; I can't think of its name right now, though.
05:15:49 <KipIngram> That's interesting because you're on a cheap box that has network capability.
05:16:31 <KipIngram> OpenWrt.
05:17:30 <KipIngram> There's a whole list of router projects here:
05:17:32 <KipIngram> https://en.wikipedia.org/wiki/List_of_router_firmware_projects
05:23:58 <siraben> KipIngram:  calculators, of course!
05:24:10 <siraben> Certain models anyhow, like the TI-84+
05:24:25 <KipIngram> Yes indeed.  :-)
05:24:30 <siraben> Later models are still programmable but the signed OS cannot be changed due to 2048 RSA
05:24:44 <siraben> Someone factorized the 521 bit RSA key on the TI-84+
05:28:16 <siraben> Routers are worth a shot, because that space is still pretty proprietary and it's a critical device
05:35:18 --- join: pierpal (~pierpal@host161-197-dynamic.245-95-r.retail.telecomitalia.it) joined #forth
05:38:17 <KipIngram> Yes, I think that's exactly why it pulls so much interest.
06:40:46 <corecode> hm, my compiler needs two word lists
06:40:56 <corecode> at least for primitives
06:41:40 <`presiden> word lists? dictionary?
06:42:00 <corecode> yes
06:42:24 <`presiden> corecode, why two dictionary?
06:44:01 <corecode> because + is different for the compiler and the target
06:44:10 <corecode> it's a cross compiler
06:44:55 <corecode> or i have one, and have a compiler and target entry
06:46:56 <corecode> hm, + is a primitive, not an immediate
06:47:24 <corecode> i guess i could implement it as immediate?
07:16:53 --- quit: gravicappa (Ping timeout: 252 seconds)
07:17:46 --- join: gravicappa (~gravicapp@h37-122-112-168.dyn.bashtel.ru) joined #forth
07:21:18 --- quit: tabemann (Ping timeout: 246 seconds)
07:30:34 --- join: xek_ (~xek@user-94-254-224-236.play-internet.pl) joined #forth
07:33:12 --- join: xek__ (~xek@public-gprs401058.centertel.pl) joined #forth
07:33:16 --- quit: gravicappa (Ping timeout: 255 seconds)
07:35:35 --- quit: xek_ (Ping timeout: 252 seconds)
09:07:24 --- quit: pierpal (Quit: Poof)
09:07:44 --- join: pierpal (~pierpal@host161-197-dynamic.245-95-r.retail.telecomitalia.it) joined #forth
09:22:34 --- quit: Zarutian (Read error: Connection reset by peer)
09:23:18 --- join: Zarutian (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth
09:26:50 --- quit: pierpal (Quit: Poof)
09:27:11 --- join: pierpal (~pierpal@host161-197-dynamic.245-95-r.retail.telecomitalia.it) joined #forth
09:40:55 --- quit: nighty- (Quit: Disappears in a puff of smoke)
09:51:55 <siraben> Wow, Forth really is amazing.  It's been less than a week since I started R216 Forth and most of the work was in the first two or three days and it's more or less complete
09:52:14 <siraben> Or not, if I look at the standard. Hm.
09:52:37 <zy]x[yz> ignore the standard
09:54:24 <siraben> Yeah I don't look at it any more
10:04:20 <the_cuckoo> it's funny though - most people approaching a language will look to write stuff in the language... not write the language :)
10:10:05 <the_cuckoo> think i'll push my rpany-pi stuff to gitlab this evening - it's incomplete and untested (as the gpio pins i want to access are obscured by the 3d printed case i put on it and am somewhat reluctant to remove :)), but it covers the basics of the core wiring pi api
10:32:24 <crc> I've written a shell script (http://forth.works/c3e38d6893fe4d0a5483d4551789ded1) that can take a retro source file (e.g., http://forth.works/cacca889c001818c43c5cd97dd7059d3) and generate a glossary file of the words used in it (e.g., http://forth.works/d9af302587b6d8441d9b71a4897da5db).
10:36:42 --- quit: rprimus (Ping timeout: 244 seconds)
10:37:21 --- join: proteusguy (~proteusgu@49.230.15.231) joined #forth
10:37:21 --- mode: ChanServ set +v proteusguy
10:38:32 --- join: rprimus (~micro@unaffiliated/micro) joined #forth
11:11:26 --- quit: pierpal (Quit: Poof)
11:11:46 --- join: pierpal (~pierpal@host161-197-dynamic.245-95-r.retail.telecomitalia.it) joined #forth
11:20:32 --- quit: proteusguy (Ping timeout: 252 seconds)
11:27:32 <corecode> https://gist.github.com/935e31dc5656812657e7b572ea1cd689
11:27:39 <corecode> getting somewhere
11:38:16 --- join: proteusguy (~proteusgu@2600:1700:d930:1ae0:2ca4:a12:63fe:b6ae) joined #forth
11:38:16 --- mode: ChanServ set +v proteusguy
11:43:15 --- join: xek (~xek@user-94-254-224-236.play-internet.pl) joined #forth
11:45:13 --- quit: xek (Remote host closed the connection)
11:45:16 --- join: xek_ (~xek@user-94-254-224-236.play-internet.pl) joined #forth
11:45:50 --- quit: xek__ (Ping timeout: 252 seconds)
11:47:29 --- quit: proteusguy (Ping timeout: 252 seconds)
12:00:05 --- join: proteusguy (~proteusgu@2600:1700:d930:1ae0:2ca4:a12:63fe:b6ae) joined #forth
12:00:05 --- mode: ChanServ set +v proteusguy
12:06:20 --- join: mtsd (~mtsd@94-137-100-130.customers.ownit.se) joined #forth
12:40:05 <corecode> https://gist.github.com/f1e4ae278f500cdcfbbf7d6f7ab2b053
12:40:18 <corecode> now optimizing EXITs
12:42:28 <corecode> https://github.com/corecode/forth-cpu-compiler/blob/master/compiler.py#L298
12:42:34 <corecode> that's the forth source
12:46:59 <the_cuckoo> https://pastebin.com/FEndCk5p <- an example of use of rpany-pi
12:49:05 --- quit: proteusguy (Ping timeout: 252 seconds)
12:54:24 <corecode> wow you support do loop in interpret mode
12:55:55 <the_cuckoo> oh yeah
12:56:23 <the_cuckoo> when a parser closes there, it executes
12:56:29 <Zarutian> we hear so much about do loops lately but I wonder if they are done or not.
12:57:15 <corecode> i feel this is a joke
12:58:13 <Zarutian> corecode: did I throw you for a loop there?
12:59:47 <the_cuckoo> :)
13:00:25 <the_cuckoo> do it again
13:01:56 <Zarutian> on one condition I might
13:02:13 <corecode> so cmforth has FOR, not DO
13:03:56 --- quit: pierpal (Ping timeout: 252 seconds)
13:07:06 --- quit: mtsd (Quit: leaving)
13:32:12 --- join: dave0 (~dave0@223.072.dsl.syd.iprimus.net.au) joined #forth
13:32:56 <dave0> hi
13:43:49 <crc> Hi dave0
13:45:25 <dave0> hi crc 
14:15:34 --- quit: Zarutian (Ping timeout: 255 seconds)
14:18:16 --- join: Zarutian (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth
14:18:34 <the_cuckoo> https://gitlab.com/lilo_booter/rpany-pi/blob/master/README.md <- first draft
14:19:27 --- join: proteusguy (~proteusgu@2600:1700:d930:1ae0:59e6:bf5a:2b52:6a8e) joined #forth
14:19:27 --- mode: ChanServ set +v proteusguy
14:24:52 <corecode> i guess i should implement constant
14:30:50 --- quit: proteusguy (Ping timeout: 252 seconds)
14:43:51 --- join: proteusguy (~proteusgu@49.229.39.165) joined #forth
14:43:51 --- mode: ChanServ set +v proteusguy
14:45:46 <zy]x[yz> implement constantinople
14:57:10 --- quit: proteusguy (Ping timeout: 240 seconds)
15:12:50 --- join: proteusguy (~proteusgu@162-235-152-188.lightspeed.milwwi.sbcglobal.net) joined #forth
15:12:50 --- mode: ChanServ set +v proteusguy
15:12:53 --- join: pierpal (~pierpal@host161-197-dynamic.245-95-r.retail.telecomitalia.it) joined #forth
15:17:13 --- quit: pierpal (Ping timeout: 255 seconds)
16:30:49 --- join: pierpal (~pierpal@host161-197-dynamic.245-95-r.retail.telecomitalia.it) joined #forth
16:48:20 --- quit: john_cephalopoda (Ping timeout: 252 seconds)
16:59:08 --- join: xek__ (~xek@user-5-173-144-62.play-internet.pl) joined #forth
17:01:32 --- quit: xek_ (Ping timeout: 252 seconds)
17:02:10 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth
17:05:06 --- join: xek_ (~xek@user-5-173-152-127.play-internet.pl) joined #forth
17:07:55 --- quit: xek__ (Ping timeout: 255 seconds)
17:15:28 --- join: tabemann (~travisb@rrcs-162-155-170-75.central.biz.rr.com) joined #forth
17:41:08 --- join: xek__ (~xek@user-5-173-144-212.play-internet.pl) joined #forth
17:43:46 --- quit: xek_ (Ping timeout: 245 seconds)
17:44:10 --- join: xek_ (~xek@user-5-173-152-183.play-internet.pl) joined #forth
17:45:14 --- quit: cantstanya (Ping timeout: 256 seconds)
17:46:41 --- quit: xek__ (Ping timeout: 245 seconds)
17:47:51 --- join: cantstanya (~chatting@gateway/tor-sasl/cantstanya) joined #forth
17:48:08 --- join: xek__ (~xek@user-5-173-144-172.play-internet.pl) joined #forth
17:50:26 --- quit: xek_ (Ping timeout: 245 seconds)
17:55:06 --- join: xek_ (~xek@user-94-254-233-42.play-internet.pl) joined #forth
17:57:50 --- quit: xek__ (Ping timeout: 240 seconds)
17:58:08 --- join: xek__ (~xek@user-5-173-152-47.play-internet.pl) joined #forth
18:00:24 --- quit: xek_ (Ping timeout: 246 seconds)
18:02:36 --- join: xek_ (~xek@user-94-254-233-93.play-internet.pl) joined #forth
18:05:04 --- quit: xek__ (Ping timeout: 255 seconds)
18:16:03 --- quit: Keshl (Read error: Connection reset by peer)
18:16:38 --- join: Keshl (~Purple@207.44.70.214.res-cmts.gld.ptd.net) joined #forth
18:17:31 --- quit: tabemann (Ping timeout: 245 seconds)
18:19:19 --- join: nighty- (~nighty@b157153.ppp.asahi-net.or.jp) joined #forth
18:34:50 --- quit: `presiden (Ping timeout: 240 seconds)
19:04:20 --- quit: dddddd (Remote host closed the connection)
19:19:35 --- quit: dave0 (Quit: dave's not here)
19:36:32 --- join: rdrop-exit (~markwilli@112.201.168.172) joined #forth
20:03:17 --- quit: rdrop-exit (Quit: Lost terminal)
20:25:08 --- join: travisb (~travisb@172-13-49-137.lightspeed.milwwi.sbcglobal.net) joined #forth
20:26:15 --- quit: proteusguy (Ping timeout: 245 seconds)
20:26:55 --- quit: jn__ (*.net *.split)
20:26:55 --- quit: crc (*.net *.split)
20:26:55 --- quit: malyn (*.net *.split)
20:26:55 --- quit: Lord_Nightmare (*.net *.split)
20:28:34 --- nick: travisb -> tabemann
20:54:02 --- join: crc (~crc@li782-252.members.linode.com) joined #forth
20:54:02 --- join: jn__ (~nope@aftr-109-90-232-48.unity-media.net) joined #forth
20:54:02 --- join: malyn (~malyn@unaffiliated/malyn) joined #forth
20:54:02 --- join: Lord_Nightmare (Lord_Night@unaffiliated/lordnlptp) joined #forth
20:54:02 --- mode: livingstone.freenode.net set +v crc
20:59:20 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
21:01:29 --- quit: pareidolia (Ping timeout: 264 seconds)
21:02:30 --- quit: MrMobius (Ping timeout: 240 seconds)
21:02:30 --- nick: [1]MrMobius -> MrMobius
21:05:00 --- join: pareidolia (~pareidoli@87.213.124.143) joined #forth
21:20:13 --- join: gravicappa (~gravicapp@h37-122-113-40.dyn.bashtel.ru) joined #forth
21:36:03 <siraben> Programming on this in-game computer makes the Z80 look like a supercomputer
21:36:19 <siraben> I have a clock rate of around 130 Hz
21:53:07 --- quit: pierpal (Read error: Connection reset by peer)
22:09:41 <KipIngram> Hahahahahah...  That's kind of priceless.
22:21:31 <ttmrichter> If you have a REALLY CISC architecture that could be fine.
22:21:40 <ttmrichter> The human brain operates at about 30Hz after all...
22:21:51 <presiden> can confirm
22:23:42 --- quit: PoppaVic (Remote host closed the connection)
22:28:45 <KipIngram> I think there's a lot more going on than we think in the human brain.
22:28:56 <KipIngram> I suspect quantum stuff.
22:29:09 <KipIngram> Penrose has written a lot about that.
22:29:12 <KipIngram> Microtubules.
22:29:25 <KipIngram> Penrose and, uh... Stapp?
22:30:29 <KipIngram> Some folks will get vehemently riled up over talk like that, but I think we get rather arrogant at times over how much we think we know.
22:31:17 <KipIngram> Science doesn't even have a REAL explanation for how it is we're even aware of our own existence.
22:54:23 <siraben> Keep in mind the brain is highly parallel
22:54:34 <siraben> And clock-less
23:14:53 --- quit: nerfur (Ping timeout: 250 seconds)
23:26:00 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
23:26:43 --- join: nerfur (~nerfur@broadband-95-84-184-13.ip.moscow.rt.ru) joined #forth
23:28:45 --- quit: MrMobius (Ping timeout: 268 seconds)
23:28:46 --- nick: [1]MrMobius -> MrMobius
23:32:47 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
23:35:37 --- join: [2]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
23:36:07 --- quit: MrMobius (Ping timeout: 250 seconds)
23:37:56 --- join: MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
23:39:11 --- quit: [1]MrMobius (Ping timeout: 252 seconds)
23:40:51 --- quit: [2]MrMobius (Ping timeout: 245 seconds)
23:59:59 --- log: ended forth/19.03.06