00:00:00 --- log: started forth/20.04.08 00:00:10 mtsd, lina is made by Albert Van Der Horst, hes really active and well respected in the Forth community on C.L.F 00:00:28 rdrop-exit, why not? 00:01:04 crab1, different contexts 00:01:43 mtsd, Ive started learning Retro for Linux, I'm really impressed: http://forth.works/book.html#retro-a-modern-pragmatic-forth 00:02:37 Ah, I see. I got the impression that Lina was made by someone who knows what he is doing 00:03:01 mtsd, definitely, Albert knows more about Forth than I ever will 00:03:01 I'll have a look at Retro too, thanks tpbsd 00:03:12 rdrop-exit, I think the expectation is reasonable 00:03:33 I sent Albert an email some time ago, thanking him for the work. And wishing him well in these times 00:03:36 mtsd, the thanks for trtro goes to our own #forth CRC who is the creator 00:03:51 crab1, ignoring context, or pretending it doesn't matter, is not a good idea 00:03:51 trtro = Retro 00:03:57 --- quit: webchat9 (Ping timeout: 265 seconds) 00:04:58 mtsd, awesome, Albert seems like a great guy, like all Forth people :) 00:06:11 I don't want to ignore context 00:07:36 I want to have guarantees about context 00:09:46 a word may only be present in a valid context 00:10:59 crab1, you are expecting a word to be interchangeable with it's definition 00:11:43 yes 00:12:42 tpbsd, yes. Forth people do seem great. :) 00:13:11 crab1, it is not a realistic expectation for all words 00:14:19 Can you think of an example with a word that I cannot expect that from? 00:14:26 mtsd, one thing I noticed is that Forth people don't descent on a new poster if say he's a C user, in fact most Forth people seem familiar with C anyway 00:14:56 and try and convince his that Forth is the ONLY language he should ever use 00:15:14 The overall tone is friendlier 00:15:52 but mention Forth in a predominately C forum and youll get buried in attacks 00:15:59 mtsd, I think most Forthers are older than other groups too, that doesn't hurt 00:16:33 More experienced, well-rounded personalities 00:16:58 Does not feel the need to prove themselves as much as other groups, perhaps 00:17:43 it seems to me that Forth people have a very wide experience, theyre comfortable with many methods and languages, no need to get all fanboy 00:18:29 Exactly! Lack of fanboy-ism 00:18:42 I think most language fanboys only know the one language theyre so fanatical about 00:20:14 Probably true, in many cases 00:21:31 I found that the more Forth I did, the better my Perl progams became, perhaps due to my mental perspective on problem solving 00:22:48 Im at that point now where Im seriously considering using Retro instead of Perl, but haven't yet tried it 00:23:41 I have never used Perl 00:23:43 I might see how Retro goes as a Shell replacement for all the shell scripts I write 00:23:52 Interesting 00:24:06 I have to take a look at Retro 00:24:16 crab1, most compiler directives 00:24:46 can you give one in particular to talk about? 00:24:56 retro is different, pays to read the doc first. I couldnt do anything with it to start 00:25:20 : recur { -- }( -- ) myself jmpi, ; directive 00:26:18 tail recursion, lays downs a jump back to the beginning of the definition 00:27:18 some Forths name it differently 00:27:21 mtsd, and CRC is usually here as a OP so you can ask him questions about Retro and get a reply :) 00:27:28 Great! 00:29:04 mtsd, we were having a great off topic discussion late one night about how much the earths water level would rise if the Greenland Ice sheet melted. CRC immediately went and got some data then used Retro to calculate it. That program is now on his site in the examples section 00:29:19 crab1, the beginning of a definition only makes sense within a definition 00:30:25 --- join: dave0 joined #forth 00:34:19 --- quit: jackdaniel (Ping timeout: 256 seconds) 00:34:32 --- join: jackdaniel joined #forth 01:07:14 tpbsd, reading the forthworks web site now. OpenBSD and fossil. Nice setup :) 01:07:34 oh yeah, CRC uses fossil like me :) 01:07:41 I do as well. 01:07:46 oh really! 01:07:49 awesome! 01:08:08 Yes, very good tool. I like it much better than Git 01:08:08 did you mean "is a fossil like me"? 01:08:23 hahah 01:08:31 ;-) 01:08:44 oh yeah, it's a lonely life using Fossil in a world of GIT fanboys 01:09:07 rdrop-exit, youre a Zen Forth Guru, definitely not a fossil! 01:09:36 mtsd, it's a honour meeting another fossil user! 01:09:51 Thank you. I feel the same way :) 01:10:04 mtsd, you, me and crc make three! 01:10:40 mtsd, so clone his repo and build a Retro, thats what I did, it's flawless! 01:10:47 So, quite a number of the world's fossil users are also Forth people then ;) 01:11:35 heheh 01:11:46 3/3 cant beat that! 01:13:11 mtsd, here is something you may be interested in ? You know how one normally configures the "Project Name" after the repo is created, usually in the web server ? 01:14:27 mtsd, I auto create my Forth projects with a large shell script I call my 'project builder', and because Fossil has a proper database, I configure that at the Fossil repo creation stage with the script 01:14:51 Setting it all up at once? Nice 01:15:10 which means 0.1 second after the project creation, the "Project Name" is already done 01:15:52 rdrop-exit, can't you have something like `: recur (xt -- ) dup execute 3 back ;`? 01:16:02 mtsd, yeah, I have a script that does everything, no tedious manual fossil project creation for me 01:16:23 fossil can be tedious if one does all the steps manually 01:18:25 Good idea. I had not thought about that 01:19:07 fossil is awesome for automation, every single config is available thru the database 01:19:13 I just cloned retro 01:19:20 crab1, I'm not sure what your code means. Remember it's not executing (i.e. nesting) it's jumping back. 01:19:23 :) 01:19:38 I am, slowly, trying to move some things at work over from Git. 01:19:44 crab1, what would your envisaged system do with this: 01:19:52 : foo 2* ; 01:19:53 The stuff I am in charge of has been moved already 01:20:11 ... more definitions ... 01:20:25 : foo foo foo ; 01:20:46 mtsd, altho Retro runs in a VM of some kind, you can also compile it to run natively on bare metal I'm told 01:21:07 mtsd, interesting 01:22:09 We have a common setup. Git for source code, bitbucket for hosting, then some system for tickets and another one for wikis, docs etc. 01:22:27 mtsd, I follow tabemann's "Zeptoforth" project which as you may guess is hosted on GITHUB. I just do a git pull then a fossil commit 01:22:45 I think the coolest thing about retro is his gopher based blocks 01:22:47 Fossil replaces all of that. Running on our own server, just doing off-site backups of the fossil repos 01:23:00 mtsd, and with fossil you can do it all in one ? 01:23:09 Exactly! 01:23:10 mtsd, perfect! 01:23:17 using ZFS ? 01:23:41 No, but that would be a possible development 01:24:03 mtsd, I do and have had 15 minute snapshots running for about 2 years now 01:24:09 it's just awesome 01:24:21 No issues? 01:24:43 you can send zfs snapshots out remotely, even create a clone server thats up to date 01:25:49 mtsd, Ive had ZERO issues, OpenZSF is simply the most bulletproof filesystem Ive ever seen in 41 years of using PC's 01:26:02 OpenZFS I mean 01:26:44 Sounds interesting. We could use something similar 01:26:59 i honestly believe that there is nothing better 01:27:19 I dont even bother with a UPS now, and I get about 20 brownouts a year 01:28:00 rdrop-exit, the point was to have a word recurse that basically takes a function pointer, executes the function at the pointer, then jumps back to the beginning of recurse, which has a known size instead of jumping based on the size of the repeated function's definition 01:28:53 Thanks, tpbsd. I will check OpenZFS out and do some thinking 01:28:54 mtsd, zfs-tools provides a preconfigured 15 min LIVE snapshot so I only lose a max of 15 minutes work if something BAD happens 01:29:37 You are on FreeBSD, right? 01:30:01 mtsd, for me something BSD usually happens as a result of my typing, such as makeing every file in a 4GB /home read only 01:30:02 yes 01:30:06 FreeBSD 01:30:44 I did that about a year ago, had a moment of heart stopping panic and then remembered I had the snapshots 01:30:57 5 minutes later everything was fixed 01:31:07 Would be nice to move in that direction, investigate something other than Linux 01:31:21 Fantastic 01:31:25 well you can still use Linux with a ZFS server 01:32:05 crab1, sounds like a lot overhead compared to a simple jump 01:32:08 in fact Linus is really after getting control of ZFS because $billions could be made 01:32:18 linus = Linux 01:36:31 the overhead is not large 01:38:23 probably 5x or 6x runtime overhead 01:38:47 how? 01:40:20 : test ..... recur ..... ; ends up as 01:40:31 --- quit: cheers (Ping timeout: 252 seconds) 01:40:56 ...... jmp ...... ret 01:42:37 what does the machine code of your construct end up as? 01:43:16 --- join: cheers joined #forth 01:46:56 I think it's just 'dup call jmp ' 01:48:54 so the overhead would be 'dup call' 01:50:04 ? 01:50:48 why the qmark 01:51:18 back in a few out to get food 01:51:24 I don't get it 01:52:00 don't get what? 01:52:26 what your : test ..... recur .... ; machine code ends up being 01:52:46 ...... .... ret 01:53:38 you seem to be dup-ing the TOS, how did what you're dup-ing get there? 01:54:22 what's it for? 01:55:08 it is the address of the function you wish to repeat 01:55:56 I am proposing a word that takes another word and repeats it 01:55:57 which is the function the machine-code is part of 01:56:31 I am proposing a combinator, you would not be using it the same way 01:57:16 my recurse does not repeat the word it's in the definition of, that would require contextual information, which is what I'm trying to get rid of 01:57:29 instead recurse is a word that takes a word as an argument and repeats it 01:59:30 ok, which is a lot of overhead for each iteration compared to a jmp 02:00:13 plus one extra level of call nesting at the start and end 02:00:42 I would venture to guess 5 or 6x 02:01:34 more work at runtime 02:01:45 I think it's only like 3x + call nesting 02:04:14 anyway I think it is still reasonable overhead, even if 6x it's a 6 instruction overhead per iteration that's not a lot 02:04:20 and now I go get my food 02:04:41 bon appetit 02:09:20 What happens when you're definition has more than one RECUR ? 02:14:51 ah sorry, enjoy your meal 02:18:32 --- quit: rprimus (Remote host closed the connection) 02:38:39 with yours the word restarts at each recur, correct? 02:39:42 yes, a recur is basically a jump to the start of the definition 02:40:19 you can also have RECUR within IF .. THEN or whatever 02:40:47 but it would still jump to the beginning of the definition 02:41:09 In my Forths I usually also have conditional versions, ?recur and 0recur 02:42:21 I don't use recur that often but it's sometimes handy 02:42:52 : restart ( -- ? ) 02:42:52 preset try outer fallback " Restarting..." alert recur ; 02:44:41 oops I need to modify my definition, it needs to be more like : recur (xt -- ) dup push call pop 4 back ; 02:45:30 You can always replace a recur by using a begin ... again or similar loop. 02:47:24 how does you system deal with search order related situation like the one I posted earlier 02:47:31 begin ... again is better(for being context-proof) because it is already traversing the definition and can count what the jump should be, though that would be a costly implementation 02:47:40 wdym search order situation? 02:47:52 : foo ... ; 02:48:06 ... some other intervening definitions ... 02:48:13 : foo foo foo ; 02:48:52 so you mean how do we have words that can be replaced with their definitions in a situation like this? 02:49:40 yes 02:51:26 lets say the first FOO is : foo 2* ; and all intervening definitions call it, then we have a new foo which masks it 02:52:01 then we have more definitions defined using this newer FOO 02:55:13 --- join: mtsd_ joined #forth 02:56:38 if you have `: foo 2 * ; : four 2 foo; four : foo 4 *; four` I suppose the program would have stack effect ( -- 4 8) 02:57:57 --- quit: mtsd (Ping timeout: 260 seconds) 02:58:03 the stack effect of the second foo is ( x -- x*4 ) 02:58:20 since it executes 2* twice 02:59:11 I did not address ": foo foo foo" because that would have bigger differences in a system that allows drop-in definitions 02:59:35 what are drop-in definitions? 03:00:06 --- quit: mtsd_ (Ping timeout: 256 seconds) 03:00:12 definitions that can replace the word they define with no consequences 03:00:22 ah right 03:01:54 there will always be edge cases, the map is not the territory as chuck would say 03:04:58 I don't consider `: foo ; ... : foo foo;` to be a situation where drop-ins make sense because words are not called inside `: ... ;`, they are just recorded. So I think whatever scheme you choose to use for search order can work 03:05:27 that's why we have immediate words and compile-only words, and directives ( immediate compile-only) 03:06:29 anything that tries to blurr the distinction between compiling a definition and the content of a definition will require a lot abstraction and overhead 03:07:03 i.e. `: foo ... ;` does not contain words, it contains essentially a string, the identifiers are not called.(A word is an identifier that is being called) 03:09:26 what gives you that idea? the behavior of the compiler is to look up words, compile them or if they're immediate execute them, and turn numbers into literals 03:11:15 because the behavior of `:` is to put a word in the dictionary, not to compile a word or execute it 03:12:00 the behavoir of : is to laydown a header and set the compiler on its merry way with [ 03:12:25 sorry with ] ;-) 03:12:45 you can interrupt the compiler any time with [ 03:13:03 and set it back on its merry way with ] 03:13:42 : : ( -- )( -- ? ) header, ] ; 03:13:50 for example 03:14:35 Forth is not a top-down parsing language, it's a interactive interpreter/compiler 03:19:17 --- join: webchat9 joined #forth 03:21:00 I think my language would not work that way 03:21:48 ok 03:23:27 but if it did it would work as you said, `: foo 2 * ; 3 foo : foo foo foo; 3 foo` -> {6, 12} 03:24:47 so then you'd have a problem with the words that were defined in between the old foo and the new foo 03:25:29 with how you've put it, they are already compiled, so they should follow the first definition 03:26:44 yes but you no longer have the equivalency you were looking for with your "definitions that can replace the word they define with no consequences" 03:29:01 why? 03:31:07 let's say we have this situation: 03:31:13 : foo 2* ; 03:31:21 : test foo 1+ ; 03:31:47 : foo 16 * ; 03:32:06 typing at your Forth command line: 03:32:25 5 test . <11> 03:32:44 5 foo 1+ . <81> 03:34:05 you can't blithely replace test with its content anymore, which if I understood correctly is the equivalency you were after 03:34:32 maybe I misundersttod your goal 03:34:43 the workaround is that after compilation(in my fantasy language) the definition would not be foo 1+ anymore 03:35:43 as a compiler, we assume we can replace anything, so when we see : test foo 1+ ; we store its definiton as `2* 1+` 03:36:14 you're storing a string? like a macro processor? 03:36:42 --- quit: WickedShell (Remote host closed the connection) 03:37:44 well first how is a definition usually stored? I know: |header|name|X| how is foo 1+ turned into X? 03:39:19 I'm suggesting |header|name|machine code| where we consider machine code to be the definition 03:39:26 depends on the threading model you're using, it can range from 'tokens' (i.e. an integer) to machine code for your target CPU 03:40:10 ok 03:41:00 in the system I'm conceiving a definition is tokens until it is compiled, but when it is compiled, the definition is replaced with machine code 03:41:32 and we already said that : expr ; performs compilation unless it's marked otherwise 03:43:00 at what point does the conversion to machine code happen? Usually it's incremental, by the time you finish a definition you can already start using it 03:43:13 but anyway it matches its definition because "foo 1+" is not really its definition it's like a message to tell the compiler how to create its definition 03:43:36 a message? 03:43:58 for example, if I write a new definition: 03:44:34 : +speaker .... ; \ turn the speaker on 03:45:00 as soon as I've written it I can test it by typing +speaker 03:45:25 then I continue with my next definition, e.g. 03:45:39 : -speaker ... ; \ turn speaker off 03:45:47 and test that right away 03:46:43 compiling is incremental, I can add a word to my dictionary any time I want, and it's immediately available 03:47:41 the only time I recompile an entire dictionary is during meta-compilation 03:48:58 end even then it's usually not the whole thing 03:51:08 Normally Forth is not top-down, it's an interactive incremental compiler/interpreter/assembler/development-environment etc... 03:51:55 Total Interactive Control is the mantra 03:52:34 I imagine that I do not have an interactive interpreter/compiler, but an interactive text interpreter with a word compile that redefines another word to machine code with the same effect as the definition of the word at compile time 03:53:46 I guess you'd patch the older definitions, that's what the Forth on the Canon Cat does 03:54:46 (the new definition could occupy more space than the original) 03:55:54 The Forth on the Cat is kinda of a halfway house between a traditional Forth and a macro processor, since a redefinition results in a patch to the original definition 03:56:43 Yeah it would work kinda like that, but like a regular forth after you've compiled a word 03:57:03 (I think it was ITC but my memory's fuzzy) 03:57:11 --- join: iyzsong joined #forth 03:57:34 that is if I had a dictionary that didn't work entirely differently, but I haven't thought to much about that 03:57:46 The patching has a cost in speed and space of course 03:57:58 yes 03:58:28 really what I want is a combinator calculus and a means to make new combinators 03:58:32 and any word that depends on a patched word has to be retested 03:58:55 how academic of you ;-) 03:59:10 hey combinators are fast in hardware 03:59:38 and mathematics/academia often have the rigidity I want 03:59:52 fast compared to not having them? 04:02:25 not with the architectures we are faced with 04:02:50 kidding aside, Forth is all about having it your way 04:03:36 No I appreciate the discussion, you're good at making me think about the bits I fail to think about :) 04:04:06 cool, it's always nice to explore different possibilities 04:09:21 dinner time, keep on forthin' and stay healthy 04:09:26 --- quit: rdrop-exit (Quit: Lost terminal) 04:25:31 --- join: mtsd_ joined #forth 04:27:53 --- join: mtsd__ joined #forth 04:29:13 --- quit: mtsd_ (Read error: Connection reset by peer) 04:32:23 --- join: mtsd joined #forth 04:32:48 --- quit: mtsd__ (Ping timeout: 256 seconds) 05:32:15 tpbsd: as a clarification: retro runs on a virtual machine, but this can be built to run on raw x86 hardware. I have a C implementation and john_cephlapod has an assembly implementation of the vm for this 05:33:12 the x86 vm has support for interacting with the actual hardware directly, and I'm doing some things to make it easier to generate & run actual x86 machine code for parts that need that 05:34:04 (john's work will ultimately be the future basis for a standalone retro on x86, as the assembler he uses is written entirely in retro, so it will allow a fully self-hosting system to be built) 05:41:13 --- join: xek_ joined #forth 05:41:33 Hello crc, I cloned retro earlier today. Looks good! 05:41:40 Great work 05:43:13 thanks 05:43:31 let me know if you run into any issues with it 05:44:09 Thanks! 05:49:23 --- quit: mtsd (Ping timeout: 256 seconds) 05:55:11 --- quit: webchat9 (Ping timeout: 264 seconds) 05:55:37 Have any of you taken a look at ziglang.org ? It's becoming a C replacement for me 06:25:21 --- quit: iyzsong (Quit: ZNC 1.7.1 - https://znc.in) 06:27:08 --- join: dddddd joined #forth 06:31:00 I took a quick look. I don't see how is it interestingin any way. It only looks n00b-ish to me. 06:32:31 I am sure #ProgLangDesign will be very glad to discuss anything there is to it. 06:38:19 DKordic, he shows some pretty slick features in this presentation https://www.youtube.com/watch?v=Gv2I7qTux7g 07:02:32 iirc, zig isn't working on openbsd yet, so I'm unlikely to try it anytime soon 07:10:36 --- quit: Zarutian_HTC (Ping timeout: 240 seconds) 07:18:23 --- join: webchat9 joined #forth 07:26:14 --- quit: dave0 (Quit: dave's not here) 07:26:47 --- join: lisbeths joined #forth 07:27:14 Good morning, all. 07:39:35 --- join: Zarutian_HTC joined #forth 07:46:31 Hiya 07:47:45 also realize that video is way old, Zig is changing kinda rapidly 09:00:58 --- join: xek__ joined #forth 09:03:16 --- quit: xek_ (Ping timeout: 240 seconds) 09:05:57 --- quit: xek__ (Ping timeout: 256 seconds) 09:19:13 --- quit: reepca (Ping timeout: 260 seconds) 09:32:18 --- quit: crab1 (Quit: Connection closed) 09:53:25 --- join: xek__ joined #forth 09:59:00 --- nick: xek__ -> xek 10:54:34 --- join: gravicappa joined #forth 10:56:35 --- join: xek_ joined #forth 10:59:03 --- quit: xek (Ping timeout: 265 seconds) 11:34:27 --- quit: lisbeths (Remote host closed the connection) 11:45:15 --- quit: jsoft (Ping timeout: 256 seconds) 12:04:11 --- quit: webchat9 (Ping timeout: 264 seconds) 12:11:24 --- quit: Croran (Ping timeout: 260 seconds) 12:18:45 Zig is ugly but it does seem to have a lot of attractive features 12:19:15 Good luck training people to use it though, I'm stuck with C whether I like it or not 12:27:06 --- join: Croran joined #forth 12:40:57 --- join: deesix_ joined #forth 12:41:19 --- join: dddddd_ joined #forth 12:42:36 --- quit: deesix (Ping timeout: 240 seconds) 12:42:55 --- nick: deesix_ -> deesix 12:43:16 --- quit: dddddd (Ping timeout: 240 seconds) 12:43:23 --- nick: dddddd_ -> dddddd 13:18:13 --- join: WickedShell joined #forth 13:40:32 --- join: jsoft joined #forth 13:45:19 --- quit: xek_ (Ping timeout: 265 seconds) 14:02:41 --- quit: gravicappa (Ping timeout: 250 seconds) 14:35:53 its slow to compile though 14:36:00 why IS EVERYTHING SLOW TO COMPILE 14:43:48 --- quit: jsoft (Ping timeout: 258 seconds) 15:20:55 static analysis is hard, modern CPUs are made of sin so writing optimal asm is too hard for humans or dumb compilers 15:57:30 modern cpus are kludged to hell 16:04:01 shey guys 16:04:25 *hey 16:04:36 my nRF52840-DONGLE board arrived 16:45:57 --- join: dave0 joined #forth 16:50:58 why does go compile so fast though? 17:14:06 --- join: reepca joined #forth 18:01:17 tabemann, pretty small board ? 18:03:37 back 18:03:43 yah it's small 18:04:11 looks about the size of a usb stick 18:04:24 smaller in volume than most 18:04:48 thats how they get such a low price 18:04:54 (most USB sticks are thicker than it) 18:05:07 but hey, if youre doing software mainly it doesnt matter 18:05:16 yeah 18:05:44 right now I'm porting zeptoforth to a different Nordic Semi board, and will only after that's done port it to the dongle 18:05:55 plis it wouldnt be hard to solder a bank of headers, or wires 18:06:25 I figure the two boards will be pretty similar, like how the l476 and f407 are aside from low power modes and flash erasure 18:06:40 exctly 18:06:52 and usarts 18:07:09 (this is because the other Nordic Semi board has a Mecrisp-Stellaris port and the dongle does not) 18:07:17 --- quit: Zarutian_HTC (Ping timeout: 265 seconds) 18:07:36 actually the l476 and f407 are probably more different than most 18:08:09 the port from the l476 to the f407 was pretty pain free aside from the flash erasure mechanism 18:08:32 if you were porting between two F or two L boards the differences would only be possibly the usarts and flash 18:08:32 (which was completely different) 18:09:54 yes, different chips, even in the same series often have different flash controllers 18:12:31 the main problem I'm finding is that when converting the flash erasure mechanism from the l476 to the f407, I hard-coded the changes in basic.fs rather than breaking them out into separate source files, which I'm now regretting 18:13:32 aha 18:13:59 perfectly understandable 18:14:38 probably why matthias has a small number of files in each chip source directory 18:15:25 that's what I'm doing 18:16:01 . 18:16:01 âââ Makefile 18:16:01 âââ flash.s 18:16:01 âââ interrupts.s 18:16:01 âââ mecrisp-stellaris-stm32f051.s 18:16:02 âââ memmap 18:16:03 âââ terminal.s 18:16:05 âââ vectors.s 18:16:24 yes I saw 18:24:29 back 18:25:10 just fixed the erasure problems by going back in the log and pulling out my old erasure code for the L476 that I had overwritten 18:25:46 you didnt use the SCM for that ? 18:26:06 I didn't want to do a full revert 18:26:28 oh of course, it's buried in other code 18:27:24 do you also use git at work ? 18:27:28 yep 18:47:28 --- join: boru` joined #forth 18:47:31 --- quit: boru (Disconnected by services) 18:47:33 --- nick: boru` -> boru 19:19:34 --- join: Zarutian_HTC joined #forth 19:24:50 hey 19:31:20 tabemann, I'm backporting my latest F051 scd2forth bitfield improvements to other chips atm 19:31:27 ie : USART2_CR2_LBDL ( -- x addr ) 5 bit USART2_CR2 ; \ USART2_CR2_LBDL, lin break detection length 19:31:28 : USART2_CR2_ADD ( %bbbb -- x addr ) USART2_CR2 ; \ USART2_CR2_ADD, Address of the USART node 19:33:14 cool 19:34:45 tabemann, lemme know if you want a svd2forth + assembler equ file for your nordic chips 19:36:55 sure 19:37:19 --- join: iyzsong joined #forth 19:37:37 ill need to know the exact model(s) 19:37:50 of the chips 19:38:12 both the nRF52832 which I'm working on right now and the nRF52840 I plan on ultimately targeting would be nice 19:39:27 okies 19:40:06 vielen Dank 19:46:39 Stats for: nrf52.svd 19:46:39 This generates template.xml and all the stats, to customise edit template.xml and run make-stats.sh 19:46:39 65 peripherals 19:46:39 865 registers 19:46:39 2150 bitfields 20:06:44 thanks 20:11:01 oops, delete those, all wrong! 20:27:27 nope, theyre right! 20:31:32 tabemann, these are the peripherals in the nrf52 20:31:35 20:31:35 FICR 20:31:36 UICR 20:31:36 BPROT 20:31:36 POWER 20:31:36 CLOCK 20:31:38 RADIO 20:31:42 UARTE0 20:31:44 UART0 20:31:46 SPIM0 20:31:48 SPIS0 20:31:50 TWIM0 20:31:52 TWIS0 20:31:54 SPI0 20:31:56 TWI0 20:31:58 SPIM1 20:32:00 SPIS1 20:32:02 TWIM1 20:32:04 TWIS1 20:32:06 SPI1 20:32:08 TWI1 20:32:12 NFCT 20:32:14 GPIOTE 20:32:16 SAADC 20:32:18 TIMER0 20:32:20 TIMER1 20:32:22 TIMER2 20:32:24 RTC0 20:32:26 TEMP 20:32:28 RNG 20:32:30 ECB 20:32:32 CCM 20:32:34 AAR 20:32:36 WDT 20:32:38 RTC1 20:32:42 QDEC 20:32:44 COMP 20:32:46 LPCOMP 20:32:48 SWI0 20:32:50 EGU0 20:32:52 SWI1 20:32:54 EGU1 20:32:56 SWI2 20:32:58 EGU2 20:33:00 SWI3 20:33:02 EGU3 20:33:04 SWI4 20:33:06 EGU4 20:33:08 SWI5 20:33:12 EGU5 20:33:14 TIMER3 20:33:16 TIMER4 20:33:18 PWM0 20:33:20 PDM 20:33:22 20:33:24 20:33:50 pretty packed! 20:33:52 tpbsd: you pasted a fuckload of stuff 20:34:26 it's *your* chip 20:34:26 I'm surprised it didn't kick you 20:34:53 I have anti kick, don't you ? 20:35:10 oh, where it automatically slows down what you output? 20:35:29 besides it's relevant to the Forth youre working on, and the ch is dead quiet today 20:35:39 yeah 20:35:44 yeah, slow release of spam 20:36:23 others may be interested to see whats in that chip, not *everyone* here is a PC only forther 20:37:24 the EQU file will be delayed sadly, the XML format of the NORDIC SVD is different 20:39:14 I made my Nordic SVD2FORTH converter two years ago which predates my EQU generation 20:39:58 otherwise a release tarball for the nrf52 would be on my site now 20:41:02 --- quit: dave0 (Quit: dave's not here) 20:50:18 okay, I fixed some issues with zeptoforth 20:52:24 cool 20:58:33 know what I should do - make the event scheduler compatible with sleeping 20:58:56 because currently if you use the event scheduler it will spinwait 20:59:44 how can it if it's asleep ? 21:08:00 what I mean is that it will never sleep 21:18:54 now the nRF52832 code is up on github 21:19:44 already? 21:20:21 yep 21:20:54 haven't tried it yet though, but I suspect it should be enough to enable a quick port to the nRF52840 21:21:30 of course the reason why it was so quick was that there was an nRF52832 port of Mecrisp-Stellaris 21:21:55 ah yes 21:21:56 which is exactly why there's now an nRF52832 port of zeptoforth and not an nRF52840 one 21:22:16 there is a Mecrisp-Stellaris port of the nRF52840 21:22:24 it's just not on the Mecrisp-Stellaris site 21:22:33 maybe you can help there ? 21:22:40 let me find the url 21:22:42 that would be very helpful 21:37:20 okay, I should get to bed 21:37:46 if you find that URL, could you email me it? if you write in here I'll probably forget to look at the logs 21:38:34 and I should say thanks for testing zeptoforth on your f407 board 21:38:55 --- join: webchat9 joined #forth 21:50:26 --- join: jsoft joined #forth 22:30:18 oh, a pleasure, thanks for making it available! 22:34:24 --- join: gravicappa joined #forth 22:44:52 tabemann, Im having trouble finding it, this is the guy: https://github.com/rabbithat/nRF52_SimpleTxRxDemo 22:46:53 tabemann, matthias asked him in Deb 2019 "how are you coming along with your port to the nRF52840" but he never replied :( 22:47:02 Deb = Feb 23:15:29 --- quit: iyzsong (Ping timeout: 260 seconds) 23:30:42 --- quit: webchat9 (Quit: Leaving) 23:48:38 --- join: xek_ joined #forth 23:59:59 --- log: ended forth/20.04.08