00:00:00 --- log: started forth/19.05.16
00:21:25 --- quit: xek (Ping timeout: 264 seconds)
01:02:05 --- part: nathanael_schwee left #forth
01:31:52 --- quit: pierpal (Quit: Poof)
01:32:09 --- join: pierpal (~pierpal@host103-244-dynamic.55-79-r.retail.telecomitalia.it) joined #forth
02:04:16 --- quit: ashirase (Ping timeout: 258 seconds)
02:09:29 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth
03:28:21 --- join: xek (~xek@user-5-173-137-10.play-internet.pl) joined #forth
04:02:14 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
04:06:45 <crc> ttmrichter: true, though I dislike resorting to things that complicate the overall understandability of the system
04:13:15 <ttmrichter> Fair point.  It's something that should be used sparingly and as a last resort.
05:22:09 <WilhelmVonWeiner> john_cephalopoda: would avoid those words imo
05:22:24 <WilhelmVonWeiner> if you use recursion and 0; it should be faster
05:22:38 <WilhelmVonWeiner> because quotations have layers of overhead 
05:23:21 <WilhelmVonWeiner> 0; is one of my favourite Forth words
05:23:44 <WilhelmVonWeiner> got to show off my stack processor to some lecturers today. One didn't get it, at all.
05:24:03 <WilhelmVonWeiner> "but... what could you do with it? why would you do it?"
05:25:28 <WilhelmVonWeiner> fib in one instruction word though, thanks to packed opcodes and that
05:59:36 <crc> http://forth.works/89c819ef8dacdead5c028a78ae7472a3
05:59:37 <crc>  would be the mb_value using repeat/0;/again instead of while
06:28:27 --- join: xek_ (~xek@public-gprs399932.centertel.pl) joined #forth
06:31:03 --- quit: xek (Ping timeout: 258 seconds)
07:38:45 --- join: jpsamaroo (~jpsamaroo@136.58.85.67) joined #forth
07:41:31 --- quit: tabemann (Ping timeout: 250 seconds)
07:44:21 --- join: jpsamaroo_ (~jpsamaroo@2605:a601:a39c:7b00:ead8:7321:f185:d7a5) joined #forth
07:44:33 --- quit: jpsamaroo (Ping timeout: 248 seconds)
08:19:45 --- quit: jpsamaroo_ (Ping timeout: 248 seconds)
08:40:38 <gaze___> WilhelmVonWeiner: I try to steer clear of people for whom "because it's cool" isn't an acceptable reason for why you did something
08:42:40 <PoppaVic> sounds depressing
08:43:00 <PoppaVic> "because it's cool" is certainly not valid.
08:48:56 --- join: jpsamaroo (~jpsamaroo@2605:a601:a39c:7b00:ead8:7321:f185:d7a5) joined #forth
08:50:10 <john_cephalopoda> WilhelmVonWeiner: How can I recurse a few million times without a return stack overflow?
08:50:25 <PoppaVic> with a branch
09:28:02 --- join: nerfur (~nerfur@broadband-95-84-184-13.ip.moscow.rt.ru) joined #forth
10:05:00 --- join: jpsamaroo_ (~jpsamaroo@136.58.85.67) joined #forth
10:06:25 --- quit: jpsamaroo (Ping timeout: 264 seconds)
10:29:26 --- nick: jpsamaroo_ -> jpsamaroo
10:30:51 --- join: xek__ (~xek@user-5-173-137-10.play-internet.pl) joined #forth
10:32:07 --- join: grewal (~aman@70.23.200.13) joined #forth
10:33:20 --- quit: xek_ (Ping timeout: 258 seconds)
11:14:41 <crc> john_cephalopoda:   :recurse d:last<xt> compile:jump ; immediate
11:59:44 --- quit: gravicappa (Ping timeout: 268 seconds)
12:32:59 --- quit: xek__ (Remote host closed the connection)
12:33:18 --- join: xek__ (~xek@user-5-173-137-10.play-internet.pl) joined #forth
12:56:18 --- quit: proteusguy (Ping timeout: 258 seconds)
12:58:26 --- join: john_metcalf (~digital_w@host86-139-60-58.range86-139.btcentralplus.com) joined #forth
13:25:40 --- join: DabsR (~Mutter@190.62.251.34) joined #forth
13:28:00 --- quit: DabsR (Client Quit)
14:17:46 --- quit: pierpal (Ping timeout: 252 seconds)
14:33:18 <WilhelmVonWeiner> john_cephalopoda: because this isn't c?
14:33:46 --- join: xek (~xek@user-5-173-137-10.play-internet.pl) joined #forth
14:35:27 <john_cephalopoda> WilhelmVonWeiner: No matter which language, when I recurse and write addresses to the return stack every time, I will eventually run out of memory.
14:35:31 <WilhelmVonWeiner> crc: that as `me` is in my user.forth. it's very satisfying to use.
14:35:44 <WilhelmVonWeiner> you drop them off the return stack mate
14:35:47 <john_cephalopoda> and I'll do that way faster than I'll run out of memory to store nested while loop variables in.
14:35:55 --- quit: xek__ (Ping timeout: 252 seconds)
14:35:56 <john_cephalopoda> WilhelmVonWeiner: How do I do a counted loop with that?
14:36:57 <WilhelmVonWeiner> You have a counter that's decremented
14:37:03 <WilhelmVonWeiner> and your return address
14:38:02 <john_cephalopoda> What's the difference to a regular loop?
14:38:40 <WilhelmVonWeiner> go look at how quotations are implemented
14:39:28 <john_cephalopoda> Implemented where?
14:40:05 <WilhelmVonWeiner> in Retro which was the entire point
14:40:20 <WilhelmVonWeiner> it's also conceptually very simple, and simple to write
14:43:21 <john_cephalopoda> :while (q-) [ repeat `525570 `1639430 drop again ] call drop ; 
14:44:05 <john_cephalopoda> That's some inline nga assembly...
14:44:38 <WilhelmVonWeiner> inline assembly would be as{ }as
14:47:41 --- join: xek_ (~xek@user-5-173-137-10.play-internet.pl) joined #forth
14:48:12 --- quit: xek (Read error: Connection reset by peer)
14:49:05 <WilhelmVonWeiner> a while loop with recursion in Retro should be pretty simple now
14:50:26 <WilhelmVonWeiner> :looper (n-) perform-action if; looper ;
14:50:35 <WilhelmVonWeiner> if; exits the word if true
14:50:54 <WilhelmVonWeiner> sorry whoops
14:51:02 <WilhelmVonWeiner> that's not what if does
14:51:59 <WilhelmVonWeiner> although false is 0 so :looper perform-action not 0; looper ;
14:53:15 <WilhelmVonWeiner> anyway I gotta sleep, after the presntation everyone was drinking and that took the wind out of me, followed by 5 hours of train journeys
14:57:08 --- join: xek (~xek@user-5-173-137-10.play-internet.pl) joined #forth
14:57:19 --- quit: xek_ (Read error: Connection reset by peer)
14:58:42 --- quit: xek (Remote host closed the connection)
14:59:29 --- join: xek (~xek@user-5-173-137-10.play-internet.pl) joined #forth
16:03:56 --- quit: xek (Ping timeout: 268 seconds)
16:11:37 --- quit: Zarutian (Read error: Connection reset by peer)
16:12:10 --- join: Zarutian (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth
16:17:44 --- join: pierpal (~pierpal@host103-244-dynamic.55-79-r.retail.telecomitalia.it) joined #forth
16:21:57 --- quit: pierpal (Ping timeout: 244 seconds)
16:29:28 --- join: dave0 (~dave0@069.d.003.ncl.iprimus.net.au) joined #forth
16:34:20 --- join: pierpal (~pierpal@host103-244-dynamic.55-79-r.retail.telecomitalia.it) joined #forth
16:41:37 <dave0> hi
16:41:52 --- quit: john_cephalopoda (Ping timeout: 252 seconds)
16:56:10 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth
17:48:43 <crc> WilhelmVonWeiner: that's inlined code. At the point where `while` is defined, the assembler isn't written, so I have to manually inline the code.
18:21:02 --- quit: dddddd (Remote host closed the connection)
18:53:13 --- join: tabemann (~tabemann@rrcs-162-155-170-75.central.biz.rr.com) joined #forth
19:07:27 --- quit: grewal (Quit: leaving)
20:06:54 --- quit: tabemann (Ping timeout: 268 seconds)
20:17:37 --- join: gravicappa (~gravicapp@h109-187-22-102.dyn.bashtel.ru) joined #forth
20:43:01 --- join: tabemann (~tabemann@2600:1700:7990:24e0:b944:a349:56b9:12fb) joined #forth
20:57:04 --- join: rdrop-exit (~markwilli@112.201.166.63) joined #forth
20:58:24 <tabemann> hey
20:58:47 <rdrop-exit> c[_] Hi tabemann :)
21:03:41 <tabemann> I should do *something* with hashforth, I'm not sure what or how - probably the most natural thing to do would be to port it to an embedded platform - but the problem there is that I don't really know any embedded platforms (I did program on a Stellaris board once, but it was all using builtin ROM routines that abstracted away the hardware, and for this I'd want to directly address the hardware)
21:05:07 <rdrop-exit> What platform do you run on now?
21:05:21 <tabemann> x86-64 Linux
21:08:10 <tabemann> an easier port would be to something like that Raspberry Pi, but that's really far too easy - it's just a recompile
21:09:45 <rdrop-exit> Have you tried?
21:10:59 --- join: proteusguy (~proteusgu@cm-58-10-208-71.revip7.asianet.co.th) joined #forth
21:11:00 --- mode: ChanServ set +v proteusguy
21:11:13 <tabemann> hey proteusguy 
21:11:39 <tabemann> rdrop-exit, tried porting to something like Stellaris/Riva or porting to something like Raspberry Pi?
21:12:02 <rdrop-exit> You could do a quick check on a Pi running one of the BSDs as a first step
21:12:16 <tabemann> yeah, that'd probably be a good idea
21:13:33 <tabemann> running a BSD on a Pi would be close enough to x86-64 Linux that if I did everything right it shouldn't require anything more thn a recompile - but of course, with attoforth it turned out that there were problems getting it to work on BSDs even though I didn't knowingly do anything incompatible
21:15:11 <tabemann> I know someone else here got hashforth working on one of their boxen, and IIRC that person also uses xBSD
21:16:06 <tabemann> it might've been proteusguy or crc
21:17:48 <rdrop-exit> You could try running it on a big endian setup
21:19:25 <tabemann> that effectively rules out ARM
21:19:41 <rdrop-exit> I thought ARM was bi-endian
21:21:17 <tabemann> okay, just checked
21:21:32 <tabemann> it is bi-endian, but almost always people use it as little-endian
21:22:09 <rdrop-exit> ic
21:22:22 <tabemann> According to ARM Cortex M0 (Used in ultra Low power applications) technical reference manual, table 1-1, ARM supports both Little and Big endian and it is left to the implementer, such as Qualcomm, Nordic Semiconductor, ST Microelectronics etc (who produce ARM based ICs) to pick the endianness. So to be sure about the ARM endianness, you need to refer to the reference manual from the manufacturer.
21:22:48 --- quit: dave0 (Quit: dave's not here)
21:23:07 <tabemann> so the arch is bi-endian, but the implementation is up to the implementor
21:24:08 <rdrop-exit> ah
21:25:42 <rdrop-exit> It seems some of the older ARMs were more flexible
21:26:37 <tabemann> yes
21:26:42 <tabemann> it was controlled with a pin
21:30:30 <rdrop-exit> I'm still not clear on what level of portability you're going after with hashforth
21:32:26 <tabemann> the problem is hashforth by design is targeted towards larger systems - the problem is scaling down to platforms where not much RAM is available and most of the available memory is flash
21:33:21 <tabemann> it could be easily modified to run on bare metal, mostly by removing the OS-related services and emulating their functionality
21:34:06 <tabemann> but the problem is memory architecture
21:37:39 <rdrop-exit> Ok, but ignoring the issues with smaller systems for a minute, if I've been running an application on a hypthetical hashforth for windows, do I need the source of that application to run it on hashforth for Linux?
21:39:22 <tabemann> rdrop-exit: no
21:39:53 <PoppaVic> "Mother, should I trust the Government..?"
21:39:54 <rdrop-exit> ok, thanks
21:40:00 <tabemann> provided that the set of services the windows application relies upon is a subset of the set of services provided by the linux hashforth
21:40:34 <rdrop-exit> got it
21:41:25 <rdrop-exit> PoppaVic: Which one is Pink?
21:42:24 * tabemann is confused
21:42:54 <rdrop-exit> tabemann: PoppaVic quoted a Pink Floyd song
21:43:06 <tabemann> ah
21:43:21 <rdrop-exit> (so did I)
21:43:58 <PoppaVic> rdrop-exit: yeah, it's been awhile since I listened to the album - it was time.
21:44:26 * tabemann is listening to Dogma by KMFDM
21:44:43 <rdrop-exit> Well a good first test would be to hand your hashforth spec to a Windows programmer, then give him an application binary to test
21:44:56 <tabemann> "sex drugs god sex America"
21:45:14 <rdrop-exit> "Sex and Drugs and Rock n' Roll"
21:45:15 <tabemann> whoops
21:45:19 <tabemann> I got that lyric wrong
21:45:34 <tabemann> "sex drugs god cash America"
21:47:25 <tabemann> I'd have to make sure that my spec is air-tight first
21:47:56 --- quit: pierpal (Quit: Poof)
21:48:15 --- join: pierpal (~pierpal@host103-244-dynamic.55-79-r.retail.telecomitalia.it) joined #forth
21:49:39 <rdrop-exit> The questions he comes up with as he's trying to port will help you improve it
21:50:25 <tabemann> the problem is I don't know any Windows programmers who program sufficiently close to the metal
21:50:40 <tabemann> like I work with a bunch of Java/JavaScript programmers
21:51:07 <tabemann> and at my previous job we did do C/C++ programming, but it was on Linux, not Windows
21:51:13 <rdrop-exit> Have someone implement it on Java then.
21:51:51 <rdrop-exit> Make sure you don't answer questions verbally, only through revisions of the spec.
21:52:25 <tabemann> writing an implementation for Java would result in slow-as-fuck code, but it might actually be doable
21:53:07 <tabemann> to make it fast enough it might have to be word-addressed
21:53:33 <tabemann> and that would mean getting rid of my compact token encoding
21:53:46 <tabemann> and make each token cell-sized
21:54:00 <tabemann> and likewise make "bytes" and cells equal in size
21:54:20 <tabemann> so @ and C@ both return the same size value
21:54:22 <rdrop-exit> You're just using Java for testing the robustness of your spec, not to redesign the machine for Java specifically
21:54:36 <tabemann> tis true
21:55:25 <rdrop-exit> It's the porters job to optimize for the particular target
21:55:43 <rdrop-exit> as long as he meets the spec
21:56:36 <rdrop-exit> * porter's
21:57:03 <tabemann> doing a java implementation that is only meant to test the robustness of the spec shouldn't be that hard
21:58:01 <rdrop-exit> You'll get valuable feedback for tightening the spec
21:58:30 <tabemann> the only complication is that @ and ! would be especially slow because they would have to bitshift and OR together, or bitshift and mask, each byte individually
21:59:51 <rdrop-exit> IIRC Java is big endian, which will help test if your spec deals well with that aspect
22:01:39 <rdrop-exit> If it turns out that your spec is impossibly slow on most platforms, then you might need to consider changing the design and writing a completely new spec
22:01:47 <rdrop-exit> for a completely new VM
22:03:10 <tabemann> on here a tight counted loop is half the speed of one in Python 3
22:03:47 <tabemann> but the thing is that I plan on the implementation being coupled with a platform-specific transpiler
22:03:57 <tabemann> and deriving performance from that
22:05:36 <tabemann> (by "tight counted loop" I mean 0 BEGIN DUP < X WHILE 1 + REPEAT DROP in Forth, or for x in range(0, x): pass in Python)
22:05:49 <tabemann> whoops
22:05:57 <tabemann> (by "tight counted loop" I mean 0 BEGIN DUP X < WHILE 1 + REPEAT DROP in Forth, or for x in range(0, x): pass in Python)
22:06:17 <tabemann> where X or x is a constant
22:07:22 <rdrop-exit> You can't count on the "platform-specific transpiler" for performance
22:08:13 <tabemann> there are some things that can be done to increase performance
22:08:53 <tabemann> choosing a token format that does not compact them for memory-usage efficiency but rather use a 16-bit or 32-bit token in all cases
22:09:38 <tabemann> rather than an 8/16-bit or 16/32-bit token format, which is more efficient memory-wise but less efficient performance-wise
22:09:39 <rdrop-exit> You especially can't count on it if you're allowing the end-user of the application access to the interpreter
22:11:01 <tabemann> the transpiler would be transparent to the user; whenever ; would be executed it would convert the word to native code
22:12:00 <rdrop-exit> Each and every time?
22:12:17 <tabemann> yes
22:13:54 <rdrop-exit> That's a lot of extra machinery in the runtime.
22:14:25 <tabemann> this wouldn't be part of the runtime
22:14:41 <tabemann> the transpiler would exist outside of the runtime, in the image that is loaded on startup
22:15:33 <tabemann> the only only extra functionality that the runtime would provide is a means of calling native code from the VM, and a means of returning from native code to the VM
22:15:49 <tabemann> *the only extra
22:16:01 <tabemann> ; is not a primitive
22:17:29 <rdrop-exit> yes it's not
22:18:26 <tabemann> okay, I do need to go to bed: it's already 12:17 am here
22:18:44 <rdrop-exit> Good night :)
22:19:02 <tabemann> g'night
22:19:50 <rdrop-exit> Good time for me to walk the dogs bbiab
22:19:59 --- quit: rdrop-exit (Quit: Lost terminal)
23:59:59 --- log: ended forth/19.05.16