Anregungen und Vorschläge zu PROFAN
Hier können Vorschläge für künftige PROFAN-Versionen, Ausgestaltung der PROFAN-Seiten und -Foren, etc. gemacht werden.

| Suchen
Seiten: 1 2 | Zurück zur Übersicht

Autor | Thema: zukünftiges Profan sollte enthalten
Sven Schmidts
| Datum:05.01.02 15:17 (schmidts@flat2serv.de) |
@All: Die Aufrufe von PROC's sollten generell optimiert werden, damit endlich rekursive Aufrufe bzw. Vorwärtsdeklarationen möglich sind, auch wenn es dann auf einen "2-way-compiler" hinauslaufen wird. Ich denke hierbei an Prototypen-Declaration, die ja schon in anderen Sprachen erfolgreich ihren Dienst tun. Bei der Gelegenheit sollte der Compiler nochmal überarbeitet werden, um z.B. automatisch die Variablen zu optimieren (Länge des Bezeichners) bzw. unnötige Variablen zu entfernen. Damit kann schonmal einiges optimiert werden. @Frank: Ich habe keine Geschwindigkeitstests durchgeführt und weiss daher nicht, wieviel Einträge in was für einer Zeit sortiert werden. Wenn Du meinen Eintrag richtig gelesen hast, dann erkennst Du, dass ich von mehr (>) als 5000 Einträgen in weniger (<) als einer halben Sek. gesprochen habe. Mehrere Elemente habe ich bisher nicht benötigt und gemessen habe ich es auch nicht. Da aber Delphi, wie schon gesagt, genau wie C oder C++ native Code erzeugen, bin ich mir nahezu sicher, dass der Geschwindigkeitsunterschied nicht die Welt sein wird. Da wir hier aber über Profan² reden und hier selbst 1000 Einträge in einer Sekunde astronomisch schnell sind sollten wir das Thema besser einschlafen lassen, ok? Ich denke aber, Roland sollte nicht soviel Zusatzfunktionen einbauen, sondern erst einmal an rudimentären Funktionen arbeiten. Wer sich einmal die Klassenbibliotheken von führenden Sprachen angeschaut hat wird sehen, dass der "Grundschatz" an Befehlen < 150 ist. Und mit diesen wenigen Befehlen werden weitere zusammengebastelt. Bestes Beispiel hierfür sind RISC Prozessoren (Alpha) die mit wenigen Befehlen schneller sind als CISC Prozessoren (Intel). Ich denke, anschliessend kann man an guten Bibliotheken arbeiten, die dann durchoptimiert sind. So müssen endlich CallBack Funktionen rein, ausserdem diverse Datentypen, um z.B. grundsätzlich TCP/IP zu integrieren, die ja auf der WinSock.DLL basiert. Dann könnte man sich auch die FTP-Engine sparen. Das aber nur als kleines Beispiel. Thomas Hölzer hat hier seinerzeit gute Anfänge gemacht, in dem er neue Möglichkeiten, Funktionen und Prozeduren einfach als eine Art Bibliothek integriert hat. Mfg. Sven Schmidts
René Wagner
| Datum:05.01.02 16:36 (apollo@rw-net.de) |
Wo wir mal wieder bei zwei grundsätzlichen Problemen wären: Geschwindigkeit und Grösse der Runtime. Ich denke FTP-Funktionen gut und schön (hab ja sogar die 7.5 subscription bestellt), aber das macht die Runtime gute 100 kB grösser. Für mich absolut indiskutabel. Zumal ich der Meinung bin, dass FTP-Funktionen nicht zwangsläufig in eine Programmiersprache gehören. Daher kann ich Sven in seiner Meinung nur unterstützen: Man sollte sich auf die grundlegenden Sachen beschränken, die vorhandenen Funktionen und Befehle wo möglich optimieren (auf Geschwindigkeit und Runtime-Grösse) und eventuell auf sinnvoll! erweitern (wie Stefan´s erstes Beispiel für inc, was ich für sinnvoll halte). :) Soweit meine bescheidene Meinung dazu. :) mfG, René
Sven Schmidts
| Datum:05.01.02 17:06 (schmidts@flat2serv.de) |
Zum Thema FTP kann ich was sagen, weil ich daran mit entwickelt habe ;) Die FTP-Engine basiert auf komplexen TCP/IP Routinen, was natürlich die EXE vergrößert, wobei ja heutzutage 400 KByte EXE Dateien ohne Komprimierer schwer zu finden sein dürften. Mit diesem "Bruch" in der Dateigröße sind aber automatisch zukünfigte Funktionen abgedeckt. Wenn also mal HTTP mit reinkommt, oder, was ja traumhaft wäre, eine direkte TCP/IP Unterstützung, dann würde in dem Fall die EXE Datei nur ein wenig größer, wenn überhaupt. Und da TCP/IP so nicht so ideal integriert werden können (zumindest nicht ASynchron) war diese Kapselung praktisch Pflicht. Mfg. Sven Schmidts
Stefan Stroehlein
| Datum:05.01.02 17:57 (eMailTo@StefanStroehlein.de) |
mein erster eintrag hat mittlerweile ein ausmaß angenommen den ich zu ko... finde. jeder hat eine andere meinung. der eine sagt runtime vergrößerung nur wenn sie zugunsten von 'xxx' ist, dem nächsten ist dieses 'xxx' sch... egal. und eine diskussion um die größe der runtime ist einfach lächerlich. heutzutage sind 100te von megabyte hauptspeicher und 50 gigabyte hd standart. also was soll der sch.... und wenn ihr schon so an euren 300kb hängt, dann gönnt mir doch wenigsten biblioteken, die wie in c eingebunden werden können. !!!! webmaster schließe bitte diesen teil des forums !!!! mfg der urheber dieser unsinnigen diskussion
Thorsten
| Datum:05.01.02 19:35 (mrk@mrk-soft.de) |
> ... heutzutage sind 100te von megabyte hauptspeicher und >50 gigabyte hd standart. also was soll der sch.... Ich sehe schon die Zukunft so in ca. 10 Jahren weiter, Standart: 50 Terrabate Platten, 10 Gigabyte Arbeitsspeicher, und ein Programm "Hallo Welt" hat dann mal locker 6 Giga, weil eine Runtime !! ca. 100.000 Befehle Umfast. Aber wass solls, ist doch Standart, bei 50 Tewrrabyte Platten, und über 10 Giga Arbeitsspeicher, was solls .... (merkst du noch was !!!!) (( Was ist in 30 Jahren, sollen es dann 20 Giga byte "Hallo Welt" werden, weil die Grafik Energie schon alleine 15 Gigabyte beansprucht. aber bei 100.000 Quanti Byte (Millionen von Terrabyte) Platten und über 100.000 Giga Byte Arbeitsspeicher ist das ja egal. )) >und wenn ihr schon so an euren 300kb hängt, dann gönnt mir >doch wenigsten biblioteken, die wie in c eingebunden werden > >können. Dann erstell dir doch eine eigene Bibiliothek, als Include oder $H Datei. Sondersachen, die nur für ganz Spezielle Aufgaben benötigt werden, lassen sich als DLL schön Archivieren. Nenene, Meinung hin oder Meinung her, und jeder soll seine eigene Meinung haben. Allerdings habe ich in Zukunft keine Lust, ein Programm auf CD ausliefern zu müssen, weil die Runtime irgendwann mal 1 Megabyte erreicht hat, und nicht mehr auf eine Diskette passt. (obwohl die ja eh am aussterben sind). Thorsten
Stefan Stroehlein
| Datum:05.01.02 22:05 (eMailTo@StefanStroehlein.de) |
@torsten sind wir doch mal ehrlich, die größe eines fertigen programmes hängt letztendlich von der leistungsfähigkeit des linkers ab. die dlls die einbinde sind mit pb/dll6.1 geschrieben. dieser compiler beinhaltet was weis ich wieviele befehle, auf jedenfall ein vielfaches von profan. dank der vielen befehle hat der quellcode nur ca. 12kb und jetzt halte dich fest die dll hat nur 17kb. also erzähl mir nicht das ein umfangreicher befehlssatz zwangsläufig eine große runtime benötigt. und außerdem wenn du nicht willst das der ram- und hd-wahnsinn weitergeht, warum benutzt du eigentlich windows? oder meinst du das ein kleines blatt papier das beim kopieren über den bildschirm flattert die programm runtime optimiert.
Sven Schmidts
| Datum:05.01.02 22:16 (schmidts@flat2serv.de) |
Stimmt, wir sollten diesen Thread schliessen. Aber nochmal zum letzten Link: Der Linker macht garnichts kleiner, es ist der Compiler. Und dann kannst Du PBasic nicht mit Delphi (unter dem Profan² erstellt wurde) vergleichen ... Delphi hat eine Klassenbibliothek dahinter, die sich gewaschen hat. Du kannst in Delphi Dinge machen, von denen PBasic nur träumt, zum Beispiel ist der Delphi Editor selbst in Delphi geschrieben, Map&Guide und Nero-Burning wurden grösstenteils (so 100% weiss man das ja nie ;)) in Delphi geschrieben ... Bitte nicht einen Golf mit einem Porsche vergleichen, sowas macht keinen Sinn. Jedes Tool hat seine Daseinsberechtigung. Aber es geht ja letzendlich um Profan², um Programmiersprachen gibt es genügend andere Diskussionsforen! Mfg. Sven Schmidts
Thorsten
| Datum:06.01.02 08:21 (mrk@mrk-soft.de) |
>und außerdem wenn du nicht willst das der ram- und hd- >wahnsinn weitergeht, warum benutzt du eigentlich windows? Weil fast ausschlislich jeder "Furz" Treiber von meiner Hardware nur für WIN erhältlich ist, ich von LINUX absolut nix halte, (ist nur ein Text-Dos, mit aufgesetztem Grafik Kern), es für meine Video MPG2-Grabber Karte eh nur Treiber für Windows gibt, und um Kompatible für andere zu bleiben, den zu 90 % alller benutzen Windows.
Dennis Schulmeister
| Datum:10.01.02 20:19 (dennis.schulmeister@web.de) |
Hallo, So wie Thorsten es sagt, ist es. 90% benutzen Windows, folglich gibt es fast nur Windowstreiber für alle mögliche Hardware. In die RAM- und HD-DIskussion möchte ich mich sonst nicht einmischen. Bin in letzter Zeit selber zum Mutlimedianer geworden. Denn, wenn es die Möglichkeit schon gibt, wieso sollte ich sie dann aus Prinzip nicht nutzen? Im Ursprungsbeitrag ging es um Verbesserungsvorschläge für Profan. Nun, mein Vorschlag währe eben die Rekursion für Prozeduren. Irgendwo habe ich auch noch einen Code rumfahren, wo ich das trotz Struktur wirklich gebraucht hätte. Oder eben, erst wegen der Struktur im Code! Nun gut, letztendlich beleibt es Rolands Entscheidung, was Profan können bzw. nicht können wird. Dennis :D
Sven Schmidts
| Datum:11.01.02 09:28 (schmidts@flat2serv.de) |
Letztendlich entscheiden es die User, weil die es bezahlen ;)
Daniel Hecken
| Datum:12.01.02 18:35 (privat@daniel-hecken.de) |
Hallo, Wenn man beispielsweise im Explorer auf eine EXE Datei mit der rechten Maustaste und dann auf Eigenschaften geht, erecheint dort ja Versionsinformationen bei manschen Anwendungen. Ich stelle mir das mit Profan so vor: 1. Möglichkeit Ein neuer Helfer, der eine extra Datei ablegt. Beim Linken greift der Linker eben auf diese Datei ( die die Informationen beinhaltet ) aus, und schreibt die auch in die EXE Datei. 2. Möglichkeit In den ersten Zeilen eines Programmes kann man folgende Zeilen schreiben: setversion = "1.0" setsprache = "Deutsch" setcopyright =" ... " uns so weiter gruß Daniel
Jörg Sellmeyer
| Datum: 12.01.02 19:06 (joerse@gmx.de) |
Das läßt sich mit dem Reshacker komfortabel und Script-gesteuert eredigen: http://rpi.net.au/~ajohnson/resourcehacker/ Jörg

Seiten: 1 2 | Zurück zur Übersicht

| Ein kostenloses WebMart Forum WebMart Homepage Tools kostenlos |