jedb_ has quit [Read error: Connection reset by peer]
jedb has joined #forth
jsoft has joined #forth
_whitelogger has joined #forth
remexre has quit [Quit: WeeChat 2.7.1]
dddddd has quit [Ping timeout: 260 seconds]
jsoft has quit [Ping timeout: 256 seconds]
_whitelogger has joined #forth
siraben has joined #forth
siraben has quit [Changing host]
siraben has joined #forth
gravicappa has joined #forth
MrMobius has quit [Ping timeout: 264 seconds]
[1]MrMobius has joined #forth
jsoft has joined #forth
_whitelogger has joined #forth
andrei-n has joined #forth
dddddd has joined #forth
andrei-n has quit [Read error: Connection reset by peer]
TCZ has joined #forth
TCZ has quit [Quit: Leaving]
TCZ has joined #forth
jsoft has quit [Ping timeout: 240 seconds]
<veltas>
Today I keep thinking "what if we did not have X in Forth" and realising it's better to have it
<veltas>
Like the return stack, I think "what if we did not have return stack ops" and then I realise that's *how* you add control flow, and so we may as well expose the return stack for saving stuff anyway, it's free
<veltas>
Or "what if we didn't have immediate words" and only supported one effectively immediate word [ , well then you would have to make many words much larger to accomodate this switching of state
<veltas>
Just some car thoughts
TCZ has quit [Quit: Leaving]
<X-Scale>
"Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary." - Scheme R5RS
<crest>
tabemann: i don't
<crest>
tabemann: did you read my updates on stlink (1.6.1)
<crest>
oh they fixed the permission issue
<crest>
so maybe the lockdown wasn't intentional
<crest>
i added a pull request to reduce the logging on FreeBSD something reasonable
TCZ has joined #forth
andrei-n has joined #forth
Zarutian_HTC has quit [Ping timeout: 258 seconds]
<crest>
tabemann: i'm installing a debian VM to test swdcom on linux
<crest>
asking you to rebuild one commit at a time is just annoying for both of us
Chobbes has quit [Ping timeout: 272 seconds]
Chobbes has joined #forth
TCZ has quit [Quit: Leaving]
Zarutian_HTC has joined #forth
<tabemann>
hey
<crest>
tabemann: i fixed the swdcom build on debian
<crest>
the code is on github
<crest>
would you mind testing it on your system?
<crest>
if it works please update your pull request to just include the zeptoforth specific parts
xek_ has joined #forth
<crest>
tabemann: my freebsd usb logging fixes got merged as well
<crest>
that takes care of all regressions in stlink 1.6.1 from my point of view
<crest>
the next release should be useable on linux and freebsd unless something breaks again
Zarutian_HTC has quit [Ping timeout: 256 seconds]
<tabemann>
back
<crest>
tabemann: hi
<tabemann>
just got home
<tabemann>
you mean the stlink code?
<tabemann>
in the devel branch?
<crest>
in the develop branch
<tabemann>
swdcom now compiles without any changes
<crest>
the most important change was a single line #define
<crest>
#define _XOPEN_SOURCE 500
<tabemann>
yeah, I remember seeing that one out there
<tabemann>
why must they make it hard to use headers like that (GNU I'm looking at you)
<crest>
it stops glibc headers from pretending to be even stupider than they are
<tabemann>
in the name of "standards compliance" of course, I presume
<crest>
because the gnu tools are portable to different operating systems and each one is its own kind of stupid
<tabemann>
so they seek the lowest common denominator in stupidity
<crest>
the *bsd avoid a lot of this pain because they are complete operatings systems developed as a single project in a single repo
<crest>
e.g. in *bsd, solaris and macos the "official" interface to the system is API (and ABI)
<crest>
not the syscalls
<crest>
which is annoying for languages that target the syscall interface directly like go and rust
<crest>
e.g. rust was broken on freebsd 12.0 for months because rustc couldn't support changes to the syscalls and structs
<crest>
porting rust from the freebsd 11 syscall interface to the freebsd 12 syscall interface wasn't hard
<crest>
but expanding rustc's concept of a platform to allow code reuse between them was a long debate
<tabemann>
back
<crest>
do you want to touch up your swdcom pull request to include (just) what's still missing from my swdcom repo?
<tabemann>
I'm making a few changes right now to eliminate things like the definition of b+!
<tabemann>
which is now going into the zeptoforth kernel
<crest>
i just wanted to keep you up do date
<crest>
because i know how annoying it is to get ignored by opensource projects/developers
<tabemann>
is there any way you can drop the pull request and I can submit a new one with *just* my bootstrap_zepto.fs? I don't really know how to change pull requests after the fact
<crest>
afaik the pull request is the diff between the two branches
<crest>
so you could rebase your branch
<crest>
or just add new commits
<crest>
or abandon your original pull request and start a new one
<crest>
i wouldn't mind given the current state of swdcom
<crest>
the next two features i want to add are simple file uploads and stopping at string match in the output
<crest>
afterward i want to split swdcom into a daemon and clients
<tabemann>
how do you with github merge changes from an original branch under one user into a forked branch in another repository?
<crest>
i have no idea
<crest>
just start a new pull request if it's easier for you
jedb has quit [Ping timeout: 264 seconds]
TCZ has joined #forth
<crest>
and i ordered two stm32l476 disco boards as well
<tabemann>
kback
<tabemann>
I updated my branhc
<tabemann>
I had to make a change to the Makefile as it otherwise wasn't going to commit on my debian
<tabemann>
namely I had to add -I/usr/include/libusb-1.0
dys has joined #forth
<crest>
i added $(shell pkg-config --cflags libusb-1.0) to deal with that to the GNUmakefile
gravicappa has quit [Ping timeout: 264 seconds]
Zarutian_HTC has joined #forth
<tabemann>
back
<crest>
please leave the Makefile for BSD make variants and make your changes to the GNUmakefile
<tabemann>
okay, I accidentally deleted GNUmakefile and was unable to get it back for some reason, so I copied it directly from the checkout of your code
xek_ has quit [Ping timeout: 260 seconds]
<crest>
if i squash all your changes into a single commit it doesn't matter how we got there
<crest>
please respond to the comment on the pull request when you're satisified with your changes
<tabemann>
don't merge the code yet
<tabemann>
I rean into a bug
<tabemann>
*ran
<tabemann>
back
<tabemann>
crest
<tabemann>
should I have closed the pull request or not?
<tabemann>
okay, I reopened it
<crest>
does zeptoforth support keeping the base address in r11?
<tabemann>
yes
<tabemann>
swdcom works with swd2 and bootstrap_zepto.fs without any hitches now
<tabemann>
*zeptofort works with
<tabemann>
*zeptoforth
<crest>
my stm32l476 discovery boards are in the mail
<tabemann>
cool
<crest>
i'll give zeptoforth a spin on one of them
<tabemann>
I assume the other is for mecrisp-stellaris?
<crest>
they aren't dedicated to one forth system or the other
<crest>
i just wanted two to have identical hardware for experiments e.g. if I get the CAN controller working
<tabemann>
ah
<crest>
(and as backup if i fry one)
<crest>
i already ripped of a solder pad on one of the nucleo boards
<tabemann>
egad
<crest>
i was fixable
<crest>
*it
<crest>
the damn pad came of while adding some solder to it
<crest>
either the board as a lot more thermal capacity than i thought or it's a low quality pcb
<crest>
the fix isn't pretty but it works
* tabemann
can't solder, as he discovered at a tech camp in high school (I soldered together a radio - it actually worked, but the soldering wasn't pretty)
<crest>
if it works...
<crest>
i squashed all your changes into a single commit to hide the long-winded path you took
andrei-n has quit [Quit: Leaving]
dave0 has joined #forth
dddddd has quit [Ping timeout: 240 seconds]
<tabemann>
thanks
TCZ has quit [Quit: Leaving]
<crest>
what features would you like to see in swdcom?
<tabemann>
crest: I would like e4thcom-style #include and #require, including with nested source files
<tabemann>
I would also like to see a proper line editor
<tabemann>
with history and like
<tabemann>
note that these should not go in the swdcom core, but rather in a client application
<tabemann>
if anything, this functionality should not even know about swdcom
<tabemann>
but rather swdcom should expose itself as a device file
<crest>
exposing a device is hard to do cross platform
<crest>
is there even a linux userspace device driver kernel module?
<crest>
i do know that freebsd has cuse4bsd
<tabemann>
well there's gotta be a way, since things like xterm are crossplatform
<crest>
what does xterm have to with this?
<crest>
oh you don't want a general purpose device
<crest>
just a ptty
<tabemann>
yes
<crest>
good idea
<crest>
but how would you attach to it?
<tabemann>
donno, I don't know enough about pttys
<crest>
it's a nasty api but posix does say enough on it
<tabemann>
but you'd also want to keep a "raw" interface as well where you can just transfer arbitrary bytes to and from the MCU
<crest>
i overlooked the pseudo ttys
<crest>
and wanted to start from scratch
<crest>
but actually my idea for the daemon was to use unix domain sockets
<tabemann>
for the core layer, yeah, that's a good idea - where one is just dealing with bytes alone
<crest>
unix stream sockets are fast and reliable
<crest>
but file descriptor passing over them is a pain in the ass
<crest>
because the stream abstraction breaks down
<tabemann>
yeeeah
<crest>
and each unix has its own intersting interpretation of what should happen in corner cases
<crest>
for decades freebsd had a really, really nasty bug
<crest>
if the sender passed more file descriptors than the receiver could receive all file descriptors got passed
<crest>
there was just no way to learn their file descriptor number