mark4 changed the topic of #forth to: Forth Programming | do drop >in | logged by clog at http://bit.ly/91toWN backup at http://forthworks.com/forth/irc-logs/ | If you have two (or more) stacks and speak RPN then you're welcome here! | https://github.com/mark4th
f-a has quit [Read error: Connection reset by peer]
<mark4> i think there might be an ioctl to disable it
<mark4> or configure it
f-a has joined #forth
f-a has quit [Client Quit]
Zarutian_HTC has quit [Remote host closed the connection]
jedb has joined #forth
jedb has quit [Remote host closed the connection]
jedb has joined #forth
lispmacs has joined #forth
<mark4> got the menu bar listing all the pulldown menus now and i can see which items are disabled and what the current item is etc
<mark4> but the pulldowns themselves dont work yet
<mark4> i can enable and disable menu bar entries via string match
<mark4> so basically once i got the pulldown menus themselves displaying right i need to do some way to load the UI layout from a config file.... and then im basically done with this
batflu has joined #forth
<batflu> hi
<batflu> oh, i found another channel that doesn't require signup
<batflu> i can now speak in two channels
<cmtptr> what's the other one
<batflu> #freenode
<cmtptr> nice
<cmtptr> do they have anything good to say over there?
<mark4> lol
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
Zarutian_HTC has joined #forth
sts-q has quit [Ping timeout: 260 seconds]
sts-q has joined #forth
Zarutian_HTC has quit [Read error: Connection reset by peer]
Zarutian_HTC has joined #forth
Zarutian_HTC has quit [Quit: Bye]
gravicappa has joined #forth
f-a has joined #forth
<proteusguy> remexre, that inkplate-6 looks cool. Are there not already esp32 forths around? I haven't looked yet.
<remexre> proteusguy: I saw one project announcement, but didn't see a GitHub nor a mailing list, and didn't dig deeper
<remexre> (deeper includes looking beyond the first search result)
<proteusguy> What kind of cpu architecture/ISA is esp32? MIPs-like? ARM-like?
<proteusguy> Hmmm... I'm at a loss to find a good description of the ISA and it sounds like access to all the peripherals (like bluetooth) are proprietary C libs. Seems like a chip that I'd want to avoid at all costs. Maybe my google-fu is just no good today?
<nihilazo> is there a way while I'm in a running gforth application to just start a shell? Like, a word/words to temporarily kick back out to the shell that would start when you just run "gforth"? Would be useful for debugging my game because then I can just press some key and mess with stuff without having to write a debug menu
<inode> nihilazo: tried S" $SHELL" SYSTEM ?
<nihilazo> ah, yeah, that's the system shell, I mean the forth shell (maybe I don't know the proper term for that. like the REPL)
<inode> QUIT?
<inode> (without the ?)
<nihilazo> ah, that works, thanks
<proteusguy> inode, thanks... that's pretty dense stuff but likely what I need.
f-a has quit [Ping timeout: 256 seconds]
f-a has joined #forth
<proteusguy> oh it's not as bad as I thought.
<proteusguy> So it's pretty much a RISCy style ISA from what I can tell. Shouldn't be difficult to get a forth going. Would just naturally be a big one I guess it being a 32bit processor and native word size.
f-a has quit [Quit: leaving]
jedb has quit [Read error: Connection reset by peer]
jedb has joined #forth
<veltas> mark4: The OS can probably mask repeats even from a PS/2 keyboard by tracking which keys are currently up/down and ignoring down presses without an up.
<veltas> It's turtles all the way down
hosewiejacke has joined #forth
hosewiejacke has quit [Ping timeout: 240 seconds]
hosewiejacke has joined #forth
tech_exorcist has joined #forth
rprimus has quit [Quit: leaving]
rprimus has joined #forth
jedb has quit [Ping timeout: 240 seconds]
jedb has joined #forth
jedb has quit [Ping timeout: 240 seconds]
<mark4> :)
<nihilazo> OK so how do I debug a forth program lol
<mark4> inode i am writing an ESP32 assembler!
<nihilazo> is there any easier way than using gforth's debugging words, which are all basically just slightly fancier print statements lol
<nihilazo> at least as far as I've read the docs
<mark4> its almost complete i just have not done that last little bit with it, branch resolution :)
<mark4> i have two ESP32 boards here with LORA radios on them that i would love to bring up with forth
<MrMobius> nihilazo, well you cant set variable watches without variables :)
<MrMobius> i usually halt and examine thr stack
<nihilazo> something is filling the float stack with stuff but idk what
<nihilazo> I think I know roughly where it's happening?
hosewiejacke has quit [Ping timeout: 240 seconds]
<nihilazo> except I don't
<nihilazo> if I have something I've defined with "create devices 0e ,f -1 ," that has two cells, one that contains a floating point number and one that contains a fixed point number
<nihilazo> I think there's something odd in the way I'm handling tracking changes of stuff, I would post code but there's nothing more specific I can do than just post everything and say "it's in here somewhere"
dave69 has joined #forth
dave0 has quit [*.net *.split]
sts-q has quit [Ping timeout: 246 seconds]
hosewiejacke has joined #forth
sts-q has joined #forth
<inode> mark4: nice, are you going to share the sources?
<mark4> to my esp32 assembler?
dave69 has quit [Quit: dave's not here]
<inode> yes
<mark4> yea that will be published :)
<mark4> really i shud put it on github already lol
<inode> nihilazo: tried DBG under gforth-itc?
<nihilazo> that's what I'm trying now but that's not tracing the float stack which is annoying
<mark4> err actually i cant find those sources lol if i lost them it would be a PITA lol
<mark4> but sometimes a redo is better than the first time :)
<nihilazo> idk if I can get dbg to show me the float stack too
<nihilazo> (I'm doing a lot of float stuff, which is probably forth heresy, but it's the most reasonable way)
<inode> you can, but you'll need to make your own copy of the offending words from debug.fs
<inode> (or modify it in your site-forth if you don't care about keeping it entact)
<nihilazo> ok
<inode> in (_debug) you'll see a call to d.s, if you stick f.s, next to it you'll get the float stack printed as well
<inode> like s/BEGIN d.s/BEGIN d.s f.s/
<nihilazo> thanks
<mark4> ok phew found my esp32 assembler sources lol
<mark4> inode if you would like to see these not yet finished sources i can try dcc them :)
<mark4> they are still 99.999999% not even tested yet lol
<inode> i'm not even sure i have dcc support in this irc client :)
<mark4> lets try lol
<mark4> see it?
<mark4> dcc has never really been that reliable
<mark4> i could paste the entire sources in here }:)
<inode> well i see a message about connecting to an illogical socket: 0.0.0.199:0
<mark4> lol
<inode> no rush though, i'd have to find the esp32 i got in a pile of parts someone was parting with first
<mark4> ya and branch resolution is not done yet, i was working on it but at the time i was doing this i was kind of forcing myself to code
<mark4> 99% of my time was dedicated to important things like Ark Survival Evolved! lol
<inode> did you write it in forth?
<mark4> yes
<mark4> https://dpaste.com/C9J34JQ4F <-- thats my register definitions for it
<inode> cool, are you expecting the usual syntax you'd see xtensa code in or something RPNish?
<nihilazo> oh of course the assembler is written in forth :D
<mark4> i dont do RPN assemblers, they totally mess my brain up lol
<mark4> https://dpaste.com/4EDGET6TQ <-- the word asm> in this file is now i do assembler in a sane manner :)
<mark4> every nemonic starts with asm> which pulls its return address off the stack and replaces it with the return address of the previous nemonic
<mark4> xxx reg, reg
<mark4> yyy reg
<mark4> when yyy is referenceed the reg, reg on the xxx nemonic line will already have been parsed
<mark4> we return INTO xxx and complete that opcode
<mark4> forth black magic
<mark4> when yyy is parsed and executed i mean
<veltas> Yeah I don't know how people do RPN assemblers
<inode> fair enough re: brain mess, i'm playing with the idea of generating asm though inline-forth-as-a-preprocessor and relying on `operand [... operandN] mnemonic` syntax at the moment
<veltas> Assembly is hard enough already I don't want a hard-mode
<mark4> veltas: asm is trival to code once you know all the opcodes, it just requires you do everything yourself so no mommy compiler or library holding your hand :)
<mark4> but 5 # ax mov is just horrible
<mark4> mov ax, 5
<mark4> push bx
<mark4> is readable
<veltas> I know Z80 like the back of my hand, but assembly is a lot of juggling register state etc and RPN just makes that even harder
<veltas> There's only so much room in my head to write good assembly with, I don't want to use up brainpower trying to learn to write it all backwards too
<mark4> lol i have had forth jobs where i was fixing bugs in bass ackwards asm code
<mark4> i would literally have to rewrite it all out forwards, fix the bug then write it all bass ackwards for them again
<veltas> And to be fair 8-bit assembly is harder than modern assembly, which I write alongside C professionally
<mark4> well doing 16/32/64 bit operations on an 8 bit CPU is difficult, most forths for 8 bit computers are 16 bits
<mark4> but use forth extensions to give you the 32 bit stuff
<mark4> double number extensions etc
<veltas> Yeah weird shit in code throws me off and I have to 'clean' it up too as a way of understanding it
<veltas> Your code is clean in my books mark4
<mark4> its actually my #1 prime directive to keep it clean... i dont always manage that
<mark4> its a sequence of successive approximations lol
<veltas> Your code is clean but your interface stinks :P
<mark4> like my memory manager in x4/x64 is really bad code that needs to be rewritten
<veltas> It should be like the cathedral that SwiftForth is, silent but deadly
<mark4> there are things about the interface that are broken right now, it really did not stink this bad originally
<mark4> it suffering from slight bitrot atm
<mark4> has been bugging me for a cpl of years but my coding get up and go kind of got up and went lol
<veltas> I think the key is really it should just be a simple repl like anything else, not this full-terminal thing
<veltas> I liked the gforth status bar when they added it at first but I've even gone off of that, just keep it simple
<mark4> the full terminal thing is optional
<veltas> How do you turn it off
<mark4> how do you turn what off
<veltas> The full terminal stuff
<mark4> cp src/x4.f to src/x4v.f and edit out all the terminfo related sources
<mark4> and remove hello and status.f from the build too
<mark4> then change ./extend to reference x4v.f
<mark4> or you can just say statoff
<mark4> turns off the status bar
<mark4> you can add that to your ~/.x4.rcf file
<veltas> So it's optional in the sense you can patch it out :P
<veltas> It should be a switch somewhere or gone IMO
<mark4> the commented out smkx in there turns on cursor key handling
<veltas> Anyway just my opinion
<mark4> veltas lets say you write this application in forth. you develop it with the full extended forth kernel will ALL the bells and whistles that makes development easier
<mark4> but you want to create a slimmed down turnkey executable
<veltas> Respect otherwise though, if I had to use x4 I could patch it and make it suit me, I couldn't do that for gforth at all as easily despite being interactively closer to what I want
<mark4> well you can copy x4.f to somewhere, create a very very slimmed down extended forth compiler and compile your sources on top of that
<mark4> then you do ' app-main is default
<mark4> turnkey my-app
<mark4> now you have ./myapp executable with NO HEADERS and all the bloat thats in ./x4 stripped out
<veltas> Nice
<mark4> you could just edit src/x4.f and comment out everything you dont want (start at the bottom and work your way up commenting out things you dont want)
<mark4> comment out hello.f and utils.f and status.f and re-extend and see that it still works
<mark4> then comment out everythig thats inside src/ext/terminal and rebuild - if any of the extensions lower down rely on those you can comment them out too
<mark4> ./extend will puke if an extension that relies on the terminal stuff is still in there so you can find deps that way
<veltas> Yeah that is what I'd expect
<mark4> but i find having the status bar is a great help during devel
<veltas> How so?
<mark4> i can see how much list space (code space) and how much header space and how many items are on the stack without having to ask
<mark4> also, i see what the current radix is
<mark4> that number is always expressed in decimal
<mark4> so hex is shown as base 16 in the status bar
<mark4> the date code is juts eye candy lol
<mark4> and broken lol
<mark4> cuz they changed the format of the timezone files
<mark4> is Jan Engelhardt someone thats in here?
<mark4> he cloned my uCurses repo a few days ago and im kind of surprised anyone has found it at all lolk
lispmacs has quit [Remote host closed the connection]
<veltas> I cloned x64 to do some changes and then immediately diverted to other things, it's rare I follow through and actually contribute *on github*
<veltas> I do contribute but often just send patches to people directly
shmorgle has quit [Ping timeout: 264 seconds]
<mark4> ya lol
<proteusguy> mark4, are you gonna be able to talk to all these devices at a lower level than C libs for the ESP32 stuff? Definitely interested in your assembler and (presumably) forth targeted there.
<mark4> i would like to beb able to take all those low level drivers in c and stuff them all in /dev/null lol
<mark4> writing a spi/i2c/uart driver in forth/asm is trivial
<mark4> doing low level asm/forth drivers for the rest would also be doable
<mark4> i wont be putting any FFIs in there to call C stuff
f-a has joined #forth
shmorgle has joined #forth
f-a has quit [Quit: leaving]
f-a has joined #forth
<nihilazo> is there an equivalent of f. that will leave off the trailing . if there are no decimal places?
[1]MrMobius has joined #forth
MrMobius has quit [Ping timeout: 265 seconds]
[1]MrMobius is now known as MrMobius
<nihilazo> or would I have to write it
<nihilazo> also lmao gforth's implementation of ftrunc is wonderful
<nihilazo> f>d d>f
f-a has quit [Quit: leaving]
hosewiejacke has quit [Ping timeout: 240 seconds]
<crc> mark4: the uCurses repo is missing the `configure` script that `build.sh` tries to run
lispmacs[work] has joined #forth
<mark4> to get the configure script you have to do autoreconf -fiv
<mark4> then cd build and ../configure and then make
<mark4> that keeps all the .o files etc OUT of the src dir
<mark4> thats the only way you can do that with autotools it pisses me off
<mark4> there should be a OUTDIR or somethng
<mark4> OBJDIR or it should build all the obj's into /tmp or something
<mark4> poluting src is utter bs
<mark4> i was going to add all that autoreconf stuff to ./build but i am actually never using ./build now
<mark4> i just cd build and run make in there
<mark4> also, please ignore all the stuff in main.c thats not really an example of how things are going to be, im working on the key input stuff atm
<mark4> and getting frustrated with the utter inadaquicies of terminfo for input
<crc> `cc src/*.c -I./` works to build the example (with some warnings); I had to disable the call to clock_nanosleep() to build it on openbsd
<mark4> warnings are errors
<mark4> what warnings did you get and what compiler did you build it with?
<mark4> i find clang has a much better optimizer than gcc usually
<mark4> that whole main.c demo/example code is really just so i can see things working as expected
<mark4> you would not have that kind of stuff happening in an actual app using this lib :)
<mark4> wow i dont get those
<mark4> thats in format.c
[1]MrMobius has joined #forth
<mark4> part of the %{ processing if i remember correctly
<crc> parse.c not format.c
<mark4> oh ya sorry lol.
f-a has joined #forth
<mark4> format.f is what i called it in forth
<mark4> its the terminfo format string parser
<mark4> so.. parse.c works too :)
<mark4> does the code RUN in what ever terminal you are using?
MrMobius has quit [Ping timeout: 264 seconds]
[1]MrMobius is now known as MrMobius
<mark4> it does not look right in the linux terminal because many of the utf8 chars are not available there
<mark4> it also does not work great in rxvt's or some other terminals
<crc> it does run (under putty on a Windows 10 machine connected to my openbsd box)
<mark4> works great in gnome-terminal and konsole
<mark4> are there any artifacts in that console when its doing its updates?
<crc> not that I can see
<mark4> ok cool
<mark4> putty doesnt suck as bad as i thought :)
<mark4> nobody in their right mind would do that rainbow effect either lol
<mark4> not like that any way
<mark4> just testing the full 24 bit rgb display and the gray scale display there
<mark4> can you do a make scan?
<mark4> that does the clang scan-build make
<mark4> and ive been trying to figure out why the scan-build of color.c takes 20+ seconds when every other file takes 1 or 2 max
<crc> I have no makefile
<crc> no autoconf/autotools on this system
<mark4> run autoreconf -fiv
<mark4> then cd build
<mark4> then ../configure
<mark4> then make
<mark4> how come no autotools?
<mark4> !
<crc> BSD system, I've not needed it for anything thus far :)
<mark4> heh
<mark4> thats herecy to some people :)
* crc tries to avoid using the gnu bloatware
<crc> setting it up now, will advise back shortly
<mark4> cool
<mark4> it can always be purged later :)
<mark4> i do that a lot
<mark4> emerge blah
<mark4> blah foo bar bam
<mark4> emerge -c blah
<mark4> only 42k stripped. used to be less than that when i was building without autotools
<mark4> like 8k less lol
<mark4> btw, space pauses the app and enter quits
<mark4> i shud really specify that somewhere lol
<crc> ./build.sh[3]: ../confiure: not found
<mark4> from outside the ./build dir you need to run autoregen -fiv
<mark4> that creates the ./configure
<mark4> which you run from inside the build dir and that creates the makefile
<mark4> dont use ./build heh
<mark4> its kind of incomplete
<mark4> cd uCureses && autoreconf -fiv && cd build && make
<mark4> erm no after cd build you do ../configure
<mark4> mkdir build
<mark4> make
<mark4> autoreconf -fiv
<mark4> ../confiure
<mark4> cd build
<mark4> would be a working ./build.sh
<crc> after this, I needed to edit the Makefile to change -std=gnu17 to -std=c99 and now the build fails on the warnings in parse.c
<mark4> change them to use %lu
<mark4> n2 = snprintf(s, 3, "%lu", n1);
<mark4> that worked for me
<mark4> but i never got those warnings you were getting before
<mark4> i think -wall -werror should be universally enforced 100% of the time and not bypassable :)
<crc> %llu worked for me, but the demo built this way is completely broken
<mark4> yea llu is not right
<mark4> i use llu and it gives me warnings
<crc> with lu I get:
<crc> ../src/parse.c:562: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'uint64_t'
<mark4> error: format ‘%llu’ expects argument of type ‘long long unsigned int’, but argument 4 has type ‘uint64_t’ {aka ‘long unsigned int’} [-Werror=format=]
<mark4> your uint64_t def is not the same as the linux one!
<mark4> uint64_t in linux IS a long unsigned int
<mark4> cast the uint64_t's to (long unsigned int) for the printf
<mark4> ugly lol
<mark4> n2 = snprintf(s, 3, "%lu", (long unsigned int) n1);
<mark4> etc etc
<mark4> i think that your bsd has a broken definition for uint64_t
<crc> uint64_t is an 'unsigned long long'
<mark4> not in linux
<mark4> in linux ists an unsigned long int
<mark4> oh!
<mark4> are you on a 32 bit system?
<mark4> that might be the problem :)
<mark4> the problem is a uint64_t is a unsigned long int on a 64 bit system and an unsigned long long on a 32 bit system :)
<mark4> maybe i mean
<crc> no, 64-bit
<mark4> ok then someone is defining uint64_t wrong
<mark4> they should not be defined differently and obviously they are
<mark4> can you cast them to unsigned long ints as above?
<crc> the wikipedia entry https://en.wikipedia.org/wiki/C_data_types lists `long long` for 64-bit, which matches what I've generally seen in my work with C
gravicappa has quit [Ping timeout: 240 seconds]
<crc> your casting there fixes the build, but the demo still fails to work correctly :(
<mark4> whats it doing?
gravicappa has joined #forth
<mark4> instead of doing the cast change the declaration of n1 to unsigned long int?
<mark4> and leave then as %ld
<mark4> also, replace that ENTIRE switch statement with this one liner lol
<mark4> n2 = snprintf(s, digits + 3, "%ld", n1);
<mark4> and that just leaves ONE switch statement (well with nested switch statemetns actually) to purge with extreme prejudice from these sources :)
<mark4> num_esc += snprintf(&esc_buff[num_esc], digits + 3, "%ld", n1); moar optimizashunz plzkthxbai
hosewiejacke has joined #forth
<mark4> though really im not a fan of snprintf either, i should code this trivial thing by hand
<crc> num_esc += snprintf(&esc_buff[num_esc], digits + 3, "%ld", (unsigned long)fs_pop()); /* get rid of the variable */
<mark4> no that i prefer not to do, statements like that are actually harder to read
<mark4> and also harder to optimize sometimes too
<mark4> i dont like to bury function calls inside function calls lol
<mark4> tho.. i have been known to when being lazy
<crc> I prefer not using variables in most cases
<mark4> the optimizer will put that in a reg usually
<mark4> fs_push(utf8_strlen(s)); <-- lol me being lazy
* crc dislikes the optimizer... it breaks my mental model of my code as it relates to the generated assembly
<mark4> also, having the variable there makes the code more descriptive too if you give the variable a good name which i rarely do :)
<mark4> well with C you can set optimizations to -Og to make debug easier
<mark4> and then to -Os/3 for production
<mark4> did the code work after that change
<mark4> ?
<crc> yes
<mark4> cool
<mark4> and you can make scan and get no bugs?
Zarutian_HTC has joined #forth
<crc> no `scan-build` in openbsd base, and I don't have enough space to install llvm on this box
<mark4> aha
<mark4> ok nvm that then :)
<crc> mark4: when I deploy a new install I'll setup a bigger disk and let you know how it goes, won't be for a while though
<mark4> thats ok, i have a lot to figure out yet, like maybe i have to hard code the key escape sequences for all terminals for shift cursor up, shift cursor down, shift home, shift end...
<mark4> and you can use any combination of control shift and alt on any key and get different key sequences for each and every terminal will give different results
<mark4> which is dumb
<mark4> contorl X, shit control X, alt control X, shift alt control X... all different sequences returned
<mark4> all different sequences returned on all possible terminals.... MAYBE
hosewiejacke has quit [Remote host closed the connection]
<crc> I'm happy I can avoid all of that
<mark4> :)
<mark4> just link to libncurses
<crc> no, i just don't build tui's
<mark4> :)
<mark4> so, biden trips up 3 times walking up the stairs of af1. i think it might well actually be president harris soon
<mark4> just a guess
f-a has quit [Ping timeout: 246 seconds]
f-a has joined #forth
gravicappa has quit [Ping timeout: 264 seconds]
f-a has quit [Quit: leaving]
jess is now known as JESS
<cmtptr> meh, they'll keep up the charade for as long as possible
<cmtptr> but what do i know? every time i think "they won't do that, the optics would be too bad", they always surprise me
<mark4> lol
<mark4> he might be a senile old goat but i think his voter base is even more so
JESS is now known as jess
<Zarutian_HTC> I think that Democrat eleet thrusting Hillary in front of Bernie got many younger peeps disinterested in politics
<Zarutian_HTC> and I say that as an Icelander with no or little interst in USA politics
<mark4> :)
<cmtptr> too concerned about the volcano brewing under your feet to pay attention to US drama?
<Zarutian_HTC> cmtptr: no and besides it seems to be simmering down
<cmtptr> famous last words
<mark4> hope not lol. we cant afford to lose forth coders :)
<Zarutian_HTC> nope, the geologist on the news this evening said that the propability of an erruption has gone down considerably
<Zarutian_HTC> sat imagery using diff images between images taken at diffrent times show that the rate of rising has fallen to negative
<Zarutian_HTC> tremour soundings seem to indicate that the lava in the lava tube there has started to solidify
<Zarutian_HTC> and rate of small quakes in the area has dropped down to pre event levels
<cmtptr> if it did erupt do you think your country would change its name to lavaland
<inode> or thawland?
<Zarutian_HTC> if there is an erruption going to happen at this area then it is most likely going to be a lava flow erruption
<Zarutian_HTC> not an explosive ash cloud erruption like Eyjafjallajökull was
<Zarutian_HTC> cmtptr: no
<Zarutian_HTC> inode: and definitly no
<Zarutian_HTC> no, the insight into USA politics is mainly due to one guy I know loosely in Utanríkisráðuneytinu (the ministry of foreign affares)
<patrickg> inode: Iceland is green, Greenland is icy - but it got the annoying folks to move over there from Iceland, so the marketing worked. As a result I don't expect names to reflect reality there, ever ;-)
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
<Zarutian_HTC> cmtptr: are you perchance a precog? it seems that erruption has started
<mark4> keep off the glowing grass :)
<mark4> you see it? or feel it? or news telling you about it?
<Zarutian_HTC> banner alert on rúv telly station channel
<inode> patrickg: was vinland also based on a false promise?
Zarutian_HTC1 has joined #forth
* Zarutian_HTC1 hates this wifi instability
Zarutian_HTC has quit [Read error: No route to host]
Zarutian_HTC1 is now known as Zarutian_HTC
<Zarutian_HTC> here is a news item with a webcam capture https://www.ruv.is/frett/2021/03/18/helstu-tidindi-eldgos-hafid-i-fagradalsfjalli
Zarutian_HTC has quit [Remote host closed the connection]
Zarutian_HTC has joined #forth
Zarutian_HTC1 has joined #forth
<Zarutian_HTC1> looks like a small one
Zarutian_HTC has quit [Read error: Connection reset by peer]
rixard has quit []
* Zarutian_HTC1 watches https://m.youtube.com/watch?v=_AdBcTMHG0Q and disagrees
Zarutian_HTC1 is now known as Zarutian_HTC
<Zarutian_HTC> failed a lot, were expensive even though the electronic ballast was cheap shit, took forever to get to useable brightness
<Zarutian_HTC> and their sound was irritating as hell
<Zarutian_HTC> low volume high frequency hiss
<Zarutian_HTC> and do not get me started on how bad the light spectra (not temperture _specta_) these things had
rixard has joined #forth