<crab1>
How do modern day forth systems tend to handle concurrency?
dave0 has quit [Quit: dave's not here]
<remexre>
I just implement coroutines, and set things up to be one process / cpu core
<proteusguy>
crab1, old forths mostly did cooperative multi-tasking because there was generally only one core. But forth lends itself incredibly well to multi-core development and coroutines, like remexre describes, are particularly apt. ActorForth will ultimately have an actor concurrency model with extremely low overhead per independent actor thanks to the natural low call overhead for forth words.
<remexre>
er yeah, I didn't write the second half of my response
<remexre>
e.g. sharing a socket between multiple processes for network-connected processes, which iirc is how some C software does it anyway, for crash-resilience
jsoft has quit [Ping timeout: 256 seconds]
<crest>
crab1: it depends on the programmer
<crest>
most embedded forth systems that include some kind of cooperative multitasker
<crest>
but if you have a timer interrupt you could use the interrupt handler to implement preemptive multitasking
<crest>
the problem is that you now have to deal with a "hostile" multitasker
<crest>
you have to use mutexes etc. to protect critical sections
<crest>
or stop the timer/mask the interrupt inside critical sections
<crest>
the question is do you want to complicate your system that much?
<crest>
or is cooperative multitasking good enough
<crest>
because truly time critical is rare enough that you probably can afford to dedicate a timer interrupt to it
<crest>
ofcourse this depends on your hardware
<crest>
or you could implement a callout system to multiplex a single hardware timer and interrupt
<crest>
e.g. keep a binary heap sorted by deadline for oneshot timers
jsoft has joined #forth
<crab1>
so there are many options
gravicappa has joined #forth
<crest>
crab1: other forth systems running on top of operating system just expose the native thread api in some way
<shynoob>
hey.. how hard will it be to reverse engineer a program that was developed using Forth? will it be easier than reverse engineering a program that was developed using C?
<remexre>
depends on the Forth implementation, I'd expect; if it's a straightforward threaded-code implementation, it's probably pretty easy (heck, the wordlist might be in there still!); if it's an optimizing native-code implementation, might be harder for RE tools to work with if the code it generates doesn't look like the code a C/C++ compiler generates
<shynoob>
that's troubling
<shynoob>
it all ends down to how random you can be
<shynoob>
damn
<remexre>
eh, I wouldn't say /random/
<remexre>
RE tools need to use heuristics, or determining program behavior is intractable
<remexre>
and these are developed against C/C++ programs, 'cause lots of programs are in C/C++
proteus-guy has joined #forth
<remexre>
if you want to make a forth implementation that makes difficult-to-reverse-engineer code, that might honestly not be /that/ hard
<shynoob>
you just need to be random right?
<remexre>
I again wouldn't say random
<remexre>
there's a bunch of things that automated tooling is bad at reasoning about
<remexre>
anti-human-reverse-engineering measures are trickier
<shynoob>
oh btw I was meaning to ask.. do most ppl here not use swiftforth IDE?
<shynoob>
assuming its not free
<shynoob>
and there are other forth implementations
<shynoob>
assuming that's the reason*
<remexre>
I write my own forth implementations, currently maintaining 2, one for bare-metal aarch64, one for any 64-bit little-endian processor with a C compiler, running under Linux 5.6+ onlyy
<remexre>
there's a common joke that there are more Forth implementations than programs written in Forth
<shynoob>
heh.. looks like forth is a stepping stone for ppl designing their own impl. and using it to develop?
<remexre>
I describe Forth as equal parts philosophy and language; it definitely feels like one of the steps of having fully learned forth is writing your own Forth implementation
<remexre>
and generally despite these implementations not being identical, people can share ideas + pseudo-code pretty freely between them
<shynoob>
I still have a hard time understanding computers and computer science in general.. I only have my end goal at sight.. which is to be able to develop games..
<remexre>
Forth is not what I'd recommend for that, assuming you want 3d games using the gpu
<remexre>
it's possible to do games in forth, you're just going to be walking uphill
<remexre>
(again assuming 3d, gpu-using games; a text adventure in forth would be reasonable + super-interesting)
<remexre>
I'd personally recommend C, C++, or Rust; you'll find it a lot easier to use opengl (or your other gpu api of choice) from them, and especially for C++ there will be a lot more resources available
Zarutian_HTC has quit [Read error: Connection reset by peer]
Zarutian_HTC1 has joined #forth
<remexre>
on the other hand, learning Forth might help with grokking what exactly the machine does, which you'll want a very strong practical understanding of for complex games
<shynoob>
yeah... it appears thhey are the only options.. available.. but is there no way you'd suggest for forth to get good with graphics and games and stuff?
<shynoob>
oh I meant..
<shynoob>
since there will be alot of stuff to do using forth if I begin to think of 3d games in Forth.. why does not anyone suggest.. to help the forth community grow.. and accept graphics and gaame stuff
<shynoob>
is it not worth the efforts long term?
<remexre>
I don't think it's the case that graphics isn't *accepted*, so much as most of the people using Forth are working on different things
<proteus-guy>
remexre, calling openGL and other C interfaces is not difficult in several forths. Then it comes down to reasoning about your game mechanics which, I think, is easier to do in a DSL (written in forth) than most regular languages. Real issue only comes when you're pushing performance boundaries and then you probably need to go to C++.
<proteus-guy>
There are a few game oriented platforms in forth already.
<shynoob>
I meant why couldnt forth be a language of choice for high end games say 20 years down the line?
<shynoob>
for developing game engines and games*
<proteus-guy>
shynoob, in 20 years anything can be a choice but won't likely be. :-)
<remexre>
proteus-guy: using opengl 3 even? there's a lot with shaders <-> your game/engine that's disgustingly abi-dependent
<proteus-guy>
shynoob, what kind of game are you talking about?
<remexre>
well, when I say "a lot" I mean struct layout
<remexre>
I've been doing vulkan for the past year or two and there it's /terrible/
<shynoob>
why stick with one type of game.. I meant stuff what you can do using unreal engine ... or most games that are in the market
xek_ has joined #forth
<remexre>
unreal is the product of hundreds of thousands (probably millions?) of engineer-hours of work, though
<proteus-guy>
remexre, are you aware of SciPy? They're python wrappers around super high-performance language-specific scientific libraries that are a PITA to build systems on top of. Having python wrappers allows scientists to just focus on their problem while it takes care of the lower level stuff. You could do a forth wrapper around unity or some other game engine in much the same way.
<proteus-guy>
Almost the entire scientific community has standardized on SciPy now.
<shynoob>
not matlab?
<shynoob>
oh nvm
<proteus-guy>
matplotlib provides an option for people migrating from matlab when it doesn't scale up. It's part of SciPy.
<remexre>
proteus-guy: yeah, I don't disagree that it's possible; by the time you've built this for opengl though, you've basically built a rendering engine, though?
<remexre>
though, thinking about it from that angle, bindings to ogre might be reasonable?
<proteus-guy>
remexre, no you've build an modeling engine that uses that rendering engine. Well if you do it on top of OpenGL I guess so. But I'd do it on top of Unreal most likely.
<proteus-guy>
remexre, correct. And what most games ultimately need is a great scripting language. Forth is ideal for it.
<shynoob>
that's an interesting turn of events..
<shynoob>
instead of going low level.. we are going high level
<shynoob>
of abstraction to work at
<shynoob>
if my desire is to build games.. at the end.. works fine
<proteus-guy>
shynoob, forth allows you to work at precisely the level you need ultimately.
<shynoob>
this is amazing
<shynoob>
why didnt I think of that..
<shynoob>
why bother with the redesigning ... reinventing the wheel.. everytime I want to develop a game.. why not just use the existing game engines.. and get better at using them ... like this ..
<proteus-guy>
shynoob, just understand - building a full system on top of a platform like Unreal is a huge enterprise effort if you're trying to make a AAA game. It's akin to a movie production. Content is generally bigger effort than the game mechanics (script) itself.
<shynoob>
I think that would be an ambitious project..
<shynoob>
yeah
<shynoob>
I think I can start learning unreal.. and forth.. and start small.. and learn things..and implement.. little by little
<shynoob>
if at all it seems possible
<shynoob>
can you guys help me started? like know where to look for stuff etc..
<proteus-guy>
shynoob, for doing that first trick is getting your forth to call a C++ library easily. Different forths are easier than others for this. You might have to try a few til you find the one right for you. Also the concurrency model of your forth can make a big difference. You'll definitely need access to all your CPU cores. A single process cooperative threading forth is going to be difficult to scale.
<proteus-guy>
I advise playing with the RamenEngine project for a while first. Then you can get a sense of all the logistics involved for any game.
<shynoob>
I have 2 cores in my wooden laptop
<shynoob>
I wont take heed to that particular advise
<shynoob>
I intend to learn Forth and find out what is the difference between different forths.. and which one I'll be comfortable with
<shynoob>
thanks
<proteus-guy>
good luck
<shynoob>
is it worth to buy swiftforth?
<proteus-guy>
when you get something running at all post it here. be great to see some progress no matter how simple.
<shynoob>
yeah sure..
<shynoob>
but the free version it offers.. can it work with unreal?
<proteus-guy>
there's a free version you can try and then decide for yourself. I expect it's well worth buying.
<shynoob>
yeah I have the free version... but I am not sure what the difference is between the free and the paid.. except the part that..
<proteus-guy>
shynoob, no idea. You'll have to see how easy/hard it is to call a C++ library with it. I don't know if such support is built in or you have to do it yourself. Most likely the latter.
<shynoob>
I cant make executables and share
<shynoob>
no I meant.. what's the actual difference between.. free and paid version
<shynoob>
what can I do and what can't I do?
<proteus-guy>
Looks like that's the major difference. Also they do have support for loading C libraries. See https://www.forth.com/swiftforth/ section "Libraries, Functions, Callbacks, and Threads". Of course calling C++ is something different. May have to have a small C lib that wraps your C++ model first.
<proteus-guy>
You won't need the paid version until you build standalone executables you wanna distribute.
<remexre>
uh, also note, swiftforth appears to be 32-bit i386 only? which may or may not be an issue with unreal
<remexre>
oh, google says it is
<remexre>
er wiat, that's unity editor
* remexre
shrugs
<proteus-guy>
32 bit only? wow that's a surprise.
* proteus-guy
is in a meeting now.
<remexre>
lol I will be in 12 hours... should probably get to bed
<shynoob>
gn
<shynoob>
welp its a layer on top of another layer.. dang
<shynoob>
too many layers of abstraction ..and levels to deal with
<shynoob>
proteus-guy hey I understand that I dont need the paid version if I dont wanna distribute my executables.. but can I use it with unreal or something with the free version.. directly..?
<shynoob>
I guess I can run and stuff from the IDE .. will have to stick with the IDE.. all the time..
<shynoob>
damn I feel so unexperienced .. lacking of basic general knowledge
shynoob has quit [Ping timeout: 245 seconds]
X-Scale` has joined #forth
X-Scale has quit [Ping timeout: 246 seconds]
X-Scale` is now known as X-Scale
jsoft has quit [*.net *.split]
proteusguy has quit [*.net *.split]
C-Keen has quit [*.net *.split]
jsoft has joined #forth
proteusguy has joined #forth
C-Keen has joined #forth
proteus-guy has quit [Ping timeout: 256 seconds]
xek_ has quit [Ping timeout: 260 seconds]
shynoob has joined #forth
<shynoob>
so I was wondering .. will it really be tht helpful to create a forth wrapper around unreal engine.. it might only complicate things.. maybe?
<proteusguy>
shynoob, that's because unreal engine has to be a general purpose engine useful for all game development. you want/need a DSL that is specific to your game. forth is ideal for DSLs.
<shynoob>
what is DSL
<proteusguy>
domain specific language
<shynoob>
I see
<proteusguy>
the domain, in this case, being your game mechanics.
<shynoob>
so using Forth for a specific implementation or instance or game?
<proteusguy>
using forth to create a language that makes it easy to implement your specific game.
<shynoob>
that smh makes sense
<shynoob>
btw how do you create a language using forth
<proteusguy>
all good forth programs consist of first creating a DSL for your problem using forth, them implementing the solution to your problem in your new DSL.
<proteusguy>
all words are equal in forth. any word you create is just as much a part of the language as the prior existing words, built in or otherwise.
<shynoob>
cool
<proteusguy>
building words is what you do in forth. you create a new language by composing these words together, concatenating them and passing their data between each via the stack.
<proteusguy>
you can make your words as high level or low level as you need for your specific problem.
<shynoob>
cool then I'll start by learning forth first and the existing words in it
<proteusguy>
read "Starting Forth" then "Thinking Forth" and you'll understand. Leo Brodie is the author and both are available freely in pdfs now.
<shynoob>
cool
<shynoob>
and then I'll have to establish a bridge between C++
<proteusguy>
shynoob, yes - that's gonna require some effort. :-)
<shynoob>
so will have to visit C++ and learn some of that
<proteusguy>
that's why starting out with a 2D game and using Ramen is likely a much better way to learn because you'll be able to make progress much sooner.
<shynoob>
I believe.. C++ used in Unreal is different than the standard C++.. coz it approaches programming in a distinct way..
<shynoob>
or maybe I am wrong
<proteusguy>
No - it's standard C++.
<shynoob>
yeah it is technically
<proteusguy>
it is really.
<shynoob>
but.. smh the usage style
<shynoob>
ohh
<shynoob>
many ppl hate object oriented paradigm.. coz it complicates stuff for them..
<proteusguy>
usage styles vary across most projects. I not aware of anything about Unreal that seems out of place, however. Don't recall anything.
<proteusguy>
People who hate certain things generally don't understand them. OO is perfectly fine architectural style. But few things claiming to be OO really are.
<proteusguy>
They're just saying ue4 uses a lot of old style stuff. True but every old project uses a lot of old style stuff. However, UE5 is out now and has been modernized.
<shynoob>
oh ok
<proteusguy>
Oh UE5 isn't actually released yet. Next year.
<shynoob>
oh I thought they released it
<shynoob>
oh first look
<shynoob>
by the time it releases..I'll have gone thru some of forth and C++ .. I suppose.. so no harm
<shynoob>
:D
<proteusguy>
yep. you've got plenty of time. write some 2D games first!
<shynoob>
in ramen engine ? :P
<proteusguy>
sure
<proteusguy>
there's a pre-made environment designed to do specifically what you wanna do.
<shynoob>
I saw some of the 3d game dev process.. in unreal.. it isnt more scary than 2d game dev process.. much..
<shynoob>
I mean.. they use blueprint and stuff which helps a lot I guess
<shynoob>
to imagine
<shynoob>
and manage
<shynoob>
maybe
<shynoob>
everything just seems like dealing with layers of abstraction
<proteusguy>
that's what programming is
<shynoob>
with complex relations
<shynoob>
hm
<proteusguy>
it's managing and eliminating complexity
<shynoob>
pdf is not available for swift forth 2nd edition? only online?
<proteusguy>
I dunno
xek_ has joined #forth
chewb has joined #forth
xek_ has quit [Ping timeout: 258 seconds]
xek_ has joined #forth
Zarutian_HTC1 has quit [Read error: Connection reset by peer]
Zarutian_HTC has joined #forth
Zarutian_HTC has quit [Ping timeout: 256 seconds]
jackdaniel has quit [Remote host closed the connection]
jackdaniel has joined #forth
xek_ has quit [Ping timeout: 240 seconds]
crab1 has quit [Ping timeout: 265 seconds]
jsoft has quit [Remote host closed the connection]
jsoft has joined #forth
Zarutian_HTC has joined #forth
chewb has quit [Ping timeout: 265 seconds]
chewb has joined #forth
shynoob has left #forth [#forth]
spoofer has quit [Quit: leaving]
gravicappa has quit [Read error: Connection reset by peer]
remexre has quit [Read error: Connection reset by peer]
remexre has joined #forth
gravicappa has joined #forth
spoofer has joined #forth
xek_ has joined #forth
gravicappa has quit [Ping timeout: 256 seconds]
WickedShell has joined #forth
xek_ has quit [Ping timeout: 240 seconds]
dave0 has joined #forth
Keshl has quit [Read error: Connection reset by peer]