<tp>
I have many good questions, and few answers :)
<tp>
Jeg har mange gode spørsmål, og få svar
<Zarutian_HTC>
google translate, eh?
<tp>
yeah, danish is unknown to me
<tp>
I use Google translate a lot when trying you understand Mecrisp-Stellaris
<tp>
you = to
<tp>
as most of the excellent comments are in German
<Zarutian_HTC>
had to learn the bare minimum in elementary. I am not fond of the language due to too many borrowed words from french, english and german
<Zarutian_HTC>
jahwëll!
<tp>
and you have to carry around a potato to insert in your throat to speak it ?
<Zarutian_HTC>
naah, just immitate the speach impedent one half danish king had
dave0 has quit [Quit: dave's not here]
<tp>
aha
<Zarutian_HTC>
once, for an electronics course work I had to read a twenty or so page booklet written entirely in german. But the language was so clear that a short glossary was all that was required to understand it
<tp>
yes, I now know a bit of German for reading
<tp>
the things one learns while doing Forth !
<Zarutian_HTC>
I have strived to be as concise and clear in my writings regarding tech topics
<tp>
excellent, I also try to achieve the same
<tp>
but some have are much better at writing, I'm convinced that writing is a 'gift' rather than a learned skill
<Zarutian_HTC>
well, you can get a long way by translating drafts into lojban. It is an excelent way to find unnoticed ambiguities
<tp>
tabemann, very interesting reading your changelog :)
iyzsong has joined #forth
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
<tabemann>
back
<tabemann>
I assume you noticed the double words
<tabemann>
I'm now starting to write documentation for the double words, since I figured I should document them before releasing them
<tp>
I didnt actually
<tp>
awesome, thats the time to do doc, when you write the code
<tp>
I've found that for me, Forth doc has absolutely no penality
<tp>
because my system strips all comments before uploading
dave0 has joined #forth
<tabemann>
tp: I have documentation in with the code
<tabemann>
but I'm separating it out and improving it
<tabemann>
so someone doesn't have to dig through my kernel code to get at some comments
<tp>
Doxygen!
<tp>
;-)
<tabemann>
well I'm also writing stack signatures, because I had neglected to write them originally
<tp>
yeah, theyre essential I think (now that rdrop-exit made me aware of the correct use)
<tp>
I've learnt a lot lately reading matthias code
<tp>
tabemann, so how do you determine free memory if not using the chip 'flashsize' register contents ?
<tabemann>
tp: it's hard compiled in
<tp>
that precludes a paramater driven word tho ?
<tp>
guess it doesnt matter
<tabemann>
I have another file, ihex_manual.fs
<tabemann>
where you can just hand-specify a number of bytes
<tabemann>
I find it much easier to remember how much flash space my boards have than to remember some address to read the size out of
<tp>
the problem with dynamically scanning flash is some models use "0xFF" for erased and some use "0x00" but the biggest problem is if one scans memory that's NOT there ... EXCEPTION!
<tp>
is there a way to look for a exception and recover from it ?
<tp>
Im not aware how
<tp>
that way one would only need to scan flash and wait for a exception
<tabemann>
tp: in hashforth I was able to do just that; with zeptoforth I was hoping that I could do something similar
<tabemann>
bbiab
<tp>
no problemo
<tp>
dave0, cortex-m can detect divide by zero is enabled: SCB->CCR onfiguration and Control Register: contains enable bits for trapping of divide-by-zero
<tp>
is = if
<dave0>
tp: ah cool
<tp>
it seems to have exceptions available for everything
<dave0>
tp: i found a simple compare to detect divide by zero and overflow at once, so it checks and just jumps back to QUIT
<tp>
cool
<dave0>
it doesn't distinguish between / by 0 and overflow, but it does trap properly
<dave0>
i added a check for LSHIFT with a -'ve count, so it traps too :-)
<tp>
ill get a underflow error on that I think
<tp>
from Mecrisp-Stellaris
<dave0>
ah
<dave0>
after the discussion about divide, i decided to add checks for as many undefined behaviours as i could
<tp>
i should turn on the underflow exception and see what happens with Mecrisp-Stellaris
<dave0>
that's one thing that makes C shit... it doesn't check for you and screws up the whole program
<tp>
my todo list is getting pretty long now
<dave0>
tp: ehehe
<tp>
thats one advantage of using Fossil as a SCM, it has a inbuilt ticket system
<tp>
every repo has it's own ticket server
<tp>
so I just add them
<tp>
thats what people dont get about GIT, it may be great for linus and the Linux kernel, but it's now where near as useful for private devs doing their own small projects as Fossil is
onat has joined #forth
<tp>
lol, my IDE is so well developed now that if I get a error from it I really have to dig deep to find it!
<onat>
hello fellow forthwrights!
<tabemann>
back
<onat>
Throwing this idea for discussion: Is Forth viable as a runtime language? As in, using actual stacks in runtime. Feels quite wasteful to me.
<onat>
I've been viewing Forth more as a programmable assembler for a while now.
<tabemann>
onat: considering just how wasteful much of computing is today...
<tabemann>
I mean, Forth is seriously lightweight when compared to the likes of Java and JavaScript virtual machines, especially when compiled to native code
<tabemann>
furthermore, there are Forths such as Mecrisp-Stellaris RA that do automatic register assignment
<onat>
tabemann: totally agree with the waste
<onat>
Thing is With automatic register assingment, does it lose subroutine call efficiency?
<tabemann>
onat: note that it's combined with inlining as well
<tabemann>
any good native code Forth will also have inlining
<tabemann>
also, I should note that almost all virtual machines out there are stack oriented in reality, just like Forth
<tabemann>
there are only a handful (e.g. Lua's) which are register-based
<onat>
I see, yeah, I want Forth speed to take on C:)
<onat>
I'm wondering, stack should be always in L1 cache, which is around 3 cycles on modern processors.
<tabemann>
and I bet a subroutine threaded / native code inlining / register assigning Forth will give that to you
<onat>
Can you recommend such a Forth for Linux?
<onat>
I'm wondering about the generated code.
<tabemann>
the main Forth that fits that description I know is Mecrisp-Stellaris RA, but that is for Cortex-M (even though it has a version that can run under Linux on ARM)
<tabemann>
but there are fast PC Forths as well, e.g. gforth (which is fast, so I hear, even though it's a behemoth as well)
<tabemann>
tp:
<tabemann>
I now have made a new release, 0.2.0, of zeptoforth
<tp>
tabemann,
<tp>
ah cool
<onat>
Thanks, I didn't check Mecrisp-Stellaris yet.
<tabemann>
it includes the double-cell words, along with deferred words and XON/XOFF
<tp>
tabemann, nice
<tabemann>
onat: note that there are two different kinds of Mecrisp-Stellaris, RA and non-RA
<tp>
onat, Forth has every advantage C does depending on the type of Forth
<tabemann>
Forth is like the love child of assembly and Lisp, as I like to say
<tp>
tabemann, and C if you use a tethered Forth
<onat>
tabemann: huh, what's the difference? optimizations?
<tabemann>
it's like assembly in just how low level it can be
<tabemann>
it's like lisp in that it provides a REPL and a lot of support for metaprogramming, reflection, and "macros"
<tabemann>
oh, about RA
<tabemann>
RA goes and assigns values on the top of the stack to registers when possible
<tabemann>
rather than using the stack in memory all the time
<tp>
and with a tethered forth, multiple passes to further optimise the binary output
<onat>
tabemann: How much faster is that? Any resources/papers on the speedup?
<onat>
Should've mentioned I'm also writing a colorForth inspired system.
<tabemann>
haven't seen anything
<onat>
I speculate the speed difference should be that much actually
<onat>
*shouldn't
<tabemann>
you seem really concerned about how fast Forth is - from what you are saying, you wouldn't accept anything slower than assembly - but mind you that everything is slower than assembly, oftentimes dramatically slower
<onat>
Juggling registers back and from memory and between the function calls, it could be actually slower.
<tabemann>
if you're ruling out Forth because it doesn't match assembly, you might as well rule out all programming languages other than assembly
<tabemann>
even C was designed for the PDP-11, not for modern superscalar processors
<onat>
You're totally right, I'm imagining I would use "Forth runtime" for cold code and assembly generated by Forth for hot code.
<tp>
read all about it!!! tabermann burnt at the stake by angry crowd of hooded C programmers ....
<onat>
When I say runtime, I'm saying the register allocation for a specific task, still featuring a data and return stack.
<onat>
:))) I'm a C programmer and I don't like it anymore, I write more Forth-like-C. I don't find textual Forth that workable either.
<onat>
An IDE seems necessary to become productive with Forth, yet so many people write without an IDE.
<tabemann>
Forth is infinitely more extensible and interactive than C
<onat>
So I'm thinking maybe I'm missing something.
<onat>
Totally!
<tabemann>
and it is probably the only interactive language even close to C in performance
<onat>
I've had close to interactive programming in C with hot-reloading.
<onat>
I need more from the environment, like instant visualisation of memory structures.
<tabemann>
the main way to make C interactive is to embed another language in it, such as Lua
<onat>
Built-in debugger, no printfs.
<tp>
tabemann, or Forth
<onat>
The main way, yeah. You can also hotload the C application just as Lua allows.
<tabemann>
that sounds like Java, but Java will not give you the performance, extensibility, or interactivity that you want
<tabemann>
tp: yes, e.g. ficl
<onat>
If coded in a certain way.
<tp>
tabemann, I know a guy who runs a Forth embedded in his C application
<onat>
Java is awful, doesn't give any visualisation AFAIK
<tp>
he uses "atlast"
<tabemann>
onat: Java gives you a moderate amount of debugger support when combined with an IDE designed for it, such as IntelliJ
<tp>
onat, tell us more about C "hot reloading" ?
<tabemann>
whereas Forth is more about poking and prodding your code from the REPL
<tabemann>
tp: I think onat means dlopen()
<tp>
tabemann, ahh, on a PC
<tp>
tabemann, thanks
<tabemann>
but dlopen() doesn't allow you the interactivity that a REPL allows
<tabemann>
you still have to separately compile your code, then tell the application to load it - and you can't just poke and prod your code at runtime
<tp>
so much for it as a 'alternative' then
<tabemann>
a closer thing to interactive C is gdb
<tabemann>
but that doesn't allow you to change your program at runtime
onat has quit [Ping timeout: 260 seconds]
onat has joined #forth
<onat>
Oh dang, my internet just disconnected for 260 seconds sorry!
<onat>
Oh dang, my internet just disconnected for 260 seconds sorry!
<tabemann>
look at the logs
<onat>
Yeah:)
<onat>
Exactly, with dlopen! Allocate some piece of memory at the startup, pass that to the DLL, works like magic.
<tabemann>
but you can't just sit down at a REPL and start entering code to execute right then and there
<onat>
Yeah, that doesn't allow for runtime changing of some piece of code, you have to change the whole DLL.
<tabemann>
which super-simplifies the debugging process
<tp>
onat, there is no C alternative for interactive programming on small embedded, what youre describing is only any good on a PC
<onat>
tp, yes, for embedded Forth is unrivaled.
<onat>
tabemann: I haven't used REPL that much.
<tp>
onat, almost, there is a BASIC for cortex-m I think ;-)
<onat>
:))
<tabemann>
beware microPython and eLua though
<tp>
tabemann, not on cortex-m0 :)
<tp>
tabemann, because neither will run on coertex-m0
<tp>
onat, here is a sample of a cortex-m0 REPL in use
<tabemann>
tp: otherwise it will spew out asterisks as fast as the CPU will allow
<tp>
tabemann, does no delay strip the phosphor of your screen ?
<tabemann>
and it will never yield
<tabemann>
of course you could add a pause for that
<tp>
tabemann, aha, of course
<onat>
tabemann: very interesting
<tp>
tabemann, or have the terminal use a interrupt ;-)
<tabemann>
tp: the RX and TX in zeptoforth are interrupt-driven, so no PAUSE would not prevent the stars from being output
<tabemann>
however
<tabemann>
no PAUSE means that the REPL will freeze
<onat>
cooperative tasks?
<onat>
PAUSE was yield AFAIR
<tabemann>
tasks in Forth are cooperative typically, even though there are preemptive Forths as well
<tabemann>
(e.g. another Forth of mine, hashforth, is preemptive)
<onat>
I've got two guys on my shoulders now, whispering to my either ears.
<onat>
One says do it the purest way, write own Forth in assembly, use textual input.
<onat>
The other says, do a complex editor in C, use Vulkan for rendering, custom-binary pre-parsed format.
<tp>
tabemann, how can no pause freeze a interrupt driven usart ?
<onat>
Maybe do the first purely in asm, then go on to do the complex binary pre-parsed in that later but what's the point anyway, just needs to exist.
<tp>
the interrupt driven usart MUST respond
<tabemann>
tp: it doesn't - but the lack of a PAUSE prevents REFILL from reading text into the input buffer
<tp>
tabemann, aha, thanks for explaining that
<tabemann>
eventually the RX and TX circular buffers will fill up
<tabemann>
wait
<tabemann>
the TX circular buffer won't fill - it will be starved instead
<onat>
The interesting thing with pre-parsed format is that the editor will be complex but the Forth core/loader will be MUCH simpler.
<tabemann>
the RX circular buffer will fill
<tp>
tabemann, cant the usart interrupt call refil ?
<tabemann>
the USART interrupt handler does not know about REFILL
<tp>
onat, people new to Forth often imagine all kinds of improvments they will do, perhaps without realising that Forth has been polished by 10's of thousands of programmers since the 70's
<tp>
tabemann, obviously, but does that mean it is impossible ?
<tp>
onat, if you want a Forth that produces code as optimised as a C binary output, you just use a 'tethered Forth
<tp>
onat, that way you get all the advantages of a REPL and all the advantages of a multi pass compiler
<onat>
tp, I should check out tethered Forths, first time I'm hearing about those.
<tp>
tabemann, darn, the M0 has no div by zero setection!
<tabemann>
about REFILL, well, the input buffer cannot receive input at any point in time
<tp>
tabemann, lol, is that why ?
<tp>
tabemann, re REFIl, I see
<tabemann>
because if the main task is interpreting code in the input buffer, and then the RX handler shoves in more data, it will corrupt it while it is being executed
<tabemann>
rather, data can only be read into the input buffer within REFILL, when it is safe to do so
<tabemann>
and REFILL uses KEY to get bytes from the RX circular buffer
<tabemann>
if there is no PAUSE, REFILL will never execute, and thus it will never call KEY to read bytes in
<tabemann>
even if there were an automatic means for refilling the input buffer via the interrupt handler
<tabemann>
that code would never be executed without PAUSE
<tp>
tabemann, thanks, I'l try and limit stupid questions in future :)
<tabemann>
the only way to do it would be to make a preemptive kernel
<tp>
thats a good one and will run mecrisp-stellaris and tabemann's Zeptoforth
<tp>
it's the same board he is using for development
<tp>
thats definitely the one for you
<tp>
Mecrisp-Stellaris has a STM Nucleo L432KC STM32L432KC which is pretty close, but tabemann will have a version hes modified to run on the stm32l476g I'm sure
<tp>
veltas, Mecrisp-Stellaris has a binary ready to run on the STM L476 Discovery with STM32L476VG, no mods needed
<veltas>
I will get those mecrips when I get the boards probably
<tp>
you dl Mecrisp-Stellaris from the link I gave you above
<veltas>
Actually wget worked so now I have them
<tp>
and of course if you want a full blown Eclipse C system, theyre all free doe the Disco board
<veltas>
Eclipse ugh
<veltas>
ewww
<tp>
doe = for
<tp>
yeah, only 4GB of install probably
<veltas>
I hate Eclipse
<veltas>
And eclipse tools
<tp>
so would your lappie
<veltas>
Yes
<veltas>
Why do you think I have this laptop? Nothing I do needs more than that
<tp>
I installed the eclipse STM 'atollic studio' on a Intel NUC with a dual celeron
<veltas>
Although I will admit when I use Facebook occasionally it struggles
<tp>
to change a menu on that massive system took about 10 minutes on the NUC, LOL
<veltas>
Gross
<tp>
yeah, it almost made me vomit
TCZ has quit [Quit: Leaving]
<crest>
tp: my workstation is a 16 core amd 3950x with 32gb ram
<tp>
it looks pretty and so capable, in reality is just horrible
<crest>
but at the moment i'm on macbook from 2012
<tp>
crest, youre low end as well huh ?
<veltas>
Eclipse tools are usually just a load of stuff that worked well on the terminal but now I have to run a massive bloated Java app with a horrible interface
<tp>
;-)
<veltas>
I hate IDEs so might be biased
<crest>
its fast enough for ssh and mosh
<tp>
veltas, when a Forth person says they have a IDE, they are talking about something completely different
<tp>
crest, lol
<crest>
and modern browsers work better on macos than freebsd if you have to use a webcam and audio
<veltas>
tp: What are they talking about? I'm interested
<veltas>
IDEs aren't inherently bad, just all IDEs I see are like Visual Studio or Eclipse or something
<tp>
veltas, they mean 'a Integrated Development System' not anything like Atollic with eclipse
<veltas>
Isn't Forth itself an integrated development system?
<tp>
yeah, thats right, they really mean a MBM a 'Massive Bloated Monolith"
<crest>
tp: does the default kernel include hardware flow control?
<tp>
veltas, in a way it is yes
<tp>
crest, no, matthias didnt need it
<tp>
crest, matthias is fine with a 200ms EOL and picocom
<veltas>
I watched a good YouTube rant about how new Visual Studio is worse than the old one because its interface (i.e. the main point) is so slow and bloated
<crest>
is it enough to reconfigure the hardware or i have to change the input/output hooks as well?
<veltas>
It's all written in Visual BASIC so no surprise there
<tp>
veltas, I'm not surprised, I hate all that junk als well
<tp>
crest, ALL you need to do is enable RTC on the USART
<tp>
oops
<tp>
RTS
<crest>
so a simple init word is enough?
<tp>
and select a pin to go with it, plus a Alternate Function config
Zarutian_HTC| has joined #forth
Zarutian_HTC has quit [Ping timeout: 265 seconds]
<crest>
i just have to find out how to configure the pin and bump the uart speed as far as it will go
<tp>
crest, I dunno, Im about to try a modified init for the dev edition
<tp>
crest I may have a ready made binary somewhere
<tp>
one without a USB default
<tp>
want me to look ?
<crest>
could the boot 1 jumper on the bluepill be used to switch between serial and usb?
<tp>
crest, no
<tp>
crest, not unless you want to flash a binary via serial ?
<tp>
crest, a standard Mecrisp-Stellaris will expect a serial connection
<crest>
.oO( i wonder if its possible to not reset the usb hardware keep the user serial connected during a reset )
<tp>
not on my bluepill binaries, it will always revert to usb on reset
<tp>
thats what the users wanted
<tp>
hmm
<veltas>
I want to support that syntax now
<veltas>
.oO(
<veltas>
Alias for (
<veltas>
tp: I do really hate features that make me think "somebody got promoted for that"
<veltas>
Like Visual Studio changing theme, or getting a dark theme, I'm just thinking maybe they should do a 'fast' theme that would be good.
<veltas>
And then there are changes in programs designed to actually annoy me, like a notification that a program I'm using is about to change how it looks to a "new" more "modern" style that's "easier to read" or something and I just know it's going to lose features, get slower, and display less on the screen
<veltas>
Overall a lot of repetition of me getting annoyed by people who invest time and money in making my stuff worse
<tp>
it's for .... the children
<veltas>
I also use vim
<tp>
cool
<tp>
veltas, I like simple and I like fast
<tp>
my system isnt all shown there and it was one of my first ever videos, so pretty crappy
<tp>
veltas, Ive been thinking about doing another one but there is a lot to show, so I'll need better video compression etc
<veltas>
vim is bloated but I don't care because it has simple setup, runs quickly, and seems to mostly have stuff that lets me work faster
<veltas>
It's not VS bloated though lol
<tp>
it's not really bloated to anything like that
<tp>
it's crazy fast here
<tp>
but I need all the VIM facilities, I cant use a simpler editor
<tp>
something like Geany wont do much of the stuff I must have
<veltas>
vim is fast on *my laptop* so it is 'fast' lol
<tp>
yeah it's ok
<veltas>
If I could get 95% of the features I use in vim in something 10% of the code size I would switch
<veltas>
Because inevitably I could understand it and configure it easier
<veltas>
Well it would have to be as fast too, but probably it would be
<veltas>
Some people use the vi stuff that's around still but I don't like vi, lots of stuff is pedantic in vi
<tp>
same
<veltas>
Features of vim that actually distinguish it for me: macros, whole line select, block select, uppercase/lowercase conversion, search for current word, search forwards/backwards on last search, move backwards/forwards in file jumping history
<veltas>
Save/load session, pattern replacement on file/selection
<veltas>
That's all I can think of, some of those you'll expect on normal editors
<tp>
I also use it to add Forth diag words and include the line number
<tp>
in some debugging
<veltas>
Moving forwards/backwards through the file like you would press back/forwards on a browser is super useful and vim is the only editor I have seen do it
<tp>
it a kind of C 'printf' favility
<veltas>
Nice
<veltas>
emacs has some stuff that I prefer over vim, but it was not worth staying in emacs for
<veltas>
It has one m
<veltas>
'mode' for input
<veltas>
Sorry hit enter too soon
<tp>
i like emacs but dont want to try and make a competing system for what I have already with it
<veltas>
So the commands you learn for text editing work while editing, moving, and in commands. Most of those commands actually work on most Linux prompts including bash, python, whatever
<veltas>
In vim you have to learn 2 different sets of key commands and inevitably most people don't (including me)
<veltas>
so I feel like an ape correcting vim commands
<veltas>
pressing and holding left key while I'm in a supposedly powerful text editor because I can't remember the command to move one word etc
<tp>
haha
<tp>
yeah
<tp>
I'm slow editing anyway
<veltas>
Forth is good for this
<veltas>
Because it's so factored you could edit it in any editor for roughly the same productivity
<veltas>
And it's hard enough usually that I couldn't benefit from writing faster anyway
<tp>
you can, but I use my IDE
<tp>
I never use the terminal to enter code except for short experiments
<tp>
i do most of my experiments in GVIM anyway as I only have to click on the MAKE button to have them uploaded as you saw in the video
<tp>
it uploads at 460800 baud after stripping all comments
<tp>
if the compiler errors I get a beep and the error has a RED "ERR" flag inserted in the problem source location
<tp>
i also log it all so I can grep for the error if I cant be bothered scrolling up the terminal screen with my mouse wheel
<tp>
this is all 100% automated
inkajoo has joined #forth
<inkajoo>
Streaming game development in Forth all day for Ludum Dare #LDJAM #ForthLang #gamedev http://twitch.tv/inkajoo
<tp>
ill take seed studio over alibaba and the 40 theives anyday
<veltas>
seeed have that horrible website thing of "as soon as you scroll down a bit because you wanted to see info further down we are going to lop off 40% of your screen with our moving banner that should have just stayed at the top but then I wouldn't have gotten the promotion
dave0 has quit [Quit: dave's not here]
* Zarutian_HTC|
uses pico if he has to use a text editor in a terminal, otherwise he use Notepad++ often with wine or recompiled to work on a linux. (TexfWrangler I use on MacOS X)
<tp>
well nighto folks, it's midnight here
<Zarutian_HTC|>
tp: see ya around
<tp>
Zarutian_HTC|, pico is ok
<tp>
Zarutian_HTC|, see ya!
Zarutian_HTC| is now known as Zarutian_HTC
<veltas>
Night tp
<veltas>
Zarutian_HTC: Have you tried scintilla-based alternative on Linux?
<veltas>
They're rubbish but so is Notepad++ (shots absolutely fired)
<Zarutian_HTC>
nope, often I am remoting into some machine and dont have the time or inclination to try to install or setup something
<Zarutian_HTC>
what I have been looking for is resource light code editor with semantic highlighting
<veltas>
gedit is fine, but it has syntax highlighting not sure about semantic
<veltas>
Even the new gedit is fine
<Zarutian_HTC>
that is, say an identifier is coloured the same unless it is being shadowed (in such languages that support that)
<veltas>
You need to enable color syntax, line numbers, etc if you want them
<veltas>
Does anyone here use any programming tools or everyday programs written in Forth?
<veltas>
I know tp does, since he uses FreeBSD I am guessing he uses the Forth-based kernel startup or whatever it is
<Zarutian_HTC>
yeah, I have used gedit but it sometimes seem to want to use propotional small font instead of monospaced for some reason
<Zarutian_HTC>
and dont get me started on IDEs or some electronics design software
<Zarutian_HTC>
veltas: does an home made l seven segment clock count?
onat has joined #forth
<Zarutian_HTC>
I had one running for years, programmed in forth
<Zarutian_HTC>
an atmega328p jobbie with a ported eForth on it iirc
<veltas>
I guess I'm talking more about software on your computer
<Zarutian_HTC>
I see, no not recently. Though I have used gforth to do bit of electronics number crunching
<Zarutian_HTC>
finding a fixed point for a certain resistor network iirc
<Zarutian_HTC>
most of the spice simulator crapped out, gave wrong answers, or were just too costly runtime wise
<veltas>
tp: Bought it from ali because I want the whole chinese experience ;), you can sue me for that too
<veltas>
Zarutian_HTC: Spice simulator?
jsoft has quit [Ping timeout: 256 seconds]
<Zarutian_HTC>
right, electronic circuit simulator. The spice line started with ltspice.
<Zarutian_HTC>
but one problem is that they are too inaccurate and cannot simulate certain simple circuits
<Zarutian_HTC>
ltspice was an old project by an phd student in theoritical electronics engineering
<Zarutian_HTC>
veltas: ^
TCZ has joined #forth
TCZ has quit [Quit: Leaving]
merkc0 has joined #forth
<merkc0>
is there any way to execute a loop in interpret mode ?
<merkc0>
2 0 DO CR LOOP
<merkc0>
^ -312 Only for compilation !
<MrMobius>
merkc0, you could make a word then undefine it after you run it
<merkc0>
more specifically, I have this problem
<merkc0>
A: ' NOP EXECUTE ;A \ this works
<merkc0>
but this doesn't:
<merkc0>
A: ' NOP 3 n-execute ;A
<merkc0>
: n-execute ( xt n ) 0 DO DUP EXECUTE LOOP DROP ;
<merkc0>
A: ' NOP 3 n-execute NOP
<merkc0>
INSTRUCTION
<merkc0>
^ OFFSET OR IMMEDIATE OPERAND NOT ALLOWED WITH THIS
<merkc0>
A: ' NOP EXECUTE ' NOP EXECUTE ' NOP EXECUTE ;A \ also works
<veltas>
Okay the issue is that DO..LOOP assumes the stuff in between is compiled and not 'consumed'. [IF] is possible because you are only doing the input once, loop would not be possible without compiling
<veltas>
That's my 2 cents
<veltas>
It's not impossible but not surprised it's not supported in interpret mode
<tabemann>
back
<tabemann>
hey guys
<tabemann>
control structures other than [if] [else] [then] are not normally allowed when interpreting in Forth
Zarutian_HTC has quit [Ping timeout: 250 seconds]
Zarutian_HTC has joined #forth
<tabemann>
tp: when you get back - if you have had no luck trying to use the F407 full binaries, that's because they've been corrupt - try the newest ones
dddddd has joined #forth
onat has quit [Quit: Lost terminal]
merkc0 has quit [Ping timeout: 258 seconds]
TCZ has joined #forth
C-Keen has quit [Quit: WeeChat 2.6]
<crc>
veltas: I use a variety of applications written in forth daily for both personal projects and when at work
<veltas>
That's what I want to hear
<veltas>
In retro?
<crc>
yes
<veltas>
Or other kinds as well?
<crc>
all retro, I don't use other forths for anything I rely on
<crc>
(nothing against other forths; retro is just too comfortable for me at this point as I know it completely)
<veltas>
Well it's your forth right?
<crc>
yes
<veltas>
I think it's a good sign that you use it all the time for your stuff
<veltas>
A good sign for forth and for retro in particular
<crc>
I mostly use unix hosts, ficl is buggy, gforth is a pain to build, I've not used pforth much, and quite a few others (x4/isforth, reva, helforth, etc) are 32-bit Linux/x86 only and I need to run on a wider variety of unix systems
<veltas>
I think that's a good benchmark for a language
<crc>
for retro, I use it as my first choice for projects in almost every case
<veltas>
Right now my go-to languages for "getting stuff done" are Lua and C, I am not really religious about either and would like finding a language to replace at least one of those
<veltas>
gforth *is* a pain to build
<crc>
(exceptions are mainly where I have to integrate into an existing codebase, which is typically involving either C or Python; even then, if I can get by with using retro and communicating via pipes or sockets, I prefer to do so)
<crc>
I think I've managed a working gforth build once, on a linux system, and that was a few years ago
<veltas>
Does retro have support for calling C directly?
<crc>
no
<veltas>
Is there a reason?
<crc>
I've not needed this in my programs so far
<crc>
I *have* experimented with this a little, but not enough to release yet
<veltas>
Do you think that would work nicely?
<crc>
it'll require some work; retro's internal model is purely 32-bit or 64-bit, so there'll be need for bridging to allow tranlsation between byte and cell addressed memory at a minimum
<veltas>
Shame that we moved on from K&R C
<Zarutian_HTC>
my usual modus operandi for C in Forth is basically hand translate it
<veltas>
crc: Is there anything that would stop there being a 16-bit cell retro? Is it an assumption in retro that cell sizes are at least 32-bit?
<crc>
veltas: the kernel is written for 32-bit or larger cells, but this could be changed (I've done it once as a test)
<veltas>
I'm not familiar with forth terminology, is the 'kernel' the non-portable part that provides the words the portable part uses?
<veltas>
I shouldn't say 'portable' because I mean 'platform-specific'
<veltas>
It's *portable* if one part is platform-specific
<veltas>
Lockdown is definitely hurting my talking/writing ability...
<crc>
specifically in retro, the kernel is the assembly portion of the system (which in retro, runs on an emulated misc architecture)
<veltas>
So the misc architecture is the bit that needs to be implemented for each system?
<veltas>
And some 'drivers' too I imagine?
<crc>
the easiest way to run on a 16-bit system is to just compile the vm for 16-bits (and accept a performance hit as the 16-bit vm handles the 32-bit system)
<crc>
yes
<crc>
a minimal implantation of the vm in C is around 250 lines of code
<crc>
john_cephalopod did an x86 assembly version that's just over 1kb of binary
<veltas>
Well I was wondering aloud about whether I could implement a 16-bit cell version in Z80, or how much would fit in that
<crc>
The smallest I've done was running on a emulated 8086 system, with 64k of ram
<veltas>
Well if it was Z80 I'd run on the Spectrum
<veltas>
I don't assume it would fit, but maybe retro is quite small?
<veltas>
It looks very powerful but in forth I don't assume powerful = big
<crc>
with 32-bit cells, it's about 40k; it'd be smaller with 16-bits
* crc
*is* planning to do a version with 16-bit cells sometime...
<crc>
(a food chunk of that is dictionary heads, since cells are 32-its, each character in a name uses 4 bytes currently)
<veltas>
Ooooh wow okay
<veltas>
Meanwhile in my forth I have a c-constant
<veltas>
I mean c-variable
<veltas>
For byte-sized variable
<veltas>
But c-constant as well
<veltas>
crc: Are your characters all UTF-32?
<tabemann>
hey guys
<crc>
veltas: I use ascii only, but it'll happily hold any encoding your os supports. On iOS, it uses utf8; I've explored utf16 on windows. I don't know of any hosts using utf32 though
* tabemann
hates that he feels the need to make a whole new release for any minor mistake in zeptoforth
* tabemann
is on his sixth release of zeptoforth within like a week, and only one of those was really due to new functionality
<crc>
tabemann: release early and often, especially when it's still early in its life
<crc>
iirc, with retro6, I was doing weekly releases for quite a while
xek has quit [Ping timeout: 260 seconds]
<tabemann>
crc: this is more like daily releases
<tp>
tabemann, no I havent tried Zeptoforth in about a week as Ive been busy trying to finish a binary release of my own which is nearly done
<tp>
tabemann, but I always compile Zeptoforth as I like to read your changelog
<tp>
tabemann, I'm very interested to try your pictured numerical output so I can test a new svd2forth release on it
<tabemann>
the pictured numeric output is basically straight ANS
dave0 has joined #forth
<tp>
tabemann, I recommended a L476 to veltas so he can then try Mecrisp-Stellaris and Zeptoforth
<tp>
tabemann, nice work, you didnt take long to implement it
<tabemann>
the pictured numeric output itself was pretty simple
<tp>
and essential for my svd2forth
<tabemann>
a port of svd2forth to zeptoforth would certainly be cool
<tp>
ill definitely do one for you
<tp>
most of my work the last week has been fixing up the stack comments
<tp>
it at a stage where I'm not aware of any issues now
<tabemann>
I'm always not aware of any issues in zeptoforth, at least I run into them
<tabemann>
*until I
<tp>
yeah, hence crc's recommendation to release early and often
<tp>
then others will find the problems also
<tp>
my problem is I dont get much feedback
<tabemann>
for me making a release is some work, because I have to make zeptoforth_full binaries for both the L476 and the F407
gravicappa has quit [Ping timeout: 240 seconds]
<tabemann>
and this will become moreso in the future, as I support more boards
<tp>
tabemann, I'd release only major and bug fixes in binary
<tp>
any real forther will easily git-pull your work
<tabemann>
bug fixes are the most common for me; e.g. I only did two minor releases for zeptoforth
<tp>
hence release binaries infrequently
<tp>
one thing I dont understand is why a binary is so much work ?
<tabemann>
well... I'd prefer to catch bugs before too many users run into them
<tabemann>
so I'd do binary releases for bug fixes
<tp>
for me a binary is a single shell script command
<tabemann>
and as long as I'm doing those, I might as well also do them for minor releases, since there aren't too many of them
<tp>
I've automated everything
<tabemann>
well the creation of "full" binaries cannot be fully automated
<tp>
why ?
<tp>
you only have to grab the full dictionary and make it into a binary ?
<tp>
thats what I do
<crc>
tabemann: nothing wrong with that
<tp>
using the ihex upload etc
<tp>
tabemann, it's all scriptable
<crc>
Have a stable lik to pont to the latest release and advise people to use that
* crc
has hourly updates between releaee snapshots now
<tp>
tabemann, is your terminal unable to auto grab a log ?
<tabemann>
tp: screen is able to
<tabemann>
the question is how to make e4thcom scriptable
<tabemann>
as I am using e4thcom for code loading
<tp>
tabemann, yeah, e4thcom would be a problem I think
<tp>
crc, you do have a very slick and well organised system!
<tabemann>
okay, I'm gonna take a walk in a moment - I'll be back laater
<tp>
tabemann cya
<veltas>
crc: Why does your latest.tar.gz have two snapshots in it?
<veltas>
Oh no it doesn't I guess I already had it downloaded lol
<veltas>
that makes more sense
<crc>
it shouldn't...
<tp>
veltas, I hope your girlfriend is a lawyer with all the suing going on lately ? ;-)
<veltas>
tp: She's not my girlfriend she's my *fiance* :-P
<tp>
veltas, oops, apologies, I forgot!
<veltas>
I forgot I downloaded RETRO, and I have no idea why I did
<crc>
ok
<veltas>
I think maybe I was comparing forth implementations or something?
<crc>
perhaps
<crc>
I like automated snapshots and updates; my latest.tar.gz, html formatted examples, documentation, retro/native binaries, and retro-unix.c amalgamation are all rebuilt via a few simple cron jobs
<veltas>
crc: Hey what did you think of the SVFIG forth demo Chuck Moore did last year?
<tp>
crc, same here, I spent ages automating my projects
<crc>
veltas: watching now, thanks
<veltas>
Just wondering because he has a personal forth he demos there, which is different to colorforth but has some stuff from that
<tp>
crc, my philosophy is "automate wherever possible"
<veltas>
And I see in the retro docs that retro took some ideas/inspiration from colorforth
<crc>
tp: same philosophy here
<tp>
crc, apart from the possible massive time savings, some of my stuff must be automated to cut errors to zero
<tp>
crc, my svd2forth is one example, it's just not humanly possible to hand translate 2000 registers and 17,000 bitfields into Forth words
<veltas>
inkajoo: how is your game going?
<inkajoo>
coming along.. we ran into some really hairy bugs that took up the better half of the day, but we overcame and are now actually putting in the gameplay elements. you'll be playing a designated driver leading a drunk guy to the car.
<veltas>
Is it a team?
<tabemann>
back
TCZ has quit [Quit: Leaving]
<crc>
watching this, I see clear evolutions from the old x86 colorforth design, though I disagree with him regarding the usefulness of comments
<veltas>
crc: I really enjoyed watching it in here, his attitude, the stuff he came up with, whole thing
<veltas>
Can't say I agree with him either re comments but I don't think he was preaching
<veltas>
s/ in here//
MrMobius has quit [Ping timeout: 256 seconds]
MrMobius has joined #forth
<inkajoo>
it's me and a friend, yeah.
<veltas>
crc: Anything you liked in there?
<crc>
it's interesting to see what he's doing now; I was surprised that he's running under windows
<veltas>
I've got respect for a man that will segfault his demo like 10 times and shrug it off
<crc>
yeh, I'd have had a hard time dealing with that
[1]MrMobius has joined #forth
<veltas>
I think that I'd struggle because that would be considered very bad for me
<veltas>
But I think his own standards on his personal project seem to be "that is fine, working as intended, I typed the wrong stuff after all"
* crc
would likely have rehearsed a presentation lke this for a rather significant amount of time
<crc>
the use of super & subscripts in addition to colors is interesting
MrMobius has quit [Ping timeout: 264 seconds]
[1]MrMobius is now known as MrMobius
<veltas>
crc: c:consonant? and c:vowel?
<veltas>
Have you used those?
<veltas>
Also what is Dictionary usually called in forths? Or what are some names you've seen?
<veltas>
I have been struggling to figure out what I will call that
<veltas>
Well not struggling but I know somehow this is something almost all forths will have, just wondering what a conventional name for it is
<crc>
every word in my core system (except some of the ASCII: wprds) is used in more than one of my larger applications
<veltas>
Just wondering what kind of thing you'd use those for
<crc>
I've seen Dictionary named as `last` and `dp`. Not all expose dictionary in the same way
<crc>
I have various filtering words that use those. (E.g., I have used them in a text analysis tool when counting different character types)
<crc>
if I was using a hashed dictionary and not storing names, I might not have `Dictionary`, or it might be used in a different way