00:00:00 --- log: started forth/21.04.17 00:03:06 --- join: andrei-n joined #forth 00:28:39 --- quit: f-a (Quit: leaving) 00:52:17 --- quit: wineroots (Remote host closed the connection) 01:30:43 KipIngram, re: " just the specific notion that a great architecture can emerge from a vacuum." absolutely agree. And too many snake oil salespeople and, worse yet, programmers still claim this. 01:44:28 I've designed a lot of things over the years, but the thing I was always best at was digital logic design. Before I ever started with a schematic, I would sit and think. I could hold a fair amount of logic in my mind well enough to evaluate and reject possible approaches without having to "really" go down that road. Similar to mentally executing a piece of code, except with hardware and parallel signals. 01:44:30 Obviously I could "simulate it" in my mind in any sort of complete or cycle accurate way, but could tell (often) when something wasn't going to work, and I'd lay that idea aside and try something new. 01:45:09 Usually by the time I started doing a schematic I KNEW what I was about to do was going to work. I knew I had some bits and pieces to work out the details on, but I knew I wasn't going to run into an insurmountable problem. 01:45:28 Sometimes this would take days, if the piece of work was significant. 01:45:52 I thought of that sitting and thinning as the best possible application of my time. 01:47:04 When I did start doing the schematic, I went straight throough it. No iterating. 01:48:21 In his second book (after The Seven Habits of Highly Effective People), or at least a "later book" called "First Things First" Steven Covey laid down the principle "all things are created twice." First they are imagined, and then they are realized. 01:49:08 Plus prototypes and failed production units ;) 01:49:09 I believe in "imagining" WELL and THOROUGHLY. 01:49:41 Yes, it's possible to *imagine* the failed prototypes. 01:50:16 And failed prototypes in electronics take weeks. 01:50:29 Board layout, PCB fab, assembly, etc. 01:50:43 It's not a file you can edit. 01:50:46 Well, it is. 01:50:49 But not JUST that. 01:51:40 Good hardware simulators are hard to come by 01:52:16 And they were impossible to come by in the 1980's when I was active in this area. 01:52:37 I saw some early work by Mentor Graphics at a trade show once and was fascinated by it. 01:52:40 But it was early days. 01:53:37 That stuff got better in the 1990's, while I was still active, but I was with small companies and we couldn't afford $40k / $50k pieces of software. 01:53:44 With special workstations to run it on. 01:54:59 There's some simple ones that run in browsers now, but the big ones I think are still like that 01:57:55 Yeah. What beat the hell out of me in the earl FPGA days (and still) was that the chip vendors want to make a profit center out of their software. I used to flatly tell the people that came calling that there was NO CHANCE of us using their chips unless we got the software for free. I just refused to hand over money for that. And I managed to make that work for a while - later on they got more "corporate" 01:57:56 about it, but in the beginning I was able to talk anumber of them out of free copies. 01:58:22 I guess we represented enough possible volume. Early days. 01:58:35 These days that volume would be a spit in the ocean. 01:58:53 KipIngram, yeah the hardware folk never quite understood the real value of software was in getting devs to use it so they'd buy your dang chip! 01:59:11 I was accustomed to PAL programmable logic, which was totally transparent. You could look in the data book and infer the format of the fuse file. 01:59:45 Then FPGAs come along, and they wouldn't tell me what the bits of the fuse file meant, and it drove me crazy. 01:59:56 This frigging undocumented bit stream. 02:00:34 KipIngram, fortunately that's slowly becoming more open. 02:01:39 Yes, at last. 02:01:54 --- quit: gravicappa (Ping timeout: 240 seconds) 02:02:01 Decades later. :-) 02:02:29 I used to have dreams of being able to reconfigure bits of logic on the fly. 02:03:09 We made equipment that programmed programmable devices - I used to think about having "accelerators" that we could install in the FPGA on a per-device algorithm basis. 02:03:27 (Algorithm - our word for the bit of code specific to a device that made the programmer able to handle it). 02:03:50 We had a custom language called DPL we wrote algorithms in, and a third of my team did nothing but write such algorithms. 02:04:13 The owner had created DPL way back in the day, using the usual compiler tools like yacc and so on. 02:04:34 I regard it as the primary reason his company became #1 in the programming business. 02:04:48 Our number of devices supported just flew by the competition. 02:05:30 And when we did a new programmer, we'd just change the code generator of the DPL compiler to accomodate it, and instantly ALL of those devices were supported on the new product. The competition just couldn't do that. 02:06:06 --- join: gravicappa joined #forth 02:06:13 I believe it. Being able to make your own DSL shows mastery of the domain and gives you the ability to multiple that value. That's why I like forth. 02:06:55 The guy was brilliant. He could be a complete asshole at times - he'd never worked for anyone else in his life, and he just didn't undnerstand what the boss's opinion could mean to people. 02:07:05 He started the company right out of college at Rice. 02:07:17 He was also an analog circuitry wizard. 02:07:29 A generation younger than you usually found analog wizards. 02:07:56 There were days I didn't like him, AT ALL. But I had huge respect for his abilities. 02:09:36 And he gave me a sandbox to play in, and he paid my salary. I appreciated those things. 02:09:58 I was able to send my wife to graduate school on that financial success. 02:10:32 And then later after those glory days had passed for me she brought home the big bucks. :-) 02:11:42 She wound up one of about half a dozen people in the world fully expert in a technology the offshore oil folks call "flexible pipe." It's this sophisticated multi-layer pipe technogolgy, with layers for sealing, layers for pressure handling, etc. etc. 02:12:32 Some of the strength layers are made of these groovy little pieces of interlocking metal, that can move and flex but still resist loads. 02:16:45 Good call on the wife there! ;-) 02:17:15 Oh yeah man, I don't know that I really deserve her. I wasn't going to get married again, after my nightmare of a first marriage. 02:17:33 --- quit: cmtptr (Ping timeout: 240 seconds) 02:17:34 For about a year I chased every woman in sight and had a blast. 02:17:49 Then I met her and decided almost instantly that she was a keeper after all - turned on a dime. 02:18:16 --- join: cmtptr joined #forth 02:18:56 Pro tip: Early 30's is a great time for a guy to be single. It's a buyer's market. 02:19:46 The women a few years younger are starting to get serious about things and losing interest in the flashy bad boys, and the women a few years older are starting to get... desperate. 02:21:04 A guy who's at least not ugly, has an education, and is holding a good job turns out to be a hot commodity around that time. 02:29:18 Can confirm, although I'm late twenties and happily engaged, I can tell that's the way the market is 02:31:21 I certainly wouldn't advise making long term decisions to try and remain single at that time 02:31:58 But if you're having trouble in your 20's then maybe it's good to know if you can stay in good shape and not be a total loser you will find it easier later 02:46:04 Agreed. 02:46:27 It wasn't by choice I wound up single at that age. Well, actually it was my choice, but not one I savored. 02:47:23 And that's exactly what my advice would be - at least try not to get depressed if you're young and not a big hit with the ladies - the game changes quite a lot over time. 02:49:16 Anyway, now it's a quarter century later and things have been great. For me, second time was the charm. 02:49:31 Nice 02:50:15 I got my two oldest daughters out of the first marriage, so if I had it to do again I'd go through it again, just to get them. So it wasn't a total loss. :-) 02:50:31 Yep 02:56:12 You know, this LISP primer has a really nice fully fleshed out example at the end - some symbolic math. That's gold; sometimes just carefully going through something like that teaches more than anything else. 02:56:59 It really, REALLY looks like code from the 1960's. 02:57:16 I remember seeing similar weirdly abbreviated names in old FORTRAN programs. 03:32:54 So, speculating on the internal operation of a LISP system, am I getting the right idea? The LISP entity most similar to the Forth "dictionary" looks like it would dynamically grow and contract during execution. Would that be what the primer called the "a-list"? 03:34:25 It looks like in LISP that structure is a much more "active participant" in things than the Forth dictionary is - I think of the Forth dictonary as relatively static during application executionn. 03:35:10 But I guess that makes sense, since LISP has this ever-changing name scope. 04:01:26 so what I've read about writing assemblers in forth (ones that run "inside" forth, defining words for different opcode etc) would suggest that they are single pass, but I'm confused if it's possible to, for example, define a label and reference it before the location it's defined. To make that work in a single pass assembler would you need to declare labels before their locations are given? 04:10:31 To do that in a single pass you do something similar to how Forth's IF ... THEN works. IF and THEN are both immediate words that run at compile time. IF compiles a conditional jump, but it doesn't know where it needs to jump to yet, so it allocates the space for the jump target, put the address of that space on the stack, and puts a "code" on the stack. Then, later, THEN checks for that code; if it's there, 04:10:32 great - if not, error. THEN compiles no code itself - but it knows the jump target, and it goes and patches that address into the spot that IF allocated. 04:10:37 You can do that same kind of trick in assembly. 04:11:18 Reverse jumps work similarly - the first word puts the target address and a code on the stack; the later word confirms the code and compiles a conditional jump to that target. 04:11:39 In neither case do you need to define a "label" in the dictionary or some other symbol data structure. 04:12:17 hmm ok 04:12:22 The trick is to use the stack to communicate information forward from earlier immediate words to later immediate words. 04:12:59 I'm still not entirely sure how that works but I kinda get it? 04:13:13 I wrote some partial x64 assembler words for my Forth, and in the arena of jumps (conditional and unconditionnal) it didn't really "look like" traditional assembly. 04:13:28 Get a pencil and paper and step through a couple of examples; it'll click. 04:14:06 In all cases once you get past the whole thing all the information you need to define the code exists. You just sometimes have to wait a while after you first need it to get it. 04:14:30 Leaving a blank spot and backpatching it later is perfectly fine. 04:15:17 I understand how that works for jumps 04:15:24 but I'm slightly confused how I'd use it for other things 04:15:32 Like what? 04:15:40 for example in uxn (my target platform), there are memory addresses that you're meant to write memory addresses to as vectors 04:15:47 like an interrupt type thing 04:15:53 Ok. 04:15:58 and you need to do those at the start of the program 04:16:09 Well, these are documented addresses, right? 04:17:05 ?" 04:17:24 Ooops - sorry. 04:17:35 My dog started to fall off the sofa, and hit the keyboard. 04:18:01 "Problems cats never have" (tm) 04:18:06 yeah you know the addresses to write the vectors to but the vectors themself are in your own code 04:18:37 so let's say you have a screen drawing routine at 0x0280, you would write 0x0280 to the address for the screen vector 04:18:42 I am explaining this badyl, sorry 04:19:50 Yes, so ok. So I'd let those be determined at compile time, and then I'd set them at startup. I have some things like that in my Forth - I don't know where it's going to be loaded in memory, and there are a things that are global addresses I have to set. So code that isn't actually part of my system but runs first, at startup, patches that stuff up. 04:20:04 If you must have these things set before you get to do ANYTHING, then you have a bit of an issue onn your hands. 04:20:34 One alternative might be to put a table of jumps at the start of your code. 04:20:51 Point those vectors into your jump table, and let the jumps there take you the rest of the way to your target. 04:21:16 You'd allocate them first as blank spots, and then fill them in during compilation as you learned where your code was going to be. 04:22:18 Does your code image get loaded in a specific place every time? 04:22:57 yeah 04:22:59 I think so 04:23:05 yeah it does 04:23:37 Ok. Then if your code image gets loaded at X, and a jump instruction takes N, then the jumps would be at X, X+N, X+2N, etc. - you'd point the vectors at those spots. 04:23:58 So your image would start off with 04:24:03 JMP X1 04:24:06 JMP X2 04:24:07 etc. 04:24:21 Fill in Xi when you know what they are. 04:25:50 Maybe that doesn't feel like a pure 1-pass operation to you, and I guess it's not. When you backpatch that's a bit like a little piece of a second pass, isn't it? 04:26:03 But it's easier to do than a full-on multi-pass setup. 04:26:41 Easier because you don't have to build a general symbol table mechanism. 04:29:18 ok 04:29:43 maybe it would be easier to just build a multipass assembler. But I like the idea of doing this within forth 04:29:56 and doing multiple actual passes isn't really possible if you're writing assembler as forth words 04:35:59 Well, you COULD write a multipass assembler in Forth, but you'd have to build the traditional symbol table and so on - you wouldn't be able to take full advantage of what Forth already gives you. 04:36:44 yeah 04:37:39 I just don't really want to have a jump table in my output code, for some reason 04:37:51 even though it's very few bytes in reality 04:38:17 Well, you're writing to please yourself, so... you're in charge. 04:46:56 --- join: f-a joined #forth 04:47:22 You might consider cuckoo hashing for your symbol table if you do that. It's got fast lookup time. 04:47:29 cuckoo hashing? 04:47:30 And makes good use of table space. 04:47:42 Yeah, it's a particular hasing method. There's a Wikipedia article. 04:48:17 ah ok 05:02:52 Felt like something that would implement cleanly in Forth. 05:04:15 It offers guaranteed read speed, but inserts might start taking longer as the table becomes fuller. The article said it was pretty straightforward to get 95% space utilization in your table before inserts became prohibitivey expensive. 05:04:25 prohibitively 05:06:02 ah ok 05:06:08 cool 05:17:55 --- quit: Zarutian_HTC (Remote host closed the connection) 05:41:06 --- quit: dave0 (Quit: dave's not here) 06:13:45 remexre: have you ever used bisimulation? 06:14:22 in the context of proving semantic preservation of compiled code wrt. source language, I know it also can be used to establish equivalences between state transition systems and process calculi 06:15:31 There's a great presentation by Xavier Leroy on compiling IMP (a simple imperative language) to a stack machine (with a store) https://xavierleroy.org/courses/EUTypes-2019/slides.pdf 06:17:49 all formally verified in Coq, I might try the same but target other stack machines/VMs. 06:20:47 "proving semantic preservation of compiled code wrt. source language" - that would be "making sure the code does what it's supposed to"? 06:21:01 KipIngram: yes but I was stating it precisely 06:21:09 :-) 06:21:21 Just poking at you a little. 06:21:36 you define a relation between the source language and target VM state, then show that when the source language takes a step, the VM takes one (or more) as well 06:21:37 hehe 06:21:51 so in other words, programs don't get stuck 06:21:59 One of the supposed assets of Forth (done right) is that you have short definitions that you can simply look at and "know" are right. 06:22:26 Using whatever mechanism Goedel found humans to have that machine intelligence doesn't. 06:22:47 I almost certainly spelled that wrong. :-( 06:22:52 Well this is quite unrelated to Gödel, but I see what you mean. 06:22:58 That's also an alternate spelling 06:23:16 Oh, shoot - I didn't. That was the alternate that I see out there. 06:23:43 Forth programs are quite compositional, so I'm certain that the properties of short words could be almost automatically proved 06:23:44 Right - I didn't think it was really the same thing. 06:24:38 I imagine so. 06:25:04 Proofs, like functional programs, compose very well. It's annoying to build up the theory at first (mostly doesn't happen in real projects), but once you do, for instance, someone might write a dead code elimination pass (along with a proof of correctness) and someone else a pass to optimize arithmetic (with proof) 06:25:20 then combining the two passes and you get a bigger, correct pass for free 06:25:21 I actually like the idea of provable correctness. If we had more of it we might not have such crap operating systems on the market. 06:25:38 someone here desperately wants types :P 06:25:51 This is a great resource https://softwarefoundations.cis.upenn.edu/ 06:26:02 Yeah but you can erase types at runtime 06:26:18 not from your heart 06:26:39 They even have a verifiable C volume, but I don't know enough yet to tackle that 06:26:41 indeed that is a superb resource 06:26:54 f-a: fellow FPer? ;) 06:27:24 I'm a big fan of "compile time smarts, run time performance." 06:27:30 yeah, tho I mostly do crap programs 06:27:56 Forth is funny in that you basically are already writing programs in the target VM (or using other words built up from primitives) 06:29:23 Forth could be understood by small children, in my opinion. 06:29:32 It has a childlike simplicity. 06:29:44 Say this, this happens. 06:30:11 Of course all this formal stuff is not a silver bullet, probably out of reach for most programmers since you'd need a good understanding of mathematics and proofs to apply them to programs 06:30:13 so YMMV 06:30:32 --- quit: andrei-n (Ping timeout: 252 seconds) 06:30:39 UNSAFE-PERFORM-IO 06:30:50 f-a: gasp the unutterable sin 06:31:12 "every time you use unsafePerformIO, a kitten dies" 06:33:14 Hahaha - I had to look that up. 06:33:20 "I promise..." 06:33:40 Basically telling the compiler to trust you. 06:51:46 --- quit: f-a (Ping timeout: 252 seconds) 06:53:41 --- join: f-a joined #forth 07:10:04 --- quit: pareidolia (Ping timeout: 260 seconds) 07:20:36 --- join: wineroots joined #forth 07:29:50 --- join: andrei-n joined #forth 07:57:23 By the way, the hashing method alluded to by the LISP primer sounded very similar to that cuckoo hashing I posted a link to a couple of weeks ago and recommended to nihilazo earlier this morning. 07:57:43 I really like the combination of simplicity and effectiveness that offers. 08:42:41 I was reflecting on functional programming this morning, and I decided that one of the reasons it's never appealed to me is because of my embedded background. The first thing I think about when I think about writing software is that the software is going to DO SOMETHING. It's going to cause an effect. Perhaps only on the memory, but more often on some other aspects of the hardware. Its purpose is to 08:42:43 *control* something. So the very thing I'm interested in is the side effects. I feel like when you're mostly interested in side effects functional programming loses some of its "naturalness." 08:43:12 I probably should do some self study on theorem proving or something like that - I might wind up with a better appreciation. 10:22:35 --- join: mark4 joined #forth 10:22:59 REALLY annoying that C cannot tell you the ADDRESS of a function at runtime given its name :P 10:23:22 C isn't Python 10:24:22 --- mode: ChanServ set +v mark4 10:27:07 c isnt forth 10:36:25 Unless you've got debugging information around all that symbol info is gone, right? 10:36:51 strip -R .comment 10:48:00 Well, I guess what I meant by that is that the, uh, "academic" purpose of a compiler is to eliminate all that stuff. 10:48:20 But I guess that only truly applies after you link. 10:53:23 --- quit: f-a (Read error: Connection reset by peer) 10:53:45 So what were you tryinng to do that a function pointer doesn't give you? 10:54:17 --- quit: gravicappa (Ping timeout: 265 seconds) 10:55:47 --- join: gravicappa joined #forth 10:57:21 --- join: f-a joined #forth 11:41:36 hey guys 11:45:23 KipIngram, I thinkk given a string containing a function name get the function pointer 11:45:34 which obviously C can't do 11:46:35 --- part: f-a left #forth 11:46:46 well, on any modern POSIX system C can do that: dlopen, dlsym 11:47:15 but that's a feature of POSIX, not of C 11:53:34 --- quit: andrei-n (Quit: Leaving) 11:58:35 Yeah - it's not something I'd expect a traditional, straightforward compiled language to do. 12:02:29 dys a c application can use dlsym to get the address of a function 12:02:46 a c library can not use dlsym to get the address of a function in an application 12:02:50 crippled 12:07:39 siraben: nope, but I'm familiar with it's existence/usefulness; I'll give that presentation a look, thanks! 12:08:24 mark4: hm, does dlsym(RTLD_DEFAULT, "whatever") work? 12:10:26 looks like no :( 12:10:31 remexre, i would need to add that to my library which when linked against ANYONES application, the library would need to do that 12:10:40 on a stripped application 12:10:45 wont work 12:10:55 oh, well, if it's stripped you're SOL no matter what 12:11:30 I wonder if you could do something sick and twisted to gnu as to have it build a forth-like dictionary in the .text section... 12:12:15 remexre i would need an associative array of strings for menu item names and & function addresses 12:12:32 and i would need the end user to create that associative array at edit time 12:12:40 possibly with macros 12:13:01 yeah, I was thinking of defining a macro for .type, which then maintains a linked list using as' macro system 12:13:05 which again. is a FUCKING nightmare becauuse theres no reason wny i cant have a BLAH menu item inside both the FOO and BAR pulldowns 12:13:21 not a linked list. an array 12:13:34 right I mean you'd turn it into an array at runtime 12:13:56 menu_association_t array which they populate with string menu item names and function pointers 12:14:21 they could then create a json file which references that array 12:14:39 only. ill need one array per pulldown and another one for the menu bar 12:14:51 meaning im practically building the ENTIRE FUCKING MENU at compile time 12:15:00 instead of dynamically creating it at run time 12:15:05 which is what im trying to achieve 12:15:19 i need a way to offload ALL that compile time bullshit to run time 12:15:52 creating compile time intermediate structures just so i can dynamically create the run time structures mkeas those run time structuers entirely NOT dynamic 12:16:30 the compile-time structure would just be for looking up name->function pointer 12:16:52 but doing it by messing with as is definitely the wrong thing 12:17:03 no, they would have to give the name of the menu item within the pulldown and its associated function pointer 12:17:19 tne only other item in the pulldown menu item is the shortcut key escape seauence 12:17:45 and every single pulldown menu would need its own menu item associative array 12:18:09 and the menu bar would also need an associative array of pointers to associative arrays 12:18:28 menu bar name for the pulldown and a pointer to the array of associations for that one pulldown 12:18:49 yup. statically creating structures so i can dynamically recreate them elsewhere 12:18:58 to make them look like im dynamically creeating them 12:19:02 utter bullshit 12:19:27 IIRC it's not about the strippedness, it is about linkage. Static functions cannot be dlsym'd, they need external visibility 12:19:51 yes but the EXECUTABLE is already linked and stripped 12:19:55 not yet executed 12:20:17 the ENTIRE freeking UI can be dynamically generated at runtime based off of a json file 12:20:46 define a screen. put windows in that screen. put menu bar in that screen. put pulldown menus in that bar. put menu items in that pulldown 12:20:55 define attributes for windows, pulldowns etc etc etrc 12:21:02 ALL at run time based off of a json file 12:21:18 except. CANNOT associate function addresses with names dynamically 12:21:20 only statically 12:23:13 someone said i should be using QML lol 12:23:19 /facepalm 12:24:12 --- join: Gromboli joined #forth 12:24:31 well, just don't link it statically, then you can. if you don't put function in the dictionary for performance reasons you cannot do the lookup there either... 12:24:37 no 12:24:54 because anything i link dynamically to at run time STILL increases my runtime footprint 12:25:08 which is currently less than 53k which is the size of my stripped elf file 12:25:28 here is my list of dependencies... dep_array[]={}; 12:25:40 and its staying that way 12:25:46 other than stdio, stdlib, etc etc 12:26:06 if a library is not guaranteed 100% to be on your system its not going to be a dep here 12:26:25 in fact. if its not 99.99999% guarnted to already be loaded on your system it wont be a dep here 12:27:16 no matter how i swing this NO part of my menus for this UI can be dynamically generated at run time 12:27:32 they absolutely have to be statically generated at compile time :/ 12:27:35 and thats not acceptable 12:28:07 I don't get it... just implement a dlsym() yourself then to siute your needs? C gives you all that's needed... 12:28:18 sure 12:28:49 and you create a ultra geeky executable that links agianst my lib and is stripped 12:28:52 boom. fail 12:28:56 also wait I've run linux systems before without a libc.so... 12:29:15 remexre, you were never without a libc of some sort 12:29:24 there must have been a ulibc or something like it somewhere 12:29:28 nope, kernel booted to my forth 12:29:39 which cant run my application 12:29:58 and is not a real world scenario 12:30:07 as much as i would love it to be :) 12:30:13 A branch of stubforth does that as well. Only dependency is linux syscalls 12:30:40 ALL of my forths are stand alone. i treat the linux kernel as my bios 12:30:47 i dont link against ANYTHING external with them 12:30:57 but.... thats not how the real world works. 12:31:04 this is not forth im developing here right now :/ 12:33:52 how do you feel about linking to BFD 12:34:05 should be on 99.9% of systems that ship ld 12:34:12 linking is not the solution 12:34:24 right, bfd is how ld looks at objects 12:34:38 that plus a macro to dump functions into a particular section might work? 12:34:46 and it is entirely dependent on an unstripped executable 12:34:49 or objects 12:34:57 no, that's why you're creating a new section 12:35:13 CANT do that at run time 12:35:32 you don't need to define functions at runtime (or if you do, you're much "deeper in" than I realize) 12:35:38 [executable with all functions here]<--[user interface DESCRIPTION here] 12:35:46 stripped executable 12:35:56 well, you need to do *something* at runtime. you can either use the standardized dynamic linker for it or homebrew something 12:36:15 and again, strippedness doesn't really matter 12:36:32 the ONLY thing i can do at run time is reference a compile time statically generated array 12:36:35 the dynamic linker doesn't use debug info at all 12:36:52 which contains 99.99999999999999999999% of the ENTIRE menu structure items 12:48:32 Holy cow - turn my back for a few minutes and this place just blows up... :-) 13:04:18 --- join: tech_exorcist joined #forth 13:12:03 --- quit: gravicappa (Ping timeout: 240 seconds) 13:27:35 --- join: pareidolia joined #forth 13:43:53 " https://proxy.c2.com/wiki/remodel/pages/BondageAndDisciplineLanguage" HTTP.GET 13:51:16 not found? 14:10:41 --- quit: wineroots (Remote host closed the connection) 14:17:08 back 14:23:37 mark4: ever tried writing something that precompiles the UI to C? 14:23:47 like yacc? 14:24:26 nty :) 14:24:41 i have a solution but its not as elegant as it would be in forth 14:25:42 well of course it's not 14:28:33 --- quit: mtsd (Ping timeout: 240 seconds) 14:35:51 I heard that BASIC can cause permanent brain damage, and I guess C(11) doesn't stop at the brain. 14:36:41 Not so limited as BASIC. 14:37:57 Directly after Compilation a Kernighan's laughter can be heard. 14:38:53 lol 14:39:19 both K & R are probably turning in their graves :P 14:43:30 At the start of COVID-19 plandemic someone commented in #scheme that it was written in C(11). 14:44:01 thats quite humorous 14:44:18 but can the chinese evem code c(11) ? 14:46:30 mark4: You are getting into Conspiracy Theories. 14:46:37 maybe :) 14:47:53 SciFi? 14:58:15 lol 14:58:26 covid is sifi for sure 15:04:47 --- quit: tech_exorcist (Ping timeout: 252 seconds) 15:08:20 I thought Kernighan was still around 15:10:18 yeah, he is 15:12:15 i know lol 15:15:24 by C(11) do you mean C++11 15:20:49 I intend it as an allusion to PDP11 and (occult) man pages section known only to High Priests of UNIX (Cargo Cult). 15:21:05 * tabemann was just reading up on the C++11 memory model and it made his brain melt a bit 15:22:10 ""C Is Not a Low Level Language: Your computer is not a fast PDP-11"" ( https://queue.acm.org/detail.cfm?id=3212479 ) 15:24:07 https://github.com/yosefk/c++fqa ? 15:25:22 the problem with the idea that "C is not a low level language", then what is, assembly? 15:25:41 from glancing at that article, it implies that assembly is not a "low level language" 15:26:03 then what is? custom microcode? 15:26:05 To be a purist, pedantic shite, if it most be translated, then it's not a "low level" language. 15:26:46 to me the difference between a low level language and a high level language is if one has direct access to the addressing space 15:27:22 which, by that standard, C definitely is a low level language, and so is Forth and even C++ 15:27:24 To what degree? Virtual memory? What memory model? 15:28:31 that's a matter of whether code is running under a virtual memory OS in user space or not, not what language it is written in 15:29:01 e.g. C can run both on bare metal, in supervisor mode but under a hypervisor, and in user mode under a virtual memory OS 15:29:31 I was being a bit facetious; I think that as soon as an "abstract machine" is involved, you're not talking about "low level" anymore. 15:29:57 ISO C has the concept of freestanding and hosted implementations. That's it./ 15:30:43 the thing is then even assembly is not "low level" 15:30:59 because assembly code doesn't see micro-op translation and register renaming and like 15:31:09 Precisely. 15:31:15 but rather has an "abstract machine" presented to it by the hardware 15:31:33 The thinly veiled point I was trying to make that "levels" are nonsense. 15:32:46 but then that does not address the point that distinguishing "low level" from "high level" based on ability to address RAM, whether in bare metal or in virtual memory, is a useful one 15:33:06 if we just say "oh well, then all languages are high level" we don't get anywhere 15:33:35 That is the point of programming languages, however. 15:33:41 whereas there's a fundamental difference between, on one hand, C and Forth on one hand and Python and Haskell on the other 15:33:43 --- join: jevinskie[m] joined #forth 15:33:59 What features they have is what makes them suitable for one problem or another. 15:34:25 To reiterate, I am being pedantic. 15:35:23 the problem with being pedantic is that it often isn't useful 15:35:56 like in this case, by essentially saying "all languages are high level", you ignore the fact that important distinctions can be made between classes of languages 15:37:08 Sure e.g. compiled and interpretted. 15:37:34 As for what features are exposed by a given languge, "low level" and "high level" are nonsense. 15:38:37 no, they're not nonsense - they essentially mean whether languages allow access to the addressing space or not 15:38:43 * TangentDelta throws down a PDP-11/03 with a KUV11 Writeable Control Store 15:38:51 There. A true system for writing low-level programs on! 15:39:10 I think they're nonsense. 15:39:41 and as for compiled and interpreted, that is not a firm distinction, due to things like languages with both interpreted and compiled modes (Forth and various Lisps), JIT's, and like 15:40:05 well you're a pedant, that's why 15:40:19 to you, the only low level language is microcode 15:40:28 Oh wait...the MCP-1600's used in the LSI-11 are microcoded themselves. 15:41:30 Well, I baited with you with that distinction on purpose. 15:41:57 Would you consider being able to write to a device, say, a file descriptor, such as a socket, or a file, as being "low level"? 15:42:09 well what is your point, aside from lumping C with Java with Haskell with Python all in one category 15:42:49 boru: that's a question of what API's are exposed, but the programming language 15:42:51 I think you're missing my point, actuallyt. 15:43:16 your point is that all languages are high level, even assembly, which is an utterly useless point 15:44:23 take this: 15:44:32 Would you consider being able to write to a device, say, a file descriptor, such as a socket, or a file, as being "low level"? 15:44:41 you can say the same exact thing about assembly 15:45:48 because you write assembly code that runs under a host OS, which gives it access to things such as FD's, sockets, and files through system calls hidden behind a standard library just as well 15:46:52 So...if you write C or assembly and compile it for x86 and run it on a modern processor, the processor executes it in a non-sequential, superscalar way. 15:47:14 C and assembly assume the code is executed sequentially 15:47:14 yes 15:47:37 hence assembly is a "high level language" 15:47:52 At this point the phrase "high level" has lost its meaning. 15:47:54 So that article is saying that C isn't low-level because the x86 processor is re-interpreting the bytecode into it's eldritch superscalar mechanism. 15:48:11 yes 15:48:16 *into its 15:48:18 and by that logic so is assembly 15:48:54 because the x86 processor is re-interpreting the hand-written instructions into its eldritch superscalar mechanism 15:49:13 I think that trying to program in assembly at that superscalar x86 spaghetti level would drive you insane. 15:49:39 kiedtl: no, it just makes sense to redefine "high level" to something that actually makes sense and is useful 15:49:41 In a modern CPU, a lot of it is machine-learning accelerated lol 15:50:01 So, to reiterate, inventing criteria for "levels" is nonsense, since ultimately, everything is translated. 15:50:08 e.g. whether a language has the ability to directly address memory 15:50:38 boru: you're arguing that because something is translated one can't make any distinctions between things 15:50:38 Hence, the actual point of programming languages. 15:51:19 and I'm arguing that you can make distinctions that actually matter and which can be reasonably defined 15:51:37 if one distinction doesn't work, make a different one 15:52:10 Right. Let's discern programming languages which can make ham sandwiches. 15:52:18 you're being useless 15:52:40 boru: Oh, you mean chef? 15:52:41 Pot, meet kettle. 15:52:51 https://esolangs.org/wiki/Chef 15:52:57 Your distinctions are pointless. 15:53:21 The features of a given language matter. They are, afterall, just tools with different features. 15:53:29 Ergo, with specific suitabilities. 15:53:33 boru: simple question for distinguishing the language: without dealing with things like FFI's, can the language make a machine segfault? 15:54:01 boru that applies to everything except forth bcause forth allows you to extend forth to ass the language features you need 15:54:01 You might as well ask me to solve the halting problem. 15:54:27 boru: that's not like the halting problem 15:54:49 It is, really. Will a perl interpretter segfault? 15:55:00 ^^ Any program can segfault. 15:55:06 boru: if it does not allow access to the addressing space, no 15:55:06 Precisely. 15:55:11 Alan Turing proved in 1936 that a general algorithm to solve the halting problem for all possible program-input pairs cannot exist. 15:55:15 i would disagree with that 15:55:21 you're missing the fucking point guys 15:55:38 I think you're missing the point, actually. 15:55:41 the algoritm is to walk through the code with all possible input (invinite data) 15:55:45 Python e.g. does not expose the addressing point to the user 15:55:52 without writing code that uses the FFI 15:55:53 that IS a working but not viable algorithm 15:56:12 *space 15:56:36 I specifically said "segfault" for a reason 15:56:48 not "crash" or "raise an exception" or like 15:56:58 I ususally make the distinction between an interpreted and a compiled language. Python is compiled to bytecode that is interpreted by a software mechanism. 15:57:03 What does the FFI have to do with it? You can write C code which _should_ cause a segfault, but might also limp onward with corrupted memory. 15:57:22 C is compiled to bytecode that is interpreted by a hardware mechanism. 15:57:22 An interpretter may also do the same. 15:57:29 https://github.com/mark4th/uCurses/blob/master/src/json.c <-- 1285 lines of totally untested C code lol. only one function left to write :P 15:57:36 boru: because FFI's often expose memory that is otherwise hidden from the user 15:57:39 TangentDelta; I take it you haven't written much C. 15:58:08 >bytecode 15:58:10 boru: Not targeting x86, no. 15:58:13 What do you mean? machine code? 15:58:24 bytecode, machine code, what's the difference 15:58:34 tabemann, exactly 15:58:37 I didn't make any distinction about ISA, nor does C. 15:58:58 tabemann: bytecode is confusing in this context because it can be confused with, say, java bytecode 15:59:08 or .net clr bytecode, or whatever 15:59:20 oh. there is one change i need to make to that code so it will pass scan-build make 15:59:27 but we will gloss over that for now :P 15:59:28 kiedtl: anyone who automatically associates the term "bytecode" with VM's is an idiot 15:59:29 I've written and compiled C for an embedded MIPS CPU for example and looked at the actual machinecode bytes (bytecode) in the resulting binary 15:59:39 tabemann: thank you for your constructive insult. 15:59:49 TangentDelta, i feel your pain lol. 15:59:52 scan-build is a bit shitty, ime. I'd recommend invoking it per TU. 16:00:22 Bytecode is...byte code... 16:00:30 kiedtl: well, the matter is that there's nothing stopping me from writing an implementation in Verilog and uploading it to an FPGA... 16:00:33 --- join: X-Scale` joined #forth 16:00:34 no actually i do it on the entire prject and have ZERO bugs except for two i introdced with this code due to a change i KNOW i need to make 16:00:37 so zero bugs 16:00:38 ezpz 16:00:39 It's code executed by some mechanism that is encoded in a binary format. 16:00:54 no no, I mean the scan-build script itself. 16:00:56 anyone who doesn't realize this is an idot 16:00:59 oh 16:01:02 The mechanism can be a Java VM, an x86 processor, a 6502... 16:01:06 clang-analyzer is great. 16:01:06 yes 16:01:33 i cant enforce clang use for building this :( 16:01:35 or i would 16:01:39 Yes, but 'machine code' is less ambiguios 16:01:47 for a start libtool REFUSES to honor my CC setting and invokes gcc 16:01:50 a single ISA can be implemented in hardware or software 16:02:05 whether one calls it "bytecode" or "machine code" is completely irrelevant 16:02:21 compiled forth is virtual cpu assembler 16:02:26 and w.r.t. hardware it can be in an ASIC or in an FPGA 16:02:29 or is physical cpu assembler 16:02:32 --- quit: X-Scale (Ping timeout: 252 seconds) 16:02:32 --- nick: X-Scale` -> X-Scale 16:02:40 tabemann: Or a collection of crabs in tubes 16:04:20 mark4; I do: http://sprunge.us/SMLNcD?make (on freebsd) 16:04:21 Modern x86 assembly confuses the heck out of me. So much going on. So many magic instructions that just do everything. 16:04:29 Pretty sure there's a hello world instruction 16:04:45 * tabemann prefers Thumb-2 and doesn't touch x86 or x86-64 16:05:12 boru well i still cant enforce clang because theres no guarantee you have it installed lol 16:05:23 Ah. 16:05:24 I have a SAM D21 dev board that I need to play with. I was looking at the Thumb instruction set it uses and I like it :D 16:05:37 Well, gcc10 has a static analyser as well. 16:05:41 if i could enforce i could set -Oz optimization 16:05:53 ya 16:06:11 Or you can use cppcheck or something, I geuss. 16:06:38 e.g. http://sprunge.us/5AN0fb?make 16:09:07 But yeah, libtool and autotools in general is a pain in the arse. 16:12:17 agreed lol 16:12:41 but distro package maintainers get pissy with you if you dont use it :P 16:13:01 Aye, there is that. Suited for that purpose, I guess. 16:14:36 All makes are not equal, and all that. 16:17:27 --- join: dave0 joined #forth 16:45:23 K&R 16:45:33 tabemann: AFAIK ""#pragma""-tism is defined by C(11) (it is a Turing Tarpit). 17:03:08 TangentDelta, is that thumb16 or thumb2 ? 17:03:21 you could port github.com/mark4th/t4 to it 17:09:02 --- quit: dave0 (Quit: dave's not here) 17:14:27 Thumb-2 17:14:40 I'm still not sure what I want to run on it for the purposes of my experiment. 17:14:49 Been leaning towards Forth 17:15:29 well t4 is a sub threaded thumb 2 forth :) 17:15:42 its for linux but you could ezpz make it stand alone 17:15:43 I want a multicomputing platform on the cheap to play with. The SAM D21 is perfect because it has 4 serial ports. 17:16:53 I've been playing around with Transputer stuff but it's just too expensive to play with the parallel-computing and graph theory concepts with :( 17:22:40 my zeptoforth is thumb-2 but is aimed at cortex-m MCU's rather than linux 17:25:09 and it's SRT/NCI 17:27:10 TangentDelta: I bought a little Cortex M4 thumb drive a year or two ago (just in time for my employer to defeat USB writing, so I can't use it any more). 17:27:41 It had a nice amount of RAM and flash - my plan was to do a Forth OS for it that would provide a working environment sort of like Gnu Screen. 17:27:59 Just plug it in anywhere and work with it 17:28:17 It was cheap - I can't remember the name of it right now, but whenn I do I'll tell you. Send you a link if I can find it. 17:28:50 Those SAM processors are pretty cool - I've looked at them in the past. 17:28:56 Never did anything with them, though. 17:29:06 If we're talking about the same SAM. 17:29:37 Atmel used to make SAM but it's Microchip now. 17:34:47 Yeah; musical company chairs. 17:39:47 Ok, it was similar to this: 17:39:50 https://www.adafruit.com/product/3857 17:40:05 It was set up to run Python, but my intent was to re-program it with Forth. 17:40:29 I'm not even sure where that thing is now. :-( 17:40:37 Maybe in my nightstand drawer. 17:42:06 I had a lot of fun comparing its specs to the specs of my first IBM PC-AT that I bought back in 1986. 17:42:46 Similar RAM, flash was bigger than my hard drive, and of course on clock speed it just blew the AT out of the water. 17:55:03 back 18:28:46 --- join: boru` joined #forth 18:28:48 --- quit: boru (Disconnected by services) 18:28:51 --- nick: boru` -> boru 19:37:10 --- join: dave0 joined #forth 19:38:24 maw 19:38:39 Hi dave0. 19:39:05 hey KipIngram 19:49:54 --- quit: sts-q (Ping timeout: 240 seconds) 19:51:49 https://xkcd.com/297/ 19:53:18 ehehe lisp 19:54:28 im not a fan of xkcd any more 19:54:36 while i agree black lives DO matter 19:54:42 BLM is a terrorist organization 19:55:07 hell bent on overthrowing our government and destroying the republic through anarchy 19:56:58 I think there are quite a few such organizations these days. 19:57:10 yes 19:57:33 I think a relatively small number of people drive them that way, and there just seems to be an unlimited supply of gullible people contributinng their numbers without kicking the tires. 19:57:52 george soros 19:58:01 Yes. For example. 19:58:14 but tbh i dont worry about it 19:58:28 There's not a lot of point. 19:58:45 If I were suddenly presented with an opportunity to actually do something good that might have a real effect, I'd do it. 19:59:00 But I'm generally not, so I do my work and raise my family and try to enjoy life. 20:01:08 --- join: sts-q joined #forth 20:07:39 --- join: wineroots joined #forth 20:10:58 I don't really follow xkcd; never have. I just ran across that one in a stackexchange answer and thought it was cute, and fit into our recent discussion of Lisp. 20:14:11 satan does his works but its alwaus to gods purpose 20:14:46 i dont hate xkcd :) 20:15:13 but obviously he is a socialist tree hugger or scared of the anarchists 20:46:48 --- join: gravicappa joined #forth 20:50:46 i hate xkcd 20:51:12 it is sappy and i hate it 21:11:08 --- quit: proteus-person (Ping timeout: 240 seconds) 21:14:23 --- quit: nmz (Ping timeout: 252 seconds) 21:20:52 --- join: mtsd joined #forth 21:24:40 --- join: proteus-person joined #forth 21:32:52 --- join: mtsd_ joined #forth 21:35:40 --- quit: mtsd (Ping timeout: 265 seconds) 21:38:50 user-friendly was good at one time 21:48:06 saying that BLM is a terrorist organization really sets a low bar for what counts as "terrorism" 21:48:35 by that standard the protestors in hong kong are "terrorists" 21:49:50 the protestors in hong kong are burning things to the ground and looting? 21:49:59 and destroying historical monuments? 21:50:45 the thing is that when you have very large numbers of protestors, there will always be some doing such things, and they stick out because they make news, even though in reality they are a minority 21:51:08 whereas when police beat the shit out of protestors because they can, it is generally overlooked 21:51:22 --- join: mtsd__ joined #forth 21:51:25 blm are funded by george soros 21:51:36 about those "historical momuments", they are monuments to traitors who should have never been so honored 21:51:37 and its not a few doing it 21:51:41 its ALL of them 21:52:37 all is a major exaggeration 21:52:49 and "george soros" is a conspiracy theory 21:53:13 next thing I will hear is that BLM is really funded by the bavarian illuminati 21:54:13 --- quit: mtsd_ (Ping timeout: 260 seconds) 21:54:19 * tabemann has long heard of george soros being a mastermind behind everything supposedly left-wing or subversive 21:55:34 anyways, it's getting late here, and I haven't yet figured out how to get PLL working on the L4, so I'm going to bed 22:06:59 --- join: andrei-n joined #forth 22:07:09 --- join: Kumool joined #forth 22:13:13 --- quit: mtsd__ (Ping timeout: 252 seconds) 23:11:51 --- join: mtsd joined #forth 23:59:59 --- log: ended forth/21.04.17