00:00:00 --- log: started forth/19.02.19 00:07:40 OK, that is QUITE enough code for the night - I thought I blew it up. *sigh* Just dumbassery. 00:43:05 --- join: mtsd (~mtsd@94-137-100-130.customers.ownit.se) joined #forth 00:56:17 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 01:29:10 --- quit: spestov (Ping timeout: 246 seconds) 01:29:24 hmm - 90s to compile rpany on a rasberry pi 3 (sans tests and demo), 8s on my i7 and 5s on my thread ripper (latter two with tests and demo) - that's pretty decent for c++ i think 01:29:52 --- join: `preside1 (~presiden@unaffiliated/matematikaadit) joined #forth 01:30:29 --- quit: `presiden (Disconnected by services) 01:30:39 --- nick: `preside1 -> `presiden 01:30:56 what is rpany 01:32:29 yunfan: a FORTH-like scripting language implemented in c++ as a c++ header library - https://gitlab.com/lilo_booter/rpany/blob/master/README.md 01:32:47 yuck 01:32:55 * the_cuckoo yawns 01:33:11 oop, cpp 01:33:21 yup 01:33:27 john_cephalopoda: it's not a founder cult 01:33:35 he's a role model 01:34:23 and to be fair: he is *that* smart 01:34:39 that exaplains the compiling time :] 01:34:41 oooh, c++, but not metaprogramming in forth-like 01:34:53 okay then 01:35:21 the_cuckoo: I will admit I am stealing your idea of putting a Forth in headers 01:35:33 heh - excellent :) 01:35:54 I've been using SDL in my free time and want to script an engine with FORTH! 01:36:27 why does it have to be in headers? 01:36:32 excellent :) 01:36:50 * WilhelmVonWeiner shrugs 01:36:54 corecode: you tell me 01:37:09 corecode: for me, it doesn't - it just makes it easier to use in embedded manner 01:37:17 why? 01:41:24 just does - no compilation of external libs to deal with - just include the header and you have the functionality - trivial to extend the dictionary with functions and objects too 01:41:43 ah 01:42:13 https://gitlab.com/lilo_booter/vml-batch/blob/master/README.md <- an example of use :) 01:42:15 i guess it is a token based inner interpreter? 01:42:21 yup 01:43:48 I plan to compile the operating system into an image for a vm (like RetroForth) but the operating system image is compiled at runtime 01:44:09 it's not fast (typically 2.5x slower than python while looping) - but it's invoking c++ stuff which runs at native speed, so there's no problem having it handle 4k video in faster than realtime 01:44:25 WilhelmVonWeiner: for what target system? 01:44:45 handle video what? 01:44:51 decoding? encoding? 01:45:03 if you were slower than cpython, then that's quite slow 01:45:22 corecode: whatever - sure - both, all 01:45:33 that sounds made up 01:45:39 :D 01:46:12 corecode: Mine is just a .c/.h file(s) embedded in my SDL engine-to-be, I only test against OpenBSD 6.4 amd64 at the moment though 01:46:41 no, it literally isn't - i'm not sure how much of the vml stuff i should go into just now though... there maybe things which i will have to move before releasing... 01:46:56 Or I'll end up using Forth in Lua, lol. 01:47:22 i've been playing with sdl too - trying to suss out the best way to handle the event loop 01:47:47 expressing it rather than implementing it iyswim 01:49:19 I have been experimenting with using anything but a switch statement to handle input 01:51:01 hmm 01:51:59 What I want in my head is like `map(lambda f: f(game_state), events)` 01:52:05 i'd be interested in the form of your dictionary for this - happy to give you my demo (but it's squirelled away on my laptop and isn't v. functional at the moment) 01:52:48 will clean up this evening and post it somewhere if i don't find it too embarrassing :) 01:52:53 Nothing I've done is worth sharing at the moment because I've been putting time into other things 01:53:53 but the feeling in my head is "dispatch tables, or some kind of map or map-reduce or something" 01:54:31 corecode: on the subject of encoding 4k video - basically, vml provides a core for distributing over multiple processes and machines - my threadripper can handle some 4k flavours in realtime, but with a bit of assistance from other machines in the lan, i can achieve faster than realtime 01:54:40 Switch statements are mega conditionals and the most complex conditional I want in my code is an `if` statement... 01:56:44 corecode: but i may well be forced to move some of that from the open source release :) - it's kinda the day job stuff and a couple of components might reveal a little more than my bosses would want me to - still, no biggie - none of it is that difficult, and someone will probably work it out... 01:57:38 the_cuckoo: Free and Open Source Software release 01:58:19 WilhelmVonWeiner: switch like in c ? 01:58:27 yeah, bleh 01:58:34 yup - basically, vml is an lgpl lib - but some components (which haven't been released yet) may be moved prior to release 01:58:44 can you use an array of function pointers? 01:59:06 That's what I'm considering 02:00:16 WilhelmVonWeiner: my case statement is a bit weird - https://gitlab.com/lilo_booter/rpany/blob/master/README.md#cases - it's not a traditional approach at all 02:01:55 --- join: xek (~xek@user-94-254-224-236.play-internet.pl) joined #forth 02:02:02 Does your case statement exist when it encounters a true statement 02:02:09 rdrop 02:02:19 yes 02:02:40 --- quit: ashirase (Ping timeout: 250 seconds) 02:06:14 then I like the syntax even if I fail to see the advantage over `if exit then` 02:06:21 RPany doesn't have a return stack does it 02:06:38 i caved and added one :p 02:07:30 you did the right thing 02:08:22 you'll find an rstack description in the docs 02:09:17 it needs some love and attention to optimise and extend, but yeah, it's great for many things (i just think i'll have a hard time explaining it to some of my colleagues :)) 02:09:29 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth 02:09:45 Use diagrams and just show an unrolled loop 02:10:15 was considering using 'dot' for that 02:10:28 for what? 02:10:36 for creating diagrams 02:13:33 you know the 'dot' tool? 02:13:59 https://www.graphviz.org/ 02:18:55 anyway - it's lovely stuff - i use it to visualise filter graphs in vml, but it's small and light and can be used for many things, including visualising dynamic state at all kinds of levels 02:19:11 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 02:19:13 i'd probably use a whiteboard 02:19:20 :D 02:19:21 --- quit: mtsd (Quit: WeeChat 1.6) 02:20:18 I'd be a dick and use *roff (you know - pic, tbl, eqn etc...) 02:22:20 :) - i have some ideas how to do it quite nicely - think it should be interesting if nothing else 02:25:36 and as for the syntax of the case - i agree - it's unnecessary - 'if' is perfectly fine 02:26:16 but i liked the form it took so i stuck it in the core lib 02:29:12 i have another concept - similar to a return stack - called a substack - a substack can inherit the dictionary of another stack (or it can have a specific set of vocabs) and have its own data stack - the concept is weirder than return stacks as what you can do is provide it with the specific data at the top of stack of the other to seed its data stack 02:30:00 thus when stuff is executed on the substack, it can only access the data provided - the rest of the data stack of the original is 'safe' 02:31:01 i was vaguely considering this for the 'condition' evaluation or for a locked down form of it at least 02:34:43 * the_cuckoo has no idea if that makes any sense ... explaining stuff is hard :) ... hence aversion to explaining return stack to colleagues :) 02:41:31 oh and my colleague has just found the reason for the https issue :D - awesome :D 02:50:33 .j #frafos 02:50:35 whoops 03:23:20 the_cuckoo: Sounds like your substack could be interesting for multi-tasking. When you fire up a new task, it inherits the top section of the parent's stack. 03:23:48 Then hopefully the parent could continue, working with what was left of its stack after removing the substack and sending it off to the child. 03:24:23 Then you'd want to be able to "pull the results back" when the child was done - when the parent got status that the child had completed, it could "reabsorb" the child's results and process them. 03:25:22 I have a "stack frame" concept that will let me do it a little differently - I'll be able to have the parent and child working in the same stack, actually. Only one of them can grow and shrink it, but both can manipulate data *within* the stack using the frame words. 03:25:40 That saves the overhead of moving data around, but it provides absolutely no security. 03:25:58 But I'm planning a cooperative type system anyway, so that fits in with my other things. 03:26:22 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 03:28:26 In my scheme, child tasks will have their own stack pointers, but will inherit the parents *frame* pointer. 03:28:38 And therefore can access data in the parent's frame at will. 03:29:13 Of course, the child might open a stack frame of its own if necessary; it would lose access to the parent's frame until that local frame was closed. 03:29:24 If it did that, that local frame would reside in its own stack. 03:30:26 Though it would be possible to have it both ways by making a copy of the inherited frame pointer, then open your own frame. You'd just no longer use the frame words to get at that parent data - you'd have to handle it via your pointer using regular words. 03:46:51 KipIngram: yes - that is precisely what a substack can do - and it also allows insecure access to the parents data if constrcucted to allow it (in the docs, you'll see i have a few constructors for substacks) 03:47:31 Good. Sounds nice. 03:47:36 the base substack-empty is the most secure - it knows nothing - you have to educate it 03:47:59 complete sandboxing 03:48:38 I like the sound of it quite a lot. I've gone completely the other direction - relying completely on the parts of the system being "friendly" with one another. But it sounds like you're onto something interesting. 03:49:03 many thanks :) - that is much appreciated 03:51:44 It's really quite cool how flexibly Forth lets us explore all these different "domains of possibility." 03:54:25 absolutely - it's a fantastic approach 03:55:35 and the main reason that it works is that you're not spending all your time aligning and nesting and convoluting your bloody parenthesis 03:55:37 :) 03:56:44 --- quit: xek (Remote host closed the connection) 03:57:46 --- join: xek (~xek@user-94-254-224-236.play-internet.pl) joined #forth 03:58:40 Yes - that utter simplicity. 03:58:51 Ok - inane but cute: 03:58:54 https://www.youtube.com/watch?v=oPhPDuCV76E 03:59:34 --- quit: spestov (Ping timeout: 268 seconds) 04:00:03 --- join: xek_ (~xek@user-94-254-224-236.play-internet.pl) joined #forth 04:00:04 --- quit: xek (Read error: Connection reset by peer) 04:00:17 :) 04:28:28 Break time break time 04:28:47 Back to lovely elegant wonderful Forth as opposed to Redis CRAP 04:29:23 in fact Redis is fine it's just the way everything else on this network is put together 04:49:28 --- quit: pierpal (Read error: Connection reset by peer) 05:02:10 --- quit: xek_ (Remote host closed the connection) 05:02:29 --- join: xek_ (~xek@user-94-254-224-236.play-internet.pl) joined #forth 05:53:45 --- join: rdrop-exit (~markwilli@112.201.168.172) joined #forth 05:56:27 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 05:59:56 h'lo folks 06:00:10 Hi Zarutian 06:00:15 been musing a bit on something regarding processor design 06:00:52 we all know that it is pretty easy to make an hardware dual stack machine. (See RTX2010 and J1 for examples) 06:02:28 such things do not need huge address spaces per se. So, how many say J1 core+mem combos you think might fit on a die area of an say an Intel Haswell? 06:03:33 Many 06:03:56 at least 256 or so 06:04:27 I'll take your word for it 06:04:56 I am just guessing but I think it is well in the realm of possibility 06:05:35 ok 06:08:22 would programming such a thing be too ardurus? what if one used FlowBasedProgramming techniques? 06:13:27 I don't know if it makes much of difference whether you're orchestrating 256 stack machines vs 256 register machines. 06:16:57 well, register machines need operand and result mux-ing around which takes up die are. Plus J1 (and proably RTX2010) use trick of constantly feeding the ALU the TOS and NOS. But as you said there is little difference between them regarding orchestrating them. 06:17:49 (code density and reuse might also come into it as smaller programs takes shorter time to shuttle around) 06:22:49 Yes, the stack machines may have an edge when shuttling around code, but there shouldn't be much of that going on. 06:23:54 Relative to data I mean. 06:25:36 The code density would give an edge in reconfiguring/prepping the grid for new work. 06:29:14 --- join: xek__ (~xek@public-gprs410830.centertel.pl) joined #forth 06:30:25 --- quit: spestov (Ping timeout: 245 seconds) 06:31:34 --- quit: xek_ (Ping timeout: 246 seconds) 06:36:09 The challenges at the level of orchestrating the machines would be pretty much the same I imagine. 06:38:13 I think if such a chip were well set up for flow-based it would be quite nice. 06:43:14 --- join: pierpal (~pierpal@host254-58-dynamic.44-79-r.retail.telecomitalia.it) joined #forth 06:46:43 All depends on the application area I guess, for general purpose reconfigural computing, I prefer putting a general purpose CPU tightly coupled with an FPGA on the same chip like what Intel is doing. 06:49:03 https://www.extremetech.com/extreme/184828-intel-unveils-new-xeon-chip-with-integrated-fpga-touts-20x-performance-boost 06:50:47 That's an old article (2014) 06:58:04 Gotta go, catch you later. 06:58:13 --- quit: rdrop-exit (Quit: Lost terminal) 07:02:36 --- join: mark4 (~mark4@148.80.255.161) joined #forth 07:22:02 --- quit: tabemann (Ping timeout: 264 seconds) 08:17:52 --- quit: dave0 (Quit: dave's not here) 08:25:10 --- quit: Keshl (Read error: Connection reset by peer) 08:25:21 --- join: Keshl_ (~Purple@207.44.70.214.res-cmts.gld.ptd.net) joined #forth 08:26:48 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 08:32:29 --- quit: the_cuckoo (Quit: WeeChat 1.4) 08:33:38 --- join: the_cuckoo (~charlie@d51a50ae9.access.telenet.be) joined #forth 08:36:34 I have begun working on retro/native again. 08:38:05 it now builds on openbsd, and I finished words to read the cmos rtc and read/write serial ports (com1-com4). 08:39:37 I also have pulled out all of my old ATA code from retro9, so I'll hopefully be able to use it as a starting point. 08:59:29 --- quit: spestov (Ping timeout: 240 seconds) 09:30:57 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 09:58:15 --- quit: jedb (Ping timeout: 258 seconds) 10:04:36 --- join: jedb (~jedb@176.113.74.187) joined #forth 10:18:01 --- quit: pierpal (Quit: Poof) 10:18:18 --- join: pierpal (~pierpal@host254-58-dynamic.44-79-r.retail.telecomitalia.it) joined #forth 10:57:37 a retro os? 11:00:05 mark4: standalone version of my vm+forth 11:00:43 oooh its still running under some other OS tho (openbsd etc) 11:01:00 in what way is the normal version of retro not stand alone? 11:01:06 hosted vs naked/standalone 11:01:33 oooh it isnt running under openbsd, it BUILDs under it 11:02:47 I dont think ill ever do a stand alone version of x4 or t4, i consider Linux to be my BIOS anyway :) 11:04:04 mark4: it does matter if you want to slap the engine into an MCU, and btw: the t4 stuff is saved local cuz I need to examine it soon. 11:04:34 cool i think i enjoy developing ARM more than x86 now :) 11:04:38 mark4: this implementation of the vm doesn't need an underlying OS :) 11:04:46 planning on x64 and t64 too 11:04:49 My engine is working fine on linux, but now I have to start thinking about avr and samd targets 11:05:25 once I get the 32-bit x86 code to a good state I'll work on amd64, then arm and pic32/mips 11:05:27 crc a stand alone forth based / forth like OS is a good thing :) 11:05:52 but if you truely want it to be stand alone it must be able to recompile itself UNDER itself :P 11:06:44 mark4: that mostly means (today) an assembler-voc that can binary compile.. Otherwise, you need to target umpty asm and linkers. 11:06:46 I can rebuild the forth image using itself. The VM, which emulates the MISC CPU I target isn't so easy yet 11:07:35 just need an assembler right? :) 11:08:06 --- join: xek_ (~xek@user-94-254-224-236.play-internet.pl) joined #forth 11:08:16 I think the biggest issue I have with "all of this" is how everyone using an OS has to suffer a linker - and those tools need a whole language.. We didn't suffer this bs under cp/m and .com files - and I seem to recall DOS used to support similar. 11:08:20 really REALLY want an x86_32 assembler for x4 but i cannot abide 5 # ax mov bullshit. it would also requjire an edit of 100% of every line of every existing source file 11:08:39 i want a forth assembler that can take my EXISTING asm sources as is with minimal to NO editing what so ever 11:08:57 yeah, that mostly means a forth VM-target. 11:09:17 PoppaVic: i think the entire universe is insane when it comes to build tools 11:09:23 I am now considering the "target assembly" to be a "microcode" 11:09:30 I won't disagree 11:09:33 --- quit: gravicappa (Ping timeout: 250 seconds) 11:09:46 mark4: yes, and then the patience to rewrite the vm to use it 11:10:00 the c compiler is horrendouslfy snow. the c libraries are horrendously large, autotools is just horrendous... i can go on and on 11:10:18 crc stop having my problems! those belong to me! 11:10:31 --- quit: xek__ (Ping timeout: 246 seconds) 11:10:33 Autoshit was alwayus a nightmare; C tends to generate really verbous shit due to the caller/callee stuff 11:10:37 not a huge priority though: on the native version, the drivers and such will all end up being in forth, so the vm part will do as little as possible 11:10:47 one of the things i really need to do is consolodate x4 and t4 into the same build tree 11:10:57 autotools might actually be one of the greatest travesties ever committed against software 11:11:00 mark4: not entierly sure why. 11:11:04 --- join: dys (~dys@tmo-105-50.customers.d1-online.com) joined #forth 11:11:29 zy]x[yz: they would never exist if it were not for C. therefore C is the root problem 11:11:43 PoppaVic: not sure why what? 11:11:44 extremely disagree 11:12:16 why you need to merge them. Unless you mean "shit under the engine" - in which case I'd slap you with a frozen salmon 11:12:26 well.. to be fair c could be really good if it were not for the libraries, the build tools... . . 11:12:45 PoppaVic: i need both versions of the compiler to work identically using the same extensions 11:12:58 some extensions do not work the same under t4 as they do under x4 11:13:10 i dont want to have to edit two source trees any time i fix one extension 11:13:19 make x4 and ./extend 11:13:22 make t4 and ./extend 11:13:31 C remains perfectly fine. For C. Our issue is that a lot of shit isn't visible to the shelltime (outer) and compile-time (because they don't tell us) - and then yer C is... Whatever 11:13:45 the makes should build their respective kernels and the extends should extend using the same source tree 11:13:58 mark4: OH, extensions... lemme guess: they take advantage of machine abilities? 11:14:15 I should say "host" 11:14:27 they are not machine dependant, but the machines dont behave identically under the same circumstances 11:14:48 i COULD have three packages, x4, t4 and "extensioins" 11:14:52 that would work too 11:15:01 They often don't - which is why I use C where others use asm - and the world of "asm" has gone waaaaaay off the deepend. 11:15:09 Yes. Do that 11:15:24 the extensions should port to the basics 11:16:40 --- quit: xek_ (Remote host closed the connection) 11:26:16 I use C, but not autotools or related junk 11:26:37 autoshit is a nightmare; and the alternatives are nearly as bad. 11:27:18 It's nearly worthwhile to write a simple C program that prints the info you want to be "massaged" by basic tools. 11:27:49 this line of logic that c is the root of all autotools evil is basically "software is bad because this one piece of software is bad" (though unfacetiously there is a part of me that would agree all software is bad) 11:28:01 or learn a few gcc "options" and strip those 11:28:48 civilization/birds/houses/"software engineers" 11:38:31 I often wrote a "compile.sh" that just runs gcc. 11:39:04 shell is just shell - you didn't learn much 11:39:59 The point to autoshit was learning wtf the compiler was thinking it knew. It's an abomination, which explains shell and gnu in a nutshell (yes, I used that reference ;-) 11:40:25 I use C (or Pascal, C#, JavaScript, or Objective-C) just for the VM. Best to use Forth and extend the image when possible. 11:41:05 --- quit: dys (Ping timeout: 272 seconds) 11:41:49 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth 11:44:35 --- quit: MrMobius (Ping timeout: 245 seconds) 11:44:36 --- nick: [1]MrMobius -> MrMobius 11:46:25 --- quit: pierpal (Quit: Poof) 11:46:43 --- join: pierpal (~pierpal@host254-58-dynamic.44-79-r.retail.telecomitalia.it) joined #forth 11:48:02 FWIW, if anyone wants to play with retro/native, http://forth.works/rnf_qwerty.386 or http://forth.works/rnf_dvorak.386 are multiboot compliant kernels, tested loading via grub and qemu. 11:48:12 They have the core language, basic repl, and a few simple I/O drivers included. 11:48:52 I'm quite pleased so far with what I'm getting accomplished with nasm. Using assembly gives me a sense of total control that I don't get using C. 11:49:34 KipIngram: however, you need to 100% suffer relative/relocation - and many folks do NOT want (or need) that pain 11:49:45 That's just because of MacOS. 11:49:50 I wouldn't have had to do that under Linux. 11:49:58 you said linux had the issue as well? 11:50:10 No, the same code (that works on Mac) works on Linux. 11:50:25 But I think I could now replace all that with hard addresses if I wanted to. 11:50:31 well, yes: because it's already RELATIVE - did you try absolute under linux? 11:50:34 I probably won't, just to keep it running from one file in both places. 11:50:43 No, I haven't tried that. 11:50:51 ok, that-is-all 11:51:06 I'm not suer I see how that relates though - I'm just responding to your "assembly is the pits" comment. 11:51:53 Generally speaking? Yes, asm is a pain. I saw that in linux and you already have in osX. 11:52:01 --- quit: rprimus (Ping timeout: 255 seconds) 11:52:11 i consider C to be orders of magnitude more painful than asm 11:52:23 It's a lot of FIGHTING to "do what the fuck I mean, not what you want" 11:52:52 mark4: I tend to disagree, but will admit that gcc sure as hell generates the most godawful asm 11:53:01 i hardly ever have to fight asm to get it to do what i want. i ALWAYS have to fight c 11:53:02 always 11:53:07 without exception 11:53:11 PoppaVic: the relocaton requirement was a consequence of the MachO executable format the Mac uses. 11:53:25 KipIngram: I know, and now they do - tidbits ;-) 11:53:27 I'll look at it the other way - I presume reloation is NOT required with Elf until I see that it is. 11:53:31 Innocent until proven guilty. 11:53:38 It's not because it was assembly. 11:53:44 C programs have to comply as well on Mac. 11:54:10 --- join: rprimus (~micro@unaffiliated/micro) joined #forth 11:54:15 mark4: Admittedly, when I look at -S generation, I almost ALWAYS am looking at an MCU target - and then I start cursing ;-) 11:54:29 Im with mark4 on this one - with asm you can do what you want - you're not in any kind of a straightjacket. 11:54:36 c compilers produce horrendously bad asm 11:54:40 --- join: dys (~dys@tmo-123-185.customers.d1-online.com) joined #forth 11:54:43 on a lappy or tower, "I don't give a fuck" 11:55:11 im developing an android NDK version of t4 and i had some temporary place holders written in C that i am now porting into asm 11:55:19 C compilers prolly worked for IBM - they are awfully conservative ;-) 11:55:32 im using the -S output as a starting point. i took 400 lines of C sources and reduced it down to 40 lines or so 11:55:40 and that was OPTIMIZED c 11:55:49 mark4: somehow, I am NOT surprised 11:56:08 granted, a lot of the source code i was working from was red tape bullshit the c compiler produces 11:56:12 and that ALL went away 11:56:32 but i was able to easilly improve the ASM too 11:56:40 my TTengine() func is not unreal at 4K, but I see it starts and ends with save/restore every register possible ;-) 11:56:48 significantly improve it 11:57:37 certainly. I will stil support C for "well, you can generate asm that you KNOW will be optimizable" - and even have a clue wtf the asm is doing. 11:57:45 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth 11:58:29 I will conceed that with asm you can't get the same sort of "instant gratification." You can't just slap out a "hello world" and see something on the screen in five lines of code. 11:58:44 There's an "investment" to be made in getting your infrastructure put together. 11:58:47 omg! 3 uranium-filled paint-buckets threatened tourists in a museum! 11:58:54 But once you reach that stage, it's all upside. 11:59:06 --- join: [2]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth 11:59:34 KipIngram: I remain sold on "C works; C can generate ASM; ASM that can be optimized". 12:00:01 ..folks can otherwise whine and cry, it remains true 12:00:34 And with straight asm, you can write code that doesn't have to be optimized, because you wrote it tight to start with. :-) 12:00:39 yes 12:01:07 --- quit: MrMobius (Ping timeout: 250 seconds) 12:01:35 except, I will again specify: "asm" isn't a LANGUAGE and there are umpty variations - and then you still (usually) suffer a linker-language as well 12:02:05 --- quit: [1]MrMobius (Ping timeout: 245 seconds) 12:03:35 But all asm is relatively similar. 12:03:52 "BUT," is the mark of "wtf" 12:04:20 C is relatively portable. 12:04:23 It's all basically a human-readable form of binary machine language where one command in asm equals one command in machine language. 12:04:46 Plus some features to reserve space for storing stuff. 12:05:01 You can crawdad all day... The issues remain. 12:08:25 Oh, and for the unscarred: "asm" usually has a preprocessor variation no one loves. gcc generated .s is already preprocessed, and .S files will use cpp preprocessing. 12:09:10 (I won't even mention C++ because they dick around with their own preprocessing) 12:11:28 c is not portable AT ALL unless you strip out 100% of the libraries and even then your not truely portable, somewhere deep inside where you do not see there is some duct tape code working its magic 12:11:44 * PoppaVic chuckles 12:11:45 i condider portable code in ANY language to be a complete and utter myth 12:11:57 I tend to agree 12:12:20 the fact that the midnight commander will compile and run identically on all the places it runs is not a result of C being portable 12:12:36 * PoppaVic chuckles 12:12:37 its a result of huge amounts of duct tape in the libs 12:12:45 dude, nd you know I use MC ;-) 12:13:51 You might mention 'libs' is a misnomer, as some are static, and some are dynamic - and the latter is like calling another program ;-) 12:14:42 OK, I must off to refill propane and get more brew.. Yes, it's that sorta' code 12:27:09 bought some chocolate covered raisins this weekend. unfortunately 1/3 of them are chocolate cofered coffee beans :/ 12:27:39 lol what 12:27:40 they are good too but when im expecing something squishy and it goes crunch... 12:28:00 are you sure they're not just really old raisins? 12:28:08 no they are coffee beans 12:28:28 --- quit: spestov (Ping timeout: 255 seconds) 12:28:38 they sold both and someone mush have dumped some scoops of the coffee beans into the raisin bin 12:30:05 who eats coffee beans this is insane 12:30:33 "You can't drink coffee all day! You got to eat something." - "Okay *crunch crunch*" 12:30:38 oh, you must mean the dump happened before the chocolate coating 12:30:48 no 12:30:52 in the store 12:30:58 they sell chocolate-coated coffee beans?? 12:31:02 look in the bins they both look identical 12:31:03 yes 12:31:08 what 12:31:22 go to whole foods, they sell them there 12:31:28 lol 12:31:33 roasted cofee beans covered in chocolate 12:31:57 they are not bad unless you are expecting a raisin lol 12:38:41 btw, the arabs have eaten chocolte covered cofee beans for "hundreds"? of years 12:40:29 maybe that's their problem 12:40:52 they have bigger ones 12:42:00 john_cephalopoda: lol just saw your funny... i used to dring 6 POTS of coffe a day 12:42:09 but then i used to roast my own beans 12:48:21 mark4: I had maybe 2 or 3 cups in my life. 12:48:39 I like hot chocolate a LOT though. 12:48:43 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 12:50:19 cocoa yes. hot chocolate not so much 12:52:08 6 POTS a day???? 12:52:09 Wow 12:52:17 I thought I used to drink a lot of coffee. 12:52:30 --- join: MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth 12:53:31 try roasting your own beans 12:53:47 i need to buy a new coffee roaster but i want a new laptop first 12:55:28 --- quit: [2]MrMobius (Ping timeout: 255 seconds) 13:06:20 I've drunk that much tea, but never coffee :) 13:07:16 tea has as much caffiene in it as coffee does im told 13:08:51 i dont drink that much any more 13:08:56 more per weight, but for a loose leaf (as I use), less is extracted per steep. Tends to be close overall at the end of the day. 13:08:57 i rarely go beyond one pot 13:18:58 --- quit: pierpal (Ping timeout: 246 seconds) 13:23:38 I can remember years of 6-pots-a-day... I can also remember when the acid-reflux and puking started 13:26:08 Any moka pot fans in here? 13:26:33 Nope 13:27:06 frenchpress vs instant/tea-bag. Done. 13:27:14 I just like making coffee with one and this seems to contribute to my cycle of addiction and withdrawal. 13:30:11 not a fan of french press 13:30:13 personally 13:30:21 makes the coffee taste too gritty 13:31:33 --- join: xek (~xek@user-94-254-224-236.play-internet.pl) joined #forth 13:31:37 mark4: I thought the same... then I ordered more 400 weave SS for some genny's and cut a block to fit the press - works fine ;-) 13:32:06 genny's ? 13:32:14 Mind you, I almost always do instant in the AM - or tea.. Genesis Atomizers. 13:32:58 You can purchase woven/fabric/screen SS in multiple sizes.. I used what was basically 4x tighter in my press. 13:34:05 oh to vape 13:34:08 ick 13:34:16 I try to avoid picking easy ways to make coffee or else I get in the habit of doing that as soon as I'm awake, and this gradually makes it harder to wake up since my body expects immediate caffeine. At least a moka pot requires some hand coordination. 13:34:24 mark4: hey, it beats handrolled cigs 13:34:55 ex smoker 13:35:21 mechaniputer: I used to go thru at least 6 pots a day - in my 20's - and THEN shit hit the fan and the body no longer woke up that bad, but the acid definitely caused problems 13:35:46 mark4: doesn't affect "there is shit available to do.... " 13:36:32 I chuckled, because my cheap amazon press wqs now able to produce CLEAR "coffee" 13:36:42 and THEN shit hit the fan 13:36:51 ^ well coffee is a laxative right? 13:37:03 never throw shit into a fan - leave that to a zoo 13:37:08 no 13:37:18 It's a diuretic - like tea 13:37:25 oh 13:37:28 i don't drink either 13:37:35 sucks to be you ;-P 13:37:50 agree to disagree! 13:37:56 I suspect hookers cost more 13:38:22 yes but they can do stuff coffee can't 13:39:40 not always 13:40:03 I dunno, zy]x[yz - tell me more. 13:40:20 when you're older 13:40:39 Oh, ok.. You mean when my dick falls-off. Cool... 13:41:14 I'm already older than most anyone I meet online, so - that's a fail ;-) 13:44:26 Amazon + laxative = Alexative 13:47:28 I've added words to escape the VM memory limits and read/write physical RAM directly 13:47:47 that doesn't sound terrifying at all 13:47:54 crc: how's that working on harvard machines? 13:48:05 Now I can rewrite the display code in forth and drop the assembly stuff I borrowed from FTS/Forth System 2 13:48:43 PoppaVic: x86 isn't a harvard arch 13:48:52 crc: I am aware 13:49:50 This is specific to x86. if i need to run on a harvard system it wouldn't affect the core VM 13:49:59 ah 13:50:51 anything related to low level access would be tailored to the needs of the system in question 13:50:55 --- quit: dys (Ping timeout: 272 seconds) 13:51:10 Yes, it would. 13:57:17 crc x86 PRETENDS to be harvard 13:57:31 it attempts to force you into thinking its harvard arch 13:57:42 the cache lines dont like data and code mixed lol 13:57:55 mark4: I don't worry about the cache 13:58:01 and they dont like it when you WRITE to code sections :P 13:58:47 linux makes x86 SORT of harvard 13:58:48 --- join: dys (~dys@tmo-086-242.customers.d1-online.com) joined #forth 13:58:53 ish 13:59:09 i.e. cant execute from data space, cant write to code space 13:59:10 meh 13:59:23 mark4: same with openbsd 13:59:43 doesn't affect me there since the compiler doesn't generate x86 code 13:59:46 x4 gives them the middle finger and sets its entire address space +rwx 13:59:54 but cant do that on android at all 14:00:24 am not even sure i can allocate a writeable buffer under android that points to the same physical memory my code is in 14:01:05 i dont think i can even call mmap() at all under android 14:02:04 corecode: imo geometric algebra is a forthier way to do geometry and physics than the (crufty) linear & vector algebra. Why it's super cool for those unaware of GA: https://slehar.wordpress.com/2014/03/18/clifford-algebra-a-visual-introduction/ 14:02:04 https://bitworking.org/news/ga/2d 14:02:04 I've been working on a forth implementation of GA to use with sixel graphics and other things. 14:02:04 https://hal-upec-upem.archives-ouvertes.fr/hal-01510078/document#page=14 [PDF] 14:02:04 I figured out I can compute geometric product basis vectors using only xor http://ix.io/1zb2 but I still need a neat and tidy way to compute the sign. 14:02:14 anyway, time to go home 14:09:09 --- quit: mark4 (Ping timeout: 240 seconds) 14:17:21 --- join: xek_ (~xek@user-94-254-224-236.play-internet.pl) joined #forth 14:19:20 --- quit: xek (Read error: Connection reset by peer) 14:20:35 pointfree: looks interesting (esp the GA stuff) - will try to take another look at that shortly 14:21:23 --- quit: xek_ (Ping timeout: 246 seconds) 14:31:36 trying to add some client server stuff for my video thing (i have a server already, but it's crufty :) - will rewrite it shortly) - have the following 3 words in mind: 14:31:42 connect -> 14:31:43 send-graph -> 14:31:45 Â send-list -> 14:33:38 the is any loaded video graph - it's serialised and sent as a graph description containing combinations of (video files) and so the graph can be deserialised on the other side 14:34:49 the send-list allows following commands (like [[ add-to-playlist ]] or [[ . ]] to play it immediately) or any command the server supports 14:37:05 in theory, the initial connector could involve a specification of the server or server:port but for that to work, i'd need to map all local files referenced to urls (which is pretty trivial of course) 14:42:58 trick is that the server provides a stack to work with - and it can deserialise as the input is received (or defer until use) 14:43:16 seems like fun to me :) 14:51:58 KipIngram: instant mashed is better than sliced-bread 14:56:44 I am so happy forth has no idea wtf a "connection" is. 14:57:12 shit.. did I say that out loud? oops 15:03:25 well, i could have called it