00:00:00 --- log: started forth/19.06.02 02:04:28 --- quit: Zarutian (Ping timeout: 268 seconds) 02:05:06 --- quit: ashirase (Ping timeout: 272 seconds) 02:08:59 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth 03:17:41 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 04:46:03 --- quit: djinni (Quit: Leaving) 04:49:12 --- quit: dave0 (Quit: dave's not here) 05:08:56 --- join: cnidario (~aaa@92.57.58.87) joined #forth 07:00:17 --- quit: dys (Ping timeout: 252 seconds) 08:23:11 --- join: dys (~dys@tmo-110-66.customers.d1-online.com) joined #forth 08:24:56 --- join: Zarutian (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth 08:28:16 --- quit: pierpal (Ping timeout: 272 seconds) 09:38:46 --- join: john_metcalf (~digital_w@host86-176-135-76.range86-176.btcentralplus.com) joined #forth 09:43:45 --- quit: john_metcalf (Quit: john_metcalf) 10:20:37 --- quit: cnidario (Remote host closed the connection) 10:27:53 --- join: pierpal (~pierpal@host196-36-dynamic.16-87-r.retail.telecomitalia.it) joined #forth 11:58:45 --- quit: gravicappa (Ping timeout: 252 seconds) 12:21:25 --- quit: pierpal (Ping timeout: 248 seconds) 12:51:41 --- join: rain2 (~My_user_n@unaffiliated/rain1) joined #forth 12:52:54 --- quit: rain1 (Ping timeout: 245 seconds) 13:09:17 --- join: dave0 (~dave0@069.d.003.ncl.iprimus.net.au) joined #forth 13:09:44 hi 13:11:58 <`presiden> hi dave0 13:13:20 hey 13:13:33 * tabemann now has a working intmap 13:14:08 (both a non-resizable ALLOT-ed one and a resizable ALLOCATE-ed one, specifically) 13:14:10 hi `presiden, tabemann 13:14:53 now I just need to make a string-map 13:16:10 --- quit: cheater (Quit: leaving) 13:46:28 --- join: john_metcalf (~digital_w@host86-176-135-76.range86-176.btcentralplus.com) joined #forth 14:04:44 --- join: xek (~xek@2a00:1028:83a0:2fde:ea9a:23fd:1b83:f76a) joined #forth 14:17:53 --- quit: tabemann (Ping timeout: 250 seconds) 14:27:28 --- join: tabemann (~tabemann@71-13-2-250.static.ftbg.wi.charter.com) joined #forth 14:54:28 --- quit: chunkypuffs (Ping timeout: 258 seconds) 15:06:50 --- quit: tabemann (Ping timeout: 252 seconds) 15:07:32 --- join: chunkypuffs (~chunkypuf@static.203.112.216.95.clients.your-server.de) joined #forth 15:14:01 --- quit: xek (Ping timeout: 258 seconds) 16:09:54 --- quit: john_cephalopoda (Ping timeout: 252 seconds) 16:23:18 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth 17:23:44 --- join: tabemann (~tabemann@h193.235.138.40.static.ip.windstream.net) joined #forth 17:40:14 --- join: rdrop-exit (~markwilli@112.201.166.63) joined #forth 17:43:29 c[_] Good morning 18:21:25 hey 18:21:45 * tabemann now has a working intmap, so he's now working on a non-int map 18:22:55 the non-int map is kinda heretical though, since it requires the use of ALLOCATE, whereas the intmap can be used just with ALLOT 18:23:52 (the intmap should be called a "cellmap", but i took the name from Haskell's IntMap) 18:24:33 (of course it's not the same has IntMap, since IntMap is functional and INTMAP is not) 18:28:52 what the hell is an intmap? 18:30:31 Zarutian: a map where the keys are cells 18:30:57 or in the case of Haskell's IntMap, Int's 18:31:23 oh, pretty much like an hashmap only perhaps without the hashing 18:31:42 the only "hash function" is a simple modulus 18:32:37 with maybe an added factor so that certain types of sets of keys don't have poor performance (e.g. where each key mod the map size is 0) 18:33:20 strictly speaking IntMap though is not a hashtable per se but rather a HAMT, a hash array-mapped trie 18:33:35 which enables it to be functional 18:34:18 a kind of persistant data structure in the functional programming sense (and not in the sense of being persisted to disk)? 18:36:51 yes 18:48:21 time for a walk! bbl 18:50:26 --- quit: dave0 (Quit: dave's not here) 19:00:31 --- quit: dys (Ping timeout: 258 seconds) 19:08:55 --- join: pierpal (~pierpal@host196-36-dynamic.16-87-r.retail.telecomitalia.it) joined #forth 19:16:32 Are you implementing this IntMap thing to fulfill a need or is this just for fun? 19:24:22 just for fun 19:25:33 partially it is that I don't feel ready to port hashforth to, say, an embedded platform, so I'm finding things to occupy my time that I find fun 19:33:49 Have you had a chance to test it on any other platform? 19:35:10 I should really get around to getting myself a Raspberry Pi 19:35:17 because that is the logical next step for porting 19:35:54 not as far a jump as going to something without an OS, but still a smaller system than what it's on now 19:36:17 at least it's a change in processor arch 19:41:58 You could try running it on an emulator in the meantime 19:42:06 or on a VM 19:44:43 yes, I could do t hat 19:44:45 *that 19:48:59 Something big endian if your current platform is little endian 19:52:12 If you're going after portability of a binary image, endianess is a big issue 19:53:42 making just the image endianness-independent shouldn't be too hard (it's just a matter of converting the fields in the image and converting each token when executed), but ensuring that the code that runs is endian-independent is probably infeasible due to the code having direct byte-level access to memory 19:55:49 probably the simplest approach, albeit the one with the greatest performance hit, is to enforce endianness upon every single memory access 19:56:45 so the code does not even know the endianness of the system it is running on 19:57:07 well, the code thinks it's running on a little-endian system even when it's big-endian 19:58:24 What level of portability is your hashforth spec meant to guarantee? 19:58:47 That's what you'll be testing against. 20:01:07 I'll probably aim for a lesser standard of endian-independence, in that the image loaded into memory is endian-independent, but the Forth code that executes must be written to be endian-independent; the reason being is that at least that allows a decent level of performance, whereas the force-everything-to-be-little-endian approach will encur a significantly greater performance hit 20:02:53 there still will be implementation issues, e.g. the image will have to encode what data in it needs to be converted and what data does not (i.e. is a sequence of bytes) 20:03:20 okay, I've gotta go - the coffee shop is closing 20:03:28 I'll be back on shortly 20:03:28 So you won't be trying to do a Forth-friendly alternative to the JVM 20:03:54 rdrop-exit: the thing is that the JVM hides endianness from the user by not allowing direct access to the binary format of memory 20:04:29 so endianness only matters in the binary format of class files and like 20:04:42 but I need to go 20:08:43 It sounds like you haven't yet resolved what portability guarantees your hashforth spec is meant to provide, so attempting to test those guarantees is premature until you pin them down 20:09:22 --- quit: tabemann (Ping timeout: 272 seconds) 20:33:09 --- join: gravicappa (~gravicapp@h109-187-8-54.dyn.bashtel.ru) joined #forth 20:34:44 --- join: tabemann (~tabemann@2600:1700:7990:24e0:b944:a349:56b9:12fb) joined #forth 20:55:38 --- quit: dddddd (Remote host closed the connection) 21:12:19 I'm confused about how much kit out there isn't already either little-endian or without very fast primitives for flipping ends? 21:18:41 https://en.wikipedia.org/wiki/Endianness#Current_architectures 21:21:07 Bi-endianess mitigates many of the cases 21:21:09 https://en.wikipedia.org/wiki/Endianness#Bi-endianness 21:24:45 The Wikipedia page for Open-Risc says "Big (unimplemented stub for Little)" whatever that means. 21:27:57 As far as non-hardware platforms, I have no idea other than it seems the JVM is big-endian. 21:31:07 WebAssembly is little-endian. 21:37:48 the thing about the JVM is it need not be big-endian at runtime, since there is no access to the real hardware representation as code running on the JVM goes 21:39:10 class files can be big-endian but be converted to a little-endian representation internally when loaded 21:39:54 That's the JVM itself, as opposed to something running on top of the JVM. 21:42:19 as far as I'm aware, code running on top of the JVM has no access to the hardware representation, so it doesn't matter what endian it is 21:43:44 the only exception are native code libraries loaded from within the JVM 21:43:57 which obviously would have access to the hardware representation 21:44:03 I actually have worked on such code 21:44:31 and I don't recall having to deal with endian conversion (I was working on a little-endian platform, either x86 or x86-64) 21:45:24 IF your Forth is running atop the JVM then doesn't the endianess of the JVM matter to you? 21:46:49 I presume that a Forth running on the JVM would be purely cell-addressed 21:47:08 i.e. there would be no C@, or C@ would be a synonym for @ 21:48:02 Why do you presume that? Is there something in your spec that says if you port this spec to platform X then you lose byte access? 21:48:44 well, you could make a byte-addressed JVM Forth, but there would be a major performance hit, because then @ would have to read each byte individually and then bitshift and or them together 21:49:29 remember that word-addressed platforms are a thing, even though they have fallen out of fashion 21:50:00 a Forth on a word-addressed platform might not have a C@ 21:50:05 I'm lost at what exactly you intend with Hashforth 21:51:20 like what degree of portability I intend? 21:52:03 Exactly, my understanding was that the point of Hashforth is its portability 21:53:08 or more precisely the portability of what runs atop of it 21:53:52 to me the main question is do we aim for complete binary compatibility without any effort on the programmer's part, with a potentially significant performance hit, or whether we enable binary compatibility as long as the programmer follows some guidelines, with less of a performance hit 21:54:28 i.e. do @ and ! do endian-conversion, or do we expect the programmer to write endian-independent code 21:54:48 It's not binary compatibility if you have to change the binary to make it run on another implementation of Hashforth 21:55:58 You're saying "the main question is do we aim for", my question to you is what does the current spec aim for? 21:58:53 the current spec requires @ and ! to do endian-conversion, because there are places in which it does not provide an option for endian-conversion to be done at load-time; however, this could easily be changed, so that endian-conversion would be done at load-time across the board, where then the programmer could just be relied upon to write endian-independent code 21:59:20 this is more a design oversight than anything 22:00:40 caused by that non-colon words' data are loaded verbatim 22:00:59 and the loader has no way of knowing whether it should be treated as cells or as bytes 22:02:41 My understanding from an earlier discussion was that image would be standardized as little endian, and that therefore the programmer is coding not in an endian independent way, but assuming little endianess. 22:04:46 I have no idea how to search the log archives for the specific mention. It was a while back. 22:05:25 I was treating it as if the image format is little endian, and was undecided as to whether to enforce little-endianness altogether at runtime, or to require the programmer to write endian-independent code 22:06:37 * tabemann should check to see how much of a hit is incurred when forcing big-endian to little-endian conversion at runtime 22:07:12 It would depend on the platform I imagine. 22:08:45 In most cases the platform would be little endian, so no runtime overhead would be needed. Big Endian platforms would be the only ones to take a hit. 22:10:22 How much of a hit would depend on the ISA. 22:12:46 In other words if you standardize the binary image to be little endian, and the programmer is writing assuming little endian, then only the people porting your VM to big-endian platforms would require the extra-layer of overhead. 22:14:32 that is true 22:15:00 The ports of your VM wouldn't require the layer, and the programmers of systems running atop your VM wouldn't have the burden of writing endian-independent code. But everything would take a performance hit on the rare big-endian platform. 22:15:33 * The ports of your VM wouldn't require the layer on little-endian platforms ... 22:19:12 Myself I would prefer keeping little-endian platforms fast, and taking a performance hit on big-endian, then making both slower. 22:20:01 And not have to burden the application programmer with having to write endian-independent code. 22:23:10 I understand your logic here; this would keep things simple, i.e. not requiring extra work to account for image file conversion (since who knows how the data stored in the images is actually formatted) 22:23:37 since image files can contain arbitrary data structures 22:23:56 I do have to go to bed now; it's getting rather late here 22:25:25 Right, the ANS standard can burden the programmer with such issues, but you don't have to since the programmer is targeting a your VM rather than an abstract might be anything target. 22:25:26 g'night 22:25:34 Ciao tabemann 23:59:59 --- log: ended forth/19.06.02