<mark4>
i just dont support DUMB definitions like invert or postpone
<mark4>
invert is a limp wristed attempt to not have to define NOT as being a 1's complement
<mark4>
because of legacy idiocy where in some forths it used to be identical to 0=
<mark4>
and postpone is an excuse to not have to know the language you are programming in
<mark4>
im probably even more rabidly ANTI ans forth than CM is :)
<mark4>
and he said that "The ans forth standard does not describe the forth language but a language of the same name"
<veltas>
Okay x64 is screwing up my terminal... inverting colors
<veltas>
Do you have white text on black background in your terminal?
<veltas>
You might want to try black text on white background if so
<mark4>
you can do white >bg black >fg clear
<mark4>
also you can set that as a default
<veltas>
I don't suppose there's a way to try and make its terminal control simpler?
<mark4>
what do you mean by simpler?
<mark4>
always have black on white?
<mark4>
cp x4.rcf ~/.x4.rcf
<mark4>
edit ~/x4.rcf and add
<mark4>
white >bg black >fg
<mark4>
my terminals are always white on black not black on white
<veltas>
By simpler I mean just do line-by-line I/O, none of this graphical / tui stuff
<mark4>
its actually not doing graphical tui stuff except in the hello message
<mark4>
and with the status bar
<mark4>
statoff turns off the status bar
<mark4>
which probably has the wrong date displayed in it
<mark4>
they changed the format of the time related files lol
<mark4>
date/time stuff
<veltas>
Is it meant to segfault so much?
<mark4>
you can add statoff to ~.x4.rcf too
<mark4>
what terminal do you use?
<veltas>
xterm
<mark4>
that should not be segfaulting
<veltas>
I've got black text on a white background
<mark4>
what are you doing to make it segfault?
<veltas>
Probably using it wrong
<veltas>
If I enter 'drop' with nothing on stack it segfaults
<mark4>
drop Stack Underflow
<veltas>
drop Segmentation fault (core dumped)
<mark4>
but im in a diff terminal let me check xterm
<mark4>
lol emerge xterm
<mark4>
wont take long
<veltas>
xterm is phat but it's very accurate with its emulation
<mark4>
xterm is also now maintained where it was not for a long time
<mark4>
thomas dicky maintains it. same guy that does ncurses
<mark4>
drop gives me a stack underflow here
<mark4>
did you build it or just go with the prebuilt?
<mark4>
make
<mark4>
./extend
<mark4>
./x4
<mark4>
make clean first maybe
<mark4>
requires nasm to build the kernel
<mark4>
ugh. with black on white i might need to adjust the colors used in "words" lol.
<mark4>
maybe it should not set colors
<mark4>
btw, im not getting that stack underflow crash
<mark4>
are you in a screen session in xterm?
<veltas>
"maybe it should not set colors" I think that it shouldn't be the default at least, to set colors on screen
<mark4>
with x64 i am even colorizing different word types
<veltas>
I'm not in a screen session, my TERM is xterm-256color probably
<mark4>
so variables and constants are different colors etc
<veltas>
Yeah I did make; ./extend
<mark4>
thats the new format of xterm and you would have crashed before yoou even got to the prompt if it was not fixed
<veltas>
I can try cleaning but I cloned your repo, I'm assuming the binary wasn't in the source repo?
<mark4>
it SHOULDNT be lol
<mark4>
that does not mean it is not in there :P
<mark4>
<-- nub
<mark4>
oh look! its JD:30 :)
<mark4>
like beer:30 but actually drinkable lol
<mark4>
p.s. im sitll here to help
<mark4>
not sure why you are seffaulting on stack underflow but we can track that down if you like
<veltas>
The address it segfaults at is 4013be
<mark4>
let me look at at
<veltas>
How is it mapped? Is it adding 400000 to the offsets in kernel.lst?
<mark4>
look at readelf -a on kernel.com
<veltas>
objdump -S is a bit more readable
<veltas>
kernel.o you mean?
<mark4>
it should be mapping at 8040xxx
<mark4>
no ./kernel not the .o
<mark4>
its called kernel.com as a joke lol
<mark4>
dos days lol
<mark4>
what distro do you use?
<veltas>
Arch Linux
<veltas>
I don't see 8040xxx anywhere in readelf -a kernel
<veltas>
I see 400000 though
<mark4>
Entry point address: 0x8049000
<veltas>
Entry point address here is 0x401000
<mark4>
aha. your binutils are giving you a different load address. that should not be a problem
<mark4>
(tm)
<mark4>
give me a min or 2 im going to track down that seffault address
<veltas>
Let me know how you find it so I can follow along at home
<mark4>
im using ida pro lol
<mark4>
but we might should do it on your machine give me a sec
<veltas>
I just use objdump -S and also you're generating that listing of the kernel
<mark4>
yea look at the kernel listing for that offset and see whats there
<mark4>
i looked at the live code and its mid opcode for me
<veltas>
So if it's 4013be the offset I should look at is 13be, or 3be?
<veltas>
Both 13be and 3be are not machine code for me
<mark4>
yea one is in number
<mark4>
run ./x4 and type 123 .
<mark4>
does it crash?
<mark4>
actually instead of drop try . and see if that crashes for you too
<mark4>
the crash could be non stack related
<veltas>
This is a segfault, it's crashing because it's trying to execute in the middle of sp_fetch
<veltas>
I dumped the memory and it matches what's at 0x3be
<mark4>
ok. the question is... WHY is it jumping to that address?
<veltas>
And the next step is for me to look at the stack and see where it's coming from
<veltas>
Tomorrow after sleeping :P
<mark4>
heh
<mark4>
where are you located?
<veltas>
Thanks for the help but yeah I need to go to bed
<veltas>
UK
<veltas>
It's 0:40 here
<mark4>
where in the UK? i grew up there
<veltas>
Leicestershire
<mark4>
cool. i lived in lancashire and in gloucestershire and in cambridgeshire
<veltas>
I will say before I sleep that your forth seems interesting and it's been encouraging so far
<mark4>
it has warts that i dont see because.. it works for me (tm) lol
<mark4>
we will fix it
<veltas>
I haven't had an opportunity to say anything nice about it yet because I built it so easily and immediately encountered bugs, which is a good thing in a way
<veltas>
I will try and help figure out this issue tomorrow
<veltas>
Please fix the colors lol
<veltas>
Okay nn
<mark4>
heh
<mark4>
night :)
dave0 has quit [Quit: dave's not here]
lispmacs has joined #forth
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
f-a has quit [Quit: leaving]
Zarutian_HTC has quit [Remote host closed the connection]
<siraben>
lispmacs[work]: ok thanks I'll look into it
gravicappa has joined #forth
sts-q has quit [Ping timeout: 265 seconds]
dave0 has joined #forth
sts-q has joined #forth
javery has joined #forth
dave0 has quit [Quit: dave's not here]
<siraben>
Is there a recommended text on a rigorous treatment of floating point numbers, error bounds and so on?
<siraben>
I suppose that would be best done in a numerical analysis textbook
<siraben>
"What Every Computer Scientist Should Know About Floating Point Arithmetic" https://cr.yp.to/2005-590/goldberg.pdf is nice in that they prove their bounds and theorems
<veltas>
That comment confused me for a sec, it sounds like it's saying the macro can do both return and parameter stacks
<veltas>
mark4: Why does x64 use R14 and R15 for stack pointers? Why not RSP or RBP?
<veltas>
You can use RSP for CALL'ing stuff and still use as parameter or return stack, unless there's some reason you can't on 64-bit
<veltas>
I see now you are using RSP as your IP, who am I to judge?
<veltas>
My single 'drop' causes a segfault because you run SP@ which pushes TOS to (SP), which is at 0x7ffff7ff9008
<veltas>
So I'm assuming your parameter stack area ends at 0x7ffff7ff9000?
<veltas>
And I'm assuming the layout on your system just happens to not cause a segfault. If you want it to work reliably you probably need to add padding to the stack to avoid immediate burnination
<veltas>
Hmmm your stack starts at end-CELL so that's not it
cartwright has quit [Remote host closed the connection]
cartwright has joined #forth
clog has joined #forth
<veltas>
SP@ gives you the value of the stack top after pushing TOS to it, and it gives ...FFF8 for me. Therefore when the stack is empty at interpreter SP is ...0000 i.e. not STKSZ-CELL
<veltas>
Changing start to STKSZ-2*CELL now I don't segfault and empty stack SP is ...0008, I think there's an off-by-one in your ABORT
<veltas>
mark4: QUIT isn't meant to reset the parameter stack, ABORT is supposed to do that before calling QUIT.
<veltas>
And I found the bug, you run SP0 SP!, but SP! (correctly, for cases where you're not resetting) pops the top of the new stack pointer into TOS
<veltas>
So either SP! needs to store n-CELL before popping, or you need to run SP0 CELL - SP!
<veltas>
In my forth SP! just sets SP and TOS becomes nonsense, so you can only reset the stack with it, so I don't have this bug
<veltas>
Because my ABORT code just does S0 SP!
_whitelogger has joined #forth
<veltas>
siraben: Why do you want that kind of info, out of interest?
<siraben>
veltas: well I'm studying analysis and topology at the moment and like the rigor, and wanted to see how similar techniques could be done for floating-point
<siraben>
which is of great importance because fixed point severely restricts the range
<veltas>
Oh okay cool
<siraben>
more excuse for some assembly or C programming too, heh
<veltas>
Well people complain about floating point numbers being illogical, but they would never allow the banach tarski paradox
<veltas>
So maybe they're better than multidim real spaces?
<veltas>
I think "the axiom of choice" is ironically named
<siraben>
well Banach-Tarski follows from AOC
<siraben>
yeah it's a pretty weird axiom especially for constructivisrs
<siraben>
constructivists*
<siraben>
veltas: which parts of floating seem illogical to people? Maybe predicting error propagation/losing the nice ring property of R are some examples
<siraben>
a+(b+c) does not necessarily equal (a+b)+c in IEEE floating point
<veltas>
Just stuff like that yeah
<veltas>
The issue is just that people don't know anything about floating point, and then when it doesn't do what they want the first time they go complain
<veltas>
siraben: What topics are you on right now in analysis/topology?
dave0 has joined #forth
<siraben>
veltas: the topology I'm learning is for differential geometry, so just enough of it (went from open sets to Heine-Borel and countable bases in a few weeks), now we're on manifolds
<siraben>
for analysis, the usual, so Cauchy completion of Q gives R, Bolonzo-Weierstrauss, limits and continuity so far
<siraben>
many of the results if course would not hold in FP because you can't just take an arbitrarily small epsilon neighborhood :(
<siraben>
perhaps I shouldn't be too concerned because that's all the subject of numerical analysis
<veltas>
I never really followed the rabbit hole but there is supposedly an alternative approach that doesn't use axiom of choice
<veltas>
It's a bit like the alternative approach of Forth compared to other languages, so seems like it might appeal to you
<siraben>
Why does AOC need to be used? Haven't gotten to that part yet.
<veltas>
You have if you've got R, I don't think you can define R without it, or at least the 'easy' definition uses it
<veltas>
It's not given a huge amount of attention because you don't want to trip up your analysis students right when they're about to start using what was just assumed in high school
<siraben>
Interesting, and I thought we know all we needed to know about R because of the completeness property
<veltas>
The completeness property is sort of the definition of R, and the assumption that R exists based on the definition assumes AOC
<veltas>
....I think
<veltas>
Go ask in #math, I haven't done maths in years so there's probably more nuance somewhere
<siraben>
Ok I'll look out for it. Did you study mathematics in university?
<veltas>
When you are thinking about AOC at all you are going slightly more rigorous than you tend to in analysis and going to the level of axiomatic set theory
<veltas>
Yes I did but dropped out / changed course after years of poor health
<veltas>
siraben: Let me try, consider the class of "sequences in Q that converge", not necessarily to a number in Q, and we can define an equivalence relation for sequences that converge to each other (i.e. eventually get within epsilion of other sequence). To get an equivalence class from that (which is R, with different labels) you need AOC.
<veltas>
I don't know if that whole message sent
<veltas>
By even talking about that first class I might have already assumed AOC... okay enough maths back to forth
<siraben>
veltas: Oh I see that makes sense. You don't have actual equality if the Cauchy sequences so need to define an equivalence relation, which is probably where AOC comes in
<siraben>
Yeah would be too low level details for an analysis class
<siraben>
s/if/of/
<veltas>
When we did real numbers at uni, it was in the first couple weeks and we spent almost no time on it
X-Scale` has joined #forth
X-Scale has quit [Ping timeout: 256 seconds]
X-Scale` is now known as X-Scale
<proteusguy>
Wanna do something interesting in math/computers and get rid of that abomination called floating point? Switch to posits! :-)
X-Scale` has joined #forth
X-Scale has quit [Ping timeout: 276 seconds]
X-Scale` is now known as X-Scale
<veltas>
proteusguy: Some interesting reading in there I'm sure but I happen to think floats and fixed are fine
<veltas>
Well I know there is interesting reading because I started reading about them
<veltas>
Why does everyone always refer to floats as "IEEE floating point", the concept is larger than the standard and doesn't usually depart from what everyone knows or is talking about
<proteusguy>
veltas, floats are evil - always have been. the whole history of how it came to be shows what an awful design by committee standard it was. It's basically the space shuttle. Set computation back 40 years. Posits is SpaceX. ;-)
<proteusguy>
veltas, are you aware of any implementations of floats that don't have negative & postive zero? How many versions of NaN do they cause? How many can represent 0.1 well?
<siraben>
proteusguy: what's good about posits? do you know of texts that have a rigorous treatment of them?
<siraben>
Representing 0.1 exactly seems irrelevant since no matter the choice of base, "nice" decimals would more often than not line up with the exponent/mantissa representation
<siraben>
hmm hard for me to judge the pros/cons of posits compared to IEEE without having read up on numerical analysis, perhaps good for later
<siraben>
TIL in machine learning model it's common to degrade floating-point precision to 16 bits because it halves the model size, with not much of an impact on gradients
dave0 has quit [Quit: dave's not here]
<proteusguy>
siraben, I don't have those bookmarks handy as I reset this machine. There are some excellent YouTube videos by the inventor that should be easy to find. Really impressive stuff when dealing with computations that don't need to be precise but need to have a known good accuracy.
<proteusguy>
We just need hardware to start implementing them as alternatives to floats so we can consign floats to the wastebin of compu-history.
f-a has quit [Remote host closed the connection]
f-a has joined #forth
<mark4>
veltas good finds!
<mark4>
i seem to recall that proteusguy might be a math wizz :)
<veltas>
siraben: Yeah 16-bit floating point is surprisingly good, the caveats just come in faster and harsher
<veltas>
Well then he can tell me if I'm right about the R AOC thing
<mark4>
just woke up. went to bed at 1:30 but did not get to sleep till past 4am grrr
<proteusguy>
mark4, nah - just a hard core eliminator of complexity whenever possible forth-wright doing what us forthers have been doing since 1968 - exposing the nonsense of what pretends to be proper computer engineering & architecture! ;-)
<mark4>
going to make coffee - we can push those bug fixes to github :)
<proteusguy>
siraben, (aka smart ben) is a stronger math whiz than me.
<veltas>
mark4: If you can't tell from the fact that I found the bug, your code is very good. I would have no hope if it was an unmaintainable mess
<proteusguy>
As I'm certain veltas is as well.
<veltas>
I just know some stuff
<mark4>
proteusguy: i have said for a long time that the best solution to any given problem is the simplest solution to it - the real problem is finding that simplest solution and the industry has abandoned that
<mark4>
veltas: if you cant understand my code how the heck am i going to be able to understand it later :)
<proteusguy>
+1 (not good for business)
<mark4>
i always write my code to be readable as best i can
<mark4>
not that the memory manager or the terminfo code is trivial to understand overall lol
<veltas>
The bits I had to look at to fix the bug were all fine
<mark4>
and the tui code is currently b0rken lol
<veltas>
Yeah I think I'd prefer it if all the graphical stuff was optional
<mark4>
OOOOOH!!!! your crash was because of my not doign sp! correctly?
<veltas>
Is it fixed on your computer or something? :P
<mark4>
no ive not changed anything here yet
<mark4>
need to get coffee first :)
<mark4>
but i was not experiencing that crash
<veltas>
I've got the master branch from github
<mark4>
"it works on my machine (tm)" is not a good attitude tho :)
<veltas>
Well segfaults aren't guaranteed, it could be my system just chooses to make pages more granular
<veltas>
They also appear to be random
<mark4>
do you want to get rid of the status bar and have a simpler "hello" option?
<mark4>
we can do that... after coffee hehe brb
<veltas>
Yeah that would be my preference
<veltas>
My Forth just starts and says "HI"
<veltas>
It's not obvious to me what the fix should be, either change SP! to subtract a cell first or change the stack reset code to do SP0 CELL - SP!
<veltas>
I think it will depend on which part you think deserves to be more generic / simpler
inode has joined #forth
<mark4>
well, the status bar depends on the terminfo parsing
<mark4>
same as the hello message currently does
<mark4>
a more generic hello can be done easilly.
<mark4>
if you dont want any of the terminfo stuff included you can create a stripped down version of src/x4.f <-- extend load file!!!
<mark4>
if you look at ./extend it pipes src/x4.f to kernel.com
<mark4>
you can strip out anything you dont want to use.
<f-a>
if you have a new machine
<f-a>
and you need to port forth there
<f-a>
what is your most likely choice?
<f-a>
roll it up yourself from assembly?
<f-a>
some kind of cross compilation?
<mark4>
both i would say
<f-a>
a well known™ forth whom you can twe- I see
<mark4>
leverage the power of forth on an existing machine to create an assembler for the new machine
<mark4>
then use the existing machine to cross compile for the new one
<f-a>
mhhh
<mark4>
for example i have been writing an ESP32 assembler
<mark4>
its mostly complete, just need to pull my head out and write the branch resolution lol
<mark4>
veltas where exactly did you change?
<mark4>
you think sp! should not pop bx? that would leave what ever was at top of stack prior to the change still in top of stack
<mark4>
that actually seems more correct to me
<veltas>
mark4: No that's not what I've said at any point :P
<mark4>
what was your fix lol
<veltas>
I personally think SP! is correct, do SP0 CELL - SP! instead of SP0 SP! in QUIT (which should really be in ABORT)
<mark4>
quit should leave the stack unchanged and abort should reset the stack?
<mark4>
something in the back of my wrinkly brain thinks that sounds right lol
<veltas>
QUIT should reset return stack and run interpreter, ABORT should reset parameter stack and then QUIT
<veltas>
I believe that's how fig-forth does it, I can check if you want
<mark4>
i think you are right
<veltas>
I'm assuming that's more authoritative to you than the standard?
<mark4>
"the" standard?
<mark4>
lol
<mark4>
i tend to follow the 83 standard more closely - but the way ANS does it might not be objectionable to me either
<mark4>
my objection to ANS is that they are taking a simple thing and making it more complificated than it needs to be
<mark4>
i loathe and despise both "invert" and "postpone"
<veltas>
You don't have to explain to me, I am not a huge fan of the standards
<mark4>
for example
<mark4>
im 100% compliant with the x4 standard :)
<mark4>
and its perfectly fine for that to be a moving goalpost
<mark4>
ok. so back to the bug. sp0 cell- sp! ?
<mark4>
i moved at line into abort too
<mark4>
i made that change and thats possibly uncovered some more bugs
<mark4>
when i run ./x4 the status bar shows 3 items on the stack :)
<veltas>
I didn't fix it on mine, I got it to not segfault by moving S0 further in, that's how I realised it was some kind of off-by-one
<veltas>
You will probably need to change depth too
<veltas>
I mean the word DEPTH
<mark4>
i know :)
<mark4>
i know what you meant
<mark4>
but the items on the stack are -1 an f7f4xxxx address (possibly related to environment) and a 1
<mark4>
yea the environment is at fffd4b38c when i run it so the f7f8xxxx is not env
<mark4>
i added a cell- to depth and now theres only 2 items on the stack when i run it heh
<mark4>
sp@ sp0 cell- - or sp@ cell- sp0 - ?
<veltas>
I just put 1- at the end
<mark4>
ya that seems simpler
<mark4>
but its tribal knowledge why that -1 is there now lol
<mark4>
when you run do you have a dpeth of 2 ?
<mark4>
k think something is legitimately leaving shmoo on the stack
<mark4>
somewhere
<mark4>
i mean... not legitimately :)
<veltas>
Not for me, it's 0 now
<mark4>
did you remove any of the terminfo stuff yet?
<f-a>
-ChanServ(ChanServ@services.)- End of #forth FLAGS listing.
<f-a>
sorry for megaping
<proteusguy>
wow what happened? and hard to believe it's been over 6 years since I was made...
jess has joined #forth
<mark4>
were about to possibly get a channel name change to ##forth
<mark4>
which i objected to prior to loki dieing
<mark4>
i won that arguement with him but im not going to be pissy about it now lol
<f-a>
I think it is *required* as now
<f-a>
among other stuff — i.e. we had to change #haskell.it to #haskell-it
<f-a>
but only when freenode staff remember it xD
<mark4>
it was a requirement back then too but chuck moore gave his ok on this being the official irc forth channel
<f-a>
oh
<f-a>
then maybe it *is* part of an organisation
<f-a>
and not «general forth talk»
<f-a>
ok, I received a reply
<f-a>
.
<f-a>
For such older hardware, you need to port an assembler and the primitives
<f-a>
(which is exactly what Klaus Kohl-Schöpe did for the 8086).
<f-a>
.
<f-a>
what does he mean with «port an assembler»?
<mark4>
ok were staying as #forth :P
<mark4>
but the owner is going to be placeholder forever
<mark4>
no biggie
<f-a>
I suspect you could poke freenode staff to get your credentials back
<mark4>
ok so i registered this channel with the nick I440r almost 20 years ago
<mark4>
i have not used that nick in a long time
<mark4>
so when I440r got deregistered due to inactivity this channel ownership dropped to the placeholder owner
<mark4>
so now NOBODy owns this channel lol
<mark4>
and im somehow not an oper either lol
<f-a>
yeah, #freenode staff can help, as I have been teeling you :P
<mark4>
the only way to get #forth off placeholder is to have chuck moore come in and register it as the official forth irc chhanel officially or something lol
<mark4>
i am in #freenode lol
<mark4>
i have been talking to them as soon as i saw i was no longer the owner lol
<f-a>
:P sorry
<f-a>
grab the attention of an op there and — well I hope you have your old mail accessible — you should be back on track in no time
<mark4>
no
<f-a>
well :P
<f-a>
that *might* be a problem
<mark4>
i might email CM and ask him if he would like to register it back in his name
<mark4>
i have no objections to CM being "THE" owner :)
<mark4>
else it can stay on placeholder :)
<f-a>
they have to get hold of some active — active here — OPs etc.
<mark4>
and any oper in here can +o me any time lol
<mark4>
and the fact that i did not know i cant +o myself shows how long its been since i have done so lol
<mark4>
not some. ALl
<mark4>
they said they could register ##forth to me and some oper here can redirect #forth to ##forth.
<mark4>
meh
<mark4>
keep this channel
<f-a>
I wouldn’t be against — not that anyone cares — to a move to ##forth
<f-a>
but we would need a functioning redirect
proteus-guy has quit [Ping timeout: 265 seconds]
<mark4>
im emailing chuck moore and asking if he would like to come by and take ownership :)
<mark4>
and if he would like to come and visit us again
<mark4>
i dont remember if any of the current regulars were here when CM came by last time
<mark4>
maybe crc?
<f-a>
let’s pull a stunt and retheme this to a Rust channel
proteus-guy has joined #forth
<crc>
I think that was just before I started here
<mark4>
well i just sent CM an invite - he is not one for idling on irc tho :)
<mark4>
ugh. the email bounced lol
<mark4>
his web site needs updating
<mark4>
he didnt die yet did he?
<mark4>
Your message couldn't be delivered to chipchuck@colorforth.com because the remote server is misconfigured. See technical details below for more information.
<crc>
Hmm, my #retro is also a placeholder account holder; I might want to address that at aome point
<crc>
He's not doing much online now, but still alive as of a few months ago
<proteusguy>
i don't have Facebook any more so can't check.
<mark4>
when facebook blocks you from viewing one of their accounts you can actually ADBLOCK their block and see the account :p
<mark4>
the page says that facebook UNLAWFULLY registered their companies page and the only way they can take ownership of it is to have one of their employees create a PERSONAL account
<mark4>
and i agree with we are legit, chuck moore gave us his blessing to be #forth
<mark4>
but because i have not used i440r in a long time the registration dropped
<mark4>
so im no longer associated with this channel at all lol
<mark4>
not the owner, not even an oper lol
<mark4>
but its still mine k. just sayin :P
<mark4>
gontacted greenarrays. not sure if cm is still associated but maybe they know how to contact him :)
<mark4>
tho...probably not on sunday :)
<mark4>
cm is still listed on the board of directors so...
gravicappa has quit [Ping timeout: 245 seconds]
<mark4>
! they replied and gave me an active email address for him :)
<mark4>
crc there?
<mark4>
or proteusguy ?
<mark4>
if i promise not to abuse it can i haz +o plzkthxbai? :)
<crc>
Done :)
f-a has quit [Read error: Connection reset by peer]
f-a has joined #forth
<mark4>
veltas: omg were you running x64 or x4? i just looked at the liner script for x64 and it DOES specirfy a load address of . = 0x401000;
<mark4>
x4 has a different load address
<mark4>
AND... in x64 when i type "drop" it segfaults :)
<mark4>
lol ty :)
<mark4>
was going to add "do drop >in" to the topic and discovered i cant! lol
<eli_oat>
yeah, gbforth is what I've been poking at so far
<eli_oat>
as a total forth noob, there are a bits of it that still feel a bit more like ASM at the moment -- so, head swimming
<eli_oat>
BUT, I am enjoying it :P
<f-a>
hehe no worries
<crc>
Foucist was active here and in #retro ~6-8 years ago
<eli_oat>
with only v limited time to devote to it, though, and wanting to actually make something more than a hello world, I'm thinking gbforth probs isn't the best go-to focus right now
<f-a>
yeah
<f-a>
they actually have examples
<eli_oat>
the ones in the repo are where I've started
<crc>
IIRC, he doesn't use Forth much since then; was using Ruby for a while, not sure about currently
<f-a>
crc: try to see if you can get +f from them then
<f-a>
it is unwise not to have active fs
<crc>
f-a: I'll see if I still have his email address from back then
<mark4>
eli_oat: x4 has full cursor control in terminals, you could write a rogue like game there :)
<mark4>
tho... the TUI code is kind of broken and needs fixing :/
<eli_oat>
that adds to the fun!
<mark4>
eli_oat: if you dont use the TUI all the cursor control stuff works just fine
<mark4>
ill be adding gray scales and full RGB color control soon
<mark4>
download, do a make (needs nasm) then ./extend
<mark4>
as a test and to show cursor control in action run
<eli_oat>
sick! easy peasy
<nihilazo>
I'm interested in retroforth
<nihilazo>
maybe I should join #retro and hang out there too
<nihilazo>
although looking at retro code confuses me (tbh looking at forth code confuses me in general still)
<eli_oat>
I've been lurking in both crc is wicked helpful, and retro's docks are next level
<mark4>
./x4 -f src/examples/dots/wmdots.f
<mark4>
then type "main enter" without the quotes :)
<mark4>
make your terminal as big as it can go.
<mark4>
that demo will be wicked once i get rgb or gray scales implemented in terminals :)
<eli_oat>
hmm, doesn't seem to play nice with my weird virtualized debian enviroment, but I have another vanilla debian box I can try it on this evening
<eli_oat>
I'm excited to check this out!
<eli_oat>
I've spent less time writing forth, and waaay more time exploring various implementations of it :P
<nihilazo>
oh TIL retro runs on a VM, that's cool
* nihilazo
knows nothing about different forths
<eli_oat>
thanks for the recommendations f-a and mark4! I've gotta bounce but will defo be back
eli_oat has quit [Quit: WeeChat 2.3]
<crc>
I lurk here and in #retro and will try to answer questions on retroforth (or other systems where I can) pretty quickly, though the speed will vary depending on real-world busyness
<mark4>
or sleep mode :)
<crc>
Sleep is just ~4 hours of the day at best
<f-a>
I could never do it
Zarutian_HTC has joined #forth
<mark4>
how come only 4 hours?
<crc>
I don't sleep well
<veltas>
mark4: Oh right so I guess this is the official #x4 channel then :P
<veltas>
mark4: I'm using x64
<veltas>
mark4: "x4 has full cursor control in terminals, you could write a rogue like" that's of interest to me
<veltas>
Separate interest to regular use though
<f-a>
nice to know people like roguelikes
inode has quit [Quit: ]
_whitelogger has joined #forth
<mark4>
yea i meant hit the enter key :)
<veltas>
Does it just go over the 16MB or however much memory you have for dictionary?
<mark4>
its allocated separately
<mark4>
using the memory allocator i wrote
<veltas>
lol
<veltas>
It segfaults when I leave it for a bit
<veltas>
The good forths are the ones that capture my interest and imagination, and also segfault on a regular basis
<veltas>
Like the colorforth presentations by CM
<mark4>
those seffaults did not used to happen at all - but x64 is still in its infancy compared to x4 and many of the examples dont run right in it yet
<veltas>
I'm running it in gdb right now
<veltas>
Yes I know x64 is experimental :P
<mark4>
x4 does not segfault that i can tell
<veltas>
Can anyone get me into the exclusive ForthHub group?
<mark4>
what i really need to do is go through every single primitive in x64 and compare it with the one in x4 and verify i did the translation correctly
<veltas>
Nah I think just use it and keep debugging
<veltas>
Do you have a test suite?
<veltas>
Probably most of it is correct
<veltas>
mark4: If I have an address in a word, how can I find out what word it is (if it's in extended part)?
<veltas>
RIght now I am looking at WORDS assuming they're in order and doing a binary search with '
<mark4>
ooh that would be an interesting debug word to write :)
<veltas>
for the address
<veltas>
Yes I think that would be a useful word
<mark4>
if you look at the structure of my words i have a header in head space
<veltas>
I suppose it would just go backwards through the list until it's less than the address and then name the previous word
<mark4>
that points to the CFA and one cell lower down in memory from the CFA is a pointer back to the NFA
<mark4>
thats so i can do name> and >name easily
<mark4>
well. with a slight modification to the macros in src/kernel and to (head,) you COULD add a marker cell so it could be something like
<veltas>
Yeah admittedly a hexdump would make this easier, most of my debug tools are geared towards well structured C output
<veltas>
A hexdump with an ASCII preview I mean
<mark4>
0xaa55aa55 followed by the NFA pointer followed by the CFA
<veltas>
Like flash :P
<mark4>
so if you are at an address above cfa scan back in memory to the maker. the next cell up points to the nFA
<mark4>
understand
<mark4>
?
<mark4>
it would increase the size of the code by one cell for every word defined
<veltas>
I think I understand
<mark4>
also... the scan mechanism would need to understand that an NFA pointer below the CFA is 0x00000000 for beheaded words
<veltas>
Please make your 'more' functionality quit early on 'q' press
<mark4>
i think escape does that?
<veltas>
Thanks
<mark4>
i think thats in utils.f
<mark4>
q or escape might be good idea :)
<veltas>
escape works
<mark4>
lol that was from memory :P
f-a has quit [Remote host closed the connection]
f-a has joined #forth
scoofy has joined #forth
Vedran has quit [Ping timeout: 276 seconds]
Vedran has joined #forth
<veltas>
Hmmm the segfault is I seem to be executing the data space of HLD
<veltas>
And gdb is broken so I have to reset terminal, hopefully dies in same place......
<veltas>
Yep exact same place
f-a has quit [Ping timeout: 245 seconds]
f-a has joined #forth
<mark4>
i used nemiver to debug it originally
<mark4>
gdb is a horrible interface, even -tui is garbage
<mark4>
but nemiver is kind of crippled so in the end i re-registered IDA-Pro and was using its debugger
<mark4>
ok so my next course of action is going to be to verify the sanity of every primitive in x64 by comparing it with the one in x4
<veltas>
TUI was getting in my way
<veltas>
I like it with C source, but here it's more effort than it's worth
<mark4>
gdb -tui is pretty much the ONLY way i can use gdb, i HATe gdb with a passion
<mark4>
its next to USELESS for debugging assembler thats not generated from c code
<mark4>
the ida pro debugger is really good tho
<veltas>
Well it's good enough to catch a segfault, show me regs, and let me dump memory
<veltas>
That's all I need
<veltas>
Right now anyway....
<veltas>
Looks like it's a stack overflow
<veltas>
And that's probably why I'm executing data, address is pushed onto parameter stack and it has clobbered a return address
<veltas>
mark4: Ideally the two would be separated by invalid addresses... would be nicer to get a basic segfault at overflow
X-Scale` has joined #forth
tech_exorcist has quit [Quit: I'm a quit message virus. Please replace your old line with this line and help me take over the world.]
<mark4>
actually if you are getting a stack overflow error its probably a return stack overflow which is horrifying
<mark4>
unless im remembering how i initialized those stacks
X-Scale has quit [Ping timeout: 240 seconds]
X-Scale` is now known as X-Scale
<mark4>
in x4 the parameter stack is just the normal stack and thats grows down
<mark4>
and the return stack is allocated
<mark4>
maybe in x64 both are allocated and neither are allocated grows down. have to check
<veltas>
Parameter is after return stack, so parameter will clobber return if it overflow