02:39:28
##forth
<lf94>
Almost done a general fixed point library :o
02:40:02
##forth
<lf94>
All that's really left is implementing CORDIC for sin/cos
02:40:24
##forth
<lf94>
How do I stop the bot
02:46:51
##forth
<ajhidd>
type QUIT
02:48:16
##forth
<lf94>
QUIT
02:48:24
##forth
<lf94>
Testing testing
02:48:28
##forth
<lf94>
Nope, that didnt work
02:48:40
##forth
<lf94>
Nothing's working
02:49:55
##forth
<ajhidd>
Looks like a bug. I'll check it out later. I'll shut the bot down for now
02:53:26
##forth
<lf94>
Thank you <3
02:53:45
##forth
<lf94>
It would be nice if it were opt-in also
02:54:18
##forth
<xentrac>
lf94: congrats!
02:54:32
##forth
<xentrac>
I still don't understand CORDIC properly
02:54:52
##forth
<lf94>
I mean, it's not much of an accomplishment @ general fixed-point lib, but it's cute at 26 lines!
02:55:01
##forth
<lf94>
I'm sure everyone's done this in forth at some point
02:55:28
##forth
<lf94>
CORDIC doesn't seem too complicated. The core idea is you get "closer and closer" to the real answer
02:55:58
##forth
<lf94>
My concern is if this is fast enough for my needs
02:56:18
##forth
<lf94>
I'm probably going to do a LUT but we'll see
03:55:54
##forth
<ajhidd>
lf94: Did you have any interaction with the bot before typing "Almost done <...>"?
03:56:04
##forth
<lf94>
Maybe months ago
03:56:06
##forth
<lf94>
lol
03:56:55
##forth
<ajhidd>
Hm. I cannot reprodue the bug. It should not react to channel messages without <nick>: prefix - and it does not when I test it
03:57:58
##forth
<lf94>
I could have interacted with it months ago
03:58:01
##forth
<lf94>
It's a real possibility
03:58:08
##forth
<lf94>
quit didn't work though
03:59:04
##forth
<ajhidd>
Nope, I've modified and started it just today. You must've interacted with cleobuline's original bot :)
03:59:24
##forth
<lf94>
Ah maybe
05:37:49
##forth
<vms14>
:0
05:37:55
##forth
<vms14>
i'm playing with sockets
05:38:11
##forth
<vms14>
i know gforth has some socket thingy already though
05:38:50
##forth
<vms14>
i have this c header file
05:39:04
##forth
<vms14>
which i have stolen from a random socket c example xd
05:40:57
##forth
<vms14>
then is just to bind that in gforth: c-function socket make_inet_socket a n -- n c-function write-line write_line a n n -- n
05:41:24
##forth
<vms14>
although it's not really write-line, but write
05:42:21
##forth
<vms14>
s\" 127.0.0.1\0" drop 3000 socket constant sock s" oh..." sock write-line
05:42:57
##forth
<vms14>
although maybe i should change the socket function to accept the str + count so i can just use s" instead of s\" + drop
05:44:00
##forth
<vms14>
i was wondering if i could play with the irc protocol in forth
05:45:21
##forth
<vms14>
what would be cooler is xlib
07:32:50
##forth
<MrMobius>
re CORDIC, I got slightly inaccurate results by calculating the K value for the max number of digits I wanted then truncating for less digits
07:33:18
##forth
<MrMobius>
IIRC, it's not that simple
14:02:25
##forth
<olle>
What about an `if` word that reads buffer until `then`, runs it, checks stack for `true`, and then runs stream from `then` to `end` if it exists.
14:02:40
##forth
<olle>
Maybe frowned upon that a word reads the stream like that.
14:06:05
##forth
<vdupras>
sure, I guess you could do it, you could even manage to have the compiled version of it, but that would mean that your "if" can only be fed from "local" code. That's not very composable. For example, you can't do ": foo if bar then ;" anymore
14:06:41
##forth
<olle>
Hm
14:07:00
##forth
<olle>
depending on what "bar" is?
14:07:28
##forth
<olle>
I actually have a two-pass system, so `if` gets parsed to Word(if) before run.
14:07:57
##forth
<olle>
But yea you can't "cut" `then` without an `end`
14:10:25
##forth
<vdupras>
... so "if" gets compiled in a "traditional" manner if no "end" is encountered down the stream? That sounds like a good bug inducer
14:11:10
##forth
<olle>
Well your example had no `end` or `endif`
14:11:31
##forth
<olle>
But there's no syntax check, so I guess it would just be buggy or weird. Will have to try a bit more.
14:11:40
##forth
<vdupras>
I was giving an example of "traditional" Forth code, in which there is no "end"
14:11:46
##forth
<olle>
Oh
14:11:54
##forth
<vdupras>
and in which the "condition" comes from the parameter stack
14:11:59
##forth
<olle>
True
14:12:35
##forth
<olle>
Since `if` would run stream between `if` and `then`, I guess you could do a void word to just check the already existing stack entry.
14:12:55
##forth
<olle>
Like `if dup then . endif`
14:13:47
##forth
<vdupras>
that could work, yes
14:15:10
##forth
<olle>
+1
14:17:48
##forth
<vdupras>
but hey, wait, isn't your proposal just syntactic sugar? If you make "if" into a noop, give "then" the meaning of traditional "if" and give "endif" the meaning of traditional then, you end up with pretty much what you want, without having to resort to stream peeking, right?
14:26:28
##forth
<olle>
That is an interesting point.
14:28:17
##forth
<olle>
Lemme write that down.
14:28:52
##forth
<olle>
Funny that `if` would be noop.
14:29:41
##forth
<olle>
Isn't original `if` stream peeking tho? How would it know which chunk to run?
14:31:19
##forth
<vdupras>
it doesn't. It "knows" because it has a ( f -- ) signature on the stack. Even if you implemented your stream peeking thing, it would require the "peeked" code to have a ( -- f ) signature, or else break the stack. In the end, it makes no difference
14:36:07
##forth
<vdupras>
what you *could* do if you implemented your stream peeking thing is have "if" be the starting point of stack signature check. If PS doesn't grow by exactly one, you could abort with "bad condition signature". It would be a fancy seatbelt
14:37:07
##forth
<vdupras>
(but then again, no stream peeking required, just do like I described above, but "if", instead of being a noop, is a PS level marker)
14:45:41
##forth
<olle>
Hm
14:56:28
##forth
<veltas>
In my design for a "next-gen Forth" I considered making 'end' take an xt on stack, so it can finish literally any construct
14:57:08
##forth
<veltas>
Because having a million 'end' words is a bit redundant
14:57:37
##forth
<veltas>
And likewise there should probably be some tracking of syntax depth so you don't have an unbalanced word
14:57:58
##forth
<veltas>
I achieve in zenv with a variable to remember initial stack depth at :
15:01:08
##forth
<olle>
If you use `end` instead of {}, you might end up with a million
15:06:37
##forth
<veltas>
Well end or }
15:07:06
##forth
<veltas>
Up to you, I thought something that looks a little like Lua suited Forth better but I know some people prefer symbolic syntax more
15:10:59
##forth
<olle>
Oh you mean like endif, endloop, etc?
15:11:19
##forth
<olle>
Yes, agree otherwise, Lua-like Forth-like :)
16:20:59
##forth
<lf94>
veltas: sounds nice
16:21:17
##forth
<lf94>
veltas: 'end' could be anything right?
16:29:11
##forth
<veltas>
Yeah
17:19:54
##forth
<xentrac>
veltas: IRC is much simpler than the X-Windows protocol
17:21:56
##forth
<xentrac>
veltas: hmm, so you'd have if{ do{ begin{ }else{ and a single } to finish them all?
22:14:10
##forth
<veltas>
xentrac: Re IRC / X wrong person
22:14:40
##forth
<veltas>
I'd do e.g. if ... then ... end
22:15:04
##forth
<veltas>
I don't think {} look good for forthy langs but that's my very subjective opinion
22:15:59
##forth
<veltas>
if .. then .. elseif .. then .. else .. end probably
22:16:26
##forth
<veltas>
Like Lua really, I think it's a nicer wordy language
22:21:24
##forth
<cleobuline>
forthBot: 2 2 * .
22:21:25
##forth
<forthBot>
4
22:23:08
##forth
<veltas>
The parens are just the braces concept I wrote that checks the result is exactly 1 deeper than start of parens, or does nothing if it's a 'release build'
22:31:20
##forth
<veltas>
I think really I'd rather write C than that language though
22:32:19
##forth
<xentrac>
I still haven't tried out the COMFY-65 control structures in a Forth yet
22:33:02
##forth
<xentrac>
I think shortcut booleans and multiple exits from a loop will pay off bigtime
22:33:21
##forth
<xentrac>
that doodle does indeed look very much like Lua
22:34:11
##forth
<xentrac>
are the parens here intended to be the operand-stack-checking thing you posted previously?
22:34:17
##forth
<veltas>
Yep
22:34:34
##forth
<xentrac>
in November
22:35:22
##forth
<veltas>
You could achieve my doodle in a standard forth probably
22:35:25
##forth
<xentrac>
yeah
22:35:26
##forth
<veltas>
Or most standard forths
22:35:35
##forth
<xentrac>
why only most?
22:37:15
##forth
<veltas>
I just hesitate to say it's achievable in all, but maybe it is
22:37:38
##forth
<vms14>
oh olle left, i was reading the irc logs and he was talking about an if word
22:37:38
##forth
<veltas>
Sorry sort of in two conversations right now
22:38:15
##forth
<vms14>
mine is like: if 1 then "is true" else "is false" endif
22:38:17
##forth
<xentrac>
which is difficult to achieve with a single framed stack like C implementations normally use
22:38:20
##forth
<vms14>
if you just put if then ... endif the test is taken from the stack
22:38:25
##forth
<xentrac>
right
22:38:55
##forth
<vms14>
the problem is that if i add some sort of macros that evaluate a list, that if will not work
22:39:23
##forth
<xentrac>
I was thinking about the fairly common case where you want to return a success/failure flag and also some meaningful value, which is easy in Forth and troublesome in most languages
22:39:26
##forth
<vms14>
well i can "compile" it, but i won't be able to dynamically generate it's body
22:40:03
##forth
<xentrac>
in Lua you can do it but it's a little bit difficult to write higher-order functions that deal with multiple return values
22:42:32
##forth
<veltas>
Also not very efficient in the Lua VM
22:43:34
##forth
<veltas>
Lists of stuff aren't as efficient as tables, better to just use tables if you've got more than a normal amount of parameters/returns
22:45:24
##forth
<xentrac>
hmm, how do you disassemble the bytecode for a function in LuaJIT?
22:46:38
##forth
<les>
one byte at a time /rimshot
22:48:32
##forth
<veltas>
require("jit.util").funcinfo(function_name).bytecode
22:48:38
##forth
<veltas>
according to Mr GPT
22:49:43
##forth
<xentrac>
that's nil
22:49:56
##forth
<xentrac>
but funcinfo is at least a function...
22:51:21
##forth
<veltas>
for k in pairs(funcinfores) ...
22:51:56
##forth
<veltas>
Also said command line -jdump=bc
22:52:04
##forth
<veltas>
for lua bytecode
22:52:33
##forth
<xentrac>
oh, I think that does work
22:52:44
##forth
<veltas>
funcbc maybe
22:53:16
##forth
<xentrac>
hmm, maybe not