00:00:00 --- log: started forth/19.06.29 00:40:28 --- quit: kori (Ping timeout: 252 seconds) 00:57:35 --- join: xek (~xek@apn-31-0-23-200.dynamic.gprs.plus.pl) joined #forth 01:06:08 --- quit: proteus-guy (Remote host closed the connection) 01:07:04 --- join: proteus-guy (~proteusgu@cm-58-10-208-146.revip7.asianet.co.th) joined #forth 01:18:38 --- join: dys (~dys@tmo-116-8.customers.d1-online.com) joined #forth 01:23:33 --- join: kori (~kori@187.123.3.51) joined #forth 01:23:33 --- quit: kori (Changing host) 01:23:33 --- join: kori (~kori@unaffiliated/kori) joined #forth 01:26:12 --- quit: proteus-guy (Remote host closed the connection) 01:42:04 --- join: proteus-guy (~proteusgu@cm-58-10-208-146.revip7.asianet.co.th) joined #forth 02:01:47 --- quit: proteus-guy (Remote host closed the connection) 02:03:18 --- quit: kori (Read error: Connection reset by peer) 02:25:21 --- join: kori (~kori@2804:14c:85a3:81b8::1000) joined #forth 02:28:47 --- quit: kori (Changing host) 02:28:48 --- join: kori (~kori@unaffiliated/kori) joined #forth 03:48:55 --- quit: xek (Ping timeout: 248 seconds) 04:00:22 --- quit: dave9 (Remote host closed the connection) 04:01:15 --- quit: dave0 (Ping timeout: 245 seconds) 04:01:53 --- join: dave0 (~dave0@069.d.003.ncl.iprimus.net.au) joined #forth 04:05:32 --- join: dave9 (~dave@069.d.003.ncl.iprimus.net.au) joined #forth 04:17:50 free (bytes) 04:17:50 FLASH.. TOTAL REPORTED: 196608 USED: 20872 FREE: 175736 04:17:50 RAM.... TOTAL PRESET: 20480 USED: 1256 FREE: 19224 04:18:12 that's memstats for a STM32L073RZ running Mecrisp-Stellaris 04:19:34 --- quit: dave9 (Ping timeout: 245 seconds) 04:19:35 --- quit: dave0 (Ping timeout: 245 seconds) 04:19:40 --- join: dave69 (~dave0@069.d.003.ncl.iprimus.net.au) joined #forth 04:21:06 --- nick: dave69 -> dave0 04:24:01 --- join: dave9 (~dave@069.d.003.ncl.iprimus.net.au) joined #forth 05:52:16 I've just been playing around with rlwrap so that picocom can have readline, works great but blocks control key characters so no file uploads or graceful exit:( 06:21:47 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 06:24:28 --- quit: reepca (Read error: Connection reset by peer) 06:24:40 --- join: reepca (~user@208.89.170.37) joined #forth 06:42:15 --- join: proteus-guy (~proteusgu@cm-58-10-208-146.revip7.asianet.co.th) joined #forth 06:42:50 --- quit: reepca (Ping timeout: 272 seconds) 06:44:47 --- quit: proteus-guy (Remote host closed the connection) 07:10:42 --- join: proteus-guy (~proteusgu@cm-58-10-208-146.revip7.asianet.co.th) joined #forth 07:12:19 --- quit: proteus-guy (Remote host closed the connection) 07:38:17 --- join: proteus-guy (~proteusgu@cm-58-10-208-146.revip7.asianet.co.th) joined #forth 07:53:57 --- quit: dave0 (Quit: dave's not here) 08:17:51 --- quit: dys (Remote host closed the connection) 09:09:56 --- quit: proteus-guy (Remote host closed the connection) 12:10:22 --- join: cnidario (~aaa@92.57.58.87) joined #forth 12:10:47 --- quit: gravicappa (Ping timeout: 248 seconds) 12:29:43 --- join: dys (~dys@tmo-101-70.customers.d1-online.com) joined #forth 13:07:55 --- quit: dave9 (Ping timeout: 245 seconds) 13:12:29 --- join: dave9 (~dave@069.d.003.ncl.iprimus.net.au) joined #forth 13:16:52 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth 13:18:50 --- quit: MrMobius (Ping timeout: 246 seconds) 13:18:50 --- nick: [1]MrMobius -> MrMobius 13:53:15 --- join: reepca (~user@208.89.170.37) joined #forth 15:13:06 --- quit: cnidario (Remote host closed the connection) 16:23:56 --- quit: john_cephalopoda (Ping timeout: 252 seconds) 16:37:29 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth 18:04:48 --- join: dave0 (~dave0@069.d.003.ncl.iprimus.net.au) joined #forth 18:05:09 hi 18:05:26 heyho 18:05:46 hi tp 18:05:48 lovely weather up here in the northern rivers 18:06:05 g'day dave0, whats new in forthland ? 18:06:28 don't know! i've been lazy lately :-) 18:07:35 always interesting things going on :) 18:08:32 I now have a new version of mecrisp-across from Matthias Koch which features Pictured Numerical Output to test 18:09:30 this one? <# # #> 18:09:35 plus Im testiing getting numbers in and out of his assembler-m0.fs 'interactive assembly' program 18:09:41 yeah thats right 18:09:58 i like those :-) the code looks like the output 18:10:12 I use Pictured Numerical Output for my register data pretty printing 18:11:23 which are all generated by my svd2forth parser, so I couldnt add that feature until I had the new release 18:12:24 i found a forth the other day with a nice assembler in it... it even had labels! 18:13:45 wow 18:14:56 trying to find it 18:15:04 basically Im working on adding hardware handshaking to a mcu and I want to test my assembly first using Forth before I test it on real hardware 18:15:45 I could easily use gdb etc but thought Id try it this way for once as it's simpler 18:21:19 can't find the link... it's called "third" 18:21:27 heh 18:23:04 here it is: https://github.com/benhoyt/third 18:27:45 too retro for me :) 18:31:49 simpler times! 18:32:10 I'm guessing you have a bucket of 8086 chips there ? ;-) 18:33:01 haha 18:33:08 nope i'm not a hardware guy :-) 18:33:15 but i do like old software 18:34:10 I always find it odd that as a tech I hate old everything but a lot of coders like old software, different worlds I guess 18:35:57 forth is sorta retro.. it's been around a long time, and works really good on small systems 18:36:39 systems aren't so small these days :-) 18:38:00 hmm, I dont see Forth as retro at all, perhaps thats the difference 18:38:52 i use Forth on the latest chips and have development advantages that frankly the usual C coders for those chips couldnt imagine 18:39:31 in fact I see their use of C as trying to fit a old language into a modern micro 18:39:54 yeah c ain't so good 18:40:18 it's probably great for large systems but was never designed for embedded micros 18:41:17 i've heard people say c was a great design for writing unix... but unix ain't all that either :-) 18:41:23 C coders talk about 'code portability' but that just doesnt happen with small micros because the hardware is always different and the massive hoops the C coders go thru to make them seem the same is incredible 18:42:41 c is too complicated 18:42:42 I'm happy with unix, it was a great fit for me the first time I saw it, I couldnt stand anything else from dos to windows to OS/2 18:42:51 Ill say it is! 18:45:25 especially in embedded. Ive been in a discussion on eevblog.com for a while about the disparities between C examples for Cortex-M regarding register and bitfield naming 18:46:47 all the C coders there seem to think that STM who make a ton of Cortex-M chips has a lot of inconsistency in it's documentation regarding register and bitfield naming 18:47:47 but as I use Forth and not C, I had to develop a parser to generate memory maps for all those register and bitfields for myself, and I found it to be very consistent 18:48:57 the bottom line is that experienced C coders post examples there and theyre usually so wrong with their naming, that the examples are totally usless and would never work 18:49:18 so id the experienced C coders cant get it right .... 18:56:33 and I suspect they can't get it right because C on small embedded is a utter mess 20:01:06 tp: C is terrible for writing large systems. 20:01:53 It lacks EVERYTHING—literally EVERYTHING—that you need to efficiently and effectively write secure, low-bug-count systems. And it's a maintenance nightmare on top of that. 20:08:19 --- quit: dddddd (Remote host closed the connection) 20:55:10 --- quit: dave0 (Quit: dave's not here) 21:06:24 ttmrichter, I didnt know that 21:07:43 ttmrichter, have you see picolisp, if so what do you think of that ? https://picolisp.com/wiki/?home 21:09:04 I knew about it, yes. Lisps are languages that I admire, but can't use. My brain just doesn't seem to ever want to think in the Lisp way. 21:10:33 mine doesn't yet either but I'm hoping it will by the time I'm 70 ... 21:11:32 ttmrichter, so here is the big question, if you were writing a x86 PC program, say one that uses a database, what language(s) would you personally choose ? 21:12:46 if I were writing a large x86 application that uses a database binding, I would personally choose haskell and postgres 21:13:06 Fantasy language availability or something that plausibly exists? 21:13:30 * tabemann checked to make sure there are bindings for postgres for haskell 21:13:32 ttmrichter, something that exists 21:13:39 For the database I'm with tabemann: postgres. 21:13:53 But Haskell is one of the very small number of languages that is banned from my system entirely. 21:14:03 LIke I don't use programs that are even WRITTEN in it on my systems. 21:14:18 me too, I like postgress and recently learnt some sqlite which is simple but easy to use and deploy 21:14:39 SQLite is great for small, embedded/encapsualted DBs, but not for big apps. 21:14:40 * tabemann loves haskell's type system and its support for concurrency 21:14:58 * ttmrichter hates Haskell's ecosystem that renders using it laughable. 21:15:05 ttmrichter, my thinking also re sqlite 21:15:22 stackage has really improved haskell's ecosystem, just so you know 21:15:26 I'd probably hold my nose a bit and pick OCaML. 21:15:35 OCaml is also a nice language 21:15:51 I have heard so many promises of "X has fixed Haskell's ecosystem" that they are now background noise. 21:15:57 I was just about to ask re ocaml as you have recommended it in the past 21:15:59 I gave Haskell a fucking decade. 21:16:19 In a decade it did not meaningfully improve and its user base insisted it was near perfection as-is. 21:16:25 It's now in my past permanently. 21:16:26 its syntax is inferior to that of haskell in my opinion, and it has inferior concurrency support, but it's strict-by-default rather than lazy-by-default, which has some advantages 21:17:09 for projects were concurrency and reliability are utmost absolute needs but straight-line performance is not the highest priority, I'd go with erlang 21:17:41 Yeah, Erlang for some classes of big system is definitely best of breed. 21:18:12 You can write AMAZINGLY resilient systems in it. 21:18:42 All the stupid little tricks that embedded developers come up with over the years as they make reliable systems are baked into either Erlang proper or the OTP. 21:19:08 erlang makes writing reliable distributed concurrent systems stupidly easy 21:20:03 Well the "reliable" part has a few gotchas still (message queue backpressure isn't a thing unless you do it yourself), but it's MUCH easier than any other language I've seen. 21:20:38 normally writing concurrent systems is hard and writing distributed concurrent systems is even harder 21:21:46 like traditional concurrent programming is so prone to bugs that it is generally best avoided 21:22:39 there are so many ways one can get locking with multiple locks wrong that it is not funny 21:25:08 Unless the code that uses the locks is mechanically-generated based on a solid mathematical model, it's almost certain that there are bugs in non-trivial code that uses locking semantics. 21:25:21 (And about 50/50 that trivial code has bugs.) 21:26:12 wow 21:26:56 I think I'll add ocaml to my "to learn" list which only has lisp on it so far 21:28:06 I'm a tech not a programmer so I wont be doing any concurrent or distributed stuff, just PC apps to support my embedded development system 21:31:40 ocaml has more rough edges than haskell in my opinion (e.g. how it handles equality is ugly), but it is still one of the better languages out there IMHO 21:32:31 ttmrichter: that kind of thing is part of why I've held off in adding preemptive multitasking to hashforth 21:33:25 hashforth currently can have preemptive multitasking pretty trivially added to it, with the exception of all the places atomic blocks would have to be added, which would be many 21:40:39 I'd put the locks inside message queues and not reveal them to the end-users. :D 21:42:02 in hashforth I've written a number of related message queue abstractions (e.g. fixed number of entries versus allocated, byte stream versus fixed block, etc.) 21:42:22 --- join: proteus-guy (~kvirc@cm-58-10-208-146.revip7.asianet.co.th) joined #forth 21:42:24 they're designed to be used for concurrent programs using hashforth 21:42:34 well, "concurrent" as it's cooperative 21:42:54 hey proteusguy 21:47:55 howdy. what am I missing today? :-) 21:50:33 discussing languages and concurrency 21:51:26 I think cooperative concurrency is a grossly-underused technique, personally. 21:51:52 Rarely do you need full-on parallel concurrency. 21:52:17 I've always been fond of coroutines as a technique. 21:52:21 strictly-speaking concurrency and parallelism are different concepts 21:52:26 Yep. 21:52:32 e.g. one cannot have parallelism on a single core 21:52:44 Wanna bet? :D 21:53:12 Sets up five DMA requests and seventeen timer countdowns on an MCU... 21:53:27 parallelism involves speeding up code vis-a-vis straight-line computation 21:53:40 Right. Like DMA. 21:53:52 Which moves data in parallel with computation. 21:54:01 that is true 21:54:18 Or timers which keep countdowns for timed operations in parallel. 21:54:28 But that's sane parallelism. 21:54:42 It's bounded and can be easily controlled to be correct. 21:55:11 one thing I need to state is (as much as you dislike haskell) concurrency under haskell with STM is amazing 21:55:42 probably best shared-memory preemptive concurrency environment I have encountered 21:55:44 STM is decent, but it's not quite a panacea. And if I really want it I can get it in Clojure. 21:56:26 Clojure is limited in that its threads are JVM threads, which are considerably heavier-weight than Haskell threads 21:56:27 Oh, and don't get me wrong. Haskell as a language is a good language (except for the lazy-by-default thing that causes endless trouble). 21:56:39 It's the Haskell ECOSYSTEM and COMMUNITY I can't stand. 21:57:18 What about the community? 21:57:21 Right up to and including its really annoying tendency to reach straight for silly levels of abstraction and then trying to hammer reality into fitting that abstraction. 21:57:36 Instead of building abstraction up from the problem domain. 21:58:14 most Haskell code I write is awfully non-abstract - the language isn't forcing you to do that 21:58:21 hey siraben 21:58:26 Hi tabemann 21:58:51 siraben: Well, the rather tepid response to the whole Cabal Hell problem, with a decade of me watching them go through the cycle of "it's not a problem → technology X solves that problem → it's still a problem → technology Y solves that problem → it's still a problem". 21:59:15 Hence "ecosystem" and "community". 21:59:29 Cabal Hell is a real problem, but I don't think that other package managers are necessarily better 21:59:41 I prefer the ML approach to functional programming, with mutable references 21:59:55 You technically don't have to use Monads in Haskell ... but good luck using any third-party libraries without having them crammed down your throat. Unless they cram lenses down your throat instead. 22:00:10 like I've had nasty problems dealing with Debian packages 22:00:11 Ah lenses, I haven't the foggiest on what they do 22:00:21 siraben: They generate loads of academic papers. 22:00:28 I had to read papers to understand monads, and looks like lenses are the same deal 22:00:29 * tabemann doesn't understand and doesn't use lenses 22:00:31 papers left and right 22:00:47 whereas monads are trivial for me to wrap my brain around 22:01:06 The other issue is the tendency of people to "document" their libraries by referencing a paper that doesn't actually, you know, document. The library. 22:01:25 most of the time with monads it's essentially imperative computing 22:01:47 Monads are trivial, but they don't compose well (I saw Don Stewart make a huge jackass out of himself trying to refute that; it was GLORIOUS!) and they're not always the best abstraction to reach for. 22:02:01 and I've written a lot of haskell code that essentially runs in the IO, STM, or State monads 22:02:44 one key thing is don't try to nest too many monad transformers 22:02:50 composing monads is a nightmare 22:02:59 and if you do, please make a new type and new abstractions for them 22:03:37 No wonder why OCaml is used for large scale things 22:04:58 The real test for me, however, is looking at the software out there. 22:05:09 I've seen massive, super-reliable systems built using Erlang. 22:05:17 Touched them with my own fingers. 22:05:30 I've never seen a Haskell-based program that wasn't a tire fire. 22:05:44 OCaml's main problem is that it gets wrong the things that Haskell gets right (equality problems, difficulty abstracting (parameterized modules are hard to work with), poor concurrency (no STM, no multicore)) even when it gets right the things that Haskell gets wrong (strict-by-default rather than lazy-by-default) 22:05:46 Darcs. Xmonad. Yi. That web framework whose name I forget... 22:06:58 And I'm not a strong static typing fetishist. I'm not ANTI-static typing by any means, but ... I'd guess at least 80% of the bugs in my code nowadays could not be caught by a type system, no matter how B&D. 22:07:53 whereas I've found that strong static typing catches a lot of bugs whereas, say, Forth provides no safety at all and no help debugging in that department 22:08:12 That's where Erlang shines. 22:08:20 You can go semi-strong static typing if you like. 22:08:26 With an eternal tool, though. 22:08:34 yes 22:08:43 And it has debugging facilities that blow everything else in use currently right out of the sky. 22:09:13 Being able to do live tracing on a production system to catch a bug in action as it happens is an AMAZING feature. 22:09:36 *external tool. Keyboard causing problems today. 22:09:59 whereas currently I love to hate JS because I work with it for a living and find its dynamic typing to be so much of a problem 22:10:15 the haskell folks got really upset with me when I remarked that their lists were more properly stacks. :-) 22:10:40 I won't work with JS. I will legit quit doing software (again) before I touch JS. 22:11:02 for concurrency I'm a big fan of the actor model, of course. Have done Erlang and dabbled in Elixir. Expect to implement an actor model for my next forth-ish language. 22:11:06 well traditionally lisp lists and ML lists are the same way proteusguy 22:11:28 tabemann, *I* know that but just don't say it out loud to the functional fanboys. ;-) 22:11:55 * tabemann is a functional fanboy :D 22:12:17 ttmrichter, now that there's Elm you need never touch javascript in the browser again. Quite a nice little language. Indeed I now consider it more of a DSL for building DOM-based UXs. 22:12:50 I'd try purescript before trying elm personally 22:13:30 tabemann, nahhh... fanboys are the kind that can't even consider a criticism of their language/devices or that an alternative should even be recognized. Liking something a lot is a different matter. I love functional style concepts. 22:14:02 purescript is essentially a redesigned haskell that IIRC is strict and aimed at the browser 22:15:06 tabemann, the thing about human computer interaction is that a pure functional language is gonna impose a lot of mental burden on the programmer because humans sure ain't "pure". Elm's architecture tries to make this more approachable. It's also why purescript is a good language for backend programming and not really an option for Elm. Thus my designation of Elm as a DSL. 22:16:26 proteusguy: I'm pretty sure that Elm hits my Haskell ban. Isn't it implemented in Haskell? 22:18:10 ttmrichter, it's compiler is haskell and javascript yet. 22:18:32 I don't do "go-lang" but I don't forbid tools written in it. I don't encourage them either. 22:19:10 I've had enough problems with programs written in Haskell that it's a blanket ban. 22:21:07 ttmrichter, do tell? I've only had good experiences. 22:22:50 Well, it all boils down to Cabal Hell, naturally. 22:23:08 Except for darcs. Darcs is just a tire fire. 22:24:13 "This merge with fifteen thousand potential conflicts happened error-free in 127µs. This merge with no visible conflicts whatsoever has thus far taken 17 hours and 16GB of your address space (4GB RAM, 12GB swap ... which is thrashing). 22:24:36 does anyone use darcs, really? 22:24:39 ANY operation with darcs that had a merge in it was a potential eternal wait. 22:24:45 Not anymore, no. There's a reason for it. 22:24:56 and it's not exactly fair to blame haskell the language for it 22:25:11 But it's kind of telling that the premier Haskell compiler project moved away from darcs, which it used to tout, because of its problems. 22:25:35 Well the problem is lazy-by-default. It's almost impossible to reason about memory complexity and time complexity with lazy evaluation. 22:25:47 Darcs is just an extreme example of that. 22:26:03 But let's go with Xmonad as a more typical problem. 22:26:13 Let's say I have no other Haskell software installed. 22:26:28 Getting xmonad installed is trivial. A delight, really. 22:26:34 And it runs on first try. So far so good. 22:26:53 But ... uh ... xmonad raw is a bit ... minimalist. I want a few plug-ins. 22:27:07 Cabal Hell starts rearing its ugly head. 22:27:08 you have to restart it to modify it 22:27:17 Like seriously huge Cabal Hell issues. 22:27:28 But let's skip that for now. 22:27:31 You resolve them. 22:27:52 Now configure. The advertising of the time was "you don't need to know how to program in Haskell to configure xmonad". 22:28:00 That turns out to be total and absolute bullshit. 22:28:16 the configuration file is a haskell source file 22:28:31 and each time you have to change the configuration, it restarts 22:28:32 ttmrichter, can understand why you don't like their tooling. but why ban anything written in it? 22:28:45 I was delving deep through multiple layers of badly-documented, badly-commented ("but you get THEOREMS FOR FREE!!!!!") code to figure out how to get any two plug-ins to work together. 22:29:07 OK, so I resolve all that. 22:29:16 And I try to install another Haskell program. Yi, say. 22:29:30 The entire Haskell ecosystem flips you the bird and says "FUCK YOU!" 22:29:45 this is where stackage comes into plan 22:29:58 Yeah, Stackage is about eight years too late. 22:30:00 stackage is a preassembled body of haskell code that is guaranteed to work together 22:30:41 I watched the community deny there was a problem, produce horrible band-aid fixes that didn't work, etc. for a decade. 22:30:46 *play 22:31:01 Haskell is now in my past and remains there forever. 22:31:14 And programs written in Haskell are banned because I just don't trust them to work anymore. 22:31:23 Because literally NONE of the ones I've used did. 22:31:25 and now you're refusing to use something potentially useful like elm because of past frustrations with haskell's tooling and ecosystem 22:31:37 Fool me once ... 22:32:09 It has been my experience that if your haskell program compiles that it works. 22:32:09 You have no idea how many times I've heard " solves all those problems" from the Haskell community. 22:32:19 FSV of "works". 22:32:22 Darcs worked. 22:32:31 If you didn't mind 17-minute commits for trivial code changes. 22:32:48 Nobody I know would call that "working" in any meaningful way, however. 22:33:46 Cabal compiles. It sure as fuck doesn't "work" by any definition anybody would use that isn't already drinking the Kool-aid. 22:37:18 ttmrichter, thanks for the info :) 23:07:22 --- join: gravicappa (~gravicapp@h109-187-47-207.dyn.bashtel.ru) joined #forth 23:12:54 --- quit: dys (Ping timeout: 245 seconds) 23:19:48 --- join: dave0 (~dave0@069.d.003.ncl.iprimus.net.au) joined #forth 23:19:53 just verified that allocated tasks function properly 23:59:59 --- log: ended forth/19.06.29