When the c compiler compiles something, if there is some sort of error, running
the c compiler again resulted in
  allocating to locked HERE!

This error goes away when running the c compiler again. This is because
the allocator has a lock that is still present when the compiler aborts
on _err
---
 fs/comp/c/tok.fs | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/comp/c/tok.fs b/fs/comp/c/tok.fs
index ebb6125..eee0c44 100644
--- a/fs/comp/c/tok.fs
+++ b/fs/comp/c/tok.fs
@@ -12,7 +12,7 @@ $400 Scratchpad :new structbind Scratchpad _pad
 0 value curtok
 1 value _firstchar
 : tokdbg curtok curline .f" Line no: %d token: %s\n" ;
-: _err tokdbg abort" tokenization error" ;
+: _err tokdbg unlockhere abort" tokenization error" ;
 : _assert ( f -- ) not if _err then ;
 
 : cctok$ 1 to curline 1 to _firstchar ;
-- 
2.40.1

Ah, I submitted this too soon, before understanding the c compiler 
better. It appears this _err word is defined in each part of the 
compiler, so this would have to be repeated there. Which itself is sort 
of awkward.

Maybe _err could be a shared word that takes a str param? S" egen" _err 


On Wed Jun 14, 2023 at 9:18 PM EDT, alex wennerberg wrote:
> When the c compiler compiles something, if there is some sort of error, running
> the c compiler again resulted in
>   allocating to locked HERE!
>
> This error goes away when running the c compiler again. This is because
> the allocator has a lock that is still present when the compiler aborts
> on _err
> ---
>  fs/comp/c/tok.fs | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/comp/c/tok.fs b/fs/comp/c/tok.fs
> index ebb6125..eee0c44 100644
> --- a/fs/comp/c/tok.fs
> +++ b/fs/comp/c/tok.fs
> @@ -12,7 +12,7 @@ $400 Scratchpad :new structbind Scratchpad _pad
>  0 value curtok
>  1 value _firstchar
>  : tokdbg curtok curline .f" Line no: %d token: %s\n" ;
> -: _err tokdbg abort" tokenization error" ;
> +: _err tokdbg unlockhere abort" tokenization error" ;
>  : _assert ( f -- ) not if _err then ;
>  
>  : cctok$ 1 to curline 1 to _firstchar ;
> -- 
> 2.40.1

all the best,

alex
alexw.nyc

On Wed, Jun 14, 2023, at 9:31 PM, alex wennerberg wrote:
> Ah, I submitted this too soon, before understanding the c compiler 
> better. It appears this _err word is defined in each part of the 
> compiler, so this would have to be repeated there. Which itself is sort 
> of awkward.
>
> Maybe _err could be a shared word that takes a str param? S" egen" _err 
>
>
> On Wed Jun 14, 2023 at 9:18 PM EDT, alex wennerberg wrote:
>> When the c compiler compiles something, if there is some sort of error, running
>> the c compiler again resulted in
>>   allocating to locked HERE!
>>
>> This error goes away when running the c compiler again. This is because
>> the allocator has a lock that is still present when the compiler aborts
>> on _err
>> ---
>>  fs/comp/c/tok.fs | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/fs/comp/c/tok.fs b/fs/comp/c/tok.fs
>> index ebb6125..eee0c44 100644
>> --- a/fs/comp/c/tok.fs
>> +++ b/fs/comp/c/tok.fs
>> @@ -12,7 +12,7 @@ $400 Scratchpad :new structbind Scratchpad _pad
>>  0 value curtok
>>  1 value _firstchar
>>  : tokdbg curtok curline .f" Line no: %d token: %s\n" ;
>> -: _err tokdbg abort" tokenization error" ;
>> +: _err tokdbg unlockhere abort" tokenization error" ;
>>  : _assert ( f -- ) not if _err then ;
>>  
>>  : cctok$ 1 to curline 1 to _firstchar ;
>> -- 
>> 2.40.1
>
> all the best,
>
> alex
> alexw.nyc

Hello Alex,

Yes, that's a problem, good catch. Ideally, we'd add a kind of "abort hooks"
system, a chain of words to hook together, a bit like the idle loop (except I
think in this case we could simply use "chain"), which we call on abort.
lib/alloc would hook "unlockhere" in there.

If it's something you'd like to try to design, please do. Otherwise, your
suggestion is good. To minimize the change, maybe add a global "ccerr" and have
all local "_err" words call upon it. Implementing your suggestion as-is would
get fussy in places where "_err" is used as a word pointer.

Regards,
Virgil

On Thu Jun 15, 2023 at 7:12 AM EDT, Virgil Dupras wrote:
> Hello Alex,
>
> Yes, that's a problem, good catch. Ideally, we'd add a kind of "abort hooks"
> system, a chain of words to hook together, a bit like the idle loop (except I
> think in this case we could simply use "chain"), which we call on abort.
> lib/alloc would hook "unlockhere" in there.

Ok, so I have skeched out;

: unlockabort" ' unlockhere ' abort" chain execute ;

What I'm wondering is, how could I make this more generic? I don't know 
enough about the dict internals (in dusk or in forth in general), but 
let me know if this works:

: hook ( w1 w2 -- ) 
\ create a new w2 dict entry (with same name) that says:
\ do w1, then do w2, then delete the new dictionary entry (ie, delete 
itself) ;

usage:

' unlockhere ' abort" hook
abort" foo \ calls unlockhere
abort" bar \ does not call unlockhere
abort" baz \ does not call unlockhere

also, is this mailing list the best place for me to work on patches? or 
should we maybe make a separate patch mailing list?

On Fri, Jun 16, 2023, at 10:48 PM, alex wennerberg wrote:
> On Thu Jun 15, 2023 at 7:12 AM EDT, Virgil Dupras wrote:
>> Hello Alex,
>>
>> Yes, that's a problem, good catch. Ideally, we'd add a kind of "abort hooks"
>> system, a chain of words to hook together, a bit like the idle loop (except I
>> think in this case we could simply use "chain"), which we call on abort.
>> lib/alloc would hook "unlockhere" in there.
>
> Ok, so I have skeched out;
>
> : unlockabort" ' unlockhere ' abort" chain execute ;

Functionally, this is equivalent to:

: unlockabort" unlockhere [compile] abort" ;

except that it litters "here" with a new word every time it's called. This is
not the intended usage of "chain". "chain" is intended to be called once at
"configuration" time to realias a target word with a chain of itself and an
"augmentation".

I was about to tell you that "chain" is used at one place in Dusk and it's in
sys/rdln, only to remember that I removed that usage when I removed the "stack
trace" feature which was too buggy for it's own good. "chain" is currently only
used for Pipe "rfilters" and "wfilters", but they're not good learning example
because they're a bit deep in the abstraction stack.

If you do a bit of archeology[1], you'll find the "stack trace" feature and how
it hooked into abort. At that time, "chain" had a double mandate and did a
realias too, which is why the code looks like this. A usage of the current
"chain" wouldn't exactly look like this code, but the principle is similar:
append behavior to "abort" globally.

> What I'm wondering is, how could I make this more generic? I don't know 
> enough about the dict internals (in dusk or in forth in general), but 
> let me know if this works:
>
> : hook ( w1 w2 -- ) 
> \ create a new w2 dict entry (with same name) that says:
> \ do w1, then do w2, then delete the new dictionary entry (ie, delete 
> itself) ;
>
> usage:
>
> ' unlockhere ' abort" hook
> abort" foo \ calls unlockhere
> abort" bar \ does not call unlockhere
> abort" baz \ does not call unlockhere

I don't think it's necessary to have the hook remove itself on call: we'd always
want to call "unlockhere" on abort, even after the first abort.

The most straightforward way to go about this isn't to mangle with dictionaries,
but to overwrite the "abort" alias with "realias".

I also don't understand why you're trying to overload "abort"" rather than
"abort".

Theoretically, you could add such overloading word directly in lib/alloc and be
done with it, but in doing so, you're going to hit a snag: sys/rdln already
fusses about with abort: it ends the "boot abort" condition, a special
temporary abort that spits "boot error" and go in an infinite loop rather than
trying to call back the "main loop" word, which at boot time leads to the
interpreter going through the whole memory and interpret it as Forth.

Because sys/rdln is presently the only viable "main loop", I've cut some corners
and gave it the responsibility of ending boot abort condition. If we're going to
have multiple points where we fuss around with abort, order needs to be brought
to this little party, so it would be time for a cleaner "lib/abort".

Do you think you have all details you need to carry on? Don't hesitate to ask
for more, I don't know what you don't know.

Small note: I've just pushed a commit that fixes obsolete information in
doc/dict that might cause confusion if you're looking around on the subject of
"abort". At this stage, "abort" doesn't have a special status like it did
before. It's now a regular word created as an "alias" and the proper way to
overwrite it is like with any other word: realias.

> also, is this mailing list the best place for me to work on patches? or 
> should we maybe make a separate patch mailing list?

Some (most, even) software projects have separate "users" and "dev" mailing
lists. In the case of Dusk, it seems to me that the Venn diagram of people
wanting to use Dusk and people wanting do know its innards form an almost
perfect circle. Those belonging only to the first group are looking at Dusk for
the wrong reasons. Therefore, I think that this list, for now, is perfectly
adequate for patches and discussion around patches.

I also know that documentation in Dusk is not perfect, but it's really hard to
cover all possible cases beforehand. These questions you ask allow me to expand
on a particular subject without overloading the documentation with needless
details. These could be a good way for others to gain better understanding of
Dusk.

Regards,
Virgil

[1]: https://git.sr.ht/~vdupras/duskos/commit/5e660b55b5f5955517e81de58cd780fe687e7510

On Sat Jun 17, 2023 at 8:38 AM EDT, Virgil Dupras wrote:
> The most straightforward way to go about this isn't to mangle with dictionaries,
> but to overwrite the "abort" alias with "realias".
>
> I also don't understand why you're trying to overload "abort"" rather than
> "abort".

Both of these choices came from me having an incomplete understanding of 
a lot of the foundational words in Dusk. I read a bunch of the 
documentation/code today and I think I have a better understanding of 
the dictionary structure / compiling words. I'll look into sending an 
updated patch soon!

> Do you think you have all details you need to carry on? Don't hesitate to ask
> for more, I don't know what you don't know.

I think so! I'll try and get a patch in soon.

> I also know that documentation in Dusk is not perfect, but it's really hard to
> cover all possible cases beforehand. These questions you ask allow me to expand
> on a particular subject without overloading the documentation with needless
> details. These could be a good way for others to gain better understanding of
> Dusk.

I think the documentation is quite thorough, and I've found most of my 
questions answered in it. Mostly, my confusion comes from relatively 
limited forth knowledge. I spent a lot of time today reading the docs 
and feel like I have a much better understanding of the system

Alex