The Perseus Programming Language

  • Wenn Perseus AutoIt-Code compilieren würde, wären mir die 13 Gig SCHEISSEGAL 8o


  • Du sagst es selber. Du lieferst nur einen Compiler und Syntax-Highlights + Calltips für Editoren. Das ist bei weitem keine IDE. Visual Studio wirft dir 13 GB an den Kopf. Darin enthalten sind, ein eigenständiger Compiler, eine eigenständige IDE, Hilfe, Dokumentation und noch sehr sehr sehr viel mehr.

    Jo. Genau dieselben Features kamen auch schon mit Visual Studio 6. Das war nur ein paar hundert MB groß, kompiliert nativ und läuft bis heute (Win 95 bis Windows 10 - das soll mal jemand nachmachen :D ).

    Achso, keine Angst vor den Klassen. Es soll bloß eine "andere" Schreibweise von UDF_Func (jetzt Klasse.Funk / Klasse.Var [= Wert] / Klasse. usw.). Im Code schlägt sich das nicht so wieder. Im Screenshot ist ein extrem "sauberer" Code zu sehen. Das Klassenmodell ist vor allem für zukünftige Standardfunktionen gelten (in den Includes und im Compiler selbst).

    Perseus 2.x bis 4.x hatten keine eigenen Funktionen.
    Perseus 5.x hat bis jetzt eine Compiler-Funktion (Format) und ein seperates String-Include
    Die neue Version hat dann eine String-Klasse. Also Aufruf per (Strings.Funktion). Dann gibt es auch besseres Speicherhandling, zum Beispiel das Ersetzen des Standard-Buffers:

    Code
    string OwnBuffer[128];
    Strings.DefBuffer = @OwnBuffer

    oder so ähnlich :) .

    Weiterhin ist auch die Minimierung der Semikolon-Pflicht vorgesehen.

    Wenn Perseus AutoIt-Code compilieren würde, wären mir die 13 Gig SCHEISSEGAL 8o

    Was ist AutoIt eigentlich? Ein Sammlung von Funktionen, welche die WinAPI so dermaßen abstrahieren, dass tonnenweise neue Probleme enstehen:

    GuiCtrlCreateButton ist eine Standard-Klasse
    GuiCtrlCreateCombo ist eine CommonControls-Klasse (muss erst initialisiert werden)
    GuiCtrlCreateGraphic ist nichtmal ein Control, sondern ein abstrakter Wrapper für GDI

    das führt zu einer komplexen Überladung jeder AutoIt-Funktion (wie GuiCtrlSetData), was wiederrum für etwa 50% der Hilfethreads verantwortlich ist. ;)


  • Achso, keine Angst vor den Klassen. Es soll bloß eine "andere" Schreibweise von UDF_Func (jetzt Klasse.Funk / Klasse.Var [= Wert] / Klasse. usw.). Im Code schlägt sich das nicht so wieder. Im Screenshot ist ein extrem "sauberer" Code zu sehen. Das Klassenmodell ist vor allem für zukünftige Standardfunktionen gelten (in den Includes und im Compiler selbst).

    Perseus 2.x bis 4.x hatten keine eigenen Funktionen.
    Perseus 5.x hat bis jetzt eine Compiler-Funktion (Format) und ein seperates String-Include
    Die neue Version hat dann eine String-Klasse. Also Aufruf per (Strings.Funktion). Dann gibt es auch besseres Speicherhandling, zum Beispiel das Ersetzen des Standard-Buffers:

    Code
    string OwnBuffer[128];
    Strings.DefBuffer = @OwnBuffer

    oder so ähnlich :) .

    Weiterhin ist auch die Minimierung der Semikolon-Pflicht vorgesehen.

    Ok das klingt schonmal besser. kannst du das hier irgendwie aus der installation raushalten und das ganze portabel für usb sticks machen? "regsvr32 the prsco.dll file as admin"

    Einen autoit compiler finde ich keine gute idee. minx müsste sich mit so viel zeugs rumschlagen und außerdem ist im originalen autoit code ja nichtmal threading vorhanden. wie soll er das in die syntax gescheit einabauen? darauf möchte sicherlich keiner freiwillig verzichten.

  • kannst du das hier irgendwie aus der installation raushalten und das ganze portabel für usb sticks machen? "regsvr32 the prsco.dll file as admin"

    Ist doch schon längst getan. Wie gesagt, komplette Überarbeitung des gesamten Source (was auch nötig war, um überhaupt an Open Source zu denken).

  • im moment verhält sich der compiler/übersetzer auch noch komisch. aus den fehlern die er ausspuckt wird man nicht schlau und ich bin fast schon davon überzeugt das ich keinen fehler mache^^ das muss also umbedingt ausgebessert sein sonst kann man mit der sprache nicht produktiv arbeiten. die fehlerbeschreibung aus dem screenshot sieht schonmal sehr gut aus^^
    Falls du wissen möchtest welchen code ich versucht habe zu kompilieren kann ich dir den gerne nochmal raussuchen

  • Dafür muss man sich registrieren glaube ich. ich habe aujedenfall ohne account keine möglichkeit gefunden ein ticket zu senden.
    Im moment hab ich noch kein bedürfniss mich bei sf zu registrieren und ich weis ja nichtmal ob es ein bug oder ein fehler von mir ist^^
    Ich hoffe mal die fehlerbeschreibung und die syntax erkennung der neuen version wird besser:)

    Also ich habe das hier versucht um eine 18bytes große .txt datei auszulesen. der compiler beschwert sich bei meinem typ FileOfStruct. diese struct stellt das objekt dar das OpenFile befülle sollte.
    Außerdem hatte ich es nicht hinbekommen bei string buffer[18]; die 18 durch FileOfStruct.cBytes zu ersetzen. cbytes sollte die richtige datei größe darstellen und nicht die auf der festplatte.

    Spoiler anzeigen

  • Hier ein Ausschnitt aus einem anderen Programm, das funktioniert:


  • ok danke habe jetzt verstanden was ich gemacht habe.
    also ich hab versucht mir viel selber im msdn zusammenzusuchen und das so in perseus umzusetzen

  • Was ist AutoIt eigentlich? Ein Sammlung von Funktionen, welche die WinAPI so dermaßen abstrahieren, dass tonnenweise neue Probleme enstehen:

    GuiCtrlCreateButton ist eine Standard-Klasse
    GuiCtrlCreateCombo ist eine CommonControls-Klasse (muss erst initialisiert werden)
    GuiCtrlCreateGraphic ist nichtmal ein Control, sondern ein abstrakter Wrapper für GDI

    das führt zu einer komplexen Überladung jeder AutoIt-Funktion (wie GuiCtrlSetData), was wiederrum für etwa 50% der Hilfethreads verantwortlich ist.

    Wenn du das wirklich ernst meinst, dann frage ich mich, wieso du nicht einen massiv gepimpten Assembler (MasmBasic, JWasm) nimmst, statt einen Compiler, der doch sowieso nur ein Abklatsch der bestehenden "abstrahierenden" Sprachen darstellt?!
    Wasch mich, aber mach mich nicht nass! 8)

    Entweder man "wrappert", oder man called die API nativ.
    Ich persönlich bin dann fürs wrappern, wenn man dazu bei immer wiederkehrenden Abläufen EINE Funktion mit Parametern versorgen kann. Und diese wiederum verteilt diese Parameter dann an zig andere (meinetwegen API-) Funktionen.
    Nichts anderes ist Klasse.Func oder Funktionen aus jedweger Bibliothek!
    Eine Bezeichnung für eine ganze Latte Code!

    Der Eiertanz zwischen der nativen Verwendung von API-Funktionen (früher aus dem BIOS gecalled) und dem Vorhaben, den Usern Schreibkram abzunehmen (nichts anderes machen HLL), ist so alt wie die Programmiersprachen selbst.
    Die Frage ist jetzt, ob man, wie bei AutoIt, Funktionen "überlädt" und damit für die 08/15-User einfach handlebar macht, oder ob man den "richtigen" Programmierern (höhö) ein flexibles und schnelles Werkzeug an die Hand gibt!

    Einen autoit compiler finde ich keine gute idee. minx müsste sich mit so viel zeugs rumschlagen und außerdem ist im originalen autoit code ja nichtmal threading vorhanden. wie soll er das in die syntax gescheit einabauen? darauf möchte sicherlich keiner freiwillig verzichten.

    Passt zum Thema!
    "Mit Zeugs rumschlagen" ist genau das, was ich oben geschrieben habe, gemeint.
    Die schönen "gewrapperten" Funktionen wieder auseinanderdröseln....
    Aber das macht JEDER Compilerbauer!

    Auf die Frage, wie Threading in die AutoIt-Syntax einzubauen ist, nehme ich keine Stellung. Ich frage mich nur, wieso "keiner darauf verzichten will", aber Threading in maximal 0,1% aller Programme eingesetzt wird?! Und in den mir bekannten AutoIt-Scripten überhaupt keinen Sinn machen würde, weil dafür garkein Bedarf besteht!
    Wobei ich persönlich übrigens der Meinung bin, dass SIMD wesentlich mehr bringt als Threading...

    Die Frage ist sowieso eine ganz andere, nämlich ob moderne Rechnerarchitekturen überhaupt von der heutigen Software abgedeckt werden!
    Wer heutzutage einen Compiler baut, der sollte sich auch fragen lassen (müssen) ob die in den heutigen Prozessoren vorhandenen Features abgedeckt werden!
    Oder soll man für "spezielle" Softwareanforderungen einfach nur hochoptimierte Bibliotheken einbinden?!
    Was die Frage erlaubt, wozu man dann einen Compiler baut, wenn ein Interpreter (*hust*) die hochoptimierte Funktion aus der Bibliothek genauso schnell ausführt?!

    Zitat

    ...was wiederrum für etwa 50% der Hilfethreads verantwortlich ist.

    Wann hast du das letzte Mal ein Java/C(++)/Fortran/ADA/E/Android/wasauchimmer-Forum besucht?
    Die Hilfethreads könnten also vermieden werden, wenn "einfachere" Funktionen verwendet werden? :rofl:
    Auf 95% der Hilfethreads könnte man antworten: "Lies MSDN, da steht alles!" oder einfach RTFM!
    Schon seltsam, dass man diesen Hinweis einem "Programmierer" überhaupt geben muss...

    ciao
    Andy


    "Schlechtes Benehmen halten die Leute doch nur deswegen für eine Art Vorrecht, weil keiner ihnen aufs Maul haut." Klaus Kinski
    "Hint: Write comments after each line. So you can (better) see what your program does and what it not does. And we can see what you're thinking what your program does and we can point to the missunderstandings." A-Jay

    Wie man Fragen richtig stellt... Tutorial: Wie man Script-Fehler findet und beseitigt...X-Y-Problem

    Einmal editiert, zuletzt von Andy (22. Dezember 2014 um 02:18)

  • 7 MB o.o
    Was hast du denn da alles drin? Das ist ja schon beinahe unverschämt... :S

    Ich habe leider immer wieder ein Problem mit SourceForge. Ich kann da rein gar nichts downloaden. Wäre jemand so nett und würde den Download evtl. hier zur Verfügung stellen?


  • Passt zum Thema!
    "Mit Zeugs rumschlagen" ist genau das, was ich oben geschrieben habe, gemeint.
    Die schönen "gewrapperten" Funktionen wieder auseinanderdröseln....
    Aber das macht JEDER Compilerbauer!

    Auf die Frage, wie Threading in die AutoIt-Syntax einzubauen ist, nehme ich keine Stellung. Ich frage mich nur, wieso "keiner darauf verzichten will", aber Threading in maximal 0,1% aller Programme eingesetzt wird?! Und in den mir bekannten AutoIt-Scripten überhaupt keinen Sinn machen würde, weil dafür garkein Bedarf besteht!
    Wobei ich persönlich übrigens der Meinung bin, dass SIMD wesentlich mehr bringt als Threading...

    Also ich brauche bestimmt in 70% aller anwendungen threads(Ich programmiere hauptsächlich in c# und die verwendung von threads ist dermaßen einfach das ich mir immer überlege ob man programmcode sinnvoll in einen thread packen kann). Wenn mans genau nimmt in noch mehr da ich mindestens einen gui thread habe und einen der den programmcode abarbeitet....(kommt halt immer drauf an was man macht)
    Damit wollte ich nur nochmal verdeutlichen das man sich schon weit von autoit entfernen sollte und nur sinnige features übernehmen kann. Und wenn er einen autoit übersetzer bauen würde dann hätte man nur den geschwindigkeitsvorteil von einem nativen programm in autoit. das überzeugt mich nicht davon perseus zu verwenden anstatt andere schon länger etablierte und getestete sprachen.

    Was mich an perseus überzeugt ist:
    1.)Man hat eine minimal gehaltene ide und einen kleinen compiler. das ganze verbraucht quasi 0 speicher und man muss nicht viel herunterladen oder updaten
    2.)Man hat keine projektdateien wie bei C#, C++, Java
    3.)Die sprache ist(finde ich) einfacher als normaler assembler bietet mehr umfang und ist trotzdem nicht so komplex wie c++
    4.)Die output datei ist sehr klein und besteht nur aus nativem code

    @Über mir: http://sourceforge.net/projects/perse…latest/download

  • @Über mir: Lies nochmal :rolleyes:

    dann erklär mal warum bei dir da entweder kein download startet oder du nicht auf direct link klicken kannst. vielleicht noscript aktiviert?

  • Das kann ich dir leider nicht sagen. Vielleicht liegt es an Chrome oder einfach nur meiner lahmarschigen 5~7 kb/s Leitung. Es könnte auch sein dass ich irgendeine Software installiert habe welche schlichtweg Downloads von SourceForge blockt. Wenn ich das wüsste hätte ich mir nicht die Mühe gemacht nachzufragen ob jemand netterweise den Download hier im Forum zur Verfügung stellt...

    Fakt ist: Ich bekomme einfach den Download nicht gestartet.

    Hoffentlich war das nun unmissverständlich ausgedrückt.
    Sorry wenn das jetzt so unfreundlich rüber kommt, aber mir kommt es vor als ob du mich hier als total bescheuert darstellen möchtest. Und ich habe gerade auch nicht die beste Laune für solch einen Kindergarten.