SRL Archive - Development

As a folllow up of the previous thread: I think it is time we made a choice on what our next step will be when it comes to an interpreter for Simba.

Possibilities (rough):

• Fix up PascalScript (if possible)
• Write our own from scratch.
• Fork one of of the existing interpreters. (Rutis, SE II or Sepi probably)
Work on these, but also keep up to date with changes in the main repos if possible)

I think forking an existing one wouldn't be a bad idea.

Wasn't RUTIS the preferred choice?
As far as I understood implementing exceptions wasn't going to be that hard..?
Or have I misunderstood?

Is the current interpreter a real problem?

From: Cazax
Is the current interpreter a real problem?

Exactly what I was thinking. Also, if you're willing to write your own, wouldn't you rather just try to fix the current one?

From: holic
Exactly what I was thinking. Also, if you're willing to write your own, wouldn't you rather just try to fix the current one?

"Fix up PascalScript (if possible)" ;)

PS is a mess. It has many ASM hacks and it would be painful to fix. Not to mention fixing it to work on Linux would be even more painful since it is not fully FPC compatible from what I grasp.

I think forking/finishing cPascal would be a great idea. If not, just forking RUTIS etc would be great.

Scrap it. Pascal sucks. Go python!

I'd like the try a diff interpreter.. kind of sick of pascal lol. I want to learn something new! :)

From: Smartzkid
Scrap it. Pascal sucks. Go python!

Give me a break, if you are going to switch languages then just make a completely separate application all together, even a separate community.

If we're moving away from PS, I'd say fix up one of the other pascal interpreters. Possibly finish Ben's ?

~RM

Embedding a python interpreter is a lot more work than one would expect.. enter Wizzup.

I vote fix up Sepi! That one's beast. :D

From: Nava2
PS is a mess. It has many ASM hacks and it would be painful to fix. Not to mention fixing it to work on Linux would be even more painful since it is not fully FPC compatible from what I grasp.

I think forking/finishing cPascal would be a great idea. If not, just forking RUTIS etc would be great.

Every engine which doesn't use wrappers for functions needs ASM hacks. ASM hacks are annoying to fix/implement because they are usually different per platform.

Speed: Sepi > RUTIS > SEII = PS (last time I checked)
Features: Sepi > SEII > PS > RUTIS
Portability: RUTIS > PS > SEII > Sepi

It's hard to change the speed of the engine without altering its design, but portability can be worked on more easily. At the moment, Sepi uses all kinds of ASM hacks to initialize/finalize variables (including classes) and does not compile on FPC natively. SEII compiles on FPC, but only has support for 32bit (Windows?). Pascal Script compiles on FPC, has support for different platforms, but just doesn't work properly on those platforms. RUTIS compiles on FPC and uses no ASM because of the wrappers.

Also, PS is probably used by more people than the other three combined, so it should be more tested. RUTIS, Sepi and SEII are just one man projects with a small group of users. Also, Sepi is half French and RUTIS is half German.

Write a plugin specification so we can plug in our own interpreters with ease? ;)
Oh, German > French so if we have to choose, I'd pick RUTIS and fix it up (as it actually has a semi-clean source).

Also, I think writing our own engine would be awesome, but too time consuming. We might not even finish it and it would slow down the development of Simba tremendously.

I think it's best to focus on other things for now (Script Manager, Stats, GUI, etc) and keep support for Pascal Script (and RUTIS?) in the future. If we find ourselves a new engine (or if we make/fix up one), we can add it to Simba and make a slow switch. Just don't depend on it.

Maybe we could switch over to unit style programming, though? As that's what the most engines are using (and PS supports it too). This would make a switch in the feature easier.

The Unit support wasn't coded by Carlo and from what I heard, it's not that great.
And it would break backwards compatibility.

From: Markus
And it would break backwards compatibility.

As would any other interpreter. As they all use the unit structure.

Then the interpreters have to be patched, or there needs to be some kind of on-the-fly script patcher.

The idea was to write SRL 5 in the unit structure, so we don't really need to be backwards compatible.

I've spent 10 minutes seeing if I could make RUTIS 64 bit compatible, but it seems it's not that easy. ;)

From: NCDS
"Fix up PascalScript (if possible)" ;)

I know he said if possible, I'm just saying writing an interpreter is a huge project and that it might be easier to just fix up the current one although I don't know what's wrong with it so I could easily be wrong about that one.

I agree with nielsie95 on most counts. Speed is not too large an issue imo. PS is deemed the slowest of them, and tbh, its fast enough (there's not much need for super speed on this kind of thing). Portability and features are more important, but unfortunately the way nielsie wrote it, the featuredness and portability are inversely proportional for them. So it needs to be decided what is more important, portability or full featuredness. I personally would lean more toward features. But anyways, you've already put a lot of work afaik into PS, so leaving it to go to something marginally better would seem kind of silly to me unless one has something substantially better.

I was under the impression that Benland had started on an interpretter. Is it not close enough to completion that it could be picked up by you as well to speed up development?

Sepi is the best.

From: Dan Cardin
I agree with nielsie95 on most counts. Speed is not too large an issue imo. PS is deemed the slowest of them, and tbh, its fast enough (there's not much need for super speed on this kind of thing). Portability and features are more important, but unfortunately the way nielsie wrote it, the featuredness and portability are inversely proportional for them. So it needs to be decided what is more important, portability or full featuredness. I personally would lean more toward features. But anyways, you've already put a lot of work afaik into PS, so leaving it to go to something marginally better would seem kind of silly to me unless one has something substantially better.

Well, RUTIS works on Linux 32 bit. And it also works on Windows. Pascalscript still does not work on Linux 32 bit. It may be fixed to work with Linux 32 bits; but I have my doubts. It's not easy to fix it.

From: Dan Cardin
I was under the impression that Benland had started on an interpretter. Is it not close enough to completion that it could be picked up by you as well to speed up development?

If we were to write an interpreter, we may port Benland's current code to pascal, but it surely isn't fit enough to be used in Simba, and I don't think Benland has the intention to finish it.

From: IceFire908
Sepi is the best.

Why? Sepi is probably the best when it comes to functionality and speed, but it doesn't even work in Free Pascal… It uses a lot of Delphi specific hacks and Delphi specific core functions that are not in Free Pascal. It's actually silly since most people who code with Delphi won't even be able to use it since it's GPL'd. (Yes, I am implying a lot of people who write with Delphi don't use the GPL)

From: Wizzup?

Why? Sepi is probably the best when it comes to functionality and speed, but it doesn't even work in Free Pascal… It uses a lot of Delphi specific hacks and Delphi specific core functions that are not in Free Pascal. It's actually silly since most people who code with Delphi won't even be able to use it since it's GPL'd. (Yes, I am implying a lot of people who write with Delphi don't use the GPL)

Free pascal is lame anyways.

From: IceFire908
Free pascal is lame anyways.

If you are here to troll, please do it somewhere else.

From: Nava2
If you are here to troll, please do it somewhere else.

Funny, but no really. FPC has limitations, delphi is much better.

From: IceFire908
Funny, but no really. FPC has limitations, delphi is much better.

I totally disagree with you, but that's beside the point. Whether FPC is better than Delphi or not is completely off topic. I'll be more than willing to take you on this discussion elsewhere, though.

If you have nothing useful to say then just don't post. You're only bothering us with your (lame) remarks. (I'm starting to think that was your intention in the first place)

From: Wizzup?
I totally disagree with you, but that's beside the point. Whether FPC is better than Delphi or not is completely off topic. I'll be more than willing to take you on this discussion elsewhere, though.

If you have nothing useful to say then just don't post. You're only bothering us with your (lame) remarks. (I'm starting to think that was your intention in the first place)

Honestly, you have your brain in the gutter. I didn't have any intentions of bothering anyone. But I can see my opinion is not wanted here so I'll gracefully leave since you only want to discuss the options available to FPC.

I got a bag of popcorn for this argument. Go go go!

From: Wizzup?
If we were to write an interpreter, we may port Benland's current code to pascal, but it surely isn't fit enough to be used in Simba, and I don't think Benland has the intention to finish it.

oh. But would it allow for an easier starting point? or is it so unfinished, that it would be easier to start anew?

and, what is unit structure?

From: Dan Cardin
and, what is unit structure?

unit Name;

procedure ohi;
begin
  //code here
end;

// etc

end.

instead of

program New;
begin
end.

From: Dan Cardin
oh. But would it allow for an easier starting point? or is it so unfinished, that it would be easier to start anew?

and, what is unit structure?

It may provide a useful starting point, yes. But Rutis may be a useful starting point too. (At least some code)

unit untitled;

interface

var a: integer // can be accessed by other units

implementation

var b: integer; // can only be accessed by the code in this unit

end.

Something like this. It allows a much more modular approach and allows units to have their own initialisation and finalisation.

Would it allow us to use OOP?

From: Smartzkid
Would it allow us to use OOP?

I know nothing on the topic but as long as it remains fairly crash-free, and allows the use of OOP, I'm OK with it. Features would be nice but those can obviously be added by the community. Based on the posts above, my vote is for RUTIS but as I said, I have no idea what I'm talking about other than what is posted here and the features I think would be good.

From: Smartzkid
Would it allow us to use OOP?

RUTIS in its current state does not. Pascalscript does not either. I'm not sure about SE II.

SEII does, but doesn't support arrays yet.

In that case, none of them sound desirable when compared to other 3GL's.

I was just made aware of Simba yesterday, and I like what I see, except for how RUTIS won't work on 64-bit systems. Wizzup pointed me to this thread from the release thread where I rambled off a crazy idea about another interpreter. I've since been able to do some research and it doesn't seem like it would be that big of a deal to embed a python interpreter into Simba, it would require some C glue code to convert data types from pascal to C to python and back, but I can't imagine it would be that hard to do or noticeably slow down a script. Alternatively to writing the glue code in-house I read about something called PyDelphi although it seems very old and I haven't been able to locate anything about it with a google search, there is also something called P4D (Python for Delphi) which I located but don't know how good it is or what the license is (just that it is 'free').

Anyway, a python interpreter would give many advantages, I'll try to list a few:

• Support Object Orientation
• Python license is compatible with GPL, free and open source
• Entirely cross-platform (works the same on Windows, Linux, Mac, BSD etc)
• Rock-solid, time tested interpreter
• Fast
• It's python!!!!

The only disadvantage I can think of is that it wouldn't be backwards compatible with SCAR scripts, wizzup mentioned that we might not be able to pause the python interpreter, I don't know about this, but I'd assume there is some type of functionality there.

I know to a lot of you incompatibility with SCAR scripts is a big disadvantage, but I think it could be remedied rather easily. From my days SCAR scripting, I remember the syntax is rather simple (no OO etc) and I believe that the pascal statements would basically translate 1->1 into python. I can't believe a converter would be that hard to write, certainly much easier than a pascal interpreter from scratch. I'd even be willing to write this when I get some free time probably around the beginning of november. This conversion of course could be done all at once and in the background, when the user clicks 'run' on a script, transparently convert it to python and set it running, the user would never know a python interpreter was running instead of pascal one.

So basically you would have the best of both worlds, support for python and OO, and backwards compatibility with SCAR scripts, in addition to all the other benefits. What do you think?

From: moparisthebest
So basically you would have the best of both worlds, support for python and OO, and backwards compatibility with SCAR scripts, in addition to all the other benefits. What do you think?

Yes! It's now or never!

From: lordsaturn
Yes! It's now or never!

+1 Sounds perfect! :)

it certainly sounds much more attractive than a bunch of alternatives to pascalscript that all sound incomplete one way or another.

and python is awesome.

I know the python thing has been brought up before and I do agree we should somehow incorporate it into Simba.

I know it would be a 'shock' to the community but as a whole I think it would be very beneficial to everyone. My C++ Professor said that Python and Java are becoming 2 popular languages that University are switching to for classes because they are used more in the world now and better memory management than C/C++.

I think switching or do something with python would benefit anyone who actually plans to do something with either programming or of the sort later in their lives.

I can assure you that neither Python nor Java have better memory management than C++, but they do manage the memory for you. ;)

From: Wizzup?
I can assure you that neither Python nor Java have better memory management than C++, but they do manage the memory for you. ;)

I meant that…as our professor said to us…"With C/C++ you have to know what you are doing." He is biased towards C/C++ IMO.

From: HyperSecret
I meant that…as our professor said to us…"With C/C++ you have to know what you are doing." He is biased towards C/C++ IMO.

I thought it was important to know what you are doing. :p

but…Python makes you fly…

I think everyone agrees incorporating python scripting would be good, what I brought up was writing a pascal->python converter to support pascal as well, so that the python interpreter is the only interpreter to worry about.

the python interpreter is the only interpreter to worry about

or rather…not worry about?

Python!!!

Pascal -> Python seems ridiculous to me. Just saying.

From: Blumblebee
but…Python makes you fly…

Im sure a lot of you know that works in python. http://svn.python.org/view/python/trunk/Lib/antigravity.py?view=markup&pathrev=66902

From: Dan Cardin
or rather…not worry about?

Exactly!

From: Nava2
Pascal -> Python seems ridiculous to me. Just saying.

More ridiculous than writing a pascal interpreter from scratch? Or more ridiculous than using one of these non-portable, hack-job pascal scripting engines? :p

From: moparisthebest
More ridiculous than writing a pascal interpreter from scratch? Or more ridiculous than using one of these non-portable, hack-job pascal scripting engines? :p

MY apologies, should have clarified.

Writing a converter between the two is silly and not really useful. It would require more effort to check if it is valid than it would take to write it new. Since the complex logic would be obnoxious.

Can not comprehend what is being spoken about here. x]

What's wrong with the current interpreter? & Cliffnote descriptions of all the interpreters listed, pl0x.

& we're looking to make Simba compile on all operating systems now?

From: Nava2
MY apologies, should have clarified.

Writing a converter between the two is silly and not really useful. It would require more effort to check if it is valid than it would take to write it new. Since the complex logic would be obnoxious.

It would only be one way, pascal->python, and not the other way around. And to write what new? An interpreter? Because that is much more complicated than a converter and involves plenty of 'obnoxious logic' (as can be seen by all the non-portable hacks in the current pascal scripting engines).

Also, as I said in my original post, there really shouldn't be ANY complex logic, as it should be a simple 1->1 mapping of a pascal statement to a python statement. To clarify this only applies to the neutered type of pascal SCAR and Simba support. When you get into object oriented code you have to consider a lot more things, such as inheritance (and what if one of the languages supported multiple inheritance and the other didn't?!!?!?), polymorphism and a variety of other painful, deal-breaker type stuff. In other words the converter wouldn't be able to convert anything FPC could compile into python, and would only apply to SCAR/Simba scripts. So it shouldn't be very hard at all, and to repeat myself, much easier than the alternatives.

From: moparisthebest
I was just made aware of Simba yesterday, and I like what I see, except for how RUTIS won't work on 64-bit systems. Wizzup pointed me to this thread from the release thread where I rambled off a crazy idea about another interpreter. I've since been able to do some research and it doesn't seem like it would be that big of a deal to embed a python interpreter into Simba, it would require some C glue code to convert data types from pascal to C to python and back, but I can't imagine it would be that hard to do or noticeably slow down a script. Alternatively to writing the glue code in-house I read about something called PyDelphi although it seems very old and I haven't been able to locate anything about it with a google search, there is also something called P4D (Python for Delphi) which I located but don't know how good it is or what the license is (just that it is 'free').

Anyway, a python interpreter would give many advantages, I'll try to list a few:

• Support Object Orientation
• Python license is compatible with GPL, free and open source
• Entirely cross-platform (works the same on Windows, Linux, Mac, BSD etc)
• Rock-solid, time tested interpreter
• Fast
• It's python!!!!

The only disadvantage I can think of is that it wouldn't be backwards compatible with SCAR scripts, wizzup mentioned that we might not be able to pause the python interpreter, I don't know about this, but I'd assume there is some type of functionality there.

I know to a lot of you incompatibility with SCAR scripts is a big disadvantage, but I think it could be remedied rather easily. From my days SCAR scripting, I remember the syntax is rather simple (no OO etc) and I believe that the pascal statements would basically translate 1->1 into python. I can't believe a converter would be that hard to write, certainly much easier than a pascal interpreter from scratch. I'd even be willing to write this when I get some free time probably around the beginning of november. This conversion of course could be done all at once and in the background, when the user clicks 'run' on a script, transparently convert it to python and set it running, the user would never know a python interpreter was running instead of pascal one.

So basically you would have the best of both worlds, support for python and OO, and backwards compatibility with SCAR scripts, in addition to all the other benefits. What do you think?

I think it will not be as easy to do as you assume it is. Simba scripts these days are more than simple statements, there's a lot of array and TPoint hackery, not to mention external plugins will have to be called. The advantage of having an interpreter written in pascal is that you can easily hook it up to other pascal plugins. Forms will also not be too easy. Pascal involves more hackery than you can imagine. ;)

I'm all for embedding python in Simba, but I'm not a fan of the extra steps. It'll be too complicated, IMO. It would be nice to embed python and allow it to use the Simba functions, though. Python obviously has it's own methods for forms, file writing, etc. So we'll only have to export core functionality. (Something pymml is aiming to do)

From: Wizzup?
I think it will not be as easy to do as you assume it is. Simba scripts these days are more than simple statements, there's a lot of array and TPoint hackery, not to mention external plugins will have to be called. The advantage of having an interpreter written in pascal is that you can easily hook it up to other pascal plugins. Forms will also not be too easy. Pascal involves more hackery than you can imagine. ;)

I'm all for embedding python in Simba, but I'm not a fan of the extra steps. It'll be too complicated, IMO. It would be nice to embed python and allow it to use the Simba functions, though. Python obviously has it's own methods for forms, file writing, etc. So we'll only have to export core functionality. (Something pymml is aiming to do)

I don't think that arrays or TPoints would be much of a problem, but I didn't think about Forms, I never used those as a SCAR scripter anyway. I'm still thinking it would be fine, as it's just calling an in-built function anyway, so the call could just be routed back to a pascal call from python, just like we would have to do with external plugins and all of the functions built into pascal. Obviously if a wrapper had to be written for each function this wouldn't be possible, but I think possibly a generic function would work for everything (perhaps passing and returning an array or the like, I'd have to experiment to be sure).

So it may or may not be too complicated, but I'm glad you plan to support python, because then I can take a stab at a pascal->python converter myself and see how it comes out. That's one of the many advantages of open source software isn't it? :sasmokin:

@moparisthebest, if you haven't already, in the git repos, check out pyMML.

From: moparisthebest
I don't think that arrays or TPoints would be much of a problem, but I didn't think about Forms, I never used those as a SCAR scripter anyway. I'm still thinking it would be fine, as it's just calling an in-built function anyway, so the call could just be routed back to a pascal call from python, just like we would have to do with external plugins and all of the functions built into pascal. Obviously if a wrapper had to be written for each function this wouldn't be possible, but I think possibly a generic function would work for everything (perhaps passing and returning an array or the like, I'd have to experiment to be sure).

The array thing is actually exactly what RUTIS does. ;)
I see your point, but I would just really prefer having Python. RUTIS seems like a good cross platform alternative. I guess the Pascal mapping to Python is possible, but I fear there will be a lot of unexpected issues to make it a viable alternative. I may even go as far as saying that it would take less work to write our own interpreter.

From: moparisthebest
So it may or may not be too complicated, but I'm glad you plan to support python, because then I can take a stab at a pascal->python converter myself and see how it comes out. That's one of the many advantages of open source software isn't it? :sasmokin:

I've been wanting Python in for a long time. An interesting read if you can stand flames: http://villavu.com/forum/showthread.php?t=55862

But now you already have built-in, selectable support between multiple scripting engines right? (PascalScript, RUTIS, CPascal) So it's probably modular enough to also add python support in as well isn't it? And I'm going out on a limb here and assuming Synedit has python syntax highlighting already.

So is it possible, as of now, to support separately python and pascal for scripting engines?

About the converter, if/when simba support python scripting I'll have a stab at writing a converter, and if it works and you guys like it you can have it, if not then it was worth a shot, I love writing parsers and converters anyhow. :)

SynEdit does have syntax support.

From: moparisthebest
But now you already have built-in, selectable support between multiple scripting engines right? (PascalScript, RUTIS, CPascal) So it's probably modular enough to also add python support in as well isn't it? And I'm going out on a limb here and assuming Synedit has python syntax highlighting already.

So is it possible, as of now, to support separately python and pascal for scripting engines?

About the converter, if/when simba support python scripting I'll have a stab at writing a converter, and if it works and you guys like it you can have it, if not then it was worth a shot, I love writing parsers and converters anyhow. :)

Yes, we can probably add python with this somewhat modular interface. Exporting all the Simba functions is another thing. And I guess SynEdit has support for highlighting Python.

From: moparisthebest
About the converter, if/when simba support python scripting I'll have a stab at writing a converter, and if it works and you guys like it you can have it, if not then it was worth a shot, I love writing parsers and converters anyhow. :)

i would think, mayhaps not, that getting a better interpretter/improving the current one would be of higher importance (since Rutis is already starting to happen afaik) than adding python (so it would come first). By then it might be too late/too annoying to make your converter useful if they're set on using their own rather than python.

Adding python would attract a number of scripters who've gotten bored of pascal. The current default pascal interpreter works 'well enough' that I believe adding python makes sense to be a higher priority than fixing a whacky pascal interpreter or writing our own (as that's a pretty long term goal).

I support the idea of using python, it seems a lot better in the long-term future (and because I don't have to develop it). Even without a proper converter. I think you'll spend more time making a fully working converter than converting a bunch of scripts manually.

From: Wizzup?
An interesting read if you can stand flames: http://villavu.com/forum/showthread.php?t=55862

Would you mind quoting that? I love interesting reads. :D

From: Dan Cardin
oh. But would it allow for an easier starting point? or is it so unfinished, that it would be easier to start anew?

http://bland.no-ip.org/repos/cpascal/

Its "functional" internally. There are still some issues with passing arrays to/from native code. Wizzup has a tendency to understate how finished it actually is, not because he's trying to play it down, or because its lacking features, but because a lot of the "external control" code isn't quite written yet. I.E., the interpreter is a partial sandbox atm, it would still need code written to interface with the external world. But the interpreter itself is quite good (considerably faster than PS at least). The downside is that few people developing Simba are proficient enough in C++ to develop it further, and converting such a monolith to fpc would be a bit tedious.

Edit: That being said, it can call to/from native methods. There is a skeleton for adding OOP support. It allows use of pointers. And, its rather clean code compared to many other interpreters (partially because its NOT written in fpc). But by not being written in FPC its a bit difficult to embed into Simba.

From: Smartzkid
Scrap it. Pascal sucks. Go python!

Yes! :sasmokin:

If PascalScript would work on Linux and 64 bit systems, we would also immediately have all the extensions working on those platforms too. I'm not sure how easily we can use RUTIS for extensions? It's probably not too hard…

bumping!

sooooo…..python….i hear that Wizzup is totally gonna add python support post haste.

From: dan cardin
sooooo…..python….i hear that wizzup is totally gonna add python support post haste.

+1 yay wizzup!

From: Dan Cardin
sooooo…..python….i hear that Wizzup is totally gonna add python support post haste.

proof? Where did you hear that?

From: IrcLogs!
<ManFlardin> you're totally gonna add python support like…post haste amirite?
<Wizzup> Yea totally! So much so post haste that one might want to call it prior haste!

you see!

Lies! Where's my &? (Plus, I never use '!') <— See what I did?

Anyway, I am indeed working on Python support at least for the actual library. Not for the past week(s) though, I feel srl stats is more of a priority. If someone else wants to work on it, let me know and I'll help getting started.

Not sure how easy it would be to actually integrate it in Simba but you could use whatever editor you want (read: vim) until it is integrated. ;)

From: Smartzkid
Scrap it. Pascal sucks. Go python!

Agree.

From: moparisthebest
I was just made aware of Simba yesterday, and I like what I see, except for how RUTIS won't work on 64-bit systems. Wizzup pointed me to this thread from the release thread where I rambled off a crazy idea about another interpreter. I've since been able to do some research and it doesn't seem like it would be that big of a deal to embed a python interpreter into Simba, it would require some C glue code to convert data types from pascal to C to python and back, but I can't imagine it would be that hard to do or noticeably slow down a script. Alternatively to writing the glue code in-house I read about something called PyDelphi although it seems very old and I haven't been able to locate anything about it with a google search, there is also something called P4D (Python for Delphi) which I located but don't know how good it is or what the license is (just that it is 'free').

Anyway, a python interpreter would give many advantages, I'll try to list a few:

• Support Object Orientation
• Python license is compatible with GPL, free and open source
• Entirely cross-platform (works the same on Windows, Linux, Mac, BSD etc)
• Rock-solid, time tested interpreter
• Fast
• It's python!!!!

The only disadvantage I can think of is that it wouldn't be backwards compatible with SCAR scripts, wizzup mentioned that we might not be able to pause the python interpreter, I don't know about this, but I'd assume there is some type of functionality there.

I know to a lot of you incompatibility with SCAR scripts is a big disadvantage, but I think it could be remedied rather easily. From my days SCAR scripting, I remember the syntax is rather simple (no OO etc) and I believe that the pascal statements would basically translate 1->1 into python. I can't believe a converter would be that hard to write, certainly much easier than a pascal interpreter from scratch. I'd even be willing to write this when I get some free time probably around the beginning of november. This conversion of course could be done all at once and in the background, when the user clicks 'run' on a script, transparently convert it to python and set it running, the user would never know a python interpreter was running instead of pascal one.

So basically you would have the best of both worlds, support for python and OO, and backwards compatibility with SCAR scripts, in addition to all the other benefits. What do you think?

Agree.

—–

Guys we can work on the converter together (just put it in a svn).
Converting pascal to python is much easier than converting python to pascal.

And about the syntax highlighting for python - you can add it later, it's not necessary right now.

Perhaps I should move some threads around. I've gotten no support from upper boards, and I've lost all my time recently.

http://villavu.com/forum/showthread.php?t=59092

Please, if people are interested.. run with it.

From: Wizzup?
Lies! Where's my &? (Plus, I never use '!') <— See what I did?

Anyway, I am indeed working on Python support at least for the actual library. Not for the past week(s) though, I feel srl stats is more of a priority. If someone else wants to work on it, let me know and I'll help getting started.

Not sure how easy it would be to actually integrate it in Simba but you could use whatever editor you want (read: vim) until it is integrated. ;)

I force & to be cut out and ! to be added to most every statement on my irc client.

when you say python support for the library i hope you mean python interpreter instead!

From: Dan Cardin
I force & to be cut out and ! to be added to most every statement on my irc client.

when you say python support for the library i hope you mean python interpreter instead!

Actual library = libmml; the library that brings Simba functionality in a library.
Python support = be able to use it in python.

From: Nava2
Perhaps I should move some threads around. I've gotten no support from upper boards, and I've lost all my time recently.

http://villavu.com/forum/showthread.php?t=59092

Please, if people are interested.. run with it.

I don't think anyone has a libmml binary. ;)

From: Wizzup?
I don't think anyone has a libmml binary. ;)

o.O The project exists though, thus compile it yourself.. :P