2025-01-27 00:53:50 <vms14       > how do I avoid the return stack?
2025-01-27 00:53:52 <vms14       > : point >r >r display win gc r> r> draw.point ;
2025-01-27 00:54:15 <zelgomer    > rot
2025-01-27 00:56:27 <xentrac     > 2swap
2025-01-27 00:56:39 <xentrac     > : point 2swap display win gc draw.point ;
2025-01-27 00:56:54 <xentrac     > unless gc leaves something on the stack
2025-01-27 00:57:22 <xentrac     > but the real answer is probably
2025-01-27 00:57:42 <xentrac     > value x value y : point to y to x display win gc  x y draw.point ;
2025-01-27 00:58:19 <xentrac     > variable x variable y : point y ! x ! display win gc  x @ y @ draw.point ;  \ alternatively if you prefer variable
2025-01-27 00:58:27 <zelgomer    > disagree
2025-01-27 00:58:35 <vms14       > yeah I wanted to avoid both variables and the return stack
2025-01-27 00:58:42 <vms14       > but instead juggle them
2025-01-27 00:58:49 <vms14       > the thing is I have 4 5 1 2 3
2025-01-27 00:59:00 <vms14       > and I have to reorder them to 1 2 3 4 5
2025-01-27 00:59:03 <xentrac     > well, it's possible to do that, but I think it's usually a bad idea
2025-01-27 00:59:10 <vms14       > the good thing is I can push 1 2 3 whenever I want
2025-01-27 00:59:19 <zelgomer    > what is the stack picture of this word? how many args does "display win gc" take?
2025-01-27 00:59:27 <vms14       > but 4 5 are already on the stack
2025-01-27 00:59:36 <vms14       > they are constants
2025-01-27 00:59:46 <vms14       > https://termbin.com/45qx
2025-01-27 00:59:52 <vms14       > is the same code I posted ago
2025-01-27 00:59:59 <vms14       > the same link actually xd
2025-01-27 01:00:31 <zelgomer    > oh, i completely misunderstood then. what's wrong with what you have?
2025-01-27 01:00:56 <vms14       > I think I should not resolve to the return stack without thinking twice
2025-01-27 01:01:14 <xentrac     > *resort
2025-01-27 01:01:16 <zelgomer    > maybe draw.point's input order should change
2025-01-27 01:01:20 <vms14       > xentrac ty
2025-01-27 01:01:24 <xentrac     > np
2025-01-27 01:01:47 <vms14       > draw.point is a binding to the XDrawPoint c function from xlib
2025-01-27 01:01:53 <xentrac     > makes sense
2025-01-27 01:01:58 <vms14       > they tend to require lots of arguments
2025-01-27 01:02:23 <xentrac     > my experience with XDrawPoint btw is that it's usually better to not use it
2025-01-27 01:02:34 <xentrac     > because it's just ridiculously slow
2025-01-27 01:02:45 <vms14       > it was a test to see if I was making the bindings right
2025-01-27 01:02:57 <vms14       > the simplest think was to draw a point
2025-01-27 01:03:00 <vms14       > thing
2025-01-27 01:03:01 <vms14       > lol
2025-01-27 01:03:21 <xentrac     > yeah
2025-01-27 01:03:52 <xentrac     > I did a thing last millennium drawing 3-D IFS fractals with XDrawPoint and later I realized that if I'd just been drawing to a shared memory buffer I would have been much happier
2025-01-27 01:03:58 <vms14       > so do you think using r> in this case is justified?
2025-01-27 01:04:06 <xentrac     > sure
2025-01-27 01:04:16 <xentrac     > though I'd probably use variables instead ;)
2025-01-27 01:04:33 <zelgomer    > does it have to take args in that order, though? imo things tend to flow more smoothly when inputs that tend to be constants or near constant are more to the right, and args that are usually passed from several callers higher are on the left
2025-01-27 01:04:47 <zelgomer    > makes for more seamless composotion
2025-01-27 01:04:52 <xentrac     > true
2025-01-27 01:04:59 <vms14       > I can add a c function as wrapper and bind to it
2025-01-27 01:05:13 <vms14       > but they will assume the display and gc and etc
2025-01-27 01:05:53 <xentrac     > OTOH if you're building a binding to an existing Xlib API it might be easier to follow if you use the argument order of the Xlib function
2025-01-27 01:06:06 <xentrac     > now I understand what display win gc does
2025-01-27 01:06:29 <xentrac     > why don't you put those three things in variables or values instead of passing them explicitly?
2025-01-27 01:06:41 <vms14       > they are constants
2025-01-27 01:06:52 <xentrac     > well, sort of
2025-01-27 01:06:58 <xentrac     > you could conceivably have more than one GC
2025-01-27 01:07:03 <xentrac     > or even more than one window
2025-01-27 01:07:15 <zelgomer    > i guess gc is graphics context. my original assumption was "garbage collect" which is why i thought it was a sentence that consumed something
2025-01-27 01:07:41 <vms14       > : point >r >r display win gc r> r> draw.point ;
2025-01-27 01:07:44 <xentrac     > yeah.  I have no such excuse
2025-01-27 01:07:47 <vms14       > display win gc are constants
2025-01-27 01:07:55 <vms14       > so I can just x y point
2025-01-27 01:08:00 <xentrac     > right
2025-01-27 01:08:10 <xentrac     > seems reasonable enough to me
2025-01-27 01:08:32 <xentrac     > you're basically already doing what I foolishly suggested you should start doing even though you'd already shown me the code that did it
2025-01-27 01:09:16 <vms14       > I guess is my fault to not put stack notations
2025-01-27 01:09:18 <vms14       > xD
2025-01-27 01:09:51 <xentrac     > nah, it's fine
2025-01-27 01:10:02 <xentrac     > I'd call draw.point XDrawPoint though
2025-01-27 01:10:52 <vms14       > if I expect someone to use those bindings I should
2025-01-27 01:10:52 <vms14       > I wonder if someone will actually want them if I keep adding bindings
2025-01-27 01:11:04 <vms14       > there are a lot of xlib functions and I have to add wrappers I guess
2025-01-27 01:11:16 <xentrac     > if you're looking for wide adoption, Forth is probably the wrong language
2025-01-27 01:11:38 <vms14       > actually the goal is to have fun with forth to learn it
2025-01-27 01:11:44 <xentrac     > :-)
2025-01-27 01:11:57 <vms14       > but if someone else can benefit from those bindings it's cool
2025-01-27 01:12:18 <vms14       > at the end I just make them for myself this is why they have those weird names
2025-01-27 01:12:22 <MrMobius    > Sometimes I wish for stack juggling words like j45123 to get 1 2 3 4 5
2025-01-27 01:12:39 <MrMobius    > it would be easy to make all permutations
2025-01-27 01:14:58 <MrMobius    > in the example, if 4 5 are already there, you can do 1 -rot 2 -rot 3 -rot to get 1 2 3 4 5
2025-01-27 01:14:59 <zelgomer    > pretty sure crc has tjat
2025-01-27 01:15:21 <vms14       > actually seems I can 4 5 1 2 3 4 roll 4 roll
2025-01-27 01:15:23 <zelgomer    > he calls it reorder or shuffle i think, idr which
2025-01-27 01:15:39 <vms14       > but I wonder if >r is better
2025-01-27 01:15:43 <zelgomer    > as in   '45123 reorder
2025-01-27 01:16:11 <zelgomer    > vms14: imo the return stack is there for you to use it
2025-01-27 01:16:49 <vms14       > yeah my fear is that I will likely to abuse it because I'm lazy and do not want to mess with the stack
2025-01-27 01:17:07 <vms14       > when I should getting familiar with it instead
2025-01-27 01:17:30 <zelgomer    > just ask me for permission before you use it. in this case, i'll allow it.
2025-01-27 01:17:35 <vms14       > :D
2025-01-27 01:17:37 <vms14       > ok
2025-01-27 01:25:17 <xentrac     > >r >r r> r> is definitely better than 4 roll 4 roll
2025-01-27 01:25:59 <vms14       > I was thinking about it, and how every element might need to be updated in a new position
2025-01-27 02:01:43 <crc         > Yes, I have a reorder word: https://konilo.org/manual/glossary_1054903512.html
2025-01-27 02:31:39 <KipIngram   > xentrac: >r >r r> r> and 4 roll 4 roll don't do the same thing.
2025-01-27 02:31:51 <KipIngram   > But yeah - roll sucks.
2025-01-27 02:55:14 <pgimeno     > 4 5 >r >r 1 2 3 r> r> does do the same as 4 5 1 2 3 4 roll 4 roll, doesn't it?
2025-01-27 02:55:54 <KipIngram   > Oh, I see.  I misunderstood - I thought the numbers were all already on the stack.
2025-01-27 03:00:22 <pgimeno     > I agree with zelgomer, if using the return stack makes the code clearer then why not use it - it's similar to pushing registers to the stack in assembler when you run out of registers
2025-01-27 03:02:10 <KipIngram   > Yeah, I feel the same.
2025-01-27 09:43:54 <veltas      > thrig: Whether C or assembly doesn't matter much, but if you parse C headers or have to enter that info manually makes a huge difference sometimes
2025-01-27 09:44:17 <veltas      > I mean there are short/sweet C headers that aren't effort
2025-01-27 09:44:40 <veltas      > But a lot of stuff I'm interested in like OpenGL, SDL, etc are more effort
2025-01-27 09:45:03 <veltas      > Of course the right way to do those manually is just as and when definitions are needed