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