00:00:00 --- log: started forth/19.04.24
00:50:53 --- quit: rdrop-exit (Quit: Lost terminal)
01:28:02 <WilhelmVonWeiner> problem is nobody is prepared to write space-level Forth anymore
01:28:43 <WilhelmVonWeiner> the tooling for safe javascript and thisscript and thatscript would far outweigh the existing Forth equivalent
02:04:13 --- quit: ashirase (Ping timeout: 250 seconds)
02:07:24 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth
02:20:23 --- join: rain1 (~My_user_n@unaffiliated/rain1) joined #forth
02:21:31 --- quit: rain2 (Ping timeout: 255 seconds)
04:16:34 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
04:37:42 --- join: dave0 (~dave0@108.060.dsl.syd.iprimus.net.au) joined #forth
04:37:59 <dave0> hi
05:40:01 --- join: dys (~dys@tmo-112-127.customers.d1-online.com) joined #forth
06:23:12 <proteusguy> there is no such thing as "safe javascript" and most space-flight software for long term high reliability is still in forth.
06:29:51 <Zarutian> Forth or a variant of Ada
06:32:17 <Zarutian> proteusguy: can you expand on why javascript couldnt be safe?
06:34:21 <proteusguy> To be truly "safe" you either have to prove the safety by having a strong algebraic type system (ala haskell, Ada,C++) or be so simple that there's nothing complex to break (ala FORTH). Javascript is not and can not be either of those. As complexity increases linearly the opportunities for defects and exploits increase geometrically. 
06:35:09 <WilhelmVonWeiner> Wonder how it'd be writing a static analyser for yer Forth 
06:36:42 <proteusguy> Not difficult up to a point... but there's too many opportunities for things to get hairy with pointers and math on pointers.
06:37:01 <proteusguy> I'm designing a strongly typed forth-like language meant to address these specific concerns.
06:38:50 <WilhelmVonWeiner> ActorForth, right?
06:39:03 <Zarutian> sorry, C++ does not have strong static algebraic type system.
06:39:22 <WilhelmVonWeiner> release some docs so I can immerse myself in new forth knowledge
06:39:48 <proteusguy> WilhelmVonWeiner, yes. I will once I have something I can release publicly.
06:40:29 <proteusguy> Zarutian, what's your basis for that claim. The C++ type system + it's template language makes for an incredibly strong type system that can work in a declarative manner.
06:41:55 <Zarutian> proteusguy: implict casting and no defense against unbounded pointer arithmetic
06:42:42 <Zarutian> plus issues of cross package friendly classes.
06:44:49 <proteusguy> Zarutian, you don't have to use every feature of C++ to be a real C++ app. In my own apps we never use built in types except in the scope of a typedef or construction of a more formal type. Naturally that means no regular pointers. You follow those procedures and your code is guaranteed to perform correctly without runtime errors.
06:45:16 --- quit: dys (Ping timeout: 246 seconds)
06:47:30 <Zarutian> proteusguy: "you don't have to use every feature of C++ to be a real C++ app" means that various things cannot be made inexpressible in it. Things that are error prone and causes confusion.
06:48:02 <proteusguy> yeah you can't lock down C++ but you can check and see if your code complies with the rules or not and only accept code which does.
06:48:36 <proteusguy> If you're trying to say C++ isn't haskell or elm then correct. That DOES NOT mean you can't construct an algebraic type system with it.
06:48:39 <Zarutian> having to follow procedures while programming OR having to write code compliance checker is often an extra hassle most software houses dont do.
06:49:10 <Zarutian> I can construct an algebraic type system in any decent macro assembler
06:49:33 <Zarutian> it is like a Turing tarpit in that sense
06:49:35 <proteusguy> Funny - it's an extremely easy and simple habit to adopt. Been doing it since the early 90s and all my dev teams have as well. Never once deployed code that had a memory leak - ever.
06:50:18 <proteusguy> C++ has language features that can provable enforce it. That's the point.
06:50:54 <Zarutian> but it did have logic and unit errors out of the wazoo?
06:51:36 <proteusguy> ....I don't think you're really interested in helping the discussion other than being pedantic. No - not full of logic and unit errors either.
06:51:57 <Zarutian> I have yet to find a way to do an simple Ada type in C++. An unit type of say centimeters length.
06:52:43 <proteusguy> Absolutely doable. Not quite as simple as Ada to create. But, once created, just as easy to utilize.
06:54:06 <proteusguy> Actually with the new "concepts" and constraints additions to the C++ standard this gets even easier and stronger.
06:55:37 <Zarutian> and how long until that standard is fully implemented by compiler writers?
06:57:08 <proteusguy> I believe llvm already has an implementation available. or else the latest g++ - I forget which. My biz partner has used them in one of the compilers.
06:59:15 <Zarutian> hmm.. so I can expect to see these features in at least decade or so in certified compilers for high reliability embedded systems.
07:00:18 --- part: PoppaVic left #forth
07:00:18 <Zarutian> C++ might be usable for desktop or mobile phone applications but not high reliability embedded systems like satelites, avionics or implantables.
07:01:18 <proteusguy> C++ already is and has been for some time.
07:01:51 <WilhelmVonWeiner> wouldn't be surprised if Boeing's crashing planes were C++ 
07:01:53 <WilhelmVonWeiner> ;)
07:01:55 <proteusguy> But it's not always my goto language for such things.
07:01:55 <WilhelmVonWeiner> jk
07:02:25 <proteusguy> Boeing's issues are completely orthogonal to technology choice. That was absolutely bad architecture.
07:03:43 <Zarutian> yebb, because the bigger jetengines and lower ground clearence those planes had tendency to rise their nose up too much
07:05:43 * Zarutian recently watched an yt video on it by an airplane engineer.
07:05:51 <proteusguy> I meant the computer sensor/control system architecture. But yeah - that's what drove the adoption of this mess.
07:06:29 --- quit: dave0 (Quit: dave's not here)
07:07:49 <Zarutian> my point regarding C++ is that too much programmer vigilance is required if it is used.
07:08:29 <Zarutian> vigilance that gets easily by passed or worn away by management- or time-pressure.
07:09:25 <proteusguy> Zarutian, hasn't been my experience but I guess I could see how such a thing could happen (perhaps if you were in a Accenture run project!). So what is your recommended alternative?
07:09:26 <WilhelmVonWeiner> speaking of time pressure something I was told recently is to never eat at my desk and work during lunch
07:09:40 <WilhelmVonWeiner> that's working 5 hours a week for free
07:10:24 <MrMobius> depends on if your on salary
07:10:34 <MrMobius> and have to finish the work no matter how long it takes you
07:10:34 <WilhelmVonWeiner> oh true
07:11:01 <zy]x[yz> i leave an hour earlier if i eat at my desk, which is most days
07:11:12 <Zarutian> proteusguy: for embedded systems, Ada if it must be statically checked. An variant of Forth that is heavily tested at each eeprom burn.
07:11:20 <zy]x[yz> or to say it differently, on the days i go out for lunch i work an hour later (or pretend to)
07:11:39 <WilhelmVonWeiner> i would get kicked right up the arse for that
07:11:44 <Zarutian> proteusguy: for desktopy things, ecmascript or Tcl/Ttk
07:11:51 <WilhelmVonWeiner> lol "(or pretend to)"
07:11:56 <zy]x[yz> weird
07:12:52 <WilhelmVonWeiner> I was hired as a software engineer, they have me configuring RADIUS servers... lame
07:12:55 <Zarutian> proteusguy: for game logic Lua or Scheme (while the rendering engine might be in something else and never changes)
07:12:55 <proteusguy> Zarutian, I could never recommend Ada seriously for any serious project. Horrible syntax and developer overhead. You don't really enjoy that language do you?
07:13:55 <MrMobius> Zarutian, so the claim is that you get less memory leaks or are less likely to get memory leaks in Forth than C++ for embedded?
07:13:56 <Zarutian> well, its syntax is a variant of the terrible Algol family but then again is C++.
07:14:23 <WilhelmVonWeiner> MrMobius: in Ada than C++, I think is his point
07:15:22 <Zarutian> MrMobius: memory leaks are just one small part of the issues. More pressing are edge cases in the logic and datum unti conversion implict casting.
07:17:22 <Zarutian> MrMobius: in Forth on say on AVR, you know where each datum and or allocation goes down to the machine instruction. In C++ it is harder to anticipate what the compiler does.
07:18:38 <MrMobius> why does that matter?
07:19:13 <proteusguy> C++ compilers may be harder to anticipate than FORTH, but it's probably about 3rd in line after ASM, FORTH, C++/C. I've written incredibly tight C++ embedded systems and had complete control of what I needed.
07:19:29 <Zarutian> plus, if an entire Forth lives on the embedded device, (Doable nowdays as they got enough program memory), you can heavy easy interactive debuggable interface via serial
07:20:22 <proteusguy> Forth is great at such things to be sure!
07:20:37 <Zarutian> MrMobius: it matters as each compilation you make to test new added functionality should only change in code in that functionality
07:21:16 <Zarutian> and beside, most C and C++ compilers for embedded systems other than ARM are quite terrible.
07:23:09 <Zarutian> proteusguy: what kind of embedded systems? audio visual entertainment? high speed robotics and such automation? house control systems?
07:23:38 <proteusguy> usually industrial control systems.
07:23:47 <MrMobius> Zarutian, I thought maybe you meant "what the compiler does" to mean what assembly it generates. why does it matter if it generates totally different assembly after a minor change? it could be smaller or faster. all that should matter is that it does exactly what you tell it too. or did you mean you care about cycle timing or something?
07:25:36 <Zarutian> MrMobius: because most often the assembly for the same functionality should not change. Often it gets bigger and or slower or smaller (okaish) and faster (not okay if strict timing is required).
07:26:07 <Zarutian> MrMobius: so part of it is cycle timing, another is eeprom image continous certification
07:26:52 <Zarutian> proteusguy: oh, I have assembled and wired such control cabinets.
07:28:01 <Zarutian> proteusguy: Siemens make nifty DIN mountable control-computer with various voltage level inputs and outputs.
07:28:46 <Zarutian> proteusguy: they used to be programmed in ladder logic (the fucking horror, I am having flashbacks) so C++ might be a slight improvement.
07:29:52 <Zarutian> proteusguy: for what kind of applications though? Control of food processing lines? Industrial process control such as silicon smelting?
07:31:45 <proteusguy> a lot of warehouse automation. 145ft long sorting machines for inbound and outbound processing. on device controllers as well as integration with the rest of the WMS.
07:32:04 <proteusguy> yep - I replaced a lot of ladder logic stuff.
07:33:44 --- quit: tabemann (Ping timeout: 276 seconds)
07:35:40 <Zarutian> so basically soft-soft realtime stuff. Nothing that is as the avionics guys call "computer final authority" stuff.
07:37:18 <Zarutian> (meaning there are safety cut outs based on relays)
07:38:51 <proteusguy> Actually the machine could literally eat you so actually it does have some hard real-time controls. But nothing requiring quicker than 8ms timing.
07:39:07 <proteusguy> But naturally the stop buttons don't depend on a computer to go safe.
08:57:07 --- join: X-Scale` (~ARM@46.50.0.2) joined #forth
08:58:52 --- quit: X-Scale (Ping timeout: 255 seconds)
08:58:52 --- nick: X-Scale` -> X-Scale
10:54:54 --- join: dys (~dys@tmo-111-40.customers.d1-online.com) joined #forth
12:13:57 --- quit: gravicappa (Ping timeout: 258 seconds)
13:41:15 --- join: cnidario (~aaa@92.57.58.87) joined #forth
13:42:41 <cnidario> hello, anyone can recommend me a forth implementation with very small footprint in standard C (1K -4K of RAM?)
13:44:12 --- quit: the_cuckoo (Quit: WeeChat 1.4)
13:48:08 --- quit: pierpal (Ping timeout: 276 seconds)
13:49:18 --- join: the_cuckoo (~charlie@d51A50AE9.access.telenet.be) joined #forth
13:54:55 --- quit: cnidario (Read error: Connection reset by peer)
13:58:44 --- join: cnidario (~aaa@92.57.58.87) joined #forth
14:01:19 --- quit: cnidario (Read error: Connection reset by peer)
14:02:47 --- join: cnidario (~aaa@92.57.58.87) joined #forth
14:10:02 --- quit: cnidario (Read error: Connection reset by peer)
14:11:17 --- join: cnidario (~aaa@92.57.58.87) joined #forth
14:16:02 --- quit: cnidario (Read error: Connection reset by peer)
14:28:38 <WilhelmVonWeiner> sk3ngm4n
14:28:45 <WilhelmVonWeiner> fuuuuuuuuu
14:28:58 <WilhelmVonWeiner> moving to a new wm and copying over all my configs
14:30:17 <WilhelmVonWeiner> just ssh'ing into my boxes with `password-prohibit no` and this new wm is messing with me
14:33:20 <WilhelmVonWeiner> speaking of copying over, I found a bunch of Forth I'd written when I'd started learning
14:33:29 <WilhelmVonWeiner> probably just over a year ago
14:33:36 <WilhelmVonWeiner> jesus christ 
15:04:12 <WilhelmVonWeiner> implicit state, the stack - what a lifesaver
15:04:23 <WilhelmVonWeiner> so much of this old Forth I have variables everywhere 
15:41:54 --- join: rdrop-exit (~markwilli@112.201.166.63) joined #forth
15:45:26 <rdrop-exit> Hello Forth connoisseurs
15:54:51 <WilhelmVonWeiner> ;q
15:55:03 <WilhelmVonWeiner> sorry my terms again, hey rdrop-exit 
15:55:21 <rdrop-exit> Hi WilhelmVonW
15:55:43 <WilhelmVonWeiner> what's good?
15:56:54 <john_cephalopoda> Hmm, I have to try to rewrite my mandelbrot stuff for fixed-point.
15:56:56 --- join: pierpal (~pierpal@host197-221-static.34-79-b.business.telecomitalia.it) joined #forth
15:56:59 <rdrop-exit> Espresso first thing in the morning c[_]
16:00:33 --- quit: WilhelmVonWeiner (Quit: leaving)
16:01:22 --- join: WilhelmVonWeiner (dch@ny1.hashbang.sh) joined #forth
16:01:38 <rdrop-exit> wb
16:02:14 <WilhelmVonWeiner> changing terminal colours
16:02:18 <WilhelmVonWeiner> white background now
16:02:30 <WilhelmVonWeiner> bigger font, maybe not big enough though
16:02:50 <rdrop-exit> white background gives me a headache
16:04:06 <WilhelmVonWeiner> I have read it's better for the eyes
16:04:17 <WilhelmVonWeiner> counter-intuitively
16:06:10 <rdrop-exit> could be, my eyes are shot
16:06:20 <WilhelmVonWeiner> speaking of eyes mine hurt from a long, long day... i'm going to bed
16:06:40 <WilhelmVonWeiner> going to need glasses soon...
16:06:53 <WilhelmVonWeiner> might double my font size for good measure
16:06:58 <rdrop-exit> I have three pairs, near, middle, far
16:07:23 <jn__> bigger font -> more pressure to write compact code
16:08:05 <rdrop-exit> My terminal is always 80x24
16:08:13 <WilhelmVonWeiner> 90% of the time i only ever have 24 lines on the screen at once anyway
16:08:32 --- quit: john_cephalopoda (Ping timeout: 276 seconds)
16:08:36 <jn__> fair. i'm not used to true non-fullscreen windows
16:11:14 <WilhelmVonWeiner> anyway night forthers have a good one
16:11:39 <rdrop-exit> G'night WilhelmVonW
16:13:24 --- join: dave0 (~dave0@108.060.dsl.syd.iprimus.net.au) joined #forth
16:15:28 <dave0> hi
16:15:44 <rdrop-exit> Hi dave0
16:15:51 --- quit: pierpal (Read error: Connection reset by peer)
16:15:57 <dave0> hi rdrop-exit 
16:21:47 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth
16:40:15 --- join: PoppaVic (~PoppaVic@unaffiliated/poppavic) joined #forth
18:01:08 --- join: tabemann (~tabemann@h193.235.138.40.static.ip.windstream.net) joined #forth
18:23:39 --- join: mark4 (~mark4@12.41.103.244) joined #forth
18:35:31 <tabemann> hey
18:37:40 <dave0> hi tabemann 
18:37:52 <rdrop-exit> Hi tabemann
18:38:45 <tabemann> hey guys
18:40:25 <tabemann> drawing rectangles efficiently in sixels is a pain
18:41:10 <tabemann> (because the rectangles may have starting and ending y not divisible by 6)
18:41:47 <tabemann> I could draw them pixel by pixel, but that'd be gawd-awfully inefficient
18:42:25 <rdrop-exit> Why would it be inefficient?
18:43:27 <dave0> filled rectangles?
18:44:16 <tabemann> rdrop-exit, because I'd have to calculate the addresses for each pixel separately
18:45:05 <tabemann> dave0: yes
18:45:50 <tabemann> drawing a horizontal line is more efficient because the addresses just need to be incremented for each color in each horizontal line
18:46:07 <rdrop-exit> If you're doing vectors then shouldn't you being using ReGIS instead of Sixels
18:46:22 <tabemann> and drawing sixe horizontal lines at a time is even more efficient, because I can draw six lines at a time
18:46:34 <tabemann> I'm trying to draw sprites'
18:46:46 <tabemann> *six horizontal lines
18:47:28 <dave0> usually you have a draw-horizontal-line which is very fast, and loop over the y coordinate calling draw-horizontal-line
18:47:29 --- quit: dys (Ping timeout: 245 seconds)
18:47:48 <mark4> just bought a used nintendo 3ds from ebay and its in absolutely pristine condition and i think it had dual ips display!
18:47:58 <rdrop-exit> But you shouldn't be drawing directly in Sixels
18:48:03 <mark4> and it has $9.50 in credit in the eshop lol
18:48:26 <tabemann> dave0: yes
18:49:06 <dave0> tabemann: X-windows does it that way
18:49:17 <tabemann> rdrop-exit, my framebuffer is all sixels, and the drawing routines directly write to the sixels - it is faster than having a framebuffer, and converting that framebuffer to sixels for each frame
18:50:14 <tabemann> the advantage is that I can write the whole framebuffer to standard output without even copying it
18:51:26 <rdrop-exit> Then that will be your bottleneck, you'll be sending a screenfull of sixels each time
18:51:54 <rdrop-exit> I would only send a delta
18:52:47 <tabemann> that would require calculating a delta
18:53:18 <mark4> i dont think calculating a delta would be that expensive
18:53:22 <rdrop-exit> Sure, but calculating is cheaper than communicating
18:54:00 <mark4> also, is a sixel a 6 by 6 grid of identical pixel colors?
18:54:06 <rdrop-exit> Orders of magnitute cheaper
18:54:09 <tabemann> the whole framebuffer is written in a single write()
18:54:16 <mark4> only need to diff one pixel 
18:54:30 <tabemann> if it were a write() for each sixel, I could see how that'd be slow
18:55:27 <rdrop-exit> Plus you're tying you're hardcoding you're drawing layer to the sixel back-end
18:55:38 <rdrop-exit> * your drawing layer
18:55:54 <dave0> if a row is the same as in the last frame, you could skip sending that row
18:56:29 <ttmrichter> mark4: A sixel is much cooler than that.
18:56:30 <rdrop-exit> How many bytes is your framebuffer?
18:56:39 <ttmrichter> It's an ASCII character!
18:56:46 <mark4> oh?
18:56:47 <rdrop-exit> I know
18:56:52 <tabemann> rdrop-exit: depends on how large
18:57:10 <rdrop-exit> Currently?
18:57:50 <mark4> so i have a curses like library in forth that does optimized console updates, i have a 3d rotating dots demo and i get over 4000 fps
18:57:52 <tabemann> it all depends on how large the images you're displaying are
18:57:58 <mark4> why would sixel's be slow?
18:58:34 <tabemann> my problem is that hashforth is slow - I measured how fast a tight counted loop is in hashforth versus one in python and it was like half as fast as that in python
18:58:49 <mark4> i can launch xterm and set the font to display characters this big  .  <--
18:58:52 <ttmrichter> mark4: A sixel is a set of six pixels, one wide.  So 64 possible combinations off/on.  These are mapped into ASCII characters so you send ASCII to encode an image.
18:59:17 <mark4> and STILL get very high frame rates
18:59:26 <tabemann> note that you can also display different colors by CRing multiple times between LFs
19:00:07 <ttmrichter> Yep.  They're a really cool little trick.
19:01:48 <rdrop-exit> My point is that since this is terminal based the bottleneck for your framerate is ultimately the communication overhead.
19:02:47 <ttmrichter> Yeah, I'm with rdrop-exit here.
19:03:05 <ttmrichter> Calculating differentials is far quicker than even blasting out a single line of I/O on a terminal.
19:03:29 <dave0> tabemann: does it have a jpeg viewer?
19:04:19 <tabemann> does what have a JPEG viewer?
19:04:24 <rdrop-exit> What I would do is make my drawing routines independent of sixels, the sixel dependent code would be in the delta production.
19:04:41 <dave0> tabemann: a proram for your library?
19:04:50 <tabemann> no
19:05:04 <dave0> make one! lol
19:06:20 <rdrop-exit> Another option is that if you want scalable vector drawing on a terminal use ReGIS instead of Sixels.
19:07:18 <rdrop-exit> DEC had Sixels for raster, ReGIS for vectors
19:07:51 <rdrop-exit> https://en.wikipedia.org/wiki/ReGIS
19:12:04 <rdrop-exit> Drawing your filled rectange in ReGIS would be trivial with ReGIS
19:12:10 <rdrop-exit> * rectangle
19:12:42 <rdrop-exit> Sorry about the redundancy in my sentence :)
19:12:49 <rdrop-exit> Need more coffee
19:17:32 <tabemann> the thing about making the code as agnostic as possible is that it's much more efficient to do things six pixels at a time
19:17:43 <tabemann> like those horizontal lines
19:17:54 --- quit: dddddd (Remote host closed the connection)
19:20:17 <rdrop-exit> The efficiency that counts here is reducing the communications overhead, only sending the commands that are needed to transform the last frame to the new frame in one burst.
19:22:08 <rdrop-exit> It'll never be efficient if you're sending out all the commands required to paint the entire screen from scratch.
19:22:41 <rdrop-exit> Successive frames don't change that much.
19:24:34 <rdrop-exit> At least on average.
19:25:35 <rdrop-exit> Think video.
19:31:15 <tabemann> the thing is that I don't envision this data ever going over a serial line, for sixels at least
19:36:29 <tabemann> rather the data is being blitted twice - once going into kernel space - and once going into xterm's or mlterm's memory space
19:37:10 <tabemann> which is much, much faster than going over a typical serial line hooked up to a physical terminal
19:38:00 <tabemann> whereas doing a comparison is going to be slow because, well, hashforth is slow
19:49:38 --- join: mark4_ (~mark4@172.58.7.49) joined #forth
19:53:24 <rdrop-exit> Measure twice, cut once.
19:53:37 --- quit: mark4 (Ping timeout: 255 seconds)
19:54:04 <PoppaVic> you were NOT around when we built the house ;-)
19:54:15 <rdrop-exit> :-))
19:55:45 <mark4_> if you knew how to measure you would only need to do it once :P
19:56:06 <PoppaVic> mark4_: I was just the son that ran the radial-arm saw ;-P
19:56:32 <mark4_> i.e. if you cut on their line and their line was in the wrong place it was their fault
19:57:06 <rdrop-exit> Gotta walk the dogs, catch you all later
19:57:13 --- quit: rdrop-exit (Quit: Lost terminal)
19:57:30 <PoppaVic> ..about 4 times, #2 lugs over a 2x4: "Dad sez take a 1/2 inch off." OK.. About #5 I holler over there: "Dad, I been cutting these <whatever> Just like I am supposed to do - WTF?"
19:57:55 <ttmrichter> Huh.  I'd never seen ReGIS before.
19:58:04 <ttmrichter> Sadly not a lot of terminal emulators support it.
19:58:05 <PoppaVic> ..he hollers back: "Look, they are too goddamned short!" <dead silence>
19:59:02 <PoppaVic> mark4_: We'd been at it all damned day, and apparently his brain went into reverse: ..{This is too short, cut another 1.2 inch off}
19:59:35 <mark4_> lol
20:00:00 <PoppaVic> #2son and I unplugged and covered all the hw, lifted the old man up and poured him into the damned honda: "That's it, we quit - dinner."
20:00:25 <PoppaVic> Fucking "Learning Experiences".
20:01:10 --- quit: tabemann (Ping timeout: 246 seconds)
20:03:27 --- join: gravicappa (~gravicapp@h109-187-32-71.dyn.bashtel.ru) joined #forth
20:12:08 --- join: groovy2shoes (~groovy2sh@unaffiliated/groovebot) joined #forth
20:18:03 <ttmrichter> Is this the time to Muntz it?
20:27:17 --- join: tabemann (~tabemann@2600:1700:7990:24e0:5ca5:9a72:d11d:b497) joined #forth
20:37:04 --- quit: mark4_ (Ping timeout: 245 seconds)
20:43:49 --- join: mark4 (~mark4@12.41.103.244) joined #forth
20:45:06 --- quit: groovy2shoes (Excess Flood)
20:45:28 --- join: groovy2shoes (~groovy2sh@unaffiliated/groovebot) joined #forth
21:53:08 --- join: mark4_ (~mark4@172.58.7.49) joined #forth
21:56:45 --- quit: mark4 (Ping timeout: 250 seconds)
22:06:26 --- quit: PoppaVic (Ping timeout: 264 seconds)
22:06:33 <yunfan> this ReGIS looks like intersteing
22:06:46 <yunfan> i was hoping there will be a web implementation
22:12:04 --- quit: mark4_ (Ping timeout: 245 seconds)
22:17:47 --- join: PoppaVic (~PoppaVic@unaffiliated/poppavic) joined #forth
22:26:39 --- quit: gravicappa (Ping timeout: 250 seconds)
22:32:58 --- join: mark4 (~mark4@12.41.103.244) joined #forth
22:49:08 --- quit: proteusguy (Remote host closed the connection)
23:06:24 --- join: proteusguy (~proteusgu@mx-ll-14.207.101-217.dynamic.3bb.co.th) joined #forth
23:06:24 --- mode: ChanServ set +v proteusguy
23:08:03 --- join: mark4_ (~mark4@172.58.7.91) joined #forth
23:10:59 --- quit: proteusguy (Ping timeout: 258 seconds)
23:11:43 --- quit: mark4 (Ping timeout: 250 seconds)
23:23:05 --- join: proteusguy (~proteusgu@mx-ll-14.207.101-217.dynamic.3bb.co.th) joined #forth
23:23:05 --- mode: ChanServ set +v proteusguy
23:34:31 --- join: mark4__ (~mark4@12.41.103.244) joined #forth
23:38:35 --- quit: mark4_ (Ping timeout: 258 seconds)
23:59:59 --- log: ended forth/19.04.24