cantstanya has quit [Remote host closed the connection]
cantstanya has joined #forth
rdrop-exit has joined #forth
WickedShell has joined #forth
<rdrop-exit> (-_-)zzz c[] good morning Fortharians
TCZ has quit [Quit: Leaving]
karswell_ has joined #forth
<crc> hi rdrop-exit
<rdrop-exit> hi crc!
karswell_ is now known as karswell
iyzsong has joined #forth
iyzsong has quit [Ping timeout: 260 seconds]
Zarutian_HTC has quit [Ping timeout: 256 seconds]
Zarutian_HTC has joined #forth
TCZ has joined #forth
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
<tp> g'day rdrop-exit
<tp> all is well on the Forthen front
<rdrop-exit> excellent Major tp, jolly good
TCZ has quit [Quit: Leaving]
corn has joined #forth
<corn> good evening, #forth fanatics
<rdrop-exit> hi corn
<corn> how's your morning
<rdrop-exit> good, relaxing with a cup of coffee and some books
<corn> I try to stay away from coffee
<rdrop-exit> "One doesn't write programs in Forth, Forth is the program." -- Chuck Moore
SandboxGeneral has joined #forth
<corn> When/where did he say that?
<rdrop-exit> "... in those days software was exciting: things being done for the first time; programmers working 18 hour days for the joy of it. Now programming is a 9-5 job as part of a team working to a schedule; not much fun." -- Chuck Moore
<rdrop-exit> corn, in the interview that's part of O'Reilly's Masterminds of Programming book
<rdrop-exit> The interview has two parts, hardware and software, I believe a pdf of the software half is available online.
<rdrop-exit> IIRC
<corn> Ah I think that's familiar
tabemann has joined #forth
<rdrop-exit> "The ability to do anything and not the ability to do everything."
<rdrop-exit> cool
<tabemann> hey
<rdrop-exit> hi tabemann
<rdrop-exit> "More important than the compiler is the editor."
<rdrop-exit> actually, I misremebered, the interview doesn't have two halves, it has various sections, including one on hardware
<rdrop-exit> "Comments do not substitute for proper documentation. A document must be written that explains in prose the code module of interest. It should expand greatly the comments and concentrate on literate and complete explanation."
<corn> I do think literate programming is a suitable replacement for documentation, I am a big fan of literate programming
dave9 has quit [Quit: dave's not here]
dave9 has joined #forth
<rdrop-exit> I wouldn't call anything a "replacement for documentation", if done right it should result in proper documentation. In the case of Knuth's "TeX: The Program" book he certainly did produce quality documentation using literate programming.
reepca has quit [Read error: Connection reset by peer]
reepca has joined #forth
<rdrop-exit> This one reminds me of IBM's mainframe strategy in their heyday:
kori has joined #forth
kori has quit [Changing host]
kori has joined #forth
<rdrop-exit> "sell hardware and give away the software"
<corn> literate programming can be a replacement for "A document ... that explains in prose the code module of interest" because it includes, in prose, the module of interest, without a separate document. If it's replacing the important part(the fact that the module is explained in prose) then unimportant parts like documentation being separate can be reasonably forgotten
<rdrop-exit> It replaces a document, it doesn't replace documentation, it either results in proper documentation if done well, or not if done badly.
<rdrop-exit> I think your conflating document and documentation.
<rdrop-exit> * you're
SandboxGeneral has left #forth ["Leaving"]
<corn> I was referring specifically to Chuck's explanation of what proper documentation requires, and his explanation called for a document to contain the documentation
<corn> I'm just saying the second document is not needed
<rdrop-exit> Ah ok, I get your point and agree.
<rdrop-exit> Done with that article, on to chose something else from my reading pile (mountain).
<corn> I wonder if there's a collection of interviews/publications/etc of Chuck's, it's always a good read when I find ones I haven't seen before
<rdrop-exit> Not a complete one, but Jeff Fox's (RIP) had lots on his ultratechnology site.
<rdrop-exit> Some of what he has are transcripts, some are his Jeff's interpretation of the "Forth way".
<rdrop-exit> Jeff's writing style was all over the place though
<corn> I remember him putting a lot of (often bad) humor into stuff he wrote
<rdrop-exit> His writing was emotional and repetitive, but there were nuggets of good food for thought in some of his writings
<corn> Ah, like on his bio page, right away, he says he was "raised by foxes," due to his last name
<rdrop-exit> Michael Misamore produced a more coherent summary of Jeff's Thoughtful Programming writings
<rdrop-exit> Here's a copy I just Googled:
proteus-guy has quit [Ping timeout: 246 seconds]
<tabemann> Forth provides a way of creating non-trivial systems that one, as an individual, can understand the whole of, top to bottom
<tabemann> everything else is too complex to fully understand or too simple to provide sufficient power to express what one needs
<tabemann> like in my Haskell phase there was no way that I, as an individual, could really understand what GHC was doing
<corn> I'm not sure that you can say the second statement
<corn> I think that statement is bogus, but the other two I agree with
<rdrop-exit> "The goal was very simple: to minimize the complexity of the hardware software combination. As far as I can see no-one else is doing that." -- Chuck Moore
<corn> I wonder how Chuck navigates the definition of complexity
<corn> because that is itself quite a challenge
<corn> I choose to just embrace what feels right and reject what feels wrong, and use that is my separator between simple and complicated, but my approach is not very objective
<tabemann> I've never met a compiler for any other language that I truly understood how it worked
<tabemann> for the longest time I treated compilers as black magic
<corn> but "never met" does not mean it can't or doesn't exist
<corn> I think plenty of paradigms, when reduced to their essentials, could be implemented in an entirely understandable way
<corn> It's more complicated than a forth, but I think that a solid implementation of smalltalk could fit that bill
<tabemann> well, there are some languages that might be comparable to a degree
<tabemann> such as a very simple implementation of Scheme with a very simple garbage collector
<tabemann> but even that is more complex than Forth
<rdrop-exit> you lost me at garbage collector :)
<tabemann> exactly
<corn> why quit the moment you hear garbage collector?
<corn> garbage collector does not somehow imply complication
<tabemann> because GC's result in non-deterministic behavior
<rdrop-exit> Is the GC optional?
<corn> non-deterministic also does not imply complicated
<tabemann> rdrop-exit: the alternative is allocating memory until you crash from running out of memory
<rdrop-exit> then don't
<rdrop-exit> It's one thing having a GC because your application inherently requires one, it's another to have it because your language imposes it on you
* tabemann tried writing a scheme - he quickly gave up because even such a simple language as scheme was too complex for him to bother
<corn> languages will always impose something on the author of a program, that's inevitable
<tabemann> rdrop-exit: I think the key factor with scheme is whether numbers are boxed or not
<rdrop-exit> and Forth imposes almost nothing that I wouldn't want, i.e. 2 stacks
<tabemann> if numbers are unboxed, you can theoretically write a scheme program that runs in constant memory space without GC
<corn> the "that I wouldn't want" portion of your statement is nearly arbitrary
<rdrop-exit> of course not
<corn> and I could reasonably have a different conception of what is unwanted, so other languages could reasonably fit into the accepted category
<tabemann> it's almost impossible to get away from having one stack in a programming environment - a second stack is a bonus, because it allows you to treat some things (data) separately from other things (return addresses)
<tabemann> not impossible, of course
<tabemann> since when programming in a language without subroutine calls stacks are not necessary
<tabemann> but no subroutine calls are such a restriction that I can't see any way it would be desirable
<corn> I think another important thing to take into consideration is that hardware affects what software is simple, and we usually deal with register/stack machines that forth will appear well suited for
<corn> but register machines are honestly quite complicated things in comparison to some other machines
<rdrop-exit> That's why Chuck focuses on the combination of hardware and software
<rdrop-exit> Chuck doesn't just focus on surface simplicity, he's after simplicity all the way down
<corn> And one of the biggest reasons I wanted to disagree with tabemann's statement above is the importance of the combination, and that I find it highly unlikely that forth is the ONLY combination of hardware and software with both reasonable hardware and software
<corn> and you likely won't have seen many examples that fit the criteria, because me, tabemann, everybody is doing a LOT more experimenting with radically different software architectures than with radically different hardware architectures
<tabemann> to me at least one can have simpler systems, but they all come at the cost of expressiveness and power
<corn> I think complicated problems like this tend to have multiple simple solutions if they have any
<corn> I suspect that a cleverly concocted automata based language could have similar complexity and expressive power to forth
<tp> hey tabemann, news CRC mentioned that Hashforth compiled fine on his openbsd so I had another go building Hashforth, Gmake worked perfectly first time, dunno what I did wrong last time, I expect I didnt read the notes and just executed hashforth saw 'no image' and moved on
<tp> tabemann, so hashforth builds and runs easily on freebsd
<tabemann> cool
<tp> tabemann, and your tip on adding swap after the 'fall thru' in CASE fixed a few problems I had in my code :)
<tabemann> cool as well
<corn> tp: I watched one of your YouTube videos, you have the voice of an Australian pilot
<tabemann> what I really think is there should be a DEFAULT word for handling fall through in CASE
<tp> tabemann, using Hashforth without a prompt of dictionary is a bit weird for this poor Forth user
<tabemann> because the standard way of doing is frankly quite ugly
<tp> well I was lost by the fall thru problem for years
<tabemann> tp: I should add something to hashforth to make it automatically look for the image in certain locations
<tp> lol, so I add the fall thru message and what did I get ?
<tp> "jump too far"
<tabemann> to me when zeptoforth complains about too far of a jump what it really means is that the compile-time stack is corrupted
<tp> putting the fall thru stuff in another word was a good idea as I use it 4 times elsewhere in this app anyway
<tp> tabemann, because you use M4 ?
<tabemann> yeah
<tabemann> well, I should get to bed
<tp> I only use cortex-m0 as you know. tho I need to alter my M3 code as well
<rdrop-exit> corn, I hope you find what you're looking for, as Chuck says "show me a simpler way to do anything that I'm doing, I will jump on it".
<tabemann> but cool that you got hashforth working
<tp> night-o tabemann
<corn> well I got a lotta years left to look for it
<rdrop-exit> goodnight tabemann
<tp> rdrop-exit, nice notes, agree entirely, this forther loves simplicity
<rdrop-exit> cool
<rdrop-exit> "It must be wonderful to be seventeen, and to know everything." -- Arthur C. Clarke
<tp> thats not true, I have a sister who also knows everything and she is in her 70's
<rdrop-exit> she probably has known everything since she was 17
<tp> probably before then
<tp> I think ghod gave her this special gift
<rdrop-exit> I've raised four like that
<rdrop-exit> lunch is ready, catch you later, stay healthy :)
rdrop-exit has quit [Quit: Lost terminal]
<tp> cya
karswell has quit [Remote host closed the connection]
karswell has joined #forth
gravicappa has joined #forth
<veltas> My fall through message needs to be "aim for the bushes"
rprimus has joined #forth
jedb_ has joined #forth
jedb has quit [Ping timeout: 244 seconds]
dddddd has joined #forth
iyzsong has joined #forth
proteusguy has quit [Remote host closed the connection]
proteusguy has joined #forth
WickedShell has quit [Remote host closed the connection]
jsoft has joined #forth
rprimus has quit [Quit: Lost terminal]
rprimus has joined #forth
rprimus has quit [Client Quit]
TCZ has joined #forth
rprimus has joined #forth
TCZ has quit [Quit: Leaving]
karswell has quit [Remote host closed the connection]
karswell_ has joined #forth
karswell_ has quit [Read error: No route to host]
TCZ has joined #forth
jedb_ is now known as jedb
corn has quit [Ping timeout: 260 seconds]
iyzsong has quit [Quit: ZNC 1.7.1 - https://znc.in]
Zarutian_HTC has quit [Ping timeout: 240 seconds]
Zarutian_HTC has joined #forth
TCZ has quit [Quit: Leaving]
TCZ has joined #forth
TCZ has quit [Quit: Leaving]
dddddd has quit [Remote host closed the connection]
WickedShell has joined #forth
dave0 has quit [Quit: dave's not here]
karswell_ has joined #forth
karswell_ has quit [Remote host closed the connection]
karswell_ has joined #forth
jsoft has quit [Ping timeout: 258 seconds]
gravicappa has quit [Ping timeout: 264 seconds]
TCZ has joined #forth
Kumool has quit [Quit: FreeZNC - Visit us! Server: chat.freenode.net Channel: ##bnc4you]
Kumool has joined #forth
_whitelogger has joined #forth
ornxka has joined #forth
klys has joined #forth
kori has joined #forth
TCZ has quit [Quit: Leaving]
TCZ has joined #forth
Zarutian_HTC has quit [Read error: Connection reset by peer]
Zarutian_HTC has joined #forth
tp has joined #forth
tp has joined #forth
tp has quit [Changing host]
karswell_ has quit [Read error: Connection reset by peer]
TCZ has quit [Quit: Leaving]
<tabemann> hey
<tp> hey tabemann
<tabemann> the disassembler is at ~750 lines
<tabemann> and currently covers instructions up through 'B'
<tp> wow
<tabemann> if each of those lines corresponded to a single 16-bit instruction
<tabemann> that means that i'd take up 1500 bytes
<tabemann> *it'd
<tp> i note that the mecrisp dissasembler only covers a small number of instructions, maybe 20% ?
<tp> same as the assembler
<tabemann> these are significant instructions, though
<tp> even GCC only uses about 20% of instructions
<tabemann> there's plenty of stuff I'm not going to implement
<tabemann> like the floating point stuff
<tp> yeah, lots of instructions never get used
<tabemann> and a lot of the math routine stuff
<tp> 750 lines of assembly ?
<tabemann> no, 750 lines of Forth
<tp> aha
<tabemann> it certainly will take up way more than 1500 bytes for just this
<tp> heheh, youd be at 75 lines of assembly by now ?
<tabemann> this is why I question whether this is a good idea
<tp> all useful forths have a 'see' which requires a dissembler
<tp> so obviously lots felt it is a good idea
<tp> of course, this is YOUR forth, it's your choice
<tabemann> the problem is that cortex-m seem to have a quite complex instruction set
<tabemann> I'm probably going to continue with work on at least the important instructions, even though it's going to eat up a ton of flash
<tp> the Mecrisp-Stellaris M3 dissasembler is 19k of Forth code
<tabemann> that might give me a good picture of how much space it will take
<tabemann> but of course, mecrisp-stellaris is probably more efficient than zeptoforth in the code it compiles...
<tp> it will be for sure with the RA version which I use
<tp> tabemann, here is the m3 disassembler http://dpaste.com/1R4BYF5