2024-11-21 09:32:21 <lilo_booter > is there a simple way to override the (annoying) ok prompt in gforth?
2024-11-21 11:14:10 <TactfulCitrus> KipIngram: Thanks for the advice. At the moment just trying to learn Forth by building a maths library. My background is in neural nets and physical simulations of blood flow and more recently MRI so I thought I'd start at the bottom and work my way up
2024-11-21 11:15:36 <TactfulCitrus> Doing either blood flow or MRI simulations in Forth would be cool but I'm not sure if I'd have the time. This started because I wanted to do advent of code in forth as a learning exercise, started on preparing some utility functions and then got side tracked with starting writing a matrix algebra library
2024-11-21 11:16:46 <TactfulCitrus> xentrac: That's a great idea! Why store the pointer though? Is it so you can copy the matrix without having to copy the data?
2024-11-21 11:19:45 <TactfulCitrus> Bare bones at the moment with just dot product, element addition and shape equality and shape conformity checking along with some tests
2024-11-21 12:25:18 <TactfulCitrus> How do I dynamically get a memory address within a word definition?
2024-11-21 12:26:21 <TactfulCitrus> m-init ( addr1 m n rs cs --- addr2 ) ( ... ) ;
2024-11-21 12:27:20 <TactfulCitrus> something like that with an addr initial address, row size,  column size, row stride, column stride and then get the address to the data field back?
2024-11-21 12:27:57 <amby        > is that for indexing a 2d array?
2024-11-21 12:28:43 <TactfulCitrus> Yes, the idea would be to create an array with the format ( rows cols rstride cstride data ) where data is the pointer to the data
2024-11-21 12:29:37 <amby        > indexing or creating?
2024-11-21 12:31:22 <TactfulCitrus> Not necessarily interested in returning the data pointer but it would be handy to have it dynamically generated in the word definition rather than passing an additional address for the data in the input
2024-11-21 12:31:22 <TactfulCitrus> Sorry, creating
2024-11-21 12:31:24 <TactfulCitrus> Thanks! So I would do something like this? m n * cells here +
2024-11-21 12:34:15 <amby        > HERE @ TUCK + HERE !
2024-11-21 12:34:47 <GeDaMo      > Or you could just use allot
2024-11-21 12:35:10 <GeDaMo      > https://forth-standard.org/standard/core/ALLOT
2024-11-21 12:35:18 <amby        > hey i wonder what allot does
2024-11-21 12:37:32 <amby        > although for some reason the standardised version of allot doesn't return the old value of HERE
2024-11-21 12:37:38 <amby        > which is. very strange
2024-11-21 12:42:21 <TactfulCitrus> So it would be something more like: here addr 4 cells + ! here m n * cells allot
2024-11-21 12:42:36 <TactfulCitrus> assuming addr m n are local variables
2024-11-21 13:16:05 <zelgomer    > typical use is  create foo 20 cells allot
2024-11-21 13:31:54 <amby        > 20 CELLS ALLOT CONSTANT FOO
2024-11-21 13:32:17 <zelgomer    > : n ( a-u)  cell- @ ;  : m ( a-u)  cell- cell- @ ;  : rs ( a-u)  -3 cells + @ ;  : cs ( a-u)  -4 cells + ;  : matrix ( n m rs cs -- a)  , , , , here  n rs *  m cs *  * allot ;
2024-11-21 13:32:50 <zelgomer    > amby: that's not the same thing
2024-11-21 13:33:20 <amby        > CREATE works differently in the standard to in jonesforth
2024-11-21 13:33:39 <amby        > so i'm not too familiar with the """correct""" behaviour
2024-11-21 13:35:52 <zelgomer    > TactfulCitrus: see above
2024-11-21 13:36:11 <amby        > in jonesforth CREATE takes a string on the stack and literally just creates a dictionary header
2024-11-21 13:36:29 <amby        > link pointer, length/flags byte, name
2024-11-21 13:36:52 <zelgomer    > and what in the code field?
2024-11-21 13:36:59 <amby        > nothing
2024-11-21 13:37:07 <amby        > you populate that yourself after calling create
2024-11-21 13:37:38 <amby        > for example : starts WORD CREATE DOCOL ,
2024-11-21 13:38:20 <TactfulCitrus> Thanks very much guys
2024-11-21 13:39:17 <zelgomer    > TactfulCitrus: my matrix definition should probably start with an align, btw
2024-11-21 13:39:33 <TactfulCitrus> Why align?
2024-11-21 13:40:09 <zelgomer    > so that the metadata cells are properly aligned
2024-11-21 14:19:10 <KipIngram   > amby: I'm mostly familiar with older Forths, but I've never expected ALLOT to return anything at all.
2024-11-21 14:19:24 <KipIngram   > I get HERE before I run ALLOT and use that.
2024-11-21 14:20:49 <KipIngram   > TactfulCitrus: Some processors need data to be aligned so that a fetch doesn't straddle across hardware word addresses, but even on processors that will do the multiple fetches as required to give you what you asked for, it's more efficient to use just oen fetch than multiple.  That's the sort of situation where alignment comes in handy.
2024-11-21 14:21:17 <TactfulCitrus> Thanks very much - makes sense
2024-11-21 14:21:46 <KipIngram   > On those less capable processors fetching something not aligned would cause an exception or something.
2024-11-21 15:20:11 <crc         > lilo_booter: I'm not aware of any simple approach for this. You could try changing the definition in kernel-ec/int.fs & rebuilding
2024-11-21 15:48:13 <lilo_booter > crc: ok - thanks - i was thinking that i wouldn't mind just looping on a means to read stdin to a string and build my own parser (eventually - for now, i'd probably just hack with an evaluate and hope the user doesn't leave the stack in a crappy state :))
2024-11-21 15:48:45 <lilo_booter > (the user being me of course)
2024-11-21 16:56:35 <lilo_booter > fwiw, valgrind is useful for identifying memory leaks and out of bounds access issues with gforth - it obviously isn't going to give me line number info, but generally i don't need that - the main issue is "definitely lost" and that seems to correlate with interpreted strings (compare 's" this is a test" type' with 's" this is a test" 2dup type drop free')
2024-11-21 16:57:21 <lilo_booter > the docs definitely point this behaviour out
2024-11-21 16:59:15 <lilo_booter > the problem is of course that you a word given a string cannot possibly know if they have received the last reference to it as there's no concept of reference counting or garbage colleciton
2024-11-21 17:01:17 <lilo_booter > and of course, compiled strings should not be freed, and again, there's no way for a word to distinguish that either
2024-11-21 17:08:50 <lilo_booter > you could define two words - like type and type-free - where the second would be like : type-free 2dup type drop free ; and then at least it would be the caller's responsibility to get it right
2024-11-21 17:09:26 <lilo_booter > or is all of that completely off base and i'm still missing something about them?
2024-11-21 19:45:30 <lilo_booter > https://gitlab.com/lilo_booter/plotify/ <- thought i may as well push it to gitlab :D - breshenham is implemented but i haven't tied it into the x-loop or y-loop words yet - the entry point to that is line-draw (takes a pair of terminal col/row coords) - there's also xy-circle takes x y r args (custom functions for these types of functions will come later .. maybe)
2024-11-21 19:48:13 <lilo_booter > there's also x-loop-xt - the string cat thing is just an option (i did go for the free/no-free distinction for the string thing, but obviously no issue with manual use of :noname)
2024-11-21 21:16:35 <veltas      > Don't type SEE XT-SEE in gforth
2024-11-21 21:16:40 <veltas      > I found out today
2024-11-21 21:17:10 <lilo_booter > see in gforth often brings the whole thing to a grinding halt :D
2024-11-21 21:19:31 <veltas      > Yeah in the ancient last released one it does
2024-11-21 21:19:47 <veltas      > It's especially bad with code words
2024-11-21 21:19:51 <lilo_booter > ah - still on ubuntu 22.04 here
2024-11-21 21:22:34 <lilo_booter > 
ACTION does the happy dance as breshenam's slots into place

2024-11-21 21:24:50 <lilo_booter > no idea how i'm supposed to deal with ftan - but it looks cool depite being wrong :)
2024-11-21 21:31:46 <TactfulCitrus> lilo_booter: Love the plotting library!
2024-11-21 21:32:57 <lilo_booter > TactfulCitrus: ah - thanks :) - that really is much appreciated :)
2024-11-21 21:36:01 <TactfulCitrus> I'm sure I'll make use of it in the future
2024-11-21 21:36:25 <TactfulCitrus> Although I'm not using the fp stack atm
2024-11-21 21:38:29 <lilo_booter > you're quite welcome to do what you want with it - i slapped an mit license on it, but i was havering between that and the WTFPL tbh :)
2024-11-21 21:39:33 <lilo_booter > i do think it would be worth trying to see what happens if i slap sdl in there - rendering in 4k could be fun
2024-11-21 21:43:21 <TactfulCitrus> I pretty much exclusively license all of my stuff with GPLv3
2024-11-21 21:43:35 <TactfulCitrus> Aha 4k would be brilliant
2024-11-21 21:44:52 <TactfulCitrus> Could potentially do animations with sdl?
2024-11-21 21:46:41 <lilo_booter > possibly.. definitely matrix transforms should be doable
2024-11-21 21:47:41 <lilo_booter > no idea what possible use they would have... but that's never stopped anyone from developing anything
2024-11-21 21:49:43 <lilo_booter > this is all kind procrastination though - i have a much larger project which i'm itching to drop ...
2024-11-21 21:50:54 <veltas      > lilo_booter: In the latest gforth snapshot PROMPT is a defer'd word, so you can redefine it in a live system
2024-11-21 21:50:57 <veltas      > PROMPT is called after interpreting a line, and prints 'ok' or 'compiled' depending on STATE
2024-11-21 21:52:15 <veltas      > In gforth 0.7.3 PROMPT is a regular colon word so as far as I know you can't do that
2024-11-21 21:54:14 <lilo_booter > excellent :)
2024-11-21 21:54:24 <veltas      > I strongly suggest building latest gforth snapshot (which you need gforth 0.7.3 to build)
2024-11-21 21:54:32 <veltas      > Because it's just a lot better than 0.7.3
2024-11-21 21:54:48 <lilo_booter > i have ubuntu 24.04 on the laptop and see what it offers before building locally
2024-11-21 21:54:59 <veltas      > I think snap might have a newer snapshot
2024-11-21 21:55:05 <veltas      > I seem to remember someone saying
2024-11-21 21:55:07 <lilo_booter > ok - good to know
2024-11-21 21:55:18 <lilo_booter > you a gforth dev?
2024-11-21 21:55:33 <veltas      > No I actually think I'm blacklisted by gforth's devs :P
2024-11-21 21:55:53 <lilo_booter > uh oh :)
2024-11-21 21:58:56 <TactfulCitrus> How come the snapshots are so far ahead of the current release?
2024-11-21 21:59:04 <TactfulCitrus> Snapshots look like there on 7.9
2024-11-21 21:59:34 <veltas      > I think 0.7.3 is like 15+ years old now, I don't know, I've moaned about this before on here
2024-11-21 21:59:40 <veltas      > I should moan less really, though
2024-11-21 21:59:53 <lilo_booter > :)
2024-11-21 22:00:22 <veltas      > I think I remember reading on a mailing list that they're waiting for 1.0 before next release, and want to improve docs before doing that release
2024-11-21 22:00:57 <veltas      > I personally think they should just release what they have now, because we're at diminishing returns trying to 'polish' it when we've had no official release for well over a decade
2024-11-21 22:00:58 <TactfulCitrus> I guess the downside of building against 0.7.9 is that most people would be using 0.7.3 - unless theres no breaking changes?
2024-11-21 22:02:45 <TactfulCitrus> veltas Completely agree there! Otherwise whats the point in the 15+ years of development?
2024-11-21 22:03:08 <veltas      > I think it's a labour of love
2024-11-21 22:03:30 <veltas      > Maybe you can release something with gforth bundled, but maybe GPL would get in way of that(?)
2024-11-21 22:03:33 <TactfulCitrus> But to FLOSS is to share that love
2024-11-21 22:03:48 <lilo_booter > .. i can kinda appreciate the hessitance tbh
2024-11-21 22:03:51 <veltas      > It's out there, it's just not relased
2024-11-21 22:04:11 <TactfulCitrus> I might create an ebuild so I can play around with it
2024-11-21 22:04:33 <veltas      > Perfect is the enemy of the good, as I say
2024-11-21 22:05:01 <lilo_booter > well, yes.. but .. it doesn't help to crash and burn :)
2024-11-21 22:06:09 <TactfulCitrus> I think if there's major performance concerns with the latest pre-leases then I get you but if its just docs and tidying then I can't see why one would put it off ...?
2024-11-21 22:07:25 <lilo_booter > there's always one more tweak :) - but yeah, you guys are probably right here.. still, i can appreciate it from the author's point of view too
2024-11-21 22:07:41 <TactfulCitrus> On another topic, does anyone know when nested loops shift what index i represents? That is, if I have a nested loop i is always the inner most of loop that I'm in? Is this a gforth thing or a forth thing?
2024-11-21 22:08:05 <lilo_booter > forth thing afaik
2024-11-21 22:08:26 <lilo_booter > been that way since i was a kid anyway
2024-11-21 22:08:33 <TactfulCitrus> At the end of the day their the ones doing the hardwork so it's their decision but it's not one that I can understand well
2024-11-21 22:09:18 <TactfulCitrus> lilo_booter: Thanks! Took me by surprise but just resorted to creating variables when I'm using nested loops. Less to get my head around
2024-11-21 22:09:45 <veltas      > I is the innermost loop
2024-11-21 22:10:05 <veltas      > e.g. on my ZX Spectrum Forth I is just R@
2024-11-21 22:12:00 <lilo_booter > it's one of those things in forth that always makes me smile :) - unexpected but still surprisingly elegant :)
2024-11-21 22:30:21 <xentrac     > TactfulCitrus: yes, so you can copy the matrix (or take slices of it) without copying the data
2024-11-21 22:32:05 <xentrac     > lilo_booter: I feel like maybe GForth's prompt used to be a deferred word that you could redirect with is, but it isn't now
2024-11-21 23:02:52 <TactfulCitrus> Thanks for the help as usual. I'm off to bed now - ttfn
2024-11-21 23:15:57 <zelgomer    > TactfulCitrus: if you haven't discovered already, there are a few problems with the code i gave you earlier
2024-11-21 23:16:13 <zelgomer    > that's what i get for trying to program in irssi from a smart phone