00:06:24
##forth
<tpbsd>
veltas, thanks!
00:07:17
##forth
<tpbsd>
it's a lot like using C instead of Assembler with no includes file
00:08:04
##forth
<tpbsd>
and it saves space in small embedded because it doesnt use constants to link the labels to the absolute addresses
00:09:51
##forth
<tpbsd>
so the programmer gets all the easy stuff like alphanumeric labels that are CMSIS-SVD compatible, and the mcu gets 'magic numbers' which are a no-no for maintainable small embeddedForth code
00:10:17
##forth
<tpbsd>
the mcu doesnt understand or want all the human stuff
00:29:26
##forth
<veltas>
Very true
00:31:27
##forth
<tpbsd>
I tried converting that source to absolute addresses manually using my other project "svd2db" and it's horrendous, I gave up after 1/2 hr as it was very tiresome
00:32:18
##forth
<tpbsd>
I wanted to obtain a memory usage reading for Plang2 and manual coding, but it's just too hard
10:56:45
##forth
<anthk_>
morning
10:57:20
##forth
<anthk_>
thanks for the editor, veltas
10:57:38
##forth
<anthk_>
I'm so fed up of the pfe block support that I use forth-scr to convert text files into blocks
10:58:15
##forth
<anthk_>
ttps://github.com/ablevm/forth-scr
10:58:34
##forth
<anthk_>
I did a template with unix sh and that's it, just two for loops redirecting to a text file
11:07:21
##forth
<identity>
anthk_: [[ ]] is bash, not sh</pedantic>
11:09:01
##forth
<anthk_>
it works under ksh
11:09:54
##forth
<identity>
well, some gcc extensions work under clang too
11:10:09
##forth
<anthk_>
but thanks, I fixed it
11:19:01
##forth
<anthk_>
also I forgot about -lt | -gt instead of redirecting commands, I'm dumb
11:19:05
##forth
<anthk_>
it's monday :p
11:21:20
##forth
<anthk_>
I must confess that I alternate between Forth and Lisp in order to not get bored with either
11:22:15
##forth
<
anthk_>
not scheme nor common lisp, but zenlisp from http://t3x.org, because scheme it's fine but I've got bored with the "Concrete Abastraction book", at least with one chapter
11:22:38
##forth
<anthk_>
and Common Lisp has cool stuff but the 'loop' construction can be more complex than the whole Forth itself
11:22:41
##forth
<anthk_>
I am not kidding
11:23:00
##forth
<anthk_>
'loop' might be Turing complete by itself
11:23:55
##forth
<identity>
lisp, the bad parts: loop and format
11:24:32
##forth
<anthk_>
identity: common lisp, yes; scheme it's easier
12:29:14
##forth
<veltas>
anthk_: I'm the same, I alternate mostly to C
12:35:33
##forth
<deadmarshal_>
CL is so bloated compared to Scheme.
15:12:46
##forth
<veltas>
anthk_: Shame zelgomer's not in here because he had some good tips for using shell to convert between blocks/files
15:14:18
##forth
<xentrac>
he got too enthusiastic about politics and death threats
15:15:22
##forth
<veltas>
Leave off dead horses
15:16:42
##forth
<xentrac>
as long as it's only dead horses and not dead people, we're doing fine
15:17:31
##forth
<xentrac>
I'd just as soon not have people around who are threatening other channel members with death based on their guesses about political alignment
15:28:04
##forth
<crc>
good morning
15:29:12
##forth
<xentrac>
hiya
15:30:09
##forth
<xentrac>
hooray, dpans is back!
15:30:57
##forth
<crc>
sorry, forgot to restart it after the openbsd 7.7 upgrade completed :(
15:34:06
##forth
<xentrac>
it's probably unusual to put IRC bots in /etc/rc and family
15:37:44
##forth
<crc>
I'll probably set them up as proper daemons at some point
15:47:21
##forth
<anthk_>
veltas: I just use forth-scr for that
15:47:39
##forth
<anthk_>
altough maybe dd would suffice, or xxd, or plain printf
15:47:47
##forth
<anthk_>
or sed/awk
15:49:47
##forth
<vms14>
how it was to use the dpans bot?
15:50:13
##forth
<veltas>
anthk_: Try fold command maybe, for converting a block to file
15:50:29
##forth
<veltas>
I seem to remember that was one of the good suggestions
15:50:54
##forth
<xentrac>
dd does have some options that seem relevant but I don't remember if I was able to get it to provide useful output
15:51:18
##forth
<xentrac>
but I wanted the shadow screens alongside
15:51:26
##forth
<xentrac>
and dd definitely can't do that
15:51:54
##forth
<veltas>
dd is rightly hated
15:52:41
##forth
<veltas>
I had the great idea of using dd for modifying binary files once, and after a big rabbit hole it turns out that it claims to modify one byte and then just modifies loads after that as well
15:52:55
##forth
<xentrac>
really? I'd never heard of that
15:53:05
##forth
<veltas>
So don't use 1 byte at a time, it claims to support it and doesn't
15:53:29
##forth
<veltas>
And if it can't do that what can it do, I need to trust the commands I use with my important data
15:53:37
##forth
<anthk_>
which dd? gnu dd or bsd?
15:53:57
##forth
<anthk_>
also bear in mind dd has many options for files with holes and such
15:54:03
##forth
<veltas>
GNU I think
15:54:11
##forth
<veltas>
But it's a POSIX standard so should be same everywhere
15:54:14
##forth
<veltas>
Unfortunately it's not
15:54:43
##forth
<anthk_>
conv=notrunc maybe?
15:55:02
##forth
<xentrac>
dd cbs=64 conv=unblock if=hanoi.blk seems to do the right thing
15:55:18
##forth
<veltas>
anthk_: Maybe yeah
15:55:58
##forth
<xentrac>
I'd never heard of anyone having problems using dd but generally people only use it for writing disks
15:56:11
##forth
<veltas>
Certainly that's what it's *for*
15:56:37
##forth
<xentrac>
it's also for converting between EBCDIC and ASCII or swapping bytes apparently
15:56:47
##forth
<veltas>
today I learn
17:36:47
##forth
<anthk_>
uhm, after some thinkering, I'll use eforth under subleq/muxleq for starting forth exercises
17:37:36
##forth
<anthk_>
as I enabled do...loop, it might work for the 99% of the online book
17:38:00
##forth
<anthk_>
on blocks, I have them... but in subleq's RMA
17:38:01
##forth
<anthk_>
RAM
17:38:13
##forth
<anthk_>
but well, I can fill them with the 'editor' word, so it's fine
17:38:57
##forth
<hello-operator>
You could modify the VM so it automatically saves the image on exit
17:42:16
##forth
<hello-operator>
I think colorForth did something similar, "BLOCK" was defined as ": BLOCK 1024 * ;" (or whatever the colorForth equivalent is)
17:42:37
##forth
<hello-operator>
And you would just save everything at the end
17:44:40
##forth
<anthk_>
it's that, nothing fancy, subleq but with multiplex
17:45:21
##forth
<anthk_>
altough with a custom DEC image, not the base; I enabled float (altough I don't use it a lot), do...loop and a better 'see'
17:45:48
##forth
<anthk_>
at the muxleq.fth file, at the top, there are variables
17:45:58
##forth
<anthk_>
then: pforth < muxleq.fth > muxleq2.dec
17:46:07
##forth
<anthk_>
sorry, not pforth, pfe
17:49:07
##forth
<anthk_>
ah, muxleq must be created from itslef. Long wait for older machines, but much faster than subleq.
17:49:23
##forth
<anthk_>
yes, I did that, but I dpn't need a whole FS
17:49:42
##forth
<hello-operator>
You only need the different subleq.c VM
17:49:50
##forth
<hello-operator>
It saves the image
17:50:30
##forth
<hello-operator>
The makefile shows how to use it
17:51:24
##forth
<anthk_>
uhm wait
17:52:03
##forth
<hello-operator>
Sorry, you only need the different subleq.c not the entire ffs thing, take the code from that and add the muxleq stuff
17:52:38
##forth
<anthk_>
I could add the same to muxleq, it's just open a file at argv 2 right?
17:53:22
##forth
<anthk_>
muxleq it's just subleq with the mux if added
17:53:47
##forth
<hello-operator>
Not quite, it dumps the memory to the final file in the argv list so long as there is at least one file
17:54:07
##forth
<hello-operator>
"./subleq file.dec" would not save anything
17:54:40
##forth
<anthk_>
./muxleq new.dec disk.dec
17:54:40
##forth
<hello-operator>
but "./subleq file.dec new.dec" would, as would "./subleq file-1.dec file-2.dec new.dec"
17:54:52
##forth
<anthk_>
and then reuse disk.dec as the normal muxleq file?
17:55:04
##forth
<hello-operator>
yeah, that's what's in the makefile
17:55:09
##forth
<anthk_>
ah interesting
17:55:39
##forth
<hello-operator>
I guess it's because if it is running andd you hit CTRL-C it will not save as the mv command is never run
17:55:44
##forth
<anthk_>
it's kafkesque, eforth under subleq working more 'reliabily' than pfe
17:55:59
##forth
<anthk_>
brb
17:58:12
##forth
<xentrac>
anthk_: subleq is simple; consequently you'd expect it to be reliable, wouldn't you?
18:02:01
##forth
<hello-operator>
as muxleq has two instructions, logically it must be twice as unreliable :D
18:03:23
##forth
<anthk_>
you laugh, but it works
18:05:54
##forth
<hello-operator>
what problems are you having with pfe?
18:07:08
##forth
<hello-operator>
i've never used it, so i don't know how it compares
18:08:15
##forth
<anthk_>
sometimes the open block get lost after editing
18:08:24
##forth
<anthk_>
pfe tells me that I can't find my file anymore
18:08:45
##forth
<anthk_>
ok, muxleq working with the HD file
18:09:00
##forth
<anthk_>
this like a zen or something
18:10:44
##forth
<hello-operator>
ah right, so it's just the block layer that is the problem?
18:11:02
##forth
<hello-operator>
that's good it works
18:12:30
##forth
<anthk_>
I mean, I use open-blockfile foo.blk
18:12:32
##forth
<anthk_>
I launch
18:12:37
##forth
<anthk_>
edit-blockfile foo.blk
18:12:48
##forth
<anthk_>
I edit something, I run flush
18:13:16
##forth
<anthk_>
and later I run edit-blockfile foo.blk and pfe tells me that I can't open it, even by using open-blockfile
18:14:17
##forth
<anthk_>
it tells me 'non-existent file'
18:21:38
##forth
<hello-operator>
I can't even get it to compile (PFE) at the moment, not that I'm making a huge effort
18:48:50
##forth
<anthk_>
OS?
19:02:55
##forth
<hello-operator>
Ubuntu x86_64, ugghhh, now which version...
19:15:16
##forth
<cleobuline>
forthBot: LOAD ini.fth
19:15:16
##forth
<forthBot>
File ini.fth with date loaded
19:15:24
##forth
<cleobuline>
forthBot: DATE
19:15:24
##forth
<forthBot>
Mon June 2 19:15:24 CEST 2025
19:18:21
##forth
<cleobuline>
forthBot: PRINT-TIME
19:18:26
##forth
<cleobuline>
forthBot: PRINT-TIME CR
19:18:26
##forth
<forthBot>
19:18:2119:18:26
19:18:30
##forth
<cleobuline>
forthBot: PRINT-TIME CR
19:18:31
##forth
<forthBot>
19:18:31
19:26:51
##forth
<crc>
xentrac: might be good to edit to ##forth; some irc clients don't handle the redirection from #forth properly
20:27:37
##forth
<cleobuline>
forthBot: LOAD "ini.fth"
20:27:37
##forth
<forthBot>
File ini.fth with moon loaded
20:27:45
##forth
<cleobuline>
forthBot: MOON
20:27:45
##forth
<forthBot>
Phase de la lune pour Mon June 2 2025
20:27:45
##forth
<forthBot>
🌓 Premier quartier
20:27:46
##forth
<forthBot>
Premier quartier, la lune guide vos soirées !
20:41:53
##forth
<cleobuline>
forth: LOAD "ini.fth"
20:41:56
##forth
<cleobuline>
forth: MOON
21:22:08
##forth
<cleobuline>
forthBot: QUIT
21:22:08
##forth
<forthBot>
Environment for cleobuline has been freed.
21:22:20
##forth
<cleobuline>
forthBot: LOAD ini.fth
21:22:20
##forth
<forthBot>
File ini.fth with moon loaded
21:22:25
##forth
<cleobuline>
forthBot: MOON
21:22:26
##forth
<forthBot>
Phase de la lune pour Mon June 2 2025
21:22:26
##forth
<forthBot>
🌒 Croissant montant
21:22:26
##forth
<forthBot>
Une jeune lune, un nouveau depart a Paris !
21:22:27
##forth
<forthBot>
45% illuminee
21:25:36
##forth
<xentrac>
crc: sorry, too late to edit
21:27:00
##forth
<crc>
ok, wasn't sure what the limits are on hn
21:35:44
##forth
<veltas>
xentrac what are you talking about re character assassination
21:36:30
##forth
<veltas>
I've said before anyone in the UK, or who can work for the UK, who isn't Russian, Chinese etc can send CVs to me
21:38:04
##forth
<veltas>
I work in embedded mostly writing firmware for embedded controllers, Intel and ARM SoCs; can potentially refer you if you're good
21:38:14
##forth
<veltas>
That said I don't think we have any openings at the moment
21:43:37
##forth
<xentrac>
2 hours
21:43:56
##forth
<xentrac>
veltas: oh, that's just what I call the site
21:44:28
##forth
<xentrac>
because three or four comments down in any thread you can always find people calling each other "disingenuous", "trolls", "LLMs", etc.
21:46:07
##forth
<xentrac>
it's unusual to see things like "commie"
22:02:13
##forth
<veltas>
I've noticed the most prolific HN users tend to deride the site the most, personally I think the site's pretty good despite some bad users
22:02:41
##forth
<veltas>
Then again I've frequented 4chan for many years so my benchmarks might be different
22:09:06
##forth
<veltas>
The content's often interesting/insightful, but for some reason there's a competition to be as negative as possible about the site and talk about it in euphamisms
22:31:48
##forth
<tpbsd>
veltas, don't discounts attempts by certain groups to 'cancel' this ch
22:32:18
##forth
<tpbsd>
veltas, some people just hate everything they dont own
22:32:41
##forth
<tpbsd>
in the olf days we used to call them 'trolls'
22:35:38
##forth
<veltas>
To add context tpbsd, I am talking about the website news.ycombinator.com, not this channel
22:36:45
##forth
<tpbsd>
oops
22:37:53
##forth
<tpbsd>
apologies for talking out of turn
22:45:00
##forth
<veltas>
No need to apologise
22:52:25
##forth
<tpbsd>
veltas, well my Neovim Mecrisp-Stellaris IDE is working very well and I've found a bug in my Plang2 system already, looks like a character escape problem which I would not have found so easily were the IDE not based on nvim
22:54:04
##forth
<tpbsd>
Plang intelligently creates Forth statements based on the cmsis-svd bitfield 'Access Rights' as theyre one of three types as youd know
22:54:38
##forth
<tpbsd>
ie no point creating a read statement for a write only bitfield
22:55:41
##forth
<veltas>
Have you got any projects planned to test this IDE?
22:55:51
##forth
<veltas>
Maybe you should upload a video demo to YouTube
23:02:15
##forth
<tpbsd>
veltas, yes all the above
23:02:50
##forth
<tpbsd>
Ive made a thermoter using the LMT01 two term digital sensor chip using it
23:02:56
##forth
<tpbsd>
thermometer
23:22:13
##forth
<veltas>
Nice
23:22:26
##forth
<forthBot>
Environment for cleobuline inactive, freeing...
23:47:45
##forth
<veltas>
Programming is actually quite hard, don't let anyone say otherwise
23:58:08
##forth
<tpbsd>
veltas, it does get interesting when one is building advanced software tools for development use
23:59:19
##forth
<tpbsd>
so now I will have to raise a trouble ticket on this bug, I think one of my parsers is deleting the appending '@' on a transform