Well you say PascalScript is the problem, and I hear lape is a better alternative? :p I dunno, I may be wrong.
Printable View
Well you say PascalScript is the problem, and I hear lape is a better alternative? :p I dunno, I may be wrong.
hurr durr, double post + bump.
(tl;dr at bottom, as usual)
So, here I am, listening to a brilliant man named Bjarne Stroustrup talk about some sweet stuff (C++0x <3), and he mentions memory. It made me think about memory management in general, and reminded me of a pretty big reason that I seem to have completely didn't even bring up in this thread, and it's a very important one indeed.
Jagex has done a shitty job with RuneScape, in my opinion. Countless bugs, awful memory management (albeit I blame Java and the shitty JVM for this more than Jagex, but still, I can't imagine Java would be so used and THAT shitty all the time, but hey, I may just be too kind to Java ;)), and just an awful line of "improvements." But most importantly, the memory that RS takes is outstanding. I remember when I was just a wee lad I could play RS on my old mac from '86 if I had private chat off (I think public was fine), and I got about 5 fps. Now, I literally couldn't, because it takes up more memory than that computer even had. With hardware advancing and becoming cheaper and more used in common PCs, memory is usually fine. Video editing, intense photo editing, and super cool new games are all some examples of why people would need more memory/faster processor(s), etc.
Oh, and there's RuneScape(/Java).
I remember seeing the proggy for tarajunkies chickenkiller of 122 hours or some hysterically long time by uhh.. well his name slips my mind (started with a b, I think), but the point is, that was doable, and there were quite a few proggies that were all in the 50-100 hour range. That was a fantastic time where scripts could be ran indefinitely, and all that would stop it was someone's parents wanting to use the mouse that SCAR took from them. I'm sad to see proggies more in the 5-50 hour range, where 50 is quite long, in today's world of SRL.
And it can't all be Java's fault, as people are getting quite long reports with RSBot (~100 hours every once in awhile, I've seen), and RSBot uses Java, so it wouldn't make sense that moar Java would allow for longer proggies. So, it comes back to SRL(/Simba/scripts/reflection/MSI/PascalScript/Pascal/MML/whatever it may be). We have known that there are quite a few memory leaks all around different scripts/includes/libraries. And usually they're fixed. But it seems quite silly to me that we even have them. With a well structured library and proper use of the library, memory leaks should be able to be found quite easily, and shouldn't continue to pop up.
I know most people don't agree with me about the language changes/library downsize/etc., and that's fine, but I would like to at least see a proper restructure to MML/SRL/reflection/etc. so that memory leaks will not happen, unless something goes terribly wrong in a script and somehow leaks. (Memory leaks which happen in scripts should be able to be controlled in most cases with proper checks at runtime.)
I don't really know if this is just a stupid post that doesn't mean anything because obviously people aren't causing memory leaks on purpose (hopefully), but I do know that it happens in the changes are generally a bit more like band-aids, and aren't good for a community. I haven't had the time to look through SRL5 much (I did notice my name in there, and I wish I would've known earlier when I still had my code to give to the developers, but oh well), but from what I've heard/seen (sorta) is that it's more of just a restructure for appearance and losing SCAR functionality, but doesn't really address a whole lot else (which is completely understandable and I see nothing wrong with that, I just that a functional upgrade is also necessary at some point soon). And in my eyes, SRL and RS have evolved together, which is fantastic, except for what we're evolving with is sad and flawed and ugly. SRL shouldn't follow their standards.
(tl;dr,)
So, to sum this ramble up, at the very least, a restructure to deal with memory leaks is needed sometime soon. We really can't be messing around with that when RS is so bloated and stupid. I hope that can be agreed on, and if I have done nothing but cause over 100 posts by people, I hope I at least bring some more people to the attention of the include, and thus increase the standard for a fine, well working include.
:) Thanks.
It's pretty hard to do awful memory management in Java as Java itself handles pretty much everything. Just like you said, it could be the JVM, but you can't really blame Jagex for it. Also, Jagex just "goes with the flow". If they still had the graphics you could play on your '86 Max, they would have a lot less players. You need to evolve to keep your market share. Besides, computers nowadays can handle such graphics, so why not make use of that?
EDIT: I just thought of OpenGL. Jagex could probably leak some memory there..
Pascal itself also does not need you to do much management. Arrays, records, strings and variants are all handled by the compiler. You only need to manage the memory you allocate by getMem (which isn't in PS as there are no pointers) and classes. SRL doesn't really use a lot of classes. Bitmaps and dtm's are managed by Simba, so that pretty much leaves forms (which aren't used that often either).
Now, reflection is a bit of an exception here, as it lets SMART allocate memory. Here, a nice wrapper system would indeed simplify things. Inside Simba/MML it is easier to leak memory (getMem). I don't think MML allocates that much memory, though. Probably in the color finding functions, but they get called very much and crashes would probably rise sooner if they were leaking memory.
Memory leaks are annoying, easily made and sometimes hard to find. They are not solved by a mere restructure, though. Plus, you might introduce new memory leaks by restructuring.
Well of course just because you restructure something doesn't mean you solve the problem. But I still completely believe that the way SRL and Simba and RuneScape (and many other things) have been handled is pretty bad, as features just get thrown in and thrown in. I know this isn't a major language like C++ or C or anything where there are quite strict "regulations" to get things changed, but I don't see the harm in being a bit more strict with it.
I autoed for a brief hiccup in the past couple weeks for all of about 24 hours, and since then it was months if not years. But I had seen quite a few threads/posts about people having troubles with crashes and a lot of the problems were because of scripts, and not the includes, iirc. I see no reason to not have a bit more checks at runtime, since we know in general what will be done in the script. It's not like we're using this for large projects where new types are made and blah blah blah, so checking some basic stuff seems logical to me.
I need sleep. I can tell I'm not making a whole lot of sense.
i really don't see what's wrong with downsizing the library. Or the very least putting a multitude of the functions where they wont be automatically included. I dont fee like reading through 4 pages to see if that's generally agreed upon, but that makes sense to me. I forget if it was just because of including msi, but when i was working on the msi form it loaded srl and msi before loading the form and it took like 8 seconds or something. That is simply crazy.
I still and probably will continue to support switching or allowing for python. Python and pascal are fairly similar in terms of syntax. I feel like a lexer/parser(if i have the terminology correct) would have a fairly easy time of converting pascal syntax to python if you still wanted to support pascal (which i feel like you would want to). And mopar seemed to express interest in making this happen. I feel like it is definitely fast enough for our needs, or if not afaik, pypy or Cpython are faster.
I completely agree with you, but quite a few people don't. A lot of the powers that be here like the whole "it's there if you need it but you don't have to use it" ideology, which is fine, but I don't want a bunch of nonsense in /core.
My biggest problem with adding Python support (which I'd still be happy to do, if changes are made), is that there's too much to be done. Not like "oh, this is a lot of work, so I won't do it," but more like "this is a lot of work that will never be used and will only make things slower, so there's no point in doing it unless things change." MML is quite large. SRL is even bigger. I don't want to do all of that work because it's simply too much right now.
I'm going back and forth on actually implementing the changes I think would be useful or not, and it's hard for me to decide. I think there are a lot of silly things about continuing the use of PascalScript/Pascal, but also a lot of good reasons to use it. I've been trying to get a little more educated about how/why changes are made to other languages (read: C++), and what would be best for MML/SRL. I won't voice my opinions currently, but I am also trying to remember that C++ is a general purpose, object oriented, high level language, which is far from PascalScript, and our specific use for it. But I still think things can be learned from looking at C++/Python/etc.
And @ Wizzup, I'm confus. What are you saying is done but not used? :x
IIRC memory leak detection?
I doubt that adding the interpretter itself would be difficult in itself. There's not much incentive to work towards something that isnt guarunteed to even be added. Adding it is the first step. But who am i to criticize. I doubt i would have the knowledge to do anything towards making python work to the needs nor the time atm.
;) You definitely could. It's really not that difficult. It's just a lot of work.
It's nothing that most (active) members here couldn't do, really. Takes a slight knowledge of Pascal beyond PascalScript to finish libmml, and then some basic knowledge in a different language for what you're adding (Python, for example).
But it's also not something you wanna just do willy nilly, because then errors will come up, and it'd be best to keep those to a minimum.
Also, Wizzup/Dgby know more about this than me.
i was talking moreso of mopar's idea of pascalscript being converted to python so that the python interpreter can be used rather than a pascal one. afaik then pymml would take over if i understand it right. and IIRC you guys said that pymml could be automatically generated. Ofc it would have to be rewritten eventually, but if it can be done automatically, i dont see why it shouldnt be for finishing it quickly's sake.
Well I've been confused on why more of this can't be gen'd. I dunno.
One thing with pyMML is that some of the things in MML can be done without calling them from the .dll, and can just be done in the language itself a better/faster/more convenient way. But, as you said, it can be do manually later.
On top of that, pySRL has to be made, and that really shouldn't be done automatically, since that wouldn't utilize OOP, which is a pretty big reason to be using Python in the first place.
The interpreter itself may be a bit more work, afaik.
EDIT:
@niels, I dunno.. Most people here aren't familiar with MML/libMML/Pascal.
Discouraging people is the last thing I want to do. I've been saying it's pretty easy to work on Simba and related stuff for ages. It's just that if you want to write a proper libMML and Python bindings you need more knowledge than just ``how pointers work''. You also need knowledge of both FPCs and Pythons GC, how to use python's native interface, etc. :)
Seeing as srl is written in simba, it wouldnt have to be done. The only doing would be to allow python to do the colorfinding stuff and whatnot that simba can do. Once you have simba in python(lib/pymml), srl would be able to stay the same. or afaik that was the idea.
SRL is written in Simba? :x wat. Simba isn't a language.
The idea is to package up MML into a .so/.dll called libMML, but it's a little different from MML. Then you make pyMML which will just "import" functions from libMML, so that pySRL can use them, as SRL uses MML functions. Then we need to implement a CPython interpreter as well. (Well we don't NEED to, but it would be easier to script/test, sorta.)
We can already load SMART, find colors, click, move the mouse (with Python), and I had keyboard functions working too but they're not in the repo, iirc. Bitmaps, DTMs, TPAs and I dunno what else still need to be done (I guess like.. crypto, sockets, etc., but I still don't see why those are in MML, tbh).
There's something to be said for using rather simple languages like Pascal for runescape scripting.
I've written some scripts for RSBot, and personally it feels like the complexity needed to accomplish relatively small things is way out of proportion. I was coding scripts here in pascal when i was only 13 years old, there's no way i could have done that in Java.
What i see is simply a lack of in-demand scripts being made. In the end that's what gets people to come here, scripts. Once scripts are being made actively, demand for increased functionality from SRL and SIMBA will grow.
A cookie for anyone who ports SRL to Malbolge.
-- BP
Porting is bad idea, in just about every case.
But, on topic, http://pastebin.com/kbvK8Zj5 <-- why I absolutely despise dynamic typing.
I really do not want to be a part of pySRL. :/ I fear it will be horribly messy and confusing, because of the practice Python promotes.
I still think C/C++ would be a good choice, but whatever. :p
Malbolge is a bad idea in every case. ;)
I'm actually learning python right now - why not give it a chance? (Plus, this way I won't be entirely hypocritical when I'm arguing against it ;))
I think it's fine to open up a terminal, "python," and then do some small calculations or testing functions or mess with some stuff, and it's quite a good language to do that with, as you can just throw variables around like it's nobody's business. But it better stay nobody's business, because you'll damn well get yourself into some errors if you try to collaborate.
A language which promotes bad practice is a bad language, in my opinion.
I could not agree more.
I believe this is part of the general foundation of what sets SRL apart from all other botting communities, because in the end this is a true community, the others are more like... bot gateways, designed just to give you the bot/script and away you go.
what do you mean about throwing variables around. From my experience, i don't remember anything being particularly different between python and pascal in terms of variables. In fact, in python you have to say when something is a global variable, so it makes it harder to screw things up inadvertently. The main reason something like C++ or languages like that IMO, is that they are a lot more complicated in terms of code. Python has some fairly elegant ways to deal with many things that might normally be annoying. As well as making python scripts is a really easy and quick thing to do. You go in, do your stuff, then you're done. I find development to be very fast and flexible, which is the kind of development you want to have for making rs scripts.
http://pastie.org/pastes/1840808/tex...rq7dxkirwuvw0a
^ what I mean about "throwing variables around." There's no declared types at all in that. (It's from someone on 420chan.org/prog/.)
And, like I said, I think Python is fine for a one man job that doesn't do much. But a whole include with a bunch of different people contributing would be a dreadful process.
So, just because you don't understand Python and don't document your code you think it's a bad choice?
I've used Python in several projects on my university, with groups up to six people. Didn't have problems with ``throwing variables around'' and not understanding their code.
You aren't the type of person I'm talking about, Wizzup?. I know you're fine with Python, and I can read that and know what it was MEANT to do, but I also know that I could put in quite a few things that would be the wrong input and I wouldn't get an error.
But there aren't many people who are as fluent with Python as you, and so not only will there be a lot of stuff in pySRL that won't be good code.
And that wasn't my code by the way. And I know that it was a very extreme example, but still.
This is true. I think very few people knew Pascal when they stumbled across Scar in the beginning. But it's always the ambition that drives us to learn the language. Atleast this way we'll have the basic coding knowledge when jumping into Python so it won't be as tough as when one first begins scripting. Whatever ways Scar/Simba change, we'll always adapt to it because of that ambition.
Well of course people will learn. ;) There are very bright people here, but Python and PascalScript are quite different.
And of course you can declare variables as a certain type, but then that sorta defeats the purpose of dynamic typing.
But I'm sure we'll see what I mean if libMML ever gets done.
I've read barely any of this thread, but I will do when I get round to it (tomorrow perhaps?).
Is somebody porting it, is it just an idea or what?
Anyway, g'night :)
It should not be ported. As I just said, PascalScript and Python work very differently. It would be a stupid idea to just change the syntax.
Because, essentially with all the argument you're using against Python, you're very much pleading for Java. Java is that enterprise language with all that OOP and Java so you don't really need to understand each others code... That's why it's so huge in enterprises. And it's a hell to work on/in/with it, trust me. :p
I definitely don't want Java. :p
And I don't think that Python is a bad choice for those who are good with it, like you, but you have to realize that it's not really a language that would be beneficial for this community with the current amount of Python knowledge, that's all.
Also, I see no reason to make things more confusing and slower instead of using a statically typed language.
First of all using python will shorten the includes greatly and it will also teach proper formatting(right word?) of code. Also just because there's a bunch of people contributing doesn't mean there are going to be problems. Im pretty sure it would've happened already if that was the case(though PS sorta prevents it).
slightly offtopic: If python leads to dreadful problems then I wonder how many problems the guys at google must have :P
How well do you know Java and Python, luffs?
PascalScript doesn't have dynamic typing support. It is also a much different language from Python, in a number of ways. It's sorta unfair to even compare the two, imo.
I know the syntax of both to an extent. And I can figure out bugs and errors in both without TOO much trouble. Definitely not very efficient with either, but I have worked with both. I could help with either language, after it was implemented (I've done some, but it was pretty poor; I also have learned a lot more about computing in general, so if I relearned the languages I could help to implement them, but I'm not a fan of either and don't think it'd be worth my time to work with them at this time).
I'm nowhere near as good with Python as Wizzup?, and nowhere near as good with Java as quite a few people here, if that helps. :p