Hello Virgil,

Am 26.05.2023 um 23:19 schrieb Virgil Dupras:
> On Fri, May 26, 2023, at 4:58 PM, Michael Schierl wrote:

> This changes the implicit semantic of "code", which so far meant nothing more
> than "create an entry". Now it would be "create an entry and add a prelude".
> This means that "here" doesn't point to the beginning of the code after a "code"
> call. This breaks a lot of usages for it.

Fair point.

> Also, what happens when we jump to that word instead of calling it? Currently,
> it changes nothing as it simply defers the "ret". I use this pattern quite

Hello Virgil,

Am 26.05.2023 um 21:01 schrieb Virgil Dupras:
> Hello all,
>
> People looking at Dusk's commits will have seen that I've been happily porting
> Dusk to ARM with the Raspberry Pi model 1 as a first target. Things are going
> well and the ARM architecture is interesting.

Having more than one architecture fully supported will definitely be
great for proving Dusk OS's concepts.

> One obvious roadblock is the way "calls" are made in ARM. "bl" doesn't do like
> a traditional "call", it simply saves PC to the "LR" register. To make it

Hello eril,

Am 11.05.2023 um 20:11 schrieb Virgil Dupras:
> On Thu, May 11, 2023, at 12:30 AM, eril wrote:
>>> I don't think that DuskOS proper has audio support yet! If you want,
>>> you could theoretically implement it :>
>> I'd like to, but I don't know where I would start.
>> I have little experience with systems programming, and have no
>> experience with developing an audio stack. I'm just starting to
>> get comfortable with FORTH. Does anyone recommend any resources?
>> I've found a book and a video from a stackoverflow post.
>> https://openlibrary.org/books/OL683184M/A_programmer%27s_guide_to_sound
>> https://xiph.org/video/vid1.shtml
>

Hello,

Am 26.04.2023 um 01:49 schrieb Virgil Dupras:
> On Tue, Apr 25, 2023, at 6:29 PM, Michael Schierl wrote:

> Since you've obviously been using the documentation, I'd be really interested to
> know if there were pain points or confusions other than the fixes you've made
> already.

I probably should have used the documentation more. I mainly grepped for
words in the whole code base, and when documentation showed up, I read
it first before reading the code results. Those files I read were clear
to me. I stumbled a bit with one case which probably would have been
clear to a more experienced Forth user, but resolved quickly after

Hello,


This is my first non-trivial contribution to Dusk OS. I am still trying
to create a web emulator (wasm or JavaScript) for Dusk OS, but I first
want to try to understand the system better and reduce the complexity
for my emulator.

Dusk OS currently depends on both a Grid and a Screen driver to be able
to use all applications. Therefore, I decided to start implementing a
Grid driver that runs as a framebuffer on the Screen driver.

While doing so, I encountered a few small documentation glitches that I
fixed as well.

Hello,


Am 29.11.2022 um 21:29 schrieb Virgil Dupras:
> and... mission accomplished[1]! with a DuskCC line count of... 1166 ;)
>
> Sure, there's a few TODOs in the ported puff.c, but nothing major. Once that's
> done, the diff with the original will be pretty slim!

Looked at the diff against original puff.c, and it does not look too
bad. Really ugly in my opinion is the MAXBITSPLUSONE define, but I
assume I can guess why this is here (there is no constant expression
evaluation in DuskCC, and allocating an array on the stack requires the
size of the array to be known at compile time). Other minimal C subsets

Hello,


Am 26.11.2022 um 15:24 schrieb Virgil Dupras:
> On Fri, Nov 25, 2022, at 4:34 PM, Michael Schierl wrote:
>> The "(br)" word itself is popping the return address (which is a pointer
>> to the address written when AGAIN was compiled), dereferences it and
>> jumps to it. (It could probably also be seen as popping the return
>> address, dereferencing it, pushing it again, and returning to it).
>
> You understood correctly, except for "pushing it again". The last line of (br)
> jumps to [eax], not from stack's top.

Probably instead of "It could also be seen" I should have written "It

Hello Virgil,


Am 02.07.2022 um 21:02 schrieb Virgil Dupras:
> And I don't think I'd be willing to sacrifice STC for the sake of being able to
> run on Harvard machines. When compactness isn't a priority, STC is much more
> pleasant and straightforward (and fast).
>
> I see a bunch of Forth implementation in WASM, I'll go check whether they're
> ITC, or if they use modules.

Sorry for digging out this old post, but now I had a look how BEGIN ..
AGAIN is actually implemented in Dusk OS (and probably any other STC
Forth - I don't have experience in that):

Hello Virgil,


Am 19.11.2022 um 16:52 schrieb Virgil Dupras:

>> [...] while still running well when compiled with other C compilers.
>
> That, however, is not part of DuskCC design goals. A C application ported to
> DuskCC is not going to compile on a regular C compiler. The semantics of the
> stdlib, especially with memory allocation and I/O, are different.

Hmm. If the differences are just libs, they could probably be worked
around by different include path or some #ifdefs? (M2libc also comes
with bootstrappable.{c,h} which includes a C implementation of the

Hello,

I spent this evening trying to get "make test" work on my two test
environments. One is cygwin (on 64-bit Windows 10), the other is a
32-bit Linux VM (running on same 64-bit Windows 10 host OS).

The cygwin case was the easier one: In
<https://git.sr.ht/~vdupras/duskos/tree/master/item/posix/vm.c#L812>,
you call realpath() without checking the return value. When realpath is
called on cygwin with a non-existing file, it returns 0 with errno
ENOENT and the output buffer stays empty. On Linux, it also returns
errno ENOENT but the output buffer is filled with the path as if the
file did exist.