00:31:14
##forth
<xentrac>
amirouche: doesn't normal jonesforth run on alpine?
09:35:23
##forth
<veltas>
Yeah I didn't mean before SQL existed, just before most people were using it
10:31:10
##forth
<amirouche>
it might not be related to alpine or musl, but I can't run jonesforth, here a snippet:
10:31:14
##forth
<amirouche>
> make run
10:31:16
##forth
<amirouche>
cat jonesforth.f - | ./jonesforth
10:31:18
##forth
<amirouche>
/bin/bash: line 1: 31092 Broken pipe cat jonesforth.f -
10:31:20
##forth
<amirouche>
31093 Segmentation fault | ./jonesforth
10:31:22
##forth
<amirouche>
make: *** [Makefile:14: run] Error 139
10:38:55
##forth
<veltas>
gdb
10:44:37
##forth
<veltas>
cat jonesforth.f testinput.f > debug.f
10:44:41
##forth
<veltas>
gdb ./jonesforth
10:44:44
##forth
<veltas>
layout asm
10:44:50
##forth
<veltas>
run < debug.f
10:45:11
##forth
<GeDaMo>
I'm having problems assembling that on my Lubuntu system, first, no asm include subdirectory
10:47:26
##forth
<GeDaMo>
OK, I needed other headers installed
10:48:07
##forth
<GeDaMo>
The jonesforth executable segfaults
10:48:11
##forth
<veltas>
Oh cool, I am seeing it's including <asm/unistd.h>
10:48:18
##forth
<veltas>
I've not seen that before, seems useful!
10:49:02
##forth
<GeDaMo>
I needed to install linux-libc-dev-i386-cross and then add -I /usr/i686-linux-gnu/include/ to the compile
10:49:51
##forth
<veltas>
They're also got #include <asm-i386/unistd.h> next to it, commented out
10:49:56
##forth
<veltas>
They've*
10:50:51
##forth
<veltas>
That might have worked for you
10:50:51
##forth
<GeDaMo>
Yeah, I don't seem to have that one either
10:54:10
##forth
<veltas>
I wonder if -fcf-protection=none will help
10:55:07
##forth
<iyzsong>
you can just define those SYS_ , instead of import the header
10:55:39
##forth
<veltas>
I've defined those SYS_ before, it's not thrilling
11:11:34
##forth
<GeDaMo>
amirouche: if I compile it without the -W parameters, it works
11:11:55
##forth
<GeDaMo>
My compile line is «gcc -g -m32 -nostdlib -static -o jonesforth jonesforth.S -I /usr/i686-linux-gnu/include»
11:15:12
##forth
<GeDaMo>
The -g isn't needed (debugging symbols)
11:19:18
##forth
<amirouche>
thanks, it works.
11:20:06
##forth
<GeDaMo>
-Wl is passing commands to the linker but I have no idea what those are actually doing
12:04:13
##forth
<amirouche>
I have much to learn from c, and generally unix tools, for the time being I will look forth
12:04:45
##forth
<amirouche>
I am reading about duskos too
12:04:55
##forth
<amirouche>
duskos' hal looks cool
12:18:34
##forth
<veltas>
Working with assembly, I strongly recommend just linking against the system libraries, C standard library, etc
12:19:15
##forth
<veltas>
Will be necessary anyway if you want to link any normal libraries
12:19:51
##forth
<veltas>
As I've currently stopped working on my shared-object Forth to work on a project that might actually generate revenue, I am willing to share the repo with anyone that's interested
12:20:20
##forth
<veltas>
if you want some idea of how to write a relocatable shared object AMD64 forth with nasm + C libraries
12:20:51
##forth
<veltas>
Or just ask if you get stuck, I and some people here will be able to help
14:15:39
##forth
<KipIngram>
I avoided C or any other libraries in mine - I used os system calls for the few outside things I needed.
14:17:44
##forth
<KipIngram>
Termios syscalls and memory allocation at start up and shutdown, and otherwise just console in/out and disk in/out.
14:20:04
##forth
<KipIngram>
On the notebook version, though, I'll probably eventually link in SDL2 or something like that, so I have some graphics.
14:28:53
##forth
<veltas>
Basically modern computers are super complicated, because everything's abstracted by an OS, and they're all written in C. So you can rewrite everything or just use the 'system layer', which has similar complexity to I/O on old mainframes
14:29:31
##forth
<veltas>
And frankly the same sophistication, or less. Only newer async API's are close to what I/O really offers, in a more complicated format, but this is the whole OS tradeoff in a nutshell
15:04:10
##forth
<KipIngram>
I know - I quite dislike how complicated it's all gotten, but I can't think of a better way we could have done it. It's just that I want a system that is easy to port to microcontrollers where there won't BE an os (or rather, I will be the OS). So when I do get on with this next system I want that reliance of stuff like SDL2 (or anything else) to be segregated well away from the "core system."
15:04:13
##forth
<KipIngram>
The syscall model just was closer to what I wanted - one way or another I have to have characters in/out and mass storage in/out - on a micro I'll have to write those bits of code myself.
15:06:44
##forth
<KipIngram>
I could have linked in the C library, but I wouldn't have used all of it - anything beyond those simple bits listed above - and the rest would have felt like waste to me.
15:07:34
##forth
<KipIngram>
It just felt more "purist" to do it the way I did it.
15:32:50
##forth
<crc>
on some systems you can't really avoid using libc
15:33:05
##forth
<crc>
e.g., on OpenBSD, where the kernel restricts where syscalls can be made and there's not a stable syscall interface between releases
16:00:46
##forth
<KipIngram>
Yeah - the first place I ever used that approach was on MacOS, which is BSD derived, I think, and I did read somewhere that Apple "didn't like" for people to use syscalls. I did it anyway and crossed my fingers, since I wasn't writing something "critical."
16:01:55
##forth
<KipIngram>
I'm just old enough that I remember the early days, and I firmly believe that a computer should offer access to all of its functionality without requiring an OS. That is, there should "be a BIOS," and it should be documented and stable.
16:02:28
##forth
<KipIngram>
I know the syscalls aren't quite the same thing - they're actually part of the OS too.
16:02:54
##forth
<KipIngram>
But they played the role of a BIOS for me.
16:05:04
##forth
<crc>
I prefer to use syscalls, but I mostly work under OpenBSD, so that's not as viable now that they've been adding pinning to restrict syscalls to a subset of the libc memory space.
16:05:55
##forth
<KipIngram>
See, that's annoying to me. It's one thing to just advise you n ot to use them because they might change, but to go to special trouble to prohibit you from using them seems antagonistic to me.
16:06:50
##forth
<crc>
It's still possible, but you have to create a table in the binary with the specific syscalls you use, and the specific addresses they will be called from.
16:07:33
##forth
<KipIngram>
There are some decisions the Wayland guys have made that annoy me in the same way. Not quite the same sort of stuff, but it provokes the same kind of reaction in me. Their "security" policies often keep me from being able to do things with my PERSONAL computer that I want to do.
16:07:58
##forth
<KipIngram>
I was tinkering with SDL2 in C one day, and SDL2 has a call that allows you to move your window around on screen, and one to maximize it.
16:08:12
##forth
<KipIngram>
Neither one of those will work under Wayland, and when I dug into it it was for "security reasons."
16:08:37
##forth
<KipIngram>
And my reaction was "It's my computer - let me do what I want."
16:08:53
##forth
<crc>
I understand it on OpenBSD where they frequently alter things in the syscall interface. Programs using syscalls directly won't be portable across releases. (it's similar to Windows in this regard).
16:09:36
##forth
<KipIngram>
Yes, but my view of that is that that's the problem of the person who wrote the program. So ADVISE them not to use syscalls, but if they want to set themselves up for problems it's their business.
16:09:44
##forth
<crc>
I don't use Wayland at all, so have no experience with that
16:10:52
##forth
<KipIngram>
The main Linux distros seem to be gradually shifting over to it. I can still choose to boot into X if I want to, but I think that's slated for eventual deprecation.
16:13:28
##forth
<KipIngram>
I do get it - X was developed when an entirely different model was prevalent, with graphical terminals remote from the main CPU. So getting X to work on a single machine left you with a rather "odd" architecture. Wayland's main idea was to streamline all that for modern times.
16:13:47
##forth
<KipIngram>
Which I'm 100% behind, but please don't TAKE AWAY capabilities in the process.
16:14:09
##forth
<KipIngram>
Capabilities that are actually formally supported in libraries like SDL2.
16:55:10
##forth
<thrig>
getting the "assumes linux stack" wayland ported to *BSD has been... challenging. and then there are latency issues in wayland
16:56:52
##forth
<crc>
taking a brief look at wayland, I don't think I'll be doing anything to support it in the near future
19:17:27
##forth
<veltas>
crc: You and literally all sane programmer's reaction to Wayland lol
19:19:12
##forth
<veltas>
KipIngram: Having written boot firmware, my opinion is there's not a ton of difference between a BIOS and a C call
19:20:02
##forth
<veltas>
And with my insight as a firmware engineer I'd say a C call is more likely to work properly than your firmware, because firmware engineers suck
19:20:34
##forth
<veltas>
I can't talk too carelessly though with NDA's I've signed, but I've seen stuff that would make your toes curl lol
19:20:44
##forth
<veltas>
That's probably running on at least one of your computers
19:21:14
##forth
<veltas>
Ultimately stuff like Linux and associated libraries are much better written and bring sanity to all the chaos
19:21:30
##forth
<veltas>
And OpenBSD too in its own way, I'm sure
19:27:25
##forth
<thrig>
openbsd ran into a lot of trouble trying to get documentation from some firmware folks
19:27:44
##forth
<veltas>
There are BIOSs that rewrite your performance registers to cover their tracks running unmaskable ring -2 interrupts that steal your CPU time and mess up high performance profiling
19:29:45
##forth
<veltas>
I think all major OS's basically avoid using firmware for anything if they can help it, and never unquestionably trust it
19:30:55
##forth
<thrig>
or how pretty much every operating system says "hi, I'm windows" for ACAPI
19:31:39
##forth
<veltas>
We do just recreate the same problems everywhere, don't we
19:32:39
##forth
<veltas>
"hi, I'm Mozilla"
19:34:22
##forth
<veltas>
I wish we had "hi, I'm 10pt 96DPI" for fonts, because I've noticed a lot of fonts are nicer proportioned around there, and look awful as they scale up
19:46:26
##forth
<vms14>
this is how slow the perl implementation is
19:47:25
##forth
<vms14>
colon words are just a list of subroutines that I iterate and call
19:47:55
##forth
<vms14>
when compiling a colon word its list gets appended to the outer colon definition
19:48:14
##forth
<vms14>
which means that I can abuse them now :D
19:48:53
##forth
<vms14>
but the "compilation" process is a bit weird since I keep refusing to have the dictionary in an array and pretend to have memory
19:49:36
##forth
<vms14>
I actually have a list of lists for compilation and a list of flags. ':' creates a new list in the list of lists and pushes a true flag on the states list
19:49:54
##forth
<vms14>
';' pops both the state and the list of compiled stuff
19:50:53
##forth
<vms14>
I guess this method might give me problems in the future
19:50:53
##forth
<vms14>
for example '[' pushes a 0 state flag and ']' pops it
19:51:05
##forth
<KipIngram>
veltas: Well, except that the BIOS is built in and requires nothing else be added to the machine beyond your own code. It's a "native capability" of the hardware, off the shelf.
19:52:05
##forth
<KipIngram>
And as I mentioned above, I know that syscalls are not "built in," but on the other hand I don't have to add anything to my binary to use themm.
19:52:38
##forth
<KipIngram>
So they "feel" more built in.
20:09:19
##forth
<KipIngram>
vms14: You sure there's not some overhead in that GForth test? Because I coded it up in mine and am measuring 13,000 to 31,000 microseconds, so that 0.013 to 0.031 seconds. I can't be faster than GForth like that. Or at least it's not what I've seen in the past.
20:11:04
##forth
<KipIngram>
My looping structure is different, but I did the same million addition ops.
20:19:49
##forth
<vms14>
more than executing that into a phone with a fake debian in termux?
20:19:55
##forth
<vms14>
in*
20:20:17
##forth
<vms14>
no
20:20:40
##forth
<crc>
vms14: for ref., on my openbsd box running that in gforth takes 0.07s, konilo takes 3.45s (or 3.03s w/o the startup blocks loaded), and retro takes 4.1s
20:21:50
##forth
<vms14>
I see no difference between gforth and gforth-fast
20:22:03
##forth
<vms14>
sometimes one is slower than the other and viceversa
20:22:13
##forth
<vms14>
I guess the code cannot be optimized properly or whatever
20:22:49
##forth
<vms14>
this specific code*
20:23:22
##forth
<thrig>
"fast" might have been written with different CPUs in mind
20:25:36
##forth
<amirouche>
Surprise! Scanning a dataset made of lobste.rs stories took only 150 seconds, here is the code: xzcat rs.lobste-stories.jsonl.xz | grep jonesforth | jq first | tee out.txt
20:25:56
##forth
<crc>
iirc, the main diff. between gforth and gforth-fast is that gforth-fast does fewer error checks
20:27:39
##forth
<vms14>
btw I made do loop and +loop work a bit different
20:28:59
##forth
<vms14>
0 3 do i . loop this makes gforth iterate until it wraps
20:29:26
##forth
<vms14>
in my case if start is bigger than end it will count from 3 to 0, decrementing the number instead
20:29:34
##forth
<vms14>
I wonder if you guys dislike the idea
20:30:56
##forth
<vms14>
but I did not like the interpreter to do what forth does in this case, because I do not think I will ever want that behavior
20:31:23
##forth
<vms14>
I guess it should not be a problem since I do not expect anyone using loops like that and expecting them to wrap
20:32:46
##forth
<vms14>
anyways it won't be too much forth like, only when I think it makes sense
20:33:12
##forth
<vms14>
I keep struggling finding a middle ground that does not go against forth or the implementation language (perl, js)
20:33:49
##forth
<vms14>
but I guess that weird compiling lists approach will give me problems soon
20:53:13
##forth
<veltas>
It's worth playing with either the standard or a good dialect of Forth before trying your own dialect, in my opinion
20:53:33
##forth
<veltas>
I'm sure it works sometimes, but really most of the good forths/dialects are "standing on the shoulders of giants"
20:54:07
##forth
<veltas>
Well if you want something good, if you just want to have fun then who am I to say how to do that
20:54:16
##forth
<vms14>
yeah that's the reason I wanted to go more in depth with forth so I will know better what to steal and not
21:20:50
##forth
<veltas>
Why is it so much easier to rewrite code than to pick it back up half-written?
21:21:15
##forth
<vms14>
because usually the core design changes
21:21:29
##forth
<vms14>
the older code had some design in mind that does not longer apply
21:21:41
##forth
<vms14>
which means that you will change something and break 3
21:22:00
##forth
<veltas>
This is how I've been justifying 2am coding for years, if I stop at midnight then I can't pick it up the next day, so all is lost; it's better to carry on until it's done
21:22:36
##forth
<veltas>
I actually work better sleep-deprived too. I don't think quite as well, but well enough, and somehow it helps my motivation.
21:22:55
##forth
<vms14>
oh like you forgot what you were doing you meant
21:23:02
##forth
<veltas>
Sort of
21:23:07
##forth
<veltas>
There's a complicated machine sitting in front of the keyboard
21:24:19
##forth
<vms14>
at 3am is where I get the most focus though
21:24:48
##forth
<vms14>
mainly because there is total silence and nothing distracts me and this happens during all night so at 3am is like the peak
21:25:22
##forth
<thrig>
meanwhile, return to office, hot desking, and open office designs will clearly improve productivity
21:26:49
##forth
<vms14>
though if you want focus, cut your internet wire
21:27:05
##forth
<vms14>
pomodoro seems helpful also
21:27:44
##forth
<vms14>
because you set your mind into " ok, for this period of time I will focus on that and then I will do whatever I want"
21:33:38
##forth
<veltas>
My discipline at that is good, my main issue is just being unmotivated sometimes
21:33:46
##forth
<veltas>
Helps to have something that's worth working on though
21:39:11
##forth
<veltas>
I find firing off a build helps pick back up though
21:39:22
##forth
<veltas>
Just let the compiler crash and burn and that prompts me to carry on with it
21:39:46
##forth
<veltas>
GCC-driven-development
21:50:52
##forth
<vms14>
xd
22:02:13
##forth
<veltas>
I actually do the same with assembly, but it's more gdb-driven-development
23:16:22
##forth
<xentrac>
veltas: is your shared-object Forth an interpreter that can be loaded as a .so, or a compiler that generates .sos, or what?
23:17:59
##forth
<thrig>
sos or mayday might be typical for a lot of code
23:18:36
##forth
<xentrac>
Linux does generally try pretty hard to keep a stable interface to userland
23:25:32
##forth
<veltas>
It's a Forth environment that is written as a shared object. You can either run it standalone or embed it in another program. That's the idea anyway, it's not working yet.
23:25:48
##forth
<veltas>
But the 'shared object' parts are working, a lot of it is
23:27:08
##forth
<veltas>
Really if anyone wants to write something similar and gets stuck then hit me up and I'll divulge the nitty gritty
23:27:19
##forth
<veltas>
Probably a good blog in there somewhere too
23:29:05
##forth
<thrig>
linux has to have an interface because of the complete split brain between kernel and userland (that is absent in macOS, *BSD, etc)
23:29:52
##forth
<veltas>
The BSD's essentially have one too, as there's not much reason to change it
23:29:58
##forth
<veltas>
OpenBSD is the big exception isn't it
23:30:54
##forth
<thrig>
Golang got in trouble on both OpenBSD and macOS for trying to use direct syscalls
23:31:55
##forth
<veltas>
Like Apple M4 not allowing rwx pages or something(?) which messes up Forth and a lot of JIT stuff
23:32:32
##forth
<thrig>
wxallowed is necessary on OpenBSD for that, like if you have SBCL
23:32:49
##forth
<veltas>
But why did they call it M4 when there is already an M4 in ARM? Apple what are you thinking
23:43:53
##forth
<xentrac>
it's an executable that you can also load as a shared library? kinky!
23:44:27
##forth
<xentrac>
thrig: my NetBSD friends complain bitterly about Golang using direct syscalls
23:44:31
##forth
<veltas>
No it's a shared library and you can produce a standalone version as well with some more code
23:44:39
##forth
<veltas>
Like e.g. Lua
23:44:49
##forth
<xentrac>
aha, I see
23:47:47
##forth
<veltas>
I wonder how hard it is to make the .so executable, probably not that hard
23:47:56
##forth
<veltas>
There are some .so's like that I've seen
23:54:07
##forth
<xentrac>
yeah
23:59:28
##forth
<Zarutian_iPad>
veltas: arent .so just elf binaries?