IRC Log - 2025-05-29 - ##forth

Channel: ##forth
Total messages: 279
Time range: 00:00:13 - 19:54:18
Most active: tpbsd (138), xentrac (108), veltas (20)
00:00:13 ##forth <veltas> tpbsd: Yeah?
00:00:41 ##forth <xentrac> but China hasn't been feudal for a surprisingly long time. Qin Shi Huang really worked hard to destroy feudalism as a threat to his dynasty
00:00:49 ##forth <anthk_> tvfm (t3xforth) from https://t3x.org it's very fun to use
00:00:49 ##forth <xentrac> he didn't realize his son was an even bigger threat
00:01:07 ##forth <tpbsd> veltas, it transposes CMSIS-SVD register labels in the Forth source for absolute addresses on it's upload to the MCU, the source isnt changed
00:01:50 ##forth <tpbsd> veltas, It does this with only a SVD file for the mcu model
00:02:25 ##forth <anthk_> this on multitasking makes POSIX and semaphores and such a bit of a hell https://www.bradrodriguez.com/papers/mtasking.html
00:03:00 ##forth <tpbsd> xentrac, which is why I dont use Chinese clones, they never have SVD files, but I embrace their development and think theyre a good thing
00:03:23 ##forth <anthk_> dumb simple compared to C89 (or maybe C99) and advanced programming under Unix Environment
00:04:20 ##forth <tpbsd> anthk_, simple is always best imho
00:04:43 ##forth <xentrac> tpbsd: what do the Chinese developers use instead?
00:05:06 ##forth <tpbsd> xentrac, nothing, they just have lots of doc
00:05:32 ##forth <tpbsd> I guess SVD is probably proprietary, tho it's just XML
00:05:49 ##forth <veltas> I thought the swd2rl.pl would be Perl, based on the extension
00:06:13 ##forth <tpbsd> I simply cannot develop anything without a SVD, as cortex-m peripherals are far too complex
00:06:22 ##forth <xentrac> prolog?
00:06:30 ##forth <veltas> Python
00:06:57 ##forth <tpbsd> veltas, it is a Perl wrapper around a C program written by Jan Bramkamp named swd2
00:07:11 ##forth <tpbsd> oops
00:07:17 ##forth <tpbsd> ignore that
00:07:40 ##forth <xentrac> anthk_: you might like einkornix
00:10:53 ##forth <tpbsd> veltas, it made a mistake, you found it! it's actually swd2rl.py a python program, it's now deleted and fixed
00:11:08 ##forth <veltas> Well no harm done because of the shebang
00:11:36 ##forth <tpbsd> yeah, just me being old and doing too many things at once
00:12:42 ##forth <tpbsd> it is a Python wrapper around a C program written by Jan Bramkamp named swd2 which adds readline command history and command completion
00:13:04 ##forth <tpbsd> it works perfectly under the neovim :terminal
00:13:30 ##forth <xentrac> anthk_: http://canonical.org/~kragen/sw/dev3/einkornix.S "simple cooperative task switching operating system for ARM EABI"
00:13:39 ##forth <tpbsd> (apart from a possible flowcontrol issue but that only affects uploads)
00:14:11 ##forth <xentrac> anthk_: example code in http://canonical.org/~kragen/sw/dev3/einkornix-test.c, interface in http://canonical.org/~kragen/sw/dev3/einkornix.h
00:14:18 ##forth <xentrac> I guess I should have linked the interface first
00:14:27 ##forth <veltas> Only the cool kids use .S files
00:14:42 ##forth <xentrac> it's a 34-instruction operating system
00:16:00 ##forth <veltas> Reminds me of Lua's coroutines
00:16:19 ##forth <xentrac> yeah, exactly, except that it maintains the list of tasks for you
00:16:43 ##forth <veltas> It's basically how I would implement threads in Forth if I had to
00:16:50 ##forth <xentrac> I also wrote a smaller version which is basically just 5 instructions, but it doesn't have APIs to create and exit processes: http://canonical.org/~kragen/sw/dev3/monokokko.S
00:16:57 ##forth <veltas> And similar to what I've seen on polyforth
00:17:00 ##forth <xentrac> and it doesn't comply with the EABI so you can't use it from C
00:18:28 ##forth <xentrac> in μονοκοκκο you have to create your circular linked list of tasks by hand, maybe at assembly time
00:19:08 ##forth <xentrac> whereas einkornix lets you create and destroy them dynamically, though reclaiming the storage they used is up to you
00:22:14 ##forth <veltas> I often use linked lists in embedded code to rely on static pre-allocation of things that needs to be in a list
00:22:20 ##forth <tpbsd> veltas, this was the start of my Plang development https://mecrisp-stellaris-folkdoc.sourceforge.io/plang-v2-stm32f051.html#plang
00:23:04 ##forth <xentrac> veltas: yes, exactly
00:23:26 ##forth <tpbsd> it's awesome to see the embedded skillset here :) this chan used to be mainly Forth on PC stuff
00:23:50 ##forth <xentrac> I don't know if I have an embedded skillset just because I like writing ARM assembly
00:24:01 ##forth <anthk_> forth it's a better form of assembly
00:24:29 ##forth <xentrac> this breadboard here is looking at me with puppy dog eyes asking when I'm going to power it back up
00:25:00 ##forth <xentrac> I feel like Forth is closer to a scripting layer for assembly than a replacement for it
00:25:17 ##forth <xentrac> like, Tcl
00:25:20 ##forth <xentrac> only, embedded
00:26:56 ##forth <tpbsd> the advantage of Forth is the ease of embedded development. the negatives are image size and it's slower than assembly when running
00:27:33 ##forth <tpbsd> unless you use ... tada https://mecrisp-across-folkdoc.sourceforge.io/index.html
00:27:42 ##forth <tpbsd> thats another of my doc sites
00:27:56 ##forth <tpbsd> Mecrisp-Across is what you get if Forth and C had a baby
00:28:41 ##forth <tpbsd> all the advantages of Forth interactive development, all the advantages of compact assembly on the target
00:29:41 ##forth <tpbsd> the downside is the speed difference between the development system (emulation) and the actual target standalone
00:30:54 ##forth <tpbsd> the dev system is currently 4x slower than the standalone target
00:30:54 ##forth <tpbsd> Mecrisp-Across is unique, there is nothing else like it in the world afaik
03:06:02 ##forth <xentrac> tpbsd: well, it's certainly true that the proof of the pudding is in the eating
03:06:35 ##forth <tpbsd> yeah, and I think it coes down to fundamental principles here
03:07:08 ##forth <tpbsd> for instance we need to measure the power going into a capacitor or coming out ?
03:07:43 ##forth <xentrac> but I don't agree that five and a half orders of magnitude is an insuperable range. delta-sigma converters can handle that kind of thing with panache
03:08:17 ##forth <tpbsd> but measuring power coming out using ADC's has a time delay and resolution issue
03:08:25 ##forth <tpbsd> panache ?
03:08:29 ##forth <xentrac> ease
03:08:40 ##forth <tpbsd> I find them noisy and slow myself
03:08:45 ##forth <xentrac> what the BQ27200, which is not a BMS, does is that it amplifies the voltage drop across an external current-sensing resistor, with an internal capacitor across it, using a delta-sigma converter
03:09:13 ##forth <xentrac> which is a kind of ADC
03:09:18 ##forth <tpbsd> sure, thats a fairly typical method, nothing new to me there
03:09:46 ##forth <tpbsd> the external current sensing resistor is a problem in itself
03:10:53 ##forth <tpbsd> Ive found any small signal processes introdule all kinds of challenges
03:10:53 ##forth <xentrac> they do, yes
03:11:04 ##forth <tpbsd> ie noise and instability
03:11:21 ##forth <xentrac> offsets
03:11:37 ##forth <xentrac> even stable offsets can be a problem, I mean
03:11:39 ##forth <tpbsd> hence my attraction to counting pulses where one pulse represents a discrete amount of energy
03:11:45 ##forth <tpbsd> yeah
03:13:43 ##forth <tpbsd> the only weak point in the design is the comparitor that controls 'topping up' the capacitor, but I think I can design that fairly well using proven noise reduction techniques etc
03:14:04 ##forth <tpbsd> and use a fact comparitor
03:14:08 ##forth <tpbsd> fast
03:14:40 ##forth <tpbsd> at least I can test it fairly well with noise and spike injection
03:15:51 ##forth <tpbsd> it's going to be a interesting project, but the first part is to build one 'power injector' where I can accurately measure tiny values of power, reliably and accurately
03:16:11 ##forth <tpbsd> if I cant do that, I cant build the rest of it and will give up
03:16:58 ##forth <tpbsd> so first stake is a calibrated 'nano power' metering psu
03:17:11 ##forth <tpbsd> step
03:20:35 ##forth <xentrac> I wonder if you can borrow an SMU to calibrate against
03:20:47 ##forth <xentrac> I mean those are off-the-shelf calibrated nano-power metering PSUs
03:21:03 ##forth <xentrac> and you live in a developed country, so there's probably one in your state
03:21:16 ##forth <xentrac> maybe you can visit a lab and use it
03:22:22 ##forth <tpbsd> I think that a static measurement of nA and volts will do well enough
03:22:37 ##forth <tpbsd> I can use my in house equipment for that
03:23:15 ##forth <xentrac> you can probably measure a 10MΩ resistor to ±2% with a commonplace multimeter
03:23:20 ##forth <tpbsd> if accuracy is a issue, then Id search farther afield, but needing a lab to calibrate it would be a hassle
03:23:25 ##forth <xentrac> that would be 500nA across a 5V supply
03:23:48 ##forth <xentrac> I was thinking you might have a friend who has a friend who has a nice Keysight SMU you can use for an afternoon
03:24:04 ##forth <xentrac> but then there's precision and there's precision
03:24:41 ##forth <tpbsd> yeah, well the principle is the important part at this point, will it work or not
03:24:50 ##forth <tpbsd> accuracy comes later
03:25:12 ##forth <xentrac> this hardware store multimeter I have here can only measure down to a microamp, and probably has an error of 10μA or so, but it can measure volts to ±0.1% and probably ohms to 2%
03:25:25 ##forth <xentrac> including up to 20MΩ
03:25:36 ##forth <xentrac> some of them only go up to 2MΩ
03:27:06 ##forth <xentrac> anyway you can trust thin-film and thick-film resistors to be damned linear all the way down to zero volts
03:27:55 ##forth <tpbsd> yeah
03:28:29 ##forth <xentrac> so generating a few hundred precisely calibrated nanoamps should be pretty easy
03:28:48 ##forth <tpbsd> any idea how I can send a ^$ with pkill to a process ?
03:28:59 ##forth <xentrac> a ^$?
03:29:01 ##forth <tpbsd> ha, in theory
03:29:04 ##forth <tpbsd> yeah
03:29:18 ##forth <xentrac> caret pesos?
03:29:40 ##forth <xentrac> I was talking to Andrew Zonenberg about this the other day and he said, why don't you try charging up a supercap and then measuring how much its voltage has been reduced after a while?
03:29:57 ##forth <xentrac> I'm not sure how much I trust supercaps
03:30:54 ##forth <tpbsd> how is andrew ? we used to talk a lot, but havent after freenode went away
03:31:12 ##forth <xentrac> yeah, but I think that's okay if the internal leakage current is low compared to the average power you're trying to measure
03:31:18 ##forth <tpbsd> hes one super capable dude, made some awesome gear
03:31:24 ##forth <tpbsd> true
03:31:25 ##forth <xentrac> what i mean is I don't know if they have like soakage or hysteresis or things like that
03:31:34 ##forth <tpbsd> but it would be useless of nanoamps
03:31:52 ##forth <xentrac> if the leakage current is picoamps then nanoamps would be easy
03:32:07 ##forth <xentrac> if the leakage current is single-digit nanoamps then hundreds of nanoamps would be easy
03:32:58 ##forth <tpbsd> I think it's in the milliamps
03:33:01 ##forth <xentrac> I had thought about trying to do this but with a C0G/NP0 capacitor. which would necessarily be much smaller
03:33:29 ##forth <tpbsd> I fel it's easier to measure the power going into rather than out of a cap
03:33:45 ##forth <xentrac> milliamps would be millivolts per second, a self-discharge time constant in the minutes. I think supercaps have a self-discharge time constant measured in months or years
03:34:12 ##forth <tpbsd> especially as a comparitor is used to tell the psu 'supply power please'
03:34:44 ##forth <tpbsd> no, the ones Ive tested discharge in hours
03:35:00 ##forth <xentrac> so microamps, which is still too much
03:35:05 ##forth <xentrac> thanks for the tip!
03:35:23 ##forth <tpbsd> the very reason theyre a supercap is responsible for their high internal discharge
03:35:37 ##forth <xentrac> how so?
03:36:04 ##forth <tpbsd> the very close 'plates' result in higher leakage
03:36:43 ##forth <tpbsd> the opposite of two air gapped plates 1 foot apart, very low internal resistance, very low capacitance
03:37:26 ##forth <xentrac> that makes some sense. but in this case there isn't an actual dielectric
03:37:39 ##forth <tpbsd> Ill be using a high quality electrolytic in my design
03:38:03 ##forth <tpbsd> something with low internal resistance
03:38:44 ##forth <xentrac> those don't have spectacularly low leakage either, do they?
03:39:11 ##forth <tpbsd> no, but as long as it's consistent, it can be calibrated out I guess
03:39:53 ##forth <tpbsd> tantalum would be best as they have very low leakage
03:40:04 ##forth <tpbsd> (when theyre not exploding)
03:40:29 ##forth <xentrac> that's nice too though
03:40:33 ##forth <tpbsd> of course polyester is the lowest leakage, but theyre low capacitance
03:41:19 ##forth <tpbsd> I think the trick is to use reliable parts that have minimal drift and just compensate for all that stuff
03:41:23 ##forth <xentrac> I think a high-voltage C0G operated at low voltage has lower leakage than polyester
03:41:47 ##forth <xentrac> and has much less thermal dependency
03:42:35 ##forth <tpbsd> Im not a expert there, I never needed much accuracy in my work, reliability was always more important fo me
03:45:33 ##forth <xentrac> I certainly am not either!
03:46:38 ##forth <tpbsd> accuracy is overated :)
03:46:57 ##forth <tpbsd> I spent years in instrumentation calibrating stuff
03:47:31 ##forth <tpbsd> using primary references
03:48:14 ##forth <xentrac> heh, too much objectivity wore you down?
03:51:10 ##forth <tpbsd> it's very boring
03:51:24 ##forth <tpbsd> I loved industrial control, lots of challenges
03:52:24 ##forth <tpbsd> I wrote the software in 1985 for my first industrial controller in machine code with a hex keypad
03:52:57 ##forth <tpbsd> that was very tiresome, when I finally got an assembler it was like christmas time!
03:54:17 ##forth <xentrac> yeah, I don't think I've ever hand-assembled anything except for CPU architectures I designed myself
03:54:58 ##forth <xentrac> although I have copied opcodes into a program and calculated jump offsets
03:55:25 ##forth <xentrac> then I figured out how to get gas to do that for me even for CPU architectures it didn't support natively and stopped doing that :)
03:56:47 ##forth <xentrac> because I was really tired of debugging miscalculated jump offsets. I kept screwing it up!
03:57:20 ##forth <tpbsd> yeah jumps were the worst as they vary in offset depending on direction
03:57:20 ##forth <tpbsd> I was always screwing up there
03:57:42 ##forth <tpbsd> it was a dual 8085 bottle filling controller, 2000 bottles a day
03:57:53 ##forth <tpbsd> worked perfectly
03:58:01 ##forth <xentrac> nice
03:58:45 ##forth <xentrac> the only machine I ever had with a hex keypad was a Heathkit H-8
03:58:56 ##forth <tpbsd> then my next project was a position controller on a 68HC11 using a SWTP 6800 dev system with assembler on 8" floppy, that was a *dream* to use
03:59:00 ##forth <xentrac> it actuallly wasn't really a hex keypad, even though it had 16 keys
03:59:05 ##forth <tpbsd> ahh
03:59:18 ##forth <xentrac> it was an octal keypad, which you might have noticed is a lot more pleasant for 8080 code
03:59:20 ##forth <tpbsd> the device I used was a 8085 SDK
03:59:46 ##forth <xentrac> I mean it was a decimal keypad but the monitor program in the ROM was an octal monitor
03:59:51 ##forth <tpbsd> it also had led 7 seg displays
03:59:58 ##forth <xentrac> same same
04:00:03 ##forth <tpbsd> Ive never used octal
04:00:05 ##forth <xentrac> except the H-8 was an 8080
04:00:17 ##forth <tpbsd> ahh, a bit older gen
04:00:18 ##forth <xentrac> oh, well, the 8080 instruction set is a *lot* more comprehensible in octal
04:00:24 ##forth <tpbsd> ok
04:00:45 ##forth <xentrac> ARM is better in hex because it has 16 registers
04:00:57 ##forth <tpbsd> hahah, that SDK8085 was interesting
04:00:58 ##forth <xentrac> and most of the instruction fields are nibble-aligned
04:01:35 ##forth <xentrac> what was great about the HC11 system? having an assembler?
04:01:44 ##forth <tpbsd> I just run Mecrisp-Stellaris on them and never mess with the cpu. Peripherals are my interest
04:02:12 ##forth <tpbsd> having an assembler for sure, but the 6800 ISA is a dream to work with
04:02:25 ##forth <tpbsd> the MSP430 is kind of similar
04:02:35 ##forth <tpbsd> bith are very different to ARM
04:02:42 ##forth <xentrac> I've heard it's nice, but my only experience with the 6800 family was on the 6809, and I was doing BASIC rather than asm
04:02:55 ##forth <xentrac> so I couldn't even tell it was 6809
04:03:08 ##forth <tpbsd> Ive never programmed for a 6809 tho I hear it was great
04:03:24 ##forth <tpbsd> they were too expensive for me and I didnt need the power
04:03:46 ##forth <tpbsd> a 6802 did all I needed
04:04:01 ##forth <tpbsd> or a 8085 tho I hate all Intel ISA
04:05:38 ##forth <xentrac> haha, Intel chips aren't very nice
04:05:46 ##forth <xentrac> the 80386 got a lot better though
04:05:47 ##forth <tpbsd> gahh! finally found my error!
04:06:15 ##forth <tpbsd> whats wrong with "pkill -QUIT ./swd2" ?
04:06:32 ##forth <tpbsd> <doh Im so dumb>
04:06:49 ##forth <tpbsd> it's the "./"
04:07:13 ##forth <xentrac> oh!
04:07:43 ##forth <xentrac> I didn't understand the ^$ part
04:07:58 ##forth <tpbsd> once swd2 has been executed in it's subdir with "./swd2" to send it a signal from anywhere else only needs the process name !
04:08:25 ##forth <tpbsd> Ill wear a dunce hat today!
04:08:50 ##forth <xentrac> I don't think I've used pkill myself
04:13:05 ##forth <tpbsd> it's used to send a signal to swd2, telling it to upload a file to the Forth mcu
04:13:12 ##forth <xentrac> right
04:13:20 ##forth <tpbsd> crest designed, evilly clever
04:13:20 ##forth <xentrac> I figured it was something like that
04:13:38 ##forth <xentrac> but you could just hit ^\ in the window where swd2 is running?
04:13:39 ##forth <tpbsd> xentrac, and the most awesome part of swd2 ?
04:14:10 ##forth <tpbsd> xentrac, you know how if you have a Forth mcu, perhaps it's blinking a led at 1000 khz ?
04:14:31 ##forth <xentrac> sure
04:14:42 ##forth <tpbsd> but you decide to insert a print statement of the loop variable just to see it in action ?
04:14:51 ##forth <tpbsd> or to debug, whatever
04:15:08 ##forth <xentrac> and suddenly it's 1 kHz?
04:15:13 ##forth <xentrac> because it's waiting on the serial port
04:15:17 ##forth <tpbsd> and it totally kills the program because of the delays the print proces causes ?
04:15:26 ##forth <tpbsd> bingo!
04:15:42 ##forth <xentrac> so what you really want is a nonblocking FIFO of log messages or something
04:15:59 ##forth <tpbsd> or ...
04:16:18 ##forth <tpbsd> to use the cortex-m DEBUG peripheral via SWD
04:16:47 ##forth <tpbsd> Crest added a 512 char buffer to the mcu and the pc term, and theyre in sync
04:17:13 ##forth <xentrac> but now you need to handle flow control ;)
04:17:22 ##forth <tpbsd> xentrac, so I can send up to 512 chars to the terminal via a print and there *is no overhead* !
04:17:26 ##forth <xentrac> because eventually that buffer gets full
04:17:43 ##forth <tpbsd> crest took care of all that stuff
04:18:34 ##forth <tpbsd> the wierd part is that a full screen of text appears, but it was over in undr micro seconds, long before the terminal printed anything
04:18:43 ##forth <xentrac> sure
04:18:55 ##forth <xentrac> I mean that happens with oscilloscopes too, right?
04:19:06 ##forth <tpbsd> yeah I guess
04:19:08 ##forth <xentrac> not so much the analog ones but the digital ones
04:19:25 ##forth <tpbsd> our human perception gets confused
04:20:00 ##forth <tpbsd> so with swdcom I can have all the prints I want and the program isnt slowed down waiting for a usart
04:20:11 ##forth <tpbsd> *debugging nirvana*
04:20:27 ##forth <xentrac> but surely you can print stuff to that buffer faster than you can read it over JTAG?
04:21:17 ##forth <tpbsd> I guess but as long as it's under 255 chars thats ok
04:21:49 ##forth <tpbsd> and it's SWD which is way faster than jtag in my experience
04:22:01 ##forth <tpbsd> tho theyre kind of the same thing
04:22:28 ##forth <tpbsd> except SWD doesnt have all the stuff that jtag has (I think)
04:23:09 ##forth <tpbsd> Segger do the same with their expensive gear, tho they make a big fuss about it
04:23:23 ##forth <tpbsd> but we get it for free with Mecrisp-Stellaris and swdcom
04:23:41 ##forth <xentrac> I guess I'm confused about the relationship between SWD and JTAG
04:23:52 ##forth <xentrac> I thought SWD was like JTAG with less pins
04:24:00 ##forth <tpbsd> I think the eyes would pop out of the heads of C GDB users if they saw this in action
04:25:15 ##forth <tpbsd> I think the distinction is swd is meant for comms and reading/writing registers, memory but jtag was also meant for testing peripherals using special proprietary stuff
04:26:42 ##forth <tpbsd> with SWD being used for development but JTAG used in production testing devices in manufacturing ?
04:34:01 ##forth <tpbsd> xentrac, I also found that neovim does do USB flowcontrol ! it works perectly with swd2, the problem comes from the python wrapper
05:12:25 ##forth <xentrac> I think you can use JTAG for a lot of things. usually it's pretty slow
05:12:45 ##forth <xentrac> that's great news! The Python wrapper was what was failing to do the flow control?
05:33:15 ##forth <tpbsd> yes, I havent looked into why, but thats the issue for sure
09:03:39 ##forth <veltas> Anyone else remember the glory days before IT departments ruled over our productivity with an iron fist?
09:11:05 ##forth <tpbsd> yeah, but that was before IT existed, back in the 70's :)
09:11:33 ##forth <tpbsd> but we had imcompetent directors to make up for it
09:14:40 ##forth <veltas> At my company we basically had an IT dept that only had time to fix our machines, and configure networks, a number of years ago
09:16:38 ##forth <tpbsd> yeah thats how they usually start
09:17:39 ##forth <veltas> And then we got a lot of corporate security rules that seemed to make more sense for a normal office than a place where we literally make and program computers from scratch
09:18:35 ##forth <veltas> It's really driven by security standards and regulation, and it's not done much good preventing e.g. our major shops from all getting pwned recently
09:18:54 ##forth <veltas> But if people are looking for national productivity sinks, there's one
09:19:50 ##forth <veltas> major shops I mean Marks & Spencers etc, not our 'workshops'
09:31:37 ##forth <tpbsd> shame
09:33:58 ##forth <veltas> xentrac: Argentina mention https://thedailywtf.com/articles/format-identified
09:34:12 ##forth <veltas> I say as if Argentina is a small village or something
12:32:48 ##forth <xentrac> veltas: I have a file with the CUIT of everybody in Argentina, as if Argentina were a small village or something
12:33:04 ##forth <xentrac> they're a matter of public record; my wife uses the file for her accounting work
12:44:49 ##forth <veltas> Nice
13:39:25 ##forth <olle> Building a simple graph database with a Forth-like interface to not have to google same thing over and over
13:41:33 ##forth <anthk_> today I tried to use emwm with Motif stuff and such, but I don't need them; cwm and some xterm it's more than enough for Forth
13:43:57 ##forth <veltas> I've said before I consider terminal harder than a GUI if you just want some text and basic interactivity
13:44:04 ##forth <veltas> Unless you literally want a REPL or something
14:02:49 ##forth <xentrac> olle: heh!
14:17:23 ##forth <olle> But I'm cheating a bit, making all word definitions in PHP :P
15:22:34 ##forth <cleobuline> xentrac: -> https://labynet.fr/xentrac.mp4
16:58:11 ##forth <xentrac> this guy can't find his keyboard
16:58:27 ##forth <xentrac> also, I think he's French, because he has cigarettes
17:34:01 ##forth <MrMobius> haha, I just spent all morning implementing s\" for my calculator forth and just realized it doesnt have a \ key
18:00:35 ##forth <xentrac> haha
19:49:17 ##forth <cleobuline> command shift /
19:50:00 ##forth <cleobuline> \`òption shift / pardon
19:51:06 ##forth <xentrac> yclept: art thou yclept yclept?
19:53:22 ##forth <yclept> seems that way, paraventure
19:54:18 ##forth * xentrac traverses the dictionary looking for an unsmudged yclept