00:00:00 --- log: started forth/19.07.07 00:02:36 yeah, you got me :P 00:02:45 pure, including nontermination as a side effect 00:03:47 so not just pure but total 00:03:55 yeah 00:04:27 let me guess - is this dependently typed? 00:06:50 yup! 00:07:13 but are you trying to replicate erlang? 00:07:22 erlang's task model, yeah 00:07:24 I ask because erlang is neither pure nor total 00:07:36 exceptions can exist in the IO monad 00:10:14 note that the design of erlang is not very compatible with being pure, total, or even statically typed 00:10:15 though quite possibly I only have as IO primitives, killThisTask : IO (), sendMessage : Bytes -> TaskID -> IO (), recvMessage : IO (Bytes, TaskID), spawnTask : IO () -> IO TaskID 00:11:33 yeah, I'm mainly planning to support erlang's... fluidity... via a bunch of IOful functions 00:11:41 or possibly do everything in a freer monad 00:12:04 the difference is that erlang sends data structures 00:12:23 like I have written an actor implementation for hashforth 00:12:31 and I am limited to sending bytes 00:12:42 yeah, I'm probably doing that with something like serde baked in 00:13:03 (or like aeson if you don't know the rust ecosystem) 00:13:21 however, I have the advantage that, because task have access to the underlying memory, I can send tasks pointers to data structures 00:14:23 yeah, I might do that "as an optimization," with the understanding that once I'm doing multimachine, I'll use the same GC traversal hooks generated for types to ensure copies of data exist on the receiver 00:14:52 though I guess that implies blocking GC on the network 00:16:34 well then what you need is some means of representing data structures 00:16:40 combined with serializers and deserializers 00:16:59 essentially you end up with tagged data structures in memory 00:17:12 I mean don't they need to be tagged for GC? 00:17:17 (implicitly or explicitly) 00:17:46 I mean furthermore, to represent the structure of the data structures 00:18:08 GC only needs to know of data structure nodes as sets of references 00:18:28 I guess 00:18:41 but for this you need tagging that gives data structures meaning 00:19:10 this kind of thing is why erlang is dynamically typed 00:19:11 but if I'm fine storing a GC mark/sweep method, I'm fine storing a pointer to a vtable for everything else the word before it or smth 00:20:32 like you'll probably need a number of types, e.g. symbols/atoms, vectors, maps, and bytearrays 00:20:43 and integers and maybe floating points 00:21:14 why can't I just use e.g. the real in-memory representation with pointers made relative or smth 00:21:26 since both sides have the type definitions 00:22:02 assuming that both sides have the type definitions gives up the ability to hot-load code 00:22:23 there's a compiler process assumed to exist 00:22:52 where I send an AST to it and it spawns a process or smth 00:23:27 what I mean is that you need to take into account that different processes have different ideas about what types exist 00:23:51 because if you hot-load one process that introduces new types that an existing process lacks 00:24:09 you cannot rely on all processes agreeing upon what types exist 00:24:28 you're better off using a structured wire format akin to, say, JSON 00:24:31 messages are tagged w/ a hash of the data structure? 00:24:35 or BSON 00:24:53 though I guess that implies needing newtypes for all the messages that're plain strings 00:25:03 which I'm fine with tbh 00:25:16 I would seriously take a look at how Erlang does things more closely 00:25:29 I've written ~2k lines of Erlang ever, yeah 00:25:29 there is a reason why Erlang is not Haskell 00:25:54 I mean, if there are better models for high-reliability concurrency, I'm open to them 00:26:16 I've looked at distributed Haskell code, and even tried to write an actor framework in Haskell, and it's not exactly pretty 00:26:25 no, I mean the opposite 00:26:48 Erlang is the best we have for high-reliability distributed computing 00:28:26 I don't get what part of the erlang model is compromised by strong types tho 00:28:26 there's a reason with in Erlang they use static analysis tools to analyze Erlang code prior to compilation, rather than relying upon static typing at compilation time to ensure safety 00:29:04 the reason is that erlang applications are heterogeneous at runtime 00:29:28 more than one version of any given erlang process can be running at once 00:29:32 Yeah 00:29:54 if you enforced static typing you'd have to force all the processes to act in lock-step 00:30:03 i.e. you couldn't incrementally restart and upgrade processes 00:30:10 but rather you'd have to restart them all at once 00:30:48 So as I understand it in erlang 00:31:15 you upgrade by swapping out your main loop function, such that the new version can handle the old one's args 00:31:40 If I added an execAST : Ast -> IO () or something, wouldn't that work basically the same? 00:31:50 except ofc I'd be passing the arg as a literal in the ast 00:31:58 er, IO a I guess 00:32:28 you upgrade by having the main function call itself but with a macro for the current module, so that when the current module is updated it calls the new version 00:32:47 the problem is one of synchronization 00:33:06 you'd have to synchronize updates across the entire application 00:33:13 why? 00:33:16 which is effectively impossible in distributed environments 00:33:44 because different processes and nodes would have different ideas as to what types exist 00:34:01 if I send a message to a reciever that doesn't understand it, it gets dropped 00:34:09 and the sender has a responsibility to time out 00:34:16 (or retry, or...) 00:34:25 that's too inflexible 00:34:54 if the type definition doesn't change the hash shouldn't either, ftr 00:34:58 you can't just be suddenly dropping lots of packets at upgrade time just because the logical structure of the types have changed 00:35:18 consider it this way 00:35:30 let's you have a type, to use Haskell syntax: 00:35:36 I mean... if it changed, why not? wouldn't the erlang equivalent be the same, except you'd be crashing and getting restarted by a supervisor? 00:35:44 data MyType = Foo | Bar | Baz 00:35:52 it shouldn't be broken by changing that o: 00:36:05 data MyType = Foo | Bar | Baz | quux 00:36:11 data MyType = Foo | Bar | Baz | Quux 00:36:18 sure, the type is different 00:36:20 but Foo is Foo 00:36:24 and Bar is Bar 00:37:13 but how should the receiver handle quux? I see your point though; maybe tooling to make old types be supported with a "promotion" to the new types? 00:37:15 in erlang in this case, foo bar and baz are atoms 00:37:24 atoms don't change 00:37:27 they're like integers 00:37:52 sure, but a reciever that doesn't know how to handle quux still wouldn't 00:38:02 that's up to the programmer 00:38:21 but it's more flexible than just saying "oh, the types are formally different, let's break everything" 00:38:29 as in it could have a catch-all clause? 00:39:11 yes 00:39:35 I could add something for that, sure? (actually, I think I'd have to) 00:40:14 I think my recv type would look more like IO (TaskID, (T: Type ** T)), to use Idris syntax 00:40:50 though then I need equality for types, which is bad... 00:41:41 I could do addRecvHandler : (T:Type) -> (T -> IO ()) -> IO (), and waitForRecvs : IO () I guess 00:42:01 which ensures the type-equality-checking only happens inside IO 00:42:18 where many bets are off anyway :P 00:42:27 okay, I do need to hit the sack soon 00:42:38 ok, gn; thanks for the convo! 01:06:40 --- join: mtsd (~mtsd@94-137-100-130.customers.ownit.se) joined #forth 01:12:39 --- quit: jimt[m] (Write error: Connection reset by peer) 01:12:45 --- quit: siraben (Write error: Connection reset by peer) 01:12:46 --- quit: bb010g (Write error: Connection reset by peer) 01:21:38 --- quit: tp (Remote host closed the connection) 01:21:57 --- join: tp (~Terry@2001:44b8:314b:a800::10) joined #forth 01:21:57 --- quit: tp (Changing host) 01:21:57 --- join: tp (~Terry@mecrisp/staff/tp) joined #forth 01:22:49 --- join: siraben (sirabenmat@gateway/shell/matrix.org/x-mmknpdaepwhvffwa) joined #forth 01:33:33 --- join: john_metcalf (~digital_w@host31-54-142-171.range31-54.btcentralplus.com) joined #forth 02:06:51 --- quit: karswell (Ping timeout: 244 seconds) 02:09:57 --- join: bb010g (bb010gmatr@gateway/shell/matrix.org/x-eawqizelpdwgrmzm) joined #forth 02:09:57 --- join: jimt[m] (jimtmatrix@gateway/shell/matrix.org/x-hvjsgjqptkzjxkjt) joined #forth 02:11:25 --- quit: kori (Ping timeout: 268 seconds) 02:13:00 tp: Mmh, the eye of cepahlopods and of humans is a case of convergent evolution. Human eyes are part of the brain and are formed from there, cephalopod eyes were originally light-sensitive cells on the skin and eventually evolved into a U-shape, then into a pinhole camera and then a lens developed. 02:14:04 Cuttlefish can see the polarisation of light. Apparently that can help them to hide better in water. 02:17:08 john_cephalopoda, and they don't have to oscillate their eyes back and fro as humans do ? 02:24:36 --- quit: rdrop-exit (Quit: Lost terminal) 02:34:26 --- quit: john_metcalf (Ping timeout: 252 seconds) 02:37:11 --- quit: jedb (Ping timeout: 246 seconds) 02:37:53 --- quit: mtsd (Quit: Lost terminal) 02:42:33 --- join: jedb (~jedb@103.254.153.113) joined #forth 03:12:10 --- join: kori (~kori@187.123.3.51) joined #forth 03:12:14 --- quit: kori (Changing host) 03:12:14 --- join: kori (~kori@unaffiliated/kori) joined #forth 04:04:08 They also don't have a blind spot because their optic nerve grows on the OUTSIDE of the eye, not the INSIDE. 04:04:40 ahh good point 04:05:11 back of the retina you mean ? 04:09:59 --- join: dys (~dys@tmo-080-255.customers.d1-online.com) joined #forth 06:10:34 I ported my x86 assembler to RETRO. 06:10:54 https://github.com/jmf/impexus/blob/master/arch/x86/asm-x86.forth 06:12:45 Example program (multiboot executable) https://github.com/jmf/impexus/blob/master/arch/x86/init.forth 06:12:56 nice work, you make it look easy! 06:14:28 Thanks! It isn't too complicated, took a few iterations to get there though. 06:14:36 And a lot of drawings on paper :þ 06:17:00 I have a Mecrisp-Stellaris Forth to thumb assembler written by matthias koch, which I'm trying to use to prototype bare metal thumb2 assy 06:17:22 just to pick up my usual stupid mistakes etc 06:18:13 a interactive assembler is very handy for such things, unlike assy on bare metal and absolutely no feedback 06:21:20 Hmm, I haven't looked at thumb yet. x86 assembly is a mess. Hundreds of opcodes... 06:22:09 I've heard it's horrible, I never liked Intel assy much 06:22:51 I implemented a subset of it, which is very RISC-like. 06:24:35 Matthias says that "The ARM instruction set is too complex" when it comes to making a Forth emulator for it 06:25:11 but hes written a emulator for RISC-V in Pascal 06:25:31 and MSP430 also in Pascal 06:26:08 Oooh, an emulator... that sounds like a cool project. But I'll save that for in a few years :þ 06:26:59 he wrote 'mecrisp-across' which is a tethered Forth using a Cortex-M4 running Mecrisp-Stellaris Forth to generate machine code for a MSP430, it works really well 06:27:53 the terminal talks to the Cortex-M4 and runs in 'host' or 'target' mode. In target mode it seems that the MSP430 target is running Forth locally, but it's not 06:28:49 so much code to write, ... so little time! 06:29:54 I am working with ARM Cortex M processors. Takes a bit of work to set up the clocks, the GPIOs and a UART to actually get some feedback out of it. 06:30:17 (Haven't done anything forth-y with those yet) 06:30:53 Ive written and modified clock, gpioand uart assy code in thumb, I thought it was really easy ? 06:31:17 everyone says it difficult but I found it really straightforward 06:31:48 dunno why as I'm hardware not really software, but I have always liked assy 06:32:19 john_cephalopoda, you write C for ARM Cortex M processors ? 06:32:30 maybe thats why it seems hard ? 06:33:03 here is my state of Forth with cortem-m0 06:34:01 RCC_AHBENR. RCC_AHBENR (read-write) $005E0000 06:34:02 I I I I I F 06:34:02 T O O O O O L S 06:34:02 S P P P P P C I R D 06:34:02 C F D C B A R T A M 06:34:02 E E E E E E C F M A 06:34:04 N N N N N N E E E E 06:34:06 |2| |2| |2|1|1|1| N N N N 06:34:10 ~|~|~|~|~|~|~|4|~|2|~|0|9|8|7|~|~|~|~|~|~|~|~|~|~|6|~|4|~|2|~|0 06:34:12 0 0 0 0 0 0 0 0 0 1 0 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 06:34:22 I hope that the columns align for you, apologies if they dont 06:41:05 They do, I am using a terminal client with monospace font. 06:41:50 And yes, I am writing C for Cortex M processors. It's for my master's thesis at a company. 06:42:09 cool :) 06:42:33 i wonder if the reason everyone tells me how hard the clocks are because theyre using C ? 06:43:28 I generate every register and bitfield Word using CMSIS-SVD for any MCU that has a SVD 06:43:32 It is not really well-documented in the processor-specific docs, and the Hardware Abstraction Layer (HAL) doesn't make it easier most of the time. 06:44:32 and a pretty print for all the peripheral registers like the above is autogenerated, tho ones like that one I hand edited the legends. Default is just a 32 bit template 06:45:25 I havent really done any C since I started learning Forth in 2014 and the more I use Forth the less I want to use C 06:45:51 but then I only do simple stuff, I could never do a ethernet word, or a USB word 06:45:53 I'll have to use a lot of C in my thesis and after that in my job. 06:46:44 yeah, jobs come first 06:47:02 this is all hobby level for me 06:47:47 tho I used to make some small commercial embedded gear a decade ago and may do some more with Forth in future 06:48:20 Sell a small Forth or RETRO computer for nerds :D 06:48:51 not my thing, more like grain level detectors for industrial control etc 06:49:07 I'm hardware, not really software 06:49:33 Ah, industrial. There's some fun stuff. 06:49:48 or perhaps a small handheld car speedometer tester for automotive electrical people 06:50:35 I have about 100 projects Id like to make, but my gravestone will read " He died mid project!" 06:51:17 Ive always worked in industrial, instrumentation, automotive etc 06:52:45 so with Forth I can make up words to set up and test on chip cortex-m0 peripherals and do it all the time. The interactivity makes that job pretty easy 06:53:33 You can just flip memory bits and see what happens. 06:53:44 with the interactive assembler I can even write the code in near real assy and test it unde rforth, then just go bare metal assy and it usually works 06:53:48 exactly 06:54:10 and then I can check they have actually flipped with my register pretty print words 06:55:58 I find that the stm doc is pretty good and it's my fav doc for mcu's now. When the doc seems to be ambiguous I just test the register with Forth and once I see what happens, the doc *then* makes sense 06:56:47 Id hate to have to burn my brains out with C doing the same thing 06:57:27 I had a hard time finding the clock tree drawing in the STM docs a few weeks back. 06:59:56 are you using low power versions "L" ? 07:00:22 theyre a lot more complex than the "F" versions imho 07:02:35 Nope, using the F series. 07:02:54 then youre in for a surprise ;-) 07:03:32 I bought some STM32L chips recently including a Nucleo-L073 and everythings changed! 07:04:00 the same named registers are doing completely different things now 07:04:33 the low power additions mean a lot more options for power hence more config 07:05:29 here is a generic register pretty print 07:05:32 gpioa_moder. 07:05:32 GPIOA_MODER (read-write) $2AA80000 07:05:32 15|14|13|12|11|10|09|08|07|06|05|04|03|02|01|00 07:05:32 00 10 10 10 10 10 10 00 00 00 00 00 00 00 00 00 07:15:22 night all, thanks for the chat john_cephalopoda 07:16:05 Night, tp 07:30:39 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 07:38:48 I think the original designer of x86 had octal fetish. 07:41:03 x86 is a real virtual machine. 07:41:36 --- quit: ashirase (Quit: ZNC - http://znc.in) 07:41:53 IDK how to avoid it. 07:46:08 DKordic: do like I do. Write a small Forth runtime in .c (something that pretty much emulates the canonical dual stack machine in Stack Machines the New wave by Philp Koopman) and then target that. 07:46:34 ie, treat it like the legacy architecture it is by virtualizing it away 07:52:54 I am planning to port a VM to x86 to run Forth on top of. 08:24:41 I think it's fair to say that where my system is gravitating to as well - I have a set of "virtual machine operations" I call "portable instructions." Then primitives are implemented using those. 08:25:22 It's not a minimal set by any means, because I'm requiring that I have something like a "most efficient system" on both x86 and ARM, and to get that I need a bit more "expressiveness" in the portable instructions. But it's the same idea. 08:26:26 Practically speaking what this means is that in the meta-compileable system portable instructions are written using the assembler, then primitives are generated by invoking P.I.'s. Then the higher level definitions are done in the usual way. 08:27:03 The PI's are like macros - primitives don't CALL PI's - the PI's generate machine code into the primitives at compile time. 08:27:48 An alternative implementation would be to make the PI's executable, and they could then be tokenized or something. Or they could be used AS primitives. But either of those approaches would impair efficiency some. 08:27:50 KipIngram: do you have a list of those 'Portable Instructions' somewhere accessible on the 'Net? 08:28:11 Not yet, I'm kind of creating them as I work through implementing the primitives. I'll be happy to share when it's done though. 08:28:34 They are basically things like "store TOS to location addressed by SP," "increment SP by a cell," "decrement SP by a cell," etc. 08:28:46 If you really tear the Forth VM down to its atomic operations - that's the PI's. 08:29:12 I'm expecting to wind up with a few dozen of them. 08:29:12 good, because I am thinking about writing a bit about ?different implementation levels?. 08:29:39 J1 arch has about 32 iirc primitives or primitive instructions. 08:30:18 My system has a lot of primitives, because I kind of went nuts with "variations" on things. Like conditional return primitives for all kinds of different conditions, etc. 08:30:46 It's definitely not a "minimal porting effort" system, though the PI layer will help a lot because there are many fewer PIs than primitives. 08:30:51 the idea of the writing is that there would be quite stupidly simple smaller primitives that can be implemented everywhere but if speed is required then a less primitives that used those could be used. 08:30:56 I have like 150-200 primitives. 08:31:34 But with this current approach the primitive definitiosn will become portable, so it doesn't really matter how many there are. 08:31:41 I think I went in the complete opposite direction, I got the primitives down to 12-15 or so. 08:31:58 Yes, I've seen as few as eight, I believe. 08:32:12 It's definitely fertile intellectual territory. 08:33:02 what I have in mind is that those 150-200 primitves chould have two diffrent implementations. One in assembly, if required for speed, and one in composed out of more primitive operations. 08:33:57 those more primitive operations can then be ported first and you get a running system 08:34:27 if there are some slow parts then those higher level primitives can be reimplemented in assembly to be speedier 08:39:34 Oh, yes - I've thought of doing that. It would work particularly well with indirect threading where the CFA / PFA data are separate from the bodies. The PFA would be a POINTER to the body, which is how my system already is. 08:39:52 You'd set it up so that redefining a word re-uses the same CFA/PFA pair, and that would thus redefine all prior uses of the word too. 08:40:02 Then you'd write inefficient but portable definitions for as many primitives as possible. 08:40:10 And then just redefine the ones you needed to in assembly. 08:40:21 The system would immediately speed up as you did each redefinition. 08:40:59 Indirect threaded Forth is just pretty much perfect for such an approach. 08:42:02 I understand that having a pointer to the parameter field follow the CFA, rather than having the parameter field itself follow the CFA like in FIG, is slightly less efficient. But I think it brings some powerful advantages that more than make up for the efficiency loss. 08:42:15 It makes multiple entry points possible, for one thing. 08:42:20 well Subroutine Call threaded forths can also be changed in this way by overwriting the code of the word. 08:42:29 And the above-mentioned dynamic redefinition ability. 08:42:45 Yes, provided the new definition will fit. 08:42:59 But you could always overwrite with a call, which would almost certainly fit. 08:43:01 Or a jump. 08:43:28 It's just more "natural" in ITC, I think. 08:43:32 sure that is an issue but then you could overwrite with a call or jump or have padding in those words to give some room 08:44:51 Oh, and the PFA pointer approach made it a lot easier to implement CREATE / DOES> functionality. 08:45:02 I'd always struggeled with that on past systems - always felt like a kludge. 08:45:08 But this go round it was very straightforward. 08:45:22 from one topic to the next, and you just give me a good seque into that topic. 08:45:32 :-) 08:45:38 Happy to help... 08:46:00 I am trying to figgure out how to use defining words inside other words 08:46:36 Do you mean use defining words to make "higher level defining words"? 08:46:40 I know that CREATE or Like some kind of inheritance? 08:46:58 no, not some kind of inheritance but composition. 08:47:27 I kicked that around on paper for a while. I think I figured out a workable approach, but it wasn't particularly tidy and pleasing. 08:47:39 It didn't feel "done" to me. 08:48:02 Felt like there had to be something better still out there that I wasn't seeing. 08:48:28 I think the starting point is to say you want to be able to use any defining word in place of CREATE. 08:48:36 : foo create ... does> bar ; 08:48:46 : bam foo ... does> boom ; 08:49:04 And then you make that do something sensible. 08:49:05 what I am seeing is that there is a lack of a version of CREATE or Ok, that's a slightly different angle, I think. 08:50:20 because the only requirement that requires CREATE and A word created with bam would need to do the allocation specified in foo, then the allocation specified in bam, and then it's runtime would need to be "bar boom," I think. 08:51:12 Or maybe "boom bar"; not fully sure of that yet. 08:52:54 I guess it would be "bar boom," because the CREATE runtime (putting the address on the stack) is run before the "bar" action. 08:53:03 So it would need to be oldest to newest. 08:55:24 the forth I am most familiar with is an variant of eForth and it didnt have CREATE in it. 08:55:44 so I had to port it from FIG-Forth or some other forth I did not note down the name of 08:56:49 : CREATE TOKEN $,n OVERT ; IMMEDIATE 08:57:21 Wow - no CREATE? 08:57:28 That seems like a fundamental thing to me. 08:57:35 A basic building block. 08:58:08 the first called word in its defintion TOKEN is what is causeing my grief I think 08:58:37 What's it supposed to do? 08:58:50 Get a name from the input stream? 08:59:30 it takes from TIB (the Terminal Input Buffer) and space deliminated string and returns it ( c-addr len ) iirc 08:59:54 Ok, like WORD in some systems. 08:59:57 Or BL WORD. 09:00:16 it is pretty much BL WORD in functionality 09:00:51 no, not only that. It does PACK$ too. Damn. 09:01:04 What's PACK$? 09:01:33 PACK$ is what moves a string from TIB into another place, in this case the name part of the dictionary 09:01:49 I see. 09:02:42 FIG Forth did some short-cutty things in that area, like WORD would parse out the word and give it to you as a counted string at the location it would need to be at if it becomes a new word header. 09:02:48 (eForth has split dictionay, name part and code part) 09:03:09 That turned out to cause me some trouble given how I handle my memory allocation. 09:03:25 I don't just have "all of memory" lying out there in front of me the way FIG did. 09:04:25 So I had to have WORD put the stuff elsewhere, and then I do an extra copy if I want to make a header out of it, AFTER making sure I have the space in the current page to do that. 09:05:14 : TOKEN BL PARSE 31 MIN NP @ OVER - CELL- PACK$ ; 09:05:28 That's your CREATE def? 09:05:42 you saw it earlier 09:05:56 Oh, that's TOKEN. 09:05:57 Sorry. 09:05:59 Misread. 09:06:24 so I basically now looking how PARSE works again 09:07:01 In some systems PARSE just returns a pair of pointers that bracket the new word, in TIB. 09:07:15 In FIG it was called ENCLOSE. 09:07:27 yebb it does so in this one too only the latter pointer is not a pointer just a length 09:07:41 Ok. 09:07:47 But it doesn't move anything. 09:08:14 so it seems that I need a variant of TOKEN that does not have BL PARSE and takes instead such string_pointer&length pair 09:08:17 Sounds like it's setting you up for CMOVE, though. 09:09:01 that is what PACK$ does internally 09:16:14 heh thanks for being my rubber-ducky in this, it helped 09:24:37 :-) 09:24:41 My pleasure. 09:24:51 the need for this, the composition, arose from what I am doing with graphics. 09:25:02 I love this stuff - maybe it's a little weird having a programming language be a "hobby," but that's how it is for me and Forth. 09:26:05 basically pixmaps, bitmaps and transformers thereof are made by defining words. 09:26:06 Back when I worked for UT Austin I used to ride bikes at lunch with some of my coworkers. We had one guy in the group who was obsessed with the weight of his bike. 09:26:16 He had a nice Italian bike that weighed in at about 19 pounds. 09:26:24 That was really light in those days. 09:26:45 Anyway, at one point he dropped like $800 on a set of titanium bolts that would reduce it to a little over 18 pounds. 09:26:56 and they all have the same four 'methods' (selected via an control variable) pretty much how many implemented VALUEs and TO in other Forths 09:26:57 Now, you have to understand this guy was probably 20-30 pounds overweight... 09:27:13 We all thought he was kind of strange for doing that, but, it was his hobby. 09:27:48 oh, just about nine kilograms? 09:28:00 Just under, yes. 09:28:16 I imagine bikes are lighter now - this was like 25+ years ago. 09:28:23 heh, he might have been aiming at how light he could make it so it isnt as heavy to carry 09:28:29 Full carbon frames weren't even really a thing yet. 09:28:41 Though there were frames with carbon tubes and metal connections. 09:28:46 forget the carbon frame hype. 09:29:23 I had one of those (with the metal lugs). It was a nice bike, but I don't know if it was nice BECAUSE of the carbon tubes. 09:29:31 I just think it was well-engineered in general. 09:29:39 I know of a guy who makes RC model airplanes and such drones out of newspapers and that epoxy fiber plastic used in small fishing boats 09:29:52 Old glider planes were made out of welded metal tubes covered with fabric. Fixing it was trivial. 09:29:52 Oh, interesting. 09:29:58 Like paper machet? 09:30:25 naah, the paper was folded and tubed up to give initial structure 09:30:44 I see. 09:30:48 Clever. 09:31:22 the fiber plastic is then painted on in layers. The thing is basically painted into being basically 09:31:23 Anyway, we joked behind his back that he could have dieted for two weeks and dropped more weight from his bike/rider system. :-) 09:31:34 That's cool. 09:32:02 well, that is how my late uncle lengthened his fishing boat. 09:34:12 the issue is that the 'paint' is a bit nasty. It isnt dangerous or such but you must wear full sleeve throw away labgrade shirt or you will feel like you waded through a see of micro sized procupines 09:34:14 I don't know why that made me think of this, but I read somewhere that when they were assembling the SR-71 blackbirds they would carve mothballs into "holder jigs" and use them to hold parts in place while they got the neighboring/supporting parts in place as well. Then the mothballs "evaporated." 09:35:06 pretty much the same with water or alcahole soluable support materials in 3d printing. 09:35:18 Yes. 09:37:08 hell in addetive manifacturing using lazer or solar sintering the unfused powder/sand is the support material. But then you have to have escape holes designed into the part 10:22:19 tabemann: also the real solution in that case is that the Foo, Bar, Baz, and Quux variants should all be distinct message types :P 10:35:48 remexre: except what about when you want to make tuples of multiple such values 10:36:09 are you going to make a separate message type for each permutation? 10:39:41 tabemann: probably, or newtype the tuple as a whole 10:39:57 what I mean is this 10:40:03 let's say you have a vector of 10:40:24 [(x, Foo), (y, Bar), (z, Baz)] 10:40:29 and a vector of 10:40:53 [(x, Quux), (y, Foo), (z, Bar)] 10:41:19 this is even less tractable since vectors are (practically-speaking) unlimited in length 10:41:25 so you can't cover every permutation 10:43:08 oh, yeah 10:43:22 hm 10:49:27 I still feel like the right option is to just have tooling to smooth the upgrade; in general, you still need to care about the semantics of the upgrade anyway 10:51:25 (also, sorry for spotty responses, internet keeps dropping out) 10:53:23 to me, the key thing is that in using static typing you give up incremental updates 10:53:39 e.g. with Cloud Haskell you can't do that 11:05:13 --- quit: kori (Ping timeout: 244 seconds) 12:07:35 --- quit: gravicappa (Ping timeout: 258 seconds) 12:23:39 --- join: andrei-n (~andrei-n@173.155-67-87.adsl-dyn.isp.belgacom.be) joined #forth 12:43:06 back; I still see this as an issue tooling can solve 12:43:49 --- join: mtsd (~mtsd@94-137-100-130.customers.ownit.se) joined #forth 13:24:16 back 13:24:54 --- quit: andrei-n (Remote host closed the connection) 14:08:20 --- quit: mtsd (Quit: Leaving) 14:40:03 --- quit: dys (Ping timeout: 268 seconds) 15:18:25 --- quit: john_cephalopoda (Quit: WeeChat 2.3) 15:18:43 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth 15:34:17 --- join: kori (~kori@2804:14c:85a3:81b8::1000) joined #forth 15:34:17 --- quit: kori (Changing host) 15:34:17 --- join: kori (~kori@unaffiliated/kori) joined #forth 15:35:47 anyone have ideas on factoring https://github.com/remexre/stahlos/blob/master/src/amd64/forth/init.fs#L34-L51 to be less huge? 15:49:50 I've written way huger Forth code than that :P 15:51:32 L 15:51:47 I'm trying to make this nicer from the last time I wrote this 15:51:58 last time I was using higher-order words / passing XTs to everything 15:52:02 and it was pretty awful 15:55:11 fg 16:04:00 --- join: rdrop-exit (~markwilli@112.201.174.189) joined #forth 16:06:32 c[] Good morning Forthists 16:14:40 --- quit: john_cephalopoda (Ping timeout: 252 seconds) 16:18:26 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth 17:15:19 Just read on CLF that the EuroForml 85 papers have been scanned and uploaded 17:15:29 http://www.complang.tuwien.ac.at/anton/euroforth/ef85/papers/ 18:19:43 --- join: dave0 (~dave0@069.d.003.ncl.iprimus.net.au) joined #forth 18:20:21 hi 18:21:07 Hi dave0 18:21:23 hi rdrop-exit 18:42:00 --- quit: cheater (Ping timeout: 272 seconds) 18:43:57 --- join: cheater (~cheater@unaffiliated/cheater) joined #forth 19:56:23 hey guys 20:08:26 --- quit: dddddd (Remote host closed the connection) 20:08:57 --- quit: dave0 (Quit: dave's not here) 20:21:08 hi tabemann 20:28:20 --- quit: rdrop-exit (Ping timeout: 245 seconds) 20:29:30 --- join: rdrop-exit (~markwilli@112.201.174.189) joined #forth 20:37:10 Hi Forth Fanatics :) 20:43:33 Hi tp :) 20:45:23 I'm having a great day today, last 5 hrs gardening at our community vegie garden, now getting back to some Forth stuff I left at midnightish last night 20:45:47 Excellent 20:45:54 and lunch is cooking, frest stirfry vegies and kangaroo 20:46:09 after 5 hrs labor, Im starving! 20:47:01 I'm perusing the 1985 EuroForml proceedings which were uploaded earlier today 21:22:43 --- join: gravicappa (~gravicapp@h109-187-239-230.dyn.bashtel.ru) joined #forth 22:26:29 --- join: dys (~dys@tmo-104-223.customers.d1-online.com) joined #forth 22:47:44 --- quit: rdrop-exit (Ping timeout: 272 seconds) 23:25:21 --- join: rdrop-exit (~markwilli@112.201.174.189) joined #forth 23:30:48 --- join: xek_ (~xek@apn-31-0-23-202.dynamic.gprs.plus.pl) joined #forth 23:52:07 --- quit: dys (Ping timeout: 248 seconds) 23:57:03 --- join: john_metcalf (~digital_w@host31-54-142-171.range31-54.btcentralplus.com) joined #forth 23:59:18 --- join: andrei-n (~andrei-n@173.155-67-87.adsl-dyn.isp.belgacom.be) joined #forth 23:59:59 --- log: ended forth/19.07.07