mIRC Home    About    Download    Register    News    Help

Print Thread
Page 2 of 2 1 2
Joined: Sep 2005
Posts: 2,881
H
Hoopy frood
Offline
Hoopy frood
H
Joined: Sep 2005
Posts: 2,881
The only thing I'd like to see is a switch or maybe even new keyword to run a while loop that will execute on a different thread and will be destroyed when the loop is finished, preferably where everything is managed for us. Something similar for the $findfile/$finddir identifiers would be useful too.

I think full control over threading is overkill.

Joined: Oct 2004
Posts: 8,330
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,330
Originally Posted By: hixxy
The only thing I'd like to see is a switch or maybe even new keyword to run a while loop that will execute on a different thread and will be destroyed when the loop is finished, preferably where everything is managed for us. Something similar for the $findfile/$finddir identifiers would be useful too.

I think full control over threading is overkill.


I agree that putting while loops into a separate thread would help to avoid freezing mIRC's main window while running scripts. Of course, if you don't see mIRC freeze, it's hard to know if there is a broken while loop. I'd assume there would need to be some method of seeing that. I don't know a ton about multithreading, so just noting what came to mind.


Invision Support
#Invision on irc.irchighway.net
Joined: Sep 2005
Posts: 2,881
H
Hoopy frood
Offline
Hoopy frood
H
Joined: Sep 2005
Posts: 2,881
Maybe a setting for max amount of iterations allowed? I dunno, can't really think of an ideal solution to that problem.

Joined: Dec 2003
Posts: 48
N
Ameglian cow
OP Offline
Ameglian cow
N
Joined: Dec 2003
Posts: 48
Quote:
And if DLL's are too hard a concept to grasp, I'm wondering how you're managing with the biogenetic research


I have no problem making a DLL function, thus the concept is
not hard to grasp, I just don't like to do it, and the C++
coding is not hard to grasp, I just don't see the reason why I
should spend hours days or weeks making something that I could
make in mIRC in seconds.

Quote:
By the way, "properly suggested" or not, this feature has been suggested before, probably many more times than the threads referenced above, and there are general etiquette rules about posting for the same feature twice.


I did a few searches for the topic before I posted, so its not
like I did it on purpose. Thus I think I'd pay a little less
attention to my etiquette and a little more on your own.

P.S.
I don't feel like posting anymore "suggestions" to this site again.

Joined: Oct 2004
Posts: 8,330
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,330
Quote:
and the C++ coding is not hard to grasp, I just don't see the reason why I should spend hours days or weeks making something that I could make in mIRC in seconds.


Coding in C++ doesn't take so much more time as to make a difference. And, depending what you're doing, it can be faster in C++ than in mIRC because it has more functions you can use to directly do things that yuo'd have to create in mIRC to do the same thing.


Invision Support
#Invision on irc.irchighway.net
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
By the way, using dll's doesn't mean you're limited to C/C++. You can use C#, J#, Python, Ruby, Perl, PHP, Java, VB.. pick your language. You may need a small C/C++ wrapper in some of those cases, since not all of those can produce dll binary files, but it's still doable. You could also just use COM, which all of those can interface with very easily. At that point, though, you would probably be wondering why you'd need to interface with mIRC at all, since the solution has nothing to do with the client in this case-- and you'd simplify your life by just doing it in C#/Ruby/Java from the start-- which is what I would have done.

As for C++ being slower.. I can't imagine that, since the only really convoluted programming in C++ that mIRC could otherwise do is socket stuff; most of everything else is pretty straightforward, especially when you're talking about looping over file data, reading in strings, etc.. mIRC literally copies the C api for filehandling (/fopen, $fread), so it really is no different.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Dec 2003
Posts: 48
N
Ameglian cow
OP Offline
Ameglian cow
N
Joined: Dec 2003
Posts: 48
My suggestion still stands, multithreading for mIRC scripting.

There are alot of people who need mIRC to do more and don't have
the luxury of time to learn C++, so I refuse to accept the
excuses from a few narrow minds on their behalf. Instead of explaining how it can't work, try explaining how it would.
I expected and received a response of "rtfm", in not so many
words. I just think you've forgotten that this is a forum for
suggestions and not articulate excuses with a side of argv0
attitude. The past posts have not impressed me much aside from
the users who seemed like they actually cared and actually gave
it some serious consideration, thats all.

If its so similar then it should be no problem integrating this
new procedure. smile

Joined: Oct 2004
Posts: 8,330
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,330
The fact that it uses the same commands doesn't mean that putting in multithreading capability is easy or worthwhile. Yes, this forum is for suggestions. However, that doesn't mean that you'll find people who agree with every suggestion you offer. You should see the debates of stuff like emoticons. In any case, I think we have all points for and against from each person already, so why not leave it at that and if Khaled decides he wants to add it, I'm sure he's already seen this thread. Honestly, I doubt you'll ever see it added to mIRC, so you would be better off using another language.


Invision Support
#Invision on irc.irchighway.net
Joined: Dec 2002
Posts: 2,031
R
Hoopy frood
Offline
Hoopy frood
R
Joined: Dec 2002
Posts: 2,031
YOU SAID THE E WORD!!!! NOOOOOOOOOOOO!! eek

smirk

Joined: Jul 2003
Posts: 655
Fjord artisan
Offline
Fjord artisan
Joined: Jul 2003
Posts: 655
I dont know enough about multithreaded programming to offer an educated opinion either way, mostly because i have yet to find a situation where it would have greatly benefitted any of my projects.

If you really want to put your point across, the best way would be to provide a practical example (perhaps with pseudo-code) of something you could do in mirc with the addition of this feature, that would otherwise be inpractical or overly troublesome.

It would also benefit if the example is related to IRC, and not something that probably shouldnt be done through mirc in the first place, although either way go for it...


"Allen is having a small problem and needs help adjusting his attitude" - Flutterby
Joined: Jan 2004
Posts: 162
R
RRX Offline
Vogon poet
Offline
Vogon poet
R
Joined: Jan 2004
Posts: 162
I have just some general hardware cpu architecture, memory, bus systems and programming knowledge, but I am abit surprised some people seem to consider multithreading (I guess this is about mirc script-multithreading) as something that has little benefits and only for a minority of the users. I think that is just... wrong or shortsighted.

Argv0 said:
Quote:

No. The point is that only cpu intensive programming truly benefits from multithreading.
...
From experience, multithreading really is not meant to give speed increases, so you shouldn't expect to see much in speed, only bandwidth

I think he completely missed the point here.
This is not about "cpu intensive programming".
This is not about "making things faster"
This is about programming in such a way that a user can do thing A without affecting the operation of thing B. For example, multithreading with two threads is basically processing task A for a little while, then B, then A again, then B and so on. The operation system assigns time 'slices' to the threads, so its impossible one task prevents another getting a time slice, same way as the mirc application can hang due to a scripted endless loop and you can work further with other applications.

Multithreading benefit could be working on your script in the script editor without being annoyed of sluggish typing responses when mirc has some work due to alot networks, channels or generally, alot irc related work.

Multithreading benefit could be editing settings in a dialog without the same annoyance as above.

Multithreading benefit could be a thread for every connection so a flood or alot activity on one connection could not influence the other connections (no pingouts or sluggish responses, lag there)

Multithreading benefit could be indexing folders on the background without noticing it.

Multithreading could be playing a mirc game with no lag for a bot that runs for some or all connection(s).

Multithreading could be sending alot data through sockets with a speed that isnt cranked down depending on other work mirc has to do.

Multithreading is bringing the benefit of a multitasking operating system to within application level (here: mirc script 'engine' under the mirc application).

NrWarren used a good description:
Quote:

"its like freeing up another hand for it to do its work"

mIRC is already multithreaded in its innards. I have no idea in which ways, but I saw amount threads going from a dozen till over 700.

So, I like to see this in its scripting engine.
The big question is how realistic this 'oh I like it' is, i.e., the amount work involved, and also the effects it would have on the current scripting ways. mIRC scripting is easy in the way it saves the user from complexities inherent to common programming, and that is the big reason for the large amount scripters. Its well possible the implementation of multithreading takes away a (big?) deal of this benefit. Though, the examples I listed earlier could already be enough.

Suppose an IRC-only script, no common objects with other code, could be inherently (no conditions like now) bound to a connection (seen as a thread only for that connection), that would need little to no multithreading related code, so mIRC could run 5 bots on 5 connections and they would not affect eachother regardless amount IRC activity.

I am busy on a script that has grown over years, a myriad of functions and, being on average on a dozen networks and a mere 60 chans, it is very prone to sluggyness as soon as overall activity raises. I had to use queues for the core functions and I even switch temp-off the two main queues as a sort of time-slicing.
If mIRC would do such things itself, in fast .exe code, that would simply rock. Imagine, a scripted-overhead turned into executable-multithreading.

Joined: Dec 2003
Posts: 48
N
Ameglian cow
OP Offline
Ameglian cow
N
Joined: Dec 2003
Posts: 48
Thank you for addressing this with an open mind,
I can relate well with the provided examples.

Expanding on the scripting capabilities is always
a plus in my opinion, no matter if this program is
a dedicated IRC client, and I realize khaled might not
want to bulk the app too much with potentially
unnecessary code, but the more I think about how it
might work, the more convinced I am that this is a good idea
(Regardless of who came up with it first).

Joined: Jul 2003
Posts: 655
Fjord artisan
Offline
Fjord artisan
Joined: Jul 2003
Posts: 655
Quote:
Multithreading benefit could be a thread for every connection so a flood or alot activity on one connection could not influence the other connections (no pingouts or sluggish responses, lag there)

I kinda assumed this was already the case, but have never really noticed or looked into it either way, i guess my assumption was wrong.

Again personally, i really dont know either way about the ability for the scripter to make use of threading through the code. But i do think it would benefit if each connection id is run through its own thread as to not affect others with pauses and such. (at least theoretically?)


"Allen is having a small problem and needs help adjusting his attitude" - Flutterby
Joined: Dec 2003
Posts: 48
N
Ameglian cow
OP Offline
Ameglian cow
N
Joined: Dec 2003
Posts: 48
I think someone already mentioned this, but maybe making an
easily comprehendable modification to focus on While loops.


While(condition,[paramters])[.Add_Thread] {

}

Example: (Creates 10 independant Threads with Draw/Refresh filler code)

var %N 0
While (%N < 10,Thread_Name).Thread_Add {
inc %N
}

alias Thread_Name {
; Control synchronizations or events from here?
; Also maybe good idea to define the loop code here as well.
;
; /Var (private var)
var -p %tmps $2-

; /Set (Global var) where $1 is defined as a unique numeric thread #.
; -g is for global variable, -L to lock the variable from other
thread change, other threads will have to wait, but other
execution is aloud for that thread if other instructions are defined.

inc -gL %Plot
inc -gL %Refresh

;%Plot resets to 1 when all 10 threads have been cycled through.
if (%Plot > 10) { set %Plot 1 }

;Plots Coordinates
drawdot -n @Plot 1 5 $mouse.x $mouse.y
;Refresh Drawings
drawdot @Plot

}


Its not very useful at this stage, but I think it served as a
good possible example of what it could be like. I know it still has alot of potential if done just right. the filler code is not
written in stone, so accept as such.

Last edited by NrWarren; 18/05/07 01:26 AM.
Joined: Apr 2003
Posts: 342
M
Fjord artisan
Offline
Fjord artisan
M
Joined: Apr 2003
Posts: 342
K before you start wanting to multithread... make sure you know how to properly work with multiple threads... try using multiple copies of mIRC that communicate thru DDE. Use this code which will auto assign DDE server names and communicate with all the other mIRC clients loaded.

Code:
ALIAS dde_setup {
  var %rootname = smIRC
  var %i = 0

  while (1) {
    if (%i = 0) { var %ddename = %rootname }
    else { var %ddename = $+(%rootname,%i) }
    inc %i

    if $isnot($isdde(%ddename)) { /ddeserver ON %ddename | break }
    else { /hadd -ms DDE.SERVER.LIST $enum(%i) 0 }
    /dde_remote_announement %ddename -1 FOUND
  }
}

ALIAS dde_announce {
  if $isnot($hget(DDE.SERVER.LIST)) { /hmake DDE.SERVER.LIST 100 }

  var %sendstring = $1-

  var %i = 0
  var %n = 1

  while (%i < $hget(DDE.SERVER.LIST,0).item) {
    inc %i
    tokenize 32 $hget(DDE.SERVER.LIST,$enum(%n)) 

    if $isnot($len($1-)) { continue }

    var %sname = $1
    var %last.ticks = $2
    tokenize 32 $3-

    if $isnot($isdde(%sname)) {
      /hdel DDE.SERVER.LIST $enum(%n)
      continue 
    }

    inc %n

    /dde %sname command "" /dde_remote_announement $ddename $ticks %sendstring 
  }
}

alias /dde_remote_announement {
  if $isnot($hget(DDE.SERVER.LIST)) { /hmake DDE.SERVER.LIST 100 }

  var %argstring = $1-

  var %i = 0

  while (%i < $hget(DDE.SERVER.LIST,0)) {
    inc %i
    tokenize 32 $hget(DDE.SERVER.LIST,$enum(%i))
    if $isnot($len($1-)) { break }
    if ($1 === $gettok(%argstring,1,32)) { break }
  }

  if (%i == 0) { inc %i }

  /hadd DDE.SERVER.LIST $enum(%i) %argstring

  /debugmsg 09 -l543 /hadd DDE.SERVER.LIST $enum(%i) %argstring

  tokenize 32 %argstring
  if ($3 != RECIEVCED) { /dde $1 command "" /dde_remote_announement $ddename $ticks RECIEVCED $2 }
}


You may need to modify this a little bit.

Er $enum and $isnot are custom aliases.

ALIAS ENUM { return $+(n,[,$1,],) }
ALIAS ISNOT { return $iif($1,$false,$true) }

I'm sure there are some others I did not write this for distrubution.


Last edited by MeStinkBAD; 19/05/07 07:40 PM.

Beware of MeStinkBAD! He knows more than he actually does!
Page 2 of 2 1 2

Link Copied to Clipboard