00:00:00 --- log: started forth/21.06.06
00:43:44 --- join: Glider_IRC_ joined #forth
00:47:13 --- quit: Glider_IRC__ (Ping timeout: 260 seconds)
01:58:36 --- quit: Bogen85 (Remote host closed the connection)
02:43:20 <cbridge_> <neuro_sys> A separate stack per "type" sounds like an interesting idea.
02:45:58 <cbridge_> <neuro_sys> At least, say, for vector3 or matrix4 types.
02:55:09 <cbridge_> <siraben> remexre: you might be interested in attending BLAST 2021 https://math.nmsu.edu/blast-2021/
02:55:39 <cbridge_> <siraben> it's not PL theory but kind of related areas in the math world like universal algebra and lattices
03:49:28 --- join: rtdos joined #forth
03:49:28 --- join: proteanthread joined #forth
05:33:40 --- join: newuser|43 joined #forth
05:35:43 <newuser|43> As a new user I find it hard to put it all on stack - I use global variables. Is it bad code practice in forth? 
06:12:44 <cbridge_> <neuro_sys> I don't think it's bad practice. It's perfectly fine to use global variables like local variables (defined right above the word they're used).
06:14:11 --- quit: newuser|43 (Quit: Connection closed)
06:15:47 <cbridge_> <neuro_sys> On the other hand, if you limit the word to need at most 3 items on stack, utilize return stack, and expect arguments in reasonable order, there's little need to do stack juggling.
06:33:10 <cbridge_> <amirouche> what do you think about lbforth and xforth?
06:33:20 <cbridge_> <amirouche> https://github.com/larsbrinkhoff/xForth
06:51:54 <cbridge_> <lispmacs> amirouche: I'm always interested in another AVR Forth, but i see xForth has no resident compiler, and tethered operating is not yet implemented
06:53:31 <cbridge_> <lispmacs> for me, it is an essential requirement to have the full interact development experience while logged into the chip itself
06:54:30 <cbridge_> <lispmacs> I prefer a resident compiler, though I can see arguments for tethered compiling
06:56:07 <cbridge_> <lispmacs> I don't want to have to burn the whole chip again to compile in a new word
06:58:07 --- quit: cbridge_ (Remote host closed the connection)
06:58:20 --- join: cbridge_ joined #forth
07:00:20 <veltas> Is there some kind of web chat set up for this channel?
07:00:34 <veltas> Just notice people joining under 'newuser|xx'
08:02:23 --- quit: dsmcfarl (Ping timeout: 260 seconds)
08:04:02 --- join: dsmcfarl joined #forth
08:40:23 --- join: Bogen85 joined #forth
08:40:24 --- mode: ChanServ set +v Bogen85
08:47:07 --- join: crab joined #forth
08:52:23 --- join: mark4 joined #forth
08:52:55 --- mode: ChanServ set +o mark4
08:53:33 <mark4> fell asleep at 9pm last night, woke up at 11, couldnt get back to sleep till 5am
08:53:38 <Bogen85> heh
08:53:51 <mark4> just get my sleep schedule in sync with the rest of reality and this happens lol
08:54:11 <Bogen85> interesting, yesterday much discussion in here about Forth with a compile time type stack...
08:54:20 <Bogen85> sounds familiar :D
08:54:32 <mark4> yea i sort of saw that 
08:54:32 <Bogen85> as that is what I'm working on
08:54:45 <mark4> dont quite understand it but im sure those who were talking about it do :)
08:54:50 <mark4> yea
08:56:28 --- quit: crab (Ping timeout: 258 seconds)
08:56:53 --- quit: cbridge_ (Remote host closed the connection)
08:57:18 --- join: cbridge_ joined #forth
09:13:39 <cbridge_> <neuro_sys> mark4: Is x4 older than jonesforth?
09:14:32 <mark4> yes by a few years
09:14:42 <mark4> i started x4 in about 2000 ish
09:15:20 <mark4> i also think x4 sources are much cleaner than jonesforth
09:15:28 <mark4> i strive to make my code readable
09:15:38 <mark4> or else i cant read it lol
09:18:28 --- nick: ornxka -> ornxka2
09:19:01 --- nick: ornxka2 -> ornxka
09:19:07 --- nick: ornxka -> ornx
09:19:36 <cbridge_> <neuro_sys> Bogen85 is there anything I can read about compile time type stack?
09:19:48 --- nick: ornx -> ornxka
09:19:55 <veltas> I personally found x4 and x64 very readable, and sort of went in and diagnosed a portability bug in x64 when I tried it out, so that's encouraging to me
09:20:25 <veltas> x64 isn't 'done' right now as far as I know
09:20:33 <Bogen85> neuro_sys, it is work in progress for me, but I saw others discussing it here yesterday
09:21:18 <Bogen85> well, the interpreter stack, but "compiled" words won't lay down code that accesses that stack
09:21:51 <Bogen85> so a turnkey app won't have the type stack
09:50:51 <cbridge_> <KipIngram> mark4: My newer Forths are also much more readable than earlier ones.  The one I'm doing now and the one I did right before kind of reached a new level of "cleanness" in my opinion, with the newer one the better of the two.
09:51:14 <cbridge_> <KipIngram> If you spend a little time crafting assembler macros you can really get a clean way of expressing things.
09:51:31 <cbridge_> <KipIngram> I've got a set of macros that totally handle the dictionary structure for me.
09:52:33 <cbridge_> <KipIngram> And even though my  headers and bodies go into different memory regions, I can use section callouts in those macros so that I can WRITE header and body right by each other.
10:07:04 <mark4> kip yea one way of getting better code is to design it, write it, debug it, DELETE IT and start over :)
10:07:33 <mark4> once you have a fully working app delete 100% of the sources and start over :)
10:09:09 <Bogen85> in many work places you would fired for that
10:09:27 <mark4> right.  they dont want to pay you to do it twice
10:11:32 --- quit: cbridge_ (Remote host closed the connection)
10:11:33 <Bogen85> well, with modern agile devops it is not as bad as it use to be... you deliver minimum viable products, you have full TDD or BDD (Test or Behavioral drivel developement), you maintain a backlog. But you do also plan to start over on somethings if the "toil" gets to high.
10:11:42 --- join: cbridge_ joined #forth
10:12:44 <Bogen85> so needing to start over is not what it use to be. Often you decide up front to to scrap the initially MVP and start over based on what you learned. Where I work we have done that a few times in the past couple years.
10:13:09 <Bogen85> MVP == minimum viable product
10:14:07 <mark4> i would not recommend it for work projeccts but personal projects its fine. i dont do it very often myself, it depends on how bad the work im doing feels
10:15:36 <Bogen85> often cost of maintenance gets higher than what a rewrite would be, like I said, good development teams even in large companies understand that (like we do)
10:15:52 <Bogen85> (where I work)
10:16:10 <mark4> i have rarely seen that in the wild
10:19:31 --- quit: gravicappa (Ping timeout: 248 seconds)
10:30:46 <cbridge_> <KipIngram> I've started over with my Forth several times.
10:33:53 <cbridge_> <crc> the solution to this for work is to divide the program into a set of smaller ones that can be individually replaced :)
10:34:57 <cbridge_> <KipIngram> That works good if the pieces "fit together" gracefully.
10:35:27 <cbridge_> <crc> yes; it does require a lot of planning up front
10:35:39 <cbridge_> <KipIngram> That's the most valuable planning you can do.
10:36:35 <cbridge_> <KipIngram> If agile has any shortcomings, it's that an up front "architecturral planning  period" doesn't fit into it perfectly.  You can do it, but you do  not have a demonstrable version of your product after architectural planning.
10:36:50 --- quit: cbridge_ (Remote host closed the connection)
10:37:00 --- join: cbridge_ joined #forth
10:37:45 <cbridge_> <KipIngram> But I really don't believe you can just "start writing" a really compicated application and hope for it to come together as well as it could with suitable initial planning.
10:38:03 <cbridge_> <KipIngram> That's like believing in magic.
10:38:50 <cbridge_> <f-a> ↑
10:38:59 <cbridge_> <f-a> maybe for some subset of programs?
10:39:10 <cbridge_> <KipIngram> I'm also rather doubtful about having the whole team involved in architectural planning.  You can get the "too many chefs" problem, and people get butt hurt if their idea doesn't get adopted.
10:39:21 <cbridge_> <KipIngram> I think your two or three best people should do the planning.
10:40:00 <cbridge_> <KipIngram> And then they have an "oversight" function to fill during actual development.
10:40:25 <cbridge_> <KipIngram> But another facet of agile is that it seems to shun that sort of "leadership."
10:41:19 <Bogen85> not always, it depends on the org and if you have "cluefull" managers and directors, but yeah, that is not always the case
10:42:42 <Bogen85> if the teams are small enough, they are by nature, more "Agile"...
10:42:55 <cbridge_> <KipIngram> Yeah, I agree with that.
10:43:01 <Bogen85> it is big entrenched teams that become dinosaurs...
10:43:09 <cbridge_> <KipIngram> Small teams are just better.
10:43:12 <cbridge_> <KipIngram> Agreed.
10:44:30 <Bogen85> we have a lot of Java dinosaur teams where I work... there stuff is never innovative and just gets more bloated, complex, and unwieldy the more features they add...
10:44:45 <cbridge_> <KipIngram> Ugh.
10:45:11 <cbridge_> <KipIngram> There was a period of time a while back when Java became a lot more entrenched that it should have.
10:45:50 <Bogen85> but not in my immediate teams. in my team especially, none of use will do Java. No desire to, no need to...
10:46:05 <cbridge_> <KipIngram> Nothing wrong with it, and if you really really need an application that will run on almost any system it's a way to go.  But I once saw it chosen for a high performance system controller, where the company was going to shiop  not just the software but the hardware as well.
10:46:23 <cbridge_> <KipIngram> I.e., they controlled the server, completely.  Ultimate portability was just not required.
10:46:39 <Bogen85> everything is cloud cloud cloud nowadays... and cloud apps need to be small if you are going to scale
10:46:43 <cbridge_> <KipIngram> But the manager of that team "came of age" during the Java window.
10:47:15 <Bogen85> Java apps are never small, their footprint is 10 to 20 times other modern langugages
10:47:46 <cbridge_> <KipIngram> That seems backwards from how it should be.
10:47:51 <Bogen85> both in terms of app image size and memory consumption
10:48:05 <iv4nshm4k0v> ... Not that I've studied the question in any detail, but my impression re. Linux (which is to say, the kernel) development is that ideas get discussed, the best one is picked up to be implemented, then after a few years its flaws become obvious, but it takes months before work starts on something new.  I'd be curious to learn if there're approaches to solve / mitigate that.
10:48:10 <cbridge_> <KipIngram> You'd think that having a virtual machine that was fixed would lead to smaller applications (above and beyond the vm, I mean)
10:48:25 <Bogen85> most cloud stuff is Linux, thankfully.
10:48:48 <cbridge_> <KipIngram> Who picks "the best one"?
10:49:00 <cbridge_> <KipIngram> Hopefully the "best" people.
10:50:20 <Bogen85> Java should just die. While there are lots of things I don't like about Go or how it was designed, it is a far better fit for the cloud than Java.
10:50:39 <Bogen85> And you can compile it for any platform...
10:51:03 <cbridge_> <KipIngram> I don't know Go myself, but I have an acquaintance whose judgement I really trust who really thinks highly of it.
10:51:17 <cbridge_> <KipIngram> He was very impressed, and he's not an easy guy to impress.
10:51:41 <cbridge_> <KipIngram> Gotta figure if anyone could "design to fit the cloud" it would be Google, I guess.
10:53:05 <cbridge_> <KipIngram> I don't know if he's actually an acquaintance anymore.  A couple of months ago he confided a personal problem, or rather his concern about one, in me, and logged off that night planning to go react to it somehow.  Then for a month he showed no online activity at all - I considered the possibility that he'd gotten himself thrown in jail or something.
10:53:18 <Bogen85> yeah, well, any lean system that produces small binaries and has networking capabilites, and a rich default library and a growing ecosystem, is potentially a good fit for the "cloud"
10:53:20 <cbridge_> <KipIngram> He seems active on IRC again now, but hasn't said a word to me and hasn't responded to any messages.
10:53:38 <cbridge_> <KipIngram> Which, is actually sort of rude - I was very concerned about him and worried over him some.
10:53:44 <cbridge_> <KipIngram> But I guess if he's moving around on IRC he's fine.
10:54:02 <cbridge_> <KipIngram> I think he's just embarrassed at having told me the things he did that evening.
10:54:12 <Bogen85> yeah, that happens
10:56:24 <Bogen85> whats up with all this rain... not raining today yet though... wettest May/June that I can remember
10:57:11 <cbridge_> <KipIngram> Yeah, here too (Houston area).
10:57:30 <Bogen85> North Dallas area for me
10:57:53 <KipIngram> Ah, we've probably shared some of it, just a few hours / a day apart.
10:58:11 <Bogen85> yeah
12:43:45 --- join: Glider_IRC__ joined #forth
12:46:43 --- quit: Glider_IRC_ (Ping timeout: 248 seconds)
13:04:41 <cbridge_> <tabemann_> about Java and footprint... I wrote a simple program for work that relies on Hibernate, because it uses classes shared with a much larger application that uses Hibernate - guess how large it is
13:10:18 <cbridge_> <KipIngram> I couldn't even begin to guess.
13:11:23 --- quit: Kumool (Ping timeout: 258 seconds)
13:17:55 <cbridge_> <tabemann> it's 40-something megabytes
13:18:11 <cbridge_> <f-a> lol
13:18:14 <cbridge_> <tabemann> most of the source code fits in a single, not-very-long file
13:18:20 <cbridge_> <f-a> strong performance
13:18:36 <cbridge_> <tabemann> but because of all the dependencies required by Hibernate, it balloons out in size
13:19:31 <cbridge_> <crc> makes me glad I gave up on Java long ago
13:20:06 <cbridge_> <tabemann> unfortunately the big application I develop at work is a big pile of Java and JavaScript
13:21:03 <cbridge_> <tabemann> the thing is, of that simple program, it itself is far less complex than my Forth, zeptoforth, which in a "big" build fits in 256K, and that is a big build
13:23:03 --- quit: cbridge_ (Remote host closed the connection)
13:23:18 --- join: cbridge_ joined #forth
13:25:49 <cbridge_> <crc> I'm stuck using an application written in Java at work; it sucks. I've decompiled parts of it in the past to remind myself to stay away from Java as much as possible.
13:29:52 <cbridge_> <tabemann> the thing about the application I work on at work is that it is unmanageably complex, whether it is the Java parts or the JavaScript parts
13:30:12 <cbridge_> <tabemann> in addition to just being overly large
13:33:36 <cbridge_> <tabemann> and what it really does is pretty simple fundamentally, it's just all the extra stuff forced by in this customer's needs or that customer's needs which causes it to get overly complex
13:35:36 <veltas> Love it or hate it that's the kind of code that keeps most of us in business :P
13:40:47 <cbridge_> <tabemann> well I get a lot of shit about it at work, because I'll make a change in response to a ticket, and then someone will come back with that it broke something completely unrelated or that there is some other problem that is seemingly related that I didn't fix (because to me as programmer it was not within the scope of the ticket, but the testers don't think that way)
13:41:13 <cbridge_> <tabemann> oftentimes the things I "broke" were not broken by me at all
13:41:46 <cbridge_> <tabemann> but were already broken, but the testers, in their ignorance, like to glom things onto existing tickets just because they're too ignorant to know the difference
13:43:02 <cbridge_> <tabemann> what's also wonderful is when the designers at my work come up with sloppy requirements... and then the testers take them literally (and when I ask the designers to fix the requirements they don't bother)
13:45:02 --- quit: cbridge_ (Remote host closed the connection)
13:45:14 --- join: cbridge_ joined #forth
13:45:59 <cbridge_> <Zarutian_HTC> tabemann: example of such sloppy requirements?
13:47:10 <cbridge_> <tabemann> Zarutian_HTC, horrible copy-and-paste errors taken from one part of the application to a new part... where stuff got omitted, or stuff got inappropriate included, or things weren't changed accordingly
13:48:13 <cbridge_> <Zarutian_HTC> that kind of recycled copypasta
13:50:10 <cbridge_> <Zarutian_HTC> worked once with an requirement gatherer whose criteria were damn good but it made the customer or their end users feel like they been through probeing
13:51:01 <cbridge_> <tabemann> the main designer is annoying because he often acts like a tester, but he doesn't test by requirements but rather by he what he feels the customer would expect
13:51:32 <cbridge_> <tabemann> <tabemann> the main designer is annoying because he often acts like a tester, but he doesn't test by requirements but rather by he what he feels the customer would expect
13:52:22 <cbridge_> <tabemann> whereas I as a programmer obviously couldn't care less about what the customer expects, but rather I care about requirements and about issues brought up in tickets
13:52:50 <cbridge_> <tabemann> if the customer expects something to be a certain way, there should be a requirement for it
13:52:55 <cbridge_> <tabemann> I'm not psychic
13:54:55 --- quit: cbridge_ (Remote host closed the connection)
13:55:06 --- join: cbridge_ joined #forth
14:06:18 <cbridge_> <KipIngram> Haha - copypasta.  Somehow I've never encountered that term before.  That's a clever one.
14:06:29 <cbridge_> -!- f-a(~f-a@151.34.43.99) has left ##forth
14:08:33 <cbridge_> <KipIngram> tabemann: Right.  If something is unspecified then I regard it as programmer discretion.
14:09:11 <cbridge_> <KipIngram> I wouldn't normally expect user interface behavior to be unspecified, though.
14:09:41 <Bogen85> oh, so cbridge_ is still relaying has left messages? or has it not stopped?
14:10:09 <Bogen85> I guess hard to distinguish some
14:12:36 <cbridge_> <Zarutian_HTC> tabemann: what sort of software is this? Customer Record Management? order flow? or ui for industrial machines?
14:16:20 <cbridge_> <tabemann> Zarutian_HTC, QA management software for industry,  especially aerospace
14:18:20 <cbridge_> <tabemann> it covers stuff like nonconformances, corrective actions, complaint handling, document management, receiving inspections, in-process inspections, and so on
14:28:28 <cbridge_> <crc> Bogen85: it still misses a few. I'm working on it in between other tasks :)
14:32:04 <Bogen85> crc, oh, no problem, just an observation. For a bit there I though cbridge had left, but the earlier messages were from the system, and colored
14:32:39 <Bogen85> (the earlier cbridge quit/joined messages)
14:33:59 --- quit: cbridge_ (Remote host closed the connection)
14:34:12 --- join: cbridge_ joined #forth
14:35:14 <crc> the bridge should be pretty stable, and has auto detection for disconnects so it can restart as needed now
14:35:16 <Bogen85> there was a long discussion here yesterday about a type stack and type checking. The project I'm working (between a lot of other tasks) is a strongly typed "forth", and I will be using a type stack during compile and interpret, but not in the compiled words.
14:36:11 <cbridge_> <crc> I saw that, I'm interested in seeing how you make put with it
14:38:09 <Bogen85> yeah, is taking be a bit to work out the design, it has to be clear in my head on in documentation (albeit crude) before I can start, because this in uncharted territory. All the forths I've written so far were untyped.
14:38:26 <Bogen85> but I'm close
14:44:39 <Bogen85> just juggling so many other things taking my time
14:45:24 <cbridge_> <tabemann> I would tend towards implementing something like haskell's type system but using a type stack myself, were I to implement this
14:47:01 <Bogen85> yeah, strong static typing, functions have types
14:47:33 <Bogen85> (so a function vector will have a type, and you can't assign the wrong type to it)
14:49:25 <Bogen85> well, words have types... I'm staying with that nomenclature
14:50:03 <cbridge_> <tabemann> in many ways this would be more flexible than a more limited type system like trying to use a C-style type system
14:50:27 <cbridge_> <tabemann> hmm, one could even do ad hoc polymorphism with type classes...
14:50:53 <Bogen85> yeah, though I plan to go more with go struct/interfaces
14:51:41 <cbridge_> <tabemann> IMHO a "Forth" with type classes would be pretty neat
14:52:30 <Bogen85> forth has one level classes with one member function...
14:52:36 <Bogen85> create does ...
14:53:08 <Bogen85> and a compile time constructor...
14:56:32 <cbridge_> <tabemann> such a language would necessarily have to be far higher-level than a normal Forth
14:56:49 <cbridge_> <tabemann> e.g. it would have to have higher-order functions
14:57:01 <cbridge_> <tabemann> s/functions/words
14:57:26 <cbridge_> <tabemann> it would have to support type variables
14:57:58 <cbridge_> <tabemann> just add dynamic allocation and garbage collection, and then you pretty much have Factor
14:59:15 <cbridge_> <tabemann> one thing is that it would have to have deterministic stack effects
15:00:59 <cbridge_> <tabemann> in many ways, though, it would be not very forth-like aside from that it would be stack-oriented
15:02:58 --- quit: cbridge_ (Remote host closed the connection)
15:03:10 --- join: cbridge_ joined #forth
15:09:18 <Bogen85> tabemann, yeah, I'm not really referring to it as a forth, it is just forth like in how it compiles (to an extent...)
15:09:58 <Bogen85> it is still whitespace token delimited (for the most part, in my design I'm having to make exceptions for some things)
15:12:49 <Bogen85> my plan is to implement in ruby (outputing to ruby) (using it's GC), and output to C++, and leverage unique/shared pointers.
15:13:25 <Bogen85> then when I have a working system, reimplement in itself
15:14:10 <Bogen85> so what be targetting a VM, but will transpile
15:14:53 <cbridge_> <tabemann> the thing with that is how would you compile code and execute it on the fly in the ruby version?
15:15:28 <Bogen85> out to ruby strings and eval them, thereby creating new words
15:16:06 <Bogen85> and those will (should be) jitted as well
15:17:16 <Bogen85> oh... in the c++ reimplemented one will need to internally use a VM (or use mirjit), that that is for much later...
15:18:04 <cbridge_> <tabemann> why implement in three stages, rather than two?
15:18:29 <cbridge_> <tabemann> if you're going to write it initially in ruby, why not write the final implemenation using itself with that
15:19:01 <Bogen85> ok, keep ruby all along and just output to c++ for turnkey?
15:19:47 <Bogen85> or use mirjit from the beginning?
15:20:31 <Bogen85> keeping/staying with ruby and outputting c++ for turnkey would be the easiest
15:20:46 <cbridge_> <tabemann> nah
15:21:48 <cbridge_> <tabemann> what I mean write it to compile to ruby itself initially, and use that to bootstrap a native code version
15:24:03 <Bogen85> oh, yeah, that makes sense
15:24:04 <cbridge_> <tabemann> or you could just write the whole thing in assembly and compile directly to native code :D
15:25:14 <Bogen85> yeah, but then I'll have to implement my own memory management (lobster memory memory most likely)
15:25:28 <Bogen85> lobsert memory model...
15:25:34 <Bogen85> can't type...
15:27:07 <Bogen85> I did a lot of assembly previous decades (prior to 2010). This pass decade has all been higher level languages.
15:27:12 <Bogen85> this past...
15:29:16 --- quit: cbridge_ (Remote host closed the connection)
15:29:26 --- join: cbridge_ joined #forth
15:29:33 <cbridge_> <tabemann> writing a memory manager isn't that hard - it always seems like people will do anything to avoid writing a memory manager
15:30:29 <cbridge_> <tabemann> 
ACTION did write a memory allocator for his forths

15:30:45 <Bogen85> well, writing an automatic one (where the programmer does not have to do frees) is not as easy
15:31:06 <Bogen85> that does not leak, and is not a garbage collector
15:31:37 <Bogen85> https://aardappel.github.io/lobster/memory_management.html
15:31:46 <mark4> i also wrote one
15:31:58 <Bogen85> an automatic one?
15:32:05 <Bogen85> that knows when to free?
15:36:06 <mark4> of course not, thats complexity i dont need :)
15:36:09 <mark4> personally
15:36:17 <cbridge_> <tabemann> the main limitation of a writing a GC is either you have to do it for a higher-level language, or you have to do it with the assumption that all aligned words might be pointers, which of course results in wasted memory and performance lmitations
15:37:14 <Bogen85> I don't want a GC, they may work, but they heard my head. Automatic freeing is not necessarily a GC.
15:37:43 <Bogen85> C++'s smart pointers (unique and shared), and the model the lobster author discusses
15:37:48 <cbridge_> <tabemann> do you want something more along the lines of Rust's memory management model?
15:38:41 <Bogen85> yes, similar to that
15:39:33 <Bogen85> that lobster article talks about Rust's model
15:39:40 <cbridge_> <tabemann> my memory allocator is not that sophisticated - you have to allocate, resize, and free your memory manually
15:42:12 <Bogen85> yeah, I'm use that that (of course, I've done alot of c malloc/free/realloc, etc...). But with string manipulation that get tedious
15:42:38 <Bogen85> puts a lot of burden on the programmer to do something simple
15:44:37 <cbridge_> <tabemann> in Forth I typically don't actually use my memory allocator but rather use ALLOT or RAM-HERE! a lot
15:45:45 <cbridge_> <tabemann> well, RAM-ALLOT
15:46:25 <cbridge_> <tabemann> (any given task in zeptoforth has two HERE pointers, one in RAM for that task, and a global one in Flash)
15:48:37 <Bogen85> mark4 considers me a Forth guy... I consider myself more of a polyglot in regard to programming languages...
15:49:49 <mark4> i consider you knowledgeable about forth :)
15:49:58 <cbridge_> <tabemann> I used to be a Haskell guy, before I really decided that I wanted to create my own systems, and that Forth was ideal for accomplishing this
15:50:48 <cbridge_> <tabemann> before that I was an OCaml guy
15:51:22 <Bogen85> I played with OCaml for a while, did not get that far
15:51:43 <Bogen85> I've written a few toy forths
15:52:00 --- join: Kumool joined #forth
15:53:34 <cbridge_> <tabemann> I've written three Forths, zeptoforth, hashforth, and attoforth; I didn't really like the latter two, which required running on an OS, whereas zeptoforth is a bare-metal SRT/NCI Forth/operating system written for Cortex-M4 and Cortex-M7
15:54:46 <cbridge_> <tabemann> well, hashforth is neat in many ways, but it has the fundamental design limitation of that it was written to be TTC, which resulted in a significant performance hit (e.g. a tight loop in it is no faster than one in Python)
15:57:06 <cbridge_> <tabemann> also, hashforth was designed to be portable, but then I realized that portability between large systems (e.g. Linux) and small systems (e.g. Cortex-M4) is essentially infeasible (e.g. small systems need a distinction between RAM and Flash which doesn't exist for large systems)
16:02:06 <Bogen85> yeah, if I target a small system it would be through a hosted environment/compiler
16:02:21 <Bogen85> I used Chipforth and SwiftX for many years
16:05:23 <cbridge_> <tabemann> why not write your own compiler?
16:07:03 <Bogen85> That is what I'm planning to do... the language project I was discussing earlier... Things keep coming up with other things in my life...
16:07:28 <Bogen85> but the past week I've hashed out a lot of the design
16:10:07 <cbridge_> <tabemann> 
ACTION wonders what he should do next with zeptoforth

16:13:05 <cbridge_> <tabemann> maybe actually write real comments for the assembly source
16:19:43 --- part: rtdos left #forth
16:19:44 --- part: proteanthread left #forth
16:25:41 --- join: rtdos joined #forth
16:25:41 --- join: proteanthread joined #forth
16:42:37 <cbridge_> <tabemann> back
17:04:04 <cbridge_> <dave0> maw
17:04:28 <cbridge_> <crc> maw dave0
17:04:37 <cbridge_> <dave0> maw crc 
17:13:58 <cbridge_> <Keshl> What is "maw"? I require details. Such an engima. @.=.@
17:15:58 <cbridge_> <MrMobius> we're all still wondering
17:17:58 --- quit: cbridge_ (Remote host closed the connection)
17:18:11 --- join: cbridge_ joined #forth
17:24:20 <cbridge_> <tabemann> back
17:26:34 <cbridge_> <tabemann> maw dave0
17:26:42 <cbridge_> <dave0> maw tabemann 
17:29:45 <cbridge_> <Zarutian_HTC2> 
ACTION is trying to figgure out wtf 'risk based guidence' is regarding banks. Risk that they do not perform their function? what?

17:38:43 <cbridge_> <tabemann> "risk" is anything that doesn't involve them making money
17:47:25 <cbridge_> <Zarutian_HTC> might be, but I suspect it is just fig leaf for creepy old white men to force their out dated puriticanal views on businesses
20:35:15 --- join: gravicappa joined #forth
21:10:50 <cbridge_> <remexre> https://github.com/brightly-salty/mlatu
21:10:56 <cbridge_> <remexre> Have people here seen this?
21:13:49 <Bogen85> no. interesting though.
21:15:53 <Bogen85> What I'm working on, while similar (as far as stack based and statically/strongly typed) does not share the same overall project goals.
21:16:40 <proteusguy> Zarutian_HTC it's because fractional reserve banking incurs risk by its very nature. 
21:17:40 <proteusguy> tabemann re:forth with type classes.... on it. ;-)
21:24:46 <cbridge_> <dave0> re maw
21:33:45 --- nick: proteusguy -> proteusguy-awk
21:51:23 <cbridge_> <KipIngram> maw dave0
21:52:24 <cbridge_> <dave0> maw KipIngram 
21:54:24 --- quit: cbridge_ (Remote host closed the connection)
21:54:35 --- join: cbridge_ joined #forth
22:21:38 --- quit: mark4 (Ping timeout: 260 seconds)
22:35:07 --- join: mark4 joined #forth
22:45:55 --- nick: proteus-guy -> proteusguy
22:46:09 --- mode: ChanServ set +v proteusguy
23:59:59 --- log: ended forth/21.06.06