Discuss documentation about dbg HOT 31 CLOSED

OT: mental distractions in the hospital

Best wishes on being edited by the surgeon. Let's hope the surgeon prefers vim(1) over emacs(1) so that the surgery process focuses more on you than on the editor itself. :-)

Suggestion: when you are in that twilight phase of post-op surgery recovery, think about a problem to solve entirely in your mind (no paper, no internet: nothing but your thoughts). Make sure this problem can take many hours to solve, or a problem that is open-ended: something that require you to hyper-focus on the problem instead of your post-surgery situation and all of those annoying machines that go bing and the many hospital bed interruptions of rest as the nursing staff does their work.

Anyway, we selected a number theory problem to work on:

Find the longest cubic polynomial:

f(x) = a*x^3 + b*x^2 + c*x + d

for integers a, b, c, d, x such that f(x) is prime for a nice consecutive run of x.

For example:

f(x) = x^3 - x + 7

is prime for -1 <= x <= 5 ... 7 consecutive integers!

The values don't get very large .. you just have to concentrate and solve. 
This problem requires you to focus on adding, subtracting, multiplying and factoring numbers. 
The values need not be large.  Much of the space involves 2, 3 or sometimes 4 digit values. 
Not impossible to do in your head.  Reduce the size of a, b, c, d, x if they get too large.

It is OK to loose track of where you were.
It is OK to drift off to sleep or be distracted by some external event.
The point is NOT to find a solution, but rather to WORK on a solution. 
So it OK to make mistakes, to forget stuff, to restart, etc.

BTW: About the best one we found, simply by picking random coefficients, was:

f(x) = x^3 + 10*x^2 - 67*x + 193

is prime for -15 <= x <= 13 ... 29 consecutive integers!

It turns out that that 29 consecutive integers is hard to beat. 
Still the point is NOT finding longer sequences. 
The point is try try to find nice runs of primes while distracting yourself
from the annoying medical environment.

from dbg.

Sure. And thank you again for the best wishes of my surgery and giving me an idea of something to do when waking up after it (see comment #1 (comment)). It was funny how you put the surgery and funny in general - a much needed laugh (or laughs)!

You are most welcome.

And don't forget to review your personal man page after being edited .. to be sure your own internal documentation remains up to date. 😀

Very funny! Good word play in there too whether intentional or not.

I'm still not in the clear of recovery. I mean the doctor was okay with me not going back but I'm having some issues (minor and he's not too concerned but given how awful the situation was I am being extra extra careful) and so I will be seeing him again. Hoping I won't have to go back many more times though.

Well I'm off to do something else that doesn't require any thinking. Good day and good luck with Internet access / other things you mentioned!

from dbg.

I also just noticed something with the example program I wrote. Perhaps it should tell the user what is going to happen before it happens as it might be alarming to some people to run it and see errors and warnings.

Currently one would see:

$ ./dbg_example 
Warning: main: elephant is sky-blue pink
debug[3]: file: foo.bar has length: 7
ERROR[2]: main: test: errno[1]: Operation not permitted

but perhaps it should at least say something before each example function is used (what will be called and with the same args and also what the output should look like - kind of like I have in the comments)? What do you think?

from dbg.

With commit 09b6563e8f38213eceafc01e9a1ca80458c2987c there are 6 new functions in the dbg facility:

Released dbg version 2.4 2022-06-26

Version 2.4 2022-06-26 contains functions to write (form)
a message, debug diagnostic message, warning, or error
message into a string buffer:

   extern void snmsg(char *str, size_t size, char const *fmt, ...)
   extern void sndbg(char *str, size_t size, int level, char const *fmt, ...);
   extern void snwarn(char *str, size_t size, char const *name, char const *fmt, ...);
   extern void snwarnp(char *str, size_t size, char const *name, char const *fmt, ...);
   extern void snwerr(int error_code, char *str, size_t size, char const *name, char const *fmt, ...);
   extern void snwerrp(int error_code, char *str, size_t size, char const *name, char const *fmt, ...);

These functions produce the same text as their counterpart functions,
however instead of writing that text onto a stream, the text is
copied into a buffer of known maximum length.  The text is NOT followed
by a newline, however the buffer is NUL byte terminated.

The seqcexit tool, version 1.8 2022-06-02, will sequence
snwerr() and snwerrp() calls.

These 6 new functions need to be documented.

I was thinking the same. At first I was thinking of the man page but now that I've read the full comment (I read preview in iOS mail notifications) I remembered the readme file as well. This brings up two points.

First of all do you want to write those details in?

Second of all whether you want to do that or not we should discuss the things I brought up (maybe in the other thread - not sure if it was this one or not and I'm not looking up .. just quickly replying to comments and then I hope to rest again: been awake since just after 0000 :( . I can elaborate more later if you need. Should I do that?

from dbg.

With commit 09b6563e8f38213eceafc01e9a1ca80458c2987c there are 6 new functions in the dbg facility:

Released dbg version 2.4 2022-06-26

Version 2.4 2022-06-26 contains functions to write (form)

a message, debug diagnostic message, warning, or error

message into a string buffer:

extern void snmsg(char *str, size_t size, char const *fmt, ...)

extern void sndbg(char *str, size_t size, int level, char const *fmt, ...);

extern void snwarn(char *str, size_t size, char const *name, char const *fmt, ...);

extern void snwarnp(char *str, size_t size, char const *name, char const *fmt, ...);

extern void snwerr(int error_code, char *str, size_t size, char const *name, char const *fmt, ...);

extern void snwerrp(int error_code, char *str, size_t size, char const *name, char const *fmt, ...);

These functions produce the same text as their counterpart functions,

however instead of writing that text onto a stream, the text is

copied into a buffer of known maximum length. The text is NOT followed

by a newline, however the buffer is NUL byte terminated.

The seqcexit tool, version 1.8 2022-06-02, will sequence

snwerr() and snwerrp() calls.

These 6 new functions need to be documented.

I was thinking the same. At first I was thinking of the man page but now that I've read the full comment (I read preview in iOS mail notifications) I remembered the readme file as well. This brings up two points.
First of all do you want to write those details in?

We are not sure which details. Do you mean text for the 6 new functions?

And by "write those details in" do you mean in a new comment in the thread, or write them elsewhere?

Well I was thinking README.md. Do you want to do that? I can add them to the man page of course.

I'll have to elaborate on the other comment later on. Hope I can do it today but it might have to be another day. Have to go do the Covid test for the surgery on Thursday. Later I have another appointment. If I don't get to this today I hope you enjoy the rest of your day!

from dbg.

As you requested on the mkiocccentry repo I am opening this here.

To start out: what do you think should be changed with the man page? If you think it's complete for now how would you like it to be referred to in the README?

Looking at the repo I think it would be good if the README could be dramatically cut in size. I don't know what most people would prefer but I think some might look at the length (even with the tl;dr part) and look for something else instead. But perhaps with just the tl;dr part referring to the man page (which actually has an example program) and another file that has more details (not sure what it would be called - maybe something to do with the api? I really don't know) it might seem much less formidable to some people?

Just some initial thoughts to get a discussion started.

This is one of the things I was thinking of though. Anyway I must get going.

from dbg.

Well I was thinking README.md. Do you want to do that? I can add them to the man page of course.

OK, we will.

from dbg.

Would you do me a favour please? If I don't do the updates in the coming days please remind me. I hope I can do it before my surgery but if not I should not too many days after I should expect.

Again, very best wishes on your surgery prep, surgery experience, post surgery wake-up, and the long surgery recovery. Hope you find ways to make the experience enjoyable.

Thank you! Well someone dear to me got back in touch with me a few weeks ago so things are going well in a way. Picked up like it was yesterday. The true sign of a true friendship.

If coding, code editing, code reviewing (all that you do for this repo etc.) helps before surgery,and when you find the energy after your surgery to work on this repo: please do. However, please try not to overdo it, especially avoid the point where it negatively impacts your recovery.

I really appreciate that! I won’t overdo it but I appreciate the reminder!

We will be extra patient with a slower speed of your repo activity. We will welcome reading any OT general recovery progress updates after the surgeon edits you. 😷

Thank you very much my friend! Funny way of putting it too!

We DO request you resist the urge to code during surgery. 😁

Very funny! I assure you that I won’t! When I am allowed to I have twilight instead of general anaesthesia. If I am allowed and it’s something that will work for me I stay wide awake.

This surgery requires general anaesthesia so I certainly won’t be working on the repo at the time 😀

It’s at 1330 and I probably will not be home until at least 1700 (at least!) hours and I will be going to sleep at that point. Of course I will have to get up because of my prostate but that’s always the case.

I don’t know if I will say anything in the other thread until the next day but we’ll see.

Hope you have a great day my friend!

from dbg.

FYI: I have some updates to dbg_example.c. These are not yet in the man page. I am not going to commit them now and I'm not sure if I will do so today even. I think the changes will be very helpful though.

I was thinking I would commit them at the other repo and you could copy them over. However since I already forked this repo I might do it on both. If however I haven't done a pull request yet on either and you have a preference that I do it on one or the other please let me know.

Hope you're having a nice sleep my friend! I'm going to try resting again. Hope you have a great day when you wake up!

EDIT 0:

This is what the changes make it look like:

NOTE: Setting verbosity_level to DBG_MED: 3
NOTE: The next line should say: "Warning: main: elephant is sky-blue pink"
Warning: main: elephant is sky-blue pink

NOTE: The next line should read: "debug[3]: file: foo.bar has length: 7"
debug[3]: file: foo.bar has length: 7

NOTE: The next line should read: "ERROR[2]: main: test: errno[1]: Operation not permitted"
ERROR[2]: main: test: errno[1]: Operation not permitted

The strings and errno values (including errno string) are specified via format specifiers so if for some reason there are different values they should still be correct on the same system.

And with that I'm gone for a while - maybe for the day but we'll see - so I bid you well for now!

from dbg.

With commit 4e229bc

Added initial documentation of snfoo() dbg functions.

Added some initial documentation of the new fixed buffer functions
to dbg.md.  This documentation is very preliminary.  It is intended
to serve as a basis for improved markdown and man page documentation.

Made some minor improvements to dbg.md and dbg.c.

We hope this will be enough for you, @xexyl , to complete the documentation of the new functions.

I'll have a look in the coming days. We still have to somehow shrink down the file a lot as well. I think that discussion will help there somewhat but again not today. I'm just taking it easy a bit longer and then going to try and sleep. I would be going to sleep early tomorrow too but I have a zoom meeting so I might not be able to. Thursday we can assume I won't be doing anything but hopefully tomorrow I can get the example file committed.

Hope you have a good rest of your day my friend!

from dbg.

Somewhat OT:

I'll have a look in the coming days. We still have to somehow shrink down the file a lot as well. I think that discussion will help there somewhat but again not today. I'm just taking it easy a bit longer and then going to try and sleep. I would be going to sleep early tomorrow too but I have a zoom meeting so I might not be able to. Thursday we can assume I won't be doing anything but hopefully tomorrow I can get the example file committed.

Hope you have a good rest of your day my friend!

I'm sure you gathered it already but I won't be doing anything today either. I'm very very tired. I have prepared a bit for surgery tomorrow though there are still a few things I need to do before I go to bed. I won't be doing anything tomorrow almost certainly.

I will be leaving late morning but I have other things to do tomorrow prior to the surgery too (including a pre-op thing). I'll go to sleep when I get home. Friday I will be taking it easy most likely but we'll see what I manage in the coming days. Anyway I wanted to let you know and wish you a good rest of your day.

from dbg.

Hmm... for some reason setting up ssh key for this repo is not working right. I was hoping to set it up so I could do a pull request. I'm not sure if I will today for given reasons (and I want to go back to sleep in a bit but can't sleep for now) but I was hoping to at least set this up. Will possibly have to do this another time then and that might very well mean another day.

I'll answer the accumulation (not accumulation: I can't think of the right word .. it's something like that I think but I'm too tired to ponder it more) of powers of two another time as well. Good day (though I know it's early morning)!

from dbg.

I have a commit for this on the other repo but unfortunately there's a problem with my local copy. It happened a while back where a commit from another day (yesterday in this case) is there as well - as in it will be committed again. I don't know why this happens.

I will have to possibly recreate my fork as that seems to be the solution. Maybe I can find another solution but if so that's not now. However I will have to defer this till later as after the surgery I have quite a bit of discomfort and pain (right now discomfort).

However the files changed were dbg_example.c and dbg.3 and quite a bit of changes. I suppose in the meantime if it's important enough (I rather gather that it's not) I could attach them here and you could commit them but in any event I will not likely resolve the problem today due to not wanting to overdo it after the surgery. Today I have to see another doctor due to a complication with the surgery and I hope that problem can be resolved. If so that'll make things a lot easier (though not easy) so I'll have to do this another day anyway.

Hope you're having a nice sleep my friend and good day to you!

from dbg.

Can this issue be closed now ? Feel free to do so if you think it can be.

from dbg.

Can this issue be closed now ? Feel free to do so if you think it can be.

Almost certainly yes .. once we get around to accessing a real computer and keyboard (not some hand held device) AND import the files from the mkiocccentry repo into this dbg repo.

What files have to be imported out of curiosity ? If it's the dbg.* I think they're already here? Or have there been updates to the dbg facility that haven't been copied here?

Until this happens, this issue should remain open .. but think of this as a reminder to us to import the files and close this issue when we do.

Sure. And thank you again for the best wishes of my surgery and giving me an idea of something to do when waking up after it (see comment #1 (comment)). It was funny how you put the surgery and funny in general - a much needed laugh (or laughs)!

from dbg.

Sure. And thank you again for the best wishes of my surgery and giving me an idea of something to do when waking up after it (see comment #1 (comment)). It was funny how you put the surgery and funny in general - a much needed laugh (or laughs)!

You are most welcome.

And don't forget to review your personal man page after being edited .. to be sure your own internal documentation remains up to date. 😀

from dbg.

Can this issue be closed now ? Feel free to do so if you think it can be.

Almost certainly yes .. once we get around to accessing a real computer and keyboard (not some hand held device) AND import the files from the mkiocccentry repo into this dbg repo.

What files have to be imported out of curiosity ? If it's the dbg.* I think they're already here? Or have there been updates to the dbg facility that haven't been copied here?

Updates from the mkiocccentry repo have not been copied into the dbg repo for example, as this is not a high IOCCC priority.

It is too bad that there isn't some form of "include file curds form repo URL whey" in git(1). On the other hand we can see how such inclusion would lead to ugly complications on tool internals, AND could lead to bad side effects when one repo changes and other repo gets impacted indirectly.

For example, imagine if iocccsize.c were magically included from the original author's repo and they made a change that impacted how Rule 2 worked.

For example, imaging if an interface change were made to the dbg repo that caused the code in mkiocccentry repo to break.

So probably it is best to not wish for a such a "include a file from an other repo" after all.

We will just have to manually copy over code and documentation as we do now.

Yes makes sense. What feature of git do you refer to though ?

from dbg.

Updated the dbg repo as per the dbg(3) and dbg.md changes as per commit a99396d.

Great.

from dbg.

With commit 09b6563e8f38213eceafc01e9a1ca80458c2987c there are 6 new functions in the dbg facility:

Released dbg version 2.4 2022-06-26

Version 2.4 2022-06-26 contains functions to write (form)
a message, debug diagnostic message, warning, or error
message into a string buffer:

    extern void snmsg(char *str, size_t size, char const *fmt, ...)
    extern void sndbg(char *str, size_t size, int level, char const *fmt, ...);
    extern void snwarn(char *str, size_t size, char const *name, char const *fmt, ...);
    extern void snwarnp(char *str, size_t size, char const *name, char const *fmt, ...);
    extern void snwerr(int error_code, char *str, size_t size, char const *name, char const *fmt, ...);
    extern void snwerrp(int error_code, char *str, size_t size, char const *name, char const *fmt, ...);

These functions produce the same text as their counterpart functions,
however instead of writing that text onto a stream, the text is
copied into a buffer of known maximum length.  The text is NOT followed
by a newline, however the buffer is NUL byte terminated.

The seqcexit tool, version 1.8 2022-06-02, will sequence
snwerr() and snwerrp() calls.

These 6 new functions need to be documented.

from dbg.

I also just noticed something with the example program I wrote. Perhaps it should tell the user what is going to happen before it happens as it might be alarming to some people to run it and see errors and warnings.

Currently one would see:

$ ./dbg_example 
Warning: main: elephant is sky-blue pink
debug[3]: file: foo.bar has length: 7
ERROR[2]: main: test: errno[1]: Operation not permitted

but perhaps it should at least say something before each example function is used (what will be called and with the same args and also what the output should look like - kind of like I have in the comments)? What do you think?

That is a good idea.

from dbg.

I also just noticed something with the example program I wrote. Perhaps it should tell the user what is going to happen before it happens as it might be alarming to some people to run it and see errors and warnings.
Currently one would see:

$ ./dbg_example 
Warning: main: elephant is sky-blue pink
debug[3]: file: foo.bar has length: 7
ERROR[2]: main: test: errno[1]: Operation not permitted

but perhaps it should at least say something before each example function is used (what will be called and with the same args and also what the output should look like - kind of like I have in the comments)? What do you think?

That is a good idea.

Agreed. I just have to (0) find the energy and (1) figure out what to write before and after each test case. I will then have to update the man page as well (I am saying this so I do don't forget to do this).

Hope you're having a nice sleep my friend!

Would you do me a favour please? If I don't do the updates in the coming days please remind me. I hope I can do it before my surgery but if not I should not too many days after I should expect.

from dbg.

With commit 09b6563e8f38213eceafc01e9a1ca80458c2987c there are 6 new functions in the dbg facility:

Released dbg version 2.4 2022-06-26

Version 2.4 2022-06-26 contains functions to write (form)

a message, debug diagnostic message, warning, or error

message into a string buffer:

extern void snmsg(char *str, size_t size, char const *fmt, ...)

extern void sndbg(char *str, size_t size, int level, char const *fmt, ...);

extern void snwarn(char *str, size_t size, char const *name, char const *fmt, ...);

extern void snwarnp(char *str, size_t size, char const *name, char const *fmt, ...);

extern void snwerr(int error_code, char *str, size_t size, char const *name, char const *fmt, ...);

extern void snwerrp(int error_code, char *str, size_t size, char const *name, char const *fmt, ...);

These functions produce the same text as their counterpart functions,

however instead of writing that text onto a stream, the text is

copied into a buffer of known maximum length. The text is NOT followed

by a newline, however the buffer is NUL byte terminated.

The seqcexit tool, version 1.8 2022-06-02, will sequence

snwerr() and snwerrp() calls.

These 6 new functions need to be documented.

I was thinking the same. At first I was thinking of the man page but now that I've read the full comment (I read preview in iOS mail notifications) I remembered the readme file as well. This brings up two points.

First of all do you want to write those details in?

We are not sure which details. Do you mean text for the 6 new functions?

And by "write those details in" do you mean in a new comment in the thread, or write them elsewhere?

from dbg.

Second of all whether you want to do that or not we should discuss the things I brought up (maybe in the other thread - not sure if it was this one or not and I'm not looking up .. just quickly replying to comments and then I hope to rest again: been awake since just after 0000 :( . I can elaborate more later if you need. Should I do that?

Please elaborate more.

from dbg.

Would you do me a favour please? If I don't do the updates in the coming days please remind me. I hope I can do it before my surgery but if not I should not too many days after I should expect.

Again, very best wishes on your surgery prep, surgery experience, post surgery wake-up, and the long surgery recovery. Hope you find ways to make the experience enjoyable.

If coding, code editing, code reviewing (all that you do for this repo etc.) helps before surgery,and when you find the energy after your surgery to work on this repo: please do. However, please try not to overdo it, especially avoid the point where it negatively impacts your recovery.

We will be extra patient with a slower speed of your repo activity. We will welcome reading any OT general recovery progress updates after the surgeon edits you. 😷

We DO request you resist the urge to code during surgery. 😁

from dbg.

With commit 4e229bc

Added initial documentation of snfoo() dbg functions.

Added some initial documentation of the new fixed buffer functions
to dbg.md.  This documentation is very preliminary.  It is intended
to serve as a basis for improved markdown and man page documentation.

Made some minor improvements to dbg.md and dbg.c.

We hope this will be enough for you, @xexyl , to complete the documentation of the new functions.

from dbg.

OT: mental distractions in the hospital

Best wishes on being edited by the surgeon. Let's hope the surgeon prefers vim(1) over emacs(1) so that the surgery process focuses more on you than on the editor itself. :-)

Thank you for the laugh - and quite a laugh it was! Just looking at it again I laughed out loud again.

Suggestion: when you are in that twilight phase of post-op surgery recovery, think about a problem to solve entirely in your mind (no paper, no internet: nothing but your thoughts). Make sure this problem can take many hours to solve, or a problem that is open-ended: something that require you to hyper-focus on the problem instead of your post-surgery situation and all of those annoying machines that go bing and the many hospital bed interruptions of rest as the nursing staff does their work.

I'm actually quite okay with that. I'm rather used to it. But then my first surgery I was 17 months old and back then the anaesthesia was worse - had that awful aftertaste. I have had more surgeries than most people could imagine ever having in many lifetimes!

But soon as I wake up enough I'll be going home. When I'm home I'll go to sleep.

However this problem you suggest is very intriguing and I'll have to look at it when I'm more awake. For now I am getting a snack before I sleep. Hope you have a great night my friend! I'll let you know how surgery goes when I can.

Anyway, we selected a number theory problem to work on:

Find the longest cubic polynomial:

f(x) = a*x^3 + b*x^2 + c*x + d

for integers a, b, c, d, x such that f(x) is prime for a nice consecutive run of x.

For example:

f(x) = x^3 - x + 7

is prime for -1 <= x <= 5 ... 7 consecutive integers!

The values don't get very large .. you just have to concentrate and solve. 
This problem requires you to focus on adding, subtracting, multiplying and factoring numbers. 
The values need not be large.  Much of the space involves 2, 3 or sometimes 4 digit values. 
Not impossible to do in your head.  Reduce the size of a, b, c, d, x if they get too large.

It is OK to loose track of where you were.
It is OK to drift off to sleep or be distracted by some external event.
The point is NOT to find a solution, but rather to WORK on a solution. 

I like this! But at the same time it is a problem for someone like me.

So it OK to make mistakes, to forget stuff, to restart, etc.

Similar to above. This can be so annoying but at the same time I know what you mean.

BTW: About the best one we found, simply by picking random coefficients, was:

f(x) = x^3 + 10x^2 - 67x + 193

is prime for -15 <= x <= 13 ... 29 consecutive integers!

It turns out that that 29 consecutive integers is hard to beat.
Still the point is NOT finding longer sequences.
The point is try try to find nice runs of primes while distracting yourself
from the annoying medical environment.

Though I should say that although I do love numbers when I was in school I was not well and so I didn't do the best in maths. I have however surprised myself quite a lot with programming in what I have done maths wise.

Back in 2017 during a talk with someone about something else entirely I figured out a way (and by during a talk I meant I was physically speaking!) to sum up powers of two. It's quite easy actually. What I mean is 1 + 2 + 4 + 8 + N. I need to get ready to sleep though so I'll pose this as a question: how would you go about it? Can you figure it out or do you already know even? I'll tell you my answer later on.

Good night and thank you for the laugh and also suggestions! It might be something I look into. I do have some new films to watch too of course.

Take good care for now and BCNU :)

from dbg.

Can this issue be closed now ? Feel free to do so if you think it can be.

Almost certainly yes .. once we get around to accessing a real computer and keyboard (not some hand held device) AND import the files from the mkiocccentry repo into this dbg repo.

Until this happens, this issue should remain open .. but think of this as a reminder to us to import the files and close this issue when we do.

from dbg.

Can this issue be closed now ? Feel free to do so if you think it can be.

Almost certainly yes .. once we get around to accessing a real computer and keyboard (not some hand held device) AND import the files from the mkiocccentry repo into this dbg repo.

What files have to be imported out of curiosity ? If it's the dbg.* I think they're already here? Or have there been updates to the dbg facility that haven't been copied here?

Updates from the mkiocccentry repo have not been copied into the dbg repo for example, as this is not a high IOCCC priority.

It is too bad that there isn't some form of "include file curds form repo URL whey" in git(1). On the other hand we can see how such inclusion would lead to ugly complications on tool internals, AND could lead to bad side effects when one repo changes and other repo gets impacted indirectly.

For example, imagine if iocccsize.c were magically included from the original author's repo and they made a change that impacted how Rule 2 worked.

For example, imaging if an interface change were made to the dbg repo that caused the code in mkiocccentry repo to break.

So probably it is best to not wish for a such a "include a file from an other repo" after all.

We will just have to manually copy over code and documentation as we do now.

from dbg.

Yes makes sense. What feature of git do you refer to though ?

There isn't such a feature.

from dbg.

Yes makes sense. What feature of git do you refer to though ?

There isn't such a feature.

Ah .. I thought when you referred to git(1) you meant an actual feature that GitHub was simply lacking. I know there are submodules and other things like it but I didn't know about this. Now I know why. It doesn't exist.

from dbg.

Updated the dbg repo as per the dbg(3) and dbg.md changes as per commit a99396d.

from dbg.