<tp>
similar, as SARS-CoV-19 spreads here most biz is shut down, many thousands let go from their jobs etc
<tp>
our infection graph is much like the USA in terms of increase
<tp>
forthwise progress proceeds at my usual snails pace
<crab1>
I haven't seen a whole lot of layoffs around my area, most jobs seem to be keeping people through everything
<crab1>
mostly the people losing jobs are choosing to in these parts
<tp>
tabermann has discovered a new hobby called 'interrupts' on cortex-m4, it's a lot of fun he says ;-)
<rdrop-exit>
hi crab1
<crab1>
Evening
<crab1>
I would say night, but it doesn't really work as a greeting
<rdrop-exit>
My wife is focused on getting face shields to health care people
<rdrop-exit>
I've been focused on reorganizing all my home storage
<rdrop-exit>
going through all my boxes of books and such
<crab1>
how many books are you stashing?
<rdrop-exit>
I have thousands of books, magazines, and boardgames
<rdrop-exit>
All my shelves are full, the rest are in boxes
<crab1>
I only have 30+-5 books :(
<tp>
reorganisation is good, my workshop needs it badly
<rdrop-exit>
You're probably young, nowadays physical books aren't necessary with ereaders and such
<rdrop-exit>
Each time we moved countries I purged a portion of my library
<rdrop-exit>
It's time I do a big purge
<crab1>
I am young, but I prefer textbooks and pleasure reading to come in physical copies
<crab1>
If I need to read a paper I'm gonna probably print it if I can
<rdrop-exit>
I prefer paper too, but it's not very practical nowadays, the more you have, the longer it takes to find something on your shelves, or dig up an old tome from your boxes
<rdrop-exit>
Not to mention the yellowing of some of the old high acid papers
<rdrop-exit>
A good portion of my technical books are outdated now
<rdrop-exit>
e.g. I just found 3 books on Unix typesetting and document formatting with troff
<crab1>
Some things won't become outdated though
<rdrop-exit>
Yes, and some forgotten approaches can become relevant again as technology tradeoffs change
<crab1>
I wonder how many use forth regularly
<rdrop-exit>
I even found a bunch of books on nomography, some published before I was born
<crab1>
I also wonder why forth seems to have a terrible reputation
<rdrop-exit>
Probably a few hundred at most\
<crab1>
nomography could be fun
<rdrop-exit>
and slide rule design
<rdrop-exit>
Forth is different
<crab1>
how you mean forth is different
<rdrop-exit>
Different from what people are used to and comfortable with
<crab1>
I'm not sure forth is for me
<rdrop-exit>
Very open-ended
<crab1>
I think I need some modification of it
<crab1>
open ended is good and I like the similarity to combinators
<crab1>
but I don't particularly like the existence of parsing words as they don't compose, some other things like that rub me backwards
<rdrop-exit>
what parsing words?
<crab1>
And I can't seem to find a looping mechanism I'm satisfied with
<crab1>
parsing words as a whole I do not like. I don't like `:` because it does not take arguments from the stack
<rdrop-exit>
Why do you need it to?
<crab1>
purity I suppose
<rdrop-exit>
any practical reason?
<rdrop-exit>
You can have both, just make a : variant when you run into a use case where you actually have a practical need for it
<crab1>
It is easier to reason about a language that works in a consistent way
<rdrop-exit>
But Forth is open-ended, you can extend or change as your actual needs dictate
<crab1>
and yeas forth works in a consistent way, but behind a veil(though a smaller veil than other languages)
<crab1>
And I would like to retain the open-endedness and extensibility, I just want a language where the words of the language always operate on the words (or results of those words) immediately before them
<rdrop-exit>
I don't think of Forth as a fixed language, or even as a language, I can adapt it to my needs of the moment, so I don't worry about it
<rdrop-exit>
When you need something radically different, you can always metacompile or target compile a new Forth from one of you're older ones
<rdrop-exit>
* your
<rdrop-exit>
That's more efficient than doing meta stuff at runtime
<crab1>
wdym doing meta stuff at runtime
<rdrop-exit>
very abstracted manipulations at runtime, such as functional programmers seem to crave
<crab1>
highly abstracted manipulation at runtime would not be something I'd want
<crab1>
If anything I'd like to simplify more
<rdrop-exit>
can you give a practical example?
<crab1>
Of how I want forth simplified?
<rdrop-exit>
yes
<tp>
I'm definitely an Imperative programmer
<rdrop-exit>
Me too, I use lots of exclamation points in my code ;-)
<tp>
I want all the information and I don't want to hide it
<tp>
I dont have to look at it all at once but I want everything easily available
<rdrop-exit>
I find that most surface simplifications people crave actually increase the overall complexity of the implementation
<tp>
I find that most surface simplifications exclude vital information required to understand whats happening
<rdrop-exit>
exactly, too much abstraction rots the brain
<tp>
in the 1800's when I went to school, if I solved a equation without showing how I got there, the teacher was very unhappy and would fail me
<rdrop-exit>
Most libraries and APIs drive me nuts
<tp>
my teachers would be very unhappy nowadays trying to read functional examples people give when showing their code
<tp>
same here
<tp>
when I wrote my Forth LMT-01 temperature sensor project I looked for code examples online, there was understandably nothing for Forth, but I was surprised to find only two examples in C, lots of C user problems getting the sensor working, and nothing for Arduino
<tp>
both online projects used the lame Ti reference example which is a single sensor running continuously
<tp>
the sensor is in fact incredibly simple, but many simple things, it's not that easy to use well
<tp>
+like
reepca has joined #forth
<tp>
so the C and Arduino world just stopped right there
<tp>
they continued with the horrific and ancient/obsolete Dallas Semi DS18B sensor which someone had written code for many years ago
<rdrop-exit>
they don't crave understanding, it's rare to find people who grok what they're using, which is dangerous
<tp>
it's a world of 'code reuse' and 'libraries' of which both terms are just a joke to me
<crab1>
I want a language with a compiler that matches this pseudocode: `: source->xt (source--xts) first-token dup in-dict? if get-xt endif ; : compile source->xts opt to-machine ;` so if something is not in the dictionary, then it is a literal, and its xt is itself, to-machine creates a call to each xt in the dictionary and that's your program
<crab1>
idk if that's entirely illogical, I'm trying to voice a vague and unclear concept that floats around my head sometimes
<crc>
Good evening
<crab1>
evening sir
<rdrop-exit>
hi crc
<rdrop-exit>
crab1, so you want a pure compiled language?
<crab1>
Maybe, I'm not certain on that point
<crab1>
but the one I describe is pure compiled, yeah
<crab1>
I think that I would one one or the other though, either pure compiled or pure interpreted
<crab1>
want one or the other*
<tp>
g'day crc
<crab1>
tp: does arduino use C?
<rdrop-exit>
Pure compiled, you lose Forth's interactivity and overall simplicity, pure interpreted you make the system impratically slow
dave0 has quit [Quit: dave's not here]
<rdrop-exit>
In Forth you normally try to hit a sweet spot between the extremes
<rdrop-exit>
it's one reason for the different threading schemes
<rdrop-exit>
Wasn't strongForth also compile-only, I don't remember
boru has quit [Disconnected by services]
boru` is now known as boru
<rdrop-exit>
There have been a few attempts, but I find them futile
<rdrop-exit>
In ColorForth the editor is made smarter so the interpreter/compiler can be simpler/faster
<crc>
rdrop-exit: not as I remember it
<crc>
strongforth still has STATE and immediate words
<rdrop-exit>
crs, thanks, my memory is hazy, I only read about it
<rdrop-exit>
* crc
<crab1>
can you do interpret only if you have a word compile and can call pre-compiled words that you've made with compile?
<crc>
Interpret only would be *slow*
<rdrop-exit>
The extreme of interpret-only is an interactive macro processor
<rdrop-exit>
I wrote one once, forth-like, all parameters were strings, all outputs were strings
<rdrop-exit>
TeX is kinda like that in a way
<rdrop-exit>
crab1, I don't understand your question
<crab1>
interpreted forth with a word compile and a word execute, where compile produces machine code and execute executes machine code. Almost like forth is your shell, and you have a compiler program and a means to execute compiled programs
<rdrop-exit>
that's how most subroutine threaded Forths work if I understood you correctly
<rdrop-exit>
In a subroutine threaded forth with inlining,
<rdrop-exit>
: foo ( -- ) do-this do-that ;
<rdrop-exit>
lays down machine instructions
<rdrop-exit>
and interactively typing foo executes those machine instructions
<crab1>
but then any interpret-only language with compile() and a call instruction to the start of that compiled program can run compiled programs with the call instruction as the only overhead
<rdrop-exit>
compiling the whole program every time you want to run it?
<crab1>
not necessarily, you only need to do it once, you could do `program compile dup dup call call call` (where : compile (source--address))
<crab1>
and if you have a place to store the binary permanently then you just need to know where it is
<crc>
Retro would be `[ ... ] dup dup call call call`
<rdrop-exit>
I've never needed :NONAME
<crab1>
I've become used to seeing `:foo ... ;` and thinking retro
<rdrop-exit>
crab1, you seem to be intent on making hoops to jump through
<crab1>
wdym?
<rdrop-exit>
whay not just do
<rdrop-exit>
: program ( -- ) ... ;
<rdrop-exit>
program program program
<crab1>
that requires an infrastructure that both compiles and interprets by default, all I was trying to say is that an interpreted only language can gain the advantages of compilation without a huge cost
<crc>
The infrastructure to handle compiling doesn't need much
<crab1>
and all the interpreted language needed was call and a compiler
<rdrop-exit>
a pure interpret-only language can't be compiled unless you constrain what it's allowed to do during interpretation
<crab1>
what constraints do you need?
<rdrop-exit>
the compiled version can't have the same semantics as the interpreted version unless you constrain what the interpreted version is allowed to do, if that were not so, then you're compiler would have to completely simulate your interpreter
<rdrop-exit>
basically the spectrum of interpretations, goes from pure direct interpretation (of strings), through compilation of various intermediate codes, all the way to pure overall compilation to native code
<rdrop-exit>
most of the range is covered by the various intermediate codes, except for the two extremes
<tabemann>
hey guys
<crab1>
Hello
<tabemann>
I got interrupts working for USART2
<rdrop-exit>
pure direct interpretation is like having a string-based CPU
<rdrop-exit>
it basically does macro expansion
<rdrop-exit>
hi tabemann
<tp>
tabemann, awesome!
<tabemann>
now I need to get sleeping working
<tabemann>
tp: the tricky part was that it was occasionally doubling characters
<tp>
oh!
<tabemann>
I fixed that by only reading one character per interrupt, and by making my circular buffers interrupt-disabling-free
<tabemann>
so I had to figure out an algorithm for circular buffers that could be simultaneously accessed by the interrupt handler and the task code
<tp>
yah the old stm32 is pretty fast
<rdrop-exit>
crab1, Part 1 of "Interpretation and Instruction Path Coprocessing" by Dabaere & Van Campenhout has good overview of the spectrum of possibilities
<rdrop-exit>
it discusses various interpretation schemes and their intermediate codes
Keshl has quit [Read error: Connection reset by peer]
Keshl has joined #forth
<pointfree>
How is everyone? Hello forth crew
<rdrop-exit>
hi pointfree!
<pointfree>
o/ rdrop-exit!
<rdrop-exit>
all ok here, my wife and I are quarantined at home, and our kids are each quarantined in their respective homes
<pointfree>
How are you holding up in this mysterious virus quarantine?
<rdrop-exit>
haven't run out of espresso and cigarettes yet, so ok
<rdrop-exit>
yourself?
<proteus-guy>
rdrop-exit, that's an excellent book. Definitely gives me ideas for fpga design of a forth-based stack processor.
<rdrop-exit>
cool, glad you like it
<pointfree>
I decided to try psychogeography myself. I went on the Foster City bay trail by apartment and to get lost deliberately. The tech campuses are ghost towns. It's kinda spooky. WIldlife is reclaiming the parking lots. I guess that's what it looks like to be the last man on earth.
<pointfree>
I'm assembling the gigatron https://gigatron.io/ I bought from Ken Boak on Forth Day. I got some grab bags of discrete components from amazon before they went out of stock.
<rdrop-exit>
wow, that's neat!
<tabemann>
back
<rdrop-exit>
8-bit RISC architecture, his own ISA?
<pointfree>
I like that I can have a forth desktop computer with video output, keyboard, etc with discrete components. It makes it easy to change things as needed and I don't depend on electronics IC supply chain.
<tabemann>
okay, I'm baffled
<tabemann>
my code a moment ago didn't work
<tabemann>
then I added some test code, then removed all the test code
<tabemann>
and now it works
<rdrop-exit>
looks like a fun project pointfree
<rdrop-exit>
tabemann, must be gremlins
<tabemann>
zeptoforth is kinda funky at times
<tabemann>
for instance, if you erase the flash when basic.fs hasn't been loaded yet, it reboots fine
jsoft has quit [Ping timeout: 256 seconds]
<tabemann>
if you've loaded all the recommended code, though, erasing the flash causes it to lock up, but only after it has erased the flash - so if you press the reset button it works fine
<tabemann>
except under some circumstances I do not gather the nature of, even that is not true
<tabemann>
and you need to use something like st-flash or openocd to reflash the device to unwedge it
<tabemann>
I did get interrupt-driven IO working
<tabemann>
and it should be sleeping when it's not doing anything now
<rdrop-exit>
cool
<tabemann>
aha
<tabemann>
that's why my systick was so damn fast
<tabemann>
the TENMS calibration field is for the default clock of the processor
<tabemann>
8 MHz
<tabemann>
but it doesn't take into account the fact that I bumped the clock up to 45 MHz
Zarutian_HTC| has quit [Ping timeout: 256 seconds]
<tabemann>
*48 MHz
gravicappa has joined #forth
dddddd has quit [Remote host closed the connection]
jsoft has joined #forth
jsoft has quit [Max SendQ exceeded]
jsoft has joined #forth
jsoft has quit [Max SendQ exceeded]
jsoft has joined #forth
crab1 has quit [Quit: WeeChat 2.7.1]
nonlinear has quit [Ping timeout: 268 seconds]
nonlinear has joined #forth
mtsd has joined #forth
mtsd has quit [Quit: Leaving]
rdrop-exit has quit [Read error: Connection reset by peer]
iyzsong has quit [Ping timeout: 240 seconds]
dddddd has joined #forth
xek has joined #forth
jsoft has quit [Ping timeout: 265 seconds]
proteus-dude has joined #forth
proteus-guy has quit [Ping timeout: 260 seconds]
<tp>
tabemann, I find when I set the systick interrupt period too fast the mcu becomes unreliable as least as far as the terminal is concerned
<tabemann>
I've found that too
<tabemann>
what I was actually doing was slowing down the systick
<tp>
currently my 75Mhz f0 interrupts every 0.1mS and is fine
<tp>
same with a M3 at 75Mhz
<tabemann>
because I had set the systick for what would be 10 KHz were the processor running at 8 MHz not 10 KHz as the processor is actually running at 48 MHz
<tp>
understand
<tabemann>
I was wondering why my blinkies were blinking so fast
<tp>
there are a lot more clock options on the L series
<tp>
hahah
<tp>
that the cool thing about embedded, it's easy to verify stuff in the real world
<tp>
I did an Hackaday aticle (ages ago) about using a old moving coil meter to indicate MCU load/usage which they actually published
<tp>
but Forth wasnt mentioned as usual
<tabemann>
well, now that I have gotten interrupt USART IO working, I should go on to port zeptoforth and its add-ongs to the F407
<tp>
what you do is have a short blocking delay drive a gpio and adjustable series resistor into a microamp meter, set it to show full scale on the meter. After that as other things take up cpu time the meter indicates less
<tabemann>
but unfortunately, I have work to do this weekend (does my boss have any clue about "work-life balance?") that will have to wait
<tp>
what does the USART interrupt on ?
<tp>
bosses generally dont
<tp>
I'm thinking of making up a nice small box for my dev system which is just a Disco board with wires that easily fall off atm
<tabemann>
USART2_ISR_TXE, USART2_ISR_RXNE, and USART2_ISR_ORE
<tp>
i'll use my 32 pin QFN header for the chip, add a meter for cpu usage, decent pins or terminals for gpio etc
<tabemann>
I'm really happy about getting interrupt IO with sleeping working
<tabemann>
mind you it wakes up at a 10 KHz frequency....
<tabemann>
(thanks to systick)
Bunny351 has left #forth [#forth]
<tp>
it's a milestone for sure
<tabemann>
the nice part about this is that the interrupt IO does not interfere with multitasking
<tabemann>
so it is safe to use within the multitasker
<tp>
I'm still cautious of interrupts but so far no problems
<tabemann>
yeah, some stuff was tricky
<tp>
are you sure the interrupt is actually working ?
<tabemann>
tp: my IO path now requires the interrupts to send or receive anything at all
<tabemann>
because, unless you directly call the "legacy" serial driivers directly, everything goes through the interrupt
<tabemann>
(the "legacy" serial driver is what is used on bootup)
<tabemann>
unless the interrupt-driven one has been installed
<tp>
aha
<tabemann>
ugh
<tabemann>
I still have occasional glitches on doing the install of all the standard code
<tabemann>
occasionally the IO fucks up
<tp>
it's complex stuff
<tabemann>
and I did make sure to put disable-int ... enable-int in my interrupt handler...
<tabemann>
when I try to elicit the issue now, though, it works just fine
<tp>
perhaps some USART registers have junk in them ?
<tabemann>
sometimes I just wonder if I'm accidentally hitting the keyboard - I do do that at times - and that causes it to fuck up
<tabemann>
nah, because it's loading just fine before it installs the interrupt IO
<tabemann>
or starts the multitasker
<tp>
i think it's hard to test usart code on the usart one is using for the termina
<tp>
perhaps test it on a second non terminal usart ?
<tp>
ahh, you cant because you use the usb serial ?
<tabemann>
yeah
<tabemann>
well I could attach serial to a serial to USB converter, which I do own but would have to find
<tabemann>
but I don't have a suitable cable, and don't want to solder anything into my board
<tabemann>
*onto
<tp>
good idea
<tp>
you need a box of the cheap and crappy female to female jumper cables
<tp>
so called 'dupont cables'
<tabemann>
okay, I should get to work
<tp>
okies, cya!
tabemann has quit [Ping timeout: 256 seconds]
xek_ has joined #forth
xek has quit [Ping timeout: 265 seconds]
Zarutian_HTC has joined #forth
reepca has quit [Read error: Connection reset by peer]