00:00:00 --- log: started forth/18.12.19
00:27:42 --- quit: dave0 (Quit: dave's not here)
00:45:22 --- quit: rdrop-exit (Quit: Lost terminal)
00:46:19 --- quit: KipIngram (Quit: WeeChat 1.4)
00:57:26 --- join: smokeink (~smokeink@42-200-118-145.static.imsbiz.com) joined #forth
01:07:06 --- quit: smokeink (Ping timeout: 250 seconds)
02:03:00 --- quit: ashirase (Ping timeout: 250 seconds)
02:07:31 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth
02:17:29 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
02:20:23 --- quit: MrMobius (Ping timeout: 250 seconds)
02:21:00 --- join: MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
02:23:29 --- quit: [1]MrMobius (Ping timeout: 240 seconds)
02:26:24 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
02:28:07 --- join: [2]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
02:28:55 --- quit: MrMobius (Ping timeout: 246 seconds)
02:31:39 --- quit: [1]MrMobius (Ping timeout: 250 seconds)
02:32:44 --- join: MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
02:35:23 --- quit: [2]MrMobius (Ping timeout: 244 seconds)
02:36:21 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
03:13:24 --- join: rdrop-exit (~markwilli@112.201.164.82) joined #forth
03:30:47 --- join: dave0 (~dave0@47.44-27-211.dynamic.dsl.syd.iprimus.net.au) joined #forth
04:30:48 --- quit: jhei (Ping timeout: 260 seconds)
04:31:00 --- join: jhei (sid81469@gateway/web/irccloud.com/x-vthlkvwgsfwudzmi) joined #forth
04:32:59 --- quit: mark4 (Ping timeout: 250 seconds)
04:40:40 --- join: smokeink (~smokeink@42-200-118-145.static.imsbiz.com) joined #forth
05:10:46 --- quit: smokeink (Remote host closed the connection)
05:21:27 --- join: smokeink (~smokeink@42-200-118-145.static.imsbiz.com) joined #forth
05:21:42 --- quit: dave0 (Quit: dave's not here)
05:33:23 --- join: freemor (~freemor@fsf/member/freemor) joined #forth
05:33:44 --- part: freemor left #forth
06:13:38 --- join: pierpal (~pierpal@95.239.223.85) joined #forth
06:22:54 --- quit: smokeink (Remote host closed the connection)
06:37:35 --- join: mark4 (~mark4@148.80.255.161) joined #forth
07:33:04 --- quit: tabemann (Ping timeout: 268 seconds)
07:52:24 --- quit: pierpal (Read error: Connection reset by peer)
07:52:37 --- join: pierpal (~pierpal@95.239.223.85) joined #forth
07:54:24 <proteusguy> mark4, https://en.wikipedia.org/wiki/Sixel
08:27:05 --- join: ncv (~neceve@host165-120-111-163.range165-120.btcentralplus.com) joined #forth
08:27:05 --- quit: ncv (Changing host)
08:27:05 --- join: ncv (~neceve@unaffiliated/neceve) joined #forth
09:03:47 --- join: dys (~dys@tmo-103-108.customers.d1-online.com) joined #forth
09:19:16 --- join: ncv_ (~neceve@2a00:23c5:341b:d800:e144:9e2b:a867:7791) joined #forth
09:19:16 --- quit: ncv_ (Changing host)
09:19:16 --- join: ncv_ (~neceve@unaffiliated/neceve) joined #forth
09:21:41 --- quit: ncv (Ping timeout: 246 seconds)
09:22:47 <mark4> yea i read that
10:21:46 --- quit: dys (Ping timeout: 250 seconds)
10:45:39 --- quit: ncv_ (Ping timeout: 250 seconds)
12:07:47 --- join: jedb_ (jedb@gateway/vpn/mullvad/x-cnyjkiewurmdnavl) joined #forth
12:10:49 --- quit: jedb (Ping timeout: 240 seconds)
12:17:07 --- join: dys (~dys@tmo-106-79.customers.d1-online.com) joined #forth
12:46:09 --- quit: pierpal (Ping timeout: 240 seconds)
12:57:58 --- quit: Zarutian (Read error: Connection reset by peer)
12:58:30 --- join: Zarutian (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth
13:43:29 --- quit: mark4 (Ping timeout: 240 seconds)
14:33:08 --- join: mark4 (~mark4@12.41.103.244) joined #forth
15:51:59 --- join: learning (~learning@47.149.80.42) joined #forth
15:56:06 <learning> hey guys
15:58:21 <DKordic> Hi learning.  
16:02:31 <learning> signed up for a third party ZNC. haven't used one before. i usually just check logs.
16:03:06 <john_cephalopoda> Hey
16:09:46 <learning> jesus christ
16:10:23 <learning> i had some hotkey setup for my terminal for copy paste
16:10:48 <learning> and i just went on a journey losing control over my computer while it typed out 500 lines of code letter by letter
16:10:50 <learning> JFL
16:12:06 <learning> oh this ZNC service stores passwords in plain text. nice. i'll definitely be providing them with my personal information.
16:16:16 <WilhelmVonWeiner> learning: could try joining hashbang.sh
16:16:37 <WilhelmVonWeiner> oh maybe ZNC is not what I thought it were
16:16:56 <john_cephalopoda> I just use my own server which runs weechat and ssh into the server every time ;)
16:17:05 <WilhelmVonWeiner> I use a hashbang shell account to do the same
16:17:13 <WilhelmVonWeiner> I have mutt and irssi running
16:17:22 <WilhelmVonWeiner> as abduco instances
16:20:06 <learning> what's this hashbang.sh thing
16:20:52 <WilhelmVonWeiner> bunch of nerds
16:20:54 <WilhelmVonWeiner> nerdin'
16:22:37 * Zarutian saw what they did with that curl pipe bash
16:24:28 <WilhelmVonWeiner> I've previously used their service to run Linux binaries otherwise unavailable on OpenBSD, too
16:24:29 <learning> kek
16:24:34 <WilhelmVonWeiner> anyway, night
16:24:50 <learning> night
16:28:25 --- quit: john_cephalopoda (Ping timeout: 250 seconds)
16:30:10 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth
16:32:35 <learning> what is this ZZZ part on the right called       : word ( var -- ZZZ ) ;
16:33:21 <Zarutian> datastack results?
16:33:42 <learning> ok
16:33:53 <learning> is there a word for comments next to colon definitions
16:34:02 <Zarutian> the ( ) part is basically a stack diagram of what the word expects on the data stack and what it leaves behind on the data stack
16:34:03 <learning> just trying to learn the vocab so i can talk about stuff in a way other people will understand
16:34:04 <PoppaVic> stack-comments
16:34:13 <reepca> also "stack effect"
16:34:30 <PoppaVic> before and after; small variations also report R)eturn stack effects
16:34:44 <learning> i'm finding the stack-comments surprisingly useful in learning the code im reading
16:35:12 <learning> they are so terse but ive been able to infer a lot
16:35:42 <Zarutian> learning: sometimes when I am reading a trick code from somewhere I move every word or obvious phrase to its own line and put a stack comment after it
16:36:19 <learning> thanks. will try that as i get stuck.
16:36:48 <Zarutian> this also applies when I do have quite a few (inside ten) items on the stack
16:37:30 <Zarutian> which sometimes happen in higher level words that has to carry quite a bit of partial state between its component words
16:37:38 <john_cephalopoda> Heh, I do the same. Writing a stack comment after every complex part so I can look up how it stands at that point.
16:37:48 <Zarutian> (component words -> the words it is made up of)
16:38:39 <PoppaVic> Yeah, vertical-alignment and comments are the only way to fly
16:40:42 <learning> forth strings are so ugly. must. find. a. way.
16:41:11 <learning> (+ "where" "is" "the" "love")
16:43:17 <john_cephalopoda> learning: ." This is a text to print" and S" This is a text to store to a temporary buffer with length min. 80 (iirc)" work okay.
16:43:33 <Zarutian> you mean in source? sure. But note that " is an immediate Forth word that starts inclusion of the string prepended by a runtime string word into the word at compilation time
16:43:48 <learning> i didnt know about ."    thank you
16:44:11 <learning> i just need to hack a prettier syntax
16:44:23 <Zarutian> john_cephalopoda: S" as the stack effect of ( -- str_addr str_length ) at runtime, no?
16:44:39 <john_cephalopoda> Zarutian: Yes.
16:44:47 <learning> s" where" s" is" s" the" s" love" s++       is impossible to read
16:45:01 <PoppaVic> "prettier syntax" is the very first and worst sin
16:45:13 <learning> programmer happiness > *
16:45:29 <john_cephalopoda> Zarutian: The str_addr is a temporary buffer of size 80 or greater (at least defined as that in ANS) and every new use of S" overwrites that buffer.
16:45:44 <learning> i dont quite understand what " does on its own. gonna google.
16:46:15 <Zarutian> john_cephalopoda: oh, right. But what if I wanted that string to be stored inside the word that is being compiled?
16:46:27 <learning> oh nvm its not defined
16:46:51 <Zarutian> in some forths it acts like s"
16:47:14 <john_cephalopoda> Zarutian: Hm, I'm actually not sure. Probably a bunch of "<number> EMIT" would do. Not sure how ." is handled.
16:47:31 <john_cephalopoda> Right, ." should be a run-time thing.
16:48:43 <learning> " fam" "  " " we're doing it" s+ s+ type fam we're doing it ok
16:48:48 <learning> ok that's a lot better
16:48:56 --- join: pierpal (~pierpal@95.239.223.85) joined #forth
16:49:00 <learning> i just defined " to act like s"
16:49:39 <learning> crisis averted
16:49:44 <john_cephalopoda> ." fam, we're doing it!" fam, we're doing it! ok
16:49:55 <Zarutian> john_cephalopoda: I have looked into it in eForth. There are the ." immediate word which compiles .|" into the word being compiled, then finds the other ", to find the length and comma's that into the word. Then for all the chars before that closing " it adds it in, char by char.
16:50:26 <learning> almost feel like i should put gforth in my screenname just so people know what forth im learning with
16:50:48 <john_cephalopoda> Zarutian: Huh, interesting. It's a nice choice.
16:50:55 <john_cephalopoda> learning: I am using gforth, too.
16:51:00 <john_cephalopoda> ." fam, we're doing it!"
16:51:08 <john_cephalopoda> ^ This gives me the right result.
16:51:38 <Zarutian> john_cephalopoda: then when the word gets run .|" is invoked which looks at the next cell behind it for the string length, does COUNT and TYPE of the string and advances the instruction pointer beyond the string.
16:52:41 <reepca> Note that recent gforths support string literal syntax through use of recognizers. "hello world" type works in those. For what it's worth.
16:52:48 * Zarutian always recommends eForth for someone who wants to really understand a Forth. Specially when one wants to port it to another (fantasy) ISA.
16:53:04 --- join: dave0 (~dave0@47.44-27-211.dynamic.dsl.syd.iprimus.net.au) joined #forth
16:53:34 <dave0> hi
16:53:34 <john_cephalopoda> Zarutian: I wonder if compiling a string to <number> EMITs would be a better way to do that.
16:54:06 <john_cephalopoda> It probably needs quite some additional memory space...
16:54:47 <john_cephalopoda> Also might break for UTF-8, so eForth's decision makes sense.
16:55:01 <john_cephalopoda> I should go to sleep, late already. See you.
16:55:03 <reepca> john_cephalopoda: it's generally a good idea to batch together I/O as much as possible. Good for performance. 
16:55:17 <Zarutian> john_cephalopoda: depends. I sketched out but havent written any code for a version that compacts these kind of strings into an encoding inspired by the Infocom encoding of text strings.
16:55:29 --- quit: pierpal (Ping timeout: 240 seconds)
16:56:14 <Zarutian> john_cephalopoda: allows for three letters per cell! (But shift codes like in ITA.2 teleprinter code is needed to change from alphanumerics to numbers and punctuation and also to switch lower and upper case)
16:56:42 <learning> "does this work"    :1: Undefined word
16:57:01 <learning> @ reepca
16:57:22 <Zarutian> learning: probably not as there isnt any word "does in your forths dictionary
16:57:49 <learning> reepca said    "hello world" type   works
16:58:35 <reepca> learning: s" gforth" environment? drop type
16:58:53 <john_cephalopoda> Zarutian: Imagine you want to encode a multi-byte UTF-8 character. When you got a string, you can simply move as far as you have to to read the whole character, while relying on cell size would mean that a string could be split between several stack elements.
16:59:03 <learning> 0.7.3
16:59:07 <learning> just installed with homebrew
16:59:11 <reepca> => 000.007.009_20181115
16:59:11 <learning> on OSX
16:59:23 <john_cephalopoda> learning: Put at . in front of the " and a space behind the ".
16:59:26 <reepca> ... something's a bit messed up with my version printing it seems
16:59:42 <Zarutian> john_cephalopoda: I never put the string on the stack, only a pointer to it and the length
16:59:42 <reepca> but it's 0.7.9. Anyway, that's what I meant by "recent versions of gforth".
16:59:59 <learning> ." works fine ye
17:00:12 <learning> you shocked me for a second
17:00:27 <john_cephalopoda> reepca: http://gforth.org/ says "0.7.3 (Latest release)"
17:00:35 <learning> imma take a break for a few
17:00:35 <siraben> learning:  are you familiar with how words are parsed in Forth?
17:00:40 <learning> yes
17:00:44 <siraben> Ok
17:00:48 <learning> they need spaces between them
17:00:48 --- join: pierpal (~pierpal@95.239.223.85) joined #forth
17:01:09 <learning> checks to see if its a word
17:01:11 <siraben> learning:  I'd recommend Starting Forth as an intro book
17:01:13 <learning> checks to see if its a number
17:01:15 <learning> then throws an error
17:01:24 <siraben> I found it a very good resource
17:02:10 <Zarutian> john_cephalopoda: but yeah, in the encoding variant I had sketched up, full utf-8 support via redefinition of shorter 'codes' inside the string to point to an unicode codepoint identified by a utf-8 byte sequence.
17:02:48 <reepca> john_cephalopoda: latest *release* was 0.7.3, yes, and it was also 5 years ago. The recognizer stuff is from a few years ago IIRC, which I would classify "recent".
17:03:30 <john_cephalopoda> Well, most distros ship releases. When there's no current release, the package will stay at 0.7.3 for 5 years :þ
17:04:32 <learning> thats what i started with ye
17:05:06 <learning> its nice to know that all thats happening is, is there whitespace, look up the word, if its not a word, see if its a number, if its not a number, then error
17:05:18 <Zarutian> john_cephalopoda: Eins og ég hef líklega sýnt með dæmum hér þá eru all margir stafir í móðurmáli mínu sem eru ekki í hið takmarkaða latneska stafrófi sem enska notar). (Translation: As I probably shown here with examples there are quite a few letters in my native language that are not in the more limited latin alphabet that english uses)
17:05:50 <siraben> English used to have ð
17:06:09 <Zarutian> siraben: þorn too. Æ and others also
17:06:10 <dave0> are you packing chars into cells?
17:06:16 <siraben> Zarutian:  yes
17:06:30 <siraben> Gotta thank the romans for latinizing it
17:06:37 <learning> ye ill have to look into that string stuff at some undesignated time in the future reepca if only to see how its implement
17:06:39 <siraben> It used to be written with runes before that
17:06:41 <john_cephalopoda> Zarutian: I'm from Germany, we got "öäüß". And when you want to internationalize your program, UTF-8 support is basically a must.
17:07:14 <PoppaVic> One ASCII to RUle them all..
17:07:27 <learning> lots germans using forth and lisp ive noticed
17:07:40 <john_cephalopoda> Would be interesting to look at different approaches for implementing ." and looking which one works best with UTF-8 while being the most efficient implementation.
17:07:54 <Zarutian> john_cephalopoda: yebb. I recall the days of doing search and replace in my html web pages to put in &aacute; and such instead of the usual letters, so it would show correctly.
17:08:55 <john_cephalopoda> Zarutian: I am just adding <?xml version="1.0" encoding="utf-8"?> to the top of the document. 
17:09:25 <Zarutian> john_cephalopoda: jeg har en spørgsmål for dig, fattar du hvad jeg skriva på dansk/norsk/sverge?
17:09:31 <john_cephalopoda> But yeah, I used to add all the &uuml; and &szlig; stuff to HTML so it would display right. :D
17:09:46 <Zarutian> john_cephalopoda: yeah, that was such a huge relief when that got supported.
17:10:08 <john_cephalopoda> Still isn't really working well in TeX though :D
17:10:36 <john_cephalopoda> There is some pack that claims to solve it, but I never got it working.
17:10:58 <john_cephalopoda> Anyway, it's after 2 am. Good night, for real this time.
17:11:11 <Zarutian> john_cephalopoda: night.
17:12:42 --- join: tabemann (~tabemann@rrcs-162-155-170-75.central.biz.rr.com) joined #forth
17:12:49 <rdrop-exit> Hello Forthwrights
17:14:03 --- quit: learning (Remote host closed the connection)
17:14:29 --- join: KipIngram (~kipingram@185.149.90.58) joined #forth
17:14:29 --- mode: ChanServ set +v KipIngram
17:14:51 <dave0> hi KipIngram 
17:14:55 <dave0> hi rdrop-exit 
17:15:40 <rdrop-exit> Hi dave0
17:17:04 <KipIngram> Hi dave0.
17:17:14 <KipIngram> Looks like they rebooted my seedbox - had to connect up again.
17:17:34 * Zarutian really likes how the old MacOS did MASKs that are used in clipping graphics.
17:17:35 <siraben> KipIngram:  not sure if I shared this already but I've been working on an assembler for the Z80
17:17:36 <siraben> https://github.com/siraben/zkeme80/blob/master/assembler3.scm
17:17:50 <KipIngram> Oh, no you hadn't.
17:17:53 <KipIngram> Or I missed it.
17:17:55 <siraben> If you scroll to the bottom there's a kernel around 20% done
17:18:14 <siraben> It'll have the best macro system out of all the assemblers I know
17:18:44 <siraben> Would make defining Forth words very simple
17:19:33 <KipIngram> In Lisp?
17:19:40 <KipIngram> Yes, macros help.
17:19:41 <siraben> Yeah, Scheme.
17:19:48 <siraben> Lisp has the best macros
17:19:52 <KipIngram> Specifically, they help you write something that's more architecture independent.
17:20:37 <siraben> Because Lisps are homoiconic languages, everything can be generated
17:20:44 <rdrop-exit> I wrote a Forth-like text macro langiage a while back
17:20:51 * Zarutian is off to bed
17:20:58 <siraben> Even stuff like labels are just expressions like this: (label foo)
17:21:07 <tabemann> hey guys
17:21:26 <rdrop-exit> Hi tabemann
17:21:31 <siraben> KipIngram:  although this assembler's not retargetable because I didn't write a data format that it can look up
17:21:45 <siraben> It's very much pattern matching on the expressions and creating the opcodes
17:21:53 <KipIngram> Cool.
17:22:02 <reepca> out of curiosity, what are your opinions on qhasm? https://cr.yp.to/qhasm.html
17:24:22 <siraben> Currently debugging an issue that makes my generated binary file differ from a reference one by 1 byte
17:24:24 <siraben> Hm
17:25:03 <tabemann> qhasm looks like an assembler frontend that uses a vaguely C-like syntax
17:25:59 <rdrop-exit> I don't see the point
17:26:15 <reepca> it's an interesting approach - same syntax for all architectures, but the behavior is still architecture-dependent
17:26:45 <siraben> Eventually I can just write (defcode "DUP" '((hidden . ())) (push bc) (push bc))
17:27:12 <siraben> Where defcode defines a new word "DUP" with the right instructions and makes sure to generate the link back to the previous word
17:27:50 <rdrop-exit> Any language that provides inline assembly accomplishes the same thing, or am I misunderstanding what he's trying to accomplish.
17:28:18 <siraben> A better macro system
17:28:31 <rdrop-exit> (I'm still on my first cup of coffee)
17:28:51 <reepca> I think the rationale is at least partially contained here: https://cr.yp.to/qhasm/20050129-portable.txt
17:29:14 <rdrop-exit> That's what I was reading
17:29:54 <siraben> Of course all the assemblers are equivalent, but try writing macros like push* which takes a list of registers (e.g. (hl de bc ix iy)) and outputs (push hl) (push de) (push bc) ...
17:30:18 <siraben> Or macros that are expanded without needing to name them
17:30:34 <siraben> ,@(make-list 10 '(push hl)) expands to 10 instructions of (push hl)
17:31:18 <siraben> I wonder a Forth-based assembler would look like
17:32:48 <siraben> If I can figure out some sort of data structure to hold the conversion from assembly instructions to opcodes, then this would be a targetable assembler
17:35:10 <reepca> I think the idea of assemblers with unified syntax is an interesting one - portability is the programmer's job, but no harder than necessary. The programmer knows what their target platforms are, and what potentially non-portable behaviors they want to use. Especially interesting (but I don't think really explored in qhasm) is the idea of pairing that with a macro system so that they can make their code exactly as portable or
17:35:10 <reepca> non-portable as they like.
17:35:45 <rdrop-exit> reepca: It's not clear to me, how is his approach different from using a portable language that supports inline assembly?
17:36:55 <siraben> Well, I don't have a C compiler for my target, and even if I did, why write a Forth in C rather than ASM?
17:37:21 <siraben> My approach is different in that it's Lisp-based, so it's really the macros that make it different
17:38:13 <rdrop-exit> Siraben, I'm asking reepca about qhasm.
17:38:19 <siraben> rdrop-exit:  oops sorry
17:38:41 <rdrop-exit> no porblen :)
17:42:03 <reepca> rdrop-exit: it's using a non-portable language with a unified syntax that preserves the one-to-one instruction mapping. The main idea is that if some other architecture has an instruction that does exactly the same thing as this one, then the syntax should be the same. I guess it just seems interesting to me because it's a way of providing low-level control without making porting any harder than it has to be.
17:42:28 <dave0> not sure i'd say gforth is portable C, it looks like it's gcc-specific
17:42:48 <siraben> reepca:  what about targets like the Z80?
17:42:50 <reepca> I'll admit, it's mostly of only conceptual interest to me - I haven't tried making stuff with it or anything.
17:44:01 <rdrop-exit> reepca: I'm not sure his concept is feasible
17:45:26 <reepca> rdrop-exit: in which way? The tools work, and seem to work well enough for the author's purposes at least. How well they would work for you or me, I really don't know.
17:49:14 <rdrop-exit> I'll take a closer look when I'm fully awake, I just can't imagine a portable instruction set would be feasible across all ISAs.
17:49:51 <siraben> The Z80 has an extremely different architecture than something like the x86
17:50:05 <siraben> That and the fact that it's 8 bit instead of 64 or 32
17:51:05 <rdrop-exit> BTW Siraben, here's an example from my RPN-based macro processor:
17:51:27 <rdrop-exit> `'country `"The Duchy of Grand Fenwick" `new
17:51:35 <PoppaVic> 4-instruction forth. heh.. there you go: portable.
17:51:44 <PoppaVic> or was it THREE? ;-)
17:51:44 <rdrop-exit> `'Spain `'country `store
17:51:59 <rdrop-exit> The rain in `country stays mainly on the plain
17:52:12 <rdrop-exit> the above would output:
17:52:17 <rdrop-exit> The rain in Spain stays mainly on the plain
17:53:01 <reepca> the instruction set isn't portable, though. It's up to the programmer to make sure their program runs on the architectures they want. But equivalent instructions always look the same.
17:54:08 <reepca> My main issue with the concept is that "equivalent instructions" is a *deep* rabbit hole to go into. Is an add that might set a carry bit somewhere equivalent to one that might not?
17:55:14 <rdrop-exit> The concept might be useful if you're coding for a family of similar processors, such as x86
17:55:22 <siraben> Exactly, it's really not equivalent across processors
17:55:30 <siraben> Maybe across similar processers, but only maybe
17:55:53 <reepca> at some point, to verify it does what you want, you end up having to actually look at the mapping to instructions
17:56:37 <reepca> for the author, that's probably easy, since he has his own conventions on how they get mapped
17:57:09 <reepca> I find myself wishing that qhasm had more documentation online...
17:58:07 <reepca> which is weird, since apparently it's been around since 2005
18:04:44 <siraben> Which is why IMO having a good macro system will alleviate these problems
18:04:56 <siraben> The only universal language is one that the writer understands
18:05:14 <rdrop-exit> For his portable 64*64->128 example, you can define a portable mulh for the high 64 bits in a macro
18:05:46 <siraben> reepca:  reminds me of a project I tried to do that converted an abstract register machine into Z80
18:05:47 <siraben> https://github.com/siraben/sicp-to-z80
18:05:55 <siraben> Abandoned because the generated code was inefficient
18:06:16 <siraben> It essentially boils down to compilers
18:06:30 <siraben> If you have a good compiler for your platform, then you don't need to worry about asm
18:07:25 <siraben> There's various ways to solve portability, another is to write a bytecode interpreter
18:07:30 --- quit: xek (Ping timeout: 245 seconds)
18:07:55 <siraben> With overhead of course, but at least you can worry about compiling to a single target
18:08:19 <rdrop-exit> Compiler optimization is NP-complete
18:08:44 <siraben> I was thinking about how program synthesis could help this problem
18:09:01 <siraben> Write a specification, generate the code
18:10:06 <siraben> Of course now you're entering undecidability, but for well-scoped problems program synthesis is magic
18:11:49 --- quit: tabemann (Ping timeout: 240 seconds)
18:14:41 <reepca> From a certain perspective, all programming languages are interpreted languages. Some are just a lot weaker than others. Java code is a script in a non-turing-complete language that outputs java bytecode. C code is a script in an almost-turing-complete language (thanks to the C preprocessor) that generates machine code. Forth and Lisp use turing-complete program-generation languages. I guess what I'm thinking is that it would be
18:14:41 <reepca> interesting to use a compiler like a library instead of like a language.
18:18:06 <rdrop-exit> The more difficult portability issues are related to IO and the runtime environment.
18:18:31 <siraben> Forth and Lisp have amazing extension capabilities
18:20:09 <siraben> rdrop-exit: That's a very difficult problem because it ultimately depends on the hardware
18:20:34 <siraben> My calculator's flash chip needs a bunch of specific bytes written at specific ports to issue behaviors like "unlock flash" and "lock flash"
18:20:48 <siraben> And the display chip, I'm still figuring it out
18:21:28 <rdrop-exit> That's why VMs are the most effective approach if portability is the overriding goal
18:21:48 <siraben> But one should never need to solve the same problem twice, so if I manage to draw a pixel, I'll wrap it in a word
18:21:59 <siraben> Right, VMs are effective.
18:22:40 <siraben> Forth attempts to achieve portability through a VM-like model ("cells" instead of "bytes"), various registers and so on
18:23:23 <rdrop-exit> The ANS standard takes the wrong approach to portability IMHO
18:23:53 <siraben> How so?
18:24:11 <rdrop-exit> It makes simple things complex
18:25:48 <rdrop-exit> It would have been better to define a VM ISA for each common bit-width, and limit portability to the chosen bit-width
18:26:56 <siraben> Portability is hard, let's just reinvent the wheel for each new target
18:28:17 <PoppaVic> siraben: and that is exactly what CM would advocate - for the win.
18:29:35 <rdrop-exit> For me portability is worthwhile on host machines, for targets it depends on the project.
18:30:42 <rdrop-exit> My Forth IDE is on POSIX, but targets could be anything.
18:31:30 <rdrop-exit> A long time ago, my Forth IDE was on DOS.
18:32:17 <siraben> PoppaVic: CM?
18:32:22 <siraben> Oh Chuck himself
18:32:40 <siraben> Right, because the world needs more programs
18:33:39 <rdrop-exit> That's a strange thing to say
18:34:01 <siraben> Forth IDE?
18:34:24 <rdrop-exit> My Forth setup is umbilical (AKA tethered)
18:34:49 <siraben> Incidentally portability is an area that formal verification is trying to work on, don't just test but prove that your program is portable and equivalent on different targets
18:35:25 <rdrop-exit> Good luck with that
18:36:32 <PoppaVic> rdrop-exit: I'll take 2 please ;-)
18:36:42 <rdrop-exit> :)
18:36:45 <siraben> I haven't touched it, but I think they're making progress
18:36:49 <siraben> There's already a formally verified C compiler
18:37:01 <PoppaVic> Tethered forth would be wunnerful.
18:37:27 <rdrop-exit> Most commercial Forths are tethered
18:38:03 <rdrop-exit> SwiftX from Forth Inc.
18:38:13 <rdrop-exit> I forget the nae of the one from MPE
18:38:43 <rdrop-exit> Here's a page on chipForth that explains the concept:
18:38:51 <rdrop-exit> https://www.computer-solutions.co.uk/chipdev/cfworks.htm
18:39:16 <rdrop-exit> * I forget the name of the one from MPE
18:41:37 <crc> VFX Forth 7 iirc
18:41:59 <rdrop-exit> thanks
18:42:06 <rdrop-exit> Here's the SwiftX page:
18:42:11 <rdrop-exit> https://www.forth.com/embedded/
18:43:01 <rdrop-exit> Here's the MPE page:
18:43:04 <rdrop-exit> https://www.mpeforth.com/software/forth-cross-compilers/forth-7-cross-compilers/
18:43:46 <rdrop-exit> GForth isn't tethered AFAIK
18:44:26 <rdrop-exit> Which is why I never bothered with it.
18:45:08 <crc> nope. there's gforth ec, but afaik it isn't tethered and building it is difficult
18:46:31 <rdrop-exit> I see
18:50:28 <rdrop-exit> brb
18:57:06 --- quit: dave0 (Quit: dave's not here)
19:00:12 --- join: dave0 (~dave0@47.44-27-211.dynamic.dsl.syd.iprimus.net.au) joined #forth
19:08:48 <rdrop-exit> Have to run, chat again later. Keep on Forthin'
19:08:56 --- quit: rdrop-exit (Quit: Lost terminal)
19:24:57 --- quit: proteusguy (Ping timeout: 244 seconds)
19:38:32 --- join: proteusguy (~proteus-g@cm-58-10-209-244.revip7.asianet.co.th) joined #forth
19:38:32 --- mode: ChanServ set +v proteusguy
19:42:46 --- join: tabemann (~tabemann@2602:30a:c0d3:1890:a433:523c:27b8:b5c8) joined #forth
21:21:19 --- quit: dddddd (Remote host closed the connection)
21:41:04 --- quit: dave0 (Quit: dave's not here)
22:23:00 --- quit: dys (Ping timeout: 268 seconds)
23:59:59 --- log: ended forth/18.12.19