2023-04-11 08:54:00 <KipIngram   > I think that comes from us operating from positions of at least somewhat higher expertise.  I think a lot of the things that have happened have been oriented at making stuff accessible to successively lower tiers of knowledge.
2023-04-11 08:54:25 <KipIngram   > At levels like the BIOS the trend has been to remove control rather than add it, though they've certainly added some things too.
2023-04-11 08:54:58 <KipIngram   > I feel like we had this "personal computer revolution," and then ever since the trend has been back the other way toward more and more centralization.
2023-04-11 08:55:22 <KipIngram   > It's almost like someone said "Ooops - wait - we didn't really mean to give you THAT much power."
2023-04-11 09:05:03 <veltas      > I'm hoping UEFI is left out of the ARM and RISC-V ecosystems
2023-04-11 09:05:27 <veltas      > I think the intention is for UEFI to support those architectures as well, but literally anyone could do a better job
2023-04-11 09:06:33 <veltas      > UEFI is pretty much an OS, it's the new DOS. I don't think we needed that. And they've got all this awful security stuff as well to lock down your systems
2023-04-11 09:07:34 <veltas      > Although you can achieve this security crap anywhere but it's been championed by UEFI more than anyone else
2023-04-11 09:22:05 <gordonjcp   > oh hey
2023-04-11 09:22:33 <gordonjcp   > did you read the thing about Phoenix Hyperspace?
2023-04-11 09:27:57 <unjust      > https://cohost.org/cathoderaydude/post/1228730-taking-the-deepest-p ?
2023-04-11 09:37:37 <gordonjcp   > ye
2023-04-11 09:37:41 <gordonjcp   > it's *mental*
2023-04-11 09:37:55 <gordonjcp   > suspend the machine, lie about the parameter tables, then unsuspend
2023-04-11 09:38:24 <veltas      > The UEFI thing they mentioned... I believe what's happening is they are controlling what's displayed via the UEFI graphics interface, and what keyboard does via the UEFI keyboard input interface
2023-04-11 09:38:37 <veltas      > So when the OS properly takes over with real drivers it all stops happening
2023-04-11 09:39:30 <veltas      > I'm glad that most OEMs don't realise they can put this kind of stuff in their BIOS
2023-04-11 09:39:48 <veltas      > Because look at what they already distribute on Windows, imagine that stuff running all the time at the SMM level
2023-04-11 09:43:41 <gordonjcp   > that being said
2023-04-11 09:43:54 <gordonjcp   > you could make a UEFI app that's really OpenBoot
2023-04-11 10:02:39 <veltas      > What I want is OpenBoot as an alternative to UEFI, not a layer on top of UEFI
2023-04-11 10:02:46 <veltas      > But you are right
2023-04-11 10:03:17 <veltas      > If anyone here wants help doing a UEFI Forth I have actually spent a little time thinking about this and have experience with UEFI-level stuff
2023-04-11 10:05:10 <veltas      > And as far as I'm concerned it should go all the way and be an OS, as Forth was intended to be
2023-04-11 10:05:52 <veltas      > UEFI provides access to video, keyboard, storage blocks. Go, that's your playground
2023-04-11 10:12:05 <veltas      > They've got mouse access too, network access I think
2023-04-11 10:12:31 <veltas      > And then you've got a good jumping off point for developing actual drivers
2023-04-11 13:39:41 <vms14       > I'm still thinking about concurrency
2023-04-11 13:40:09 <vms14       > but I'm not sure on how I want to approach it
2023-04-11 13:40:11 <thrig       > fake money?
2023-04-11 13:40:36 <vms14       > would be fakecurrency
2023-04-11 13:40:48 <vms14       > I'm fine with fakecurrency as long as it kind of works
2023-04-11 13:41:38 <vms14       > what I have in mind is to have just one main loop and be able to execute code async, but also being able to set a timer for that code, so the process/thread dies once it times out
2023-04-11 13:42:11 <vms14       > I could make something with what I have now, but would be to spawn a thread and need another thread as a watcher
2023-04-11 13:42:45 <vms14       > I wonder if making some sort of event based thing, kind of similar to node
2023-04-11 13:44:02 <vms14       > but I'd like to have sync code when I want to
2023-04-11 13:45:48 <vms14       > the first idea is to have several interpreters and execute statements in some sort of multitasking round robin way
2023-04-11 13:46:14 <vms14       > for loops I could be fine if I have a return stack
2023-04-11 13:46:18 <drakonis    > the erlang approach?
2023-04-11 13:46:23 <vms14       > but for blocking i/o idk
2023-04-11 13:46:30 <vms14       > drakonis: the erlang approach is the actor model
2023-04-11 13:46:36 <vms14       > which I'm also considering btw
2023-04-11 13:47:38 <vms14       > but I saw also a thing called communicating sequential processes
2023-04-11 13:47:51 <vms14       > it's supposed to avoid the problems the actor model still has
2023-04-11 13:47:53 <drakonis    > ah csp
2023-04-11 13:48:30 <drakonis    > erlang's approach is actually csp afaik
2023-04-11 13:48:46 <vms14       > I have no idea about concurrency more than simple threads and shared data basics
2023-04-11 13:48:57 <vms14       > so I have a lot of research to do
2023-04-11 13:49:06 <vms14       > drakonis: oh, I thought it was the actor model
2023-04-11 13:49:12 <drakonis    > both are similar
2023-04-11 13:49:14 <vms14       > that's what internet says
2023-04-11 13:49:30 <Zarutian_iPad> there is the actor model in its many variations
2023-04-11 13:49:39 <vms14       > stole a book about csp
2023-04-11 13:49:39 <drakonis    > its a subset of the actor model i suppose
2023-04-11 13:50:09 <drakonis    > Zarutian_iPad: small world innit
2023-04-11 13:50:29 <Zarutian_iPad> then there is stuff like systoloc arrays, gpu shaders, reconfigurable computation in fpgas
2023-04-11 13:50:38 <Zarutian_iPad> systolic*
2023-04-11 13:51:05 <vms14       > 
ACTION just wants to execute async code with a timeout

2023-04-11 13:51:46 <vms14       > still I'd like the language to have a proper way to provide concurrency, more than threads and a queue
2023-04-11 13:52:06 <drakonis    > it'd be quite nice
2023-04-11 13:52:17 <drakonis    > is this for a forth library then?
2023-04-11 13:52:33 <vms14       > no, it's for a concat lang quite different from forth
2023-04-11 13:52:39 <drakonis    > oh!
2023-04-11 13:52:40 <Zarutian_iPad> you could go the prolog way of defining your computation that way
2023-04-11 13:53:02 <thrig       > I always draw a blank when I have to prolog
2023-04-11 13:53:08 <drakonis    > there's also strand and fleng
2023-04-11 13:53:12 <vms14       > Zarutian_iPad: how does prolog?
2023-04-11 13:53:25 <Zarutian_iPad> then there is the commucating event loop way of E with eventual sends
2023-04-11 13:53:44 <vms14       > I have a perl implementation of prolog in my lang as a module xd
2023-04-11 13:53:45 <drakonis    > E is nice, yes.
2023-04-11 13:54:19 <Zarutian_iPad> in prolog you define what you want but not how. Enabling the runtime to figgure out the concurent parts it can do
2023-04-11 13:54:52 <Zarutian_iPad> the there is map and reduce way
2023-04-11 13:54:56 <drakonis    > http://www.call-with-current-continuation.org/articles/the-joy-of-concurrent-logic-programming.txt
2023-04-11 13:55:01 <drakonis    > relevant to this
2023-04-11 13:55:13 <drakonis    > since prolog came up in this specific context
2023-04-11 13:55:27 <Zarutian_iPad> alsothe there operator that enables you to send a lamda to wherever the data lives
2023-04-11 13:56:08 <Zarutian_iPad> in that vein you might want to look into propagators
2023-04-11 13:57:40 <drakonis    > propagators are a hoot
2023-04-11 13:57:59 <drakonis    > vms14: is the source for your concatenative language available somewhere?
2023-04-11 14:01:13 <vms14       > drakonis: it's written in perl xd
2023-04-11 14:01:18 <drakonis    > oic
2023-04-11 14:01:30 <vms14       > https://termbin.com/bzmg
2023-04-11 14:01:37 <Zarutian_iPad> vms14: …but why?
2023-04-11 14:01:49 <vms14       > Zarutian_iPad: why perl you mean?
2023-04-11 14:01:58 <Zarutian_iPad> yeah
2023-04-11 14:02:18 <vms14       > perl turned to be the language I used the most and I feel more comfortable with
2023-04-11 14:02:49 <vms14       > mainly cause it does what I tell it to do and tries to not get on the way telling me how things should be done
2023-04-11 14:03:03 <vms14       > and it's also quite flexible, I can do a lot of stuff
2023-04-11 14:03:23 <Zarutian_iPad> a bit like I have used tcl and js
2023-04-11 14:03:42 <vms14       > for example the oop in my lang is the oop of perl, my lang can create perl packages at runtime and add functions or variables, creating modules and classes
2023-04-11 14:04:13 <vms14       > it's slow, but for now it's a prototype, so why I want performance
2023-04-11 14:04:31 <Zarutian_iPad> right
2023-04-11 14:04:51 <vms14       > but now the next step seems to be concurrency
2023-04-11 14:05:05 <Zarutian_iPad> best way to get performance is for the compiler/packer/jitter to figure out what can be omitted
2023-04-11 14:05:07 <vms14       > although I'm also learning tex cause I want something to document the langage xD
2023-04-11 14:05:34 <vms14       > Zarutian_iPad: I never cared about performance until I made a benchmark and cried
2023-04-11 14:05:44 <thrig       > tex might be overkill?
2023-04-11 14:06:10 <vms14       > I tried to fake compiling the words, converting them into functions
2023-04-11 14:06:21 <vms14       > mainly avoiding the reasoning the interpreter does
2023-04-11 14:07:00 <vms14       > it did get rid of the interpreter overhead, but if I want performance I'd like to make a transpiler
2023-04-11 14:07:16 <vms14       > which btw I wonder what about a code generator instead
2023-04-11 14:07:36 <vms14       > I know they're the same stuff, but I mean to just have words that generate code
2023-04-11 14:08:07 <Zarutian_iPad> machine code?
2023-04-11 14:08:11 <vms14       > as I've added packages I could for example make a 'js' package that when you use the words there, they'll write js code
2023-04-11 14:08:13 <vms14       > nah
2023-04-11 14:08:27 <vms14       > high level languages code
2023-04-11 14:08:39 <vms14       > I tried it a bit and got something
2023-04-11 14:09:12 <vms14       > mainly I put a stack on the target language and have another kind of immediate word
2023-04-11 14:09:39 <vms14       > those words are executed at compile time, but return a string of code the transpiler will concatenate
2023-04-11 14:10:12 <vms14       > still is a bit trickier than just an interpreter
2023-04-11 14:10:22 <vms14       > and I wonder how I'll add some features
2023-04-11 14:10:51 <vms14       > but the language still needs to evolve so it will stay being a prototype
2023-04-11 14:17:35 <vms14       > brb
2023-04-11 14:19:14 <veltas      > My fav 'scripting' language is Lua
2023-04-11 14:20:30 <drakonis    > hmm, so erlang actually isnt csp
2023-04-11 14:22:57 <Zarutian_iPad> veltas: it is a bit verbose but alright in other regards though I would have loved to have debug.getRelPC(<thread>, <level>) and debug.setRelPCandFunc(<thread>, <level>, <func>, <relPC>) baked in from the start to be able to easily serialize and deserialize most coroutines.
2023-04-11 14:24:51 <veltas      > Is that something they have now?
2023-04-11 14:24:58 <Zarutian_iPad> nope
2023-04-11 14:25:15 <veltas      > Full serialisation would be cool, it's the sort of thing language creators don't think about
2023-04-11 14:25:33 <Zarutian_iPad> been figguring out how to make the .c code patch
2023-04-11 14:25:41 <veltas      > The big issue with Lua is it's very cathedral model
2023-04-11 14:25:59 <veltas      > And it's gotten steadily more bloated over the years
2023-04-11 14:26:03 <veltas      > It used to be a lot simpler
2023-04-11 14:26:13 <Zarutian_iPad> the ERIS project is too heavy weight and arch and platform dependant
2023-04-11 14:28:35 <Zarutian_iPad> I rather write the serialization and deserialization code in Lua
2023-04-11 14:29:12 <veltas      > Is that possible?
2023-04-11 14:29:37 <veltas      > Not without those functions you request?
2023-04-11 14:30:21 <Zarutian_iPad> most of it yes but not for saving coroutine threads that only have lua functions in their callstak
2023-04-11 14:33:42 <drakonis    > https://elixirforum.com/t/does-earlier-erlang-concurrency-model-stem-from-csp/16905/5 relevant to csp
2023-04-11 14:33:51 <drakonis    > word of god aka joe armstrong
2023-04-11 14:34:14 <drakonis    > csp talk, even.
2023-04-11 16:56:27 <unjust      > 97 105 99 105 114 116 97 112 32 105 104 11 0 [DO] EMIT [LOOP]
2023-04-11 16:57:55 <Zarutian_iPad> what sort emission is this?!?
2023-04-11 16:58:36 <unjust      > the sort in reference to the previous nick
2023-04-11 17:01:25 <Zarutian_iPad> and I suspect it wont run
2023-04-11 17:01:54 <drakonis    > it most certainly does run
2023-04-11 17:02:24 <Zarutian_iPad> which Forth? oh I see
2023-04-11 17:13:30 <Zarutian_iPad> 
ACTION smirks over https://www.youtube.com/watch?v=82mUqp5rpcg