00:00:00 --- log: started forth/21.04.10 01:37:50 --- join: dave0 joined #forth 01:38:07 maw 10:30:49 --- log: started forth/21.04.10 10:30:49 --- join: clog joined #forth 10:30:49 --- 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' 10:30:49 --- topic: set by mark4!~mark4@cpe-75-191-74-68.triad.res.rr.com on [Sun Feb 28 11:55:01 2021] 10:30:49 --- names: list (clog tech_exorcist andrei-n _whitelogger jimt[m] siraben gravicappa sts-q ovf rann APic MrMobius swineflu Keshl klys tabemann lonjil mstevens jn__ fiddlerwoaroof kiedtl nitrix dnm a3f +KipIngram krjt mjl +mark4 rpcope dys pareidolia Lord_Nightmare jedb__ dsmcfarl boru spoofer rixard ornxka tolja Vedran jess X-Scale ecraven koisoke_ joe9 guan crest remexre cp- +proteusguy rprimus cmtptr jyf dzho TangentDelta phadthai bluekelp veltas lispmacs[work] Kumool) 10:30:49 --- names: list (lispmacs xybre djinni @crc nihilazo) 10:31:44 No, I don't spend a lot of time perusing other Forths these days. 10:31:53 Mostly just play in my own little sandbox. 10:32:20 I count on haning out here to make me at least a little aware of "good ideas" that have come along. 10:32:56 cool 10:33:13 just an idea. you could use that for the firmware instead of C if you wanted 10:35:51 I'll keep it in mind. Another thought I'd had for solving the keyboard problem was to perhaps rip the guts out of an existing calculator and replace it. That's kind of limiting though - I'd almost certainly wind up wishing I had other keys on the keyboard. I guess I could try repainting, or use stickers, but I don't know how well that would go. 10:40:19 interesting idea 10:40:43 if you could repaint or get stickers that wont wear off, you could build your own case 10:41:01 which is relatively simple. its just the paint or stickers problem thats so hard to solve 10:41:14 Yes. 10:41:50 The big problem with this whole project, though, is that honestly I almost never USE a calculator anymore. Most problems that would call for the power of a good programmable I just sit down an flop out in Python. 10:41:51 on that note though, there is a project called the WP-34 where HP released the skeleton code for one of their calculators and the community implemented new firmware from scratch that is supposed to be much better 10:42:05 I'd need to re-train myself to some degree to actually make it worthwhile to have. 10:42:36 there is also one called newRPL where a guy is creating new firmware for the HP-50G which has a 72mhz ARM simulating an old 4mhz calculator CPU. newRPL runs natively on the ARM 10:42:57 hehe ya its definitely just a passion project at this point 10:43:15 you can also just get a cheap graphing model with python in ROM and youd be set for practical stuff 10:55:45 --- quit: proteusguy (*.net *.split) 10:55:45 --- quit: cp- (*.net *.split) 10:55:46 --- quit: remexre (*.net *.split) 10:56:40 --- join: f-a joined #forth 10:56:42 --- join: proteusguy joined #forth 10:56:42 --- join: cp- joined #forth 10:56:42 --- join: remexre joined #forth 10:56:42 --- mode: barjavel.freenode.net set +v proteusguy 10:57:06 --- quit: cp- (Max SendQ exceeded) 10:58:00 Yeah. I got my HP 41 in fall of freshman year at UT Austin, and for the rest of college it was my only real computing tool. Honestly I cut my programming teeth programming that. I took a FORTRAN class, but didn't do nearly so much with that as I did the HP. So I was all primed and ready to appreciate Forth. Thinking in terms of a stack was already second nature. 10:59:12 --- quit: lispmacs[work] (Ping timeout: 265 seconds) 10:59:44 --- join: cp- joined #forth 11:00:25 In particular, think in terms of a four element stack, where data just pushed off the top and permanently reproduced on drops was second nature. So there was some adjusting to do. 11:16:27 --- quit: mark4 (Ping timeout: 260 seconds) 11:23:17 --- quit: gravicappa (Ping timeout: 252 seconds) 11:42:00 --- join: mark4 joined #forth 12:15:05 --- quit: tech_exorcist (Ping timeout: 265 seconds) 12:15:14 back 12:17:37 * tabemann honestly also just uses Python when he has a calculation he wants to run 12:29:34 Too easy. 12:29:52 They've really done a good job supporting "quick and dirty." 12:59:04 --- quit: phadthai (Ping timeout: 265 seconds) 12:59:18 --- join: phadthai joined #forth 13:06:33 --- quit: andrei-n (Quit: Leaving) 13:31:58 --- join: Zarutian_HTC joined #forth 13:37:26 --- quit: Zarutian_HTC (Remote host closed the connection) 14:14:01 luajit is my quick and dirty REPL 14:14:27 And my quick and dirty choice of scripting environment too 14:14:42 I love Lua it's a fantastic scripting language 14:43:36 My main reason for going with Python is just that's almost always there and has massive package support. I might like lua better for all I know. 14:44:02 --- part: f-a left #forth 14:44:15 --- join: Zarutian_HTC joined #forth 14:54:25 Lua is a fantastic VM, but a terrible scripting language 14:57:36 --- join: Croran joined #forth 15:00:46 the syntax is terrible but man I do love the tables and the metatables 15:02:45 Lua is lighter-weight than Python, though 15:04:58 not nearly as lightweight as embedded Forths though 15:25:33 KipIngram: Lua is far more bare-bones than Python 15:25:49 Lua is if you have an application written in C or C++ and you want a lightweight scripting language for it 15:26:01 Python is for if you're scripting something and want the kitchen sink 15:28:35 Having that kitchen sink is my usual desire when I use Pythonn. 15:28:44 I just want to get something done, fast. 15:28:56 but it is faster than most forths 15:29:08 Not Python. 15:29:13 Yuo mean lua? 15:29:16 aye 15:29:21 Gotcha. 15:29:47 Python is not in itself fast - but it can be fast when you're calling code in C from it 15:29:59 Sure. 15:30:18 Python is good "glue" for stiching together other things. 15:30:20 so one can have fast numerics code written in Python even though Python itself is slow as mud 15:32:41 Python is my go-to language when I want to munge a pile of text and I want it done fast (by fast I mean time spent writing the code) 15:32:55 I've only tested euler 7, and python is by far faster than awk, but only 2x 15:33:10 as the code will probably never be run more than a few times anyways 15:33:45 I timed an almost empty loop, that just counted a value down from 10 billion, in Forth (mine), Python, and gcc. 15:33:47 ah, exploratory 'throw away' code basically 15:34:05 Python was about 1% of gcc speed - the Forth was about 35% of gcc speed. 15:34:45 The Forth word was just 15:35:00 : countdown 1- .0>me drop ; 15:35:01 not much of a benchmark, but I find it more realistic than a noop 15:35:04 is your Forth ITC, DTC, or STC, and does it have inlinig? 15:35:12 ITC. 15:35:15 strangely enough, lua is slower than perl if you want to mess with text 15:35:33 I have some assembly support, but it's barely finished work annd not really honed yet. 15:36:29 the 0>me jumps back to the beginnningn of the word if the counter is > 0. Which in this case just means jumping back to the 1-. 15:36:48 So that's really two passes through NEXT and a couple of other assembly instructions that do the actual work. 15:37:24 Based on that I estimated that my NEXT consumes about 1.5 ns. 15:39:05 tabemann: I've always just had a preference for ITC. 15:39:21 It's the first Forth architecture I learned about, and I really just built my thinking about it. 15:39:41 I think dave0 is onto the best DTC approach - if I ever do one of those I'm pilfering it. :-) 15:39:55 He uses the return instruction as his NEXT. 15:40:01 my embedded forth is SRT/NCI 15:40:26 And if he wants to he can put (:) inline just before new definitions with not much space required. 15:40:33 That would scream, I think. 15:41:15 Did you find CREATE / DOES> to be somewhat cumbersome to implement? 15:41:23 I should install microPython on one my boards and do a comparison between zeptoforth and it 15:41:31 To the extent I've thought about it, I've felt that ITC makes CREATE / DOES> easier. 15:41:44 my CREATE cannot be used with DOES> - rather I have 15:42:14 Ok, that's fair enough. I actually used a different word too - I caled it MAKER. 15:42:34 And I was able to implement that all in Forth - I didn't have to use assembly to get there. 15:43:19 my building words generally call into the zeptoforth kernel, which is written in assembly 15:43:55 aside from : , :NONAME , and CONSTANT etc, which are part of the kernel itself 15:44:00 I wouldn't know what to call the "kernnel" of my Forth. 15:44:20 The QUIT loop is right down there at the bottom - I'd say that's the lowest level thing running on the system. 15:44:24 the kernel of my forth is actually pretty big; it's about 27K 15:44:42 My whole Forthis probably somewhere around that. 15:44:52 I don't know for sure yet where this onen will wind up. 15:44:57 Lemme see where it is now. 15:45:06 oh my full forth, with all the extras loaded, gets quite big 15:46:57 Looks like I'm at 9975 bytes so far. 15:47:07 That's the sum of the body section and the header section. 15:47:41 that's far, far smaller than the "big" zeptoforth builds 15:48:13 I'd say this one is just a fairly standard FIG like build, using 32-bit cells in the definitions. 15:48:43 I think if it were a 16-bit Forth it would be coming in at this point around 6800 bytes. 15:49:19 Maybe a little bigger - some of what I just chopped in half is code, and it wouldn't really reduce much. 15:50:29 The CFA/PFA pointers are also 32 bits. 15:50:55 A real FIG build wouldn't have the PFA pointers - the definitions and stuff would just start where those are. 15:51:41 I didn't want to have to have the headers intermingled with the definitions. 15:51:50 the "big" zeptoforth is essentially a soft realtime OS 15:52:03 It sounds interesting. 15:53:13 of course the "big" builds for the L4 come out at about ~150K and those for the F4 and F7 come out at 256K due to erase page boundaries 15:54:01 which is a horrible waste of flash of course 16:02:32 This sounds like it's meant as a foundation layer for stuff to run on top of? 16:09:54 Or is it supposed to support multiple Forth threads on top of this kernel? 16:10:17 I had a task ring designed into my last one, but I never got around to putting more than onen task in it. 16:11:07 Each task would have had a 4k page that contained its stacks and a set of important variables. A register pointed to the base of the task page. 16:11:39 it's supposed to be an environment where one can run multiple preemptive tasks running forth code, with also support for priority inversion-resistant locks, buffered and rendezvous channels, a lightweight event scheduler, task pools, an optional heap allocator, and so on 16:11:44 So the idea was that to switch tasks you'd stash your stack pointers, flip that register to the next task's block, and reload the stack pointers and go. 16:12:01 Cool. 16:12:45 the multitasker of course supports multiple task priorities and varied task timeslices, with support built in for sleeping tasks until a time is reached 16:15:23 Yeah, I was planning on implementing all that sort of stuff. 16:16:11 note that this stuff is not implemented in the kernel 16:16:31 rather most of the traditional "OS"-type stuff aside from the REPL is implemented in Forth 16:16:39 Oh people always moan about Lua's syntax, it's not exactly COBOL 16:17:08 Its syntax is actually quite good, people just don't like some of the choices in the basic syntax 16:17:52 Stuff like 1-based indexing, english words used for scoping, ~= is "not equals" 16:18:21 That's it, if you can get over that the rest is good, and it's so small and easy to learn/apply 16:19:43 Unlike Python where the syntax is actually mostly sensible despite syntactic indentation, but all the core library decisions are horrific and make you wonder why you bothered leaving C 16:20:28 my main issue with Lua is that I'm not a fan of 1-based indexing, even though I'm willing to put up with it 16:20:44 Lua lets you use 0-based arrays 16:21:11 But the basic list-style constructor will produce 1-based and it's the assumption for most utilities 16:21:26 yeah 16:21:28 But if you have an isolated situation where you want a 0-based array there's nothing stopping you 16:22:11 I gave a talk about Lua where I gave an example of a circular array and used metatables to make it overall neater than you get with a normal 0-based non-extensible language 16:22:35 Metatables are sort of a DOES> feature 16:22:43 yeah, I'm familiar with them 16:22:54 Just saying in case anyone else is reading 16:23:02 * tabemann added scripting to a big application using Lua like a decade ago 16:23:50 I wrote an internal package manager in Lua that ran insanely quickly compared to its PHP predecessor 16:24:31 Just kept it simple and applied associative arrays sensibly, Lua is very fast anyway, the runtime is way smaller than PHP 16:25:25 uck PHP 16:25:48 The original was written in PHP because it was available on the target machines 16:25:58 Alternatives were like Perl, bash 16:25:59 I know a lot of cheap web hosting uses PHP 16:26:09 I didn't write the original 16:26:53 PHP is very developed now and apparently not terrible 16:27:05 I can't really comment on it, I have little experience with it 16:29:21 If I had to write a web thing and I had no particular ecosystem requirements I'd use luajit 16:29:24 I did a little in PHP a long time ago and was not really impressed 16:29:46 PHP is a very unnecessary language, but really all of the web stack is that 16:30:38 currently at work I work in Java and JavaScript, neither of which I am fond of 16:30:46 luajit or C (or Forth :3) 16:31:51 The biggest problem with Java is Java programmers 16:32:04 And Java codebases 16:33:42 the Java codebase I work on at work makes me wonder how one actually creates new web applications in Java 16:33:57 just too much needs to be implemented to get off the ground 16:34:44 Spring and Maven and Hibernate oh my 16:45:43 --- join: Zarutian_HTC1 joined #forth 16:45:44 --- quit: Zarutian_HTC (Read error: Connection reset by peer) 17:39:04 --- quit: jess (Quit: K-Lined) 17:39:17 --- join: jess joined #forth 17:57:06 --- quit: Zarutian_HTC1 (Read error: Connection reset by peer) 17:57:21 --- join: Zarutian_HTC joined #forth 18:22:40 --- quit: Croran (Quit: Croran) 18:35:00 --- join: boru` joined #forth 18:35:02 --- quit: boru (Disconnected by services) 18:35:05 --- nick: boru` -> boru 19:54:03 --- quit: sts-q (Ping timeout: 240 seconds) 20:06:07 --- join: sts-q joined #forth 20:26:37 --- join: chrisb joined #forth 21:25:34 --- join: dave0 joined #forth 21:26:28 maw 21:49:06 --- join: gravicappa joined #forth 22:21:23 --- join: jedb_ joined #forth 22:23:47 --- quit: jedb__ (Ping timeout: 260 seconds) 22:31:58 --- quit: dave0 (Quit: dave's not here) 23:08:15 --- join: jedb__ joined #forth 23:10:45 --- quit: jedb_ (Ping timeout: 252 seconds) 23:13:22 --- join: andrei-n joined #forth 23:59:59 --- log: ended forth/21.04.10