[Windows+Ubuntu] MCSL Demo (eigen scripttaal)

[Maarten Baert]

Ik heb een eigen scripttaal gemaakt, genaamd MCSL (Model Creator Scripting Language). Ik ben hier al een hele tijd mee bezig (wie op game-maker.nl zit heeft het misschien al gezien in mijn onderschrift). Ik wil deze scripttaal gebruiken in een ander programma dat ik aan het maken ben, Model Creator v6 (vandaar de naam). MCv6 is nog lang niet af, maar de scripttaal wel ongeveer. Ik ben benieuwd wat anderen ervan denken en of het ook werkt op andere computers (ik doe namelijk redelijk veel dingen die niet echt standaard C++ zijn).

Het programma is gemaakt met wxWidgets 2.9.2, een cross-platform framework (vergelijkbaar met QT, wat ik veel zie op dit forum).



Download voor Windows
Download voor Ubuntu (gemaakt in 11.04, geen idee of het ook werkt voor andere versies)

De scripttaal lijkt erg op GML, maar het is wat strikter qua syntax (het lijkt wat meer op C). Ik gebruik static typing en static binding, zoals in C++. Er zijn voorlopig twee types (real en string), en je kan ook eendimensionale of tweedimensionale arrays maken van beide types (real[], real[][], string[], string[][]). En in tegenstelling tot GML kunnen arrays wel degelijk gebruikt worden als functieargumenten en returnwaarde.

Het is ongeveer 4 keer sneller dan GML. Daarmee komt het qua snelheid in de buurt van PHP (qua mogelijkheden natuurlijk niet ). In sommige tests was het zelfs sneller dan PHP.

Ik heb een lijst van alle operatoren, functies en constanten ingebouwd in het programma, druk op de knop 'Show reference' om de lijst weer te geven. In het zipbestand zitten ook een hoop tests met voorbeeldcode.

Dit is uiteraard alleen een demo, op zich is dit niet erg nuttig (tenzij als een geavanceerde rekenmachine misschien). Maar ik zou het heel leuk vinden als jullie dit willen testen en zeggen wat je ervan vindt (zowel van de scripttaal als van het programma zelf).

@Laloeka: Ik zou het naar je ge-emaild hebben zoals je vroeg, als ik je emailadres tenminste kende . Maar ik vermoed dat je hier ook wel vaak online komt . Een deel van de tips die je gaf heb ik er al in verwerkt. De code "real x = 5;" werkt nog niet, daar ben ik nog mee bezig.

[jonas]

ik volgde je blog van model creator v6 maar deze is al een tijdje niet meer geüpdated (24 april?).  Ik heb het een tijdje geleden al eens getest en het ziet er erg goed uit ik ben benieuwd naar meer

[morsil]

Ik had ook al wat glimpen opgevangen van dat je hier mee bezig was en het ziet er al goed uit.

Misschien kan je zorgen dat je bij de print functie ook real's kan meegeven als argument, dus;

Code: [Selecteer]

real a;
a = 5;
print(a);
ipv.

Code: [Selecteer]

real a;
a = 5;
print(to_string(a));
Dat zou wat makkelijker kunnen werken


Ik was zelf trouwens ook een tijdje terug bezig met een soort compiler voor een eigen gemaakte taal, maar als ik deze  afmaak krijgt het wel een ander doeleinde. (Wat dat is verklap ik nog even niet)

[Maarten Baert]

ik volgde je blog van model creator v6 maar deze is al een tijdje niet meer geüpdated (24 april?).  Ik heb het een tijdje geleden al eens getest en het ziet er erg goed uit ik ben benieuwd naar meer

Ja klopt, die moest ik dringend eens updaten (net gedaan).

Ik had ook al wat glimpen opgevangen van dat je hier mee bezig was en het ziet er al goed uit.

Misschien kan je zorgen dat je bij de print functie ook real's kan meegeven als argument, dus;

Code: [Selecteer]

real a;
a = 5;
print(a);
ipv.

Code: [Selecteer]

real a;
a = 5;
print(to_string(a));
Dat zou wat makkelijker kunnen werken

'print' is eigenlijk alleen maar een tijdelijke functie die ik heb toegevoegd om makkelijk te kunnen testen, ik weet niet of ik die functie ga houden. In Model Creator zelf is er geen outputvenster (of toch niet in het hoofdscherm), daar ga ik waarschijnlijk werken met kleine popup-vensters (eventueel wel met een outputvenster voor debugdoeleinden).

Ik was zelf trouwens ook een tijdje terug bezig met een soort compiler voor een eigen gemaakte taal, maar als ik deze  afmaak krijgt het wel een ander doeleinde. (Wat dat is verklap ik nog even niet)

Ik ben benieuwd .

[jonas]

ik heb even naar je blog gekeken  en nu maak je me nog nieuwsgieriger naar die eerste versie die je verwacht af te hebben half september 

[Laloeka]

Aha, een nieuwe versie
Monospace font zo te zien.

Die moet ik binnenkort dan maar eens gaan uittesten.
Eerst nog twee weekjes op vakantie als je het niet erg vindt

Ik heb je de code al eens gestuurd, maar ik zal hem nog even voor nieuwsgierige forumleden posten.

Dit script tekent een sinus-golf, in tekstvorm. Met instelbare hoogte en breedte.  Zie twee variabelen midden in de code

Code: Text

1. function string calculateString(real line, real maxLines, real width) {
2.    string a;
3.    real i;
4.    for(i=0; i<=width; i+=1) {
5.           if (line < floor(maxLines/2)) {
6.                  if (sin((i/width)*pi*2)*floor(maxLines/2) <= floor(maxLines/2)-line) {a += " ";} else { a += "_"; }
7.           } else if (line > floor(maxLines/2)) {
8.                  if (sin((i/width)*pi*2)*(0-floor(maxLines/2)) <= line-floor(maxLines/2)) {a += " ";} else { a += "_"; }
9.           } else if (line == floor(maxLines/2)) {
10.                  a += "-";
11.           }
12.    }
13.    return a;
14. }
15.  
16. real line;
17. real maxLines;
18. real width;
19.  
20. maxLines = 21; // height in lines
21. width = 150; // width in characters
22.  
23. print("\n" + "Sine wave.");
24. print("Characters: " + to_string(width) + "\n" + "Lines: " + to_string(maxLines));
25.  
26. for(line=0; line<=maxLines;line+=1) {
27.    print(calculateString(line, maxLines, width));
28. }
29.  
30. // maxLines should be odd. eg. 9, 11, 13...

Trouwens, zou je de time-out tijd van de parser instelbaar kunnen maken? Ik ben al een paar keer over het 2500 ms limiet gegaan (dat is het limiet toch? van de oude versie in ieder geval?)

EDIT: @Maarten Baert
Kan het zijn dat de nieuwe parser iets minder snel is (~20%?). Ik kan me herinneren dat ik met bovenstaand script rond de 90 ms zat in de oude versie, nu 112 ms.

[Maarten Baert]

Strings zijn mogelijk een heel klein beetje trager, maar ik denk eerder dat ze in dit geval sneller zijn. In de vorige versie gebruikte ik mijn eigen string-klasse met ingebouwde reference counting. Nu gebruik ik wxString (afgeleid van std::string, komt uit wxWidgets) waar ik vervolgens reference counting 'rond heb gebouwd'. Dat is mogelijk iets minder efficiënt. Maar wat vooral het verschil maakt is waarschijnlijk de werking van de print-functie. In de vorige versie werd alles wat je naar print stuurde pas op het einde weergegeven, nadat het script was voltooid. Nu geef ik het meteen weer, terwijl het script nog bezig is. De tijd voor het hertekenen van dat tekstvak wordt dus ook meegerekend bij de uitvoeringstijd. Als je dezelfde berekeningen doet zonder het weer te geven met print, lijkt het juist veel sneller te gaan dan in de vorige versie .

Klein detail: je moet line, maxLines en width eigenlijk helemaal niet doorgeven, functies kunnen ook globale variabelen lezen (zelfs als ze later gedeclareerd worden, volgorde heeft geen belang). Nu verbergen de argumenten de globale variabelen (net zoals in C++), wat natuurlijk geen kwaad kan.

[Laloeka]

Ik wist niet dat globale variabelen ook zouden werken.

Het niet doorgeven van deze variabelen geeft niets tot 1 ms winst,
Het niet teruggeven van de string maar deze in de functie te printen geeft ook weinig winst,

De schermgrootte veranderen (van gemaximaliseerd naar zo klein mogelijk) geeft 30~60 ms winst.

Alle printcodes verwijderen brengt de uitvoersnelheid terug naar 3~4 ms.

In plaats van 'string' als returndatatype 'void' te geven, en verder geen return statement gebruiken heeft een opvallend resultaat: De gemiddelde uitvoersnelheid wordt 4~5 ms, langzamer dus.

Misschien wordt dit later afgehandeld in het uitvoeren van een functie en daardoor dus langzamer?

EDIT: Wat meer tests geven verschillende resultaten, in sommige functies is void inderdaad langzamer, maar in andere is string langzamer, real zit er meestal tussenin

[Maarten Baert]

Ja, het is duidelijk de print-functie die het vertraagt.

Je kan ook dit doen:

Code: [Selecteer]

string out;
for(line=0; line<=maxLines;line+=1) {
out += calculateString(line, maxLines, width)+"\n";
}
print(out);
Dit blijkt ook heel wat sneller te zijn (ja, de parser ondersteunt \n, \r en dergelijke ).

[Divendo]

Ziet er goed uit (nog niks getest hoor, dat gaat even niet met vakantie-internet). Zeker het feit dat je een soort eigen compiler hebt geschreven

Maar als ik vragen mag: waarom heb je een hele eigen taal bedacht? Dat GML niet zou voldoen snap ik en dat C/C++ (en PHP wss ook) te geavanceerd zou zijn snap ik ook. Maar voor dit soort script-dingetjes lijkt JavaScript me eigenlijk een prima kandidaat (zo denken overigens meer programmeurs er over omdat veel plugins in JS gemaakt kunnen worden). Ik heb namelijk zelf ook overwogen zoiets te maken, voor mijn programma Dalculator, zodat daar ook scripts en/of plugins voor geschreven kunnen worden. Daar ga ik uiteindelijk denk ik JavaScript als taal voor gebruiken.

Als ik weer thuis ben zal ik het even op 2 laptops, Windows 7 64-bits en 32-bits voor je testen (als dat nodig is)

Over dat reference counting: weet je dan zeker dat zo'n wxString of een gewone std::string daar niet al aan doet? Die laatste zal sowieso per implementatie verschillen, maar het is volgens mij best een handige techniek en dus denk ik dat er wel een kans is dat dat al gebeurt (of dat er een andere optimalisatie achter zit).

[Laloeka]

Ik denk dat de redenen zijn:

1. Het vlekkeloos moet samenwerken met het programma zelf.
2. Het leuk is om te maken
3. Aangezien scripts geschreven worden om simpele handelingen zo snel mogelijk uit te voeren, is het enigszins logisch dat je een eigen scripttaal gebruikt die alleen doet wat hij moet doen, en niets meer. Ik weet niet wat de snelheden van een goede Javascript parser zijn, maar ik weet bijna zeker dat langzamer is.
(4. De optie niet bekend was?)

Wat is trouwens 'reference counting', wikipedia geeft mij een onduidelijk beeld over het begrip
Het zou iets te maken hebben met of een object nog relevant is (m.a.w., of het verwijderd kan worden).

[Divendo]

Een JavaScript engine zou even vlekkeloos moeten kunnen samenwerken met het programma als dit script.

Da's wel waar Wel veel werk

Volgens mij zijn JavaScript engines ook redelijk effectief. Misschien iets minder effectief als deze, maar daarvoor in de ruil wel uitgebreider. Daarbij: de gebruiker merkt die paar ms verschil over de gehele uitvoer toch niet, maar wel dat de taal uitgebreider is.

Tja, dat kan natuurlijk ook altijd Vandaar dat ik het ff opmerk



Reference counting is, als ik het goed onthouden heb, een manier om meerdere objecten dezelfde 'kern' te laten gebruiken.
In dit geval gaat het om strings, zoals je weet is de kern van die string gewoon een rijtje (soms een heel lang rijtje) bytes.
Gezien dit nog wel eens op kan lopen kan het relatief veel werk kosten dat rijtje te kopiëren.
Wat er dan gedaan wordt is dat niet elke string een eigen rijtje bytes heeft, maar dat ze allemaal naar hetzelfde rijtje wijzen.
Zodra een string dan verandert kopieert hij pas het rijtje en past hem aan.
Ondertussen wordt bijgehouden hoeveel strings naar dat rijtje wijzen, als de laatste wordt verwijderd kan het rijtje dus ook verwijderd worden (of als de laatste wordt aangepast kan het rijtje zonder gekopieerd te worden zelf worden aangepast).

[Maarten Baert]

Maar als ik vragen mag: waarom heb je een hele eigen taal bedacht? Dat GML niet zou voldoen snap ik en dat C/C++ (en PHP wss ook) te geavanceerd zou zijn snap ik ook. Maar voor dit soort script-dingetjes lijkt JavaScript me eigenlijk een prima kandidaat (zo denken overigens meer programmeurs er over omdat veel plugins in JS gemaakt kunnen worden). Ik heb namelijk zelf ook overwogen zoiets te maken, voor mijn programma Dalculator, zodat daar ook scripts en/of plugins voor geschreven kunnen worden. Daar ga ik uiteindelijk denk ik JavaScript als taal voor gebruiken.

Het programma zal waarschijnlijk bijna uitsluitend worden gebruikt door mensen die GML kennen, dus ik wilde een taal die zo veel mogelijk op GML leek. Ik wilde ook static typing (types van variabelen liggen vast) en static binding (variabelen moeten gedeclareerd worden) gebruiken, omdat dat gewoon veel handiger is vind ik zelf. Op die manier worden veel fouten bij het parsen al gedetecteerd. Javascript voldoet aan geen van beide (ik zou trouwens niet weten waar ik een JS-parser vandaan zou moeten halen en hoe ik die dan zou moeten inbouwen).

Over dat reference counting: weet je dan zeker dat zo'n wxString of een gewone std::string daar niet al aan doet? Die laatste zal sowieso per implementatie verschillen, maar het is volgens mij best een handige techniek en dus denk ik dat er wel een kans is dat dat al gebeurt (of dat er een andere optimalisatie achter zit).

std::string is inderdaad zo gedefiniëerd dat reference-counting met copy-on-write mogelijk is. Maar de meeste moderne compilers doen het blijkbaar toch niet zo. Ik heb het gecontroleerd voor VC++. De reden is blijkbaar dat er ook een paar nadelen zijn, vooral als het ook moet werken met multithreading. Als je dat wilt doen moet elke string namelijk ook locks gebruiken voor het geval twee threads twee verschillende strings gebruiken die verwijzen naar dezelfde data. Dat kost behoorlijk veel extra rekentijd, waardoor het blijkbaar efficiënter is om het gewoon te laten vallen. Je kan eigenlijk met een paar simpele trucjes veel van de kopieeroperaties gewoon vermijden:

Code: [Selecteer]

// slecht:
void Functie(std::string str);
// goed:
void Functie(const std::string& str);
// slecht:
std::string Functie();
// goed
void Functie(std::string* output);
Het tweede is wat lastiger omdat je code er wel wat omslachtiger van wordt, maar het eerste is heel simpel. Maar voor mijn virtuele machine (het deel dat de scripts uitvoert) was het onvermijdelijk dat er veel kopies werden gemaakt, dus daar is reference counting wel handig. Voor arrays doe ik hetzelfde.

2. Het leuk is om te maken

Dat is inderdaad ook een belangrijke reden .

Snelheid was niet zozeer het probleem, ik denk dat de taal nu al veel sneller is dan iemand ooit nodig zal hebben.

[Divendo]

JavaScript was misschien niet een goede term, ik bedoelde dan ECMAscript. Ik kwam er laatst achter dat met JavaScript ECMAscript wordt bedoeld, maar dan dus de vorm die browsers gebruiken. Volgens mij (als ik me de GML syntax goed herinner) is dat ook ECMAscript.

Qt bevat een een ECMAscript engine. Die is volgens mij vrij makkelijk te gebruiken. Maar dan heb je idd geen static typing en binding, dus als je dat belangrijk vindt is het natuurlijk al uitgesloten. Hoewel, als ik het me goed herinner, GML dat dus ook niet heeft, en dan kan ik me weer voorstellen dat mensen die GML gewend zijn dat toch lastig vinden (tenzij het makkelijk is de types in elkaar om te zetten).

Maar het blijft een mooie prestatie, een eigen scripttaal maken

[Maarten Baert]

Ik heb als experiment eens getest of ik mijn MCSL demo ook kon compileren voor Ubuntu. Ik heb wel wat correcties moeten doen om het te laten werken (GCC is strenger dan VC++ blijkbaar), maar het viel uiteindelijk heel goed mee, dankzij wxWidgets. Ik weet niet echt waarom, maar de Ubuntu-versie is zelfs een klein beetje sneller dan de Windows-versie, dus dat is ook mooi meegenomen . Als het me ook lukt om OpenGL te laten werken in Ubuntu, zal het niet moeilijk zijn om dat ook te doen voor MCv6.

Voor wie het wil testen:
Download voor Windows
Download voor Ubuntu (gemaakt in 11.04, geen idee of het ook werkt voor andere versies)