2023-02-25 00:47:27 <qartis      > I'm trying to refactor a little chunk of code but I'm stuck, anyone interested in taking a look?
2023-02-25 04:14:29 <KipIngram   > I'll be glad to take a look.
2023-02-25 04:14:54 <qartis      > KipIngram: does this channel have a preferred pastebin?
2023-02-25 04:18:46 <qartis      > KipIngram: https://pastebin.com/raw/NaC60tmJ
2023-02-25 04:21:36 <qartis      > after thinking about it for a while I'm happy with the result
2023-02-25 04:21:40 <qartis      > ESP32forth btw
2023-02-25 05:53:01 <KipIngram   > Ok, let me take a look.
2023-02-25 05:54:04 <KipIngram   > Oh wow - those throws make it kind of interesting, don't they?
2023-02-25 05:55:52 <KipIngram   > Well, you do have several bits of repeated code.
2023-02-25 05:56:25 <KipIngram   > I'm sure you already  noticed that, though.
2023-02-25 05:56:47 <KipIngram   > Like "1 listen throw" is in there times.
2023-02-25 05:56:54 <KipIngram   > three times
2023-02-25 05:58:45 <KipIngram   > Other than that not a lot is leaping out at me - it's fairly densely specified stuff.
2023-02-25 06:00:07 <KipIngram   > I think I would certainly try to get the three patterns like this;
2023-02-25 06:00:42 <KipIngram   >   telnet-sockfd telnet-serversock sizeof(sockaddr_in) bind throw
2023-02-25 06:00:43 <KipIngram   >   telnet-sockfd 1 listen throw
2023-02-25 06:00:45 <KipIngram   >   telnet-sockfd non-block throw ;
2023-02-25 06:02:53 <KipIngram   > into some word that you pass telnet-sockfd into.  Also maybe the AF_INET line.
2023-02-25 06:03:17 <KipIngram   > Anyway, your three main words are almost identical in several lines - just with different sockaddr's.
2023-02-25 06:03:47 <KipIngram   > The last one uses dup in a good way instead of repeating the sockaddr, but all of them could use dup like that, and then there's a large chunk you can factor out.
2023-02-25 06:03:52 <KipIngram   > Do you see what I'm referring to?
2023-02-25 06:06:30 <KipIngram   > Oh, wait - I see.  I'm just noticing your "before and after."
2023-02-25 06:07:51 <KipIngram   > I don't see how your after word works.  You've got the sockaddr AFTER the call to server-init.  How is that server-init actually using it?
2023-02-25 06:08:42 <KipIngram   > Does "to" parse a word out of the input stream?
2023-02-25 18:36:06 <qartis      > KipIngram: hey thanks for taking a look!
2023-02-25 18:36:36 <qartis      > I'm not sure what you mean about sockaddr coming after the call to server-init
2023-02-25 18:38:23 <qartis      > sockaddr is defined earlier as basically ": sockaddr create 0 , 4 , ... ;"
2023-02-25 18:39:22 <qartis      > and then I "sockaddr serversock" before the definition of server-init
2023-02-25 19:02:21 <KipIngram   > Ok, what does the word "to" do in the last couple of lines?
2023-02-25 19:04:27 <qartis      > isn't that the standard way of updating a value?
2023-02-25 19:04:46 <KipIngram   > No, the standard way up storing a new value in a variable is to say
2023-02-25 19:04:53 <KipIngram   > <value> <variable> !
2023-02-25 19:04:57 <qartis      > -1 value telnet-sockfd
2023-02-25 19:05:01 <qartis      > 6 to telnet-sockfd
2023-02-25 19:05:02 <crc         > value, not variable
2023-02-25 19:05:06 <KipIngram   > Oh, I see.
2023-02-25 19:05:27 <KipIngram   > Ok, maybe so.  So, what I meant was that to has to parse its target out of the input stream.
2023-02-25 19:05:40 <KipIngram   > It's the word that comes AFTER to.
2023-02-25 19:06:41 <qartis      > yup I think it's meant to do that, in my case telnet-sockfd and camera-sockfd are defined earlier as values
2023-02-25 19:07:06 <KipIngram   > I don't use value in my system, so I'm not familiar with it, but it looked like whatever to did it would have to do that - grab a word from the input.
2023-02-25 19:07:11 <qartis      > and "to" is basically like : to ' >value ! ;
2023-02-25 19:07:20 <KipIngram   > Yeah, I understand now.
2023-02-25 19:07:21 <crc         > yes
2023-02-25 19:07:34 <crc         > 6.2.2295 in CORE EXT wordset in ANS
2023-02-25 19:07:54 <KipIngram   > Since you've made it so the value leaves its... well, value instead of its address, you can't actually modify it without working directly on its definition.
2023-02-25 19:08:49 <qartis      > yeah, that was my problem with the original definition, since the name of the 'value' was baked into the word
2023-02-25 19:09:14 <crc         > I've used some Forths where TO doesn't parse, but rather sets a hidden flag that the word made with VALUE would use to decide whether to update itself or return the stored value
2023-02-25 19:09:41 <qartis      > in my case it's a bit cleaner to have these as 'value's instead of variables because I'm fetching their contents a lot more often than I'm modifying them
2023-02-25 19:10:03 <qartis      > so I can replace a bunch of "telnet-sockfd @" with just "telnet-sockfd"
2023-02-25 19:10:22 <KipIngram   > Sure.
2023-02-25 19:11:01 <KipIngram   > In the old style Forths I've worked with we had CONSTANT, which was basically the same t hing.
2023-02-25 19:11:20 <KipIngram   > VALUE is better, I think, since it IS possible to change them, if you really want to.
2023-02-25 19:11:22 <qartis      > crc: ah very interesting, when does that flag get reset? each time a "value" is executed?
2023-02-25 19:11:36 <crc         > qartis: yes
2023-02-25 19:12:00 <KipIngram   > Ah - cool.  The downside being you pay the price of checking that flag every time.
2023-02-25 19:12:22 <qartis      > so I guess you could abuse the rules and say "to 16 myvalue"
2023-02-25 19:12:32 <KipIngram   > But, I imagine most often you wouldn't be using it so much that that mattered much.
2023-02-25 19:13:48 <qartis      > KipIngram: yeah in my forth I've just got : value constant ;
2023-02-25 19:13:57 <KipIngram   > You could also require that to be followed by the value word, and if it worked right to could look ahead do all the work.
2023-02-25 19:14:10 <KipIngram   > Then there would be no added overhead when you didn't use to.
2023-02-25 19:14:12 <crc         > "ANS Forth explicitly requires that TO must parse, so that TO’s effect will be predictable when it is used at the end of the parse area."
2023-02-25 19:14:44 <KipIngram   > ;-)
2023-02-25 19:14:56 <KipIngram   > Good thing I don't get hung up over the standard.
2023-02-25 19:15:46 <KipIngram   > what do they mean by "the end" of the parse area?
2023-02-25 19:24:17 <crc         > "parse area: The portion of the input buffer that has not yet been parsed, and is thus available to the system for subsequent processing by the text interpreter and other parsing operations."
2023-02-25 19:24:35 <KipIngram   > Ah.  Unused text input buffer.
2023-02-25 19:25:19 <crc         > yes