Posts by Rainer

    hab mal kurz draufgeschaut. Da liegt eine Menge anderer Arbeit an, insbesondere stimmt die Groß/Kleinschreibung der Dateinamen nicht.
    @Nico: Das darf man NICHT mit dem Windows-Explorer ändern, sondern unbedingt mit GIT!

    So wie es ist compiliert Dose unter \installed gar nicht, z.B. weil er dose.gp nicht findet (heißt ja DOSE.GP) und mehr....
    Rufe ich den pmake &Co direkt im Code-Ordner, meckert er mit obigen Fehlermeldungen.
    Seltsam.

    Wie auch immer, das ist kein "mal so in in ner halben Stunde nebenbei" Projekt mehr.

    Rainer

    Nachtrag: Bevor du ein solches Problem per explizitem Typecasting fixt (also: Du doofer compiler, ich weiß genau was ich will, auch wenn du das anders siehst ...) musst du schauen, ob der Code inhaltlich in Ordnung ist. Dann schaust du, welchen Typ der entsprechende Parameter laut Routinendefinition hat - bei den HugeArray Routinen ist es oft 'void **' - und teilst dann dem Compiler mit, dass er den Ausdruck '&irgendwas' als void** zu interpretieren hat: (void**)&irgendwas. Wie gesagt, wenn &irgendwas dann keine Adresse eines Pointers auf eine Struktur ist, mecker der Compiler zwar nicht mehr, aber es geht dann eben schief.

    Dose does not compile with the new SDK because of pointer type mismatch errors. Perhaps this can be fixed by a simple typecasting, but I'm nor sure.

    Auf Deutsch: Es gib ein Pointer-type Fehlermeldungen, die sich wahrscheinlich per simples typecasting fixen lassen - aber dazu muss man schauen, was der Code macht.

    @bretttiktin (sorry for this question) do you know how to compile a program? Then you may create the geo file yourself.

    Rainer

    Hallo,

    hier mal wieder einer aus der Rubrik "Das kann doch nicht wahr sein".
    Ich wollte eine dword variable mit 10 multiplizieren (erg2 = 10*erg2). Dabei wird aber die ansic-Library mit dem protocol 1.008 eingebunden, so dass das Programm nicht mehr unter BBX 4.13 läuft. Das kann man zwar mit einem platform statement (platform geos21) in der GP fixen, aber das wollte ich nicht.

    Also habe ich gedacht: 10 = 8 + 2 und Multiplikation mit Acht oder Zwei lässt sich mit Shift-Operationen auch (und ggf sogar schneller) erledigen.

    Code
    erg2 = erg2<<3 + ergs<<1;	// erg2*8 + erg2*2 = erg2 * 10

    Pustekuchen, es kam totaler Müll heraus.

    ... eine halbe Stunde später mit swat und etwas Test-Code ...

    x, y und erg2 werden richtig berechnet, z aber nicht.

    ... noch ne halbe Stunde später ... die Erleuchtung. Der Plus-Operator ist in C höher priorisiert als '<<'. Der Compiler wertet den Ausdruck also so aus:

    Code
    z = (erg2<<(3 + erg2))<<1;

    Uns so gehts dann wie gewünscht:

    Code
    z = (erg2<<3) + (erg2<<1);

    Wer kommt denn von selbst auf sowas?

    Rainer

    – Die Optionen "aufsteigend" und "absteigend" könnten groß geschrieben werden. Sieht a) besser aus und b) war nicht mal eine Umfrage, wo wir uns auch darauf geeinigt hatten?

    Genau. nicht können, sondern sollen. Auch da gibt es bestimmt noch diverse andere Stellen in der Library - viel Arbeit 8)

    Rainer

    Wie dem auch sei, ich werde nach Abschluß der Arbeiten die GeoCalc-Hilfedateien nochmal nach Reihen durchsuchen und durch Zeilen ersetzen.

    :love:

    Ich glaubte, die Übersetzungsdatei schon bezüglich Reihe/Zeile durchgesehen zu haben. Aber vielleicht habe ich etwas übersehen oder bin irgendwie von abgekommen. Die grundlegenden Sachen habe ich jedenfalls gemacht. Row darf man hier nicht mit Reihe (alle Leute stehen in einer Reihe) , sondern mit Zeile (Zeilen gehen von links nach rechts) übersetzen.

    Rainer

    Nachtrag: die Suchfunktion in der Übersetzungsdatei liefert für Reihe nur das Wort 'Zahlenreihe', was im Kontext OK ist.

    nach dem NOT_USABLE setzen kriege ich das GenContent mit SET_USABLE nicht wieder sichtbar

    Ist ja komisch. Ruf mal versuchsweise für das View die Readraw_content Message. Ansonsten klappere ich in solchen Fällen die Liste Messages der betroffenen Objkete (in dem Fall der View und Content ) ab und probiere aus, was mir nur irgendwie sinnvoll erscheint. Try and (viel) error.

    Ansonsten: inwiefern würde mir pobj helfen? Und wie setze ich das "Unlock-move" flag? Und wann rufe ich "ec all" auf - wenn ich das nach Beendigung des Tools tue, macht er einfach gar nix....?

    Du musst einen Breakpoint so setzen, dass dein Tool gerade aktiv ist. Z.B. "stop in VonMeinemToolgerufeneRoutine". ** Dann brauchts du den optr des interessanten Triggers, der ggf den falschen HINT enthält und rufst am prompt "pobj OptrDesTriggers". Das listet die Instancevariablen inklusive der gesetzten Hints auf und auch alles was ggf. dort an Müll steht. Wenn du das noch nie gemacht hast, ist es interessant, das mal auf andere Objekte anzuwenden.

    Für die EC-Flags muss die EC-Version laufen. Im Breakpoint-Prompt einfach "ec all" ("ec" listet alle gesetzten Flags) und später "ec none", wenn sie wieder weg sollen. "ec unlock-move" setzt nur genau dieses eine Flag. "help ec" oder "help pobj" am Prompt kann auch helfen

    Falls du es noch nicht durch hast, empfehle ich das Tutorial aus dem SDK. Da sind eine ganze Menge nützliche swat-Befehle eingestreut und erklärt was sie tun. Ich fand das sehr hilfreich.

    So, ich hoffe ich habe jetzt nicht zu viele Eulen nach Athen getragen.

    Viel Spaß
    Rainer

    ** Am Prompt nach "Ctrl-C" einfach den Namen des Threads eingeben, den du debuggen willst, geht auch. Welcher das beim FM-Tool ist, weiß ich aber nicht aus dem Kopf.

    Hallo Konstantin,

    ich frage mich, welche Änderungen du vornimmst, dass es nötig ist alle Button zu destroyen (machst du doch, oder) und dann wieder neu anzulegen. Bei mir hat es immer gereicht, den zu ändernden Button NOT_USABLE zu setzen, die Änderungen vorzunehmen und ihn dann wieder auf _USABLE setzen. Ggf setzt du temporäre das ganze GenContent auf NOT_USABLE.

    Ansonsten: Was sagt pobj unter swat? Ein guter Test für Speicher-Lecks ist auch das EC-Flag unlock-move. Ich benutze als finalen Test oft "ec all".

    Soweit erst mal
    Rainer

    Die letzte Zahl in der "Release" (6.0 0-580) gibt die 'Buildnummer' an. Sie ist für alle Geoden in einer Ensemble-Version gleich. Je größer desto neuer. Die 6 deute auf eine FreeGeos Version hin. 4.1 ist eine alte Breadbox-Version.
    Rainer

    Dann sollte man das Programm doch standardmäßig in FreeGeos aufnehmen und den Icon-Editor versenken.

    Vom Prinzip her schon, aber das geht bei R-BASIC Programmen nicht so einfach, weil die zugehörigen Libraries nicht im Repo sind. Und es in absehbarer Zeit auch nicht sein werden.

    Rainer

    Der Pfeil ist bestimmt ein eigenes grafisches Objekt; ob man das miteinander verknüpfen kann... Keine Ahnung.

    Ich fürchte, es ist insgesamt eine einzige Grafik ** - wer einen Pfeil + Karteikarte will, muss ein neues Bild malen. Sinnvoll wäre vielleicht, das Bild gleich Im Code zu ersetzen - warum sollte die englische Version nicht vom neuen Bild profitieren?

    Rainer

    ** @Nico: wahrscheinlich ist es ein visMoniker.

    Hallo,

    hat eigentlich außer mir jemand das SDK + git unter Windows laufen? Ständig oder überhaupt benutzt ist nicht die Frage. Einfach nur installiert und geht.

    Rainer

    P.S. oder nur Git, zum Hochladen?

    Wenn ich das richtig zwischen den Zeilen gelesen habe ist Falk durchaus Fan davon, das aktuelle GEOS auf nativer Hardware laufen zu sehen. Ich würde es auch cool finden, auch wenn ich die Hardware nicht habe.

    Btw Hat schon mal jemand versucht Dos 6.x in einer VirtualBox (Oracle oder so) zu installieren und darunter GEOS laufen zu lassen? Das könnte durchaus Performace-Vorteile gegenüber der DosBox haben....

    Rainer