Hallo Lord Horazont,
Bin ein bisschen spät dran weil ich einige Zeit gebraucht habe, um mein neues System aufzubauen und das alte dafür "ausgeweidet" habe, da gab es eine Zeitling keinen Internet-Access.

Ich habe das Beta heruntergeladen.

Als erstes habe ich die beigelegte EXE laufen lassen. Ging ausgezeichnet.

Als zweites hab ich es in ein neu installiertes Lazarus (Version 0.9.24) geladen und kompiliert. Ergebnis: es wurde kompiliert, aber mit Warnungen. Ich hänge mal diesen Output hier dran (das betrifft nur die Hauptunit, weiß nicht, ob das etwas hilft).

Bei der Programmausführung gab es einen SIGSEV. Meldung: Ausführung angehalten, Adresse $100089A1, Prozedur U_VARIANTS_I.

System: Windows XP SP2 (noch ganz frisch, nicht upgedated) mit einer Intel dual core CPU.

Traude


EDIT: ACHTUNG, die Neuinstallation von meinem Lazarus funktioniert nicht. Es liegt also NICHT an Deinem Code. Ich muss das Problem hier bei mir erst in den Griff kriegen. Melde mich wieder.
Traude

Ja, an den Warnings muss ich noch arbeiten, das ist ein bekanntes Problem. Ich wollte es eigentlich vor dem Release machen, aber ... naja, war halt spät, da hab ich das vergessen. Im nächsten sind die draußen, das ist alles halb so wild, dürfte aber eigentlich zu keinen größeren Problemen führen, weil die zum großen Teil die Extended Types betreffen, die im Moment eh noch nicht wirklich verwendet werden können.

Die SigSegV... Sollte nicht auftreten, nicht, wenn du nichts am Code geändert hast. Ich vermute, dass es tatsächlich an deinem Lazarus liegt. Welches FPC verwendest du? 2.2.0 oder schon 2.2.2? Ich habe Thorium mit 2.2.2. compiliert, vielleicht ist das auch ein Problem (in der aktuellen Lazarus-Version ist das glaube ich nicht dabei, kann man aber dazuinstallieren. Einfach in das fpc-Verzeichnis im Lazarus-Verzeichnis nen neuen Ordner 2.2.2. anlegen und da dann FreePascal reininstallieren, danach noch in Lazarus umstellen und läuft. Allerdings sind Lazarus-Projekte, die Fenster verwenden noch mit 2.2.0. zu kompilieren, bis die das selber mitliefern, das läuft so noch nicht rund).

//Edit: Ich seh gerade, du hast nen neuen Thread angefangen. Gab doch schon nen alten. Kann das mal nen Mod zusammenfügen?

Aber danke fürs Feedback

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Tschuldigung, hab ich nicht gesehen.

Ich habe mir in der Zwischenzeit den Lazarus 0.9.26 besorgt (der hat nämlich FPC 2.2.2. dabei). Es ist zwar innerhalb von Lazarus so ähnlich wie vorher (es kompiliert, aber er gibt eienen SIGSEV heraus). Aber wenn man Lazarus verläßt und das Test-Programm aus Windows heraus aufruft, funktioniert es genauso, wie die mitgelieferte EXE. Schuld kann nur der GDB sein (seufz).

Durch diese ganzen Fehler bin ich noch ger nicht dazu gekommen, mir das Programm selber anzusehen.

Also die erste Funktion is klar: er addiert zwei Zahlen, das funktioniert jedesmal. Aber was ist das "Flow Control"? Da bin ich nicht drauf gekommen auf die schnelle.
Traude

Flow Control ist die Kontrolle des Programmflusses, also If, For und so nen kram (im Test wird aber nur If verwendet). Wenn du dir die mitgelieferten Scripts, demoscript.txt und demo.lib.txt anschaust, da ist ja der Scriptsource drin.

Ich hätte im Test gerne Switch verwendet, aber das zerlegt im moment einen Teil der Kontrollstrukturen, inklusive sich selbst übrigens.

Dass der GDB verreckt kann an den massiven optimierungen (teilweise Debugger-Unfriendly) liegen, die FreePascal in die Thorium.pas hauen soll. Anders kann ich mir das nicht erklären. Aber bei mir läuft das ganze erstaunlicherweise auch mit GDB einwandfrei.

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Ich habe mir die letzte Release von Thorium heruntergeladen, aber bis ich dazu etwas sagen kann, vergeht eine Weile: 13.000 Code Zeilen ist ganz schön heftig, das erledigt man nicht mal grade so nebenbei. Und ich bin beschäftigt, nämlich mit dem Testen eines OpenGL-String-Grids, diesmal hübsch ordentlich gemäß der Delphi7-Definition gebaut.

Hu, dass sich jemand den Code komplett durchliest hätte ich nicht erwartet, aber ich bin auf jeden Fall gespannt auf dein Urteil. Ich habe mich bemüht, möglichst viel zu kommentieren - hat leider gerade in den letzten Tagen nicht immer funktioniert . Wenn du also Fragen hast, hier oder per PM oder so.

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Also erstmal finde ich das Projekt sehr gut. Habs mir jetzt mal gezogen und werd mir auch einiges darin ansehen (Bin immer noch dran eine eigene kleine SL zu proggen ).
Aber was ich nicht verstehe: wieso ist das so C-ähnlich?

mfg Flö

_________________
Wer guckt schon Signaturen an?

Weil ich das so wollte . Außerdem habe ich festgestellt, dass die C-Syntax in meinen Augen an einigen Stellen leichter zu parsen ist - wobei es auch an einigen Stellen (z.B. Switch-Anweisung) viel härter ist.

Naja, letzendlich habe ich erst einen Ansatz für etwas Pascal-Ähnliches gemacht. Dann aber überlegt und mich umentschieden zu C. Frag mich nicht warum. Warum sehen Bananen anders aus als die Staude dazu

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Deine Downloadlinks funktionieren irgendwie nicht (404).

_________________
http://audorra.sourceforge.net//http://andorra.sourceforge.net

Ups, die im headpost funktionieren, bei den unteren hab ich mich vertippt. Korrigiert.

greetings

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Kannnst du mal die Diagramme Zeigen wegen den Abhängigkeiten? Eventuell sehen die anderen Nutzer ja noch Möglichkeiten.

Ein Feature aus Java vermisse ich in Delphi, und dass sind Packete. Ich denke so könntest du deinen Code besser strukturieren....

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Unit Größe: Es kommt nicht auf die Größe an. Ne mal Spaß bei Seite. Wenn es sich nicht vernünftig in Units aufteilen lässt, dann sollte man es nicht erzwingen wollen. Und so etwas wie Codeauslagerung mit Includes ist meiner Meinung nach eine ganz üble Sache. Zu mal der Compiler daraus eh wieder eine Unit macht.

TThoriumInstruction: Ich hätte da nen Vorschlag wie du diese Strukturen etwas auflockern könntest. Denn ich hatte gesehen, dass du bei jedem Record ausgerechnet hast wie viel Platz dort noch existiert um dann ein "array [0..?] of word" dort einzusetzen. Das geht auch einfacher. Bzw du könntest das auch dem Compiler überlassen.

Mein Vorschlag sähe in etwa so aus.

Deine Struktur wäre dann immer so groß wie das kleinste Case. Dieses Konstrukt bewirkt das Gleiche wie Union unter C. Die beiden Speicherbereiche der Cases würden überlagert werden. Bevor du dich fragst warum CodeLine am Anfang steht. Das liegt daran, dass solch ein Case das letzte in einem Record sein muss. Member nach dem Case sind nicht erlaubt. Ist syntaktisch etwas verschroben. Aber na ja. Alternativ könntest du das wohl auch hinter Reserved machen. Wenn du die Konstante noch innerhalb deiner TThoriumInstruction in Bezug nimmst, dann brauchtest du nur den Wert der Konstante ändern und wirklich alle Records wäre größer. Falls deine Inhalte mal größer als der Speicher werden sollte, dann führt ein Cast der Records zu einem Fehler (zu mindest unter Delphi).

CodeLine/Debug Infos: Falls es später mal mehr werden könnten, dann würde sich da ein extra Record anbieten. Also ein TThoriumInstructionDebugInfo oder so. Du würdest in den Records dann nur noch ein DebugInfo: TThoriumInstructionDebugInfo einbinden. Falls die Debuginfos doch nach den Daten stehen müssen könntest du es auch so machen, dass du nur die eigentlichen veränderbaren Daten in seperate Records gelagert würden.

Ich kenne zumindest einen Fall, wo Includes sehr nützich sind: Ich habe eine Unit mit EINEM Interface-Teil (meine Operating-System-Unit), aber diesem Interface-Teil müssen ZWEI verschiedene Implementierungen zugeordnet werden (eine für Windows, eine für Linux). Da kann man im Implementationsteil einen Compilerswitch setzten und automatisch auf das richtige Include umschalten. Der Code bleibt dadurch schön sauber und übersichtlich und wird nicht von "Ifdefs" kontaminiert. Im Klartext heißt das: Die Variante MIT Includes ist einfacher zu lesen als die Variante ohne Includes und dem Compiler ist es egal.

Include-Files sind nicht an sich "böse". Das hemmungslose Verschachteln von Include-Files ist gräßlich, weil man den Überblick verliert. Ein maßvoller Umgang mit Include-Files kann durchaus einen guten Effekt haben. Man kann zu Beginn des Include-Files einen Hinweis darauf anbringen, von welcher Unit es in Betrieb genommen wird.

Mit Casts ist es das Gleiche: Cast oder Variant-Records sind nicht von vornherein abzulehnen. Wenn mir ein Variant Record die Möglichkeit eröffnet, meinen Code einzukürzen, aber dabei die Lesbarkeit verringert, kommt es jetzt eben darauf an,
a) Wie groß ist die Einsparung?
b) Kann ich das schlecht lesbare Zeug vielleicht unschädlich machen indem ich es in eine kleinere Methode sperre?
(Mehr fällt mir im Augenblick dazu nicht ein).


Leider verstehe ich nicht, was Du unter "notwendige Rückbezüge" meinst. Kannst Du das mal näher erläutern?
Ich HABE einen Blick in Deinen Code geworfen, aber das hat offenbar nicht genügt, das Problem zu erkennen. Da müsstest Du mir schon mehr auf die Sprünge helfen.

Viele Grüße,
Traude

Ich habe was solche Dinge angeht eine sehr strenge Ansicht zu meinem Code. Deinen Fall würde ich wohl anders lösen. Und zwar würde ich persönlich da eher eine abstrakte Klasse erstellen und je nachdem auf welcher Platform man sich befindet, dann eine Implementation für Windows oder eine für Linux benutzen. Per Ifdef könnte man dann die 2 Platform units einbinden und die Erstellung der Instanzen steuern. Wäre sehr übersichtlich und man würde die Pfade der Units nicht verletzen.

Denn warum ich persönlich solche Sachen so strickt ablehne liegt in der IDE begründet. Ich habe mich sehr an die Codevervollständigung etc gewöhnt. Und in solchen Includes funktioniert die nicht vernüftig. geht ja auch nicht. Die IDE weiß ja nicht wo das Include überall benutzt wird und welche Objekte dort bekannt sind etc. Und ich meine Früher gabs da auch beim Debuggen Probleme. Wobei das schon eine Weile her ist, weil ich die nicht benutze. Für mich persönlich sind includes nur für Optionen gedacht. Umständliche Verschachtelungen von ifdefs etc. Compilerversion oder generelle Optionen für eine Bibliothek. Aber ich sehe so etwas auch sehr streng. Der Komfor des Entwicklers (also meiner) ist mir da sehr sehr wichtig.

Aber okay. Ich habe gelogen. In der TextSuite habe ich eine Stelle an der ich das so mache. Und zwar definiere ich Konstanten in einem Include. Das sind Versionskonstanten die durch ein Skript erstellt werden mit welchem ich meine Packete erstellen. Dazu habe ich ein Template mit Ersetzercodes. Das könnte ich zwar auch mit der ganzen Unit machen. Aber dann müsste ich die eigentliche Unit als Template entwickeln und bevor ich da was kompilieren kann dann die Version erstellen lassen. Ist aber doch etwas kompliziert und ich mag mir ungern irgendwelche Änderungen zerschießen. Wobei, wenn ich so drüber nachdenke. Auch das Version.inc könnte ich als pas machen. Dann müssten die Konstanten im Interface und schon wäre das Include auch gar nicht mehr nötig.

Zuerst mal danke für die Anregungen und dafür, dass sich mindestens zwei leute das ganze angetan haben.


Angehangen. Als zip aus einem .dia und einem .svg. Ich empfehle die .dia version, die .svg-Version wurde von Dia etwas entstellt.


Ja, das hatten wir in Dänemark ja schonmal angerissen. Object Pascal kennt leider keine Pakete, die Pakete, die die IDEs bieten sind etwas anderes. Wobei FreePascal da jetzt auch was im Ofen hat, bin gespannt, was bei rauskommt.


Vollkommen richtig. Ich benutze in Thorium ja Variant Records. Ich verstehe nicht, warum ich bei den Instruktionen nicht darauf gekommen bin.


Ich bezweifle, dass da noch was dazu kommt *hust*, aber dann ist das ein guter Plan.


So wenig böse wie goto und derivaten. Man muss sie halt ein wenig in Kontrolle halten. Aber ich vermeide sie trotzdem eher. Ich finde auch nicht, dass die das ganze unbedingt übersichtlicher machen. In den FP-Units finde ich immer wieder Code, der aus irgendwelchen Gründen sehr interessant in Includes aufgeteilt ist und ohne "Find declaration" würde ich da garnicht mehr durchsteigen.


Es ist halt so, dass TThoriumType Informationen über Thorium-Interne Typen enthält. Das wird zum Beispiel intern vom Compiler verwandt, aber auch von den TThoriumLibrary-Klassen, um Typen für Konstanten und Eigenschaften anzugeben. Wenn es sich aber um einen Typ aus der Hostumgebung handelt, muss ein Pointer auf die entsprechende Klasse im TThoriumType liegen. Und da beißt sich der Hund dann in den Schwanz. Man *könnte* natürlich da wirklich einen einfachen Pointer reinlegen oder ein TObject, welches man dann an den entsprechenden Stellen castet, aber das finde ich ziehmlich unschön und auch unleserlich. Ganz ähnlich verhält es sich mit TThoriumValue.
Diese Casts der Lesbarkeit wegen in Methoden oder Funktionen auslagern, will ich vermeiden. Erstens produziert es mehr Code. Zweitens ist es langsamer. Man kann natürlich inline verwenden, aber ob das immer zu 100% optimal läuft, ist auch nicht sicher. Zumal ein Cast sich ja nicht mal auf Instruktionsebene, sondern allein auf der Compilerebene abspielt. Einsparung gäbe es dabei garnicht. Nur die Möglichkeit, auszulagern.

greetings
@Lossy: Funktionieren die Coderegions unter Delphi eigentlich? Also ein-/ausklappbar?

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb