lispmacs has quit [Ping timeout: 246 seconds]
X-Scale` has joined #forth
X-Scale has quit [Ping timeout: 265 seconds]
X-Scale` is now known as X-Scale
<joe9> use plan9port?
X-Scale has quit [Ping timeout: 260 seconds]
X-Scale` has joined #forth
X-Scale` is now known as X-Scale
dave0 has joined #forth
<veltas> LEAVE is a bit too magic for my taste
<veltas> The fig-forth LEAVE is much better IMO
<veltas> (just set iterator to limit, so the next LOOP/+LOOP falls through)
<crc> joe9: still needs X11, which I don't have on my systems
<crc> none of this matters though; I'm writing an editor for my own use, which will suffice and be written in Forth
* crc intends to be done this by early summer
<veltas> The nicest approach I can think of has a runtime cost and slight overhead for DO
<veltas> i.e. add the leave address next to iterator/limit on return stack
<veltas> Alternative is to have some kind of loop or leave stack, potentially link multiple LEAVE's through code to resolve at corresponding LOOP, which is all gross
<veltas> fig-forth had the right idea with a LEAVE that requires a bit more care in use, but is infinitely simpler in implementation. That's the forth way really
<MrMobius> the way I implemented it is a separate stack for structures at compile time. every LEAVE pushes it's address and type then LOOP pops repeatedly until it finds a an address of type DO. update all the addresses for the LEAVEs and error if another type like IF is found
<MrMobius> doesnt seem to be a common way to do it though
<MrMobius> I suppose you could have some valid reason to do DO FOO IF LOOP THEN BAR LOOP
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
f-a has quit [Ping timeout: 272 seconds]
f-a has joined #forth
dave0 has quit [Quit: dave's not here]
Zarutian_HTC1 has joined #forth
Zarutian_HTC has quit [Read error: Connection reset by peer]
f-a has quit [Quit: leaving]
_whitelogger has joined #forth
Zarutian_HTC1 has quit [Ping timeout: 240 seconds]
Zarutian_HTC has joined #forth
gravicappa has joined #forth
jedb_ has joined #forth
sts-q has quit [Ping timeout: 260 seconds]
jedb__ has quit [Ping timeout: 264 seconds]
jedb__ has joined #forth
jedb_ has quit [Ping timeout: 256 seconds]
sts-q has joined #forth
dave0 has joined #forth
wineroots has quit [Remote host closed the connection]
_whitelogger has joined #forth
Zarutian_HTC has quit [Remote host closed the connection]
wineroots has joined #forth
<veltas> MrMobius: There is a valid reason but there are workarounds (assuming middle LOOP was meant to be LEAVE)
<veltas> Like just wrap end part in an IF..THEN, or use BEGIN..WHILE..REPEAT etc instead
<veltas> Yeah a LEAVE stack is a way I considered, it would have to be pretty much what you said, I can't think of another way. I have opted for three items on the return stack because it seems like the simplest overall solution
<veltas> ANd the overhead is minimal and doesn't affect the amortised loop overhead (apart from using 2 bytes more return stack, and 1 byte more with plain DO)
dave0 has quit [Quit: dave's not here]
jedb__ is now known as jedb
iyzsong has quit [Quit: ZNC 1.7.5 -]
iyzsong has joined #forth
yunfan has quit [Quit: WeeChat 2.9]
yunfan has joined #forth
<MrMobius> veltas i did mean LOOP twice there
f-a has joined #forth
sts-q has quit [Quit: ]
sts-q has joined #forth
sts-q has quit [Client Quit]
sts-q has joined #forth
<veltas> Oh okay I don't understand then
elioat has joined #forth
f-a is now known as f-menagr-a-mo
<f-menagr-a-mo> what VCS do forth people use, if any?
<f-menagr-a-mo> (don’t know if I have already asked)
<proteusguy> VCS?
<nihilazo> version control system
<f-menagr-a-mo> version control system proteusguy, something like git yeah
<nihilazo> I use git but I hate it
<nihilazo> it's just the most commonly supported and therefore the de facto default
<f-menagr-a-mo> I see
f-menagr-a-mo is now known as f-a
<nihilazo> I'm interested in fossil, because I have some friends who have started using it and prefer it over git
<f-a> I use darcs, but only for personal projects
<nihilazo> I might move a project I'm working on rn into fossil
<nihilazo> just...because
<nihilazo> to check it out
<nihilazo> sadly I dont' have a server to host public fossil projects on
<joe9> not mercurial?
<nihilazo> mercurial doesn't seem all that different to git to me? Honestly idk stuff about VCSs
<nihilazo> I also don't have mercurial hosting
<nihilazo> (rn I host my stuff on tildegit, which is a gitea instance)
<nihilazo> srht exists and is good I guess but also paid
elioat has quit [Quit: elioat]
<patrickg> has fossil hosting
<nihilazo> cool
_whitelogger has joined #forth
<nihilazo> I am interested in fossil but idk really about how much I gain from moving to fossil, it just seems to be simpler than git while also integrating the stuff that is currently messy with git (like issues over multiple hosts, etc)
f-a has quit [Ping timeout: 265 seconds]
f-a has joined #forth
<veltas> f-a: git or just .tar.gz snapshots
<veltas> My VCS requirements are extremely basic personally, I use perforce and git at work and I prefer git there.
<f-a> there is a forth ×-compiler for gb, apparently
<f-a> I *might* make something
<veltas> Go for it, only way to learn it properly really
<nihilazo> there is a forth for the gameboy
<f-a> nihilazo: a forth *interpreter*?
<f-a> I am using
<f-a> but has some annoying limitations
<f-a> (no `create` at runtime etc.)
<nihilazo> oh yeah, that's gbforth
<nihilazo> it's the only one I know
gravicappa has quit [Ping timeout: 260 seconds]
gravicappa has joined #forth
<veltas> With 8KB RAM, and assumption that any game will have essentially all code in ROM, and no keyboard, it is not surprising to me nobody has made a full interpreter forth for gameboy
<veltas> As far as I know anyway
<nihilazo> yeah, a full interpreter doesn't make too much sense
<veltas> But there's no reason you can't make one, I think it would be quite a cool thing on a real gameboy if you had a way of writing the ROM
<nihilazo> a compiler is cool though
<nihilazo> you could put writable memory inside a cartridge
<nihilazo> that's what, eg. LSDJ does for song memory
<nihilazo> (and some games for saves, but it was surprisingly a little rare)
<veltas> Or you could just limit to the 8KB RAM, you could do a lot with that in a tokenised forth
<nihilazo> LSDJ has the main program in ROM but also has storage in the cartridge the user can write and read from
<nihilazo> so did pokemon games (although they used a battery-backed RAM which isn't a very robust solution)
<veltas> That is definitely the way to go, some kind of nv storage
<f-a> well you cannot use `create … does>`, which is a bit of a pity
<nihilazo> and a forth interpreter is likely to be running from a flash cartridge
<nihilazo> in which case you can use the insanely huge flash memories that those have lol
<veltas> Yes
<nihilazo> my EMS cartridge (which everybody agrees is pretty terrible, it's like the worst GB flashcard) has 32M storage
<nihilazo> which is insane for the gameboy
<nihilazo> some have even more, I think some of the bennvenn ones have multiple gb of storage
mjl has quit [Ping timeout: 272 seconds]
mjl has joined #forth
gravicappa has quit [Ping timeout: 256 seconds]
f-a_ has joined #forth
f-a has quit [Read error: Connection reset by peer]
f-a_ has quit [Quit: leaving]
f-a has joined #forth
f-a has quit [Ping timeout: 256 seconds]
f-a has joined #forth
dave0 has joined #forth
Keshl has quit [Ping timeout: 264 seconds]