2025-02-11 00:31:14 <xentrac     > amirouche: doesn't normal jonesforth run on alpine?
2025-02-11 09:35:23 <veltas      > Yeah I didn't mean before SQL existed, just before most people were using it
2025-02-11 10:31:10 <amirouche   > it might not be related to alpine or musl, but I can't run jonesforth, here a snippet:
2025-02-11 10:31:14 <amirouche   > > make run
2025-02-11 10:31:16 <amirouche   > cat jonesforth.f  - | ./jonesforth
2025-02-11 10:31:18 <amirouche   > /bin/bash: line 1: 31092 Broken pipe             cat jonesforth.f -
2025-02-11 10:31:20 <amirouche   >      31093 Segmentation fault      | ./jonesforth
2025-02-11 10:31:22 <amirouche   > make: *** [Makefile:14: run] Error 139
2025-02-11 10:31:29 <amirouche   > here is the repo I use https://github.com/nornagon/jonesforth
2025-02-11 10:38:55 <veltas      > gdb
2025-02-11 10:44:37 <veltas      > cat jonesforth.f testinput.f > debug.f
2025-02-11 10:44:41 <veltas      > gdb ./jonesforth
2025-02-11 10:44:44 <veltas      > layout asm
2025-02-11 10:44:50 <veltas      > run < debug.f
2025-02-11 10:45:11 <GeDaMo      > I'm having problems assembling that on my Lubuntu system, first, no asm include subdirectory
2025-02-11 10:47:26 <GeDaMo      > OK, I needed other headers installed
2025-02-11 10:48:07 <GeDaMo      > The jonesforth executable segfaults
2025-02-11 10:48:11 <veltas      > Oh cool, I am seeing it's including <asm/unistd.h>
2025-02-11 10:48:18 <veltas      > I've not seen that before, seems useful!
2025-02-11 10:49:02 <GeDaMo      > I needed to install linux-libc-dev-i386-cross and then add -I /usr/i686-linux-gnu/include/ to the compile
2025-02-11 10:49:51 <veltas      > They're also got #include <asm-i386/unistd.h> next to it, commented out
2025-02-11 10:49:56 <veltas      > They've*
2025-02-11 10:50:51 <veltas      > That might have worked for you
2025-02-11 10:50:51 <GeDaMo      > Yeah, I don't seem to have that one either
2025-02-11 10:54:10 <veltas      > I wonder if -fcf-protection=none will help
2025-02-11 10:55:07 <iyzsong     > you can just define those SYS_ , instead of import the header
2025-02-11 10:55:39 <veltas      > I've defined those SYS_ before, it's not thrilling
2025-02-11 11:11:34 <GeDaMo      > amirouche: if I compile it without the -W parameters, it works
2025-02-11 11:11:55 <GeDaMo      > My compile line is «gcc -g -m32 -nostdlib -static  -o jonesforth jonesforth.S -I /usr/i686-linux-gnu/include»
2025-02-11 11:15:12 <GeDaMo      > The -g isn't needed (debugging symbols)
2025-02-11 11:19:18 <amirouche   > thanks, it works.
2025-02-11 11:20:06 <GeDaMo      > -Wl is passing commands to the linker but I have no idea what those are actually doing
2025-02-11 11:25:37 <iyzsong     > you could try to do it with fasmg, which hidden less than gcc, my tries: https://git.envs.net/iyzsong/jonesforth-fasmg
2025-02-11 12:04:13 <amirouche   > I have much to learn from c, and generally unix tools, for the time being I will look forth
2025-02-11 12:04:45 <amirouche   > I am reading about duskos too
2025-02-11 12:04:55 <amirouche   > duskos' hal looks cool
2025-02-11 12:18:34 <veltas      > Working with assembly, I strongly recommend just linking against the system libraries, C standard library, etc
2025-02-11 12:19:15 <veltas      > Will be necessary anyway if you want to link any normal libraries
2025-02-11 12:19:51 <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
2025-02-11 12:20:20 <veltas      > if you want some idea of how to write a relocatable shared object AMD64 forth with nasm + C libraries
2025-02-11 12:20:51 <veltas      > Or just ask if you get stuck, I and some people here will be able to help
2025-02-11 14:15:39 <KipIngram   > I avoided C or any other libraries in mine - I used os system calls for the few outside things I needed.
2025-02-11 14:17:44 <KipIngram   > Termios syscalls and memory allocation at start up and shutdown, and otherwise just console in/out and disk in/out.
2025-02-11 14:20:04 <KipIngram   > On the notebook version, though, I'll probably eventually link in SDL2 or something like that, so I have some graphics.
2025-02-11 14:28:53 <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
2025-02-11 14:29:31 <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
2025-02-11 15:04:10 <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."
2025-02-11 15:04:13 <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.
2025-02-11 15:06:44 <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.
2025-02-11 15:07:34 <KipIngram   > It just felt more "purist" to do it the way I did it.
2025-02-11 15:32:50 <crc         > on some systems you can't really avoid using libc
2025-02-11 15:33:05 <crc         > e.g., on OpenBSD, where the kernel restricts where syscalls can be made and there's not a stable syscall interface between releases
2025-02-11 16:00:46 <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."
2025-02-11 16:01:55 <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.
2025-02-11 16:02:28 <KipIngram   > I know the syscalls aren't quite the same thing - they're actually part of the OS too.
2025-02-11 16:02:54 <KipIngram   > But they played the role of a BIOS for me.
2025-02-11 16:05:04 <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.
2025-02-11 16:05:55 <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.
2025-02-11 16:06:50 <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.
2025-02-11 16:07:33 <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.
2025-02-11 16:07:58 <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.
2025-02-11 16:08:12 <KipIngram   > Neither one of those will work under Wayland, and when I dug into it it was for "security reasons."
2025-02-11 16:08:37 <KipIngram   > And my reaction was "It's my computer - let me do what I want."
2025-02-11 16:08:53 <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).
2025-02-11 16:09:36 <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.
2025-02-11 16:09:44 <crc         > I don't use Wayland at all, so have no experience with that
2025-02-11 16:10:52 <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.
2025-02-11 16:13:28 <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.
2025-02-11 16:13:47 <KipIngram   > Which I'm 100% behind, but please don't TAKE AWAY capabilities in the process.
2025-02-11 16:14:09 <KipIngram   > Capabilities that are actually formally supported in libraries like SDL2.
2025-02-11 16:55:10 <thrig       > getting the "assumes linux stack" wayland ported to *BSD has been... challenging. and then there are latency issues in wayland
2025-02-11 16:56:52 <crc         > taking a brief look at wayland, I don't think I'll be doing anything to support it in the near future
2025-02-11 19:17:27 <veltas      > crc: You and literally all sane programmer's reaction to Wayland lol
2025-02-11 19:19:12 <veltas      > KipIngram: Having written boot firmware, my opinion is there's not a ton of difference between a BIOS and a C call
2025-02-11 19:20:02 <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
2025-02-11 19:20:34 <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
2025-02-11 19:20:44 <veltas      > That's probably running on at least one of your computers
2025-02-11 19:21:14 <veltas      > Ultimately stuff like Linux and associated libraries are much better written and bring sanity to all the chaos
2025-02-11 19:21:30 <veltas      > And OpenBSD too in its own way, I'm sure
2025-02-11 19:27:25 <thrig       > openbsd ran into a lot of trouble trying to get documentation from some firmware folks
2025-02-11 19:27:44 <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
2025-02-11 19:28:21 <thrig       > hence https://www.openbsd.org/lyrics.html#38
2025-02-11 19:29:45 <veltas      > I think all major OS's basically avoid using firmware for anything if they can help it, and never unquestionably trust it
2025-02-11 19:30:55 <thrig       > or how pretty much every operating system says "hi, I'm windows" for ACAPI
2025-02-11 19:31:39 <veltas      > We do just recreate the same problems everywhere, don't we
2025-02-11 19:32:39 <veltas      > "hi, I'm Mozilla"
2025-02-11 19:34:22 <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
2025-02-11 19:46:26 <vms14       > this is how slow the perl implementation is
2025-02-11 19:46:27 <vms14       > https://imgur.com/A1Ya6ym
2025-02-11 19:47:25 <vms14       > colon words are just a list of subroutines that I iterate and call
2025-02-11 19:47:55 <vms14       > when compiling a colon word its list gets appended to the outer colon definition
2025-02-11 19:48:14 <vms14       > which means that I can abuse them now :D
2025-02-11 19:48:53 <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
2025-02-11 19:49:36 <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
2025-02-11 19:49:54 <vms14       > ';' pops both the state and the list of compiled stuff
2025-02-11 19:50:53 <vms14       > I guess this method might give me problems in the future
2025-02-11 19:50:53 <vms14       > for example '[' pushes a 0 state flag and ']' pops it
2025-02-11 19:51:05 <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.
2025-02-11 19:51:14 <vms14       > that's gforth in comparison https://i.imgur.com/0ySWWgD.png
2025-02-11 19:52:05 <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.
2025-02-11 19:52:38 <KipIngram   > So they "feel" more built in.
2025-02-11 20:09:19 <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.
2025-02-11 20:11:04 <KipIngram   > My looping structure is different, but I did the same million addition ops.
2025-02-11 20:19:49 <vms14       > more than executing that into a phone with a fake debian in termux?
2025-02-11 20:19:55 <vms14       > in*
2025-02-11 20:20:17 <vms14       > no
2025-02-11 20:20:40 <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
2025-02-11 20:21:50 <vms14       > I see no difference between gforth and gforth-fast
2025-02-11 20:22:03 <vms14       > sometimes one is slower than the other and viceversa
2025-02-11 20:22:13 <vms14       > I guess the code cannot be optimized properly or whatever
2025-02-11 20:22:49 <vms14       > this specific code*
2025-02-11 20:23:22 <thrig       > "fast" might have been written with different CPUs in mind
2025-02-11 20:25:36 <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
2025-02-11 20:25:56 <crc         > iirc, the main diff. between gforth and gforth-fast is that gforth-fast does fewer error checks
2025-02-11 20:27:39 <vms14       > btw I made do loop and +loop work a bit different
2025-02-11 20:28:59 <vms14       > 0 3 do i . loop this makes gforth iterate until it wraps
2025-02-11 20:29:26 <vms14       > in my case if start is bigger than end it will count from 3 to 0, decrementing the number instead
2025-02-11 20:29:34 <vms14       > I wonder if you guys dislike the idea
2025-02-11 20:30:56 <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
2025-02-11 20:31:23 <vms14       > I guess it should not be a problem since I do not expect anyone using loops like that and expecting them to wrap
2025-02-11 20:32:46 <vms14       > anyways it won't be too much forth like, only when I think it makes sense
2025-02-11 20:33:12 <vms14       > I keep struggling finding a middle ground that does not go against forth or the implementation language (perl, js)
2025-02-11 20:33:49 <vms14       > but I guess that weird compiling lists approach will give me problems soon
2025-02-11 20:53:13 <veltas      > It's worth playing with either the standard or a good dialect of Forth before trying your own dialect, in my opinion
2025-02-11 20:53:33 <veltas      > I'm sure it works sometimes, but really most of the good forths/dialects are "standing on the shoulders of giants"
2025-02-11 20:54:07 <veltas      > Well if you want something good, if you just want to have fun then who am I to say how to do that
2025-02-11 20:54:16 <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
2025-02-11 21:20:50 <veltas      > Why is it so much easier to rewrite code than to pick it back up half-written?
2025-02-11 21:21:15 <vms14       > because usually the core design changes
2025-02-11 21:21:29 <vms14       > the older code had some design in mind that does not longer apply
2025-02-11 21:21:41 <vms14       > which means that you will change something and break 3
2025-02-11 21:22:00 <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
2025-02-11 21:22:36 <veltas      > I actually work better sleep-deprived too.  I don't think quite as well, but well enough, and somehow it helps my motivation.
2025-02-11 21:22:55 <vms14       > oh like you forgot what you were doing you meant
2025-02-11 21:23:02 <veltas      > Sort of
2025-02-11 21:23:07 <veltas      > There's a complicated machine sitting in front of the keyboard
2025-02-11 21:24:19 <vms14       > at 3am is where I get the most focus though
2025-02-11 21:24:48 <vms14       > mainly because there is total silence and nothing distracts me and this happens during all night so at 3am is like the peak
2025-02-11 21:25:22 <thrig       > meanwhile, return to office, hot desking, and open office designs will clearly improve productivity
2025-02-11 21:26:49 <vms14       > though if you want focus, cut your internet wire
2025-02-11 21:27:05 <vms14       > pomodoro seems helpful also
2025-02-11 21:27:44 <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"
2025-02-11 21:33:38 <veltas      > My discipline at that is good, my main issue is just being unmotivated sometimes
2025-02-11 21:33:46 <veltas      > Helps to have something that's worth working on though
2025-02-11 21:39:11 <veltas      > I find firing off a build helps pick back up though
2025-02-11 21:39:22 <veltas      > Just let the compiler crash and burn and that prompts me to carry on with it
2025-02-11 21:39:46 <veltas      > GCC-driven-development
2025-02-11 21:50:52 <vms14       > xd
2025-02-11 22:02:13 <veltas      > I actually do the same with assembly, but it's more gdb-driven-development
2025-02-11 23:16:22 <xentrac     > veltas: is your shared-object Forth an interpreter that can be loaded as a .so, or a compiler that generates .sos, or what?
2025-02-11 23:17:59 <thrig       > sos or mayday might be typical for a lot of code
2025-02-11 23:18:36 <xentrac     > Linux does generally try pretty hard to keep a stable interface to userland
2025-02-11 23:25:32 <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.
2025-02-11 23:25:48 <veltas      > But the 'shared object' parts are working, a lot of it is
2025-02-11 23:27:08 <veltas      > Really if anyone wants to write something similar and gets stuck then hit me up and I'll divulge the nitty gritty
2025-02-11 23:27:19 <veltas      > Probably a good blog in there somewhere too
2025-02-11 23:29:05 <thrig       > linux has to have an interface because of the complete split brain between kernel and userland (that is absent in macOS, *BSD, etc)
2025-02-11 23:29:52 <veltas      > The BSD's essentially have one too, as there's not much reason to change it
2025-02-11 23:29:58 <veltas      > OpenBSD is the big exception isn't it
2025-02-11 23:30:54 <thrig       > Golang got in trouble on both OpenBSD and macOS for trying to use direct syscalls
2025-02-11 23:31:55 <veltas      > Like Apple M4 not allowing rwx pages or something(?) which messes up Forth and a lot of JIT stuff
2025-02-11 23:32:32 <thrig       > wxallowed is necessary on OpenBSD for that, like if you have SBCL
2025-02-11 23:32:49 <veltas      > But why did they call it M4 when there is already an M4 in ARM?  Apple what are you thinking
2025-02-11 23:43:53 <xentrac     > it's an executable that you can also load as a shared library?  kinky!
2025-02-11 23:44:27 <xentrac     > thrig: my NetBSD friends complain bitterly about Golang using direct syscalls
2025-02-11 23:44:31 <veltas      > No it's a shared library and you can produce a standalone version as well with some more code
2025-02-11 23:44:39 <veltas      > Like e.g. Lua
2025-02-11 23:44:49 <xentrac     > aha, I see
2025-02-11 23:47:47 <veltas      > I wonder how hard it is to make the .so executable, probably not that hard
2025-02-11 23:47:56 <veltas      > There are some .so's like that I've seen
2025-02-11 23:54:07 <xentrac     > yeah
2025-02-11 23:59:28 <Zarutian_iPad> veltas: arent .so just elf binaries?