00:00:00 --- log: started forth/19.02.24
00:07:41 --- quit: dys (Ping timeout: 250 seconds)
01:24:01 --- join: proteusguy (~proteusgu@203.177.88.178) joined #forth
01:24:02 --- mode: ChanServ set +v proteusguy
02:02:29 --- quit: nighty- (Ping timeout: 245 seconds)
02:02:58 --- quit: ashirase (Ping timeout: 255 seconds)
02:15:46 --- join: nighty- (~nighty@b157153.ppp.asahi-net.or.jp) joined #forth
02:22:27 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth
02:25:24 --- quit: nighty- (Ping timeout: 245 seconds)
02:37:16 --- join: nighty- (~nighty@b157153.ppp.asahi-net.or.jp) joined #forth
02:42:34 --- quit: nighty- (Ping timeout: 255 seconds)
02:55:10 --- join: nighty- (~nighty@b157153.ppp.asahi-net.or.jp) joined #forth
02:57:21 --- quit: proteusguy (Ping timeout: 244 seconds)
03:06:39 --- quit: mark4 (Ping timeout: 245 seconds)
03:36:24 --- join: dys (~dys@tmo-100-120.customers.d1-online.com) joined #forth
04:15:06 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
04:41:11 * corecode working on getting the cpu design into fpga
04:48:31 <WilhelmVonWeiner> very cool
04:58:54 <corecode> i had to take a detour to port open source tools to the chip i'm using
04:58:59 <corecode> because the vendor tools don't work
05:04:40 <WilhelmVonWeiner> that is very cool
05:04:48 <WilhelmVonWeiner> difficult port?
05:05:39 <corecode> took its time
05:05:50 <corecode> had to understand how their code works
05:06:05 <corecode> most of the hardware stuff was already there, just had to put it in the right place
05:32:05 --- join: pierpal (~pierpal@host105-222-dynamic.3-87-r.retail.telecomitalia.it) joined #forth
05:38:05 --- join: gravicappa (~gravicapp@h37-122-126-13.dyn.bashtel.ru) joined #forth
05:54:50 --- quit: rdrop-exit (Quit: Lost terminal)
06:20:29 --- quit: dave0 (Quit: dave's not here)
06:32:27 --- quit: cantstanya (Remote host closed the connection)
06:36:18 --- join: cantstanya (~chatting@gateway/tor-sasl/cantstanya) joined #forth
06:45:25 --- join: proteusguy (~proteusgu@203.160.190.58) joined #forth
06:45:25 --- mode: ChanServ set +v proteusguy
07:39:44 <the_cuckoo> well, rewrote my rpany server this afternoon - has one small issue relating to clients leaving (currently leaves zombie threads around which are cleaned up at shutdown), but the boost::asio stuff is lovely and allows me to implement it very succinctly - https://gitlab.com/lilo_booter/rpany-comms/blob/master/include/rpany/comms/server.hpp (session being the main class involved - 1 of these is created per
07:39:45 <the_cuckoo> connected client)
07:41:58 <the_cuckoo> nice thing about it is that it honour the 'read' word - so far, everything i've thrown at it works from a simple nc client (including prompts and coloured output)
07:58:16 --- join: mark4 (~mark4@12.41.103.244) joined #forth
08:21:52 <corecode> not to demean your work, but to me somehow an interpreted forth by far does not have the allure as a compiling forth kernel
08:22:43 <PoppaVic> and Real Men will poke bytes and eschew the assemblers, linkers, C and other
08:26:09 --- quit: pierpal (Read error: Connection reset by peer)
08:26:27 <`presiden> using magnetized needle and a steady hand
08:27:08 <corecode> i think that's prison tattoos
08:27:24 <the_cuckoo> corecode: understandable - and each to their own :) - me, i just want functionality without pain 
08:28:24 <the_cuckoo> the more i can reuse of others, the happier i am - don't go for the 'nih' attitude at all
08:29:04 <the_cuckoo> anyway, i'll probably end up with a compiling version at some point
08:30:55 <the_cuckoo> and fwiw, i started writing z80 assembly on paper, manually converting to hex and entering that into the computer - which is fine, when you're like 12 :)
08:31:49 <PoppaVic> I was almost twice as old, and still have those z80 tables I created. Interesting machine.
08:32:21 <the_cuckoo> i'd loved the z80 - 68000 too - was never taken by 6502 or x86 though
08:32:28 <the_cuckoo> awkward buggers
08:32:56 <PoppaVic> I was not fond of the 6502. but the 6510 was neat
08:33:06 <PoppaVic> x86 is mostly a nightmare
08:33:22 <the_cuckoo> indeed - never used used 6510 myself
08:34:06 <PoppaVic> well, the c64 used their special 6510 - I think they mostly used a 6502 and added the sprite/graphics to the die
08:35:18 <the_cuckoo> ah - right - never had a c64 - commodore pet at school was my first intro to computers - did a lot of BASIC on there and touched the assembly, but i managed to persuade my parents to get a zx81 and never looked back
08:35:38 <the_cuckoo> 1k of fun
08:35:57 <PoppaVic> yes, the t/s-1000 was nifty.
08:40:50 --- quit: gravicappa (Ping timeout: 245 seconds)
08:44:03 <the_cuckoo> when it comes down to it though, the main motivation for rpany is the work stuff - we have a complex library consisting of many specialised plugins which form increasingly complex filter graphs - this approach makes development, testing, tuning and analysing a whole heap easier
08:46:16 <the_cuckoo> criticisms of the approach are all entirely welcome, but are unlikely to budge me from the current path :) - it's just working too well - trivial to extend, trivial to use
08:54:25 --- quit: nighty- (Quit: Disappears in a puff of smoke)
08:55:09 <WilhelmVonWeiner> compile it all into memory
08:55:14 <WilhelmVonWeiner> memoisation
08:55:42 <the_cuckoo> and fuck it :), i want to build robots anyway - this is small, light, reasonably fast (but isn't fully optimised yet, though it's trivial to do - just haven't bothered yet as i need to make some special cases for recursion which the current code doesn't care about) - compiles to 400k as a fully statically linked executable
08:59:42 <the_cuckoo> and yeah, that's what i'd do - end of the day, i mostly just have a list of pointers to functions to iterate though
09:02:21 <the_cuckoo> none of this is rocket science - doesn't have to be complex, and building from the bottom up isn't necessary imo - it's fun and can be rewarding in its own way, but having a broad base to work from just makes things easier
10:55:29 --- quit: dddddd (Remote host closed the connection)
11:03:28 <corecode> yey forth cpu is blinking leds
11:07:24 <jn__> yay
11:07:36 <jn__> that's always nice to see
11:12:28 <KipIngram> So guys, what goes on in the details of text files vs. binary files?  Does declaring a file "text" cause the OS to apply some modifications to it as it passes between the disk and your application?
11:12:47 <KipIngram> If I'm implementing a "blocks.dat" file for a Forth system, should I go with binary, or will either work?
11:19:07 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
11:22:47 <corecode> huh?
11:22:56 <corecode> text is easier to read by humans
11:23:15 <corecode> some systems will translate line feeds when you open a file as text
11:32:36 <KipIngram> I'm talking about the OS level - in C you can open a file in read/write mode ("w+") or binary read/write ("w+b").
11:32:44 <KipIngram> I'm just wondering PRECISELY what difference that makes.
11:32:48 <KipIngram> What does that "b" DO?
11:32:56 <KipIngram> Or the lack of it.
11:33:08 <corecode> <corecode> some systems will translate line feeds when you open a file as text
11:33:33 <KipIngram> So that happens in the OS layers, out of my sight?
11:33:44 <corecode> in the library usually
11:34:05 <corecode> this argument only exists for fopen()
11:34:08 <KipIngram> Does the system translate it back properly on read, and does it account for what it did in terms of offsets and so on?
11:34:13 <corecode> fopen(3), not open(2)
11:34:23 <jackdaniel> it makes sense semantically speaking: text file has encoding and it doesn't necessarily match environment encoding itself
11:34:34 <KipIngram> I think I'll just go binary so I don't have to worry.
11:34:35 <corecode> it would just replace \r\n with \n, or something like it
11:34:37 <jackdaniel> so there must be decoders and encoders
11:35:13 <KipIngram> I want the file to contain exactly, precisely what I put in it, and exactly and precisely the offsets I put it all at.
11:35:16 <corecode> if you don't use fopen(3), you can't even choose
11:35:56 <KipIngram> Yesterday evening and this morning I got all of the traditional Forth disk handling stuff working on my system.
11:36:41 <KipIngram> I'm supporting a large number of disk buffers, allocated as they are needed, via a set associative block # -> buffer # hashing method.
11:36:57 <corecode> what's your implementation base?
11:37:17 <KipIngram> nasm assembly on MacOS and Ubuntu 18.04.
11:37:37 <corecode> do you use libc or syscalls?
11:37:48 <KipIngram> I have a common asm file that will work in both places, that includes a local include file that mops up the differences in syscall number and things like that.
11:37:53 <KipIngram> Syscalls only.
11:37:55 <corecode> ok
11:38:26 <KipIngram> I do my own memory allocation, and I'm about to implement my own file system.
11:38:33 <corecode> and you implemented a hash table?
11:38:40 <KipIngram> My notion is that this code will BE the OS for stuff I may build in the future.
11:39:04 <KipIngram> Embedded gadgets, and maybe (if I have the time) a personal machine with the processor cores implemented via FPGA.
11:39:06 --- quit: proteusguy (Remote host closed the connection)
11:40:03 <KipIngram> Yes, I allocate the actual buffers as 4k pages from my "cheap heap," as I need them, and one page holds a table of 256 16-byte records that assocate block numbers with buffer addresses, hold the dirty flag, etc.
11:40:23 <KipIngram> It's a really simple hash algorithm - it just uses the low order bits of the block number, and each block gets mapped to a pair of bufers.
11:40:28 <KipIngram> I pick the least recently used one.
11:40:33 <KipIngram> Using the TSC counter.
11:40:33 <corecode> implemented in forth or in assembler?
11:40:47 <KipIngram> Well, I wrote it in Forth, and then hand-translated to assembly.
11:40:53 <corecode> oh
11:40:55 <corecode> why?
11:40:55 <KipIngram> It qualifies as pure Forth.
11:41:03 <KipIngram> Why what, exactly?
11:41:07 <KipIngram> Which part
11:41:09 <corecode> why hand translate
11:41:10 <KipIngram> ?
11:41:22 <KipIngram> Oh, just because up until now I haven't had disk support working in the Forth.
11:41:32 <KipIngram> As of today I've reached the point where I can load source from the disk.
11:41:37 <KipIngram> So I can decide from here on out.
11:41:44 <corecode> aha
11:42:13 <corecode> how will your file system work?  just use a large file as container?
11:42:57 <KipIngram> Well, yes - right now I'm running this under a host OS, and I will have a "blocks.dat" file to model a physical storage system.  But in the future it may run bare metal, in which case it will access the hardware directly.
11:44:42 <KipIngram> I'd like to build a system from scratch in the future - just so that I can say I've done it.  That will include my own flash-based storage system, designed from the chip level.
11:44:54 <KipIngram> I work in IBM's flash storage group, so I have a pretty good idea about how to make such a thing work.
11:45:48 * KipIngram enjoys doing things from the ground up.  :-)
11:47:41 <corecode> ok
11:48:04 <corecode> you mean you will design your own chip?
11:48:13 <KipIngram> Oh gosh - I wish.
11:48:28 <KipIngram> I've read about MOSIS and the MAGIC IC design software and so on.
11:48:35 <KipIngram> But no, that's a dream that probably won't come true.
11:48:48 <KipIngram> Likely it will be my own hardware design implemented in an FPGA.
11:48:54 <corecode> ok
11:49:06 <KipIngram> Or a fleet of FPGAs - I could see it being massively multi-core.
11:49:15 <KipIngram> Since I can't make a single core that rivals COTS processors.
11:49:26 <KipIngram> So I'd try to compensate via core count.
11:49:28 <corecode> why does it have to rival it
11:49:33 <KipIngram> It doesn't "have to."
11:49:41 <KipIngram> But the more I can do with it the more fun it will be.
11:49:48 <KipIngram> Plus parallelism is just interesting.
11:49:49 <corecode> well, we know that core count only helps scaling in specific cases
11:49:52 <corecode> amdahl etc.
11:49:55 <KipIngram> Right.
11:50:21 <corecode> i was thinking about supporting 4 threads in my cpu
11:50:28 <KipIngram> On the other hand, do ps ax on your Linux box and look at how many threads are running.
11:50:32 <KipIngram> It's a ton.
11:50:38 <corecode> no
11:50:43 <corecode> they're not running
11:50:52 <corecode> they're waiting
11:51:03 <corecode> most will be waiting on IO
11:51:10 <KipIngram> For operational things, or for an opportunity to own a core?
11:51:11 <corecode> run queue is quite short
11:51:35 <KipIngram> I would like to think it's within some small factor of the core count.
11:51:59 <corecode> my load average is 0.17 right now, meaning there is one thread runnable 1/5 of the time
11:52:16 <KipIngram> xy]z[yx in this channel pointed out "flow based programming" to me - it looks like a good fit for the sort of thing I have in mind.
11:52:19 <corecode> now it is 0.11, so 1/10th of the time
11:52:37 <corecode> what is flow based programming?  dataflow?
11:52:53 <KipIngram> Essentially just independent processes communicating via streams.
11:52:58 <KipIngram> There's a Wikipedia article.
11:53:06 <corecode> ok
11:53:09 <KipIngram> The idea itself is sort of common sense - I just didn't know there was a formal topic around it.
11:53:26 <corecode> most things are event driven tho
11:53:43 <corecode> some compute is flows
11:57:13 <KipIngram> Some of my interests are in numerical physics.
11:57:21 <KipIngram> There you have applications that are compute-bound.
11:57:59 <KipIngram> It's not all about watching movies and sending emails.  :-)
11:58:28 <KipIngram> Even though it may be for 99.99% of the user base.
11:58:56 <KipIngram> One of the things that bothers me quite a lot about computing is that the direction of the whole industry has been taken over by the "interests of the masses."
11:59:10 <KipIngram> When I was young computers were for "special things."
11:59:29 <KipIngram> Most people never saw one.  Much less touched one.
11:59:50 <corecode> outrageous, the plebs taking over our nerd stuff!
11:59:57 <KipIngram> :-)
11:59:58 <WilhelmVonWeiner> I wish it still were
12:00:00 <KipIngram> Right - exactly.
12:00:11 <WilhelmVonWeiner> I blame the iPhone.
12:00:17 <corecode> ahem?
12:00:18 <KipIngram> Well, there are so many of those people that even if most of them aren't wealthy their financial power trumps everything else.
12:00:25 <KipIngram> So of course the industry chases them.
12:01:34 <corecode> aka working economy
12:01:58 <KipIngram> I tolerate the GUI on my computer, and I certainly enjoy some of the things it provides - I enjoy watchign YouTube videos sometimes, and being able to see pictures in the articles I'm reading, etc.
12:02:19 <KipIngram> But I spend most of my time, and far and away most of my "serious time," in a console.
12:02:34 <KipIngram> I'm in one now, chatting here.
12:03:40 <KipIngram> corecode: Exactly, yes - working economy.  And I'm all for it - I'm thoroughly capitalist, though I do worry about the power the biggest entities in the economy seem to gather up.
12:03:49 <KipIngram> But just because it's the way it should be doesn't mean there are no downsides.
12:04:39 <KipIngram> A lot of interesting things get overlooked because there's not enough money involved.
12:05:47 <corecode> declare it art and do it anyways
12:06:19 <john_cephalopoda> Quite a big portion of people nowadays probably think social media = the internet.
12:13:57 <KipIngram> Oh, I totally agree with that.
12:14:02 <WilhelmVonWeiner> eh
12:14:04 <KipIngram> I just shake my head.
12:14:06 <WilhelmVonWeiner> wikipedia isn't social media
12:14:09 <WilhelmVonWeiner> google isn't
12:14:14 <KipIngram> God I love Wikipedia.
12:14:30 <WilhelmVonWeiner> Same, it gets a lot of flak but I couldn't be where I am now without it for sure
12:14:39 <KipIngram> If you'd told me when I was a kid that I'd have access to information like we do today... WOW.
12:15:11 --- join: DabsR (~Mutter@190.62.250.53) joined #forth
12:15:14 <KipIngram> I know that you have to be careful using it for "controversial" topics, but there are so many topics that aren't controversial, and on those it's a pretty damn good resource.
12:15:58 <WilhelmVonWeiner> yeah, though you wouldn't expect the definition of "metaprogramming" to be controversial....
12:16:14 <WilhelmVonWeiner> someone watching that page really doesn't like Forth.
12:17:30 --- quit: DabsR (Read error: Connection reset by peer)
12:25:35 <KipIngram> There used to be a guy like that here.
12:25:38 <KipIngram> Russian dude.
12:25:49 <KipIngram> It was like he lived to tear down anything anyone said nice about Forth.
12:26:06 <KipIngram> I was... relieved that he wasn't around when I came back.
12:26:16 <KipIngram> I didn't really let it bother me, but it wasn't a positive, that's for sure.
12:26:38 <corecode> where?
12:27:12 <john_cephalopoda> WilhelmVonWeiner: Well, apparently many people rarely google or use wikipedia directly. Instead they spend their day on facebook, following links that their friends repost.
12:27:46 <KipIngram> ^ :-(
12:27:50 <KipIngram> What a waste.
12:28:18 <corecode> sounds universalist prescriptitarian to me
12:28:20 <john_cephalopoda> Hmm, I recently read an interesting article about the core internet structure - how it was used for end-to-end communication once but now is mostly used by CDN to distribute their content.
12:29:20 <john_cephalopoda> When you watch a video, it's usually not hosted halfway around the world but instead mirrored in a datacenter close to you.
12:29:33 <john_cephalopoda> Network traffic stays local.
12:31:39 <KipIngram> All trends in the world get exploited eventually, by whoever can get there first - it's a competition to see who can win that race.
12:31:57 <KipIngram> All systems will be gamed, all soft spots will be explited.
12:32:00 <KipIngram> exploited
12:32:15 <KipIngram> It's as sure as the 2nd Law of Thermo.
12:32:50 <john_cephalopoda> The internet becomes more and more a distribution platform that is used by a few monopolies.
12:32:52 <KipIngram> And I don't know how much physics you guys read, but it doesn't get any "surer" than that.
12:33:16 <KipIngram> john_cephalopoda: Our whole economy has become more and more about a few monopolies.
12:33:23 <KipIngram> I regard this as one of the world's worst problems.
12:33:42 <john_cephalopoda> Facebook (whatsapp+instagram), twitter, google (youtube+gdocs), microsoft (github+skype).
12:33:44 <KipIngram> One of the first things I'd do if I could re-write the script would be to arrange for barriers against that sort of monopoly power.
12:33:58 <KipIngram> Probably through the tax code.
12:34:08 <KipIngram> "You are big?  Your tax rate will be high"
12:34:10 <john_cephalopoda> Amazon didn't pay any taxes last year.
12:34:16 <KipIngram> Just make it more and more expensive to grow, the bigger you get.
12:34:27 <john_cephalopoda> In the US. They actually got some subsidies, so the tax payer _supported_ Amazon.
12:34:32 <KipIngram> Then you'd see companies "divest themselves" in a strategic way.
12:34:47 <KipIngram> yeah - that's *fucked*, pardon me.
12:35:04 <KipIngram> I believe we were much healthier economically back in the 50's.
12:35:13 <KipIngram> I know we had problems - the segregation and the racial unrest and so on.
12:35:17 <KipIngram> And we've improved in some of those areas.
12:35:37 <KipIngram> But back then small and medium size outfits played a much bigger role in the economy.
12:35:41 <john_cephalopoda> Eh, a lot of things improved. Unions became stronger.
12:35:44 <KipIngram> And that was a "Good Thing" (tm).
12:36:14 <KipIngram> Those small and medium size companes were the rungs in the ladder of upward mobility.
12:36:14 <WilhelmVonWeiner> New Deal and Post-Keynsianism caused the dearth of US economic success we see today
12:36:25 <KipIngram> We've systematically kicked those rungs out over the last few decades.
12:39:01 <john_cephalopoda> What would be needed is a decentralisation of internet platforms.
12:39:15 <john_cephalopoda> Mastodon, Peertube and Pixelfed are already working on some parts of it.
12:39:46 <WilhelmVonWeiner> I don't see it happening
12:40:30 <WilhelmVonWeiner> free and open source version control for websites and their data would be interesting though
12:41:09 <WilhelmVonWeiner> found your centralised website on a constitution and then provide version control so someone can fork from a less impure state when you inevitably violate that constitution
12:43:50 <john_cephalopoda> Supplying data under libre licenses is a thing.
12:48:04 <john_cephalopoda> What kind of web service would you find useful?
12:48:40 <WilhelmVonWeiner> clones of things that already exist, but centralised and not full of the alt-{left,right}
12:49:12 <john_cephalopoda> You mean decentralized?
12:49:40 <WilhelmVonWeiner> Not really
12:50:05 <WilhelmVonWeiner> Decentralisation leads to ruined communities, echo chambers, disjointed information, power struggles and more
12:50:32 --- join: yrm (~yrm@KD106165109038.ppp-bb.dion.ne.jp) joined #forth
12:50:37 <WilhelmVonWeiner> it's why for all it's flaws I like Twitter and not Mastodon
12:50:38 <john_cephalopoda> Twitter is centralized. Facebook is centralized.
12:50:59 <john_cephalopoda> Twitter and Facebook are full of Nazis.
12:51:03 <WilhelmVonWeiner> A business will likely support my interests better than a random sysadmin running an instance of x
12:51:36 <john_cephalopoda> WilhelmVonWeiner: A random sysadmin who has similar views as you will likely support your interests better than a company interested in making money.
12:51:47 <john_cephalopoda> Except if your interest is "helping a company make money".
12:52:07 <WilhelmVonWeiner> But then I'm on an instance with similar views and another demographic is somewhere else
12:52:25 <john_cephalopoda> Is that really different from Twitter?
12:52:27 <WilhelmVonWeiner> if a company is making money, it's good for the both of us - they need me as much as I want them
12:52:56 <john_cephalopoda> WilhelmVonWeiner: How many alt-right people do you follow on twitter?
12:53:18 <WilhelmVonWeiner> Maybe one? 
12:53:32 <john_cephalopoda> One of how many? ;þ
12:54:00 <WilhelmVonWeiner> The same applies to the left. The number of hard-left marx/social/commun/mao-ists is astounding
12:54:07 <john_cephalopoda> When you are on twitter, you will follow people from your demographic. It's just as much of an echo chamber.
12:54:35 <WilhelmVonWeiner> It's far less of an echo chamber because those opposing demographics aren't on a completely different instance
12:54:59 <WilhelmVonWeiner> an instance that may or may not have completely blocked the one I'm on, and their users may or may not be aware
12:55:13 --- quit: yrm (Client Quit)
12:55:41 <john_cephalopoda> Twitter isn't different though. People won't follow you and probably never see your posts when they aren't in your demographic.
12:55:58 <WilhelmVonWeiner> I used two different pleroma and a mastodon instance and really it just sucks 
12:56:32 <WilhelmVonWeiner> People see your posts with "x liked this tweet", retweets between demographics, the search function, "you should follow" etc etc 
12:57:15 <john_cephalopoda> What is "you should follow" based on?
12:57:29 <john_cephalopoda> Will it propose following Trump to a super-leftist person? Surely not.
12:57:33 <WilhelmVonWeiner> If Twitter nazis overtake Twitter commies I'll move to "Forthstodon" elsewise I'm okay being a well-served product
12:57:56 <WilhelmVonWeiner> john_cephalopoda: I think it has the potential to
12:58:08 <john_cephalopoda> Lol, you think Twitter Nazis are less common than Twitter commies? You live in an echo chamber.
12:58:17 <WilhelmVonWeiner> No, I think they're about equal.
12:58:42 <john_cephalopoda> They are most likely not equal.
13:00:23 <john_cephalopoda> If you assume that Twitter demographics and real-world demographics are approximately equal and that right-wing parties and leaders are on the rise all around the world, then they are far from equal.
13:01:11 <WilhelmVonWeiner> I don't assume the former, but I also don't think the latter means "there are more hard-righter than hard-leftists"
13:02:19 <WilhelmVonWeiner> based on % of voters to % of voters to each party, you do the maths.
13:03:06 <john_cephalopoda> Hm, ~50% of people voted for the far-right Trump, 50% voted for the relatively-right Hillary Clinton.
13:03:20 <WilhelmVonWeiner> I hope a suitable, decentralised or distributed solution to social media will exist some day. I assume it'll rely on everybody being their own node.
13:04:24 <corecode> what kind of social media
13:04:28 <corecode> like twitter?
13:04:31 <corecode> or irc?
13:04:35 <WilhelmVonWeiner> former
13:05:19 <WilhelmVonWeiner> latter appears to work for some reason. Probably because it's (generally) topic-focused and impersonal. Cold, calculating, other c words
13:05:23 <john_cephalopoda> WilhelmVonWeiner: Filter bubbles exist everywhere, no matter if you are using centralized or decentralized media. You always have ways to block out undesired opinions.
13:05:49 <corecode> yes
13:06:00 <corecode> plus we're used on irc that there are trolls
13:06:13 <corecode> tho i've been called all kinds of things on irc
13:06:24 <WilhelmVonWeiner> It's not just the filter bubbles, it's the features I've mentioned, too. But I see federation as too fragmented and too personal-political and bureaucratic to be meaningful.
13:06:44 <john_cephalopoda> I actually think that mastodon makes it more obvious that there is a bubble and doesn't let you believe that you are in a majority group.
13:06:54 <WilhelmVonWeiner> corecode: have you ever been called a badger-scratcher
13:07:00 <corecode> no!
13:07:22 <WilhelmVonWeiner> you bark-nibbling frothhuffer
13:07:35 <john_cephalopoda> forth-huffer
13:08:20 <WilhelmVonWeiner> IN BREATHE OUT BREATHE
13:08:33 <john_cephalopoda> BREATHE WITH ME
13:08:48 <WilhelmVonWeiner> ME ' BREATHE WITH surely
13:08:54 <john_cephalopoda> https://www.youtube.com/watch?v=6_PAHbqq-o4
13:10:58 <WilhelmVonWeiner> i miss the prodigy.
13:14:38 <john_cephalopoda> I think that IRC is just as much of an echo chamber as Twitter, Mastodon or any other social network.
13:15:46 <WilhelmVonWeiner> Only on programming opinions. 
13:20:19 <john_cephalopoda> I think that it is quite natural that people with similar view group together.
13:20:53 <john_cephalopoda> I wouldn't befriend a neo-nazi in real-life, just as little as I'd follow one on any social media.
13:22:01 <john_cephalopoda> It's just important to remember that there _are_ actually people with other opinions out there, and that you might actually be a minority.
13:24:25 <WilhelmVonWeiner> following isn't befriending
13:27:32 <corecode> what's the problem with people grouping up?
13:29:11 <the_cuckoo> depends on why they're grouping up i would have thought
13:30:04 <the_cuckoo> things like going to football matches - that's bad - very bad
13:30:12 * the_cuckoo shakes his sadly
13:42:03 <john_cephalopoda> the_cuckoo: What's wrong about going to football matches?
13:42:41 <john_cephalopoda> WilhelmVonWeiner: Following means "I like to hear what that person has to say". I don't really feel like listening to xenophobic ramblings all day.
13:52:35 <WilhelmVonWeiner> I don't think that's what someone'll spend *all* their day doing.
13:53:10 <the_cuckoo> john_cephalopoda: nothing at all :) - as long as i don't have to go
13:54:45 <the_cuckoo> really can't stand social media either - absolutely no interest in whatsoever
13:59:28 <Zarutian> I was recently asked to define what social media is about to someone who doesnt do the 'net much: Screeching gossiping washerhags with busy body attitude is what it boiled down to.
13:59:41 <john_cephalopoda> the_cuckoo: I'm on mastodon, following a few people who post a few times per week each. It's nice for keeping track of interesting projects. I'm posting about my own projects from time to time.
14:03:18 <the_cuckoo> don't know that one, but i guess there are varying degrees of social media - you could class irc, forums and slashdot as social media, but they at least aren't trying to be all things to everyone - much more focussed niches
14:04:26 --- join: travisb (~travisb@71-13-2-250.static.ftbg.wi.charter.com) joined #forth
14:05:41 --- quit: tabemann (Ping timeout: 264 seconds)
14:07:00 <the_cuckoo> i hang out on a couple of forums to pass the time and keep abreast of current news (or rather, opinions about current events) and i kinda like the anonymity of that - if you get it into an argument about politics or religion, it's not like you're risking life long relationships :)
14:08:06 <the_cuckoo> social media is about who knows who, and there is serious risk of finding out more than you want to about your friends and family :)
14:16:04 <the_cuckoo> just looking at the mastodon site - that's quite nice i think - it might actually works a good base for corporate communicates too (oddly enough, given their ethos :))
14:20:00 <the_cuckoo> one of the things which has pissed me off intensely is how chat has got worse - irc excepted, the good ones are gone and replaced by microsoft tech - teams and skype - or are ridiculously restricted without paying masses of money (slack)
14:22:01 <the_cuckoo> all of them want to own *your* conversations - i would rather my conversations where at least readily available for mining - even if i'm offline - full local logs which i can just grep would be ideal
14:27:34 <john_cephalopoda> There is Matrix and XMPP. XMPP has a billion extensions and no client supports the right ones, so basically you have to use the same client or some stuff won't work.
14:27:42 --- join: yrm (~yrm@KD106130207224.au-net.ne.jp) joined #forth
14:27:46 <john_cephalopoda> Matrix is quite nice but there is only one client for it that supports video calls.
14:30:42 <the_cuckoo> i've never understood why all of that needs to intergrated into one thing :) - i mean, jeez, the video conferencing and the chat client don't have to be the same thing - nice if the chat client provides a handy button to fire it up... but beyond that? sheesh
14:32:00 <the_cuckoo> different things - do not need to be one thing, and in fact, really you'd want to have the options available - not just one
14:32:44 <the_cuckoo> ssh client to the other persons machine for example? using the chrome ssh extension (check it out - it's nice :))
14:34:58 <the_cuckoo> <person> [ chat | video | ssh | http | ... | forget ] 
14:36:12 <the_cuckoo> <people> [ chat | video | ... | forget ]
14:36:19 <the_cuckoo> :p
14:37:30 --- quit: yrm (Quit: yrm)
14:37:42 <the_cuckoo> oh well - it amused me :)
14:40:29 --- quit: dys (Ping timeout: 246 seconds)
14:43:26 --- join: yrm (~yrm@KD106130207224.au-net.ne.jp) joined #forth
14:55:41 --- join: dys (~dys@tmo-120-87.customers.d1-online.com) joined #forth
15:03:58 --- join: yrm_ (~yrm@KD106130207224.au-net.ne.jp) joined #forth
15:03:58 --- quit: yrm (Read error: Connection reset by peer)
15:04:07 --- quit: travisb (Ping timeout: 272 seconds)
15:32:17 --- quit: yrm_ (Ping timeout: 268 seconds)
16:09:20 --- join: yrm (~yrm@KD106130207224.au-net.ne.jp) joined #forth
16:12:04 --- quit: yrm (Read error: Connection reset by peer)
16:22:23 --- join: yrm (~yrm@KD106130207224.au-net.ne.jp) joined #forth
16:30:39 --- join: rdrop-exit (~markwilli@112.201.168.172) joined #forth
16:40:43 <rdrop-exit> c(_) Good morning Forthwrights :)
16:41:23 * Zarutian notes its fourty minutes past midnight UTC
16:41:29 <Zarutian> morning enough!
16:41:49 <rdrop-exit> 08:41 here
16:51:55 <`presiden> it's always morning on irc
16:52:11 <`presiden> rdrop-exit, and good morning too O/
16:52:11 <Zarutian> "even in the afternooon"
16:52:51 <rdrop-exit> Hi Zarutian and `presiden
16:58:16 --- join: dave0 (~dave0@193.060.dsl.syd.iprimus.net.au) joined #forth
16:58:48 <dave0> hi
16:59:07 <crc> Good evening 
16:59:08 <rdrop-exit> Hi dave0
16:59:09 --- join: nighty- (~nighty@b157153.ppp.asahi-net.or.jp) joined #forth
16:59:18 <rdrop-exit> Hi crc
16:59:55 <dave0> hi rdrop-exit, crc 
17:00:22 <rdrop-exit> Hi John-Boy
17:00:27 --- quit: john_cephalopoda (Ping timeout: 258 seconds)
17:01:21 <rdrop-exit> (childhood joke)
17:02:18 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth
17:07:22 <PoppaVic> rdrop-exit: dude, I'm old enough ;-)
17:08:08 <rdrop-exit> Cool :)
17:20:34 --- quit: yrm (Quit: yrm)
17:25:09 <crc> Tomorrow I'll be attempting to finish rewriting my keyboard driver in forth and starting work to parse the MBR partition table
17:27:05 <rdrop-exit> Native PC Forth?
17:27:10 <crc> yes
17:27:26 <rdrop-exit> Cool
17:28:16 <crc> (semi-native, the forth runs in my misc vm, but can access the raw hardware)
17:28:32 <rdrop-exit> I see
17:28:41 <PoppaVic> rdrop-exit: btw, "use "jim-bob" and fewer will catch on ;-)
17:28:58 <rdrop-exit> :)
17:30:51 --- join: travisb (~travisb@2600:1700:7990:24e0:a106:f1e:e4eb:7e2d) joined #forth
17:36:27 <rdrop-exit> I stick to lowest common denominator POSIX+terminal on the PC side.
17:37:58 <rdrop-exit> Only the minimum necessary for a rudimentary umbilical host.
17:40:42 <crc> I have several options (basic terminal, curses, gui editor based) on PC and iOS; have't actually done an embedded variant yet.
17:41:12 <john_cephalopoda> Hmm, it would be nice to have some Forth graphics standard.
17:41:40 <john_cephalopoda> Terminal apps can do a lot but there's a limit.
17:45:02 <rdrop-exit> I only use a PC as a development host, not as a target, haven't had any need for host graphics.
17:47:22 <rdrop-exit> I'm only interested in external standards, don't care for Forth standards.
17:47:50 <crc> I'll eventually have a graphics option on at least a few of the systems I use. (One of my sons and I have some unreleased prototypes for this running on iOS and FreeBSD)
17:51:27 * Zarutian might write some minimal VNC/RFB support in Forth
17:51:56 <crc> Both are  just using a memory mapped framebuffer (using UIImageView on iOS an SDL on BSD); it's slow, but functions ok for my limited needs
18:01:21 <KipIngram> Well, I just used the TSC counter to do a careful timing of my NEXT.  It does vary - I guess what else is happening on the computer intervenes - but with 1000 samples averaged in it looks like it's somewhere in the 1.9 to 2.5 ns range.
18:10:19 <yunfan> hi i just found my old arduino duemilanove boards yesterday, and got a ili9341 lcd for it, now i want to play a forth on it, which one would you guys recommend?
18:12:24 <rdrop-exit> No idea
18:16:51 <crc> eforth (https://github.com/DRuffer/328eforth), if its a duemilanove w/the atmega328.
18:18:11 <KipIngram> Ok, tested an empty : definition.
18:18:20 <crc> retro11 could run on some arduinos as well (https://bazaar.launchpad.net/~crc-x/retro-language/retro/files/head:/vm/embedded/avr/arduino/), though it needs some additional hardware (an sd card IIRC)
18:18:26 <KipIngram> Looks like the overhead of that (making something a word vs. inlining it) is about 6.5 ns on my Mac.
18:19:36 <rdrop-exit> ITC?
18:22:39 <KipIngram> Yes, rdrop-exit; this system is indirect threaded, and also requires some extra register juggling in NEXT and docol due to the Mac's MACH0 executable format and it's requirement for total position independence.
18:23:11 <KipIngram> Both NEXT and docol have two extra register-register additions in them, that wouldn't be required in a pristine system.
18:24:39 <rdrop-exit> Is the MACH0 format the only one supported?
18:25:35 <KipIngram> Yes, as far as I could tell.
18:25:45 <KipIngram> I suppose it's possible I was reading dated documentation.
18:26:01 <KipIngram> I'm not too terribly bitter over it.
18:29:49 <crc> rdrop-exit: I've been unable to find any other supported executable format for macos
18:31:00 --- quit: travisb (Ping timeout: 250 seconds)
18:36:58 <rdrop-exit> I see
18:41:42 <KipIngram> It baffles me.  Your application is deployed in a virtual memory space anyway, so I don't see the need for the requirement.  Every single time I run it, everything is at exactly the same (virtual) address.
18:42:19 <KipIngram> So I have no clue what they gain by requiring position independence when they put you in the same spot every time anyway.
18:43:16 <yunfan> crc: looks like the only choice :D
18:45:49 <yunfan> looks like it could be also run on arduino nano which had atmega328 too
18:52:18 <rdrop-exit> KipIngram: Probably a historical legacy from its Mach kernel origins
18:53:44 <KipIngram> Yeah, I suppose so.
18:54:03 <KipIngram> It was quite frustrating at first, until I figured out a reasonably "low cost" way of coping.
18:54:46 <KipIngram> I decided that I was still in the ballpark, and that if I was really THAT uptight about performance at some point then some custom aseembly was probably in order.
18:54:47 <PoppaVic> KipIngram: except for Estwing hammers are cheap ;-)
18:55:22 <PoppaVic> Estwing[,COMMA]
18:55:38 <KipIngram> I guess I've decided that the "stock Forth" approach needs to be GOOD, but doesn't have to be PERFECT.
18:56:12 <PoppaVic> Perfect costs more; how's yer bird-proofing?
18:56:24 <KipIngram> I mean, after all, simply by stringing primitives together in a definition we are incuring the NEXT overhead.
18:56:38 <KipIngram> incurring.
18:58:05 <KipIngram> I'd enjoy seeing some optimization tools, like a tool to automatically expand a definition formed from a series of primitives into one with all the non-NEXT parts of those primitives strung together.
18:58:29 <KipIngram> When you DID have a need for that last increment of performance, the system could help you along.
19:01:09 <rdrop-exit> The doorway to optimization is SRT+NCI, either that or just rewrite the bottlenecks in assembly.
19:02:31 <rdrop-exit> I no longer do ITC, SRT+NCI on a real machine for speed, SRT+NCI on a virtual machine for portability.
19:02:58 <rdrop-exit> (or size).
19:03:55 <rdrop-exit> ITC and DTC are an odd middle gound.
19:05:42 <KipIngram> Yeah, I do see that.
19:06:02 <KipIngram> I just became very fond of ITC, and I have it very nicely "in my head."
19:06:10 <KipIngram> It has always just "felt right" to me.
19:06:45 <rdrop-exit> ITC has nice regularity and "reflection" properties.
19:06:52 <KipIngram> Yes.
19:07:05 <KipIngram> Sort of like Bach vs. other composers.
19:07:10 <KipIngram> Very... theoretical
19:07:45 <KipIngram> Mozart, on the other hand... it still follows all the rules, but he manages to surprise you nonetheless.
19:08:41 <rdrop-exit> I think Chuck finally came to the same conclusion when he tried to siliconize Forth.
19:08:50 --- quit: dave0 (Quit: dave's not here)
19:10:05 <KipIngram> Well, when you go to hardware them "primitives" become hardware operation, and thus look like opcodes.
19:10:17 <KipIngram> Just the fact that you're going to hardware changes a lot about how it's going to look.
19:10:21 <rdrop-exit> Hence Machine Forth.
19:13:08 <rdrop-exit> There has to be a line between Forth as a development environment and Forth as a "machine".
19:15:33 <KipIngram> When you have hardware behind your primitives, you lose the need to attach any "address related" path to them at all.  You don't need indirecto pointers - you don't need direct pointers.  You just put the opcodes right in.
19:15:55 <KipIngram> Then the definition calls look just like subroutine calls - perhaps with a "one-bit opcode."
19:16:02 <ttmrichter> rdrop-exit: SRT?  NCI?
19:16:11 * ttmrichter isn't familiar with those particular TLAs.
19:16:17 <KipIngram> Chuck had one machine that used the MSB of the 16-bit cell to differentiate between 15 bit addresses and three 5-bit opcodes.
19:16:23 <rdrop-exit> Subroutine Treaded Code + Naticve Code Inlining
19:16:27 <KipIngram> That 1 bit was an *opcode* for a 16-bit instruction.
19:16:30 <ttmrichter> Ah.
19:16:59 <KipIngram> Therefore that really becomes an SRT machine.
19:17:01 <ttmrichter> I should have caught what SRT meant.
19:17:19 <rdrop-exit> The nice thing is that an application can encompass both the environment and the machine.
19:17:21 <KipIngram> With a single 1-bit opcode that takes a 15-bit operand, and a bunch of 5-bit opcodes that take no operands.
19:18:16 <ttmrichter> So now we'd use 4 2-bit opcodes with 6 5-bit opcodes.  :D
19:18:36 <ttmrichter> (Well, for a 32-bit MCU at any rate.)
19:18:38 <PoppaVic> two-bit is all too true
19:19:10 <KipIngram> ttmrichter: Yes, I've played with that idea
19:19:12 <rdrop-exit> That's where the main differences between a real machine and a virtual machine lie, the ISA design.
19:19:31 <KipIngram> Lets you have not just unconditional call, but conditional call and unconditional and conditional jump.
19:19:40 <KipIngram> The unconditional jump comes in very handy for tail optimization.
19:20:02 <rdrop-exit> But the techniques used above the machine are the same when you use SRT/NCI.
19:20:06 <KipIngram> What I wound up doing was having separate fetch and execution units.
19:20:16 <rdrop-exit> Whether the machine is real or virtual.
19:20:20 <KipIngram> The fetch unit processed the "two-bit opcodes," and passed the 5-bit ones on to the execution unit.
19:20:33 <KipIngram> And up until you came to a conditional branch, you can pipeline that.
19:20:56 <KipIngram> The fetch unit also had to look at the 5-bit opcodes well enough to detet the returns.
19:21:17 <KipIngram> In fact, it could pre-process them out, so the execution unit never even saw them.
19:22:41 <KipIngram> I tinkered with a "flag passing mechanism" between the two units, so that when your available information allowed you could separate the calculation of branch decisions from the branch itself.
19:23:17 <KipIngram> If the information is available early, the execution unit could determine the branch direction and post a flag to the fetch unit, hopefully before the fetch unit fetched the decision code. 
19:23:39 <KipIngram> When that worked, the fetch unit would know which way to go without having to stop and wait.
19:24:05 <KipIngram> It worked at least for fairly standard linked list processing.
19:24:20 <KipIngram> Instead of 
19:24:27 <KipIngram> while (p) {
19:24:30 <KipIngram> ...
19:24:32 <KipIngram> ...
19:24:34 <KipIngram> ...
19:24:36 <KipIngram> p = p^.next;
19:24:38 <KipIngram> }
19:24:39 <KipIngram> You'd do
19:24:50 <KipIngram> while (q) {
19:24:59 <KipIngram> q = p^.next;
19:25:01 <KipIngram> post(q);
19:25:04 <KipIngram> ...
19:25:06 <KipIngram> ...
19:25:08 <KipIngram> ...
19:25:10 <KipIngram> }
19:25:31 <KipIngram> That's kind of a sloppy way of writing it.
19:25:54 <KipIngram> And it wouldn't always be possible - something knowledge of the decision would be "last minute."
19:26:45 <KipIngram> Anywa, the goal was for the fetch unit to process out all of the subroutine call/return overhead, and keep the exec unit fed with a stream of opcodes.
19:29:22 <rdrop-exit> I think hardware stack machines have great untapped potential for deterministic real time.
19:30:58 <rdrop-exit> Where consistent timing rather than average speed is the thing.
19:31:29 --- join: gravicappa (~gravicapp@h37-122-126-13.dyn.bashtel.ru) joined #forth
19:32:01 --- quit: dddddd (Remote host closed the connection)
19:32:12 <rdrop-exit> Have to walk the dogs and get ready for poker with the buds, catch you all tomorrow. Keep on Forthin'
19:32:34 --- quit: rdrop-exit (Quit: Lost terminal)
19:48:14 <crc> ttmrichter: srt is subroutine treading, nci is native code inlining
20:21:49 <ttmrichter> crc: Got that, thanks.  :)  I just never saw "SRT" used before.
20:22:08 <ttmrichter> NCI, too, but would have been more obvious if I'd grokked SRT.
22:31:28 --- quit: reepca (Ping timeout: 255 seconds)
22:34:01 --- join: travisb (~travisb@2600:1700:7990:24e0:a106:f1e:e4eb:7e2d) joined #forth
23:38:43 --- quit: mark4 (Quit: Leaving)
23:59:59 --- log: ended forth/19.02.24