00:00:00 --- log: started forth/18.12.05
00:17:09 --- quit: jedb (Remote host closed the connection)
00:22:04 --- quit: gravicappa (Ping timeout: 250 seconds)
00:34:10 --- quit: CORDIC (Ping timeout: 272 seconds)
00:37:55 --- quit: smokeink (Remote host closed the connection)
01:11:37 --- join: jedb (jedb@gateway/vpn/mullvad/x-fozpypfahynmmkkl) joined #forth
01:13:33 --- join: smokeink (~smokeink@118.131.144.142) joined #forth
01:22:10 --- join: xek (~xek@apn-37-248-138-82.dynamic.gprs.plus.pl) joined #forth
02:03:02 --- quit: ashirase (Ping timeout: 250 seconds)
02:04:34 --- join: gravicappa (~gravicapp@109.233.168.8) joined #forth
02:08:55 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth
02:33:54 --- join: ncv (~neceve@2a00:23c5:341b:d800:e144:9e2b:a867:7791) joined #forth
02:33:54 --- quit: ncv (Changing host)
02:33:54 --- join: ncv (~neceve@unaffiliated/neceve) joined #forth
02:38:18 --- quit: phadthai (Ping timeout: 272 seconds)
02:46:22 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
03:12:22 --- quit: xek (Ping timeout: 250 seconds)
03:25:47 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
03:27:14 --- join: [2]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
03:27:15 --- join: xek (~xek@public-gprs352612.centertel.pl) joined #forth
03:29:30 --- quit: MrMobius (Ping timeout: 268 seconds)
03:30:08 --- quit: [1]MrMobius (Ping timeout: 250 seconds)
03:37:02 <siraben> KipIngram:  A while back you said you wanted me to go bare metal with my Forth system, well I've been reading the ASM code for a simple OS for the calculator https://www.cemetech.net/programs/index.php?mode=file&id=629
03:37:03 <siraben> I think I'll model my off that, because it gets the boring stuff out of the way
03:37:52 <siraben> The beauty of Forth is that a file system isn't necessary, just blocks.
03:39:14 --- quit: xek (Read error: Connection reset by peer)
03:59:11 --- join: ncv_ (~neceve@host165-120-99-237.range165-120.btcentralplus.com) joined #forth
03:59:11 --- quit: ncv_ (Changing host)
03:59:11 --- join: ncv_ (~neceve@unaffiliated/neceve) joined #forth
04:01:40 --- quit: ncv (Ping timeout: 252 seconds)
04:06:24 --- join: ncv__ (~neceve@host165-120-99-237.range165-120.btcentralplus.com) joined #forth
04:06:24 --- quit: ncv__ (Changing host)
04:06:24 --- join: ncv__ (~neceve@unaffiliated/neceve) joined #forth
04:08:39 --- quit: ncv_ (Ping timeout: 246 seconds)
04:11:04 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth
04:15:25 --- join: ncv_ (~neceve@unaffiliated/neceve) joined #forth
04:17:48 --- quit: ncv__ (Ping timeout: 250 seconds)
04:24:49 --- quit: ncv_ (Ping timeout: 240 seconds)
04:34:16 --- join: ncv (~neceve@unaffiliated/neceve) joined #forth
05:03:51 --- quit: john_cephalopoda (Quit: Trees can see into your soul. They lurk everywhere.)
05:19:56 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth
05:21:47 <KipIngram> Hi.  I don't think I'd say I "want" you to - I just think there would be some interesting things down that road, and you wouldn't have to "accomodate" someone else's design.
05:22:46 <KipIngram> And yeah - I appreciate the features a file system brings to the table, but you don't necessarily NEED those features for all applications, and Forth lets you do whatever parts of it you want.
05:35:22 --- quit: gravicappa (Ping timeout: 244 seconds)
06:07:06 <siraben> Yeah, I could learn a lot from making my own OS, Forth-style.  It's much easier to do so when you have a small system and instruction set.
06:07:30 <siraben> I've been groking the flash memory recently, so there's a system call to read a page to RAM, and a system call to write a page from RAM
06:32:12 --- join: gravicappa (~gravicapp@h95-110-51-236.dyn.bashtel.ru) joined #forth
06:59:37 --- quit: dave0 (Quit: dave's not here)
07:09:27 --- quit: smokeink (Remote host closed the connection)
07:16:17 --- join: phadthai (mmondor@ginseng.pulsar-zone.net) joined #forth
07:24:22 --- quit: tabemann (Ping timeout: 268 seconds)
07:45:38 <KipIngram> Yes, sounds right.  So speaking of bare metal...  Flash memory based storage is what I do at work; we build enterprise grade flash systems.
07:45:53 <KipIngram> I can tell you that there is a *butt* *load* of functionality buried under those system calls you just mentioned.
07:46:07 <KipIngram> Using NAND flash effectively for data storage is a huge undertaking.
07:46:23 <KipIngram> There are so many things to consider and get right, and those system calls just roll them up for you.  :-)
07:46:42 <KipIngram> Wear leveling, garbage collection, error detection and correction, RAID implementation, etc. etc. etc.
07:46:49 <KipIngram> Encryption, if you have it.
08:27:37 <siraben> If I have time I'll look at the implementation of other people's flash routines
08:27:54 <siraben> So that raises my memory by a lot
08:28:41 <siraben> 24 KB RAM, around 480 KB flash
08:29:02 <siraben> I think even more if I wrote my own OS
08:33:52 --- join: dys (~dys@tmo-103-188.customers.d1-online.com) joined #forth
08:37:06 <siraben> Maybe I'm overthinking how much RAM Forth actually uses.
08:37:39 <siraben> KipIngram:  what does it usually amount to?  10 KB for a text editor, simple file system, math and graphical routines, etc?
08:39:45 <KipIngram> You mean for flash storage management?  Quite a lot more than that, I imagine.
08:39:57 <KipIngram> I'm not 100% sure wha the size of our various pieces are.
08:40:24 <KipIngram> And at any rate, I imagine the 80/20 principle could be applied here - you could probably get a solidly competent base of code for managing flash in place for something like you mentioned.
08:40:36 <KipIngram> But we've pulled out all the stops - it's a "Cadillac" system.
08:40:59 <KipIngram> There are three things that drive the complexity.
08:41:14 <KipIngram> 1) Flash wears out, so you don't want to have write "hot spots" in your physical array.
08:41:33 <KipIngram> 2) Unit of erasure is larger than the unit of writing, so garbage collection is required.
08:41:53 <KipIngram> ^ those two together imply that you have to have a "logical to physical mapping table" that you maintain during operation, and save across power cycles, and so on.
08:41:54 <KipIngram> and
08:42:07 <KipIngram> 3) Flash is CRAP and will just "forget" over time.  It's really pretty shitty stuff.
08:42:25 <KipIngram> So you have to engineer in error codes and things like that to insulate yourself against that crappiness.
08:43:00 <KipIngram> Now, in an older device like your calculator you probably have SLC flash (the earlier) which stores one logical data bit in each flash cell.
08:43:06 <KipIngram> It's the most robust and the least crappy.
08:43:41 <KipIngram> MLC puts two data bits in each cell (four voltage levels), TLC puts 8 voltage levels (three bits), and QLC (appearing now) puts four bits (so 16 voltage levels that have to be distinguished in the cell).
08:44:11 <KipIngram> More voltage levels means smaller spacing between levels and it's easier for a voltage to creep into the next range and give you a one-bit or multi-bit error.
08:47:09 <KipIngram> Just FYI, what the flash memory actually DOES is provide a huge number of little "pockets" (cells) that charge can be stored in.  More charge means more voltage, and it's possible for the chip to read out the voltage associated with a cell's stored charge.
08:47:25 <KipIngram> So by controlling the amount of charge you pump in, and later measuring the voltage, you achieve data storage.
08:48:59 <KipIngram> To motivate the need for garbage collection very clearly, imagine that you have a flash chip that has write unit of 8kB but erase unit of 64kB.
08:49:08 <KipIngram> Once you write to a page you can't re-write it unless you erase it.
08:49:16 <KipIngram> Now imagine you write data to every single physical 8k page.
08:49:19 <KipIngram> Great.
08:49:26 <KipIngram> Now you want to re-write on eof those pages.
08:49:29 <KipIngram> So you have to erase it.
08:49:42 <KipIngram> But erases work on 64k, so along with erasing that page you have to erase 7 other pages.
08:49:49 <Zarutian> just switch to mram or memristor ram already ;-)
08:50:06 <KipIngram> so that's the nut of the problem.
08:50:08 <KipIngram> yeah, no kidding.
08:50:30 <KipIngram> There is a mram in our latest product that's used for some of the management data - the coversations I've listened in on imply it's insanely expensive.
08:50:36 <Zarutian> or treat the flash as infrequently ereased worm storage
08:50:56 <KipIngram> Yeah.  But that's not what they're trying to build and cell here.
08:51:19 <KipIngram> We have it all figured out and the system works very well.  It's just a lot to juggle.
09:01:48 <john_cephalopoda> So better use spinning rust? :þ
09:11:10 --- join: MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
09:13:36 --- quit: [2]MrMobius (Ping timeout: 268 seconds)
09:15:04 --- quit: gravicappa (Ping timeout: 250 seconds)
09:17:43 <KipIngram> Well, flash has a lot of advantages over spinning disks.
09:17:51 <KipIngram> No seek time for one thing.  Very very fast.
09:20:52 <john_cephalopoda> And quite low-power.
09:23:44 <siraben> KipIngram:  Ah, I mean 10 KB for the Forth part of the system
09:24:15 <siraben> I think that should fit comfortably within RAM, with the OS routines loaded in one page
09:25:12 <siraben> KipIngram:  There's a lot more abstraction than what you described, fortunately.  I can treat the flash as some sort of storage
09:25:22 <john_cephalopoda> Hmm, the block concept...
09:25:29 <siraben> Although more reading and experimenting on my part is required
09:25:51 <siraben> This is getting delicate, I might brick my calculator permanently if I write to the wrong sector
09:26:07 <siraben> I've recently discovered https://www.cemetech.net/projects/jstified/ though, which is a godsend
09:27:59 --- quit: sigjuice (Quit: ZNC - http://znc.in)
09:28:21 * siraben uploaded an image: Screen Shot 2018-12-06 at 12.27.28 AM.png (929KB) < https://matrix.org/_matrix/media/v1/download/matrix.org/ewGZkEzydSIHWABvMHFzgANS >
09:28:52 <siraben> It's a bit old in web terms. The simulator should probably be written in webassembly
09:29:50 <siraben> KipIngram:  So to keep things from wearing out like you said, I'll be writing to flash if and only if an explicit "save block" is requested
09:29:53 --- join: sigjuice (~sigjuice@107.170.193.86) joined #forth
09:45:15 --- join: gravicappa (~gravicapp@h95-110-51-236.dyn.bashtel.ru) joined #forth
09:52:38 --- quit: pointfree (Ping timeout: 264 seconds)
09:55:01 --- join: pointfree (sid204397@gateway/web/irccloud.com/x-gzcllbusnsauvukx) joined #forth
10:07:33 <KipIngram> Well, what's generally done is to just write sequentially through the physical space - every write goes to the "next" available physical page.  Or something approximating that - sometimes they break the physical space into "stripes" and write incrementally through those, but the stripes aren't necessarily re-used in incremental order. 
10:07:54 <KipIngram> Then the logical to physical mapping table just keeps up with what physical address is associated right now with any given logical address.
10:08:12 <KipIngram> You don't give the whole space to the user - you reserve some (15-20 percent) for the system.
10:08:27 --- quit: gravicappa (Ping timeout: 246 seconds)
10:08:30 <KipIngram> That's "scratch space" that it uses to juggle things around when it needs to clear out previously used stripes for re-writing.
10:08:55 <KipIngram> You try to pick a stripe where most of the content has been re-written elsewhere by the user; you then move the remainder and then you can erase the stripe and re-use it.
10:09:13 <KipIngram> Those moves are overhead - they're reads and writes not called for by the user.
10:09:17 <KipIngram> So you want to minimize them.
10:09:37 <KipIngram> You do that by selecting the "most stale stripe" you can, though you do have to pay attention to wear leveling to some degree.
10:10:00 <KipIngram> That "moving out of non-stale content" is garbage collection.
10:10:26 <KipIngram> Usually erasing the stripe takes very little time and isn't a performance bottleneck - it's the moving out of the remaining valid data that impacts your performance.
10:10:50 <KipIngram> The ratio of total writes to user writes is called "write amplification," and it can run in the range 3-8.
10:11:07 <KipIngram> The more scratch space you reserve for the system (that's called "overprovisioning") the lower the write amplification will be.
10:11:40 <KipIngram> Also if your write traffic has "hot zones" (larger than proportional writing to small areas of the logical space) you will get lower write amplification.
10:11:45 <KipIngram> Randomly distributed writes are the worst.
10:12:55 <KipIngram> I did a math analysis of all this once, and I found that for random write distribution if you reserved something around 85% of the space for the system (giving the user only 15%) then most of the time you wouldn't need to move anything - you'd almost always be able to find a stripe to erase that had been totally cleared by user writes.
10:13:08 <KipIngram> But no one wants to make their flash product such that the user can only have 15% of the capacity.
10:13:11 --- quit: ncv (Remote host closed the connection)
10:18:01 --- join: DKordic (~user@178-221-182-126.dynamic.isp.telekom.rs) joined #forth
10:59:24 --- join: verisimilitude (~user@2604:180:2:725::698a) joined #forth
10:59:52 <verisimilitude> Say, what's the opinion on Forths that run on hardware unsuited to heavy interactivity as is common in most Forth environments.
11:01:06 <verisimilitude> I suppose a simulator for the machine that does add interactivity would be best.
13:49:03 --- quit: Zarutian (Read error: Connection reset by peer)
13:49:20 --- join: Zarutian (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth
14:18:03 --- join: dave0 (~dave0@47.44-27-211.dynamic.dsl.syd.iprimus.net.au) joined #forth
14:20:01 <dave0> hi
14:27:34 --- quit: Zarutian (Read error: Connection reset by peer)
14:27:39 --- join: Zarutian_2 (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth
14:28:10 --- nick: Zarutian_2 -> Zarutian
14:28:28 <WilhelmVonWeiner> rdrop-exit: I like !@.
14:28:56 <WilhelmVonWeiner> verisimilitude: what do you mean "heavy interactivity"?
14:36:48 <verisimilitude> Well, I'd like to write a Forth on a machine without a full keyboard.
14:37:34 <verisimilitude> It seems like the best solution would be writing something to provide this and interactivity and then have the option of dumping it for use on the real machinery.
14:38:17 <verisimilitude> The memory space is very small, so it would be for the best that names aren't present in the image, anyway.
14:40:40 <WilhelmVonWeiner> Look up chuck's history on sourceless Forth and OKAD.
14:41:11 <WilhelmVonWeiner> He had a 4-button keyboard he used to enter commands with a menu-system I think.
14:41:40 <WilhelmVonWeiner> attached the controls to his chair so he could sit back and type with his arms on the armrests
14:42:05 <WilhelmVonWeiner> Oh I completely misread what you said
14:42:12 <WilhelmVonWeiner> Yeah what you said sounds pretty solid
14:52:43 <john_cephalopoda> verisimilitude: Having some menu system for entering commands would be pretty easy to do.
14:54:04 <DKordic> Like SPI!?  
14:55:43 <WilhelmVonWeiner> use 4 pins for a menu system
15:19:54 <john_cephalopoda> MISO, MOSI, CLK, CS. Right.
15:22:24 <WilhelmVonWeiner> just any 4 pins. Don't need to write an SPI driver if you've got some spare pins
15:26:41 <verisimilitude> I already have a sourceless programming system for this machine, but that's unrelated to Forth.
15:27:10 <verisimilitude> Say, on that note, is there anywhere I could get OKAD?
15:29:24 <WilhelmVonWeiner> nope
15:38:32 <john_cephalopoda> verisimilitude: Maybe this? https://web.archive.org/web/20040202043928/http://www.colorforth.com:80/vlsi.html
15:43:07 <john_cephalopoda> Hmmmm, there are a lot of cool things one could do with Forth...
15:46:05 --- join: smokeink (~smokeink@118.131.144.142) joined #forth
15:46:07 <WilhelmVonWeiner> john_cephalopoda: most of that is also hosted at colorforht.io
15:46:17 <WilhelmVonWeiner> sorry, https://colorforth.github.io/
15:52:05 <verisimilitude> Alright.
15:52:37 <verisimilitude> Say, I noticed that github subdomain a ways back; would you know how recently that was made; it came as a surprise, but I enjoy that it's convenient to browse that website again.
16:07:47 <john_cephalopoda> pointfree: If you read this: How does your mouse input grabbing in the sixel demo work? It doesn't work in my mlterm for some reason and I have difficulties understanding which mechanism is used for it and how it works.
16:10:16 <john_cephalopoda> Off for now~
16:10:18 --- quit: john_cephalopoda (Quit: Trees can see into your soul.)
16:13:45 <pointfree> verisimilitude: Penti keyboard? https://x0r.be/@pointfree/100789199205467782
16:21:35 --- join: rdrop-exit (~markwilli@112.201.164.82) joined #forth
16:27:48 <rdrop-exit> Good morning Forthwrights :)
16:48:14 <verisimilitude> I appreciate the suggestion, pointfree, but I've withheld some relevant information that makes this option infeasible.
16:49:22 <verisimilitude> I suppose using ``hardware'' in my first sentence was incorrect, since I'm actually targeting an old virtual machine.
16:53:24 <verisimilitude> Hello, rdrop-exit.
16:56:54 <rdrop-exit> Hi Verisimilitude!
16:57:07 <verisimilitude> What have you been working on, lately?
16:58:19 <rdrop-exit> Porting and rewriting some ancient code
16:58:59 <rdrop-exit> I wouldn't call it working though, I only do it when the mood carries me
16:59:56 <verisimilitude> Alright.
16:59:59 <rdrop-exit> other than that, improving my poker game :)
17:00:32 <rdrop-exit> Yourself?
17:01:02 <verisimilitude> I'm planning to write a Forth targeting a virtual machine; I don't believe Forth has ever been targeted to this machine.
17:01:35 <rdrop-exit> Cool
17:02:42 <rdrop-exit> I looked into putting a Forth on the JVM once, but the JVM spec just made my stomach trun
17:02:46 <rdrop-exit> *turn
17:05:27 <rdrop-exit> Someone alrady did it, but I wanted to use my own Forth model.
17:07:29 <verisimilitude> What would your model be?
17:09:17 <rdrop-exit> Nothing special, just having the set of primitives I'm use to, rather than being ANS-oriented
17:09:32 <rdrop-exit> *used to
17:10:05 <rdrop-exit> My typing is always awfull when I'm still on my first cup of coffee
17:12:08 <verisimilitude> Alright.
17:12:40 <rdrop-exit> Do you have a particular application in mind that makes that VM particularly attractive?
17:14:29 <verisimilitude> No; I just have a development tool for it I wrote and I thought a Forth on it would be interesting.
17:14:35 <verisimilitude> This isn't the JVM.
17:16:15 <verisimilitude> I'm planning to target CHIP-8 with a Forth.
17:17:47 <rdrop-exit> Cool, ancient tech.
17:19:18 <rdrop-exit> brb, I'm going to look it up on Wikipedia
17:19:40 <verisimilitude> I'll point you towards a good reference, instead.
17:19:57 <verisimilitude> http://mattmik.com/files/chip8/mastering/chip8.html
17:20:08 --- join: pierpa (5fefdf55@gateway/web/freenode/ip.95.239.223.85) joined #forth
17:21:51 <rdrop-exit> Great thanks!
17:23:22 <rdrop-exit> "Original CHIP-8 Display resolution is 64x32 pixels", wow!
17:26:11 <rdrop-exit> I'm sure you'll have a blast putting a Forth on that.
17:30:14 <verisimilitude> I intend to, yes.
17:30:24 <verisimilitude> This is part of why it's not suited to hosting the interactive Forth itself.
17:31:59 <verisimilitude> I may not even have an interactive environment for it, really.
17:34:05 <rdrop-exit> Will you be limited to 4k total?
17:34:29 <rdrop-exit> RAM
17:34:48 <verisimilitude> Yes, but it's actually 3.5K, if you want it to run on the original implementation.
17:35:53 --- join: tabemann (~tabemann@rrcs-162-155-170-75.central.biz.rr.com) joined #forth
17:36:28 <rdrop-exit> Very interesting
17:40:12 <rdrop-exit> I guess you could try to see if you could extend (so to speak) the CHIP-8 VM into a minimal 2 stack VM in about a half KB or so.
17:41:10 <verisimilitude> There's a machine managed return stack, which is half of it.
17:41:33 <verisimilitude> You can only use it for control flow, however.
17:42:49 <tabemann> hey guys
17:43:00 <rdrop-exit> Hi Tabemann
17:43:36 * tabemann feels his task ring is too slow - 2 seconds to go around 1024 times with 256 tasks
17:44:31 <rdrop-exit> If the Forth VM should be more memory efficient then the CHIP-8 VM to make up for the extra resources it occupies.
17:45:02 <rdrop-exit> Variable length instructions perhaps
17:45:27 <rdrop-exit> *delete the "If the"
17:47:41 <rdrop-exit> You could make a cross-compiler that builds a custom forth kernel for the particular application, compressing the opcode set to the needs of the application
17:48:04 <tabemann> if you don't care about speed you could use token threading
17:48:22 <rdrop-exit> That would be one way for the Forth to give back more then it takes.
17:48:55 <rdrop-exit> tabemann: he only has 3.5k to play with
17:49:24 <tabemann> damn - not even much room for a token table
17:50:32 <rdrop-exit> Fun challenge
17:52:16 <tabemann> that reminds me of the original Atari 400 (IIRC), which had only 256 bytes of memory (but could support more ROM than that)
17:53:05 <tabemann> no, it wasn't theh 400
17:53:12 <rdrop-exit> I read a fun book on it last year "Chasing the Beam"
17:53:12 <tabemann> oh, the Atari 2600
17:53:20 <rdrop-exit> That's it
17:53:36 <tabemann> like the most difficult platform to code for ever
17:54:10 <rdrop-exit> Correction, the book was "Racing the Beam"
17:55:22 <rdrop-exit> Jumping through hoops with tech was still fun back then, not fun anymore on todays technology
17:58:39 <rdrop-exit> Back to the CHIP-8, I think compression has to be involved in some way for a Forth to payoff on such a constrained system, and that assumes the resulting speed hit would be bearable.
18:00:04 <verisimilitude> Oh, I've recently read ``Racing the Beam'' as well.
18:00:44 <verisimilitude> Instructions are two bytes under CHIP-8 and I'm planning to simply compile things to call instructions.
18:01:17 <verisimilitude> I'm mostly interested in developing directly in CHIP-8, but this is interesting in any case.
18:03:44 --- quit: tabemann (Ping timeout: 250 seconds)
18:06:18 <rdrop-exit> Please keep us up to date on your progress and the challenges you encounter. Sounds like a fascinating project.
18:08:21 <verisimilitude> Alright.
18:08:28 <rdrop-exit> Cool
18:09:13 <verisimilitude> I may not end up building much of a real Forth environment, because I'd probably get better results by just writing the instructions manually with the tool I already have.  It would still be a Forth-like stack machine, though.
18:09:33 <rdrop-exit> Understood
18:10:29 <verisimilitude> If you're interested, I can show you the tool and some of what I've already done with it.  It's oriented at machine code, not Forth, though, so it's not necessarily relevant.
18:11:08 <rdrop-exit> Sure, I'd be interested.
18:12:02 <verisimilitude> Here's the main article: http://verisimilitudes.net/2017-07-07
18:12:34 <verisimilitude> Here's an example of what I've done with it: http://verisimilitudes.net/2018-08-28
18:13:04 <rdrop-exit> The video link doesn't seem to work
18:13:26 <rdrop-exit> (on the first article)
18:13:35 <verisimilitude> It's a heavily compressed video.  You may need to download it and play it in a dedicated player.
18:14:38 <verisimilitude> I got twenty eight seconds down to a quarter of a megabyte, but the video has no key frames.
18:14:44 <rdrop-exit> It won't let me click on it, the play button is crossed out
18:15:19 <verisimilitude> That's strange.
18:15:37 <verisimilitude> Which browser are you using?
18:15:43 <rdrop-exit> Safari
18:15:59 <rdrop-exit> (on a Mac)
18:17:48 <rdrop-exit> Is it available only in certain countries?
18:17:59 <verisimilitude> I don't think Safari plays WebMs at all, does it?
18:18:22 <rdrop-exit> I don't know
18:18:54 <rdrop-exit> There's no info on the page, just a player with a crossed out play button
18:19:24 <rdrop-exit> Wait, I will try to right click and download
18:20:15 <rdrop-exit> Success, I was able to download it and view it on VLC
18:21:13 <rdrop-exit> Cool, I will read these articles offline later today
18:21:39 <verisimilitude> Feel free to tell me what you think.
18:21:50 <verisimilitude> Also, I just checked and Safari doesn't seem to support WebM, no.
18:22:02 <rdrop-exit> Will do
18:22:49 <rdrop-exit> Ok, good to know, at least I can watch them with VLC
18:23:58 <rdrop-exit> Have to walk the dogs, enjoyed the chat. Chat again soon.
18:24:26 --- quit: rdrop-exit (Quit: Lost terminal)
18:28:04 --- join: tabemann (~tabemann@2602:30a:c0d3:1890:e076:b2ce:d7a5:84d9) joined #forth
18:54:48 --- quit: dddddd (Remote host closed the connection)
19:07:35 --- quit: dave0 (Quit: dave's not here)
19:21:38 --- join: proteusguy (~proteus-g@184.82.236.176) joined #forth
19:21:38 --- mode: ChanServ set +v proteusguy
19:51:38 --- quit: verisimilitude (Remote host closed the connection)
20:00:40 --- join: gravicappa (~gravicapp@109.233.168.8) joined #forth
20:04:54 --- quit: smokeink (Remote host closed the connection)
20:05:44 --- join: verisimilitude (~user@2604:180:2:725::698a) joined #forth
20:06:38 --- join: smokeink (~smokeink@118.131.144.142) joined #forth
20:34:45 --- quit: pierpa (Ping timeout: 256 seconds)
20:52:25 --- join: lisbeths (~user@218.190.239.35.bc.googleusercontent.com) joined #forth
21:32:21 <siraben> KipIngram:  Darn.  This flash stuff is messing with my head, I need to find a good tutorial for this.
21:33:55 <siraben> My simple model would be loading the OS from a flash page to RAM, giving the user some space in RAM to define new words and so on, and edit and save one block at a time.
21:34:52 <siraben> I think that's why the original TIOS used flash for things that really were meant to be permanent (like saving variable states, flash apps too big to be saved in RAM, program data  etc.) and RAM was the working memory
21:35:05 <siraben> I hope I don't end up wearing out the flash too badly
21:48:38 --- quit: proteusguy (Ping timeout: 250 seconds)
21:50:29 --- quit: nighty- (Quit: Disappears in a puff of smoke)
22:07:56 --- join: nighty- (~nighty@s229123.ppp.asahi-net.or.jp) joined #forth
22:19:59 --- quit: smokeink (Remote host closed the connection)
22:22:01 --- join: proteusguy (~proteus-g@184.82.236.176) joined #forth
22:22:02 --- mode: ChanServ set +v proteusguy
22:37:29 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
22:40:23 --- quit: MrMobius (Ping timeout: 246 seconds)
22:40:23 --- nick: [1]MrMobius -> MrMobius
23:19:38 --- quit: dys (Ping timeout: 250 seconds)
23:59:59 --- log: ended forth/18.12.05