<MrMobius>
so i guess maw means bye as well as hello
<MrMobius>
KipIngram, thought any more about building a calculator?
<lispmacs[work]>
is there sort of a standard way to drop your current return frame in Forth? Or is that very implementation dependent?
<lispmacs[work]>
or, what I meant to ask was if you could make a call without building a return frame
<lispmacs[work]>
like, tail call recursion but at an arbitrary place
<lispmacs[work]>
maybe a word to jump to an arbitrary address and continue executing, though that seems rather implementation dependent
<MrMobius>
lispmacs[work], how about RDROP?
<MrMobius>
drop the return address so that when you hit the end of the word it doesnt returned to the word that called it but to the word that called that word
<lispmacs[work]>
MrMobius: I don't think rdrop would work, per my requirement, since you would have to do the rdrop after getting into the word you had called
<MrMobius>
hmm ya
<kiedtl>
19
<kiedtl>
oops
<tabemann>
the problem with RDROP is it breaks if the calling word was using the rstack for something other than just a return address
<lispmacs[work]>
yeah, I definitely wouldn't want to call rdrop from within the called word
<lispmacs[work]>
I was thinking like a special version of EXECUTE that doesn't leave a return frame/address on the return stack
<lispmacs[work]>
seems like it would be real easy for the FORTH system designer to make such a word
<lispmacs[work]>
but I don't know if there is any provision for that in anything like core or core-ext
<lispmacs[work]>
it would be real handy for things like recursion and mutual recursion
<lispmacs[work]>
like my mutual recursion example in gforth:
<KipIngram>
I have words that can do a double return, but I take responsibility for only using them when it's not going to cause a problem.
<KipIngram>
Since I started using this stack frame capability that I designed, I do very, VERY little "stack twiddling." I haven't run into a need for a >R ... R> action.
Zarutian_HTC1 has joined #forth
Zarutian_HTC has quit [Read error: Connection reset by peer]
sts-q has quit [Ping timeout: 245 seconds]
sts-q has joined #forth
dave0 has joined #forth
mtsd has joined #forth
Regenaxer has left #forth [#forth]
Keshl has quit [Read error: Connection reset by peer]
Keshl has joined #forth
andrei-n has joined #forth
<proteus-guy>
MrMobius, I think autogen stack pictures would be very "forthy". Can't see any downside to it at all and would absolutely add to the correctness of the app.
<KipIngram>
You're talking about deriving the stack motion specification from the definition itself?
<KipIngram>
I've thought about that. In particular, I once had an idea for a "typed Forth" of sorts, and you would specify the effects on the type stack of each native word, and then the compiler would have to figure out the effects of new words on its own.
<KipIngram>
The idea was that you could overload word names by letting the operand type help choose the word. So
<KipIngram>
a b +
<KipIngram>
would add ints if a and b were ints, or add matrices if a and b were matrices.
<KipIngram>
Because the system would know what a annd b were.
<KipIngram>
It also allows compile time detection of over/under flow.
<KipIngram>
This wasn't something I envisioned building into a base system - I viewed it as a sort of "application shell" that I might implement on top of the base.
<KipIngram>
The difficulty arises with words like ?dup which have variant effects on the stack.
<KipIngram>
Until execution time you don't know what its effect is goinng to be.
<KipIngram>
And I very much wanted this done all at COMPILE time - not sittinng there effecting run-timer performannce.
jedb has quit [Quit: Leaving]
jedb has joined #forth
<KipIngram>
MrMobius: Not any really recent serious thoughts. I'm focused mostly on the software side of things right now.
<KipIngram>
(re: building a calculator)
<KipIngram>
I think about it from time to time, but eventually wind up asking myself what I'd really ever DO with it.
<KipIngram>
I really haven't put a calculator to SERIOUS use since college.
nihilazo has joined #forth
lispmacs has joined #forth
jedb_ has joined #forth
jedb has quit [Ping timeout: 252 seconds]
gravicappa has joined #forth
hosewiejacke has joined #forth
<proteus-guy>
KipIngram, your typed forth is pretty close to what I'm doing with ActorForth. Has overloading and also pattern matching!
<proteus-guy>
The difference is I am building a type system first, and a forth on top of it.
jess has joined #forth
X-Scale` has joined #forth
X-Scale has quit [Ping timeout: 245 seconds]
X-Scale` is now known as X-Scale
f-a has joined #forth
hosewiejacke has quit [Ping timeout: 268 seconds]
hosewiejacke has joined #forth
dave0 has quit [Quit: dave's not here]
<MrMobius>
for the auto generated comments, i was just thinking about showing the stack picture line by line
<MrMobius>
and of course you cant show anuthing if it depends on runtime data like ?dup so it would only work on some lines
<MrMobius>
one of the biggest pains is having more than 3 locals in a word and having nested loops. you waste more time on stack juggling than actually doing work. forth is really bad at that kkind of thing so you need the stack pictures
hosewiejacke has quit [Ping timeout: 240 seconds]
crest_ has joined #forth
crest has quit [Read error: Connection reset by peer]
<veltas>
I think my plan (when I am forthing again, I'm on my lisp holiday), is to use \\ for documentation comments, then consecutive \\ lines and the next line of code will get added to an HTML file
<veltas>
This is something that can be trivially parsed in Forth or some other language
<veltas>
Probably easy to do in Forth with recognisers (ewww standard forth get out!) ;)
hosewiejacke has joined #forth
hosewiejacke has quit [Ping timeout: 260 seconds]
Vedran has quit [Ping timeout: 252 seconds]
f-a has quit [Ping timeout: 265 seconds]
f-a_ has joined #forth
f-a_ has quit [*.net *.split]
jess has quit [*.net *.split]
mtsd has quit [*.net *.split]
Zarutian_HTC1 has quit [*.net *.split]
tabemann has quit [*.net *.split]
kiedtl|ltbx has quit [*.net *.split]
xybre has quit [*.net *.split]
f-a_ has joined #forth
jess has joined #forth
mtsd has joined #forth
Zarutian_HTC1 has joined #forth
tabemann has joined #forth
xybre has joined #forth
kiedtl|ltbx has joined #forth
<KipIngram>
MrMobius: Try out stack frames. It's made stack juggling a thing of the past for me.
tech_exorcist has joined #forth
jess has quit [Quit: Reconnecting]
jess has joined #forth
<KipIngram>
MrMobius: Here are my pertinnent definitionns. There's some macro naming going on here, so don't hesitate to ask if you need anything clarified.
lispmacs[work] has quit [Ping timeout: 252 seconds]
<KipIngram>
} restores the data stack pointer to what it was when { executed, but it also expects a parameter and drops that many *additional* stack items.
<KipIngram>
So you can create, use, and get rid of a new stack frame at any time with
<KipIngram>
{ ... use s0-s4 here ... <n> }
<KipIngram>
s0-s4 simply give the addresses of consecutive stack cells.
<KipIngram>
relative to the "frame register," which is set by { and restored by }
<KipIngram>
I was thinking "slot 0," "slot 1," etc. with that naming.
<MrMobius>
KipIngram, and s0-s4 is stored on the return stack?
<KipIngram>
No, they just put addresses on the stack.
<KipIngram>
There's no "content" of s0-s4 to save.
<KipIngram>
They're just offsets from the frame pointer.
<KipIngram>
So you could store something in the third item down from the frame pointer with s3 !
<MrMobius>
so the data stack then?
<KipIngram>
They're 'local variable' words.
<KipIngram>
s0-s4 aren't registers with things stored in them.
<KipIngram>
They're spots in the stack, relative to the frame register, which does hold a value.
<KipIngram>
{ save the old frame pointer on return stack; } recovers it.
<MrMobius>
and the frame register is separate from the data stack pointer?
<KipIngram>
So you can nest these frames.
<KipIngram>
Yes.
<KipIngram>
Because you want s0-s4 to keep "meaning the same thing" even while you diddle around the stack.
<MrMobius>
interesting
<KipIngram>
When I first made this system I offset from the stack pointer, but that got horribly confusing, because as soonn as you change the stack, the "content" of si changes.
<KipIngram>
The frame pointer stays put, even as the stack pointer ranges up and down.
<KipIngram>
It's a "stable reference point" within the { ... } frame, and it defines what addresses s0-s4 are bound to.
<KipIngram>
Another thing I did that was helpful in reducing stack commotion was to include words based on Hewlett Packard calculator langage.
<MrMobius>
then you can define s0! and s0@
<KipIngram>
So as a synonym for swap, I had x<>y, but then I also had x<>z and x<>t.
<KipIngram>
I could, yes.
<KipIngram>
I thought about doing that from the jump, but decided to go with this "address based" approach, just so I wouldn't need such a huge slew of words.
<KipIngram>
You can do anything with s0-s4 you want - they're just addresses.
<KipIngram>
I defined a couple of new words that work with any variable.
<MrMobius>
seems like load and store are the main advantage of those
<KipIngram>
Like we've always had +! but I added -! and also 1+! and 1-! and some other powers of two as well.
<KipIngram>
Great for updating s0-s4 when they are pointers.
<KipIngram>
Like I can step s3 through an array with s3 8+!
Vedran has joined #forth
<KipIngram>
Purely convenience; I could already have said 8 s3 +!
<MrMobius>
where did you get this idea? im gonna use it and should say where it comes from
<KipIngram>
Well, I just made it up. Obviously I've read all kinds of things, but I defined this out myself.
<KipIngram>
So you can just credit me if you want to.
<KipIngram>
Are you interested in my "other frame"? I have a second flavor of frame that lets me return up from way deep in a bunch of nested code to a pre-defined exist point.
<KipIngram>
That's {| and |}
<KipIngram>
It was enormously useful for dictionary search.
<MrMobius>
how does that work?
<KipIngram>
The "normal case" that I actually coded for was to walk the structures without finding a match. That's all the code was prepared to handle.
<KipIngram>
Then if I do find a match, I |} my way out, from the success point.
<KipIngram>
Let me pitch those into pastebin as well - one sec.
<KipIngram>
I call them "exception frames" and it's the "exception frame register."
<KipIngram>
It restores both data AND return stack to where it was at {|, but it brings the TOS value from the jump out point back up to the top.
<KipIngram>
To use it, you say {| ... ... code ... ... |} within a single efinition.
<KipIngram>
But then, many layers of code lower, down in any sort of complex code structure, you can have a second |}
<KipIngram>
And it will "send you" back up to the first |}
f-a_ has quit [Quit: leaving]
<KipIngram>
What it mean in my dictionary search code was that all those layers of code didn't have to think about carrying a success result back up through themselves.
<KipIngram>
It reduced the number of cases they had to consider by one, and that vastly simplified the code.
f-a has joined #forth
<KipIngram>
And by the way, I used several of the { ... } frames along the way, and it has a very useful feature of "cleaning up" your stack for you.
<KipIngram>
So you avoid having to drop a bunch of crap when you discover something you need to act on.
<KipIngram>
So I wrapped { .. } around each bit of "data structure traversal" code. Walkingn the linked list of vocabularies, walking the linked list of words in each vocab, and iterating over the character of words.
<KipIngram>
When any loop "terminated" (end of word, end of list, etc.) I used } to clean up any artifacts from the stack so the next higher loop could do it's "next" dance.
<KipIngram>
And at the bottom where I finally found a match, I got the match pointer in TOS and did |}, and that took me all the way back up to the exist point of the topmost word.
<KipIngram>
I don't want to claim that I did these and no one ever had - I'm sure these ideas are already out there.
<KipIngram>
But I concocted them on my own; didn't "see them" anywhere.
<KipIngram>
The operation of |} is slightly subtle. It doesn't really transfer control back up instantly. It modifies the return stack so that when you hit the next ; it will be as though it was the ; from back at the top, instead of the one you're actually executing.
<KipIngram>
Make sense?
<KipIngram>
It doesn't do anything weird to the instruction pointer, or save it, etc.
<KipIngram>
Only the return stack and the data stack.
<KipIngram>
Jesus, I feel a bit like a truck ran me down.
<KipIngram>
It provides an example of {| ... |} in action.
<KipIngram>
That little bit of code handles the linked list of vocabularies, the linked list of words in each, and the character loops of comparinng the words.
<KipIngram>
I was pretty pleased.
proteus-guy has joined #forth
<KipIngram>
So down in "gotit," there's the second |}. It's immediately followed by the ; of gotit.
<KipIngram>
You do execute that ;.
<KipIngram>
But it *does* what the ; after the upper |} would have done.
<KipIngram>
Returns you to the caller of (find).
<KipIngram>
If you do NOT find the word, anywhere, then eventually you will execute the upper |}, but anytime you succeed you never reach it.
<KipIngram>
My code feels much more terse to me than it used to, and I give the credit to { ... } and {| ... |}.
<KipIngram>
I'm sorry, that code is all strewn with my conditional return and conditional looping mechanisms - ask if anything is unclear.
<KipIngram>
Notice there are no traditional control structures.
<KipIngram>
No IF ... THEN, or any of the others.
<KipIngram>
Conditional return and conditional looping obviate the need for those, I think.
<KipIngram>
And conditional return as a control mechanism promotes short definitions, too.
<KipIngram>
I added the conditional returns and what not a couple of Forths ago.
<KipIngram>
I added the { ... } to the last one, but used it only minimally.
<KipIngram>
This go round I've realized that using it heavily has a real benefit, and this go round is the first time I've had the {| ... |} also, though I've played some ad hoc r> drop games in the past.
<KipIngram>
But those were always exceptional cases.
<KipIngram>
Not something I used as "part of how I program."
<KipIngram>
These days it is part of me - I start thinking about return structures when I first start designing a bit of code.
<MrMobius>
interesting
<MrMobius>
do you ever define local words for s0, s1, etc?
<MrMobius>
so you can refer to them by name
<KipIngram>
No, not to date. However, I have a loose vision of a fancy compiler that would bind those to names specified in a stack effect like comment.
<KipIngram>
That would be a compile-time feature; once the code was compiled it would be back to s0, s1, etc.
<KipIngram>
But so far I just note down or remember what they all are, and since they don't change the way they would if they were referenced off of the stack pointer it works pretty well.
<MrMobius>
right. i can think about how to do it with the dictionary but i dont want to lose space if theyre only used temporarily
<KipIngram>
What I tend to do is define "short words' that are more than just variable wrappers. For example, in my number convnersion code I have this:
<KipIngram>
: set s1 or! ;
<KipIngram>
Which calls out s1 as where my "flags" go.
<KipIngram>
That's a little like what you suggested - it just includes addinng a little functionality at the same time.
f-a has left #forth [#forth]
<MrMobius>
ya that works though its still hard on readability which forth generally fails hard at
<KipIngram>
Right - if I ever do that, it will be using some dynamic compile time structure that keeps up with it for me and then is discarded.
<MrMobius>
despite other advantages
<KipIngram>
Along the same lines, there then occurs
<KipIngram>
: clr not s1 and! ;
<KipIngram>
: bits s1 @ and ;
<KipIngram>
and so on.
<KipIngram>
It's a set of words for flag manipulation.
<MrMobius>
i understand. thats just not a good solution for a lot of cases
<MrMobius>
but already better than what you usually have
<KipIngram>
Sure.
<KipIngram>
So far I haven't needed an s5.
<KipIngram>
and of course it would be possible to have <n> sn
<KipIngram>
Which would be a lot like PICK, except just leaving an address instead of the content.
<KipIngram>
I don't have that either, though.
<MrMobius>
what you need is a temporary dictionary that gets dropped on ;
<KipIngram>
Generally speaking I agree with the Forth philosophy of not having too many active stack items at oncne.
<KipIngram>
I've just found that once in a while it seems unavoidable. Maybe I'm just not good enough yet.
<KipIngram>
Right.
<KipIngram>
I actually had that in my last one.
<KipIngram>
You notice some of those words have .: instead of :
<MrMobius>
heh that "philosophy" is like a lot of stuff - not any great insight but instead pretending like an insurmoutable shortcoming of the language is somehow an advantage
<KipIngram>
In my last Forth .: defined the header in an allocated buffer that I could later get rid of.
<MrMobius>
other wise you descend into PICK/ROLL hell. i dont buy it for a second
<KipIngram>
This time I've foregone that complexity - I just have .: set a bit in the header, and later I execute a word .wipe that goes through the search path and unlinks any words with that bit set from the search path.
<KipIngram>
So I don't actually get the memory back.
<KipIngram>
But I do get the words out of the namespace.
<MrMobius>
of course it's unavoidable. it really depends on what youre doing. no need for many stack items if youre blinking LEDs and then those guys pretend they have programming in all spheres at all times mastered
<MrMobius>
for even medium complexity stuff you need a lot more than that on the stack and there's no way around it other than using global variables or "local variables" as you see them in Starting Forth etc
<KipIngram>
Take as an example QUERY where you have a command line history like Linux gives you.
<KipIngram>
You have a buffer pointer, a cursor position, a current size, a max size, and you have pointers that may walk along the command history.
<KipIngram>
And you have characters coming and going.
<MrMobius>
ya losing that memory is not such a big deal on a pc but is a deal breaker for me on a 6502 for example
<KipIngram>
That's a slew of things to work with, and at least part of the time you really at least almost need them all at once.
<KipIngram>
The { ... } thing was just a LIFESAVER in that situation.
andrei-n has quit [Quit: Leaving]
<KipIngram>
Oh, yes - in an embedded application you can't afford to toss memory aside.
<KipIngram>
Well, you might be able to. Depends. But certainly in some applications you can't.
<KipIngram>
Of course, in those cases you might not have a dictionary on the target at all.
<KipIngram>
I've never really dug into the whole "tethering scenario," but it clearly seems to pose some unique requirements.
<KipIngram>
I expect most of the things I build one of these days to have fairly significant computing resources on-board.
<KipIngram>
I generally plan to have the whole system on-board, and I'll connect to it with a bluetooth serial connection or something.
<MrMobius>
right. you would want a "headerless" forth for a lot of embedded stuff. on my calculator i have a dictionary since the user is typing in commands and defining words
<MrMobius>
sure. if its a fun project, the sky is the limit. no reason to skimp just to save a dollar on memory
<MrMobius>
tethering is interesting because you need some kind of device to program the target if its not programming itself
<MrMobius>
so you can compile everything from scratch like C and let the board you bought reflash everything or you can use the tether to interact with the target and program it
<KipIngram>
Right.
<mark4>
not a headerless forth, a teathered forth where the headers are all on the host not the target :)
f-a has joined #forth
<KipIngram>
Yes.
<KipIngram>
When I've thought about that, I've always felt that you *also* want host-side words blended in as well. You're running your host in Forth, and then you have these other words you use to craft your target image.
<KipIngram>
One of the next things I do will be the compile support. I want to be careful about that - I don't want to write it so that it's hard to "redirect" the compile output to a secondary image, rather than the running system.
<KipIngram>
But most of the time I will want compiling to affect the running system.
<KipIngram>
So I need some kind of a "switch."
<KipIngram>
It's really the same issue - the fact that the target will run on the host as well is really a non-issue. It's still a "different system" from the one you're working in.
<KipIngram>
I think it will just be a matter of 1) knowing where HERE is in the image at all times and 2) knowing the base address of the image, so that I compile offsets from there.
<KipIngram>
I actually have two HEREs and two "origins." One for word bodies and data; one for headers and CFA/PFA pointer pairs.
<KipIngram>
And after this little dip in the Lisp pool I may wind up adding a third region, as the "Lisp region."
<KipIngram>
We'll see.
f-a has left #forth [#forth]
<KipIngram>
Just having that off to the side and being able to intersperse Lisp code with Forth code will be simple. What I'm unsure of is exactly to what extent they'll "interact with one another."
<KipIngram>
It would be fairly easy to have the input parsinng stuff "switch gears" inside ( and ).
<mark4>
the distinction between host and target should be utterly seamless
<mark4>
host
<mark4>
: foo .... ;
<mark4>
target
<mark4>
: foo .... ;
<mark4>
host foo
<mark4>
target foo
<mark4>
but words like dot on when target is the taget are somewhat more complex
<mark4>
a dot needs to fetch the top item of the targets parameter stack and display it on the host
<KipIngram>
Yes, I agree with that, mark4.
<MrMobius>
mark4, thats no different than storing the headers on your pc so it's still headerless with respect to the taget :)
<mark4>
i spent the last 2 weeks writing my json parser and worrying over it and changing this and chaning that and fixing this over here and NOT RUNNING IT at all lol
<KipIngram>
Or not - you could use that same syntax with the headers bi-located.
<mark4>
started single stepping it last night at like 1am and it worked flawlessly except for one small mistake i made which i fixed and went to sleep
<KipIngram>
mark4: That's ok - I looked at my number conversion code in a vim buffer for well over a week before finally pecking it in and shaking it down.
<mark4>
then there was another minor snafu that i fixed and now as best i can tell the entire freeking thing works perfectly lol
<KipIngram>
Congrats. :-)
* KipIngram
totally believes in "up front 'thought' work."
<mark4>
yea i always fret over my code for a while before i exerecise it. constantly goving over every inch of it over and over and over again
<KipIngram>
Righto.
<KipIngram>
I know exactly what you mean.
<mark4>
makes you so familiar with it that when you are debugging and you see it zig when it should have zagged you just KNOW where you went wrong :)
<KipIngram>
Yes.
<KipIngram>
mark4: Maybe the thing to do re: the situation you described above is to have a finer grain of control. You'd have host and target words like you said, and new definitions would definitely go to the current one. But in cases where a word is found in both dictionaries, maybe you'd also like to specify how to resolve that. You could have "define in target, execute from target," and "define in target, execute
<KipIngram>
from host." Finally, if you wanted to override that preference, you would have a way to do that too - it would keep effect for one word.
<KipIngram>
I don't know. I haven't tried that out. Might be too cumbersome or error prone in practice.
<KipIngram>
The problem only arises when you're interpreting if you're making a definition for the target, then all of its content has to come from the target.
<KipIngram>
I think.
<mark4>
a target word cannot refer to a word on the host and vice versa
<mark4>
if you want to run foo on the host you type host foo
<KipIngram>
^^ Right.
<KipIngram>
I guess you COULD have a system where you gave them the ability to trigger actions on one another, but that's not the general case we're talking about.
<mark4>
this is where my stats bar comes in real handy in x4, you could add an entry there for which system you are currently targeting
<KipIngram>
Makes sense.
<KipIngram>
Here's a possible rub.
<mark4>
or you could type .target or something and it will say "target" or "host"
<KipIngram>
The way I intend to set this system up, I will have "virtual instruction" words that function as macros. I'll use them to define primitives. So say I'm defining a target primitive. I might use a macro that's supposed to spew several target assembly instructions into the image. Right now. And that amcro would run on the host. But I guess those would be immediate words, so we'd know they aren't "really"
<KipIngram>
part of the target definition.
<KipIngram>
Assembly instructions will generally always work that way - they execute immediately and pour binary bits into the target dictionary.
<KipIngram>
But it shouldn't be a problem - supposedly you wouldn't find those words in the target dictionary. You'd find them in the host dictionary, even though the act to build the target image.
<mark4>
no. if you execute a word on the target thats not there you should not execute a word of the same name on the host
<mark4>
it should be a blah ?
<mark4>
eitehr you forgot to define blah or you MEANT to have host current
<mark4>
but executing blah on the host when you menat to run the non existent definition of it on the target could have disasterous consequences
<MrMobius>
KipIngram, have you seen mecrisp?
<mark4>
not really looked at it
<mark4>
know of it :)
<KipIngram>
No, I haven't - I'll look it up.
<KipIngram>
Oh, nice.
<KipIngram>
I should look that over as "ARM training." I'm fairly competent at Intel assembly, but zero ARM experience.
<KipIngram>
That doc dave0 shared with us the other night (the higly commented lisp system source) was for ARM, so that's useful to me in that way as well.
<KipIngram>
I really had a lot of fun look through that.
<KipIngram>
Really neat watching the system "rise up out of the ground" so to speak.
<KipIngram>
I think I'll try to make my "Forth in Forth" source be structured kind of like that, when I get to it.
<KipIngram>
Though I'm thinking about a way to do the comments other than inline.
<KipIngram>
Still stuck on that comments database idea.
<KipIngram>
It's still a very nebulous thing in my mind, but I'm fairly hot for the idea.
<mark4>
i prefer thumb2 to x86 now but i loathe and despise aarch64 produced by gcc
<mark4>
2/3 of the opcodes will be reg, reg move operations.
<mark4>
literally 2/3 of your compiled object code on aarch64 is mov reg, reg
<mark4>
i think the only time arm got their instruction set right was with thumb2
<KipIngram>
Yuck.
<KipIngram>
I've always found the "two instruction sets in one" thing to be a little distasteful.
<mark4>
arm was good. thumb was a utter failure.
<mark4>
thumb2 was perfect(ish)
lispmacs[work] has joined #forth
<mark4>
tho ITT blocks are a bit confuzering
<mark4>
prefer being able to put any condition on any opcode
<mark4>
if condition does not exist opcode is a nop
Zarutian_HTC1 has quit [Ping timeout: 245 seconds]
<KipIngram>
I'm not familiar enough with it yet to speak intelligently.
andrei-n has joined #forth
Zarutian_HTC has joined #forth
mark4_ has joined #forth
Gromboli5 has joined #forth
rann_ has joined #forth
WilhelmV1nWeiner has joined #forth
phadthai_ has joined #forth
tech_exorcist has quit [*.net *.split]
nihilazo has quit [*.net *.split]
Gromboli has quit [*.net *.split]
mark4 has quit [*.net *.split]
WilhelmVonWeiner has quit [*.net *.split]
joe9 has quit [*.net *.split]
rann has quit [*.net *.split]
phadthai has quit [*.net *.split]
Gromboli5 is now known as Gromboli
rann_ is now known as rann
joe9 has joined #forth
tech_exorcist has joined #forth
nihilazo has joined #forth
<KipIngram>
Ergh. Watching videos on B-Trees.
<KipIngram>
Looks to me like they'll be handy for this comment system.
<KipIngram>
The tree will get sorted by the location in the source that the comment attaches to.
<KipIngram>
Either block / line or block / line / col; haven't decided yet.
<KipIngram>
So when I go to edit a source block, I won't have any pointers there to tell me there's a comment - I'll need to check the b-tree and see what comments are attached in that block.
<KipIngram>
Say I decide to attach to block/line. What that would lead me to do is have a panel on the screen for displaying the comment, and when I put the cursor on a line of the block, any associated comment will show up in that other panel.
<KipIngram>
So the b-tree will have pointers into the source code, that it's sorted on, and pointers into other disk resources where the comments actually live.
<veltas>
B-trees are one of the fundamental data strutures in my opinion
<KipIngram>
Yes - they're very useful for when you have an access time difference like that between disk and RAM.
<KipIngram>
Seems like a natural toolkit to have if you're going for raw blocks in your Forth system.
<veltas>
Yes they're suited for hard storage
<veltas>
Nope!
<veltas>
The natural toolkit for raw blocks in Forth is writing out blocks yourself
<KipIngram>
:-)
<KipIngram>
Well, but you have to decide how to organize them.
<KipIngram>
I agree - I want to write all this myself.
<veltas>
Organize it like a filesystem if you want
<KipIngram>
But I want to do it in a way that promotes good performance, and a b-tree-based scheme will help with that.
<veltas>
Block 1 has the 'root' contents, contains comments with the name and block numbers of main directories
<KipIngram>
I guess what I'm saying is that if I were going to write a file system, I'd consider making b-trees part of it.
<veltas>
Then subdirectories are referenced from those blocks
<KipIngram>
Yes, I understand file systems. :-)
<KipIngram>
Basically at least.
<veltas>
You do all this by hand, not with a b-tree
<veltas>
It's not a "filesystem", such things are not necessary for forth programmers
<veltas>
Blocks are all we need
<KipIngram>
Well, at the momennt I'm considering this for organizing this comment database. I may decide it's not the way to go, but I'm not there yet.
<KipIngram>
Just staarted thinking about it.
<KipIngram>
If I toss it out I'll let you know, and compliment you for forecasting that.
<veltas>
Nah don't automate it, the second you automate a "comment database" you should make a real database or filesystem
<KipIngram>
I won't use it if it's too much work.
<KipIngram>
I want a place over there to go type a comment that will stick with that point in the code.
<KipIngram>
And yet I don't want it "in the code."
<KipIngram>
That means if I add a line above a comment point, I'll need to increment that comments line # to match.
<KipIngram>
This would all be part of writing the source editor.
<KipIngram>
Returning to my video...
<veltas>
It occured to me while writing effectively a filesystem from scratch that the filesystem is a naturally balanced tree, where the balancing part is the user
<veltas>
After all users would keep a sane amount of stuff in each directory/node
<lispmacs[work]>
how does one program tree structures in Forth - as far as handling the memory allocation? Do you need an allocate/free for that?
<veltas>
Really depends
<veltas>
If it's a tree you can build up and don't want to 'free' any of it you can do it in dictionary
<veltas>
Or in another stack-like place
<veltas>
If you want to add/remove parts then you could use allocate/free, but could also use simpler allocation schemes if data is fixed size like a block pool
<lispmacs[work]>
yeah, I guess it doesn't sound too complicated if each node memory allocation is the same
<veltas>
If the tree's static and you can write it all out in advance then you might encode it somehow within colon definitions, where each node is a word
<lispmacs[work]>
i am used to lisp where it is easy to make a tree, but your next node could be allocated from anywhere, and automatically deallocates itself after being unlinked
<veltas>
I am used to Lua where it is easy to make a hash table
gravicappa has quit [Ping timeout: 260 seconds]
gravicappa has joined #forth
joe9 has quit [Ping timeout: 268 seconds]
<cmtptr>
lua is good
<cmtptr>
and so are chairs
mtsd has quit [Ping timeout: 245 seconds]
crc has quit [Read error: Connection reset by peer]
joe9 has joined #forth
Zarutian_HTC has quit [Read error: Connection reset by peer]
Zarutian_HTC has joined #forth
crc has joined #forth
wineroots has quit [Quit: Gateway shutdown]
jess has quit []
jess has joined #forth
hosewiejacke has joined #forth
gravicappa has quit [Ping timeout: 240 seconds]
hosewiejacke has quit [Client Quit]
andrei-n has quit [Quit: Leaving]
tech_exorcist has quit [Quit: tech_exorcist]
<KipIngram>
I did a fairly extensive amount of stuff with a block pool on my last one; it was fine. Decided this time I didn't want to build that complexity in at the lowest level like I did before.
dave0 has joined #forth
<dave0>
maw
<KipIngram>
Hey dave0.
<dave0>
maw KipIngram
<KipIngram>
:-)
<lispmacs[work]>
I've found that Forth is probably the easiest language to debug
<lispmacs[work]>
in my experience. as far as tracing my mind through the code I've written
<KipIngram>
I've found it fairly straigtforward to debug stuff even with a barely (or not) working system.
<KipIngram>
Before anything much was working at all, I'd just push an exit call through my test code, until I segfaulted instead of exited.
<KipIngram>
Then I knnew where the fault was.
<KipIngram>
Move down into the offending word, lather rinse repeat.
<KipIngram>
Pretty quickly it's narrowed down enough that you can just look carefully at the code and find out what's wrong.