00:00:00 --- log: started forth/19.02.17 00:04:20 --- quit: dddddd (Remote host closed the connection) 00:28:57 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 01:01:46 --- quit: spestov (Ping timeout: 255 seconds) 02:02:44 --- quit: ashirase (Ping timeout: 246 seconds) 02:07:34 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth 02:33:59 --- quit: gravicappa (Ping timeout: 258 seconds) 02:59:22 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 03:10:18 --- join: xek (~xek@apn-31-0-23-81.dynamic.gprs.plus.pl) joined #forth 03:32:13 --- quit: spestov (Ping timeout: 246 seconds) 03:46:51 proteusguy: thanks 03:47:27 proteusguy: yea the python seemed a quick way to implement a metacompiler 04:21:20 --- join: gravicappa (~gravicapp@h37-122-121-105.dyn.bashtel.ru) joined #forth 04:27:54 --- quit: gravicappa (Ping timeout: 250 seconds) 04:29:03 --- join: gravicappa (~gravicapp@h109-187-233-79.dyn.bashtel.ru) joined #forth 04:48:58 pointfree, this eda in one screen thing is nonsense 04:58:47 "eda in one screen" means what? 05:01:05 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 05:01:37 --- quit: xek (Ping timeout: 255 seconds) 05:03:17 I've wondered at times how well Python would serve as a Forth bootstrapper. 05:03:50 Not exactly sure how it would work at the low level - as far as I know Python doesn't really give you any well-defined access to specific memory locations and so on. 05:04:15 I did my C implementation using gcc's "pointer to label" extension; I don't know how to do anything like that in Python. 05:04:50 Seems like Python might work really well for cross-compiling an image to be flashed into some other device, though. 05:29:15 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 05:49:51 proteusguy, it's a thing he posted on reddit that's supposedly "eda in one screen of forth" written by cm 05:50:44 --- join: TCZ (~Johnnnyas@ip-91.246.66.12.skyware.pl) joined #forth 05:51:09 i guess the reaction we're supposed to have is awe at the sheer simplicity and elegence demonstrated by this god among men 05:51:29 what i see is meaningless garbage taken out of context 06:03:41 --- quit: spestov (Ping timeout: 268 seconds) 06:12:44 EDA? Electronics Design Automation? 06:40:15 --- quit: TCZ (Quit: Leaving) 06:46:59 i guess 06:47:26 as i said, there's basically no context 06:56:34 KipIngram: my python metacompiler takes my forth kernel written in forth + forth primitives and outputs assembler 06:57:07 so it is basically a simple forth interpreter 06:59:34 zy]x[yz: I'm thinking about using cm's approach from that FORML Proceedings article to characterize timing on the psoc5lp 07:27:43 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 07:45:53 --- join: tbemann (~tbemann@50-247-156-97-static.hfc.comcastbusiness.net) joined #forth 07:49:51 --- quit: spestov (Ping timeout: 258 seconds) 07:50:49 stupid assembler doesn't work half the time when run under the hashforth VM 07:52:12 corecode: Ok, I can see how it could do that. 08:03:08 * tbemann has no clue as to why, at the end of a file, WAIT-WRITE-FULL is writing extra data 08:05:12 --- join: nighty- (~nighty@b157153.ppp.asahi-net.or.jp) joined #forth 08:20:01 corecode, that's pretty much what I intend to do with python. right now I'm using it to test the parser requirements and strong type checking. 08:24:18 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 08:29:08 a strong-typed Forthoid language sounds interesting, but I am not sure of its Forthiness 08:53:55 --- quit: tbemann (Remote host closed the connection) 08:54:09 --- join: tabemann (~travisb@50-247-156-97-static.hfc.comcastbusiness.net) joined #forth 08:57:18 --- quit: spestov (Ping timeout: 244 seconds) 09:09:12 --- quit: proteusguy (Ping timeout: 258 seconds) 09:12:03 --- quit: zy]x[yz (Quit: leaving) 09:14:09 --- join: zy]x[yz (~corey@unaffiliated/cmtptr) joined #forth 09:15:47 zy]x[yz: It works in gforth with minimal modification https://hub.darcs.net/pointfree/forth-eda-cm-portable 09:21:26 --- join: proteusguy (~proteusgu@cm-58-10-154-147.revip7.asianet.co.th) joined #forth 09:21:26 --- mode: ChanServ set +v proteusguy 09:21:41 --- quit: nighty- (Quit: Disappears in a puff of smoke) 09:22:03 zy]x[yz: the one screen thing has all context provided 09:22:40 it's more than just the code, which looks boringly simple on the surface level 09:25:42 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 09:25:59 I fixed my stupid assembler bug 09:26:03 and it was a stupid bug 09:26:11 do tell 09:26:19 I simply had forgotten to turn on truncate mode 09:28:04 truncate mode? 09:28:10 O_TRUNC 09:28:46 O_TRUNC erases the contents of a file opened in write mode 09:29:35 :| 09:29:48 must be a hard bug to catch 09:30:01 it was as stupid and very frustrating bug 09:30:09 *a stupid 09:31:34 the key insight into the nature of the bug was that the last data in the image file written had garbage after it, and never any other parts, even though the file was written to multiple times after being opened 09:33:50 WilhelmVonWeiner, please, do explain 09:34:19 it's a perfect embodiment of the Forth philosophy 09:34:34 being cryptic and useless? 09:34:57 you can simulate any number of any kind of gate implemented in very simple building blocks 09:35:06 it doesn't even appear to be valid syntax to me. line 4 looks like a continuation of line 3 but it begins with a : 09:35:25 I think that's just how they printed old Forth. He's continuing the definition above 09:35:56 old forth was written like: 09:35:58 : foo 09:35:59 : bar 09:36:03 : baz ; 09:36:05 ? 09:36:14 what is the point of calling "not" "_" 09:36:20 save keypresses 09:36:29 silliness ;-) 09:36:31 seriously, fuck that 09:36:35 although it's not not 09:36:38 it's complement 09:36:45 besides, not is ~ or ! ;-) 09:36:47 this is not something to be praised 09:36:47 a not gate would introduce delay 09:36:58 this is garbage 09:37:07 lol whatever 09:37:46 there is no genius in being incapable of expressing your thoughts clearly. that's just autism 09:37:56 "garbage" used to design CPUs that go to fabrication 09:38:05 this is pretty clean 09:38:08 *clear 09:38:18 then explain it! 09:38:25 Which part? 09:38:34 start at wtf is it? 09:38:52 Did you read the shadow block? 09:38:57 what are its inputs, what are its outputs? how and why would one use it? 09:39:11 what shadow block? all I see are 16 lines of gibberish 09:39:22 http://www.0xff.in/bin/A_Language_for_Digital_Design.pdf 09:39:42 it's another block that explains as to what that block does? 09:41:53 so now i've read it and it sounds like this is just a timing cruncher 09:42:01 that's not "eda in one screen" 09:43:48 so i guess it is the perfect embodiment of forth if that's "write one tiny piece of software that does exactly one thing and will never be useful in any other context and declare to have solved world hunger" 09:43:57 * crc suspects that line 3 should end in a ; it's likely a typo in the forml paper 09:44:19 i don't think so. then line 4 would be a definition of ROT and that's not what it looks like 09:44:20 line 3 continues into line 4 09:44:30 I notice a 23767 which I swear should be 32767 09:44:56 yeah someone on reddit commented on that too 09:44:58 that does appear to be a typo 09:45:36 this is everything i hate about forth: the religion 09:45:39 zy]x[yz: Chuck's not trying to solve world hunger. 09:45:45 "But suppose everyone wrote their own subroutines? Isn't that a step backward; away from the millenium when our programs are machine independent, when we all write in the same language, maybe even on the same computer? Let me take a stand: I can't solve the problems of the world. With luck, I can write a good program." - CM 09:46:09 now you're quoting scripture 09:46:30 I'm quoting thr author of the program that solves the problem he had 09:46:35 the annals of St. Chuck 09:46:47 i brought it up because i was responding to a reddit post: https://www.reddit.com/r/Forth/comments/aqpklc/eda_toolchain_in_one_screen_of_forth_by_chuck/ 09:46:58 here, it's presented as 16-lines of world-hunger-solving 09:47:02 You're the one who decreed he's trying to write a program to solve the world's ills 09:47:28 no, i'm not 09:47:32 pointfree, is 09:47:52 hmm, then perhaps the : in 4 is the typo 09:48:21 17:43 < zy]x[yz> so i guess it is the perfect embodiment of forth if that's "write one tiny piece of software that does exactly one thing and will never be useful in any other context and declare to have solved world hunger" 09:48:25 17:43 < zy]x[yz> so i guess it is the perfect embodiment of forth if that's "write one tiny piece of software that does exactly one thing and will never be useful in any other context and declare to have solved world hunger" 09:51:04 in one channel I'm we have a tradition of putting notable quotes by channel members up in the topic 09:51:32 crc, zy]x[yz: `: and ( n n - n) over time and over time and max rot status and rot status and and + ;` works. 09:52:35 https://hub.darcs.net/pointfree/forth-eda-cm-portable/browse/eda.4th#10 09:52:39 I'm still amazed by the stupidity of my VM assembler bug 09:57:36 tabemann: why? something unusual you were doing with that assembler? 09:58:01 I forgot to open() a file I was writing an image to with O_TRUNC set 09:59:03 bugs happen 09:59:15 and everybody dies 09:59:22 which manifested itself in all kinds of seemingly random failures with images assembled by the self-hosting VM assembler, which were hard to track down the cause of even when I realized it was that the very ends of the image files were getting corrupted 09:59:40 --- quit: spestov (Ping timeout: 246 seconds) 09:59:59 tabemann: Hah, a few days ago I spent half an hour debugging why my forth program wouldn't write to a file until I realized I opened it r/o. 10:01:52 bbl 10:06:19 --- quit: tabemann (Ping timeout: 246 seconds) 10:13:37 pointfree: thank you for sharing the corrected copy; I did a quick port to retro: http://forth.works/5b7c09490f8670475ef5b8382eeac3da 10:15:25 +1 10:46:07 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 10:52:11 I'm about to add a simple file system to my Forth. 10:52:27 Very simple, but I think it will offer broad usefulness. 10:52:59 Basically the normal block system will still "be there" - I'm going to choose a 2-byte "magic number," and any block that doesn't start off with that will just be a plain old school block, for me to manage as I see fit. 10:53:16 But if the magic number is there, then the next few bytes will specify some file system info. 10:53:25 I'm going to support several different ways of structuring files. 10:53:33 One way will just be a doubly linked list of blocks. 10:53:51 Another way will be as a "slab" - contiguous blocks of whatever size I want. 10:54:02 yet another way will be to have a block of pointers that designate the blocks in the file. 10:54:06 And a coupleof others. 10:54:20 The two bytes following the magic number will designate that style. 10:54:53 The / directory "file" will start at a pre-determined location, so I can always find it. 10:55:19 And it will be possible to put name/value pairs in these blocks, which I can use to implement a /dir/subdir/subdir/filename type thing. 10:55:35 If I type in something like that, it will first search the dictionary for it as usual. 10:55:38 If it's found, it's a word. 10:55:49 If it's not found, then it will try (and fail) to convert it to a number. 10:56:15 Then it will see if it can successfully be navigated through the file system, and if so I will get the block number of the first block of the designated file item. 10:56:52 the concept of "current directory" can exist - it will just be a variable designating the first block of the current directory info. 10:57:20 So just a plain unpunctuated word like name could select a file in the current directory. 10:57:40 provided name isn't in the dictionary. 10:57:49 To avoid such a conflict i could say ./name 10:57:56 And that would probably be good practice. 10:58:22 /source/math/fft load and other such things would work. 10:59:09 To create stuff: 10:59:26 "/path/name" mkdir 10:59:38 or "path/name" mkfile 10:59:54 Though that last one will need an extra argument to specify what kind of file (linked, slabbed, etc.) 11:00:07 And a slab would need a size specifier as well. 11:00:14 I might do that with different words: 11:00:21 "/path/name" 20 GB slab 11:00:51 : GB 30 << ; 11:02:07 Given I've got two bytes of "filetype" to play with, I think I'd be able to do any aspect of typical Linux file systems I wanted. Like mount a device at some particular point in the file system, etc. 11:14:45 KipIngram: Unix uses a very limited number of syscalls for fs interaction, like open() close() read() write() and creat() 11:15:04 Yes. 11:15:15 Exposing forth-based calls similar to those and then writing mkdir etc. on top of those would make sense. 11:17:10 That's basically what I'll do, but I wno't be using the actual Linus file system. I'm writing this to eventually be a stand-alone operating system. 11:17:25 I'll build all that stuff myself, on top of those basic calls you just mentioned. 11:17:45 Then when I port it to bare metal later, I'll only have to write the code to do the functions of those few calls, and everything else will be in place. 11:18:11 For running it under Linux or MacOS I'll have a "blocks.dat" file, that I regard as an array of blocks. 11:18:16 --- quit: gravicappa (Ping timeout: 250 seconds) 11:19:11 I did the same sort of thing with memory management - I allocate a huge block of RAM to the program at startup, then do my own allocation out of that. 11:25:03 KipIngram: If you want to do something standalone, it might make sense to actually implement an existing filesystem. 11:25:17 Makes it way easier to transfer files back and forth if needed. 11:25:26 ext2 and fat are relatively simple, 11:26:23 Yeah, I did think about that. I'll at least look into it. 11:48:13 write a FUSE filesystem that exposes straight blocks 11:49:34 --- quit: spestov (Ping timeout: 246 seconds) 12:04:51 --- join: _spt_ (~Jupiter-R@host-92-24-244-232.ppp.as43234.net) joined #forth 12:04:51 --- quit: _spt_ (Changing host) 12:04:51 --- join: _spt_ (~Jupiter-R@unaffiliated/-spt-/x-5624824) joined #forth 12:04:58 --- join: xek (~xek@user-94-254-224-236.play-internet.pl) joined #forth 12:06:06 --- join: _spt1_ (~Jupiter-R@host-92-24-244-232.ppp.as43234.net) joined #forth 12:06:21 --- join: _spt1__ (~Jupiter-R@host-92-24-244-232.ppp.as43234.net) joined #forth 12:34:17 I'll likely be writing a few command line tools to access/update the block store and not bother with FUSE. 12:38:11 * crc needs to decide on how many blocks to include in the blockfile 12:40:29 on raw hardware, it'd just be the size of the partition (or other storage medium) divided by 1024, subtracting the needed space for the retro image(s) + vm. But I'm still undecided on the size for the hosted system. 12:43:00 Foolsystem 13:32:22 --- quit: xek (Ping timeout: 255 seconds) 13:45:02 --- quit: _spt1_ (Remote host closed the connection) 13:45:16 --- quit: _spt_ (Remote host closed the connection) 13:45:22 --- quit: _spt1__ (Remote host closed the connection) 13:46:07 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 13:47:13 --- quit: reepca (Remote host closed the connection) 14:04:56 --- join: reepca (~user@208.89.170.37) joined #forth 14:09:18 --- join: TCZ (~Johnnnyas@ip-91.246.66.12.skyware.pl) joined #forth 14:09:49 --- part: TCZ left #forth 14:20:00 --- quit: spestov (Ping timeout: 245 seconds) 14:50:49 --- quit: Zarutian (Read error: Connection reset by peer) 14:51:25 --- join: Zarutian (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth 14:59:00 --- join: dave0 (~dave0@193.060.dsl.syd.iprimus.net.au) joined #forth 14:59:15 hi 15:00:46 hello o/ 15:00:51 morning fortnighter 15:05:09 hey presiden 15:08:25 guys, i'd really appreciate any opinion (be it positive or negative) to https://gitlab.com/lilo_booter/rpany/blob/master/README.md#vocabularies - i would suggest you ignore implementation details and just focus on the language (i'll accept criticism of both but c++ sucks isn't a discussion i'll entertain :)) 15:12:16 whew.. You simplified it - since C++ is a micro black-hole and the conversation need go no further ;-) 15:15:55 the_cuckoo: cool you have pick and roll! 15:20:28 :) 15:22:00 dave0: yeah - the idea is that i can put anything on the stack (numbers, strings, video graphs) and umm, do stuff i guess 15:23:45 if you scroll up in the link, you'll find an example tool i wrote for work (the underlying library i'll happily release, but it'd be nice to have some interest and help with testing in the exchange :)) 15:24:00 i'm a newbie so i don't know what not to do... i just go ahead and use pick and roll when it looks "obvious" 15:24:37 :) - makes sense to me :) 15:30:36 this was the link to the other project anyway https://gitlab.com/lilo_booter/rpany/blob/master/README.md#related-projects and i'm working on extending that with a little raspberry pi toy soon 16:03:15 --- quit: proteus-guy (Ping timeout: 250 seconds) 16:06:11 hhh 16:10:35 KipIngram: Sam Falvo gave an svfig talk about an old IBM (?) filesystem so simple it can be easily opened and edited with a hex editor or block editor. I forget the name of the fs. 16:10:35 Hm how about a dictionary/ linked-list based fs format using only printable characters. 16:16:27 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 16:17:34 Well, I have some ideas about what I plan to do, but simplicity is definitely the goal. 16:19:06 Again, using something existing has the advantage that you can just edit it with existing programs. 16:33:47 --- join: rdrop-exit (~markwilli@112.201.168.172) joined #forth 16:41:18 Good morning Forthwrights 16:42:33 --- join: tabemann (~travisb@2600:1700:7990:24e0:a106:f1e:e4eb:7e2d) joined #forth 16:42:44 --- quit: john_cephalopoda (Ping timeout: 252 seconds) 16:44:25 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth 16:45:21 Was it IBM's OS/400? 16:45:22 https://en.wikipedia.org/wiki/Single-level_store 16:48:48 http://www.varietysoftworks.com/jbaldwin/Education/single-level_store.html 16:49:10 --- quit: spestov (Ping timeout: 245 seconds) 16:49:40 Hi rdrop-exit 16:51:28 Hi KipIngram 16:59:04 hey guys 17:00:01 Hi tabemann 17:04:33 Evening tabemann. 17:37:24 back 17:37:44 did I mention to you how I had the stupidest of bugs in hashforth's VM assembler 17:37:52 @rdrop-exit 17:38:24 I read it in the log just before signing on 17:39:30 it was good, though, that I didn't zorch support for the attoforth VM assembler 17:39:48 We've all had our share of head-slap bugs :) 17:42:07 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 17:42:27 one issue that I'd had to deal with was that when running the VM assembler with hashforth, it overwrites the current image if the current image is the one assembled by the hashforth VM assembler 17:42:48 so if you produce a bad image... you can't use hashforth anymore, at least without doing git checkout 17:43:33 furthermore, the only way to produce new images that work when the hashforth VM assembler is broken is to use the attoforth VM assembler 17:44:58 so yeah 17:45:20 it's good that I didn't remove the possibility of building with attoforth 17:47:07 I'm not sure I understood all that 17:51:03 it's that when the hashforth VM assembler is broken for some reason, e.g. it produces bad images that crash, it is necessary to use the attoforth VM assembler to produce new images that work 17:52:05 Backup before you run it 17:52:13 otoh, you could fix the hash (more ketchup and onions), and then it would do what it was paid for. 17:52:53 rdrop-exit, that I did was resorting to git checkout to restore the image after each time it was broken 17:53:02 which is essentially the same thing 17:53:51 rdrop-exit, yeah the AS/400 had that single global address space which was nice from a programming perspective. I think that's the direction of the future with persistence just meaning "reachability". OO Databases in the late 80s and early 90s looked like they might go that way for a while until they created this horrific standard which immediately made them obsolete. 17:55:31 Right, OODBs went nuts and lost the simplicity at the heart of the concept 17:57:37 --- join: nighty- (~nighty@b157153.ppp.asahi-net.or.jp) joined #forth 17:58:33 the moment the standard REQUIRED inheriting from a persistent object class (generally PObject) I knew the jig was up. Sadly I had a nice working model in C++ that avoided this that would have scaled but I wasn't up to bringing it to market being a single developer in rural Arkansas at the time and no clue about sales/marketing. 18:00:07 --- quit: spestov (Ping timeout: 255 seconds) 18:00:19 tabemann: Have your "save" command create a backup before overwriting the original file 18:00:58 --- quit: nighty- (Remote host closed the connection) 18:01:17 --- join: nighty- (~nighty@b157153.ppp.asahi-net.or.jp) joined #forth 18:01:21 You could also have a "snapshot" command 18:01:51 copy on write semantics are quite powerful. but you have to then address a virtual position and make the system not care about the physical position. 18:02:10 rdrop-exit, that's a great idea, but it wouldn't've helped with my bug because the problem was O_TRUNC wasn't set 18:02:42 of course I should add that now 18:03:09 naturally just as things get interesting I have to run.... ttyl. 18:03:17 see ya 18:03:31 Ciao :) 18:04:13 --- quit: proteusguy (Remote host closed the connection) 18:07:39 This is what I do on my POSIX VM 18:07:55 2 save Overwrite the NFF disk image (nff.bin). 18:07:56 3 Done in 3 steps to safeguard the image from corruption 18:07:56 4 if the update fails to complete: 18:07:56 5 1) Write the new image to nff.bin.tmp.XXXXXX 18:07:56 6 2) Rename the old image (nff.bin) as nff.bin.bak.XXXXXX 18:07:58 7 3) Rename the temporary file as the current image 18:08:00 8 (nff.bin) 18:08:03 9 18:10:22 The XXXXXX are template placeholders 18:17:25 ... for mkstemp(3) 18:27:56 back 18:28:03 okay, I implemented backing up 18:29:24 Take a look at the log, I just posted something for you about 20 minutes ago 18:29:43 yeah, I saw 18:29:49 Cool 18:31:06 I don't back up when building a new image, but I do save the new image as `ngaImage2` (instead of the default `ngaImage`) when metacompiling and have a clean copy of the image embedded in the VM binary (on all but the most minimal builds) 18:31:54 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 18:32:18 I implemented a simple backup - it reads the file and writes it to the backup location - if writing fails, building fails - only after that does it write out the new image to the orignal location 18:35:46 Whatever works for you, as long as it's resilient 18:37:42 I could implement it so that it has any number of backups, and adds a new backup file each time it is built... 18:37:57 (currently it only supports one backup file) 18:38:26 That's what the save I posted does 19:01:10 Notice that the nff.bin.bak.XXXXXX file is not deleted by the SAVE operation 19:02:02 It sticks around until I choose to manually delete it 19:04:44 --- quit: spestov (Ping timeout: 246 seconds) 19:15:53 --- quit: dddddd (Remote host closed the connection) 19:16:25 Gotta go, see you all later 19:16:36 --- quit: rdrop-exit (Quit: Lost terminal) 19:36:02 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 19:42:36 --- join: gravicappa (~gravicapp@h109-187-233-79.dyn.bashtel.ru) joined #forth 20:45:00 --- quit: spestov (Ping timeout: 245 seconds) 21:12:12 --- join: proteusguy (~proteusgu@mx-ll-180.183.132-171.dynamic.3bb.co.th) joined #forth 21:12:12 --- mode: ChanServ set +v proteusguy 21:15:04 --- quit: proteusguy (Excess Flood) 21:15:33 --- join: proteusguy (~proteusgu@mx-ll-180.183.132-171.dynamic.3bb.co.th) joined #forth 21:15:33 --- mode: ChanServ set +v proteusguy 21:18:12 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 21:51:25 --- quit: spestov (Ping timeout: 255 seconds) 22:52:02 well, yay.. Barring flow-control, all the tokencodes work like a champ - compacted, no less. 22:52:40 --- join: xek (~xek@user-94-254-224-236.play-internet.pl) joined #forth 22:54:21 --- quit: proteusguy (Read error: Connection reset by peer) 23:10:43 --- join: proteusguy (~proteusgu@mx-ll-183.89.211-246.dynamic.3bb.co.th) joined #forth 23:10:43 --- mode: ChanServ set +v proteusguy 23:26:26 so - no comments on the rpany language? (snide comments about c++ ignored) - hmm - shame - i think the use of the stack and the word approach which FORTH provides is much more interesting than any implementation (though i do find that fascinating too - it's really nice that you guys are digging into so deep in your implementations :)) 23:27:53 as an example - my video processing lib is all about building graphs, stack based parsing is the most natural way to do it 23:31:15 clearly, i don't need an underlying language to parse/deserialise them, but it really does open a huge amount of opportunities - especially from a testing/prototyping point of view - but also from a higher level of control over playout and (transcoding) job scheduling 23:33:38 --- quit: xek (Ping timeout: 250 seconds) 23:33:53 i totally understand that there's no specific interest in a c++ library and that to me is perfectly fine - still ... i think there is an opportunity to discuss how you interact with a stack and as written, there is clearly a lot of overlap 23:38:30 just as a general thing, this isn't a new thing for me - i was one of the original developers of the MLT project (a c based media library) which was designed using a stack mechanism too - https://www.mltframework.org/ 23:40:56 i used the stack approach differently there - it was largely internal to the graph - frames were collected as a stack of evaluating callbacks (pointers to functions) and these are evaluated to render a frame 23:42:11 it also comes with a command line tool called melt which has a sort of stack based evaluation for the graph (but no additional vocabs) 23:43:37 --- quit: dys (Ping timeout: 250 seconds) 23:48:02 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 23:50:50 the above isn't really a complaint or a criticism :) - just an observation :) - each of us have our own domains of interest - FORTH is a great language but for me, the concepts it employs work well at a higher level too 23:56:44 the_cuckoo, I think I may have missed a link or something about what you wanted comments on? 23:58:41 hey proteusguy :) - it was specifically this link - https://gitlab.com/lilo_booter/rpany?nav_source=navbar#vocabularies - i'm trying to write it as a general introduction for complete noobs - dunno if i'm on the right lines or not, hence, any feedback is welcome :) 23:59:39 oops - this is a better url - https://gitlab.com/lilo_booter/rpany/blob/master/README.md#vocabularies - has more width 23:59:59 --- log: ended forth/19.02.17