Dank Deiner Veranschaulichung hab ich das jetzt begriffen. Mir war der Ablauf (Die Kette) nicht so ganz klar.
Das habe ich gemerkt. Aber mach dir nichts draus, vielen ist diese Kette nicht klar.
Wie gesagt, es lässt sich im Grunde auf dieses hier reduzieren:
Code: Alles auswählen
Browser --> Webserver --> CGI --> Interpreter --> Compiler --> Executable
Außer beim Browser muss man natürlich nur wissen, dass die ganzen Programme untereinander über Konsolen kommunizieren. Das ist das ganze Geheimnis! Soweit war ich beim Entwickeln des PB Interpreters auch schon. Man muss nur noch rausfinden, welche Parameter die Programme erwarten und was sie ausgeben.
Ich hatte natürlich das /QUIET rausgenommen, da ich eine Meldung haben wollte. Nachdem ich das nun wieder
eingebaut hatte, lief das Ding endlich. Und ich hab mir schon das Hirn zermartert....
Natürlich darfst du gerne das /QUIET rausnehmen. Aber dann musst du die Ausgabe des Compilers auswerten. Und wie gesagt, diese Auswertung ist mir zu kompliziert und lohnt sich meiner Meinung nach auch nicht. Was bringt es dir oder dem Besucher, wenn der Compiler meckert, dass Library XY nicht gelinkt werden konnte? Also: Entweder Erfolg oder Fehler.
Wenn du das /QUIET rausnehmen möchtest, müsstest du die Compilerausgabe prüfen, ob sie den String "Creating executable XY" enthält. Das ginge per FindeString() oder MatchRegularExpression(). Aber: Diese Untersuchung kostet Zeit. Vielleicht nur Millisekunen, aber dennoch ist es meiner Meinung nach nicht lohnend.
Dann hätte ich nur noch eine Frage
Das OpenConsole()..... kann man es irgendwie umgehen, dass es aufblitzt (sich kurz in den Vordergrund drängt und den Fokus klaut) ?
Also entweder dauerhaft offen sein lassen, oder eben verstecken beim aufrufen wie mit HideWindows bei Fenstern ?
Auflassen geht. Dafür müsstest du in deinem Skript (test.pb), ein Input() setzen, da dein test.pb ja eine Konsolenanwendung ist.
Aber wozu?
Du möchtest ja eh nicht in den Prozess eingreifen, also kannst du das Fenster natürlich verstecken. Das geht ganz einfach: Mit #PB_Program_Hide!
Such dir einfach die RunProgram()-Zeile, wo der PB Interpreter das Executable aufruft und füge diese Konstante noch mit ein. Ach ja: Und dann versteck doch auch das zweite Konsolenfenster, welches ja vom Kompiler immer erstellt wird!
Ich lobe die obige ausführliche Antwort ! Dafür gibts den Erklärbär
Vielen Dank!!
Ich freue mich riesig über dieses Lob! Sowas gibt mir die Motivation, weiter zu machen.
Zugegeben: Zurzeit arbeite ich gar nicht mehr mit PB (schon seit 4.30 nicht mehr), mangels Zeit. Aber ich träume davon, von meinem popeligen Windows-Server wieder auf einen Linux-Server umzusteigen. Sollte ich dann eine Webseite bekommen, möchte ich sie gern in PB umsetzen.
Mal eine Gegenfrage: Wie weit hast du die Arbeitsweise des PB Interpreters denn verstanden?
Pro Seitenaufruf (!) eines Skriptes schmeißt der Webserver den PB Interpreter an und dieser wiederum ruft den Compiler und anschließend das Executable auf. Nach dem Aufruf der EXE wird diese in v1.0 wieder gelöscht, um Speicherplatz (kostbaren Webspace) freizugeben. Dieses Verhalten wird auch durch den Parameter -f bzw. --force in späteren Versionen erzwungen.
Nachteil: Diese Routine kostet extrem viel Zeit. Auf meinem kleinen virtuellen Server damals mehr als 250 ms, bis die HTML-Ausgabe an den Browser gesendet wird!
Daher lösche ich die Executables ab Version 1.1 standardmäßig nicht mehr. Sie bleiben im Temp-Ordner. Beim Aufruf werden sie einfach erneut ausgeführt und das ist der Clou: Die Zeit bis der Webserver dem Client eine Antwort senden kann fällt auf unter 1 ms! (Auf meinem Server jedenfalls.) Dies ist sogar schneller als gewöhnliche PHP- oder Perl-Skripte! Wieso? Nun, ein Skript zu interpretieren ist immer zeitaufwändiger (einlesen, auswerten, ausführen), als eine fertig kompiliertes Executable auszuführen, denn dieses wurde bereits einmal eingelesen und ausgewertet. Ich habe den PB Interpreter sogar so programmiert, dass er das Executable automatisch neu kompiliert, wenn sich der Source Code seit der letzten Kompilation verändert hat (ÄnderungsdatumSkript > ErstellungsdatumExecutable). Wenn das kein Service ist!
Nachteil: Da die Executables auf der Festplatte behalten werden (auch wenn es das Temp-Verzeichnis ist) wird doppelt Speicher belegt, denn einmal brauchen die Skriptdateien und das Executable Platz. Aber du erkennst meinen guten Willen: Ich habe die Möglichkeit eingebaut, die Executables mit UPX komprimieren zu lassen (Parameter -c bzw. --compress).
Die Zeit, die zur Erstellung des Executable benötigt wird, wird vom PB Interpreter gemessen und deinem Skript als Environmentvariable zur Verfügung gestellt. Wenn du in deinem Skript also
Code: Alles auswählen
Print(GetEnvironmentVariable("PB_Interpreter_CreationTime")
schreibst, siehst du die Anzahl der Millisekunden, die es brauchte, vom Aufruf des Interpreters durch den Websever, über den Kompilierungsvorgang bis zum Aufruf des Executable.
Tipp: Geh mal den Source Code durch und schau, welche nützlichen PB_Interpreter_* Umgebungsvariablen der Interpreter deinen Skripten zur Verfügung stellt!
Ich als PB Interpreter versuche stets, dir als PB Skript möglichst viel Arbeit abzunehmen und Informationen zur Verfügung zu stellen.
Tipp: Der Webserver Apache stellt einem Skript in Form von Umgebungsvariablen ebenfalls relevante Infos zur Verfügung (REMOTE_ADDR, QUERY_STRING, usw.). Diese werden eigentlich dem Interpreter übergeben, aber dieser vererbt sie automatisch auch an dein Executable, welches diese Environment-Variablen auslesen kann.
Tipp: Die QUERY_STRING Umgebungsvariable enthält die URL-Parameter. Mein PB Interpreter wertet diese automatisch aus und stellt sie deinem Skript zur Verfügung. Das heißt: Wird die Seite test.pb?name=Peter&alter=23 aufgerufen, werden deinem Skript die Environmentvariablen GET_name und GET_alter zur Verfügung gestellt. Diese kannst du mit GetEnvironmentVariable() lesen.
Der Source Code des PB Interpreters hat geschrieben:Code: Alles auswählen
; for convenience, we provide all QUERY_STRING-parameters as environment variables for the program:
; the URI "www.and51.de/index.pb?site=downloads&sort=asc" would create the environment variables
; "GET_site" with the value "downloads" and "GET_sort" with "asc". then you can easily catch them with the
; GetEnvironmentVariable() command. caution: you must decode them manually if neccessary with URLDecoder()
If GetEnvironmentVariable("QUERY_STRING") And GetEnvironmentVariable("REQUEST_URI") ; check first param, but extract informations from second param
Define query_exp=CreateRegularExpression(#PB_Any, "(?U)(?<=&).+(?==)")
Dim querystrings.s(0)
Define i, n=ExtractRegularExpression(query_exp, "&"+GetEnvironmentVariable("QUERY_STRING"), querystrings())
For i=1 To n
SetEnvironmentVariable("GET_"+querystrings(i-1), GetURLPart(GetEnvironmentVariable("REQUEST_URI"), querystrings(i-1)))
Next
SetEnvironmentVariable("PB_Interpreter_QueryStrings", Str(n))
EndIf
Wie gesagt, ein Blick in den Source Code offenbart so einiges! Setz dich ruhig mal mit nem Kakao davor und zieh dir das als Roman rein
So viel zu meiner Frage, wie weit du die Arbeitsweise des PB Interpreters nachvollziehen kannst.
