2023-09-25 04:56:57 <vms14       > this shows how slow my lang is
2023-09-25 04:57:00 <vms14       > https://pastebin.com/raw/kWZDdhqb
2023-09-25 05:06:19 <vms14       > wasn't much higher time with the other implementations?
2023-09-25 05:06:55 <vms14       > i don't remeber, but it takes 7 seconds to sum the numbers from 0 to one million
2023-09-25 05:07:09 <vms14       > 1 if cheating
2023-09-25 05:10:06 <dave0       > ooh
2023-09-25 05:25:29 <vms14       > dave0: why oh xd it's extremely slow
2023-09-25 05:26:02 <vms14       > but it's not like i care about performance now
2023-09-25 05:26:46 <vms14       > i care about being able to write programs with it, which is a hard task
2023-09-25 05:30:46 <dave0       > my woefully unfinished forth takes 0.16 seconds
2023-09-25 05:31:17 <dave0       > : sum   0 0 begin dup 1000000 < while dup >r + r> 1+ repeat drop . ;
2023-09-25 05:32:15 <dave0       > vms14: mines a lot more code than yours
2023-09-25 05:32:34 <dave0       > oh and i'm off-by-one
2023-09-25 05:32:55 <vms14       > yeah, but look at the speed difference xd
2023-09-25 05:33:07 <vms14       > 0.16 vs 7
2023-09-25 05:33:27 <vms14       > KipIngram forth does not even tick
2023-09-25 05:33:31 <vms14       > xd
2023-09-25 05:34:28 <vms14       > i will have to compile somehow at the end
2023-09-25 05:34:50 <vms14       > for now i have to keep defining the language and refining some aspects
2023-09-25 05:35:02 <dave0       > threaded code is interesting
2023-09-25 05:35:10 <vms14       > i want tco
2023-09-25 05:35:32 <GeDaMo      > Chuck's colorforth has a word -; for tail calls
2023-09-25 05:35:36 <vms14       > but i want it to be natural in a way like : foo some code foo ;
2023-09-25 05:35:42 <GeDaMo      > It turns the previous call into a jmp
2023-09-25 05:36:20 <vms14       > with a return stack it's done
2023-09-25 05:36:33 <vms14       > if not, i have to make workarounds, which are not nice
2023-09-25 05:36:40 <dave0       > my BRANCH could do it
2023-09-25 05:36:50 <dave0       > it takes an absolute address
2023-09-25 05:37:45 <dave0       > you could use an immediate word to lay down a BRANCH and then tick ' the word... maybe with >body (which i haven't written)
2023-09-25 05:37:54 <vms14       > also i want to define the lang in itself as most as possible
2023-09-25 05:38:23 <vms14       > in a way i only have to write a tiny core to port it
2023-09-25 05:38:50 <vms14       > and the rest is defined on the lang itself, which should work as long as the core does
2023-09-25 05:39:24 <GeDaMo      > Are you generating native code?
2023-09-25 05:39:34 <vms14       > not yet
2023-09-25 05:39:51 <vms14       > i don't have any kind of compilation
2023-09-25 05:40:19 <GeDaMo      > concatenating machine code sequences is easy for Forth
2023-09-25 05:40:20 <dave0       > : tail-call   postpone branch recurse ; immediate        this would nearly do it
2023-09-25 05:40:29 <vms14       > i had a fake one which was just to return closures with decisions and sme values taken at "compile time"
2023-09-25 05:40:53 <vms14       > it halves the time it takes for that benchmark
2023-09-25 05:41:07 <vms14       > cause it avoids the task of the interpreter
2023-09-25 05:41:13 <GeDaMo      > So you're not using threaded code at the moment?
2023-09-25 05:41:31 <vms14       > no, colon words are just a list of words/objects
2023-09-25 05:42:02 <vms14       > and my goal is to generate code instead of threading
2023-09-25 05:42:13 <vms14       > GeDaMo: the language is written in perl
2023-09-25 05:42:22 <vms14       > and has more to do with lisp than with forth
2023-09-25 05:42:32 <GeDaMo      > Ah, right
2023-09-25 05:43:00 <vms14       > but my goal is to have some sort of half interpreter half transpiler
2023-09-25 05:43:20 <vms14       > if for example i can generate perl code the repl is a transpiler generating perl code + eval
2023-09-25 05:43:42 <GeDaMo      > "Linear Logic and Permutation Stacks--The Forth Shall Be First" https://web.archive.org/web/20200112152842/http://home.pipeline.com/~hbaker1/ForthStack.html
2023-09-25 05:43:53 <vms14       > i can generate functions from code, so i have words as a code string and as a function
2023-09-25 05:44:16 <vms14       > when compiling it will use the string, unless it's immediate, then the function
2023-09-25 05:44:37 <vms14       > but some words need to be immediate and i have to learn about the whole thing
2023-09-25 05:45:24 <vms14       > also wonder about adding a stack on the target lang or not
2023-09-25 05:55:18 <vms14       > i wonder if i'll ever compile in any of its meanings
2023-09-25 05:55:35 <vms14       > i want to automate c ffi in a similar way gforth does
2023-09-25 05:56:00 <vms14       > https://www.rosettacode.org/wiki/Draw_a_pixel#Forth
2023-09-25 07:53:10 <KipIngram   > dave0, vms14: You'll probably find that to get tail calls really right you will need to have a state variable that you maintain for ; to consult.
2023-09-25 07:53:21 <KipIngram   > I've tried to do it without that a few times and can never quite get it to work.
2023-09-25 07:53:50 <KipIngram   > It's hard to do by just inspecting recently compiled code.
2023-09-25 07:54:01 <KipIngram   > There's always the possibility of that being a literal or string data.
2023-09-25 07:54:45 <KipIngram   > Having an IF ... THEN at the end of a definition can also trip it up.
2023-09-25 07:55:02 <KipIngram   > : foo ... ;
2023-09-25 07:55:16 <KipIngram   > : bar ... ... foo ; <- tail optimizable.
2023-09-25 07:55:31 <KipIngram   > : bar ... IF ... foo THEN ; <- not tail optimizable.
2023-09-25 07:55:54 <KipIngram   > But the last of the code before ; looks the same in both cases.
2023-09-25 07:56:26 <KipIngram   > But if you set a state variable each time you compile a foo-like word, and have words like THEN clear it...
2023-09-25 07:56:37 <KipIngram   > Then when you handle ; you can just check that to know what to do.
2023-09-25 07:57:18 <vms14       > KipIngram: so you try to find the tail call as a word in the code?
2023-09-25 07:57:33 <vms14       > it's impossible for me
2023-09-25 07:57:41 <KipIngram   > My ; is immediate, and its normal operation is to compile (;)
2023-09-25 07:57:52 <vms14       > this is mainly why forths have a word named recurse instead i suppose
2023-09-25 07:58:08 <KipIngram   > So I just have ; check that state var - if it's set, I know I just compiled something I can tail optimize, so I do.
2023-09-25 07:58:31 <KipIngram   > Tail call is more general than recursion.
2023-09-25 07:58:42 <KipIngram   > Recursion is just when it happens to be the word you are defining.
2023-09-25 07:59:01 <KipIngram   > and the reason some forths have recurse is because they may not make words visible until the definition is FINISHED.
2023-09-25 07:59:07 <KipIngram   > : foo  ... foo ;
2023-09-25 07:59:11 <vms14       > right
2023-09-25 07:59:24 <vms14       > they don't exist yet
2023-09-25 07:59:26 <KipIngram   > ^ foo has to be "findable" for that to work.
2023-09-25 07:59:29 <KipIngram   > they can.
2023-09-25 07:59:39 <KipIngram   > They do in my system - heaers are available as soon as they exist.
2023-09-25 08:00:14 <vms14       > mine just does not give a fuck of the contents xd
2023-09-25 08:00:22 <vms14       > : oh my cat is nice ;
2023-09-25 08:00:25 <KipIngram   > But nonetheless I have a word called ME that does a recursion.
2023-09-25 08:00:31 <KipIngram   > And I have conditional forms of it too.
2023-09-25 08:00:51 <KipIngram   > yeah, you're not actually compiling anything.
2023-09-25 08:01:35 <KipIngram   > So ; foo ... foo ; would work fine in my system.
2023-09-25 08:01:43 <KipIngram   > But : foo ... me ; does too.
2023-09-25 08:02:12 <KipIngram   > me is immediate; it checks the dictionary for the latest name and compiles a jump to it.
2023-09-25 08:02:41 <KipIngram   > I thought about calling it SELF but ME is shorter.
2023-09-25 08:03:55 <KipIngram   > Anyway, tail optimization turns out to be a thing that is more delicate that you might initially think.
2023-09-25 08:04:20 <vms14       > i need a stack
2023-09-25 08:06:09 <KipIngram   > You do - you hang out in a Forth channel.  :-)
2023-09-25 08:07:03 <vms14       > without it the only way i see is to turn the code into a loop
2023-09-25 08:07:28 <vms14       > but it is explicit and i dislike it
2023-09-25 08:07:34 <KipIngram   > For recursion?  That's the whole point of tail optimization - to avoid consuming your return stack resources unnecessarily.
2023-09-25 08:08:23 <vms14       > yes but you have to mark a word as recursive to provide the tco
2023-09-25 08:08:45 <vms14       > and it's no longer a colon word, but some sort of a builtin
2023-09-25 08:08:53 <KipIngram   > A compiler can keep up with it without your explicit assistance.
2023-09-25 08:09:03 <vms14       > a compiler xd
2023-09-25 08:09:29 <vms14       > and a return stack
2023-09-25 08:21:00 <KipIngram   > dave0:
2023-09-25 08:21:02 <KipIngram   > : usec  uet 1000000 * + ;  ok
2023-09-25 08:21:04 <KipIngram   > : iter  swap over + swap 1- .0>me ;  ok
2023-09-25 08:21:06 <KipIngram   > : measure usec 0 1000000 iter drop . usec swap - . ;  ok
2023-09-25 08:21:08 <KipIngram   > measure 500000500000 17433  ok
2023-09-25 08:21:12 <KipIngram   > 17.4 msec.
2023-09-25 08:22:02 <dave0       > KipIngram: nice!
2023-09-25 08:22:21 <KipIngram   > And that includes some overhead - I could, with a bit more effort, have pushed the usec calls in right next to iter.
2023-09-25 08:24:14 <dave0       > what does `uet` stand for? something something time?
2023-09-25 08:24:30 <KipIngram   > Unix epoch time.
2023-09-25 08:24:35 <dave0       > aah
2023-09-25 08:24:59 <KipIngram   > It returns it as a pair of cells - : uet  ( -- usec sec) ;
2023-09-25 08:25:20 <dave0       > is it a system call?
2023-09-25 08:25:26 <KipIngram   > It does a system call.
2023-09-25 08:25:34 <KipIngram   > it's a primitive in my system.
2023-09-25 08:25:52 <dave0       > cool
2023-09-25 08:26:21 <KipIngram   > It could directly return a single cell - I think it's arranged that way as legacy from 32-bit systems.
2023-09-25 08:27:24 <dave0       > there's like 5 different ways to get the time on unix
2023-09-25 08:27:26 <KipIngram   > I wind up defining usec every time i want to use it - it's more convenient.
2023-09-25 08:40:41 <KipIngram   > Anyway, my advice re: tail opt is to just bite the bullet and use a state var rather than trying to be "clever."
2023-09-25 08:42:33 <KipIngram   > Basically whenever you compile a word in any way (immediate, non-immediate, whatever) see if it's a non-immediate : def word.  If it is, set the var.  If it's not, clear it.  Then have ; use that to decide whether to compile (;) or render that latest call into a jump.
2023-09-25 08:44:21 <vms14       > i only have a today word
2023-09-25 08:44:30 <KipIngram   > ?
2023-09-25 08:44:35 <KipIngram   > today word?
2023-09-25 08:44:46 <vms14       > (`Mon Sep 25 12:44:34 2023`)
2023-09-25 08:44:55 <KipIngram   > Oh - gotcha.
2023-09-25 08:45:04 <KipIngram   > date
2023-09-25 08:45:06 <vms14       > just for printing http date header xd
2023-09-25 08:45:30 <vms14       > but i did not decide what the time word will be
2023-09-25 08:46:36 <vms14       > "Date: " . today . cr
2023-09-25 08:47:02 <KipIngram   > Sure.  I haven't had any need for that; I don't do any http: stuff.
2023-09-25 08:47:17 <KipIngram   > I added uet to facilitate timing activities.
2023-09-25 08:47:21 <vms14       > i should be using frameworks for that
2023-09-25 08:47:28 <vms14       > or servers
2023-09-25 08:48:12 <vms14       > KipIngram: timing activities like a benchmark?
2023-09-25 08:48:54 <vms14       > i still need to find a better way to execute async code than using threads
2023-09-25 08:49:34 <KipIngram   > Yes - measure how long words take, etc.
2023-09-25 09:30:38 <KipIngram   > vms14: What do you dislike about threads?
2023-09-25 09:31:21 <vms14       > race conditions and shared data
2023-09-25 09:31:23 <KipIngram   > I view threads as the logical way to take advantage of having multiple cores.  I know they can run on a single core too, but you need more than one execution stream if you want to be able to use more than one core.
2023-09-25 09:31:32 <KipIngram   > Yes, you have to know what you're doing.
2023-09-25 09:31:43 <vms14       > but mainly the fact they are a extremely discouraged thing in perl
2023-09-25 09:31:58 <vms14       > also, i guess there are better alternatives
2023-09-25 09:31:59 <KipIngram   > But I've dealt with that kind of thing all along, in designing digital circuits, so I guess it doesn't "scare me."
2023-09-25 09:32:12 <vms14       > like event driven programming for example
2023-09-25 09:32:16 <KipIngram   > I don't mean to downplay the issue - it's certainly something you need to "get right."
2023-09-25 09:32:38 <vms14       > a thread is not a proper abstraction to async code
2023-09-25 09:32:46 <KipIngram   > But ultimately you'll still HAVE threrads right?  You're talking more about how you have your threads communicate.
2023-09-25 09:32:47 <vms14       > is just code that runs in a system thread
2023-09-25 09:33:31 <KipIngram   > When you say "events" you're talking about a message passing architecture, right?
2023-09-25 09:33:56 <vms14       > in a general way, any other alternative to threads to execute code in asynchronous way
2023-09-25 09:34:32 <KipIngram   > Ok.  We're just using the word a little differently.
2023-09-25 09:34:49 <KipIngram   > To me "threads" is anything that involves multiple code streams.
2023-09-25 09:34:58 <KipIngram   > And you can't support multiple cores without having that.
2023-09-25 09:35:21 <KipIngram   > But there are many ways you can have them communicate and synchronize.
2023-09-25 09:35:45 <KipIngram   > And shared memory - yeah, that is definitely an "optional" thing.
2023-09-25 09:35:57 <KipIngram   > So if you prefer to avoid it to avoid the problems that can come with it, I get that.
2023-09-25 09:36:06 <KipIngram   > It can also bring in cache efficiency issues.
2023-09-25 09:36:21 <KipIngram   > So there are definitely some pitfalls associated with shared memory.
2023-09-25 09:36:27 <GeDaMo      > You can take advantage of shard memory as an optimization but it's best to avoid multiple threads reading/writing the same memory at the same time
2023-09-25 09:36:48 <GeDaMo      > /shard/shared/
2023-09-25 09:36:53 <KipIngram   > A thing to keep in mind, though, is that you can get cache issues around "shared memORY" without actually sharing memory.
2023-09-25 09:37:04 <KipIngram   > It's enough to share cache lines, even without "real" overlap.
2023-09-25 09:37:16 <GeDaMo      > Yeah
2023-09-25 09:37:49 <KipIngram   > vms14: They call that "false sharing," and there are tools that can help you detect it in your applications.
2023-09-25 09:37:56 <KipIngram   > At least if you're using c.
2023-09-25 09:39:18 <KipIngram   > vms14: As far as race conditions and deadlock go, I don't think message passing is a universal panacea for that - you can still have race conditions even with message passing.
2023-09-25 09:39:35 <vms14       > but isn't all this a workaround?
2023-09-25 09:39:53 <vms14       > reflecting how threads aren't actually what we need
2023-09-25 09:42:16 <GeDaMo      > The hardware has multiple cores which are essentially threads
2023-09-25 09:42:22 <KipIngram   > ^ that.
2023-09-25 09:42:34 <KipIngram   > You have to have threads to fully utilize your hardware in modern processors.
2023-09-25 09:43:04 <KipIngram   > And you will - you might find a way to bury it under the layers you're using, but if you're capitalizing on your cores you will somehow have threads in there.
2023-09-25 09:43:19 <GeDaMo      > You may be able to map other abstractions onto the hardware threads
2023-09-25 09:43:21 <KipIngram   > you just might not have them be "visible" to you.
2023-09-25 09:43:27 <KipIngram   > Right.
2023-09-25 09:43:45 <KipIngram   > And those abstractions could offer protection against race conditions etc.
2023-09-25 09:44:16 <GeDaMo      > Erlang provides share nothing threads, they communicate via message queues
2023-09-25 09:44:24 <KipIngram   > vms14: I think you're just looking at things from a different "altitude," so to speak.
2023-09-25 09:45:00 <KipIngram   > I think Erlang is a good model - it's one of the things I intend to try to take cues from.
2023-09-25 09:45:20 <GeDaMo      > Me too
2023-09-25 09:45:20 <KipIngram   > i just don't know yet exactly what that means.
2023-09-25 09:45:36 <GeDaMo      > I also want whole array / table operations
2023-09-25 09:46:01 <KipIngram   > Yeah - I plan to raid APL for that.
2023-09-25 09:47:40 <GeDaMo      > There are many array languages to steal from :P
2023-09-25 09:47:58 <KipIngram   > APL is just the one I've looked into most deeply.
2023-09-25 09:48:35 <KipIngram   > I want to wind up with a system I can use for scientific modeling, so some kind of support along those lines is a must.
2023-09-25 09:49:35 <KipIngram   > At the moment I'm "imagining" that my target is an OS for an RPN calculator.
2023-09-25 09:49:43 <KipIngram   > Seems like a good way to "scope" the whole thing.
2023-09-25 09:56:35 <Zarutian_iPad> I found a new way to disregard idiotic comments on mainstream/social media: treat it like AI generated spewage.
2023-09-25 10:09:57 <vms14       > the abstractions on top of threads is what i want
2023-09-25 10:10:15 <vms14       > but i have to decide how
2023-09-25 10:10:20 <vms14       > and learn first xd
2023-09-25 10:12:22 <vms14       > i don't want to have to create a thread and manage the resources, etc
2023-09-25 10:12:40 <vms14       > i want some kind of systems that abstracts all this stuff
2023-09-25 10:13:32 <vms14       > i just want to execute code in asynchronous way
2023-09-25 10:13:44 <vms14       > for now when i want to do that, i spawn a thread
2023-09-25 10:14:20 <vms14       > i'll add some sort of workers list, where you give code and the number of threads to spawn with that code, or alike
2023-09-25 10:14:28 <vms14       > but it's not nice
2023-09-25 10:16:25 <vms14       > and still think i should be able to find a way to execute async code without threads
2023-09-25 10:17:06 <vms14       > for some reason non blocking io with one thread seems to perform much better than blocking io with threads
2023-09-25 10:18:11 <KipIngram   > That makes sense.  I'm on the other end of the spectrum, though - I will need some mechanism for creating threads and so on.  Any abstractions that wind up covering that I'll have to implement myself.
2023-09-25 10:18:18 <KipIngram   > I have no idea how i'll do all those things yet.
2023-09-25 10:18:45 <KipIngram   > But I want to be able to make threads simply and cheaply.
2023-09-25 10:19:16 <KipIngram   > I want them that to be a very "economical" operation.
2023-09-25 10:19:44 <KipIngram   > Just provide a bit of memory and the address of the code to run, and... go.
2023-09-25 10:20:28 <vms14       > but you want to implement the real thing
2023-09-25 10:20:35 <vms14       > with context switch and alike
2023-09-25 10:20:36 <KipIngram   > But then I also want to be able to equip threads with a private dictionary, console access, etc. as optional features.
2023-09-25 10:20:44 <KipIngram   > Yes indeed.  The real thing.
2023-09-25 10:20:55 <vms14       > i think context switch is what i don't like of threads
2023-09-25 10:21:04 <KipIngram   > I've already got the "guts" for that in place on my system.
2023-09-25 10:21:56 <vms14       > i'd always think about a main loop that partitions the code
2023-09-25 10:22:27 <KipIngram   > Every time I pass through "docol" (i.e., enter a new : definition) I decrement a register.  The idea is that when it hits zero I'll branch off and that's where a thread swap will occur.
2023-09-25 10:22:30 <vms14       > in lisp using macros i did something similar to fake async
2023-09-25 10:22:54 <vms14       > you give it code and returns a function that executes one statement every time you call it
2023-09-25 10:23:32 <vms14       > then you can run that code by pieces by just calling that function
2023-09-25 10:23:33 <KipIngram   > The idea is that for each core I'll have a "ring" of threads that are time multiplexing on that core.
2023-09-25 10:24:10 <KipIngram   > If a thread needs to wait for something, I'll remove it from its ring and park it in some other queue.
2023-09-25 10:25:02 <KipIngram   > In your lingo that would mean waiting for some "event" that would imply the thread was ready to execute again.
2023-09-25 10:25:44 <KipIngram   > Which could just be as simple as waiting for particular partner threads to arrive at that same point - maybe i want to take a collection of threads and periodically "sync" them.
2023-09-25 10:26:09 <KipIngram   > So each one would block when it got to that "gate" - only when all of them were there would I turn them all loose again.
2023-09-25 10:26:48 <KipIngram   > Or it might be waiting for a disk block to be RAM resident, etc.
2023-09-25 10:27:08 <KipIngram   > Waiting for a keystroke, whatever.
2023-09-25 10:34:44 <KipIngram   > vms14: I'm sure that by the time I have my "uppermost levels" working I'll have various layers of abstraction in place on top of these lower levels.
2023-09-25 10:34:50 <KipIngram   > But I have to build it all up, so...
2023-09-25 10:35:51 <vms14       > i would not try to implement threads
2023-09-25 10:36:01 <vms14       > but to look another thing instead
2023-09-25 10:36:19 <KipIngram   > You have more options, I think.  I don't, given the level I'm coming at this from.
2023-09-25 13:24:47 <KipIngram   > I've got several threads in play currently.  First of all, I'm going to model the lowest level of the system on Chuck's F18A architecture.  The F18A packs opcodes into cells, and I plan a "vm layer' that operates that way.
2023-09-25 13:25:26 <KipIngram   > That's where the compactness comes in - that virtual instruction set is designed primarily for compactness, while still running with speed similar to my previous designs.
2023-09-25 13:26:03 <KipIngram   > Then I'm planning this thread/vocabulary/directory/whatever layer, which is how I'll organize various applications and so on.
2023-09-25 13:26:43 <thrig       > Kubernetes layer, political layer, investor layer,
2023-09-25 13:27:02 <KipIngram   > And then we come to the actual structures for numerical computation.  I've become a big fan of geometric algebra, which is a math system that lets you mix scalars, vectors, and higher-order quantities together into what are called "multivectors."
2023-09-25 13:27:30 <KipIngram   > Oh, I'm sorry - I thought I was in another channel talking to a specific person.
2023-09-25 13:27:38 <Zarutian_iPad> thrig: you just described the stereotypical startup
2023-09-25 13:27:44 <KipIngram   > Didn't mean to whack all you guys with t his again - I've already been through most of it.
2023-09-25 13:27:57 <Zarutian_iPad> not to worry
2023-09-25 13:28:18 <thrig       > reviews help it stick in memory (however poorly some of us make use of said memories)
2023-09-25 13:28:44 <KipIngram   > Anyway, then finally I'm pondering that projective geometry layer.  Want to see if I can mix all this stuff together.
2023-09-25 14:02:42 <KipIngram   > Another thing I've mentioned but only briefly is that I'm interested in trying to work up a block-resident symbol storage approach, so that I don't take up too much of my RAM storing header-type information.
2023-09-25 14:03:00 <KipIngram   > The payoff would be to be able to use my available RAM almost completely for actual code and data.
2023-09-25 14:03:53 <KipIngram   > Looking at structuring it as a hash table.  Making it block resident would reduce performance some, since I'd have to swap stuff in and out, but algorithmically I'd go for O(1) performance.
2023-09-25 14:13:16 <KipIngram   > Gotta love "data presentation choices."
2023-09-25 14:13:19 <KipIngram   > https://media.nature.com/lw767/magazine-assets/d41586-023-02995-7/d41586-023-02995-7_26075536.png?as=webp
2023-09-25 14:13:54 <KipIngram   > Notice how the y axis there is not 0 based.
2023-09-25 14:14:08 <KipIngram   > Which of course makes the gap up at the top as prominent as possible.
2023-09-25 14:19:36 <KipIngram   > There is no doubt about it having been a hot summer, though - it's noticeably hotter here in the Houston area than "typical" summers in my memory.  It's actually nicely cooler today, but we've had a LOT of really hot days this time.
2023-09-25 14:20:49 <Zarutian_iPad> talking about warmth, it has been pleasently warmer here today than usual for this season of the year
2023-09-25 14:22:31 <Zarutian_iPad> usually, at least in my memory it was annoyingly cold. That is, the kind that makes one go 'I wished it was a degree or so warmer'
2023-09-25 14:26:14 <KipIngram   > Heh.  Too bad I couldn't have shipped you guys some hot air occasionally.
2023-09-25 18:52:04 <KipIngram   > Holy cow - it's pouring.
2023-09-25 18:52:16 <KipIngram   > Glad I took the dogs out a few minutes ago.
2023-09-25 18:55:08 <thrig       > a cow with holes in it would pour
2023-09-25 20:39:08 <Zarutian_iPad> thrig: po(o|u)r cow!