00:00:00 --- log: started forth/19.03.09 00:38:27 --- quit: tabemann (Ping timeout: 250 seconds) 01:12:33 heh - the refactoring i was analysing last night for the threaded player is working out well :D 01:13:05 cleans up a lot of stuff 01:17:19 my only concern is that if you leave an instance of the graph played on the stack while playing a duplicate, you may run into thread safety issues - not entirely sure how best to resolve that one 01:17:51 if you attempt to do anything with it that is 01:34:25 couple of other things comes out of it - multiple players - which isn't anything new in vml, but nice to make it available here - there are, however, a couple of restrictions (relating to the event queue and audio which need to be taken into account) - and iirc, the osx ain't gonna like it 01:35:17 on the latter - osx simply doesn't like gui components running on a thread other than the main process thread - peculiar, but there you go 01:36:03 which means i need a fallback to non-threaded playout - luckily of course, that's what i had to begin with, so no big issues there 01:37:31 should be all fine on windows too 01:39:15 --- join: xek (~xek@apn-37-248-138-83.dynamic.gprs.plus.pl) joined #forth 01:39:23 on thread safety - meh - this is a developers tool - if the dev screws it up, it's their look out 02:02:31 --- quit: ashirase (Ping timeout: 245 seconds) 02:07:34 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth 02:16:28 end of the day, it comes down to this for the basic 'play on main thread' or 'play on thread' decision: 02:16:35 s.teach( "player-create", [] ( rpany::stack &s ) { s += player_ptr( new player_thread( s ) ); } ); 02:16:37 s.teach( "player-play", [] ( rpany::stack &s ) { s.pull< player_ptr >( )->play( ); } ); 02:16:39 s.teach( "player-start", [] ( rpany::stack &s ) { s.coerce< player_ptr >( )->start( ); } ); 02:17:44 ie: player-create player-play [consumes graph, has no output] or player-create player-start [consumes graph, leaves on stack] 02:18:05 i think that's kinda pretty 02:19:10 now i just need to extend to have the do other stuff - pause, ffwd, rew, seek, change graph etc etc 02:20:48 and the whole thing extends to transcoding - store:output.mp4 player-create followed by player-play or player-start 02:21:09 player's a shit name though 03:12:34 what language is that? 03:18:28 c++ 03:19:46 the [] ( .. ) { } defines a lambda - in this case, because i have no captures (which would normally be specied in the opening [ ]), they are just functions 03:21:02 very powerful things lambda's - introduced in c++11 (like a lot of the sane things in modern c++ - the old insane stuff still works, but jeez, you wouldn't want to use it...) 03:25:38 hence, the s.teach thing just provides a word to function mapping on the stack instance (you can have as many stacks as you want - they can share dictionaries or have their own) - but ultimately, to run most words, a token is streated as just a look up in the map to obtain the definition and execute it - the only real overhead is in the look up 03:26:09 (and that can be optimised using hashing i guess) 03:27:19 'twerks for me anyway - but i'm no purist :) 03:27:41 forth is better :-) 03:28:16 i really like how you can drop back into the interpreter while you're compiling things 03:28:24 there's probably a name for that 03:30:42 like say i wanted to put an array in a word, but i want it to be a sorted array... i could drop back into the interpreter and sort the array using the programs own sort function 03:30:58 I wonder if it's possible to do better than Forth, maybe not. 03:31:16 What's easier to implement than a linked list and a list of addresses? 03:31:51 siraben: but you're not limited to that! 03:33:18 "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. It" 03:33:37 Tony Hoare said that 03:33:49 Forth is the former 03:34:26 i would like to see if forth's idea of threaded code ie. just a list of addresses would work for lisp 03:34:59 Hm., how to implement a lisp 03:35:27 i think lisp is more well known than forth 03:35:45 Oh yes, by miles. 03:37:00 dave0: :) - it's horses for courses really - in the case of my video library, i have a stable, well tested clutch of functionality which is exposed as a c++ api - constructing and manipulating these objects with the api is a pain, but doable - treating them as stack items trivialises it 03:37:41 i don't need a lower level of interaction for this side of things 03:39:58 dave0: Forth wins out in size vs. speed and easy of implementation because the underlying architecture is inherently stack and register based 03:41:07 it's not very easy :-) 03:41:33 i did a bit of coding today and it took a while 03:59:01 siraben: that entirely depends on what you're implementing - i won't dispute it as a general rule, but in the case of specifics... things can get very complicated indeed 03:59:58 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 04:00:27 and i also think it doesn't matter - the path to hell is paved with premature optimisation - define at the high level, refine at the low if it's deemed necessary 04:04:28 i started the rpany system by implementing it in bash first - https://gitlab.com/lilo_booter/bts/blob/master/README.md - it allowed me to play with the concepts - only when i felt it was defined enough did i attempt to implement in c++ 04:06:56 and if i feel like it, i could reimplement again at a lower level (i might at some point, but it's not high on my list of priorities until i have at least stressed the system i have - the video and robotics stuff doesn't even scratch the surface is my feeling) 04:09:28 bottom up v top down are the most common approaches - i start somewhere in the middle and wobble between the extremes :) 04:12:53 ^ personal philosophy - not saying it's the only approach, the best approach or even a good approach - it just works for me :) 04:40:25 the_cuckoo: Hm. My first Forth was right in Z80 assembly 04:40:29 So I like bottom up 04:40:49 Well I have written stuff top down before, a compiler first, then an assembler, then the VM last 04:41:46 yeah - so was mine :) 04:42:29 i'm certainly not disputing that it's a valid approach - i think all approaches that work are valid 04:42:51 --- quit: proteusguy (Remote host closed the connection) 04:50:53 my implementation was actually published in the memotech magazine - am sure i would cringe if i looked at it now :) 04:52:22 had an mtx 512 - was my last 8 bit machine - probably the machine i have the greatest fondness for too (the black brushed metal case was a work of art, the keyboard was solid, the built in assembler was magnificent) 04:59:36 anyway - formative draft of my threaded player is working - checks out with valgrind too - just need a better name than 'player' - drawing a blank though 05:00:26 could just call it 'inigo' i guess - i always liked that name :D 05:00:41 --- quit: nighty- (Quit: Disappears in a puff of smoke) 05:12:22 meh - think i'll check in as a draft and put it to bed for the day (it's 'work' stuff in a round about manner anyway) - wanna get back to the raspi :D 05:40:57 * the_cuckoo breaks out the breadboard 05:54:18 oh - if anyone is running ubunntu 16.04 and wants to see if my system is any good, i can provide a build 05:55:09 small ish - 60MB - requires a few standard packages - otherwise runs from a directory 07:02:06 --- nick: X-Scale` -> X-Scale 07:05:59 SEE done! 07:11:51 and after rewiring my lighting so i could see what i was doing, locating a multimeter/glasses and hunting around for a working led, i can confirm that rpany-pi works as demonstrated (whether it works for everything else remains to be seen) 07:13:15 can see myself getting distracted with 3d printing shortly 07:25:51 client/server stuff works too 07:28:55 f it - i'm going back to video - itches to scratch 07:28:58 :p 08:07:50 presiden: how so? 08:37:37 --- quit: dave0 (Quit: dave's not here) 09:13:19 actually, the video stuff i did this morning provides quite a nice mechanism for the rpany-pi stuff too (introducing threads for long running stuff), so now i'm conflicted - might just go with wiring up some buttons on the pi, establish a client connection vmlbatch and map switches to transport controls 09:13:39 ... getting silly, but remaining cute 09:19:32 --- join: DKordic (~user@178.220.204.203) joined #forth 09:46:30 --- quit: Zarutian (Read error: Connection reset by peer) 09:46:59 --- join: Zarutian (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth 10:36:10 --- quit: cantstanya (Remote host closed the connection) 10:38:31 --- join: cantstanya (~chatting@gateway/tor-sasl/cantstanya) joined #forth 10:58:11 --- quit: groovy2shoes (Quit: moritura te salutat) 11:22:46 --- quit: gravicappa (Ping timeout: 255 seconds) 11:39:08 --- join: mtsd (~mtsd@94-137-100-130.customers.ownit.se) joined #forth 11:59:46 --- quit: Keshl (Read error: Connection reset by peer) 11:59:57 --- join: Keshl (~Purple@207.44.70.214.res-cmts.gld.ptd.net) joined #forth 12:19:34 * the_cuckoo grins 12:29:02 * crc frowns 12:30:57 now we have balance :) 12:40:46 :D 12:41:20 this is all proving a bit to easy - no real challendge - coming together really fast 12:43:15 Hmm, there is no podcast about forth. 12:43:36 have exposed words to interact with the which i have now renamed and may later change to or [on account of job-xxxx or task-xxxx having fewer letters to type], and xxxx includes speed, pitch and seek 12:44:15 complete control over the play head in 3 words 12:44:19 * the_cuckoo likes 12:47:13 john_cephalopoda: what would such a podcast try to cover? 12:53:58 just dropped a box of 250 leds on the floor - they were sorted by colour - umm - not any more :( 12:54:36 crc: About forth, of course! ;þ 12:56:13 forth 12:56:36 a very broad, not well defined topic 12:57:12 which few of us are actually doing... still, there are conversations to be had i think 12:58:35 If one existed, I'd add it to the (rather long) list of podcasts I listen to 12:58:53 i've never listened to any 12:58:56 crc: Well, there are many things to talk about with forth. Dozens of implementations, etc. 12:59:07 not going to start one myself though 13:04:47 we could name it "fun with forth" in honour of sheldon cooper 13:04:54 Me neither 13:05:06 I'm more into audio dramas. 13:10:58 I'm currently subscribed to 91 podcasts (down from around 140 around six months ago), mostly history and tech topics 13:14:44 --- quit: mtsd (Quit: leaving) 13:19:04 Lol. 13:19:19 I listened to Wolf359 and that's basically it. 13:24:13 --- join: chunkypuffs (~chunkypuf@2a01:4f9:2b:16d5::1) joined #forth 13:24:30 pizzapizzahut.com 13:24:47 Hey, noob here 13:24:51 Got a few questions! 13:25:01 recently been playing around with forth (some guy at my makerspace teaching me all sorts about it) 13:25:09 But one thing slipped, he mentioned it but I've forgotten about it entirely 13:25:17 Forth is compiled, but how does it do this in real time? Is it just in time? 13:25:24 wrong window :( 13:25:37 he has an STM-8 that we were screwing with, and he had mentioned that every action we do is enacted in realtime, despite it being a compiled language 13:26:00 we were using e4thcom to program the device, again, in realtime, but how is it true that forth is compiled, if we were able to interact with it like that? 13:27:11 that's what it does 13:27:18 it is just in time? 13:27:29 typically, forth code is compiled as definitions are entered and the compiled code canmbe run interactively 13:27:41 we were doing stuff like: 13:28:11 : readx 3 ADC! ADC@ ; 13:28:11 : ready 4 ADC! ADC@ ; 13:28:11 : lnkill 13 tx! 27 tx! 91 tx! 75 tx! ; 13:28:11 : joy begin lnkill readx . ready . ?key until drop ; 13:28:38 How is it possible that this tiny microcontroller reacted to all of that input, instantly, and gave the output instantly, if forth is compiled? 13:29:05 the code between : and ; is being compiled as it's entered 13:29:10 --- quit: xek (Remote host closed the connection) 13:29:17 entered? 13:29:34 --- join: xek (~xek@apn-37-248-138-83.dynamic.gprs.plus.pl) joined #forth 13:29:42 typed or read from a file 13:29:52 so when I press enter 13:29:56 yes 13:29:58 okay, so it's a just in time compiler? 13:31:00 not really - jit is about optimisation at run time - forth is more about compiling as you define - the compilation is quick so you don't notice it 13:31:28 This is one of those things that people don't believe 13:31:36 * crc thinks JIT has a different meaning 13:31:37 such as leaving high voltage capacitors on a shelf, they charge up on their own 13:31:51 modern engineers would say "Haha, that can't happen silly you're defying the laws of physics!" 13:32:15 forth has an incremental compiler 13:32:44 crc: i would be interested to hear your definition of JIT after this discussion :) 13:32:46 but in reality there's a problem called dialectric absorption that means the charge that you previously charged it with a month before coming out 13:32:58 similarly, my friends aren't believing me when I say forth compiles in realtime 13:33:47 nice analogy but not entirely related :) 13:34:33 these are both things I had no idea about until 2 days ago 13:34:39 makerspaces are wonderful 13:34:48 heh - seconded :) 13:35:59 So, what is accurate to say? 13:36:04 Forth is compiled in realtime? 13:36:19 chunkypuffs: yes 13:36:24 absurd 13:36:29 this is a unique thing? 13:36:40 Does anything else do this? Why do people disbelieve me when I say that? 13:38:15 not necessarily unique. I've done similar things with LISP and Smalltalk in the past 13:38:27 I don't see that it's any different that anything else. 13:38:41 When I say "gcc hello.c" the file hello.c is compiled. 13:38:49 When I say : hello ... ; hello is compiled. 13:38:52 It's the same thing. 13:38:59 You tell the system to compile something and it compiles it. 13:39:47 The main difference with Forth is that you compile smaller pieces at a time. 13:40:22 the_cuckoo: it is a form of JIT, but without the baggage (typically) that accompanies things like the JVM 13:40:33 why does it work so fast 13:40:39 so fast, in fact, that it's un-noticeable 13:40:46 Because you're compiling only small amounts of code at a time. 13:40:54 I can't think of anything that I could do on this stm8 microcontroller that would take time 13:41:16 the boot time is microseconds, and the compile time is microseconds 13:41:53 KipIngram: compilation of C is different in that it's not happening alongside execution 13:42:11 I think it is the same - what's different is the level of granularity. 13:42:27 The friend who is teaching me forth almost like a teacher at this point suggested that Forth is like an operating system 13:42:30 how true is the statement? 13:42:39 Because you get a shell, you can do stuff inside. 13:42:52 chunkypuffs: And yet if you were to study your way through exactly what Forth is dong during those microseconds, you'd find that it all made total sense. 13:42:56 It's not "magically fast." 13:43:04 the second time it runs, it's not compiling right? 13:43:30 chunkypuffs: typically, the forth compiler will be fast as it does less optimizations and the functions are shorter/simpler 13:43:41 so my : readx 3 ADC! ADC@ ; 13:43:41 : joy begin lnkill readx . ?key until drop ; 13:43:48 that isn't compiling every single time, right? 13:43:53 Um, in mine, chunkypuff, it compiles only when I tell it to. 13:43:58 If I say 13:44:02 : word foo bar bam ; 13:44:07 : word foo bar bam ; 13:44:19 It will do the same thing, exactly, both times, and I'll have two copies of the word in the dictionary. 13:44:32 forth can be an OS; this isn't as common outside the embedded world though 13:44:38 oh so when the word is in the dictionary, that's the moment of compilation? 13:44:49 and when you call word it's running the compiled thing 13:44:53 yes 13:44:55 the compilation is upon definition? 13:44:56 Compilation is what puts it in the dictionary. 13:45:02 Right. 13:45:13 When you type the word by itself, it looks it up in the dictionary and executes it. 13:45:19 Could someone give me something that would take a long time to compile? 13:45:30 : starts the compiler and ; ends it 13:45:32 say a minute 13:45:46 That would be a huge amount of code. 13:45:48 that would depend on the machine you're running on 13:46:11 STM8 13:46:13 tiny thing 13:46:32 Why do you want that? If you have a specific learning goal or something, maybe there's a better way to get at it. 13:46:50 I just want to witness slowness 13:46:54 to see how/why/where it occurs 13:46:55 :-) 13:46:57 either way, it's not the point - you break things down so they compile quickly 13:47:05 It would be easier to make a word that RUNS for a minute. 13:47:21 Well, you really break them down so you can UNDERSTAND THEM well. 13:47:29 Compiling quickly is a nice fringe benefit. 13:47:46 the two tend to go hand in hand, but yes - understanding is key 13:47:47 But the idea, chunkypuffs, is to define words that are so short and simple that they "couldn't possibly be wrong." 13:48:02 I.e., you can hold the whole word in your mind and just *see* that it's correct. 13:48:06 Then you test it anyway, of course. 13:48:59 What I try to do is design from the top down, and then code from the bottom up. 13:49:32 Maybe a bad analogy, but ZFS has the same goal with fragmentation 13:49:40 you neatly organise things in ZFS to reduce fragmentation 13:49:59 I.E media/music instead of large folder structures 13:50:45 Okay, are you saying many words is better? 13:50:53 many many words referencing other words 13:51:05 Well, it's easier for us to understand and build the program that way. 13:51:07 for example, my code which has readx and ready, which is referenced by joy 13:51:19 Obviously, it introduces call/return overhead, so your system needs to do calls / returns very efficiently. 13:51:21 Forth does. 13:51:21 two words, referenced in one word 13:51:31 That would be taking it a little far. 13:51:42 Our short-term memories can generally hold order of 7-8 things at once. 13:51:52 So "7-8-ish" word long definitions tend to work well. 13:52:13 They also fit nicely on one line, so you can also think in terms of "one line definitions" / "one liners." 13:52:24 It's not a hard and fast rule - those numbers. 13:52:28 It's just a qualitative thing. 13:52:40 Maybe your short term memory is great and you can hold 15 things. 13:53:00 Why is forth not used in the real world? 13:53:04 Or, if it is, where is it used? 13:53:17 The first thing I thought when I was shown forth was "oh my god, rot is just a thing?" 13:53:20 It is used, in niche places. 13:53:35 rot should or could allow you to do transformation matrices faster, or easier 13:53:43 Is this assumption wrong, bad, misleading? 13:53:49 But we've talked about this. My opinion is that one of the reasons is simply that it doesn't "integrate" easily with all the other tools, and the "mind set" of Forth is different too. 13:53:57 concepts are used in many places - i would cite post script printers as a good example 13:54:13 Yes - postscript uses something very similar, though I doubt they call it Forth. 13:54:26 Well we have an 19x24 LED array here, and I want to make it a bit like that sand game 13:54:27 I've heard that NASA has used Forth in space probes and stuff. 13:54:28 they don't, but they don't need to 13:54:29 do you know the sand game? 13:54:29 Forth is used in many space applications. 13:54:35 * crc uses forth all the time, but most of my code isn't public 13:54:35 ^ 13:54:40 https://dan-ball.jp/en/javagame/dust/ 13:54:47 this game, if anybody remembers it, it's cool as hell 13:55:00 and if you wanted to do this with an arduino, and an led array with a joystick, maybe you could do it 13:55:08 there's a library for the led array, it's great, what can't you do? 13:55:18 well maybe you can't interact with it the same way because you're limited by the library right? 13:55:36 chunkypuffs: http://powdertoy.co.uk/ 13:55:39 IDK why it seems this way, but forth would allow you to write less code and produce something more accurate to what you desire 13:55:45 problem with an arduino is that it doesn't have the spec for forth style compilation 13:55:57 doesn't really need it either 13:56:02 chunkypuffs: Powdertoy is just as that game, but it is faster since it isn't running in the browser. 13:56:17 yeah it was just something I remember well from when I was a kid 13:56:37 it was equivalent to my newgrounds days or what would be many older people's first voyage into the internet 13:56:40 chunkypuffs: Another thing is that Forth kind of likes to own your whole system. 13:56:46 It's not the best at playing with others. 13:56:52 well I'm not thinking about gforth 13:56:52 Not in its "pure" form at least. 13:56:53 Arduino isn't a fast machine. Running physics simulations would be complex and might lag a lot. 13:56:56 I'm just thinking about forth on microcontrollers 13:56:59 like the STM8 13:57:05 I have 0 use for a forth on my main system 13:57:21 :-) 13:57:36 * KipIngram is thinking of making his Forth a working Linux shell option. 13:57:46 chunkypuffs: I used Forth on my main system (and on my raspi) to render Mandelbrot sets :þ 13:57:51 Well it'd certainly be interesting 13:57:51 yeah - me too KipIngram 13:57:56 I just haven't seen the future yet 13:57:59 fash? 13:58:06 I'm still a massive noob and have only used Linux for 1.5 years 13:58:21 Linux will take care of you. 13:58:24 recursive stuff is so easy in forth though, it's insane 13:58:47 If you learn its ways and become its friend, it will be loyal. 14:01:16 I've got a 19x24 LED array, and an STM8 running forth 14:01:22 chunkypuffs: Forth usually does an optimization so that tail ("last word") recursion is internally transformed into an iteration. 14:01:32 so you don't have to worry about overflowing your return stack. 14:01:49 my goal is to be able to make a navi (zelda) style light orb on the led array, and have it be controllable on the LED array 14:01:59 and have it bash into the side if you go too fast, and reflect some light back 14:02:09 then pressing the joystick changes the scene, maybe it's controlling some rainclouds 14:02:17 chunkypuffs: You could run Game Of Life on that panel. That should be totally doable. 14:02:19 Now imagine doing that with arduino 14:02:58 Is the arduino particularly limited in some particular resource? 14:03:08 No, but I am. 14:03:14 Ultimately, at the bottom level and in terms of the basic operations these things can perform, they're all pretty similar. 14:03:20 There might be a library for the array 14:03:23 They're all Turing complete in some sense. 14:03:24 the controller, etc, in fact there is 14:03:29 Oh, I see. 14:03:38 with forth I'm going to have to understand how to control the array 14:03:45 no cheats, and as a result have more control 14:03:48 Yes. 14:03:50 because it is going to force me to understand 14:03:53 You have to interface your hardware. 14:03:58 and it's not like it's difficult, why would it be difficult? 14:04:09 I wouldn't think it would be. 14:04:11 it's intended to be used, whereas if I use the library on arduino, I'm limited 14:04:21 Ultimate itcomes down to writing stuff to appropriate addresses, right? 14:04:22 limited because there may be inherant limitations in the library that I'm not aware of 14:04:50 oh I can't bash into the side of the led array and have sparks fly because there's too much something happening, or something is limiting me in the library? 14:05:05 In Forth you'd start with a word that would turn on and off individual LEDs, or groups of LEDs, or whatever turns out to get the best performance out of your hardware. 14:05:22 Then you'd build a layer of words on top of that, and a layer on top of that, and so on until you got where you wanted to go. 14:05:50 You *could* interface Forth to your library, in theory, or you could just do it from the hardware up. 14:06:45 so, a really good Forth will give you a mechanism for implementing new Forth words using assembly language of the underlying processor. 14:06:52 You'd take advantage of that as needed for performance. 14:07:29 All in all, I'm just happy to have someone able to teach me it 14:07:47 You've found a good place - someone here will be able to answer any question you have. 14:07:55 because maybe I'd never understand how to actually use the hardware from the ground up if it weren't for things like forth 14:08:06 or never bother to find out how to use the hardware and rely on someone having made a library 14:08:14 Yeah, Forth is a great tool for "dicking around with hardware." 14:08:22 You can just play, and see what happens. 14:08:26 brilliant then :) 14:08:34 I always loved bash, which is why I love Linux 14:08:47 and forth, so far, has been like that, but on the hardware itself 14:08:53 The guy that invented it had a sort of vision of kids using Forth to "just play" with things like semiconductor design and so on. 14:09:02 Kind of the way kids play with Legos. 14:09:10 well at 21, I hope I'm still a kid 14:09:30 :-) You are to me, for sure. But a kid who's starting to get into the serious part of life. 14:09:35 Well, we're all learning, but I hope I can catch up on a lot of things. 14:10:10 I only found this makerspace I'm at, (until like 5 am tonight, unhealthily) 8 months ago 14:10:27 and at this stage, I've gotten a job (1 month ago) working for a startup making sensors. 14:10:41 Ah, that's great. 14:10:47 prior to 19, I had always loved computers, but never had even one person show me how to use one 14:10:51 I think that beats the pants off of working for some big corporation. 14:10:53 Enjoy. 14:11:09 or anybody to interface with, talk to about tech, so makerspaces are wonderful, which is why I hope I can really catch up on things. 14:11:57 The internet is great and all, but I don't understand how you could possibly learn or be productive without other people showing you the way 14:12:40 Working for a big corporation, like what Google? 14:12:49 I'd feel dirty haha 14:12:55 Or any of them. 14:13:04 I used to work for small companies, and just loved it. 14:13:12 I work for IBM now. It pays the bills, and I don't hate it. 14:13:24 But I can't say it makes me feel remotely as excited about things as I used to feel. 14:13:42 Why does everything IBM make now look like crap? 14:13:46 makes now* 14:13:46 In those places processes reign and everyone is just a cog. 14:14:04 Like Synology will come out with a crazy nas that runs linux and has a nice new html5 web interface 14:14:18 Well, IBM doesn't MAKE as much as they used to. Our office makes something - I'll find you a picture. 14:14:22 whereas IBM will come up with something that requires internet explorer to interface with 14:15:14 Like yeah it'll work, I guess, but it won't be amazing to usee 14:15:19 https://www.cisco.com/c/dam/en/us/td/docs/unified_computing/ucs/UCS_CVDs/versastack_aci_svc_vmw6.docx/_jcr_content/renditions/versastack_aci_svc_vmw6_33.jpg 14:15:32 That's a flash-memory based enterprise grade storage system. 14:15:44 You don't need internet explorer for it - you talk to it over the fiber channel protocol. 14:15:45 20TB of flash storage? 14:15:49 Yep. 14:15:57 okay, fair enough, that's gorgeous 14:16:02 Obviously most customers use it in conjunction with spinning disks. 14:16:06 I will have to send you what I'm referring to whenever I find it/. 14:16:08 In a tiered type solution. 14:16:24 IBM is predominantly a service-based corporation now. 14:16:37 I actually know very little about the business as a hwole. 14:16:40 whole 14:16:44 Do you know anything about failover then? 14:16:48 They just bought the small company I was working for. 14:16:51 Or decentralized high availability stuff 14:16:56 You mean like when a flash card fails? 14:16:59 Sure - I know about that. 14:17:07 In rather nauseating detail. 14:17:12 how do you do any of that with linux? 14:17:25 Say I have two raspberry pi's, and I want one to die and have a webserver still run as if nothing happened 14:17:30 Linux has drivers that interface with "fiber channel devices." 14:17:42 We speak fiber channel, so we can work with them. 14:17:48 I think the linux fc driver is called lpfs. 14:17:51 fiber channel protocol is what? 14:18:27 Does that relate to the method by which you create a decentralized system? 14:18:35 It's a hardware specification for a physical channel (using optical fibers) and a software specification for a communication protocol used to talk over it. 14:18:40 I want to make this work with raspberry pi's initially to understand how you even implement this 14:18:59 Say two raspi's running nextcloud 14:19:08 and for everything to continue running when I smash one with a hammer 14:19:32 There's a guide for almost anything on Linux, but not for that 14:19:40 High availability is obscure, incredibly difficult, etc. 14:19:50 Ok, so what you want is to get "two unit performance" while both units are working, but still have things work correctly (just at one unit performance) when you kill one of them. 14:19:59 GlusterFS is easy enough to understand, I could do that, there's lots of guides for decentralized file sytems 14:20:12 That means that both units have to know enough about what the other is doing to be able to recover and continue its work. 14:20:13 but that doesn't allow the service to continue running 14:20:31 And you want the "overhead" of that knowledge to not impair performance too much. 14:20:37 yeah but this can't be done in a dumb way? 14:20:39 It's a difficult thing, but it can be done. 14:20:54 you can't have two machine states be identical? 14:21:12 Not really - they have to talk to each other. Each of them has to maintain enough "state information" on the other one for the other one to be able to pick up where they left off. 14:21:29 No, if the two machine states were *totally* identical, then they'd be doing duplicate copies of the same work. 14:21:34 Okay, getting super close now 14:21:36 You wouldn't get 2x performance. 14:21:40 what are the binaries that allow me to do this called? 14:22:04 Oh, I'm talking concepts here. I have no idea about existing implementations, other than ours. 14:22:05 that don't cost lots of money 14:22:17 damn, see this is what I'm saying 14:22:21 What is the nature of the work that these two units will be doing? 14:22:22 I've not found anything that lets you do this for free 14:22:25 What problem are they working on? 14:22:40 Nextcloud 14:22:59 I'm not sure what that is - a cloud based storage thing? 14:23:02 I've removed google from my life, but it is not true to state that my solution is better than theres 14:23:11 not until I can actually replace those myself, with something highly available 14:23:29 yeah it's just a DIY dropbox, and I like it 14:23:33 Ok, is it mostly limited to storage, or is it a general computing platform? 14:23:34 Ah. 14:23:35 just like plex is a diy netflix 14:23:36 Ok. 14:23:38 Storage. 14:23:53 I could do glusterfs to have decentralized backups of the data 14:23:55 that way I never lose data 14:24:01 easy, guides all over the internet 14:24:04 Ok, so with fiber channel, you can send an FC command to tell the storage to write a block. 14:24:14 And at some later point in time you will get a reply, saying that it's been written. 14:24:18 chunkypuffs: All of google? 14:24:27 as for making it highly available so that if I smash one server up with a bandsaw here at the makerspace, that everything keeps running 14:24:29 Before you get that reply, the storage has not accepted responsibility for your data. 14:24:42 If you "never" get that reply (time out), you still own it and you have to write it again. 14:24:52 Once you get that reply, the storage owns it, and has to make sure it doesn't get lost. 14:25:05 So you have to redundant units. 14:25:12 You send each write command to one of them. 14:25:18 john_cephalopoda, Yeah their suite of applications, I have either given up on them, or use my own solution 14:25:37 but my own solution may go down at least twice a year, I want to make that 0 times a century, because it should be possible with just 3 servers 14:26:00 Before that unit sends you the "I'm done" reply, it has to make sure it has saved enough information about that write (which includes the data) in a redundant place, in a way that will let the other unit know it needs to complete the write, in case it (the first unit) fails. 14:26:05 chunkypuffs: Never used any of their applications, but some of their services (like youtube) simply have no alternatives. 14:26:07 So it receives your command. 14:26:10 It receives your data. 14:26:26 john_cephalopoda, At least I can backup youtube videos on my decentralized storage network that I want to make 14:26:28 It communicates with its peer, the other redundant unit, as necessary to get a "rescue plan" in place. 14:26:32 And then it tells you it's done. 14:26:41 Then it finishes the job -writes the data to the backign storage. 14:26:49 Then it cancels the rescue plan. 14:26:52 right KipIngram But this is your implementation that I can't run, right? 14:27:04 https://youtu.be/JZ2PK-AXZ0A 14:27:04 If it fails before the data gets to storage, the other unit will execute the rescue plan and take care of things. 14:27:15 Here's one that works with ZFS called "RSF1" 14:27:16 No, I didn't give you anything proprietary. 14:27:22 HOW we do those things is proprietary. 14:27:23 but I can't run it, costs shit tons of money 14:27:43 The basic idea is something we don't own. 14:27:50 Other companies do the same thing - you can too. 14:28:07 If that weren't the case I wouldn't be telling it to you. 14:28:18 chunkypuffs: I got 140+ youtube videos (mostly music) on my computer. 14:28:40 I'd think there'd be a lot of info online about general fault tolerance. 14:28:47 KipIngram, Well what you've told me is in my bouncer, I'll see if I can implement it when I'm 25 :) 14:29:08 :-) 14:29:22 This is one of those things that is not available in the open source world yet 14:29:22 I think the key thing here is that you can't do without the "I'm done reply." 14:29:32 You can't just write to the storage and assume it's done. 14:29:41 You have to let it tell you that it's reached a point of reliability on the request. 14:29:49 Until then you are responsible. 14:29:53 https://clusterlabs.org 14:30:11 That gives it a chance to collaborate with its peers to make sure that there's a high-availability plan in place for *that command*. 14:31:21 The details of how that plan is put in place, how the peers cover for one another, etc. etc. etc. will vary wildly depending on the application and the amount of compute effort associated with each operation. 14:33:11 A good bit of work is associated with writing a big block of data to storage, so software can do a lot of that for you. If your basic operation was something much faster, you might have hardware acceleration helping you along. 14:33:17 I think this cluster-labs thing is about right 14:33:22 I didn't realise this was something that existed 14:33:35 What I searched for was related to ZFS since I had just set it up at the time, this should keep me busy 14:40:01 --- quit: xek (Ping timeout: 245 seconds) 14:42:10 chunkypuffs: For storage, that "rescue plan" has to include the data being written - if it gets lost, then nothing will save you. So you have to send that data, along with the address it's to be written to, to your peer. 14:42:33 That really means that you need a comm channel to your peer that is "much faster" than the storage. Otherwise the overhead of high availability will clobber your performance. 14:43:14 But once you have that, it's all pretty simple. You send a copy of the data and its destination and a handfull of other details to the peer - the peer knows that that's not something for it to act on unless you die. 14:43:25 As soon as you've done that you can say "I'm done" to the host. 14:43:30 Then you set about doing the work. 14:43:45 If you succeed in finishing it, all is well. You cancel the rescue plan, and you're done. 14:44:07 If anything happens that keeps you from finishing, the rescue plan doesn't get cancelled. 14:44:30 Soon thereafter, the peer will recognize you're dead, and will go through the queue of rescue plans you've sent it and will act on them. 14:44:59 The rescue plan helps in another way too. 14:45:13 What if you write address N using peer 1. 14:45:21 You get notification that it's finished. 14:45:31 But that doesn't mean the data has reached all the way to the backing store yet. 14:45:40 Now what if you read address N using peer 2? 14:46:02 It has to be able to recognize that there is an operation in progress against that address. 14:46:08 The rescue plan allows it to do that. 14:46:29 It has a record of all those operation, including the data. 14:46:39 So it can service the read out of that rescue plan queue. 14:46:48 It doesn't even have to read the backing store. 14:51:39 I will tell you that to really do this well - to get the high availability without taking a significant performance hit - requires hardware in the loop. 14:51:50 You need FPGAs implementing portions of this. 14:52:04 And that's probably all I better say about it. 14:52:32 You can do it all in softare, but if you do your HA performance will be well below your non-HA performance. 15:13:16 i do kinda like this - https://gitlab.com/lilo_booter/vml-batch/blob/master/README.md#job 15:16:25 Damn, I didn't mess with x86 opcodes for too long. 15:16:25 speed being the steps between frames (0 is pause, 1 is play, -1 is backward etc), pitch being the rate at which the audio is sped up or slowed down (1 is normal, 0.5 is half speed etc), and position is the position within the graph 15:28:06 presiden: how so? <<< in my code, there was a bug with S" that causing SEE to fail. Takes some debugging time until I found out that the bug was on S" and not the others. 15:44:33 I've been thinking about how one might do a "projectional editor" in forth https://martinfowler.com/bliki/ProjectionalEditing.html 15:44:33 So instead of storing source code as text, and then parsing+compiling+interpreting it, the editor might call SEE to "project" the dictionary data structure into the editor as a text file (synthesized from the dictionary). 15:44:33 The dictionary data structure would have pointers "projecting" to locations in the text file view, instead of pointing the other way in effect by parsing the whole file or block. 15:44:33 The editor would know the position of the cursor, but it would represent a position in a data structure such as the dictionary instead of a flat text file or gap buffer. 15:44:33 I'm not sure how changing variable length word names would work as they are still text. 15:44:33 I guess you could view insertions as being appended to the dictionary and only linked with a pointer back to the location of the cursor in the dictionary definition. 15:44:33 ...unlimited undo/redo using your dictionary (yay?) 15:44:34 I don't think I've found the forthy way to do this yet. 15:46:39 --- join: proteusguy (~proteusgu@mobile-166-175-59-31.mycingular.net) joined #forth 15:46:39 --- mode: ChanServ set +v proteusguy 15:51:29 Phew... 15:51:43 --- quit: proteusguy (Ping timeout: 244 seconds) 15:51:56 I should probably read jonesforth 16:03:49 --- join: proteusguy (~proteusgu@mobile-166-175-59-31.mycingular.net) joined #forth 16:03:49 --- mode: ChanServ set +v proteusguy 16:23:31 Or simply write an EMIT function... That would make debugging of low-level code a little easier... 16:44:30 --- quit: john_cephalopoda (Ping timeout: 240 seconds) 16:50:52 john_cephalopoda: Yeah, the least little bit of output functinoality helps a lot with debugging. 16:51:14 Even just having a word that will return you to the OS helps. 16:51:25 You can move it around in your defs and localize issues. 16:58:18 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth 16:58:58 hmm, I thought gforth had "recognizers" installed.. Damnit 17:06:06 --- join: tabemann (~travisb@172-13-49-137.lightspeed.milwwi.sbcglobal.net) joined #forth 17:21:24 --- join: mark4 (~mark4@c-73-103-69-127.hsd1.in.comcast.net) joined #forth 17:56:29 --- quit: mark4 (Remote host closed the connection) 18:41:38 --- quit: tabemann (Ping timeout: 246 seconds) 18:47:20 --- join: travisb (~travisb@172-13-49-137.lightspeed.milwwi.sbcglobal.net) joined #forth 18:49:58 --- join: nighty- (~nighty@b157153.ppp.asahi-net.or.jp) joined #forth 18:50:05 --- nick: travisb -> tabemann 19:49:50 --- join: gravicappa (~gravicapp@h37-122-113-40.dyn.bashtel.ru) joined #forth 20:09:27 --- join: dave0 (~dave0@223.072.dsl.syd.iprimus.net.au) joined #forth 20:09:41 hi 20:32:02 --- quit: dddddd (Remote host closed the connection) 22:58:20 --- quit: arrdem_ (*.net *.split) 23:18:25 g'day dave0 23:22:02 --- join: dgi (~dg@s559515c3.adsl.online.nl) joined #forth 23:23:58 hi the_cuckoo 23:24:23 how's it going? 23:29:59 --- join: weoirjweoi (~dg@s559515c3.adsl.online.nl) joined #forth 23:30:11 --- quit: dgi (Read error: Connection reset by peer) 23:30:11 --- quit: weoirjweoi (Client Quit) 23:33:48 not bad thanks :-) 23:33:57 you? 23:35:34 yeah - going ok i think - my eldest kid will be 18 next week :) - having a party with the family today :) 23:36:16 cool! 23:36:53 is there a party for family and then a party for friends? 23:39:12 --- join: dgi (~dg@s559515c3.adsl.online.nl) joined #forth 23:46:19 well, he's disabled - there will probably be something for him at school, but sadly, not the usual coming of age thing 23:46:41 ah 23:47:03 happiest wee chap ever though :) 23:47:35 i was 18 a long time ago lol 23:47:56 heh - me too - i'd already left home 23:48:27 did you share a flat? 23:48:58 for the first couple of years at unit, i stayed in student halls 23:49:06 ah 23:49:34 i moved in with a guy who was friends with my friends 23:49:47 there was /always/ someone there haha 23:50:10 :) - i didn't take to academia, but i did like the student life :) 23:50:45 yeah school sucks heh 23:51:58 :) - spent 3 years of a 4 year degree getting irritable - then got a summer job and decided to take a year out to continue with it 23:53:17 best decision i made - the job was hilarious (premium rate telephone services - voice interactive games, information services - even serious stuff like collecting money for charities) 23:57:31 --- quit: proteusguy (Ping timeout: 245 seconds) 23:59:59 --- log: ended forth/19.03.09