<veltas> I thought I'd add some of the dumb questions I had when I started
<veltas> But I get defensive on Stack Overflow like I'm going to get yelled at for not conforming to the standard
dave0 has quit [Quit: dave's not here]
jedb has quit [Ping timeout: 265 seconds]
jedb has joined #forth
zolk3ri has joined #forth
proteusguy has joined #forth
ptrkriz has quit [Ping timeout: 260 seconds]
ptrkriz has joined #forth
Zarutian_HTC has joined #forth
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
proteusguy has quit [Ping timeout: 260 seconds]
proteusguy has joined #forth
WickedShell has quit [Remote host closed the connection]
_whitelogger has joined #forth
gravicappa has joined #forth
jedb_ has joined #forth
jedb has quit [Remote host closed the connection]
sts-q has quit [Ping timeout: 240 seconds]
_whitelogger has joined #forth
hosewiejacke has joined #forth
sts-q has joined #forth
_whitelogger has joined #forth
hosewiejacke has quit [Ping timeout: 264 seconds]
_whitelogger has joined #forth
hosewiejacke has joined #forth
dave0 has joined #forth
<the_cuckoo> veltas: hmm - memmove - why would there ever need to be an intermediate buffer? isn't it just that you either copying while incrementing your pointers from the start, or decrementing from the end?
<the_cuckoo> i guess you'd lose some potential optimisations with that - like a worst case of memmove( ptr + 1, ptr, n ) would force you in a byte by byte copy rather than allowing 32 or 64 or 128 bit copies for aligned regions?
zolk3ri has quit [Remote host closed the connection]
xek_ has joined #forth
<veltas> the_cuckoo: The point is that it's "as if" there is an intermediate buffer, that's a way of thinking about it
<veltas> I don't know if anyone used to implement it that way, I imagine it's been relatively obvious that's unnecessary the whole time
<veltas> Maybe I should clarify that further somehow
gravicappa has quit [Ping timeout: 260 seconds]
<the_cuckoo> yeah - i don't really know what they would do either - i suppose there's a point where a small intermeirary buffer may allow for the types of mmx/sse/avx2/whatever type of optisimations, but i have no idea what they actually use
<the_cuckoo> veltas: either way, just thought your post was interesting and made me curious about that specific point :)
<veltas> Fair enough
<veltas> I think it might be worded that way in C standard, to make it clear what the requirement on handling overlapping memory is
<the_cuckoo> yeah - makes sense - it's definitely an easier way to visualise the special cases
<the_cuckoo> anything else would likely border on being implementation specific
hosewiejacke has quit [Ping timeout: 260 seconds]
jw has joined #forth
gravicappa has joined #forth
Gromboli has joined #forth
dave0 has quit [Quit: dave's not here]
jw has quit [Ping timeout: 260 seconds]
<siraben> Anyone know how to cross-compile gforth?
<siraben> Going from x86_64-linux to armv7l-unknown-linux-gnueabihf
<siraben> I get this error, `checking for gforth... echo "You need to configure with a gforth in \$PATH to build this part" && false`
xek__ has joined #forth
xek_ has quit [Ping timeout: 272 seconds]
Zarutian_HTC has quit [Remote host closed the connection]
jw has joined #forth
jedb_ has quit [Ping timeout: 256 seconds]
<veltas> siraben: Get an older copy of gforth and build that first
<veltas> It needs a copy of gforth to build itself 'from scratch'
<veltas> Or be like me and give up after the older one builds!
<siraben> Ok, sounds like a plan!
<veltas> "Use rock to break glass to get rock"
jw has quit [Ping timeout: 240 seconds]
jw has joined #forth
ggVGc has joined #forth
ggVGc has quit [Changing host]
jw has quit [Ping timeout: 256 seconds]
jw has joined #forth
Zarutian_HTC has joined #forth
jw has quit [Ping timeout: 240 seconds]
<lispmacs[work]> I made this little blog post about solving a puzzle with Forth:
<veltas> Reading it now
<veltas> I might recommend defining a word to make constructing the arrays a bit easier, so you can write e.g. C{ 1 2 3 4 5 }
<veltas> And have it execute any words that aren't numbers, so you can define e.g. : HOLE -1 C, ;
<veltas> I think if I had attempted this I would have tried keeping the rotation as a variable for each disc, and then provide words to lookup each location's current value based on those variables
xek has joined #forth
<veltas> Because although moving them around in memory is simple in concept, I don't know if it's any easier to code, and it's seems like it's less efficient
xek__ has quit [Read error: Connection reset by peer]
<veltas> That really sucks that the one you had was wrong! What a bad puzzle
<veltas> dup 0<> if ... else drop then I think can be replaced with ?dup if ... then
WickedShell has joined #forth
jw has joined #forth
<veltas> Sorry I mean 'endif' instead of 'then'
jw has quit [Client Quit]
<lispmacs[work]> veltas: I don't quite have the energy to go tweaking that article, but if you wanted to make any comments on the blog post with recommended optimizations, it would be appreciated
<lispmacs[work]> so everybody could learn
<veltas> I don't expect or require anything, just telling you in case you are interested since you went to the effort of writing the post
<veltas> You don't need to change it
<veltas> I can change it if I want, it's GPLv3 after all
<lispmacs[work]> of course, but if you feel inspired to share anything in the comments on better ideas or coding practice, the world would be a better place for it I'm sure
<lispmacs[work]> for learning purposes
<lispmacs[work]> probably there are at least a few bad examples of beginning forth coding in that article
<veltas> I have shared your post on Twitter although I doubt anyone will look at it because of me
<veltas> I can leave a comment
<lispmacs[work]> thanks - I won't be offended by any criticism or better ideas you drop into the comments
<lispmacs[work]> unless you insult my mother
<lispmacs[work]> I would take that personally
<veltas> I generally assume people are okay with a code review if they post code online
gravicappa has quit [Ping timeout: 265 seconds]
<veltas> I don't know why I wrote : -1 hole ; instead of -1 hole constant
<veltas> Er : hole -1 ;
<veltas> Oh I know why, I didn't write that I wrote -1 C, in there, that makes sense
<veltas> Anyway I added a comment, you now have a blog post with a comment! Also I just realised our real names are quite similar.
gravicappa has joined #forth
<veltas> I was confused because I thought I read my own name on the copyright for a split second
<lispmacs[work]> thanks!
<veltas> I'm sure some people are sensitive about it initially but personally I always want critique, if I know a better way or at least know someone doesn't like what I've done it's valuable info
<lispmacs[work]> I would really like to try this out, but there is a problem with one of the Makefiles preventing me from fully building it:
<lispmacs[work]> I contacted the author, he responded, but said he hadn't tried building the code in a few years
<veltas> What's the problem?
<lispmacs[work]> it is on my home computer, but it was an issue where make said it didn't have instructions on how to build a certain rule
<lispmacs[work]> or a certain object file, I think
<lispmacs[work]> I suspect that maybe something changed in the make software behavior since it was last built two years ago
<lispmacs[work]> but I'm not sure what version of make he was using originally
<lispmacs[work]> if anyone here can get it built, I'd be quite interested in know what versions of make, etc. that you used.
<MrMobius> make :/ gross
<the_cuckoo> paraphrasing the error isn't perhaps the right way for us to understand what the issue was
<lispmacs[work]> I'm sorry, I don't have the environment and files set up here at work
<the_cuckoo> ok - and did you try building the linked barebones-toolchain stuff?
<lispmacs[work]> no, I used his pre-built toolchain. The code itself was all building fine, but the make process dies when make doesn't know how to build one of the object files
<lispmacs[work]> I think it was something in the kernel directory
<lispmacs[work]> to clarify, I was using his pre-built toolchain, but building by-ok source
<the_cuckoo> hmm - not sure i want to dig too deep just now (machine at hand being stuff i'm doing work stuff on)
<veltas> I am trying to build it
<lispmacs[work]> thanks
dave0 has joined #forth
xek has quit [Ping timeout: 264 seconds]
<veltas> MrMobius: what would you suggest instead of make?
gravicappa has quit [Ping timeout: 272 seconds]
<veltas> Because I sort of agree but also I don't know a better tool for what it does
<inode> lispmacs[work]: https://pastebin.com/d5DyjTD3
<inode> i'm not a fan of using random toolchains for once-off builds, so that patch to include the static libraries when byok.kernel is linked is all i needed to change to use the version of i686-linux-gnu-gcc listed there
<veltas> Good that you did it because I am now making bacon instead
<veltas> I absolutely agree about the i686 gcc
<inode> bacon sounds like a much better goal to work towards
<MrMobius> veltas, what sized project? for small ones, make is not worth the trouble
<MrMobius> i had shenanigans trying to get a 6502 forth to build on windows
<MrMobius> turns out the lunix and windows versions are not identical
<MrMobius> the linux version ignores semi colons (they serve no purpose) and the windows version crashes and dies
<inode> MrMobius: which implementation of make was that?
<MrMobius> who knows. i unistalled it after that
<MrMobius> the last time I used it before that was 2014 for an mcu with 32k flash
<MrMobius> not sure why you need a 100+ line make file for that
<MrMobius> I replaced it with a 2 line batch script
<lispmacs[work]> inode: thanks. did that run successfully in qemu?
<inode> lispmacs[work]: at face value, yes
<veltas> MrMobius: The opposite I find is true, make (if you are proficient) is nice and trivial for small projects and doesn't scale
<veltas> The Windows/Linux differences in make are the fault of Microsoft primarily, I've used their make and it has lots of weird MSisms
<lispmacs[work]> inode: what version of make are you running, or which version of Debian?
<MrMobius> what is the point though? it takes 2 second to compile a 32k flash image. no need to clean and figure out what's what at link time
<MrMobius> i could see using if it took you a long time to compile every time or something
<veltas> The feature of make is not helpful, but the automatic rule writing in gmake makes it shorter than a build.sh
<inode> lispmacs[work]: GNU Make 4.1 on Devuan ascii
<veltas> You are right that the dependency graph is pointless in a small project, and in a large project it's useful but make doesn't scale well on those projects IMO
<veltas> So you think bash is the right replacement? I haven't really had an opportunity to try. Do you have an example I can see?
<veltas> I might use that as inspiration at work, don't tend to have 'big' projects at home
<inode> lispmacs[work]: i didn't test i very much, WORDS lists a bunch of names. : works, but SEE doesn't seem to disassemble code words though it workd for colon words. also HELP is missing dispite the splash disclaimer though LICENSE is available.
Filipp888 has joined #forth
<MrMobius> veltas, on windows I just make a batch file with one line for the compiler, one for the linker, and one for copying the result to the simulator or flashing the mcu
<MrMobius> and then other optional debug stuff if you want to see how much space the image takes
<veltas> Preferably for larger projects
<lispmacs[work]> inode: okay, but it "boots up". thanks
<lispmacs[work]> i'll plan to try that at home again hopefully this evening
<the_cuckoo> make will always win for me over a shell script - seems strange to even make the comparison (unless you're talking about a couple of source files, in which case, meh - who cares?)
<veltas> That is your opinion! I find make's usage tedious on medium size projects, where it is meant to shine, and you admit it is 'pointless' on smaller ones
<veltas> make was written back when you were happy if you had a tool that could only build 1 instead of 3 source files with one command
<inode> isn't that where you'd consider using autotools when make alone gets kludgy? the obvious auto{conf,reconf,make} bloat aside
<veltas> I don't think anyone's done a good job extending the core of make's syntax for more automatic rules across different directories
<veltas> autotools are horrific, and so is cmake. It's true that's the direction people conventionally go in when make gets clunky
<the_cuckoo> sure - there's never a case of one tool fits all, but make for a multi file/multi library/executable project is pretty cool - not ideal for multiple libary in their own project thing.. needs external stuff like pkg-config for that kinda thing
<veltas> Yes I happen to think Make works best with a small number of files, but apparently that's not a universal opinion
<veltas> I write 2-3 line makefiles in GNU make that build one-directory projects for one platform usually, that's much shorter and sweeter than anything else can do.
<the_cuckoo> stuff breaks at the edges as you span multple projects - there's no good solution for that (cmake isn't bad for c++ stuff, but sucks badly for everything else)
<veltas> Well autotools and cmake are designed to solve that problem, but I don't think that's even where the cracks form
<veltas> I think just *large* projects with basically no dependencies still have chronic issues from using make
<the_cuckoo> automake is just awful though
<veltas> automake and cmake are revolting as far as I can tell
<inode> awful due to the fact that it uses m4 or for the quality of the stubs that it generates?
<the_cuckoo> i wouldn't disagree - cmake fits a particular niche, but outside of that... it's a mess
<veltas> We need linus torvalds or someone to solve the big make problem
<the_cuckoo> hmm - but torvalds gave us git, and i'm not sold on that one.. hg was/is better
<the_cuckoo> (and it's not perfect either :))
<veltas> git's better than other systems I used before, like svn and p4
<veltas> (I still have to use p4 at work :( )
<the_cuckoo> yeah - no competition with those
Gromboli has quit [Quit: Leaving]
<the_cuckoo> ugh
<the_cuckoo> have done cvs, svn, bzr, hg, git.. i hated all of them, but learnt to respect hg
<veltas> My benchmark for version control is "would I be in a better situation right now with tarballed versions of my code"? If yes then it's no good
<the_cuckoo> heh - i think in all cases, i'd rather have a bad repo, but i can see where you're coming from :)
[1]MrMobius has joined #forth
MrMobius has quit [Ping timeout: 256 seconds]
[1]MrMobius is now known as MrMobius
<veltas> "Would I be in a better situation right now with COPY'd versions of my block?"
<veltas> > No external libraries or dependencies
Filipp888 has quit [Ping timeout: 272 seconds]
jedb has joined #forth
WickedShell has quit [Remote host closed the connection]