00:00:00 --- log: started forth/21.04.09 00:15:03 --- quit: wineroots (Remote host closed the connection) 00:34:12 --- join: f-a joined #forth 01:02:40 --- quit: crest (*.net *.split) 01:02:40 --- quit: guan (*.net *.split) 01:02:40 --- quit: joe9 (*.net *.split) 01:02:40 --- quit: ovf (*.net *.split) 01:02:41 --- quit: djinni (*.net *.split) 01:02:41 --- quit: crc (*.net *.split) 01:02:41 --- quit: nihilazo (*.net *.split) 01:02:43 --- quit: cantstanya (*.net *.split) 01:02:43 --- quit: _whitelogger (*.net *.split) 01:02:44 --- quit: ecraven (*.net *.split) 01:02:44 --- quit: dave0 (*.net *.split) 01:02:45 --- quit: xybre (*.net *.split) 01:02:46 --- quit: jyf (*.net *.split) 01:02:46 --- quit: gravicappa (*.net *.split) 01:02:46 --- quit: boru (*.net *.split) 01:02:46 --- quit: lispmacs (*.net *.split) 01:02:46 --- quit: Kumool (*.net *.split) 01:02:46 --- quit: xek (*.net *.split) 01:02:46 --- quit: lispmacs[work] (*.net *.split) 01:02:46 --- quit: veltas (*.net *.split) 01:02:47 --- quit: bluekelp (*.net *.split) 01:02:47 --- quit: phadthai (*.net *.split) 01:02:47 --- quit: dnm (*.net *.split) 01:02:47 --- quit: jimt[m] (*.net *.split) 01:02:47 --- quit: a3f (*.net *.split) 01:02:47 --- quit: KipIngram (*.net *.split) 01:02:48 --- quit: siraben (*.net *.split) 01:02:48 --- quit: krjt (*.net *.split) 01:02:48 --- quit: mjl (*.net *.split) 01:02:48 --- quit: f-a (*.net *.split) 01:02:48 --- quit: MrMobius (*.net *.split) 01:02:49 --- quit: rixard (*.net *.split) 01:02:49 --- quit: Keshl (*.net *.split) 01:02:49 --- quit: klys (*.net *.split) 01:02:49 --- quit: swineflu (*.net *.split) 01:02:49 --- quit: tabemann (*.net *.split) 01:02:49 --- quit: rann (*.net *.split) 01:02:49 --- quit: lonjil (*.net *.split) 01:02:50 --- quit: mstevens (*.net *.split) 01:02:50 --- quit: jn__ (*.net *.split) 01:02:50 --- quit: fiddlerwoaroof (*.net *.split) 01:02:50 --- quit: kiedtl (*.net *.split) 01:02:50 --- quit: Zarutian_HTC (*.net *.split) 01:02:50 --- quit: lchvdlch_ (*.net *.split) 01:02:50 --- quit: APic (*.net *.split) 01:02:51 --- quit: spoofer (*.net *.split) 01:02:51 --- quit: nitrix (*.net *.split) 01:02:52 --- quit: proteusguy (*.net *.split) 01:02:52 --- quit: cp- (*.net *.split) 01:02:52 --- quit: remexre (*.net *.split) 01:02:52 --- quit: Vedran (*.net *.split) 01:02:53 --- quit: tolja (*.net *.split) 01:02:53 --- quit: ornxka (*.net *.split) 01:02:54 --- quit: koisoke_ (*.net *.split) 01:02:54 --- quit: cmtptr (*.net *.split) 01:02:54 --- quit: rprimus (*.net *.split) 01:02:54 --- quit: X-Scale (*.net *.split) 01:02:54 --- quit: Lord_Nightmare (*.net *.split) 01:02:54 --- quit: jedb (*.net *.split) 01:02:54 --- quit: shmorgle (*.net *.split) 01:02:55 --- quit: jess (*.net *.split) 01:02:55 --- quit: TangentDelta (*.net *.split) 01:02:55 --- quit: dzho (*.net *.split) 01:07:25 --- join: koisoke_ joined #forth 01:07:25 --- join: joe9 joined #forth 01:07:25 --- join: guan joined #forth 01:07:25 --- join: crest joined #forth 01:07:25 --- join: remexre joined #forth 01:07:25 --- join: cp- joined #forth 01:07:25 --- join: proteusguy joined #forth 01:07:25 --- join: djinni joined #forth 01:07:25 --- join: crc joined #forth 01:07:25 --- join: nihilazo joined #forth 01:07:25 --- join: dave0 joined #forth 01:07:25 --- join: xybre joined #forth 01:07:25 --- join: gravicappa joined #forth 01:07:25 --- join: boru joined #forth 01:07:25 --- join: lispmacs joined #forth 01:07:25 --- join: Kumool joined #forth 01:07:25 --- join: xek joined #forth 01:07:25 --- join: lispmacs[work] joined #forth 01:07:25 --- join: veltas joined #forth 01:07:25 --- join: bluekelp joined #forth 01:07:25 --- join: phadthai joined #forth 01:07:25 --- join: shmorgle joined #forth 01:07:25 --- join: jess joined #forth 01:07:25 --- join: TangentDelta joined #forth 01:07:25 --- join: dzho joined #forth 01:07:25 --- join: jyf joined #forth 01:07:25 --- join: cmtptr joined #forth 01:07:25 --- join: rprimus joined #forth 01:07:25 --- join: X-Scale joined #forth 01:07:25 --- join: Lord_Nightmare joined #forth 01:07:25 --- join: jedb joined #forth 01:07:25 --- join: mjl joined #forth 01:07:25 --- join: krjt joined #forth 01:07:25 --- join: KipIngram joined #forth 01:07:25 --- mode: weber.freenode.net set +vovv proteusguy crc crc KipIngram 01:07:25 --- join: a3f joined #forth 01:07:25 --- join: dnm joined #forth 01:07:25 --- join: nitrix joined #forth 01:07:25 --- join: kiedtl joined #forth 01:07:25 --- join: fiddlerwoaroof joined #forth 01:07:25 --- join: jn__ joined #forth 01:07:25 --- join: mstevens joined #forth 01:07:25 --- join: lonjil joined #forth 01:07:25 --- join: tabemann joined #forth 01:07:25 --- join: klys joined #forth 01:07:25 --- join: Keshl joined #forth 01:07:25 --- join: rixard joined #forth 01:07:25 --- join: swineflu joined #forth 01:07:25 --- join: MrMobius joined #forth 01:07:25 --- join: f-a joined #forth 01:07:25 --- join: spoofer joined #forth 01:07:25 --- join: APic joined #forth 01:07:25 --- join: lchvdlch_ joined #forth 01:07:25 --- join: Zarutian_HTC joined #forth 01:07:28 --- join: _whitelogger joined #forth 01:07:28 --- join: ecraven joined #forth 01:07:33 --- quit: X-Scale (Ping timeout: 240 seconds) 01:08:37 --- join: cantstanya joined #forth 01:11:05 --- join: rann joined #forth 01:11:29 --- join: ovf joined #forth 01:12:22 --- join: X-Scale joined #forth 01:20:26 --- quit: ovf (Changing host) 01:20:26 --- join: ovf joined #forth 01:20:26 --- quit: rann (Changing host) 01:20:26 --- join: rann joined #forth 01:34:51 --- quit: jess (Quit: Changing server) 01:34:51 --- join: jess joined #forth 01:34:51 --- quit: clog (Ping timeout: 260 seconds) 01:34:51 --- log: stopped forth/21.04.09 01:34:58 --- log: started forth/21.04.09 01:34:58 --- join: clog joined #forth 01:34:58 --- topic: 'Forth Programming | do drop >in | logged by clog at http://bit.ly/91toWN backup at http://forthworks.com/forth/irc-logs/ | If you have two (or more) stacks and speak RPN then you're welcome here! | https://github.com/mark4th' 01:34:58 --- topic: set by mark4!~mark4@cpe-75-191-74-68.triad.res.rr.com on [Sun Feb 28 11:55:01 2021] 01:34:58 --- names: list (clog jess X-Scale ovf rann cantstanya djinni @crc nihilazo dave0 xybre gravicappa boru lispmacs Kumool xek lispmacs[work] veltas bluekelp phadthai shmorgle TangentDelta dzho jyf cmtptr rprimus Lord_Nightmare jedb +proteusguy cp- remexre crest guan joe9 mjl krjt +KipIngram a3f dnm nitrix Zarutian_HTC lchvdlch_ APic spoofer f-a MrMobius swineflu rixard Keshl klys tabemann lonjil mstevens jn__ fiddlerwoaroof kiedtl koisoke_ +mark4 rpcope dys pareidolia) 01:34:58 --- names: list (_whitelogger ecraven) 01:37:18 --- join: siraben joined #forth 01:47:10 --- join: jimt[m] joined #forth 01:49:26 --- join: Vedran joined #forth 01:49:26 --- join: tolja joined #forth 01:49:26 --- join: ornxka joined #forth 02:25:06 --- join: sts-q joined #forth 02:35:00 --- quit: f-a (Quit: leaving) 03:21:13 --- join: f-a joined #forth 03:52:52 --- quit: f-a (Quit: leaving) 04:39:09 --- join: tech_exorcist joined #forth 05:29:04 --- quit: lchvdlch_ (Ping timeout: 268 seconds) 05:30:34 --- join: lchvdlch joined #forth 05:35:03 --- quit: lchvdlch (Ping timeout: 240 seconds) 05:36:14 --- join: lchvdlch joined #forth 05:39:43 --- join: f-a joined #forth 05:54:13 --- quit: Zarutian_HTC (Read error: Connection reset by peer) 05:54:32 --- join: Zarutian_HTC joined #forth 06:06:17 --- quit: f-a (Quit: leaving) 06:10:28 --- join: lchvdlch_ joined #forth 06:11:03 --- quit: lchvdlch (Ping timeout: 240 seconds) 06:23:44 --- join: f-a joined #forth 06:27:48 --- quit: f-a (Client Quit) 06:40:48 --- join: f-a joined #forth 06:43:17 --- quit: cantstanya (Remote host closed the connection) 06:49:16 --- quit: f-a (Quit: leaving) 07:34:14 --- join: f-a joined #forth 08:10:54 --- quit: rixard (Read error: Connection reset by peer) 08:17:32 --- join: rixard joined #forth 08:18:49 --- quit: tech_exorcist (Remote host closed the connection) 08:19:48 --- join: tech_exorcist joined #forth 09:12:17 --- quit: Zarutian_HTC (Ping timeout: 268 seconds) 09:36:51 --- join: Zarutian_HTC joined #forth 10:37:07 --- quit: gravicappa (Ping timeout: 265 seconds) 10:38:42 --- join: gravicappa joined #forth 10:40:06 --- quit: tech_exorcist (Remote host closed the connection) 10:40:33 --- join: tech_exorcist joined #forth 11:22:43 xybre: I agree. 11:31:02 --- quit: f-a (Read error: Connection reset by peer) 11:33:46 --- join: f-a joined #forth 11:47:30 --- quit: dave0 (Quit: dave's not here) 12:11:48 siraben: Did you read this? https://www.cantorsparadise.com/the-unparalleled-genius-of-john-von-neumann-791bb9f42a2d 12:49:37 --- quit: shmorgle (Quit: [TalkSoup] via NEXTSPACE) 12:52:21 Oh, nice article. Thanks for sharing. 13:05:29 It was on hackernews the other day KipIngram 13:11:48 This may be interesting to you all: https://www.dawn-lang.org/posts/introducing-dawn-(part-1)/ 13:15:19 It's interesting but I have no idea how useful or real it is 13:15:48 Who wrote this? 13:16:01 No copyright or author 13:16:23 is there a `pick' implementation in forth somewhere handy that I could copy and paste? 13:17:05 : pick 3 << sp@ + @ ; 13:17:08 or something like that. 13:17:22 Depends on exactly how your sp@ works, which direction your stasck goes, etc. 13:17:30 And 3 << is for 64-bit cells. 13:18:11 You might need a 1+ or 1- in there to get exactly what you want, just before the 3 <<. 13:18:51 Or do you want an implementation in standard forth? 13:19:00 :-) 13:19:21 whatever is easiest. FlashForth doesn't have pick but it would be handy right now 13:19:47 Easiest/fastest is KipIngram's suggestion 13:19:52 I don't have pick in mine, but I have something else that gives me access to the deep stack. 13:19:59 Standard forth is hard and slow 13:20:01 It DOES come in handy now and then. 13:20:10 That's basically what PICK does 13:20:39 --- part: f-a left #forth 13:20:54 cell . 2 ok 13:21:02 lispmacs[work]: Hard-core Forthwrights will tell you that if you need pick you're doing something wrong. I see where they're coming from, but I think it's true only a large fraction of the time, with some exceptions. 13:21:15 Oh, then 1 << 13:21:28 Or 2* if you have it. 13:21:50 KipIngram: I imagine there wright, but I didn't want to rewrite the other 8 lines of code I already wrote for a different forth 13:21:58 *they're right 13:22:45 KipIngram: so, : pick 1 << sp@ + @ ; ? 13:23:08 I think they're "mostly right." But sometimes you just have a set of values that you need all of. I find that to be the case in QUERY/EXPECT, especially after I add command line history. You've got six or seven things you need to juggle. 13:23:37 I don't consider myself "hard-core", and I think "PICK" is legit, use it all you want. 13:23:47 If it makes your code shorter then do it 13:23:52 I created a "stack frame" system, that lets me access deep stack with words that always point to the same place (rather than move around as the stack pointer changes). 13:25:38 FlashForth does not have a << 13:25:56 Maybe with a different name? lshift or something? 13:25:56 but does have a 2* 13:26:09 Ok - well, that's the best one for you anyway. Shortest. 13:26:12 there is an lshift 13:26:27 Ok. << and >> are just my names for the shift operations. 13:26:38 * KipIngram likes symbols. 13:27:59 : pick 2* sp@ + @ ; appears to be working 13:29:03 kiedtl: Is that your language? 13:29:40 Oh, no, it's the OP from this discussion: https://lobste.rs/s/rqc2sj/introducing_dawn_part_1 13:37:27 lispmacs[work]: Good stuff. 13:37:58 Most implementations see to have their data stacks grow downward. 13:38:11 I guess because that's how most microprocessor stacks work. 13:38:26 I go down with data and up with return, toward each other. 13:38:48 It works better that way generally, it means that sp[0] is the current item, sp[1] is next, etc 13:38:56 I fill that range at initialization with 0xA7; that way I can inspect the range later to see how far my stacks have grown. 13:39:03 It's my reason to not change the direction 13:39:15 veltas: makes sense. 13:39:47 I never really thought about it - I just did what I Found already out there. :-) 13:40:05 But it does make accessing the stack like an array more intuitive. 13:40:16 I am one of those people that likes to understand *why* and not just *how* 13:40:51 :-) Me too, usually. Just didn't find this one that interesting at the time. But I totally agree. 13:40:57 "more intuitive" and more performant probably, on older architectures 13:41:07 You do better work that way. 13:41:24 I think it's a legitimate approach 13:41:40 It is. 13:42:21 It's one of the reasons I don't exactly care for the very strong "library based" approach of typical programming. Stiching together work others did that you don't really understand - that just can't lead to a "best" solution. 13:42:58 It's one of the things that draws me to Forth in the first place - that I can *totally* understand the whole thing. 13:43:25 I'm the same way with my hardware. I learned to do FPGA design back when the only approach was to draw a schematic, with gates and registers and so on. 13:43:46 I don't care for the modern "behavioral" Verilog approach that trusts a synthesizer to create the logic for you. 13:44:08 Even when I use Verilog, I still use it "structurally" and call out the circuit item by item. 13:46:39 I prefer schematics, though - just the shape of the circuit on the page conveys meaning. 13:46:53 You can see things like reconvergent fanout and so on. 13:51:41 --- quit: gravicappa (Ping timeout: 252 seconds) 14:25:15 Lack of proper library support means it's annoying to iterate on my own ideas and reuse my own projects without just copying and pasting, so while ecosystems like Node are full of oneliner libraries, I feel like a good balance can be struck. 14:27:26 --- join: Zarutian_HTC1 joined #forth 14:27:31 --- quit: Zarutian_HTC (Read error: Connection reset by peer) 14:31:14 I just looked at Dawn, it sure looks like my forth-like VM blacklight, semantically. 14:31:43 The creation of inline stacks is pretty fun 14:33:52 Dawn the Stanford project? 14:34:07 Is it? 14:34:42 https://dawn.cs.stanford.edu/ 14:34:46 --- quit: Lord_Nightmare (Quit: ZNC - http://znc.in) 14:34:59 I'm not previously familiar with it - that's just what I found when I searched for "Dawn programming." 14:35:17 How does an "inline stack" work? 14:35:29 No, the one that was linked earlier in the backlog, the author seems to be based in Texas 14:35:48 Ok - sorry, then - false lead. 14:35:53 https://www.dawn-lang.org/posts/introducing-dawn-(part-1)/ and https://github.com/dawn-lang/dawn-phase1 14:36:38 I'm not 100% sure how Dawn does it, I haven't looked at the source yet, but in blacklight there's a few different ways of doing "inline stacks". 14:36:56 --- join: Lord_Nightmare joined #forth 14:37:44 Firstly, you can switch to a fresh stack at any time using $new and then kill that stack and return to the previous one with $drop. 14:38:05 Oh man. Forth, Haskell, C, and Rust. 14:38:12 Ok, that's kind of interesting. 14:38:34 Is the old one completely unavailable while you've got the new one? 14:38:59 I'm trying to see why that's better than just growing the one stack taller. 14:39:02 That wasn't my impression 14:39:08 It's decoupled from any idea of a function, and you can still reference the previous stack to store your results, or even get a reference to the "metastack" directly that contains all the others 14:39:11 that the old stack is unabailable 14:39:17 what xybre 14:39:19 said 14:39:29 Ok. 14:39:41 So that means your instructions have to have a stack specifier in them. 14:39:54 Sort of like register specifiers in normal CPU instructions. 14:40:03 You lose implicit addressing. 14:40:54 Hmm. Kinda. There's an implicit "current" stack that all operations focus on. Then there's a small collection of additional bytecodes which refer to the previous or meta stacks. 14:41:19 This is ever so slightly like what my stack frames do. I don't crate a new stack, but I can access items in the old stack in a uniform way, and you can get back to it cleanly at the end. 14:42:17 And store results in it. 14:43:31 Yeah it's a lot like a stack frame, but there's no function call necessary and instructions continue being read from the same input stream. A tactic I use is like drop into a new stack, do a bunch of stuff and push the result to the previous stack, then drop. So there's only one "deallocation" and less stack shuffling. 14:43:32 Note, this is more of a general-purpose concatenative language, not an actual FORTH implemented in assembly for low-level stuff. 14:43:46 I just load a register with the stack pointner value when I open the frame, and then I can access relative to that register. And when I close the frame it whacks the stack back to that point, and also n items further, with n passed to the close frame word. 14:44:00 kiedtl: Yeah and same for blacklight. I can't speak to the design of Dawn. 14:44:10 Yes, that makes sense. 14:44:25 :120 14:44:27 oops 14:44:45 It's kind of handy to not have to worry about a completely correct cleanup. 14:45:10 I've fantasized about implementing a subset of blacklight in an FPGA. But it is significantly more complex than a real Forth. 14:45:12 And as you pointed out, it's more efficient than a bunch of drops. 14:46:52 I have a second set of words that do a frame on both stacks. That lets me return all the way through a deep set of calls to a point higher up. 14:47:29 Yeah it's both cleaner for a memory management and a coding perspective. I think it can be implemented closer to the metal whle still having that high level safety by using stack guards and checks, which would only be needed on operations which drop values anyway. 14:47:53 That one is {| ... |}, and there can be other |} instances down in the code in between. 14:47:59 Oh that's cool, like a stack break to label (or goto) 14:48:15 It returns the data stack to its original state, except for TOS. 14:48:34 Yeah that's cool, I dig it 14:48:38 TOS is the way I pass a result back up. Since it's cached in a register anyway, it was clean to implement that. 14:48:55 Yeah I got it, that's clever 14:49:33 I use that in FIND. I'm way down at the bottom of a bunch of nested loops, searching through a list of vocabularies and each those a list of words and each of those a list of characters. 14:49:51 Then suddenly I find a match. So I just |} all the way back out. 14:50:50 When I was implementing an array type I was trying to reuse some code and realized I could drop into a new stack and return it casted to the array type. This meant there was no custom syntax inside. So ( 1 2 3 ) give an array of 3 elements like you'd expect, but ( 1 2 3 add ) returns an array of 2 elements of 1 and 5. I dunno why but I love it. 14:51:07 Not only does it improve performance (a little), but it simplifies the codeing of those loops, because they don't have to be able to carry a successful result all the way back up through themselves. 14:51:51 xybre: That's very cool seeming. 14:53:26 That's a cool stackified long return with |}. I don't quite know what to call it, but I totally see the use case. 14:57:56 Another neat thing, not really stack-related, is that blacklight is a VM that can disassemble it's own bytecode back into mnemonic symbols, modify them and reassemble them back into bytecodes. 15:01:49 I think I only got that working a month or so ago. Felt great. I should still do more testing. 15:03:17 --- nick: Zarutian_HTC1 -> Zarutian_HTC 15:33:36 I don't know what to call it either, really. I guessit's a little like setjmp / longjmp in C, but I'm not really sure. 15:35:21 Yeah it sounds like it. What is your project that implements it? 15:38:09 It's just the Forth I'm currently working on, in assembly with nasm. 15:38:18 I haven't put it up anywhere yet. 15:55:02 --- quit: Zarutian_HTC (Read error: Connection reset by peer) 15:55:19 --- join: Zarutian_HTC joined #forth 16:37:44 --- join: WQX joined #forth 16:43:03 hello i'm new in forth, could someone tell me how do i declare an matrix of floating points using gforth? 16:46:00 Forth is a typeless language. It deals with integers, which can be either values or addresses, and has some support for shorter word lengths. You can allocate RAM for a matrix with the word ALLOT. To treat it as a matrix, you have to do all of your own addressing calculations and so on. Forth has no native "subscripting" capability. 16:46:35 There is usually a consant called CELL that is an integer specifying bytes per cell, so you can multiply by that in calculating the right address of an entry. 16:46:53 You decide whether to store by rows or columns, and pretty much everything else. 16:47:26 So to declare an NxM floating point matrix, let's say you're using 64-bit floats (8 bytes), you'd do 16:47:53 CREATE ARRY_NAME N M * 8 * ALLOT 16:49:21 Then when you execute ARRAY_NAME you get the base address of the array on the stack. You'd then calculate the offset to the i, j -th entry and add to that. 16:49:38 Then you have a memory address you can store to or fetch from. 16:49:58 In other words, all the stuff the compiler usually does for you. 16:50:23 You can write words to "sugar coat" those calculations in some sort of syntax if you like. 16:51:15 Forth even gives you a more sophisticated capability where you could arrange to be able to say 16:51:19 i j ARRAY_NAME 16:51:44 and wind up with the address of that cell on the stack. That uses a facility called CREATE / DOES>, and it's something of an advanced topic that I won't try to describe here. 16:52:12 But if you look that up (CREATE / DOES>) you can learn how it works - that's just one example of what you cna do with it. 16:54:34 KipIngram: thank you very much, i will study a little more about the function (CREATE / DOES>) 17:00:36 You bet. It's an interesting feature of the language, and is an important part of being able to inject pretty much arbitrary syntax into your application. 17:01:10 The CREATE part will be very similar to what I called out - that' where the memory actually gets allocated. The DOES> part specifies what the word does when it's executed, so you put your address calculation there. 17:01:47 --- quit: spoofer (Read error: Connection reset by peer) 17:02:12 --- join: spoofer joined #forth 17:02:55 can i also read and write numbers from a txt or csv file using forth? 17:06:02 Almost all Forths will give you a way to do this, but it system dependent. When it was first created Forth didn't run under any operating system - it ran as the bare metal software of the system, and it managed disk space in a different way. As Forths have been implemented to run under OS supervision later on, each one has generally provided some sort of file access tools. I'm sure GForth has this, but I'm 17:06:03 not familiar with the details. 17:06:12 You'll find GForth offers a way to do practically anything. 17:06:27 It's sort of a "kitchen sink" Forth. 17:12:52 Out of curiosity, what is your application, WQX? Forth is not really the first language that comes to mind for manipulating floating point matrices and vectors and accessing text files. :-) 17:33:38 KipIngram: I agree, I wanted to implement an algorithm to calculate the inverse of a matrix, I work a lot with numerical methods and computational mathematics, in fact I found the language interesting and wanted to learn a little more about it and try to apply the forth in this area. I heard it said that the forth has the advantage of having an excellent performance and so I might be able to gain a certain performance in my calculations. 17:33:38 I apologize for my horrible English, I don't speak English very well 17:36:26 umm, you're probably better off working in Julia 17:36:41 if you want to do that kind of thing, Julia is what I'd suggest TBH 17:37:22 (Julia is kind of what'd you get if you crossed Python with Fortran) 17:37:45 (and made Common Lisp be the godparent) 17:39:19 about Forth, Forth is better for applications where direct access to the hardware is needed 17:39:34 yes, KipIngram was talking about OS-hosted Forths like gforth 17:39:44 but Forth is particularly excellent for embedded applications 17:39:49 WQX 17:41:49 tabemann: but what about performance? forth has a greater speed than julia right? 17:42:16 gforth is approximately 20% as fast as C 17:42:41 Julia is basically one of the fastest high level languages there are 17:42:55 note that Julia is compiled to native code at runtime 17:43:55 traditionally Forths use something called "indirect threading" which, TBH, is quite slow, but some newer Forths such as Mecrisp-Stellaris and my zeptoforth (shameless plug) compile directly to native code 17:46:43 just checked, and gforth uses either direct-threading/indirect-threading hybrid or plain indirect-threading depending on how one configures it 17:47:07 whereas Mecrisp-Stellaris and my zeptoforth are subroutine threading/native code inlining 17:47:31 they're still slower than C, though, due to the need to juggle the stack around 17:50:14 "tabemann: gforth is approximately 20% as fast as C" that's what motivated me to study forth, I tried to study using Julian V. Noble's book (Scientific Forth, 1992), but the version of forth that is used in the book is quite different from gforth 17:52:08 sorry, but what is TBH? 17:52:43 my recommendation if you want to use Forth is to build up a layer of primitives on which one can build one's code 17:52:48 TBH = to be honest 17:55:30 WQX: Forth is unlikely to exceed the speed of C or a similar language in a calculation like that. And I suspect you won't find any extensive numeric libraries in Forth, so you will have to implement your own algorithms. But it sounds like that may be what you want to do anywy. 17:56:15 tabemann: but in this case, comparing the performance c, gforth, julia, which one would be the fastest? 17:57:00 I would expect C to be the fastest. But it's hard to say, because often in a language like Julia the actual numerical routines in a library may be C based. That's often the case in Python. 17:57:37 "KipIngram: WQX: Forth is unlikely to exceed the speed of C or a similar language in a calculation like that. And I suspect you won't find any extensive numeric libraries in Forth, so you will have to implement your own algorithms. But it sounds like that may be what you want to do anywy." yes 17:57:39 The language itself won't keep up with C at all, but the numpy library used in Python has huge C content, so once you call a compute intensive algorithm like, say, LU factorization you're then basically running C. 17:58:21 So if your code spends like 99% of its time in those numeric libraries, then overall the speed difference between C and Python can become negligible. 17:58:51 But if you are writing your own algorithms then you'd never want to write them in Python if you're interested in performance. 17:59:03 Forth is very high performance for an interactive language. 17:59:29 You can't really sit down and just "type C" at a computer, but you can sit down and type Forth at it. 18:00:05 back 18:01:08 Julia is faster than Python, but Python probably has more extensive numerics libraries than Julia 18:01:29 (Python is interpreted, while Julia is compiled to native code at runtime) 18:01:45 but as KipIngram says, that doesn't matter 18:02:03 because your numerics libraries will almost certainly written in C whether you're using Python or Julia 18:02:10 *be written 18:02:53 if you opt for Forth, you'll certainly have less performance than C numerics libraries called from Python or Julia 18:03:12 furthermore, you'll have to do all the work of writing everything by yourself 18:06:29 truth 18:06:52 --- quit: tech_exorcist (Quit: tech_exorcist) 18:19:54 KipIngram & tabemann: I thank you very much for clarifying my doubts, you helped a lot 18:29:21 Good luck with your work, WQX. 18:36:05 --- join: boru` joined #forth 18:36:08 --- quit: boru (Disconnected by services) 18:36:10 --- nick: boru` -> boru 18:45:00 KipIngram: thanks 18:52:33 --- quit: Zarutian_HTC (Ping timeout: 260 seconds) 18:52:46 --- join: Zarutian_HTC joined #forth 19:22:43 isnt there some kind of interpretted C repl out there? I remember hearing about this once 19:22:51 cint maybe 19:24:23 I would assume that some kind of interpreted C repl'd almost certainly be slower than a Forth REPL 19:24:34 because a Forth REPL is like as simple a REPL as you can get 19:32:37 --- part: WQX left #forth 19:33:12 --- join: dsmcfarl joined #forth 19:39:21 I'd think so too. 19:42:08 hmm maybe so. i think cint is all interpretted anyway so not fast to begin with 19:55:20 --- quit: sts-q (Ping timeout: 240 seconds) 19:59:46 --- join: sts-q joined #forth 20:03:39 But it could still be good to use in the early phases of developing something. 20:04:42 I've come to believe that one of Forth's advantages is that heavy factoring has low function call overhead. You can factor factor factor in C too, but you get parameter passing overhead at every stage. With Forth there's just the call and the return, and nothing else. 20:04:54 Though I guess you could structure an app using global variables. 20:05:01 And not have parameters. 20:06:33 --- quit: Zarutian_HTC (Ping timeout: 240 seconds) 20:08:50 depending on your (micro)architecture C can suck less at this too though; afaik, the aarch64 ABI on a CPU with reg renaming and a deep enough return addr prediction stack makes factoring pretty cheap 20:10:18 largely because they make the imo very reasonable choice to make returns and params the same, and because aarch64 can load/store two registers per instruction 20:18:32 --- join: Zarutian_HTC joined #forth 20:21:17 That sounds reasonable. I don't really know exactly what the overhead is. It just seemed to me that having to build a big stack frame for a function call, only to have that function do the same thing again after a very small amount of code, would get slow on you. But it seems like there should be ways to avoid that. 20:22:01 When I was playing with a Forth processor in an FPGA, I managed to get it setup so that the returns were free (in terms of time). 20:22:25 I never actually built and ran that, though - it was only on paper. 20:23:03 This seems to have a C repl: https://github.com/jpoirier/picoc 20:23:12 But I had the hardware stack and the 32 opcodes encoded and implemented so that there were only two gate delays between flip flop output and flip flop input. 20:24:01 It should have easily managed 100 MHz. 20:24:22 Maybe 150. 20:47:48 --- join: jedb_ joined #forth 20:48:52 --- quit: jedb (Read error: Connection reset by peer) 20:52:46 --- join: jedb__ joined #forth 20:55:00 --- quit: jedb_ (Ping timeout: 240 seconds) 21:17:32 --- quit: tabemann (*.net *.split) 21:17:32 --- quit: lonjil (*.net *.split) 21:17:32 --- quit: mstevens (*.net *.split) 21:17:32 --- quit: jn__ (*.net *.split) 21:17:32 --- quit: fiddlerwoaroof (*.net *.split) 21:17:32 --- quit: kiedtl (*.net *.split) 21:17:32 --- quit: jedb__ (*.net *.split) 21:17:32 --- quit: mark4 (*.net *.split) 21:17:32 --- quit: rpcope (*.net *.split) 21:17:32 --- quit: dys (*.net *.split) 21:17:32 --- quit: pareidolia (*.net *.split) 21:17:33 --- quit: siraben (*.net *.split) 21:17:33 --- quit: krjt (*.net *.split) 21:17:33 --- quit: mjl (*.net *.split) 21:17:33 --- quit: dnm (*.net *.split) 21:17:33 --- quit: a3f (*.net *.split) 21:17:33 --- quit: KipIngram (*.net *.split) 21:17:33 --- quit: Zarutian_HTC (*.net *.split) 21:17:33 --- quit: nitrix (*.net *.split) 21:17:34 --- quit: jimt[m] (*.net *.split) 21:17:34 --- quit: ovf (*.net *.split) 21:17:34 --- quit: MrMobius (*.net *.split) 21:17:34 --- quit: Keshl (*.net *.split) 21:17:34 --- quit: klys (*.net *.split) 21:17:34 --- quit: swineflu (*.net *.split) 21:17:34 --- quit: Lord_Nightmare (*.net *.split) 21:17:35 --- quit: APic (*.net *.split) 21:18:44 --- join: jedb__ joined #forth 21:18:44 --- join: Zarutian_HTC joined #forth 21:18:44 --- join: Lord_Nightmare joined #forth 21:18:44 --- join: jimt[m] joined #forth 21:18:44 --- join: siraben joined #forth 21:18:44 --- join: ovf joined #forth 21:18:44 --- join: pareidolia joined #forth 21:18:44 --- join: dys joined #forth 21:18:44 --- join: rpcope joined #forth 21:18:44 --- join: mark4 joined #forth 21:18:44 --- join: mjl joined #forth 21:18:44 --- join: krjt joined #forth 21:18:44 --- join: KipIngram joined #forth 21:18:44 --- join: a3f joined #forth 21:18:44 --- join: dnm joined #forth 21:18:44 --- join: nitrix joined #forth 21:18:44 --- join: kiedtl joined #forth 21:18:44 --- join: fiddlerwoaroof joined #forth 21:18:44 --- join: jn__ joined #forth 21:18:44 --- join: mstevens joined #forth 21:18:44 --- join: lonjil joined #forth 21:18:44 --- join: tabemann joined #forth 21:18:44 --- join: klys joined #forth 21:18:44 --- join: Keshl joined #forth 21:18:44 --- join: swineflu joined #forth 21:18:44 --- join: MrMobius joined #forth 21:18:44 --- join: APic joined #forth 21:18:44 --- mode: rajaniemi.freenode.net set +vv mark4 KipIngram 21:19:24 --- quit: siraben (Max SendQ exceeded) 21:21:09 --- quit: rann (Ping timeout: 245 seconds) 21:21:11 --- quit: ovf (Ping timeout: 245 seconds) 21:21:33 --- quit: sts-q (Ping timeout: 240 seconds) 21:21:36 --- quit: jimt[m] (Ping timeout: 245 seconds) 21:27:33 --- join: rann joined #forth 21:28:11 --- join: ovf joined #forth 21:30:40 --- join: sts-q joined #forth 21:48:54 --- join: gravicappa joined #forth 21:53:48 --- join: siraben joined #forth 22:03:34 --- join: jimt[m] joined #forth 22:10:50 --- join: f-a joined #forth 22:34:14 --- join: dave0 joined #forth 22:35:20 maw 23:10:32 Evening, dave0. 23:12:21 hi KipIngram 23:32:05 --- quit: dave0 (Quit: dave's not here) 23:59:59 --- log: ended forth/21.04.09