00:00:00 --- log: started forth/18.12.30 00:03:52 okay, I'm headed off to bed - bbl 00:05:07 tabemann, good night 01:09:00 --- join: john_metcalf (~digital_w@host86-191-16-140.range86-191.btcentralplus.com) joined #forth 01:17:44 --- quit: pierpal (Remote host closed the connection) 01:27:52 --- join: pierpal (~pierpal@95.239.223.85) joined #forth 01:42:31 --- quit: pierpal (Ping timeout: 272 seconds) 01:58:37 --- join: pierpal (~pierpal@95.239.223.85) joined #forth 02:00:55 --- quit: pierpal (Read error: Connection reset by peer) 02:03:59 --- join: pierpal (~pierpal@95.239.223.85) joined #forth 02:04:10 --- quit: ashirase (Ping timeout: 245 seconds) 02:06:58 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth 02:23:09 --- quit: pierpal (Read error: Connection reset by peer) 02:23:42 --- quit: reepca (Read error: Connection reset by peer) 02:24:47 --- join: reepca (~user@208.89.170.250) joined #forth 02:26:43 --- join: pierpal (~pierpal@95.239.223.85) joined #forth 03:02:52 --- quit: pierpal (Ping timeout: 250 seconds) 03:03:31 --- quit: DKordic (Ping timeout: 246 seconds) 03:15:26 --- join: pierpal (~pierpal@95.239.223.85) joined #forth 03:19:47 --- quit: pierpal (Ping timeout: 244 seconds) 03:21:13 --- join: pierpal (~pierpal@95.239.223.85) joined #forth 03:25:22 --- join: Labu (~Labu@labu.pck.nerim.net) joined #forth 03:25:28 --- quit: pierpal (Ping timeout: 244 seconds) 03:26:13 --- join: pierpal (~pierpal@95.239.223.85) joined #forth 04:54:10 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 05:43:29 --- quit: dys (Ping timeout: 240 seconds) 05:43:41 --- join: rdrop-exit (~markwilli@112.201.166.158) joined #forth 07:01:44 --- quit: rdrop-exit (Quit: Lost terminal) 07:19:51 --- join: Kumool (~Khwerz@adsl-64-237-239-100.prtc.net) joined #forth 07:26:27 really unsure about the usefulness of this, but here goes :) - over the past few nights, i've been knocking up a little library which provides FORTH-like functionality as a header only C++ library - it's not designed for speed, it's poorly documented and organised and it's incomplete - i have plans to take it further, but figured what the heck - may as well see if there's any interest :) 07:26:49 https://gitlab.com/lilo_booter/rpany 07:27:49 it's called rpany as it makes heavy use of boost::any - which provides flexibility, but at the same time makes it slow 07:28:20 for the type of stuff i have in mind, this isn't an issue 07:28:49 why C++? Your users will be dead of old age before the compile finishes. 07:29:00 :p 07:29:45 sure - it could be done in other languages, but i have a specific use in mind for a c++ library i've been working on for a few years 07:31:02 it also provides some syntactic sugar that appeals to me - like push and pop via the << and >> operators (<< being 'to the stack' and >> 'away from the stack') 07:35:50 --- join: dys (~dys@tmo-116-151.customers.d1-online.com) joined #forth 07:37:38 also, lambda's - currently you can add stuff to the dictionary via stack.teach( "dup", [] ( rpany::stack &s ) { boost::any a; s >> a; s << a << a; } ); (but there's also pick and roll implemented so you can just s << ":" << "dup" << 0 << pick << ";" or use eval_input) 07:37:53 seems flexible to me anyway :) 07:55:22 --- join: gravicappa (~gravicapp@h109-187-245-90.dyn.bashtel.ru) joined #forth 08:30:18 --- quit: proteusguy (Ping timeout: 244 seconds) 09:14:37 --- quit: dys (Ping timeout: 268 seconds) 09:24:14 --- join: proteusguy (~proteus-g@49.230.15.216) joined #forth 09:24:14 --- mode: ChanServ set +v proteusguy 09:24:41 OK, we got a VM yet? ;-P 09:31:29 Wouldn't Loeliger be a good example of VM? (Granted, his is the classic ITC). I was under the impression his scheme was predicated on the FIG plan. 09:49:25 Is there a way to make sure that forth code doesn't just call into random interpreter code? 09:50:21 Unless your implementation does some major voodoo, how? Anything on RS is potentially "executable code" 09:50:36 Exactly. 09:50:40 Hmm... 09:51:00 I'd be against that sorta' condom almost everywhere 09:52:55 Well, I want to protect my low-level functions so nobody can just jump to a random location and start messing with my functions. 09:53:24 Wow, I missed a lot of high intensity Forthscussion 09:56:31 --- join: rdrop-exit (~markwilli@112.201.166.158) joined #forth 10:06:40 john_cephalopoda: I am fairly sure CM would smile and nod, and not agree ;-) 10:07:27 I do agree we don't need heart/lung machines to offer such flexibility to the "user" ;-P 10:08:38 John is still attached to his worldy C-like concepts 10:09:28 I like C.. although not C++ or ##C - I like forth, too.. (And I used to like assemblers, but I really, really hate linkers) 10:09:58 I like C too, but Forth suits a completely different approach 10:10:06 absotively 10:10:35 ..for one thing, it's a lovely perversion.. For another, an actual app can be teeny-tiny. 10:11:48 And, anyone that has had gcc produce .S files will know that the goddamned C generates the most massive clusterfuck of register-juggling. 10:13:08 efficient register juggling? 10:13:40 MrMobius: "efficient" would be: "stop screwing with registers entirely when you are not even using them". 10:14:18 I became much less angry/irked when I found the "naked" attribute. 10:14:34 youre saying there are instructions without any useful effect in optimized output? 10:14:44 (serious question. never looked at gcc output) 10:15:21 MrMobius: You could write really simple things - without returns or args - and it'd still juggle a dozen regs. It was extremely painful. 10:16:08 For a host/pc machine, fine - go fuckyerself.. For code headed to an AVR or samd, etc: good god. 10:16:35 Anyway, I must head to work - carry on. 10:22:40 --- quit: dave0 (Quit: dave's not here) 10:31:40 john_cephalopoda: I don't think there's a good way of doing that. 10:32:14 It might be possible to add guards to make sure people can't overwrite code, and depending on how your Forth is structured, you might be able to control jumps/calls to some degree, but I see this as being more trouble than it's worth in most cases. 10:50:26 --- quit: gravicappa (Ping timeout: 250 seconds) 10:50:47 It's a problem with multiuser systems, avoid those. 10:50:51 Problem solved 11:26:25 hey guys 11:32:30 I wouldn't bother with attempting to prevent the user from fucking around with the interpreter 11:41:45 Hmmm 11:47:44 I want to come up with a basic core set of words that any forth implementing the #forth standard would implement 11:49:11 I don't feel like I am really up to doing that, because I'm most familiar with ANS/Forth 2012, and that is what we are trying to not implement - who here knows FIG Forth and Forth 83 the best? 11:49:51 Well ANS is mostly good 11:49:56 FIG was bigger than ANS 11:50:16 Is there a FIG "standard" document? 11:50:29 Or is it one of those "The implementation is the standard" things? 11:50:31 FIG was a bunch of xeroxed code 11:51:25 Did it run on the Xerox Alto? ;Ã¾ 11:51:44 I think not 11:52:26 john_cephalopoda, I think FIG Forth was one of those "the implementation is the standard" things 11:54:29 I do wish there were a FIG "standard" document, because I don't feel up to figuring out how it worked from very poor PDFs of ancient code 11:55:10 http://forthworks.com/forth 11:55:36 there are two 11:56:08 thanks 12:07:38 question 12:08:08 the Forth 79 doc states that TRUE is 1 - I assume we want TRUE to be -1, right? 12:09:48 --- join: mtsd (~mtsd@94-137-100-130.customers.ownit.se) joined #forth 12:10:19 hey 12:15:07 with TRUE being -1 (or all one bits) you get the property of being able to use AND and OR and other bitwise words as boolean logic combinators 12:15:16 yes 12:18:14 I just thought of something - with TTC we can produce a standard booting image which any compliant implementation with the proper cell size can boot into a working implementation, circumventing the need to write a forth outer interpreter in assembly or C to bootstrap the Forth off of (as I've had to do with attoforth) 12:18:42 and thus minimize the portion of the implementation of #forth that needs to be in primitives 12:20:32 this image can be generated by a metacompiler written in Forth or some other language (e.g. the popular example of Scheme) 12:30:57 I also thought of something 12:31:24 if possible, it should be possible for implementations to JIT the TTC code to native code in a fashion that is transparent to the user 12:32:16 so that compiling words generate TTC code with absolute addressing, and a JIT can then turn that into native code 12:32:53 What's TTC? 12:32:59 the TTC code should be able to be saved, though, with processing to handle changing absolute addresses, into images that can be loaded later 12:33:06 token threading 12:33:28 Ah 12:33:46 there you've got an array of word addresses, and the TTC code is an array of indices into that array 12:34:02 I am thinking about using TCC for kernel-level stuff and something else for user-level words. 12:34:12 *TTC 12:34:24 tabemann: are you styling your TTC on FCode in OpenFirmWare? 12:34:38 Zarutian: hadn't thought about that 12:36:20 I originally was against using TTC thinking it'd be too slow, but I realized that TTC would allow portable loadable images, and speed could be achieved through JIT 12:36:43 (rdrop-exit had suggested TTC last night for #forth) 12:38:47 and portable loadable images would avoid the chicken-and-egg of how do you create a working Forth implementation written in Forth without already having a working Forth implementation to compile the Forth with 12:39:30 of course it would still require metacompilation 12:39:37 initially 12:40:08 but that would only be until we had a #forth implementation that could save portable loadable images 12:40:44 What would be the use of such portable loadable images? 12:41:31 john_cephalopoda, so you could write as much of your forth in forth as possible, and minimize the number of primitives - so that the forth compiler and interpreter themselves could be written in forth 12:43:06 Wouldn't that also work with any other kind of threading model? 12:43:20 with attoforth I had to write the compiler and interpreter in C because I needed them to bootstrap the rest of the system, because attoforth is largely written in forth in a textual format - even though eventually once the system is sufficiently bootstrapped I compile a new compiler and interpreter with the original ones 12:43:56 john_cephalopoda: TTC would simplify being able to save an image in a flat file format 12:44:32 because otherwise you'd have to relocate every word address reference from within the code 12:46:02 I am writing my impexus operating system entirely in Forth. The base of it all is an assembler. 12:47:08 Basically I have got a continous memory area and when I write something like "EAX EBX MOVR32", it will find out the opcodes and put them into the memory area. 12:47:33 I always keep track of where I am in the memory area, so I can directly calculate jumps. 12:49:16 Now I'll probably define several Forth functions, which will allow me to write Forth code which is translated to assembly directly. 12:49:22 It's kinda complex to explain... 12:49:28 12:49:30 --- quit: pierpal (Quit: Poof) 12:49:48 --- join: pierpal (~pierpal@95.239.223.85) joined #forth 12:50:05 The main issue I face is how to make sure that things are protected. I don't want userspace processes to mess around in kernel memory. 12:50:05 #forth would be in a VM, so no assembly would be present in portable code - but we should make it open to writing assembly in non-portable code 12:50:40 You can't have a VM without having native code. 12:51:34 Basically I am writing a stub on top of which I can put the actual Forth code. 12:52:39 the VM itself would be written in assembly or C, but that would be a minimal amount of code independent of the majority of the Forth implementation (which would be in TTC code) 12:53:16 I like the TCC tables. They are kinda elegant. 12:53:56 --- quit: pierpal (Ping timeout: 250 seconds) 12:54:32 But how does one make sure that a program can't just do _anything_ - read any memory, jump anywhere in code? 12:55:06 fence registers I'd suppose 12:55:21 but it'd involve a performance hit 12:55:59 Not too big of a performance hit. I bet that a lot of that stuff can be done with an MMU on platforms that got one. 12:56:42 a MMU wouldn't prevent forth code from executing forth code in the wrong place on a TTC or ITC system, because TTC and ITC aren't "really" executing code 12:57:25 if you were doing native code, though, an MMU could prevent executing code in the wrong pages 12:57:38 or JIT off of TTC 13:00:18 Hmmm... I have to think about architectures that can prevent people from jumping to stupid parts of code. 13:01:04 I'd be more worried about people writing to or reading from the wrong parts of code 13:01:20 writing for obvious reasons and reading if anything involving crypto is being done 13:01:38 just jumping into the wrong code, well, if it crashes, oh well 13:01:55 * Memory accesses from userspace must be observed by the kernel. If the process wants to access some bad memory, then it has to die. 13:02:28 tabemann: When you jump into just the right code, you can take over the system. 13:02:45 not if the MMU prevents you from accessing the wrong data 13:03:12 you can still execute code, but you'll just crash when you access the wrong thing 13:05:37 not that preventing the user from exxecuting the wrong code is a bad idea 13:06:41 Forth offers a bunch of words that you can use to do stuff. By identifying problematic words and adding safeguards, the user could be prevented from doing dumb things. 13:07:52 with TTC one can avoid needing safeguards on each word that is executed, only needing safeguards for when memory is directly accessed or when branches take place 13:08:37 because with TTC you just check whether token x for word x < current number of tokens for the current user 13:09:44 rather than having to check to make sure a given word reference is not garbage in a more complicated fashion 13:10:29 Yeah, it sounds like a nice idea. 13:12:15 if you're worried about speed, what you can do is verify that all the tokens in a word are valid when ; is executed, and then JIT the code afterwards 13:12:56 so the verifying of token correctness is a one-time cost 13:14:32 EXECUTE ( token -- ) 13:14:36 Hmmm... 13:14:51 but I'd assume EXECUTE would be infrequent 13:15:07 you'd still have to verify token correctness when EXECUTE is run, though 13:16:16 Hmmm... 13:16:48 Maybe you could have two EXECUTE functions that are just overloaded - one for kernel space and one for user space. 13:17:18 you could have separate token tables for kernel space and user space 13:17:38 Ok, first of all: What would the Forth code look like in memory? 13:18:26 token token token branch-token branch-address literal-token literal-value etc. 13:18:46 note that this could be JITed into native code 13:19:46 JMPing (or CALLing into) the code pointed at by token... 13:20:24 yes, but once you've verified the token, you know the JMP or CALL will be safe 13:20:43 Where do you store the JIT-ed code? 13:21:08 If it isn't in special memory, you could simply overwrite addresses there and jump to any location. 13:21:19 it its own separate code space, such that you have execute access to it but not read or write access 13:21:29 or at least not write access 13:21:54 *in its 13:21:58 --- join: pierpal (~pierpal@95.239.223.85) joined #forth 13:22:23 When that's so simple, then why not put stuff into non-readable locations in the first place? 13:22:29 *non-writable 13:22:58 There could be a separation of dictionary and regular memory. 13:23:37 TTC code has to be writable, because compilation words have to be able to write into it prior to ; being executed 13:23:54 ; would JIT the code and freeze it in non-writable memory, forbidding subsequent edits 13:24:31 Hmm... compilation words... 13:24:57 you can use the MMU if you have one to protect memory in general, of course, which would speed up a lot of stuff (as using the MMU is faster than fence registers doing so manually) 13:25:29 Heh, idea: Push tokens to the stack, call "compile". It will compile to some non-writable memory. 13:25:42 well, to user space 13:26:26 Only problem: how do you call that word from your code? 13:27:08 4th uses a memory model with segments separating different areas and some restrictions on writing to code space. IIRC, you can read and execute compiled code, but not directly write to it. 13:27:10 because EXECUTE is a primitive, it can execute tokens 13:27:46 Let's say you have compiled "EMIT" and it is compiled to non-user-writable memory. How do you execute EMIT? 13:28:06 ; compiles the token for EMIT into native code 13:28:25 or EXECUTE looks up the token in the table and executes it in native code 13:28:44 Hmm, right, that could just work... 13:28:45 which EXECUTE can do because it's a primitive 13:33:09 --- quit: pierpal (Ping timeout: 240 seconds) 13:37:48 --- join: dys (~dys@tmo-116-25.customers.d1-online.com) joined #forth 13:39:35 Hmmm... Do tokens even make much sense there? 13:41:34 Take ": NAME WORD1 WORD2 WORD3 ;" - if you really want to JIT it, you can just as well put it into a non-writable dictionary by writing out its code. 13:42:36 Having a dictionary separate from general data might just be the way to go. 13:44:18 tokens are needed because of EXECUTE and because compilation words need access to the code, so it needs to be made to a form of code that can be ensured to be safe 13:44:47 --- join: pierpal (~pierpal@95.239.223.85) joined #forth 13:45:28 tokens can be ensured to be safe in a way that no other means of representing references to words can be 13:46:14 at least, in a way that no other means of representing references to words can be in a performant fashion 13:47:26 --- quit: mtsd (Quit: WeeChat 1.6) 13:47:39 also, TTC code is simple, whereas directly compiling to native code is much more complex (because of handling forward and backward references against actual instructions) 13:48:19 okay, I'm gonna go for now, bbl 14:01:33 also considering the same aspect - i hope to just get away with defining a each word as an iterable list of tokens where a token is either a numeric, a pointer to a function or data (functions either use just the stack, or parse the following tokens [with parsing cached to avoid evaluation on each use]) 14:03:14 will probably not work as intendend :) and probably won't appeal to a FORTH purist - am aiming for a higher level thing though 14:04:48 i've added some docs for the current vocabularies and split the code up a bit - hopefully a little more readable now - https://gitlab.com/lilo_booter/rpany 14:05:46 (and i hope no one minds me posting here - i figure that it's too niche to be of interest anywhere else and i'll totally understand if there's no interest here either :)) 14:18:01 fwiw, the eventual goal is to provide a base for video filter graph creation and playout control/scheduling and so on - i have a stack based mechanism for this now, but it's kinda hokey - looking for something nicer - still unsure if this is it, but hope to get to test that soon 14:34:39 --- quit: dys (Ping timeout: 268 seconds) 14:50:27 the_cuckoo: it needs a license, but looks interesting from the README 14:51:14 ah - cool - thanks crc - was considering lgpl 14:51:52 --- join: tbemann_ (~androirc@71-13-2-250.static.ftbg.wi.charter.com) joined #forth 14:57:29 OK, back - trying to catchup - which is easier with Drink In Hand ;-) 14:57:50 I'm in for TTC 14:59:03 because native code can always be JITed off of TTC 14:59:40 and TTC lends itself to portable binary images 15:00:12 yea i am considering TTC 15:00:21 the_cuckoo: gpl anything is usually "I plan to ignore this forever" 15:00:38 i'd like a more compact encoding, but my platform is 32bit 15:00:43 and TTC makes it easier to ensure code safety 15:01:02 corecode: so? if it's 8bit tokens, you fetch 4-at-a-time 15:01:54 how do you handle more than 256 words? 15:01:58 Ideally, the tokening can act like utf8: markers to specify 'another byte' and '2 more bytes', etc 15:02:04 aha 15:02:04 yes 15:02:17 PoppaVic: :) - i certainly don't intend to ignore if it proves useful - if it doesn't, well, yeah - meh :) 15:02:38 but the kick is: limit your total TOKENS and everything else is a list-of-token-addresses 15:02:47 i first need to implement FIND and a string compare 15:03:38 the_cuckoo: my point is.. Some folks flatly will not touch/view GPL-anything. I stopped giving a shit about licenses when GPL-anything proved viral and got slapped on EVERYTHING - including previously PD code. 15:03:49 to me tokens are to enforce safety, portability, and to provide a layer of abstraction that can hide a JIT 15:04:05 sure, tokens can do that as well 15:04:12 GPL is absolutely BASED 15:04:24 based on? 15:04:50 Oh based is an adjective meaning "cool" 15:05:10 like I would have 32 bit tokens on 32 bit systems 15:05:19 b"bastich" maybe what you meant to 'spel' 15:05:53 tbemann_: you CAN, but it's not even remotely a necessity 15:05:54 PoppaVic: fair enough - the library which i intend to use it with is lgpl though and that is in use, so i'm happy enough to keep it that way (admittedly, it's only used commercially at this point on account of me not keeping the public repo up to date for a while :)) 15:06:49 okay gonna head home 15:06:50 i also hadn't come across the 'based' thing :) 15:06:55 the_cuckoo: this is one of the reasons FIG collapsed and died.. Most of their GOOD writers, (and I mean code or articles), couldn't share the damned code due to NDA crap. 15:07:01 --- quit: tbemann_ (Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )) 15:07:44 even uselessnet had that issue, and I recall a thread with good ol' Liz mentioning the NDA and Forth, INC and clients. 15:08:21 yeah - it's why i insist on working on and with open source components with my customers - lgpl or bsd is my preference as it allows the mix with closed source stuff 15:08:49 tabemann: this was a token-forth I had opened to read before work this morning: https://github.com/mikaelpatel/Arduino-FVM 15:09:10 with Forth I don't see the GPL being a hinderance to writing a closed source version of the code 15:09:27 it's Forth, you can do anything a number of correct and consistent ways 15:09:45 I don't see GPL as a hinderance at all - I ignore it utterly.. But, otoh, I never get paid to code. 15:10:09 ah 15:10:41 gpl is too strict - very little commercial use there - lgpl is a different thing though 15:10:59 I predate Stallman's GPL - he can suck my ballsack. 15:11:08 :) 15:11:11 LGPL is only marginally better 15:11:33 When did he release Emacs? I might be that old. 15:11:35 I'd prefer a world where copyright didn't exist so it couldn't be used to fuck me 15:12:11 I like the GPL because it stops my own code being used for that purpose 15:12:16 well, yeah - it's a pain - but still... it ain't going anywhere anytime soon 15:12:18 Hey, Copyright is fine: "This is my book". Great. I spent a vast amount on books over the last 6 decades. 15:12:33 No, copyright is nonsense. 15:12:52 otoh, this is code: "Gee, I was inspired by WilhelmVonWeiner - but screw that, I didn't like this/that/other..." 15:12:53 "Copyright" is a misnomer because it's in no way a "right" 15:12:53 Forth can be tricky if using image or turnkey based systems. If the core image / system is GPL, and your code is compiled and distributed along with the GPL'd portion, it may require that your code must also be GPL 15:13:23 yeah - which is generally why companies don't touch it 15:13:35 WilhelmVonWeiner: it leads back to Patents and the days when commo was slow and biz was slower: you got time to get yer biz up and running.. For writers, it always just meant 'gentle rape". 15:14:09 IsForth (x4 now) includes an explicit exemption to the LGPL to work around this 15:14:36 crc: sounds like it just needs a simple license Kahn managed. 15:15:15 I personally think an author should decide if their code is system/library code or application code, and use MIT/PD and GPL respectively 15:15:59 most "authors" (you mean coders, programmers, or CS-majors), are too inept to decide how to brew tea. 15:16:27 PoppaVic: you have something against tea brewing programmers, eh? 15:16:27 and, remember: PD is not "legal" in places like Germany - and we all know chinee never cared anyway 15:16:44 Zarutian: not at all: I usually nuke a cuppa each morning 15:17:03 PoppaVic: what is PD in this context? Public Domain? 15:17:06 Yes 15:17:28 PoppaVic: does that mean the usual ASIS CYA clause is invalid too? 15:17:35 I was fairly poleaxed to learn PD was "not legal" in some countries. 15:17:51 for library stuff, lgpl is a nice balance - but actually, it occurs to me that it doesn't fit for a header only library (which means i'd be looking at bsd i guess) 15:17:55 PoppaVic: are these malapropisms intentional? 15:17:56 I know CYA - wtf is ASIS? 15:18:39 PoppaVic: "This software is AS IS and does not imply any liability acceptance bla bla bla ..." kind of crap 15:18:53 WilhelmVonWeiner: typically, I do occasionaly fubar - 99% of the time I play the words. 15:19:53 Zarutian: ahh.. You know? I am not sure.. I always felt that was like getting a free car - not buying a car.. ASIS when the car is FREE is... well, sane.. If yer paying for it, it's iffy. 15:21:21 Isn't CC-0 basically "legal" anywhere? 15:21:42 Zarutian: that was (to me) just sane PD/open/go-wild/here-it-is "programming", (or even telling someone how to build something sorta' trivial).. "This worked for me, yer free to go apeshit, YMMV" 15:22:08 PoppaVic: yeah, it is quite funny because where I live EULAs that usually have such clause have no legal or enforcement weight here. (Lack of meeting of minds during contract composition etc, which means DRM can also be circumvented for all other purposes than republishing) 15:22:09 actually, thinking again - may as well go for the WTFPL 15:22:19 john_cephalopoda: http://choosealicense.com/licenses/ is what I went to 15:23:07 doesn't list https://en.wikipedia.org/wiki/WTFPL 15:23:23 Zarutian: I tend to believe that any time you need a lawyer to obfuscate what you mean - or a court to sort it - avoid it. 15:23:23 PoppaVic: Wikipedia actually states that the Unlicense isn't really a great license and that CC-0 should be used instead. 15:23:24 because WTFPL doesn't even have a warranty clause afaik 15:23:53 PoppaVic: https://en.wikipedia.org/wiki/Unlicense#Reception 15:23:55 john_cephalopoda: that's fine, except I also trust Wikipedia about as much as Google, Facebook, etc 15:24:29 Well, in general it's a good source 15:24:35 Feel free to overpay a lawyer for their opinion, but I've also seen over the years that you still get stuck when they lie. 15:24:37 the_cuckoo, looks like a cool little project! You need a LICENSE file up there. 15:24:46 too many wikisalted bullshit yer pals planted to make your gullable arse believe it, eh? ;-) 15:24:48 I think aversion to wikipedia is due to a misunderstanding of how wikipedia operates 15:24:56 WilhelmVonWeiner: it's *A* source. Nothing more than that. 15:25:07 Well, it's not a source at all 15:25:38 proteusguy: cool - thanks :) - it really isn't going to rival a proper forth compiler though, but i know that there are things i can do with it.... 15:25:39 Encylopedia Britannica wasn't a source either? 15:25:41 WilhelmVonWeiner: it is like all encyclopedias, not a good source for anything but nice starting point to look for some. 15:25:43 CC0 is the closest thing to a worldwide public domain I've seen 15:26:05 Zarutian: I can tell you grok where I am on that ;-) 15:26:36 PoppaVic: havent ya written any essays in elementary school where you have to cite your sources? Encylopedias are not allowed as sources, but you can meta-cite them where you got you citations 15:26:42 crc: I'd accept that as a license if someone added that sentence to their code as well ;-) 15:27:07 john_cephalopoda, if you want to protect forth from jumping to places that aren't proper code, the best way is to implement a strong compile-time type system. I'm working on something like that now. 15:27:14 Zarutian: dude, my elementary days were back in the low 60's, and yes: they were valid. 15:27:49 PoppaVic: well, just shows that they got something corrected over the years. 15:27:49 Britannica was the canonical source for me old man 15:27:54 and his old man before him 15:28:07 proteusguy: that's extremely tough if you add peek/poke abilities. 15:29:06 Zarutian: as I got older I could visit the public and U libraries, and I still took it all with a grain of salt. 15:30:09 BUT, my bottomline was simple: you don't like my sources for a silly class-paper? Prove they are WRONG.. (My folks were teachers, saw me do the work, proofread it - I'm done). 15:30:22 PoppaVic: that is the POINT of it. Now days some peeps are just too damn quick to apeal to authority. 15:30:53 (taking the stuff written with grain of salt) 15:31:03 Zarutian: the Authority is what mandated the assignment, and then claim it's wrong, too. I know exactly wtf the schools are doing. 15:31:36 proteusguy: The problem is that compiled code is stored in accessible memory. 15:31:55 well, if you let schooling get in the way of your education then one is going to do poorly 15:31:59 ANYWAY, yes - the commons license is fine if we add a line that explains the base-goal/meaning. Fucking legal-weasels make me look for clocktowers. 15:32:11 Zarutian: HA! Yup 15:32:30 proteusguy: It would still be easily possible to find out where it was compiled to and inject some malicious code. 15:32:53 well, as i said before, i was considering lgpl - but that only works if an end user is able to replace the lgpl component with their own version - header only explicitly removes that option (essentially forcing the portions of the hosting project to be recompilable - no one would touch that commercially) - so BSD, WTFPL - something like that would be required 15:33:27 the_cuckoo: the conversation steered back to the #forth VM idea ;-) 15:33:44 ah - sorry :) 15:34:04 np, you understood where we were going - all plus. 15:34:05 * Zarutian just, usually, leaves any such license crap out and replace it with a warning on the effect there is a deliberate subtle bug put in there somewhere 15:34:33 that's dirty, but fair I suppose. 15:34:48 specially so when I have forgotten to put the bug in 15:34:57 \ WARNING:: THIS CODE WILL LOSE ONE OF EACH OF YOUR SOCKS 15:35:10 I don't have an issue with something like corporate snaggin the idea, optimizing all over, but keeping the interface, either. 15:35:28 WilhelmVonWeiner: nice. I can even do that w/o his code! ;-) 15:36:28 john_cephalopoda, I have "protected" system words which regular code can't access in its definitions. Anything outside of the type system includes that. 15:36:29 That's a copyright violation and WvWSF (WilhelmVonWeiner Software Foundation) Laywers will be all over your ass 15:37:14 WilhelmVonWeiner: this is why I think we need an Open Season on Lawyers - and bonus points for Lawyers turned politicians. 15:37:52 I really lack the wallspace for a nice array of head-mounts, however ;-) 15:38:45 Shrink em in brine. 15:39:08 the_cuckoo, MIT license is a great default if you want your code to be adopted easily. Lots of folks see xGPL anything and just walk away (for good reason). 15:39:11 well, skulls make that tough - but vinegar does make 'em flexible ;-) 15:39:14 Shrunken varnished laywer-head golf balls. 15:39:32 PoppaVic: why do you know so much about this? 15:39:36 proteusguy: heh - i had just posted an MIT license file :) 15:39:47 the_cuckoo: like I said, https://choosealicense.com/licenses/ is useful. 15:40:06 PoppaVic: yeah - was reviewing that - went MIT 15:40:22 Zarutian: I read (current and past-tenses) a lot, and did some science and suchlike. 15:40:33 proteusguy: Which threading model are we talking about with that system? 15:41:32 john_cephalopoda, was thinking DTC but not set in stone. 15:42:49 proteusguy: I thought the "architectural variants" stuff was a bit confusing 15:43:18 Which discussion is this? proteusguy's project? 15:43:18 I hope that's something discussed sooner rather than later so I can try and see the reasoning behind it 15:44:06 WilhelmVonWeiner, it just means we need to define a set of targets that we want the standard to support. But if people want to push their target they're gonna have to be willing to provide code. 15:44:11 proteusguy: So something like ": NAME W1 W2 W3 ;" will become a thing in memory, which consists of several pointers to code. When you know where NAME is located, you can pretty easily use ! to store any addresses where the pointers to code are supposed to be. 15:44:21 PoppaVic, the #forth standard i suspect. 15:44:26 oh, thanks 15:45:36 I noticed, when I researched them, that there were so damned many pseudo-code variations that it almost trebled the amount of work before you could understand wtf was happening. 15:45:53 proteusguy: Basically, as long as you are storing code to unprotected memory and the user can use !, the user can change memory addresses in the word definitions and ruin any security. 15:46:06 I know forth is not the ONLY "language" that coins terms, but goddamn it gets old. 15:46:28 So #Forth won't be targeted at an abstract machine? 15:46:37 but a volume of abstract machines? 15:46:42 john_cephalopoda: that doesn't really bug me in a single-user/rebootable dev-system 15:46:51 john_cephalopoda, the type for NAME is "fun". All you can do is call it or reference it. Being a "system" function will mark it as such (a flag like immediate) so it becomes "sys-fun", and the compiler won't let a "fun" target a "sys-fun". 15:47:32 PoppaVic: Then you also don't need protected words. 15:47:33 WilhelmVonWeiner, yes, primarily parameterized on the cell size I suspect. 15:47:43 WilhelmVonWeiner: I think the idea was to - and I could be wrong - nail down what the variations are, what the absolute essentials are, and code for the several variants.. Hopefully using uniform terms and functional examples. 15:47:54 PoppaVic, bingo. 15:48:39 john_cephalopoda: correct, in any other case, you almost want to sandbox or deny them.. But I don't plan to tinker forth on someones heart/lung machine while they are in a coma 15:49:00 proteusguy: HERE : DUP2 DUP DUP ; 120 DUMP 15:49:04 proteusguy: thanks.. I thought I was grokking 15:49:04 Oh, so those are implementation standard, but functionally all CORE code would run the same given the same cell size? 15:49:11 proteusguy: 15:49:27 That command will show you the code of DUP2 in memory. 15:49:40 WilhelmVonWeiner: that was a sticking-point the other day, but I see it (at worst) as a 2D matrix. 15:49:58 proteusguy: And you can obviously use ! to change the code in any way you like. 15:49:59 WilhelmVonWeiner, given identical parameters of the variant, yes. Not known whether cell size alone is adequate. 15:50:38 john_cephalopoda, the compiler will know the type at that address and not allow you to execute a ! there. 15:51:06 I think it becomes a case of "we definitely need macros" and "how many bits is...?" 15:51:12 john_cephalopoda, a strong type system makes for a completely different language and style of coding. I'm not suggesting it's forth. 15:51:53 That sounds weird to me. Standard code that wouldn't work ona standard system, because they're incompatible versions of the same standard? 15:52:15 sounds like just biz as usual to me 15:52:53 WilhelmVonWeiner, the goal is source compatibility without incurring needless complexity. How you gonna do that for code that runs on 8 bit and 64 bit forth? The core core words certainly must operate differently. 15:53:57 i'm actually kinda thinking of strongly typing myself :) (but then, what i'm doing is only FORTH-like - i don't think it fits for FORTH itself) 15:54:13 the_cuckoo, we're of the same mind... ;-) 15:54:21 :) 15:54:22 the_cuckoo: check out the concatenative wiki 15:54:25 "strong typing" sounds like a special stack, and a DSL. 15:54:51 there's a lot of stack languages and you might get some good ideas from one 15:54:55 "strong typing" sounds like broken keyboards to me, a whailing and shit 15:55:14 it would introduce a slow down and words would have to be more specifally specified i think 15:55:24 ah, Zarutian - that explains my dead lappy inbuilt and use of the USB ;-) 15:55:53 specifically-specified made me smile ... hard ;-) 15:56:02 PoppaVic, I thought it might require a special stack but it actually can all be handled at compile time with a word structure expansion. There is some runtime overhead for dispatching potentially ambiguous words but most stuff is compiled directly to the target. 15:56:15 PoppaVic: :) 15:57:01 proteusguy: I'd watch it, like I watch kip.. Some Good Ideas are drifting around. 15:57:18 huh? from above - : DUP2 DUP DUP ; shouldn't that be OVER OVER 15:57:20 ? 15:57:37 Rather than a linked list dictionary, mine's pretty much an executable AST with lots of meta-data available. 15:57:39 ah - sorry - my bad 15:57:52 DUP2 not 2DUP - misread :) 15:57:57 dup2 suggests a double-size word, so... I'd agree 15:58:05 ahhh 15:58:27 dislexia and forth don't mix 15:58:29 :D 15:59:17 proteusguy: #forth-VM: I would love to see the idea of HEADS/headers NOT embedded into the code/data - enabling tethering or different segments (and simplifying beheadings) 15:59:43 well, "dyslexia" and lysdexia are fun in C as well. 15:59:59 (and even more so when folks soooooo can NOT spell a word) 16:00:06 PoppaVic: you havent looked at eForth then? Code/data is seperate from the name dict pointing to the former 16:00:09 PoppaVic, so you want a very strong memory constraint on the word dict? 16:00:27 PoppaVic: yeah - that's exactly what i mean :) 16:01:04 * the_cuckoo curses the lack of spell checking in his weechat 16:02:11 Zarutian: I looked for eforth sources, and had an AVR in mind. I ran into hex files and such, and then I gave up. Just cuz the designer bailed when no one swamped him with sales - oh well. 16:03:12 PoppaVic: https://sites.google.com/offete23.com/eforth/ 16:03:58 --- join: dys (~dys@tmo-104-151.customers.d1-online.com) joined #forth 16:05:55 --- quit: dys (Remote host closed the connection) 16:07:29 Zarutian: thank you.. bookmarked and exploring.. Most links today are dead. 16:08:52 Zarutian: and, yep - back to charging for the sources ;-) I know for a fact #forth can do Better ;-) 16:09:15 Someone make an SVG of a #forth logo 16:09:21 #:; but well-squared 16:10:54 Zarutian: notice he used a f# tool (elsewhere) to generate the "datafile" for the targets. See? we can do better ;-) 16:11:19 I want to learn F# 16:11:31 looks cool and will be employable in the future 16:17:17 --- quit: john_cephalopoda (Ping timeout: 252 seconds) 16:19:00 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth 16:24:31 back 16:29:35 wb 16:31:40 I'm thinking about token sizes 16:32:03 because token sizes may not match cell sizes 16:32:27 but at the same time token inline arguments should be aligned 16:34:31 what do we do about token inline arguments are not aligned? split them into separate high and low components so that they don't need to be aligned? 16:35:24 Tokens are easy. Like I said. Bytes.. utf-8 like.. 16:35:45 Even C does the MAXALIGN game 16:39:12 An 8bit processor might byte align, but it's convenient to 16-byte align for more portability; 32-bit aligned is also easy. Nothing about 64bit makes me embrace its "joys".. (Once this lappy dies, i'm done with x64 linux) 16:40:36 the question I have is how do we handle, say, on 32-bit systems that require alignment a 16-bit token at an "even" address followed by a 32-bit argument 16:41:11 Hello Forthwrights 16:41:15 probably the simplest way to do it would be to JIT, and have alignment issues handled at JIT time 16:41:22 hey rdrop-exit 16:41:31 Hi tabemann 16:42:03 Mellor rdrop-exit 16:42:10 Err, hello 16:42:15 tabemann: if you access 16/access or 32/access the problem is solved. 16:42:23 autocorrect bugs :( 16:42:34 Mellor to you as well :) 16:42:35 rdrop-exit, I thought TTC would be too slow, but I've come around to support it, considering that many implementations could use a JIT to generate native code from TTC code behind the scenes, and TTC would allow more portability, safety, and would be simplify compilation words 16:42:53 Cool 16:44:01 another thing that I thought of is that we could have a portable image format, so that portable images could be generated that would run on any implementation that implements a particular version of the standard - and TTC would make doing so much simpler 16:44:37