mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Mar 2008
Posts: 27
7
7ramy Offline OP
Ameglian cow
OP Offline
Ameglian cow
7
Joined: Mar 2008
Posts: 27
could this be implemented as it will be a very big advantage (oo language) its allready taking over the planet
windows 8 will support native html5 applications next year

Joined: Apr 2010
Posts: 969
F
Hoopy frood
Offline
Hoopy frood
F
Joined: Apr 2010
Posts: 969
With mIRC's current scripting language, I think supporting other languages would be redudant, especially considering you can use COMs to run most .js/.php/.vbs/etc scripts


/noop $jsrun(<file>,<arg1>,<arg2>,<arg3>,....)
Code:
alias jsrun {
  var %c = $ticks, %n = 2, %args
  while ($com(js: $+ %c)) inc %c
  %c = js: $+ %c

  while (%n <= $0) {
    %args = %args $qt($(,$ $+ %n))
    inc %n
  }

  .comopen %c WScript.shell
  .comclose %c $com(%c, Run, 1, bstr, $qt($$1) %args, bool, true)
}


Last edited by FroggieDaFrog; 30/06/11 07:21 PM.

I am SReject
My Stuff
Joined: Mar 2008
Posts: 27
7
7ramy Offline OP
Ameglian cow
OP Offline
Ameglian cow
7
Joined: Mar 2008
Posts: 27
this is not about running a js code snippet through COM ( which is a slow interface with overhead anyway and is probably getting obsolete in windows.next) this is more about extending mirc scripting interface through object oriented programming plus being able to use a just in time compiler like v8 which is open source and is much faster than interpreting the mirc scripting language

Joined: Apr 2010
Posts: 969
F
Hoopy frood
Offline
Hoopy frood
F
Joined: Apr 2010
Posts: 969
I highly doubt that Microsoft is doing away with COMs seeing as how they continue to add interloper support to almost every application they release. In fact, how do you think scripting languages are supported? Either "run interpreter.exe -someswitch script.extension" or through the use of COMs.

Any script-engine is going to have overhead, and to make calls to that script engine is going to add even more. If you are worried about speed or overhead from your client then either you're doing something wrong, or you're doing something you shouldn't be.

I understand that mSL can and is slow, but it has taken the harder of things to grasp in OOP[or any type of coding language] and simplified them so even the most completer-inept individuals can read for an hour or two and be able to change mIRC as they see fit.

As scripters, we often forget that mIRC is an IRC CLIENT that has a scripting language; Not a scripting language built into an IRC client.


Last edited by FroggieDaFrog; 02/07/11 07:37 AM.

I am SReject
My Stuff
Joined: Oct 2004
Posts: 8,330
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,330
Originally Posted By: FroggieDaFrog
As scripters, we often forget that mIRC is an IRC CLIENT that has a scripting language; Not a scripting language built into an IRC client.


Exactly. Scripting in mIRC is meant to help with IRC. Yes, it does offer the ability to do other things like making games, but the main purpose is to improve your IRC experience. It does that very well. There is no need for adding yet another scripting language to the mix.

Now. Most of the time people ask for other languages to be added (it happens every so often), it is because they know how to script/program in that language and do not know how to script in mIRC's scripting language. They basically want to use what they know and not have to learn something new. That is hardly a good reason to request other languages. mIRC can already make use of Javascript as mentioned and you can use programming languages like C# to create DLLs that mIRC can use. So you already have limited support for those languages. That is enough for what mIRC is meant to do. If you want to make something more complicated, then it probably has no purpose in IRC and you should make it separate from IRC.


Invision Support
#Invision on irc.irchighway.net
Joined: Mar 2008
Posts: 27
7
7ramy Offline OP
Ameglian cow
OP Offline
Ameglian cow
7
Joined: Mar 2008
Posts: 27
this is not because i cant write mirc scripts
or other programming languages
infact i learned other programming languages because i started writing mirc scripts i've wrote huge scripts but
u could never use modularity classes inheritance etc
javascript is simple and it has many jit compilers open sourced it cant be too hard to implement
u guys need to have a new view and stop these pointless arguments
just because it was suggested with other languages before make javascript a wrong candidate here

Last edited by 7ramy; 02/07/11 05:34 PM.
Joined: Oct 2004
Posts: 8,330
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,330
Simply put, it is extremely unlikely to ever happen because there is no good reason to add it. mIRC has its own language and that's enough for what mIRC is meant to do.

And an argument isn't "pointless" just because people disagree with you.


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
js4mIRC

Problem solved (mostly). The JS engine used there might be outdated (you'd probably embed V8 instead), and the mIRC integration is a little outdated too, but that clearly shows that it's feasible and simple to add JS functionality via dll.

Why does it need to be builtin?

The others have it right. JS is the wrong candidate for mIRC because it's not mIRC script. There's no reason for Khaled to support mIRC script at the same time as adding bridge libraries for JS. That is simply put a duplication of efforts. It would only make sense of the ultimate goal was to phase out mIRC script entirely in favour of only supporting another language, but that's pretty much never going to happen in your lifetime. It would be like Linux removing Perl because Python is "better".

If you want speed use a dll like the above to avoid the overhead of COM. Plugins like these is something that third party DLL / scripting support was built for.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Mar 2008
Posts: 27
7
7ramy Offline OP
Ameglian cow
OP Offline
Ameglian cow
7
Joined: Mar 2008
Posts: 27
i checked it before yes it's based on spidermonkey, an old version of spidermonkey using an interpreter not a JIT compiler
the speed difference is huge
besides using a dll how would could integrate it the right way
mirc 7 requires a unicode dll compile
while mirc 6 requires a multibyte characterset compile
you cant just do this on your own can you?

Joined: Oct 2004
Posts: 8,330
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,330
As mentioned, it's very unlikely.

Now, if you have something that you need to accomplish that mIRC scripting can't do and it's IRC-related, then mention what it is and maybe it's already possible or if not, it *might* give Khaled a reason to consider adding it. However, if the script you want to write has nothing to do with IRC, then that's not going to be a good reason for Khaled to even consider adding it. If you want to write something that isn't for IRC, then write it in Javascript and leave mIRC out of it.


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
As I said, the above was an example, not a point. V8 is supposedly even easier to embed than spidermonkey (it was built for embedding), so it's feasible to update JS4mIRC with V8. The source code is published for JS4mIRC, so you could just change the embedding calls, or recompile with the new TraceMonkey engine, which uses the same API (you can drop the library into JS4mIRC and recompile), *is* JITed, and competes nicely with V8.

FWIW, even SpiderMonkey is hundreds of times faster than mIRC's engine, so I think you're exaggerating the importance of what JIT gets you. You'd still gain a tremendous speed increase by using the above dll, JIT or not. Also keep in mind that any window command you perform, be it /echo, /draw*, /dialog, /window or other (even /timer), has up to a 10-15 ms delay, and that's because of Windows, not mIRC, so if your script is heavily dependent on UI commands, you're not going to get speed anyway. You only really need "speed" when performing numerically intensive computations, and that rarely happens on IRC. Basically, I just think you're hearing the word "fast" and you think mIRC needs this quality because it sounds better than slow. The truth is, in many cases you won't actually notice a difference, and the other cases can be done through existing *4mIRC dlls (there are ones for Python, Perl, PHP and Ruby, and they're all faster if you need the speed and don't program C). You don't need JIT speed for an IRC script, trust me.

As far as multibyte stuff goes, mIRC 6 handles unicode just fine, so you can just return unicode characters. As far as getting the data in, everything is passed in as raw data, so you decide how to encode it. There is also this:

Originally Posted By: versions.txt
52.Added support for DLLs that use Unicode functions. By default mIRC assumes that DLL functions are ANSI for backwards compatibility. However a DLL can enable Unicode support by setting mUnicode to TRUE in the LOADINFO structure


In short, Khaled already thought about this problem. DLL developers don't really have to worry about an incompatibility between 6.x/7.x. Even in the edge cases you could easily check mVersion to see whether you should perform conversion on input, and you could also use an isutf8() function.



- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"

Link Copied to Clipboard