mIRC Home    About    Download    Register    News    Help

Print Thread
#253506 17/06/15 03:44 PM
Joined: Jul 2006
Posts: 4,145
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,145
This is pretty common and happen pretty often, you read something from a socket and you immediately tokenize it, usually with space:

Code:
on *:sockread:name:{
var %a
sockread %a
if (!$sockbr) return
tokenize 32 %a
if ($1 == stuff) ..
}
I suggest having a new switch to directly fill $1- instead of using a %variable:

Code:
on *:sockread:name:{
sockread -t32
if (!$sockbr) return
if ($1 == stuff) ..
}


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Wims #253507 17/06/15 03:45 PM
Joined: Dec 2008
Posts: 1,515
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2008
Posts: 1,515
Yeah, thats a very good idea +1


Need Online mIRC help or an mIRC Scripting Freelancer? -> https://irc.chathub.org <-
Wims #253518 17/06/15 09:24 PM
Joined: Apr 2010
Posts: 969
F
Hoopy frood
Offline
Hoopy frood
F
Joined: Apr 2010
Posts: 969
+1 from me aswell.


I am SReject
My Stuff
Wims #254027 19/07/15 01:04 AM
Joined: Apr 2003
Posts: 342
M
Fjord artisan
Offline
Fjord artisan
M
Joined: Apr 2003
Posts: 342
Your suggestion really obfuscates the code.

I suggest...
Code:
on *:sockread:name:{
 tokenize 32 $sockread
 if (!$sockbr) return
 if ($1 == stuff) ..
}

Last edited by MeStinkBAD; 19/07/15 01:05 AM.

Beware of MeStinkBAD! He knows more than he actually does!
Joined: Jul 2006
Posts: 4,145
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,145
Obfuscates, really?

You need a way to tell mIRC how to read, this is done with /sockread and won't change.
Why are you introducing a new identifier out of nowhere?
How is my code obfuscating anything?
Your version doesn't have anything better, it's just a different way to do it, but which is introducing a new identifier for no good reason

Assuming you mean $sockread would return a line from the buffer, people would use /tokenize N $sockread already, but it doesn't exist.

If you want to suggest $sockread, make a new thread about it, I think /sockread -t would be useful regardless of $sockread because it lets you use /sockread's behavior, you could use -f for example, $sockread itself wouldn't allow you to do that, so perhaps $sockread(f) to require that switch, but introducing a new identifier here seems unecessary to me.


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Wims #254029 19/07/15 02:50 AM
Joined: Apr 2003
Posts: 342
M
Fjord artisan
Offline
Fjord artisan
M
Joined: Apr 2003
Posts: 342
Your suggestion makes it harder to read for those less familiar with the /sockread command and it's switches, IMO. They'll see /sockread but the -t32 will have them scratching their heads. I doubt you know what every switch for every command does. I know I don't. Good code should be easy to understand even if you aren't an expert at it. The command /sockread tells that it does a socket read, but -t32 tells you nothing and is something that has to be looked up.

Yes my way is just a different way of the same thing you suggested. Identifiers are added all the time, and it is for a good reason. The one you suggested, provide a simpler way of tokenizing the incoming socket string.

Last edited by MeStinkBAD; 19/07/15 02:55 AM.

Beware of MeStinkBAD! He knows more than he actually does!
Joined: Jul 2006
Posts: 4,145
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,145
You're basically saying the name of a command or, of an identifier, is clearer than a switch because the name is much more meaningful, and that I agree, but switch usually have their letter based on the function done by that switch, both versions are readable...
If you argu that 'tokenize 32 $sockread' is better than '/sockread -t32 %name' because -t32 tells you nothing, well what about $sockread?
Considering mIRC never had anything similar, I can easily argu that $sockread is as confusing, as less known, than -t32, both would arguably be looked up.
Now, in the examples, you see $1- being used, there is no $1- inside the on sockread (or sockclose) event, so somewhere, someone tokenized.
Like I said $sockread doesn't say much about how the line was read, where /sockread -t wouldn't change the way a line was read.
This $sockread suggestion is entirely independent of this current suggestion and would require much more work to do a simple /tokenize on the result than -t would, and it could be used to read anything, it shouldn't be added just for this tokenization thing.
Yes your way is just a different way, but I just pointed out how it's not better.
If we had both right now, I'd use /sockread -t32 wink


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Wims #254039 19/07/15 06:55 PM
Joined: Apr 2010
Posts: 969
F
Hoopy frood
Offline
Hoopy frood
F
Joined: Apr 2010
Posts: 969
I like the idea of being able to tokenizing from the /sockread command, but I don't think the tokenization should alter the sockread command. That is to say, it should still fill a specified variable, and then tokenize what it filled said variable with:

Code:
on *:SOCKREAD:sockname*:{
  if ($sockerr) return

  ;; fills %var with what is read, then tokenizes the variable
  ;; to fill $1-
  sockread -t32 %var
}

Doing it as such would allow for current behavior to be maintained while adding the tokenization functionality


I am SReject
My Stuff
Joined: Jul 2006
Posts: 4,145
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,145
Exactly, it should only fills $1- but would still do it's job, I never wanted the current behavior of /sockread to be changed, sorry if that wasn't mentioned or unclear, seems a bit obvious to me though, I wouldn't ask to break /sockread just to quickly tokenize laugh

edit: I just realized I originally asked it to replace the %variable, the syntax would change but it wouldn't break. Either way, I think I originally suggested to get rid of the %variable because if you are using $1-, you will usually not need that %variable, but as long as it tokenize, we'd be happy.


Another good point from Talon, creating a local variable before /sockread because it would create a global variable otherwise, it's the same idea as -t, it's something almost all scripters do, because we usually never need a global variable to be assigned the read of a socket's buffer.
I think it's ok to add it to this thread: a '-l' switch to /sockread to make that %variable a local one

Last edited by Wims; 19/07/15 09:10 PM.

#mircscripting @ irc.swiftirc.net == the best mIRC help channel

Link Copied to Clipboard