00:00:00 --- log: started forth/19.02.14
00:00:15 <proteusguy> KipIngram, congrats! What was it running under before?
00:00:35 <proteusguy> tabemann, hashforth is on x86?
00:01:08 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth
00:12:26 <yunfan_> proteusguy: what do you mean ?
00:13:04 <yunfan_> proteusguy: the 1991 framework was run on gforth, and gforth-fast, hasnt change the benchmark score
00:15:55 <proteusguy> I mean the difference in performance between the node.js server and the 1991.
00:20:27 --- quit: dys (Ping timeout: 268 seconds)
00:21:13 <yunfan_> proteusguy: well, i use `ab -n 100000 -c100 ` to test, and nodejs got about ~4300 req/second, while 1991's score is ~9800 req/s
00:21:54 <proteusguy> nice! glad to see javascript gets beat by forth!
00:22:00 <yunfan_> proteusguy: and my machine's hardware is i7-6700 8G ram, OS is ubuntu 1810 64bit
00:22:27 <proteusguy> server is doing any operations other than returning some static text?
00:22:36 <yunfan_> proteusguy: but i dislike gforth, which is too big to me
00:22:45 <yunfan_> proteusguy: yes just return hello world
00:23:02 <proteusguy> yeah gforth isn't known to be particularly speedy which is even more promising.
00:23:12 <proteusguy> (in terms of the potential for other forths)
00:23:40 <yunfan_> well from a 2010 benchmark reporting, gforth is speedy
00:23:46 <yunfan_> i just dislike its size
00:24:08 <proteusguy> gforth is ITC?
00:24:14 <yunfan_> who knews what happened during the past decade
00:24:23 <yunfan_> both
00:24:31 <yunfan_> it has two version, isnt it?
00:25:12 <proteusguy> both? You mean ITC & DTC? I don't recall now...
00:31:20 <yunfan_> yes, at least in ubuntu, when you install gforth package, it gave you both version
00:32:15 <yunfan_> so is the author of 1991 in this channel?
00:34:10 --- quit: spestov (Ping timeout: 245 seconds)
00:40:49 --- join: xek (~xek@apn-31-0-23-81.dynamic.gprs.plus.pl) joined #forth
00:59:44 --- join: reepca (~user@208.89.170.37) joined #forth
01:20:04 <WilhelmVonWeiner> rdrop-exit: Did you find out anything more on CADForth?
01:20:12 <WilhelmVonWeiner> yunfan_: unlikely
02:04:26 --- quit: ashirase (Ping timeout: 246 seconds)
02:10:29 --- join: ashirase_ (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth
02:31:21 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth
03:04:09 --- quit: spestov (Ping timeout: 240 seconds)
03:35:29 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
04:13:29 --- join: dave0 (~dave0@193.060.dsl.syd.iprimus.net.au) joined #forth
05:01:24 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth
05:06:30 <KipIngram> proteusguy: Ran under MacOS before.
05:06:56 <KipIngram> It took a little while, but ultimate all that was required to port it was 1) change the system calls, 2) change the ioctls used for the termios.
05:07:11 <KipIngram> Once those things were right, it just ran, no further changes.
05:07:57 <KipIngram> it took me several hours because even thought these are both 64-bit systems, apparently the termios c_iflags, c_oflags etc. fields are 4 bytes wide in linux instead of MacOS's 8 bytes wide.
05:08:08 <KipIngram> so I spent most of the evening updating the wrong locations.
05:12:29 --- quit: Zarutian (Ping timeout: 272 seconds)
05:15:13 <KipIngram> Slooppiness on my part, not to carefually check at the outset.
05:15:19 <KipIngram> I got what we usaully get for assuming.
05:16:06 --- quit: dave0 (Quit: dave's not here)
05:17:28 --- join: Zarutian (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth
05:21:10 <KipIngram> Next thing I wnat to do is get things fixed up with my Dropbox so that the bulk of the source is in Dropbox and shared, with a small include file specifying the syscalls and ioctls for each system.
05:21:29 <KipIngram> That way I can work furthe ron one file and have the changes work in both places, rather that fret over keeping two source files coherent.
05:35:11 --- quit: spestov (Ping timeout: 250 seconds)
05:35:57 --- join: jemarch (user@gnu/pdf/jemarch) joined #forth
05:36:25 <jemarch> Hello!
05:37:01 <WilhelmVonWeiner> jemarch: good afternoon
05:37:28 <jemarch> I'm writing an application that includes a stack-based virtual machine, which has more than three stacks (data, return and exceptions) and in the process I am getting very fond of Forth :)
05:37:39 <WilhelmVonWeiner> Forth is awesome.
05:38:46 <jemarch> I meant more than two stacks :)
05:39:07 <jemarch> Anyhow.  I can't make my mind about consuming vs. non-consuming instructions
05:39:35 <WilhelmVonWeiner> example?
05:39:52 <KipIngram> jenarch: Welcome to Forth - it's a wondrous thing.
05:40:05 <jemarch> (a b-- a+b) vs. (a b - a b a+b)
05:40:12 <WilhelmVonWeiner> the latter
05:40:19 <jemarch> When I designed my virtual machine, I went with consuming instructions, I think instinctively.  Then I changed it
05:40:21 <KipIngram> Consuming.
05:40:42 <WilhelmVonWeiner> if you don't want the arguments again, now you have to faff around
05:41:05 <jemarch> yes, my code generator now generates lots of nips :/
05:42:01 <KipIngram> Well, I'd definitely go the other way, but if there's one thing Forth is all about it's experimentation and "doing it your way."
05:42:12 <WilhelmVonWeiner> seems to add complexity, imo.
05:42:34 <jemarch> Forth's arithmetic instructions are consuming, right
05:42:36 <KipIngram> You could have your code generator take stats on how often you actually re-used parameters, vs. how often you use them once and then nip them.
05:42:42 <KipIngram> Then you'd have hard data.
05:42:47 <jemarch> oh, thats very interesting
05:42:48 <WilhelmVonWeiner> jemarch: yes
05:43:05 <KipIngram> Forth is consuming in virtually every instance.
05:43:16 <jemarch> I like non-consuming branches though
05:43:45 <KipIngram> I have a very limited set of words, that I name by prefixing the standard word with a period, that refrain from consuming a single argument (the one closest to the top of the stack).
05:44:00 <KipIngram> I use those words when I find them helpful, but they're distinct words from the usual ones.
05:44:15 <jemarch> Problem is, every time I change my mind about consuming vs. non-consuming I have to rewrite a lot of code in my compiler and the run-time hand-written assembly.  So I really need to make my mind and settle on something :)
05:44:20 <KipIngram> One example is .= 
05:44:32 <KipIngram> Instead of (a b --> flag) it does (a b -- b flag).
05:44:44 <KipIngram> In some instances I find that saves code.
05:44:57 <KipIngram> Oh, I'm sorry - it keeps the DEEPEST one.
05:45:03 <KipIngram> So (a b -- a flag).
05:45:08 <crc> a little more about CADForth (re: IBM CAD/PLUS): it was a superset of FORTH-83 (see https://patents.justia.com/patent/5493641 which mentions this and has source for a couple of words in Appendix A)
05:45:10 <jemarch> yes, that's a common situation in my experience
05:45:18 <KipIngram> This would be used if you have a data item that you want to compare to a succession of other values.
05:45:27 <WilhelmVonWeiner> crc: nice find!
05:51:49 <KipIngram> jenarch: That . that leads off the names of those words isn't "system processed" in any way; the interpreter/copiler has no "knowledge" of doing this.  They're just different words with different names that are coded to do the different thing.
05:51:59 <jemarch> yeah
05:52:21 <jemarch> well, I suppose I could add similar instructions to my VM
05:52:22 <KipIngram> I did find that in a few cases the "dot word" that left one argument on the stack had a more efficient primitive than the normal word.
05:53:10 <KipIngram> But I do want to stress that this is only useful in some cases; adding those words was sort of a luxury.  Most often it just saves me some DUPs.
05:53:39 <jemarch> Yes.  You either end with lots of dups, or with lots of nips :)
05:54:36 <KipIngram> I think the "lots of nips" would wind up being more, but I admit I've never formally tested it - that's just a feeling.
05:54:50 <KipIngram> .. is an interesting word.
05:54:57 <KipIngram> It prints the top of the stack without consuming it.
05:55:00 <KipIngram> Great for debugging.
05:55:12 <KipIngram> Just slip it in anywhere, and it has no effect on the logic.
05:55:43 <jemarch> Ok, thanks for the feedback.  I think I will go back to consuming instructions, mainly for the benefit of the compiler
05:55:48 <KipIngram> I'm still in the phase of my system where I have a pretty fully working system, but I haven't shifted to writing a lot of Forth source yet.
05:55:55 <KipIngram> I still work at the assembly language level.
05:56:25 <KipIngram> So "adding .." means adding " ddot-o," in my source.
05:57:14 <KipIngram> The -o was forced on me by MacOS, which insists on everything being completely relocatable.  My compiled words are lists of *offsets* from the base address of the system, rather than lists of addresses.
05:57:37 <KipIngram> I keep that offset in a register, though, so it's minimal performance impact.
05:59:38 <crc> https://books.google.com/books?id=4RN8nH8oZ2QC&pg=PA279&lpg=PA283#v=onepage&q&f=false has a review of the CAD/PLUS software, but no details on CADForth
06:10:23 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth
06:14:55 --- quit: spestov (Ping timeout: 246 seconds)
06:47:01 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth
06:56:57 --- join: mark4 (~mark4@148.80.255.161) joined #forth
07:19:47 --- quit: spestov (Ping timeout: 246 seconds)
07:36:07 --- quit: tabemann (Ping timeout: 250 seconds)
07:38:30 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth
07:43:10 --- quit: spestov (Ping timeout: 258 seconds)
07:46:28 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth
08:20:22 <Guest69125> consider the following code:
08:20:24 <Guest69125> : test-t   1 throw ;   : test   3 ['] test-t catch . . cr ;
08:20:54 <Guest69125> on Gforth and VFX, `test` prints `1 3`
08:21:11 <Guest69125> on latest pForth git, `test` prints `1 1`
08:21:27 <Guest69125> am I correct in assuming that this is a bug in pForth?
08:29:15 <zy]x[yz> seems like it
08:30:08 <zy]x[yz> if you put a third . in there, does it print the 3?
08:30:22 <zy]x[yz> in other words, is the stack improperly restored or was the 3 clobbered
08:31:44 <PoppaVic> I'd say "what do the pforth docs say?"
08:37:01 <Guest69125> zy]x[yz: clobbered
08:37:27 <zy]x[yz> regardless of what the docs say, there's no way that's what you would ever want
08:37:44 <zy]x[yz> unless catch takes two values for some reason or something ??
08:41:31 <Guest69125> PoppaVic: the docs claim ANS-compliant EXCEPTION and that's more or less it
08:41:42 <PoppaVic> ouch
08:42:04 <Guest69125> ... or maybe I can't read, that's also a possibility
08:43:33 <Guest69125> weirdly enough, I don't actually find any language in the ANS description of THROW and CATCH (https://www.complang.tuwien.ac.at/forth/dpans-html/dpans9.htm#9.6.1.2275) saying that stack items untouched by the CATCH would stay untouched by the THROW
08:44:19 <zy]x[yz> that would be insane, though.  if that were the case, then throw should just panic
08:44:24 <Guest69125> yep
08:44:48 <Guest69125> filed that as https://github.com/philburk/pforth/issues/57, thanks
08:47:44 <Guest69125> though with the last commit in May '18, is that version actually maintained?
08:49:48 <PoppaVic> I doubt he's done diddly with pforth
08:50:00 --- quit: spestov (Ping timeout: 245 seconds)
08:50:26 <PoppaVic> well, edit: he may well be using a repaired copy for his own work - and not even paying any attention to the git.
08:54:01 --- quit: pierpal (Quit: Poof)
08:54:19 --- join: pierpal (~pierpal@host132-240-dynamic.52-79-r.retail.telecomitalia.it) joined #forth
08:56:41 <crc> Guest69125: the developer seems to still be supporting it, based on activity in the google group: https://groups.google.com/forum/#!forum/pforthdev
08:57:27 <Guest69125> I see, thanks!
09:31:32 <crc> tabemann: some notes on the latest hashforth under openbsd: http://forth.works/29878c26ad26a3f4fc15f718560d9982
10:16:53 --- quit: Keshl (Ping timeout: 246 seconds)
10:46:13 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth
10:52:01 --- quit: nighty- (Quit: Disappears in a puff of smoke)
11:07:29 --- quit: gravicappa (Ping timeout: 258 seconds)
11:09:04 --- join: Keshl (~Purple@207.44.70.214.res-cmts.gld.ptd.net) joined #forth
11:15:09 --- quit: spestov (Ping timeout: 258 seconds)
11:18:32 --- quit: Keshl (Read error: Connection reset by peer)
11:18:44 --- join: Keshl (~Purple@207.44.70.214) joined #forth
11:32:30 --- join: mtsd (~mtsd@94-137-100-130.customers.ownit.se) joined #forth
11:44:59 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth
11:46:28 --- join: dys (~dys@tmo-102-218.customers.d1-online.com) joined #forth
11:52:34 <john_cephalopoda> Hmmm, it is pretty annoying that the word . prints the number followed by a space.
11:54:13 <john_cephalopoda> If I use gforth's time&date word and try to print the date like 2019-02-14, this is pretty much impossible due to the space being displayed right after every number.
12:01:41 <mark4> you can define : . . bs emit ;
12:01:49 <mark4> colon dot dot bs emit
12:01:53 <mark4> semi
12:02:37 <mark4> you can also redefine :  .  <# # #s #> type ;
12:02:38 <mark4> no space
12:02:59 <mark4> there is no prohibition against redefinitions
12:03:05 <mark4> : foo ." foo" ;
12:03:13 <mark4> : foo foo ." bar " ;p
12:03:15 <mark4> foo foobar
12:07:42 <john_cephalopoda> mark4: bs is "9 emit", isn't it?
12:08:01 <mark4> no thats tab
12:08:03 <mark4> bs i s8 emit
12:08:11 <mark4> : bs 8 emit ;
12:08:24 <john_cephalopoda> Right.
12:08:31 <mark4> the disadvantage to this would be 1234_bs  where _ is the space emitted and then delted after
12:08:34 <john_cephalopoda> 8 emit works only as long as you output to a terminal.
12:08:42 <mark4> look at the definition for .
12:08:59 <mark4> : . s>d <# # #s #> type space ;
12:09:02 <mark4> just define it as
12:09:15 <john_cephalopoda> Ok, thx.
12:09:18 <mark4> : .l s>d <# #s #> type ;
12:09:27 <mark4> there was no need for the extra # in there
12:09:40 <mark4> : . s>d <# #s #> type ;
12:09:59 <mark4> do you know how the pictured number output words work?
12:12:13 <john_cephalopoda> Never used them before but there are dozens in the standard.
12:14:34 <mark4> when you compile a number it is compiled into a buffer from right to left
12:15:08 <mark4> you divide the current number by base and the remainder is the next digit so you covert it to an ascii char and add it to the string
12:15:25 <mark4> you can also insert ANY char at any time during this procedure by using hold
12:15:49 <mark4> the word <# initializes conversion and takes a double number as a parameter
12:16:08 <mark4> # converts ONE digit by dividing D1 by base and outputing the char of the remainder
12:16:24 <mark4> #s is a loop that keeps doing # until d1 becomes zero
12:16:46 <mark4> <# # # ':' hold # # ':' hold # # #> type
12:16:57 <mark4> the #> returns the address of the compiled string
12:17:20 <mark4> the above would compile a string that looks like nn:nn:nn  where nn are digits in the current base
12:18:10 <mark4> the difference between . and u. is that dot does a s>d (single to double) and u. just puts a 0 on the stack.
12:18:32 <mark4> : . ( n1 --- ) s>d ...... type space ;
12:18:46 <mark4> : u. ( n1 --- ) 0 ..... type space ;
12:18:55 --- quit: spestov (Ping timeout: 246 seconds)
12:19:18 <mark4> and that concludes the lesson for the day. 
12:19:24 <mark4> that will be one beer plzkthxbai
12:19:27 <mark4> oh wait i dont drink beer
12:26:37 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth
12:49:08 <bluekelp> seeing this channel active makes me very happy
13:27:40 --- quit: xek (Ping timeout: 244 seconds)
13:31:12 --- quit: mtsd (Quit: WeeChat 1.6)
13:52:43 <crc>  yunfan_: as expected, my http server is *much* slower that 1991.fs: http://forth.works/c942f363142f4e909f5a460502404442
13:57:58 --- quit: dddddd (Ping timeout: 246 seconds)
14:10:09 --- join: dave0 (~dave0@193.060.dsl.syd.iprimus.net.au) joined #forth
14:10:21 <dave0> hi
14:10:51 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
14:14:26 <mark4> sometimes there IS life on ear.. i mean #forth
14:20:22 <Kumool> mark4: this has become one of the most active channels I'm in
14:20:46 <Kumool> and I'm on #news on Rizon which is full of spam
14:22:24 <mark4> lol
14:22:43 <mark4> going home, brb
14:27:05 --- quit: mark4 (Ping timeout: 245 seconds)
14:41:43 <bluekelp> yes. recently things have been quite lively here. it's great. 
14:43:30 <john_cephalopoda> I bought a 2TB HDD.
14:43:34 <john_cephalopoda> For no reason.
14:43:51 <john_cephalopoda> Now I'll have to write some Forth in order to fill it with procedurally generated stuff or something.
14:47:41 --- quit: jedb (Remote host closed the connection)
14:48:13 --- join: jedb (~jedb@199.66.90.113) joined #forth
15:12:18 <crc> Boot a native forth and enjoy your 2 billion blocks :)
15:19:45 <bluekelp> does anybody know arm well enough to discuss the differences between the BLX instruction and an explicit jump to an odd address? 
15:20:13 <bluekelp> I read that jumping to an odd address is how you switch to thumb mode, so i did that. i suspect this might be the cause of a bug i was never able to resolve.
15:33:05 <PoppaVic> bluekelp: afaik, (and I have 3 arms I have yet to PROGRAM), BLX is the to/from ARM/thumb[2]
15:34:21 <PoppaVic> I picked up some atmel samd21s (Adafruit feather m0 and itsy-bitsy m0) which are M0+' as well as some samd51
15:34:32 <PoppaVic> s (adafruit itsty-bitsy M4)
15:35:46 <PoppaVic> In addition, I would love if someone knew more about 'em, because the atmel/microchip datasheet makes me homicidal.. (and I fear I will have to bend over, bare it and suffer Arduino to get anything done with them)
15:47:34 <bluekelp> I'm not a big datasheet reader but I do remember liking the atmel chips. Admittedly they were my first exposure to embedded systems (that worked), so perhaps just rosy glasses.
15:47:51 <bluekelp> maybe after the microchip buyout things changed
15:48:20 <PoppaVic> well, the 328p is fine; the 1284p is even decent; the 32u4 - but the ARM chips get really, really strange
15:48:48 <bluekelp> I was looking at some ARM code recently and saw BLX for the first time. previous tutorials hadn't mentioned it - but they were non-thumb arm tutorials so maybe they were old enough to predate it
15:50:00 <PoppaVic> http://www.keil.com/support/man/docs/armasm/armasm_dom1361289866046.htm
15:50:03 <PoppaVic> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0489c/Cihfddaf.html
15:50:41 <PoppaVic> https://developer.arm.com/docs/dui0802/a/a32-and-t32-instructions/b-bl-bx-blx-and-bxj
15:51:05 <PoppaVic> "Branch with link, and exchange instruction set"
16:15:41 <Zarutian> so basically an subroutine call into thumb code?
16:19:50 <PoppaVic> i suppose
16:20:54 <Zarutian> never understood the point of thumb code and spending silicon on it.
16:24:15 <Croran> Aren't the Jazelle and Thumb codes deprecated now?
16:24:27 <PoppaVic> former
16:45:47 --- quit: john_cephalopoda (Ping timeout: 252 seconds)
16:47:48 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth
17:01:21 <KipIngram> Ok, got my common Forth source into my Dropbox, with project directories on my Mac and my Ubuntu box linking to that source file.
17:01:40 <john_cephalopoda> KipIngram: Strange constellation
17:01:44 <KipIngram> In each one of those there's a small include file that captures all the syscall / iocotl differences, and also separate build scripts that handle those differences.
17:02:01 <KipIngram> Now the one common source file compiles and works on either machine.
17:02:14 <KipIngram> So I won't have to worry about developing stuff and then "moving it to the other machine."
17:04:35 --- join: rdrop-exit (~markwilli@112.201.168.172) joined #forth
17:06:04 <PoppaVic> KipIngram: bububut... GIT ??
17:06:11 * PoppaVic chuckles
17:09:54 <KipIngram> Yes, I've committed the changes to my git, and I have that repo in Dropbox too.
17:10:05 <KipIngram> And also have emailed the source to myself on gmail, so it's secure.
17:10:30 <PoppaVic> bububut... GIT is posta solve it all
17:11:08 <KipIngram> Well, I could put the common source in a git repo that I pull from in both places, and have the inc files "not in the repo."
17:11:14 <KipIngram> That would work.
17:11:24 <KipIngram> This is just smoother as far as I'm concerned - I don't have to think about it at all.
17:11:44 <PoppaVic> I like not thinking about it
17:11:52 <KipIngram> The Mac has a git repo behind it, so the Mac build script and include files are getting backed up that way.
17:12:11 <KipIngram> I should make sure that I have my Linux include file and build script properly backed up.
17:12:28 <KipIngram> The build script would be easy to rewrite, but I'd quite hate to have to work out all those termios magic numbers for Linux again.  :-|
17:16:06 --- quit: spestov (Ping timeout: 268 seconds)
17:17:52 <john_cephalopoda> KipIngram: Can't you set up scripts in the source tree that do things depending on the current system?
17:18:16 <john_cephalopoda> Like ifdefs
17:18:32 <PoppaVic> just use 2 build scripts/dirs with submakes
17:21:05 <KipIngram> Possibly.  That exceeds my git knowledge, john_cephalopoda.
17:21:47 <KipIngram> This works well enough - I don't expect ever to have to touch the include files again, so I'm not much worried about not having them front and foremost in the git infrastructure.
17:21:53 <KipIngram> I just need to make sure they're backed up somewhere.
17:22:00 <KipIngram> The big source file is the thing that counts.
17:22:12 <KipIngram> These include files are just 25 lines long.
17:22:24 <KipIngram> Just a bunch of nasm %define directives.
17:25:17 <KipIngram> Those are syscall numbers, ioctl numbers, and bit patterns and values for c_iflags, c_oflags, etc. etcc.
17:27:31 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth
17:34:24 --- join: tabemann (~travisb@rrcs-162-155-170-75.central.biz.rr.com) joined #forth
17:34:58 --- quit: spestov (Ping timeout: 246 seconds)
17:36:00 <john_cephalopoda> KipIngram: If you'd just integrate them into git, losing those files would be a non-issue.
17:37:09 <tabemann> hashforth is self-hosting! (at least in that you no longer need attoforth to assemble its images)
17:37:38 <tabemann> the catch is you need a working hashforth image to assemble a hashforth image with hashforth
17:38:34 --- join: nighty- (~nighty@b157153.ppp.asahi-net.or.jp) joined #forth
17:39:01 <tabemann> hence why I didn't simply delete the attoforth hashforth assembler from github (well, it'd still be there, but you'd have to go back in history)
17:40:04 <yunfan_> crc:  what's the testing code?
17:40:59 <KipIngram> It will be a non-issue anyway.  I don't know exactly how to set that up on git, and I have no interest in learning.
17:41:10 <KipIngram> I'll just copy it to my Dropbox and it will be done.
17:41:26 <KipIngram> This file will probably never change - it doesn't need to be under version control
17:42:54 <yunfan_> tabemann: you could put them to ipfs, so they could be exists for ever in theory
17:43:57 <tabemann> well deleting something from git doesn't actually get rid of it
17:44:13 <tabemann> unless you delete the whole repository
17:45:02 <yunfan_> and so what makes gforth so fast, and were there any other forth be much faster than gforth(-fast) ?
17:45:34 <yunfan_> tabemann: you could forced updating the whole git indexing i guess
17:45:49 <KipIngram> They've just optimized it out the wazoo over the years.
17:45:57 <KipIngram> "Every trick in the book" is what I think makes it fast.
17:46:12 <KipIngram> They've explored things like multiple stack elements cached in registers, etc. etc.
17:46:33 <KipIngram> It seems pretty clear to me that they set performance as a design goal, and systematically went after it, trying every thing they could try.
17:47:11 <KipIngram> And they seem willing to solve problems in more than one way, with the method chosen case-by-case to get highest speed.
17:47:44 <KipIngram> They've put a lot of intelligence about such things into their system, which is all nice and good, but it deviates from the "simplicity of Forth" in a pretty major way.
17:49:06 --- quit: dave0 (Quit: dave's not here)
17:52:43 <rdrop-exit> Greetings Forthlings
17:52:51 <crc> yunfan: not sure I understand. Both are serving a single file containing the letters fff since that's the default content for the 1991.fs example.
17:53:33 <tabemann> hey rdrop-exit 
17:53:46 <rdrop-exit> Hi tabemann
17:54:00 <crc> my casket server is included in the retro source as an example, and also at http://forth.works:8080
17:54:39 <tabemann> crc: you can finally build hashforth images
17:54:48 <crc> the inetd line is 8080    stream  tcp     nowait/6/30/2   crc    /home/crc/www/casket.forth
17:55:13 <crc> tabemann: not as of this morning
17:55:32 <tabemann> crc: okay, how's it acting up?
17:56:04 <tabemann> (don't tell me that hashforth also crashes on freebsd and openbsd)
17:56:07 <crc> some notes on the latest hashforth under openbsd: http://forth.works/29878c26ad26a3f4fc15f718560d9982
17:57:48 <tabemann> okay, just checked, it also leaves an item on the stack for me as well
17:59:29 <tabemann> also there was a file missing from git
17:59:50 <tabemann> try again
18:00:49 <tabemann> I'll try to figure out where that number is coming from
18:03:42 <crc> http://forth.works/4fa37b70968a8fa250501339d258308c
18:05:14 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth
18:07:17 <tabemann> interesting
18:08:04 <tabemann> that's the stock image that came with hashforth?
18:08:14 <crc> yes
18:08:54 <crc> fresh unpack of the tarball, adjusting cflags only as needed for building openbsd
18:09:00 <tabemann> and that's a 64-bit system you're running it on
18:09:34 <crc> yes
18:09:50 <crc> OpenBSD forth.members.linode.com 6.4 GENERIC#349 amd64
18:10:44 <tabemann> I'll try compiling hashforth with -std=c99
18:12:40 <crc> src/runtime/sys.c: In function 'hf_sys_poll':
18:12:41 <crc> src/runtime/sys.c:414: error: 'for' loop initial declaration used outside C99 mode
18:12:41 <crc> src/runtime/sys.c:430: error: 'for' loop initial declaration used outside C99 mode
18:12:41 <crc> gmake: *** [Makefile:48: obj/sys.o] Error 1
18:12:50 <crc> if I dont have that added
18:13:13 <yunfan_> crc: i could understand inetd solution might be slow, but why tcpserver solution be also that slow?
18:13:14 <crc> gcc version 4.2.1 20070719 
18:13:39 <yunfan_> KipIngram: so what about my other question? any other forth faster than gforth?
18:13:51 <crc> yunfan_: it still has to start a fresh copy of the vm for each connection
18:14:44 <yunfan_> crc: what about long connection, multiple request?
18:14:59 <crc> not supported
18:15:16 <crc> afaik, I'd need actual sockets for that
18:15:17 <yunfan_> crc: so you dont support keepalive?
18:15:33 <crc> no
18:15:47 <tabemann> okay, with -O2 -std=c99 -DTOKEN_16_32 it refuse to compile for me
18:16:51 <rdrop-exit> Why c99 instead of c11?
18:16:55 <yunfan_> okay, in this situation, android's dalvikvm seems had solution for reduce vm copy
18:17:40 <crc> rdrop-exit: no idea
18:18:07 <crc> it worked this morning, other than building the image
18:20:53 --- quit: spestov (Ping timeout: 250 seconds)
18:24:36 <crc> when built with c11 it works to build the image
18:29:32 --- quit: rdrop-exit (Quit: Lost terminal)
18:30:36 <tabemann> okay I figured something out
18:30:54 <tabemann> for me it works... only when -g is specified
18:32:28 <tabemann> forget about that
18:33:26 <tabemann> for me the new image that I've been compiling doesn't work... even though the source code is identical to that for an older image I built earlier that works
18:36:19 --- nick: yunfan_ -> yunfan
18:37:23 --- quit: yunfan (Changing host)
18:37:23 --- join: yunfan (~roooot@unaffiliated/yunfan) joined #forth
18:44:44 <tabemann> okay, that was weird
18:44:56 <KipIngram> yunfun: I don't really keep up with that stuff.  There might be.
18:45:05 <tabemann> I did a git checkout to go back to the old version of the hashforth image in git
18:45:07 <tabemann> it worked
18:45:10 <KipIngram> Mine compared pretty favorably, but it's not "out there" yet.
18:45:15 <tabemann> I used it to build itself
18:45:18 <KipIngram> I wouldn't say it's faster, but it was right in the ballpark.
18:45:19 <tabemann> it worked again
18:45:29 <KipIngram> Oh, cool tabemann.
18:45:53 <tabemann> it's like I introduced a bug in itself at one point that propagated itself without being in any source code
18:45:59 <crc> odd
18:46:50 <tabemann> but the thing is that I'd saved a copy of an image, which I thought was the image in git, and whenever that built in image, the image was bad, even though it itself worked otherwise
18:47:53 <tabemann> adventures in self-hosting
18:49:02 <yunfan> KipIngram: any name you could recall?
18:49:07 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth
18:49:26 <KipIngram> No.  Really the main ones I have any experience with are gforth and pforth.
18:49:33 <KipIngram> Pforth's big virtue is that it builds easy from source.
18:49:36 <KipIngram> It's VERY portable.
18:49:56 <KipIngram> But it's written in C - I doubt it can take GForth on speed.
18:50:00 <tabemann> okay, it gets weirder - the copy in git and the saved copy are identical
18:50:12 <KipIngram> There may be some commercial ones, but I really now nothing about them.
18:50:17 <KipIngram> know
18:50:40 <PoppaVic> well, gforth is "C"... and VMgen (C) and assembler and.. much massage, scented oils, etc
18:50:43 <KipIngram> Honestly, though, I've become less concerned with that last bleeding edge of speed in recent years.
18:50:56 <KipIngram> Only a small part of the code you write will be on the critical performance path.
18:51:11 <KipIngram> If you absolutely have to have that last little bit, write those pieces in assembly.
18:51:20 <PoppaVic> <shrug> speed? C, or asm-from-c
18:52:04 <KipIngram> Write your code for elegance and readability, profile it, and optimize.
18:54:20 <tabemann> stupid question - should I make hashforth crash if it gets to the end of the code?
18:54:39 <PoppaVic> core droppings ;-)
18:54:52 <tabemann> I ask because doing so would allow me to eliminate a comparison, and make a branch unconditional
18:56:22 <tabemann> (I did just this in attoforth - task had to commit suicide at the end of their execution or else it would crash)
18:56:26 <tabemann> *tasks
18:57:11 <KipIngram> I don't quite follow.
18:57:18 <crc> tabemann: crashes = core dumps, which aremannoying
18:57:18 <KipIngram> What exactly is "committing suicide"?
18:57:36 <tabemann> they had to actually kill themselves
18:57:47 <KipIngram> As opposed to just "returning"?
18:57:52 <tabemann> yes
18:57:58 <KipIngram> I see.
18:58:05 <KipIngram> Well, in a cooperative system that seems just fine to me.
18:58:19 <KipIngram> You'd make a word for it, so it would be easy.
18:58:38 <zy]x[yz> why would there not be some place for it to return to and die
18:58:40 <KipIngram> But who launched the task, and why are they not there waiting to receive a return?
18:58:53 <KipIngram> ^ that
18:58:53 <tabemann> in hashforth I have functionality so that tasks have a place to return to and clean up after themselves
18:59:37 <tabemann> zy]x[yz, well I did add that, where normal tasks returned to a function that then KILLed the task after executing ATEXIT handlers
18:59:50 <KipIngram> You'd think there would be some sort of supervisor that launched the task in the first place, so you could return to them and they could do the cleanup.
19:00:09 <zy]x[yz> so why can't reaching the end of code (whatever that means) also returns someplace and terminates the process cleanly
19:00:15 <tabemann> well that's a higher level inter-task communication thingr=
19:00:36 <KipIngram> Do these tasks start in some fashion other than executing an xt?
19:00:52 <zy]x[yz> disregard my weird verb tense braino
19:01:01 <tabemann> in attoforth I had ATEXIT handlers, and you can put something in an ATEXIT handler such as something that passes a message to another task
19:01:17 <KipIngram> But how do the tasks get launched?
19:01:33 <tabemann> KipIngram, there is some setup which is done,and then an xt is executed
19:01:52 <KipIngram> Ok, so whoever does that <xt> EXECUTE is who the return will go to.
19:02:09 <KipIngram> I'd put my kill / cleanup there.
19:02:38 <tabemann> well, tasks don't return unless you add an ATEXIT handler that sends a message to someone
19:03:11 <KipIngram> But when you compile the task, doesn't the top-level word (that becomes the XT you execute) start with a : and end with a ; ?
19:03:18 <tabemann> they're not like Unix processes in that you don't have waiting and zombie processes and like
19:03:19 <KipIngram> That will make it do a return at the end, right?
19:03:58 --- quit: spestov (Ping timeout: 258 seconds)
19:04:04 <tabemann> yes, but the return stack will either (I don't recall which) be empty or contain null
19:04:43 <tabemann> which is why it crashes, and why task seppuku is necessary to ensure the task never reaches that ;
19:05:24 <tabemann> in hashforth I avoid that by wrapping the xt in an exception handler which also cleanly handles exit
19:06:20 <tabemann> of course I effectively did the same thing in attoforth, where I wrapped the xt in a function that called ATEXIT handlers and then called KILL on itself
19:12:25 * tabemann wonders if it is a good thing or a bad thing that in hashforth tasks don't really terminate, but rather are just deactivated, in that they can be activated again
19:13:49 <PoppaVic> zzzz
19:26:31 <tabemann> crc: I fixed the bug that was leaving garbage on the stack
19:28:05 <yunfan> pointfree: your twitter avatar looks cool 
19:30:58 <crc> tabemann: works now, including building the image
19:32:04 <tabemann> yeah, the bug didn't manifest itself in DEBUG mode
19:32:16 <tabemann> so because I'd done all my testing in DEBUG mode I missed it
19:34:53 <tabemann> it's weird that it didn't like the time code in sys.c even though i'd include time.h in c99 mode unless I added an extra #define (even though the man page for clock_gettime() said nothing about this #define being necessary)
19:36:46 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth
19:38:53 --- join: gravicappa (~gravicapp@h109-187-219-53.dyn.bashtel.ru) joined #forth
19:41:09 --- quit: spestov (Ping timeout: 240 seconds)
19:44:06 <tabemann> okay, I'm gonna head home - bbl
19:48:40 --- quit: tabemann (Ping timeout: 246 seconds)
19:52:51 * crc has updated forth.works to use casket on port 80 instead of the more minimal pastebin-only server. The share URI's will continue to work, so any references to them won't break.
20:01:46 --- quit: dddddd (Read error: Connection reset by peer)
20:23:12 --- join: tabemann (~travisb@2600:1700:7990:24e0:2044:d43b:a652:1d84) joined #forth
20:35:06 --- join: rdrop-exit (~markwilli@112.201.168.172) joined #forth
20:45:44 <tabemann> wb
20:46:21 <rdrop-exit> Thanks tabemann
20:50:37 * tabemann is glad that he doesn't need to deal with attoforth to work on hashforth anymore
20:50:55 <rdrop-exit> Cool
20:51:42 <yunfan> tabemann: that's your apollo 11 moment
20:53:10 <tabemann> attoforth was an overgrown, ill-thought out attempt at a forth implementation; however, it has some thing hashforth lacks, but that's because the two ultimately have different goals
20:53:54 <tabemann> *things
20:54:42 <tabemann> e.g. I could add a full line editor to hashforth's default image, like attoforth has, but that's not a priority
20:55:41 <yunfan> well i just care about the size and the relative speed compare to gforth :D
20:56:01 <tabemann> likewise I could easily add preemptive multitasking to hashforth, with minimal modification to the underlying VM, as attoforth has, but again preemptive multitasking is not a goal for hashforth
20:56:13 <tabemann> oh, hashforth's definitely slower
20:56:30 <tabemann> performance is not a serious goal of hashforth
20:56:52 <yunfan> i think at least you should gain a performance better than cpython, this is the bottom line
20:58:06 * crc doesn't obsess over performance
21:01:12 <rdrop-exit> Is there an x86 assembler on Gforth?
21:01:31 <tabemann> hashforth is meant to be lightweight and portable - right now it should run on any recent POSIX system (recent being any which supports clock_gettime()) - and I bet it shouldn't be too hard to port to a non-POSIX embedded system (mostly by ripping out the POSIX-related services and capturing them so as to interface with the embedded hardware directly)
21:04:59 <yunfan> well  python and lua is also portable
21:05:12 <rdrop-exit> So what?
21:05:49 <PoppaVic> gee! a hammer is portable.
21:05:59 <rdrop-exit> :))
21:06:01 <tabemann> Python is not small
21:06:43 <rdrop-exit> I still haven't even looked at Python
21:07:13 <tabemann> Lua is a better comparison
21:07:40 <tabemann> even though there are definite contrasts - you can't write a multitasker for Lua in Lua, and Lua itself isn't written in Lua
21:08:15 <tabemann> a better comparison w.r.t. Python might be MicroPython
21:08:33 <tabemann> which is a minimal implementation of Python meant for embedded systems
21:08:42 <PoppaVic> circuitpython
21:15:57 <rdrop-exit> If you're tight on target space, just go tethered.
21:17:34 <rdrop-exit> No sense in trying to shoehorn a full system on a tiny target.
21:18:15 <crc> retro might not be as fast as cpython or lua, but I understand it completely. I can rewrite it from scratch if I needed to, or easily adapt it to the needs of a specicfic task. that's worth a lot to me.
21:20:22 <rdrop-exit> Hear hear!
21:38:03 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth
21:43:07 --- quit: spestov (Ping timeout: 268 seconds)
21:49:25 --- quit: rdrop-exit (Quit: Lost terminal)
22:56:56 --- quit: tabemann (Remote host closed the connection)
22:57:11 --- join: tabemann (~travisb@2600:1700:7990:24e0:2044:d43b:a652:1d84) joined #forth
23:38:59 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth
23:43:59 --- quit: spestov (Ping timeout: 272 seconds)
23:59:59 --- log: ended forth/19.02.14