mark4 changed the topic of #forth to: Forth Programming | do drop >in | logged by clog at http://bit.ly/91toWN backup at http://forthworks.com/forth/irc-logs/ | If you have two (or more) stacks and speak RPN then you're welcome here! | https://github.com/mark4th
rixard has quit [Read error: Connection reset by peer]
rixard has joined #forth
Keshl has quit [Read error: Connection reset by peer]
Keshl has joined #forth
<KipIngram> Oh, nice.
Zarutian_HTC has quit [Read error: Connection reset by peer]
Zarutian_HTC has joined #forth
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
jedb has quit [Quit: Leaving]
jedb has joined #forth
sts-q has quit [Ping timeout: 240 seconds]
sts-q has joined #forth
MrMobius has quit [Read error: Connection reset by peer]
MrMobius has joined #forth
gravicappa has joined #forth
Zarutian_HTC has quit [Ping timeout: 252 seconds]
dave0 has joined #forth
dave0 has quit [Quit: dave's not here]
Zarutian_HTC has joined #forth
jedb has quit [Ping timeout: 240 seconds]
jedb has joined #forth
mtsd has joined #forth
jn__ has quit [Ping timeout: 250 seconds]
<lispmacs> is there a really detailed guide-book on how to implement your own Forth?
<lispmacs> I've got the programmer's handbook which I suppose might be enough, but it doesn't really explain the best order to approach implementing things
<remexre> moving forth is the classic reference, if you haven't seen that
<remexre> though I think most of its performance advice is pretty out-of-date, if you care about branch prediction
<lispmacs> looks ancient, but at least the paperback is cheap
<cess11> jonesforth has a lot of detailed comments in its source, it's based on x86 assembly
<lispmacs> okay, thanks
gravicappa has quit [Ping timeout: 260 seconds]
<lispmacs> i was pondering coding my own AVR forth
<lispmacs> i really like FlashForth but unfortunately it depends on a proprietary compiler which goes against my ideals
<lispmacs> I think in theory it could be built with avr-gcc but I haven't been able to figure out how yet.
<lispmacs> up until recently it could only be assembled with the avrstudio assembler. The author recently rewrote it for microchip's XC8 compiler
<lispmacs> which I guess is a little better because XC8 is uses avr-gcc for some of the backend stuff
<lispmacs> i thought I would try amforth instead but amforth is also dependent on avrstudio assembler
andrei-n has joined #forth
<lispmacs> which leaves only AVR-forth, which can be built through the Arduino IDE, but hasn't been maintained for 7 years, and is missing a few nice features - like the ability to compile words
* lispmacs curtails rant
rpcope has quit [Ping timeout: 240 seconds]
rpcope has joined #forth
hosewiejacke has quit [Remote host closed the connection]
hosewiejacke has joined #forth
rixard has quit []
jess has joined #forth
<proteusguy> For AVR I would think you'd code that thing in asm wouldn't you? About as clean an asm as you can ask for.
jn__ has joined #forth
neuro_sys has joined #forth
jedb has quit [Quit: Leaving]
jedb has joined #forth
gravicappa has joined #forth
andrei-n has quit [Ping timeout: 268 seconds]
andrei-n has joined #forth
andrei-n has quit [Quit: Leaving]
tech_exorcist has joined #forth
<MrMobius> lispmacs, isnt there one called eforth too?
andrei-n has joined #forth
neuro_sys has quit [Ping timeout: 245 seconds]
xek_ has joined #forth
xek has quit [Ping timeout: 265 seconds]
tech_exorcist has quit [Quit: tech_exorcist]
tech_exorcist has joined #forth
<lispmacs> MrMobius: I hadn't heard of it, but looking now, it apears to be dependent also on AVR Studio 4
<lispmacs> proteusguy: I'm opened minded; I think it will be a question of whether or not I can find decent tutorials on how to write AVR ASM using avr-as or another libre-software assembler/toolchain. The tutorials I'm finding so far are all for Atmel Studio but maybe I can figure out how to map things over (...?)
rixard has joined #forth
<boru> If you've used as/gas before, you shouldn't need anything other than a programming manual for the microcontroller. I wouldn't waste my with "tutorials".
<boru> My time, rather.
<boru> For the AVR-specific parts of as(1), see `info as` -> Machine Dependencies -> AVR-Dependent
<boru> Naturally, you'll probably want to write your own linker script for the target, as well, whether you're using an emulator, a simulator or the real thing.
<boru> There is absolutely nothing tying you to atmel's awful toolchain.
<boru> It's a pretty bodgy ISA, so I wouldn't agree that it's "as clean an asm as you can ask for".
<lispmacs> I haven't used as/gas before, not counting once for about twenty minutes trying to learn x86 assembly
<lispmacs> I was just able to find the avr-libc-user-manual, which does have some limited information an direct assembly programming with avr-as
<boru> avr-as is just gas from binutils configured to be a cross assembler for avr.
<boru> So the documentation is the same.
<lispmacs> like I just said, there is an actual avr-libc users manual that gives actual code examples
<boru> Okay.
<lispmacs> it is all nice to say "just use the generic manual and tweak it for avr" unless I'm coming at this with zero gas experience
<lispmacs> and pretty much zero assembly experience
<lispmacs> not counting a few brief forays into trying to learn x86 assembly
<boru> Okay, it sounds like you know best yourself.
<lispmacs> I doubt that
<lispmacs> i guess I know what I don't know
<lispmacs> I can learn just about anything if I've got good enough reference documentation. not sure in this case
<lispmacs> this avr-libc users manual looks pretty detailed at a glance
neuro_sys has joined #forth
neuro_sys has quit [Changing host]
neuro_sys has joined #forth
Zarutian_HTC has quit [Remote host closed the connection]
neuro_sys has quit [Ping timeout: 250 seconds]
f-a has joined #forth
Zarutian_HTC has joined #forth
alexshendi has joined #forth
<alexshendi> Which Forth should I use for learning Forth on amd64 or aarch64 machines? I don't like gforth. ANS non conformance isn't an issue.
<alexshendi> Thanks in advance.
f-a has quit [Read error: Connection reset by peer]
<alexshendi> mark4th/x64?
f-a has joined #forth
<lispmacs[work]> alexshendi: do you have certain criteria in mind? What are you trying to avoid from gforth?
<alexshendi> 1. dependence on GCC extensions
<alexshendi> 2. IIRC gcc is needed for compilation
<crc> mark's x64 wouldn't be a bad target if you are using linux
<alexshendi> 3. too complicated
<alexshendi> @crc What would prevent it from running on *BSD? Direct syscalls?
<lispmacs[work]> there is jonesforth, if you don't need any features like an FFI and just want to learn
<crc> different system calls, memory layout
<lispmacs[work]> programmed in NASM I believe
<alexshendi> Ok, at least io.s uses SYSCALL.
<alexshendi> What's the opinion about pforth?
<alexshendi> jonesforth is 32bit IIRC?
<lispmacs[work]> alexshendi: correct
<lispmacs[work]> I've used jonesforth a little and some of the most obvious words are not implemented
<nihilazo> jonesforth is designed for tutorial use rather than writing stuff in
<alexshendi> @crc: Thanks, but it's extended with APL characters... šŸ˜‡
<crc> APL is useful...
<f-a> useful for what
<f-a> not snarky, curious
<nihilazo> golfing
<nihilazo> lol
<nihilazo> idk what else
<alexshendi> and there is ascii.f
f-a has quit [Read error: Connection reset by peer]
<crc> f-a: working on arrays of data
Zarutian_HTC has quit [Ping timeout: 252 seconds]
<crc> I haven't used pforth in years. It was somewhat buggy when I last used it, but seems to be receiving updates in recent years.
<nihilazo> I use pforth on plan9
<nihilazo> works OK for what I use it for although I haven't used it for anything at all large
f-a has joined #forth
<lispmacs[work]> wasn't there somebody around here working on a vm-style Forth?
<f-a> ah sorry I got dcs
<f-a> *dcā€™d
<crc> lispmacs[work]: what do you mean by vm-style?
<crc> f-a: apl is useful when working with arrays of data
<crc> it's hard to explain though :(
Zarutian_HTC has joined #forth
<lispmacs[work]> crc: somebody was designing a system sort of like the Java VM but for Forth
<crc> the able vm?
<lispmacs[work]> i don't think so, but that looks interesting
<crc> there are a lot of stack-based vm systems
f-a has left #forth [#forth]
<lispmacs[work]> crc: any with decent gfx support?
<lispmacs[work]> i had understood that javavm was not very congruous with the Forth paradigm
<lispmacs[work]> HolonJForth had to use Java datatypes instead of the usual Forth memory constructs
<crc> nothing substantial. uxn has a framebuffer, but no forth on it that I'm aware of. nga (my vm) only has some limited prototypes w/graphics support, r4vm (from r3da iirc) might have had graphics; some of his stuff did
<nihilazo> uxn is not a forth, but it is a fun stack thingy
<nihilazo> would recommend messing around with it if you want fun rather than practicality
<crc> I intend to explore graphics at some point, but haven't actually needed this so far
<nihilazo> uxn also changes every like...few days
<nihilazo> I feel like every day I check #uxn and the audio engine has been redesigned or some similar large change
ecraven- has joined #forth
ecraven has quit [Ping timeout: 276 seconds]
ecraven- is now known as ecraven
alexshendi has quit [Ping timeout: 260 seconds]
rpcope has quit [Ping timeout: 240 seconds]
rpcope has joined #forth
<KipIngram> :-) That would be frustrating to me, nihilazo.
<nihilazo> I find it fun
<nihilazo> I just don't like...build anything at all big with ux
<nihilazo> I just don't like...build anything at all big with uxn
<KipIngram> Well, that's good.
<nihilazo> my biggest uxn program is...700 bytes compiled? lol
<KipIngram> Fun is what life's all about.
<nihilazo> I just mess around with it and don't get too attached to anything in case it totally changes
<KipIngram> A buddy of mine asks me sometimes why I do all this work on Forth that I do. As in what's the purpose of it.
<KipIngram> I've gotten so I just say "Hobby" and leave it at that.
<KipIngram> I may use it for something someday. I hope so.
<KipIngram> But that's really not the point.
<KipIngram> It's mostly just the joy of creating something.
<nihilazo> yeah same here
<KipIngram> I don't create things at work anymore like I did back in the day.
<KipIngram> This is my creation outlet.
theseb has joined #forth
<mark4> so my text user interface example code now constructs its entire interface via JSON and it is working perfectly :)
<theseb> Say I'm intrigued by Forth...I wondered what are its main use cases today? Reason I ask is it appears to shine when resources are minimal but in today's world you typically have plenty of memory and other resources yes?
<mark4> still not tested any of the menu description code yet so thats next on the todo list and when i get it all working i plan to give width/height/x/y coordinates for windows as percentages of screen width/height
<theseb> I want to like it but I wonder if it is used much in a world of abundance
<mark4> maybe place windows relative to other widnows etc
<nihilazo> theseb: I use it for fun, I think it's used in some specialised applications
<nihilazo> but for like, desktop PC programming, it doesn't get used much. Aside from by folks who like it. Like us
<theseb> nihilazo: i know it is used for spacecraft....I can imagine cases you want to formally verify your system for safety reasons...perhaps in those cases Forth would be useful since it is so minimal?
<MrMobius> theseb, its not used much in industry if thats what you mean
<theseb> MrMobius: I'm wondering if need for formal verification will make Forth have a renaissance
<MrMobius> theseb, highly doubtful
<nihilazo> I think formal verification is easier in a language that has things like types
<nihilazo> forth has nothing to try and be safe
<nihilazo> but I don't really know, I just build hobby things
<KipIngram> nihilazo: A genneral goal I've had from time to time is to be able to do stuff in Forth like I do in Octave. Handle vectors and matrices and so on.
<nihilazo> I'm still just writing a crappy terminal game in it
<KipIngram> My way of contemplatinng that is to add another stack. Consulted only by the interpreter, it will maintain a "type value" for each item on the data stack.
<nihilazo> but learning forth has been cool and working with forth is fun (if frustrating at times. Had a bug I was stuck for two days on, turns out I was just using "bl" instead of "space" and it was causing all the problems)
<KipIngram> What would let me do is include type information in word searches, and find only words that worked properly with the items on the stack.
<KipIngram> So I could overload operators - for example, + with two ints on the stack would be different from + with two vectors.
<nihilazo> hmm
<nihilazo> idk honestly
<KipIngram> But it would be determined at compile time - at run time it would just be the one right + that was compiled.
<KipIngram> To do this, the dictionary has to provide info on how to update the type stack when a word executes.
<remexre> wrt formal verification, if you can define types as "a predicate on the value and the machine state that determines whether everything is 'ok'," you can get pretty far with just symbolic execution
<KipIngram> So, you'd find a word that took the right types based on what's on the stack now, execute it, and then modify the type stack as per the stack effect comment in the word you just executed.
<remexre> and your types are really just shorthand there
<KipIngram> That opens the possibility of a good bit of error protection.
<KipIngram> Suddenly you can watch out for overflow and underflow, and so on.
<remexre> this gets much less easy if you define vector as e.g. "something that was once returned from ALLOCATE-VECTOR"
<KipIngram> remexre: Yeah, I'm sure my thinking on this is all full of "real CS holes."
<KipIngram> This is the sort of thing my approach to would likely be kind of hacky.
<KipIngram> Anyway, the payoff would be that I could intersperse numbers and vectors and matrices and so on, and the system would always know what it needed to do.
<KipIngram> That makes sense.
<KipIngram> Words like ?dup present an immediate problem.
<KipIngram> Prior to executing it, you don't know what it's going to do.
<remexre> in the symbolic execution approach, not really
<MrMobius> KipIngram, no, ?dup is a COMPILE problem not an IMMEDIATE problem
<remexre> well, in most approaches, not really
<remexre> you just have two subproofs now, one for if the TOS was zero, one for if it was nonzero
<KipIngram> I imagined dealing with it manually - where necessary the programmer (me) would inject a stack effect comment to define the current state of the stack.
<remexre> yeah, that's approximately the frama-c approach
<KipIngram> Anywhere the compiler got confused.
<KipIngram> Anyway, I've never built it, so I have no idea if it would really hold together.
<remexre> which because C allows similar sorts of nonsense with pointers, has similar "hard problems"
<KipIngram> I never imagined making a base system work that way. I always thought of it as a "replacement interpreter loop" that would be tantamount to my Octave ap.
<KipIngram> app
<KipIngram> Run it when I needed it, and then exit.
<KipIngram> nihilazo: But you're right - the absence of any sort of info like that in a typical Forth system leaves one with precious little error checking to do.
<KipIngram> Forth more or less says "if you tell me I can run that word at that time, I trust you."
<KipIngram> And it will then charge right off of a cliff for you if you gave it one to charge off of.
<KipIngram> With great power comes great responsibility...
<KipIngram> I've got a pretty good layer of system protection whenever I can actually *recognize* an error has occurred.
<KipIngram> One thing I've wished I could do is catch the exceptions that occur when I access a bad memory location or something like that, and just pass that back through my error recovery. Instead of just segfaulting.
<KipIngram> I've never bothered to learn how yet, though.
<KipIngram> If it's even possible.
<remexre> are you on Unix?
<KipIngram> MacOS. It's BSD, mostly I think.
<remexre> hm, if it passes a ucontext to a signal handler, you can twiddle that
<KipIngram> The error recovery isn't PERFECT - it involves restoring a copy of the system I made prior to beginning interpretation of the line. It's always possible that my error corrupted the image.
<KipIngram> Just unlikely.
<remexre> e..g on SIGSEGV, you can push the instruction pointer to the data stack, then jump to a non-signal-based handler for it
<KipIngram> Cool. I may go hunting for it at some point.
<KipIngram> Gotta go pick my kid up from school - back in a bit.
<remexre> oh wait you probably don't even need a ucontext for that, you might be able to do it in pure posix
gravicappa has quit [Ping timeout: 245 seconds]
theseb has quit [Quit: Leaving]
<KipIngram> Catching that type of exception would remove the most common reason the system ever crashes.
andrei-n has quit [Quit: Leaving]
mtsd has quit [Ping timeout: 252 seconds]
tech_exorcist has quit [Ping timeout: 252 seconds]
dave0 has joined #forth
<dave0> maw
<KipIngram> maw
<KipIngram> wam
<dave0> hi KipIngram
Zarutian_HTC1 has joined #forth
Zarutian_HTC has quit [Read error: Connection reset by peer]
dave0 has quit [Ping timeout: 245 seconds]
dave0 has joined #forth
Zarutian_HTC1 is now known as Zarutian_HTC
<lispmacs[work]> so, what does maw mean?
dave0 has quit [Quit: dave's not here]
<cmtptr> it's wam rotated by 180 degrees
<cmtptr> and by rotated i mean flipped upside down