Latest revision as of 11:58, 3 May 2023

Your edit to https://en.wikichip.org/wiki/mirc/optimization stating that "/set -l" is faster than "/var" is simply untrue. I have benchmarked both statements - 100,000 iterations of "/var %a 1000" takes 2313ms on my PC, and the same number of iterations of "/set -l %a 1000" takes 2344ms. I am going to revert that edit. If you want to have a copy of my benchmark script, happy to share it with you. Sophist (talk) 14:13, 11 September 2018 (EDT)

Apologies - benchmark command was incorrect - revised timings are 2750ms for 100,000 "var %a 1000" and 2610ms for "set -l %a 1000". So whilst it is 5% faster, "multiple /set -l to set local variables is NOT much faster than /var because /var has to parse the line and call /set for each variable anyway". Sophist (talk) 14:20, 11 September 2018 (EDT)

Hey, /set -l is much faster regardless of the number of variable to be set. I'm not going to write a benchmark script for it, you can do it if you want, but it's only logical. Please don't revert my edit as I wrote a major part of wikichip/mirc, what I wrote is very well tested and is almost always proof read. I'm objective, so if you think something is wrong, please talk about it on swiftirc.net #mircscripting, if your benchmark is proving stuff, I'll edit the page.

So what, then, is the evidence that "/set -l" is "much faster" if you have not benchmarked it? And just exactly how am I supposed to know that such things need to be discussed on swiftirc.net #mircscripting? Psychic telepathy perhaps? Sophist (talk) 17:05, 12 September 2018 (EDT)

I have benchmarked it in the past, with a simple script but also in practice with my picwin game, I was just saying I'm not going to attempt to demonstrate it to you, or not in here. You're not supposed to know about swiftirc as it's nothing official (still no need to be on the defense like that). It's just that I wrote a lot for wikichip/mirc by myself, from a point where everything had to be done and it pains me when people edit stuff and replace them with wrong stuff, I'm not saying you did (except maybe for this case but at least you're communicating about it) but it happened. So I have no more right to edit stuff than you do but I feel like I do and i'm like "how people dare to say there are going to revert MY change". In any case, on #mircscripting there are at least Wiz, maroon and myself, which I believe with you are the major contributors, so it would be nice to have you there, if not for wikichip, for mIRC :). I see that you didn't put back the bit on /set -l, I'll wait for your reply here, please either show me /set -l is not faster in some cases, or tell me it is and that you're going to put it back! Ouims (talk) 07:51, 13 September 2018 (EDT)

I have reinstated the section and extended it with more options and a benchmark. Sophist (talk) 12:42, 13 September 2018 (EDT)

On the $hfind page you have just added: "Note': there are no convenient way to stop the $hfind search, using /halt from the command parameter (or inside the alias) will halt the full script." I am really not sure what this means. I can quite believe that with a large hash table, a $hfind call might take some time, but given the single threaded nature of mIRC I cannot see how you can issue a /halt command. Or have I misunderstood? Sophist (talk) 06:51, 15 December 2019 (EST)

Hey, unsure this is how i should reply, /halt is executed from the command parameter of $hfind, there is a difference between what /halt do inside $hfind's command parameter and inside $findfile/$finddir's parameter, one stops the full execution whereas one stops only the search, note that /halt inside the alias called by /filter -k simply do nothing. Ouims (talk) 07:51, 13 September 2018 (EDT) [Moved here from Sophist's talk page by Sophist]

You could have replied on your own talk page as you get subscribed by default when you post one someone's talk page. I now understand what you mean. I am unclear whether it is a bug or not. The help file says "If you use /halt in the command/alias, this halts the search." It doesn't say it halts the script - though Khaled is insistent on preserving backward compatibility so even if it is acepted as a "bug" I am not sure he will change mIRC to allow /halt to halt the search rather than halt the script. Can we have a chat on this on IRC somewhere? Sophist (talk) 07:37, 15 December 2019 (EST)

I have had another look at your recent edits, and if I understand it $hfind is different from $finddir and $findfile in that /halt in $hfind stops the script and in $finddir and $findfile it stops only the search and the script carries on. This definitely is inconsistent and I would consider it a bug - though as I said that doesn't mean that Khaled will change it. What would be helpful to me as a scripter (and therefore probably helpful to others) would be more examples on e.g. how to know that $finddir or $findfile has had an internal /halt (i.e. by setting a global variable or other means) and even more usefully how to work around /halt stopping the entire script in $hfind. Sophist (talk) 07:46, 15 December 2019 (EST)

The whole IPv6 thing is complicated - so explaining it is difficult. But I am still confused about Local Mode vs. stickiness. My understanding is that when you open a new connection status window it sets the IP version according to the IPv6 priority setting, and after that (assuming that the server it is trying to connect to is contactable via this IP version) it defaults to the same IP version as before unless you explicitly select an alternative version via /server -4 or -6. When you make an IRC server connection, the version for the window is set to the connection version. The choice of which IP version is used by /dns and /sockopen without -4 or -6 is then based on the window's server version (except if IPv6 Priority is set AND (???? some other status) in which case /dns and /sockopen are equivalent to -46). Is my understanding correct? And if so, is this an easier way to explain it to others? Sophist (talk) 09:51, 20 December 2019 (EST)

Not arguing with your edit of https://en.wikichip.org/w/index.php?title=mirc/identifiers&diff=next&oldid=95845 but I am unclear why you have removed these (rather than e.g. moving them to the identifiers removed section)? Sophist (talk) 05:35, 11 February 2020 (EST)

With regard to your edit https://en.wikichip.org/w/index.php?title=mirc/commands/mode&diff=next&oldid=93015 personally I prefer the previous table format than the bullet format you have created - personally I find it more readable. Similarly, I personally find the tabular "See also" sections more readable. However, I am certainly not going to get into a Wiki editing war with you over personal preferences - clearly your personal preferences are different and there is no reason why my personal preference should be any more important than yours. Sophist (talk) 03:41, 3 May 2023 (EDT)

Hello, We're moving away from wikichip, we're going to use https://mirckb.readthedocs.io/en/latest/ now, i have edited the table to be compliant with the rest so it's simpler for me to script a conversion, nothing personal. wikichip is too told, full of ads without ad blocker, and it's a bit broken. Let's talk about it on #mircscripting @ swiftirc

Well that is a pretty darn good reason to make these edits!!!! And readthedocs is indeed likely a much better place, subject to less spam and likely more functionality too. How is the source for these docs going to be managed? Sophist (talk) 12:58, 3 May 2023 (EDT)