amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Programmierung > Execute und input/output [ - Suche - Neue Beiträge - Registrieren - Login - ]

-1- [ - Beitrag schreiben - ]

10.06.2007, 19:55 Uhr

Kaesebroetchen
Posts: 643
Nutzer
Hallo,

ich starte aus meinem Programm heraus den gcc mit Execute()
das klappt auch soweit. Ich möchte jedoch irgendwie die Ausgaben des gcc (Fehlermeldungen in meinem Programm auswerten. Das kriege ich aber irgendwie nicht hin:
C++ code:
std::string CompilerAccess::CompileFile(std::string File, std::string Options)
{
	/* TODO (#1#): Implement CompilerAccess::CompileFile() */
	sExecute = "Development:bin/gcc ";
    sExecute = sExecute + "-c ";
    sExecute = sExecute + File;
    sExecute = sExecute + " ";
    sExecute = sExecute + Options;
    Execute( (char*)sExecute.c_str(), BPTRinputstream, BPTRoutputstream );

    while(FGets(BPTRinputstream,cCompilerOutput,1000))
    {
        CGUI->setTextEditorContent(cCompilerOutput);
    }

	return "";
}


Kann mir vielleicht Jemand einen Tip bzw ein Codebeispiel geben ?






































--
http://amidevcpp.amiga-world.de/

[ - Antworten - Zitieren - Direktlink - ]

10.06.2007, 20:36 Uhr

thomas
Posts: 7676
Nutzer

Lesen vom Inputstream ? Was soll das bringen ? GCC schreibt in den Outputstream, also mußt du den Outpurstream einlesen.

Etwa so:

code:
input = Open("NIL:",MODE_OLDFILE);
output = Open("dateiname",MODE_NEWFILE);
Execute (commmand,input,output);
Close (input);
Close (output);
report = Open("dateiname",MODE_OLDFILE);
while (FGets (report,line,linelength))
{
...
}
Close (report);


Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]

10.06.2007, 20:38 Uhr

thomas
Posts: 7676
Nutzer

Apropos GCC. GCC schreibt Fehlermeldung nicht nach stdout, sondern nach stderr. Das kannst du mit Execute() nicht abfangen. Schau dir lieber mal SystemTagList() an.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]

11.06.2007, 11:51 Uhr

Kaesebroetchen
Posts: 643
Nutzer
@thomas:
Danke!

Mit SystemTags habe ich es schließlich hinbekommen.

Hier mal der Code:
C++ code:
BPTRoutputstream = Open("RAM:temp.txt",MODE_NEWFILE);
    SystemTags((char*)sExecute.c_str(), SYS_Error, BPTRoutputstream, TAG_DONE);
    Close(BPTRoutputstream);

--
http://amidevcpp.amiga-world.de/

[ - Antworten - Zitieren - Direktlink - ]

12.06.2007, 17:43 Uhr

Kaesebroetchen
Posts: 643
Nutzer
Ich habe da immer noch ein kleines Problem.

Wenn beim Compileraufruf z.B. eine Datei nicht gefunden werden kann, klappt alles mit obigem code.
Ich kann dann z.B. in der Ram Disk auch temp.txt öffnen und die Datei enthält auch die entsprechenden Fehlermeldungen.

Wenn ich aber jetzt einen Fehler in code einbaue, klappt es nicht.
Wenn ich dann versuche temp.txt zu öffnen, heisst es nur "bad loadfile hunk"

Ich kann mir da keinen reim drauf machen.

--
http://amidevcpp.amiga-world.de/

[ - Antworten - Zitieren - Direktlink - ]

12.06.2007, 20:14 Uhr

DrNOP
Posts: 4118
Nutzer
- Kommt diese Meldung auch, wenn du versuchst eine nicht existente/leere Datei zu öffnen?

- Kannst du - nur zum Debuggen - die Meldungen, die du in temp.txt schreibst, parallel dazu auch auf den Bildschirm drucken?

- Hat du temp.txt schon mal mit einem anderen Editor geöffnet? Enthält sie was sinnvolles?

Ich weiß jetzt nicht wie es bei deinem Compiler ist, aber meiner schreibt nicht grundsätzlich alles nach stderr. Manches schreibt er praktischerweise nach stdout... :angry:
--
Signaturen mit mehr als zwei Zeilen gehen mir auf den Wecker


[ Dieser Beitrag wurde von DrNOP am 12.06.2007 um 20:17 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

12.06.2007, 20:23 Uhr

Kaesebroetchen
Posts: 643
Nutzer
@DrNOP:
Im Outputstream (SYS_Output) bekomme ich auch nichts rein..
--
http://amidevcpp.amiga-world.de/

[ - Antworten - Zitieren - Direktlink - ]

12.06.2007, 23:49 Uhr

Mazze
Posts: 263
Nutzer
@Kaesebroetchen:

vielleicht hilft folgendes:
SYS_Asynch, FALSE

Ich weiß jetzt nicht, ob TRUE oder FALSE Standard ist. Bei TRUE läuft das gestartete Programm im Hintergrund und die Kanäle werden automatisch geschlossen.
--
AROS - Because every rose has its dorns.
Meine Homepage

[ - Antworten - Zitieren - Direktlink - ]

13.06.2007, 08:39 Uhr

Kaesebroetchen
Posts: 643
Nutzer
@Mazze:

Scheint leider nicht zu helfen.

Habe es so eingebaut:
C++ code:
BPTRoutputstream = Open("RAM:temp.txt",MODE_NEWFILE);
    SystemTags((char*)sExecute.c_str(), SYS_Error, BPTRoutputstream, SYS_Asynch, FALSE, TAG_DONE);
    Close(BPTRoutputstream);

--
http://amidevcpp.amiga-world.de/

[ - Antworten - Zitieren - Direktlink - ]

14.06.2007, 12:32 Uhr

Holger
Posts: 8090
Nutzer
Zitat:
Original von Kaesebroetchen:
@Mazze:

Scheint leider nicht zu helfen.

Habe es so eingebaut:
C++ code:
BPTRoutputstream = Open("RAM:temp.txt",MODE_NEWFILE);
    SystemTags((char*)sExecute.c_str(), SYS_Error, BPTRoutputstream, SYS_Asynch, FALSE, TAG_DONE);
    Close(BPTRoutputstream);



Ich seh da nix vom stdout. Bist Du Dir sicher, dass Du diese Möglichkeit auch wirklich überprüft hast?

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

14.06.2007, 13:32 Uhr

Kaesebroetchen
Posts: 643
Nutzer
Zitat:
Original von Holger:


Ich seh da nix vom stdout. Bist Du Dir sicher, dass Du diese Möglichkeit auch wirklich überprüft hast?

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.


Eigentlich schon.
Siehe hier der aktuelle code:
C++ code:
BPTRERR = Open("RAM:MURKSERR.txt",MODE_NEWFILE);

    BPTROUT = Open("RAM:MURKSOUT.txt",MODE_NEWFILE);


    BPTRIN = Open("RAM:MURKSIN.txt",MODE_NEWFILE);


    SystemTags((char*)sExecute.c_str(),
                SYS_Input, BPTRIN,
                SYS_Output, BPTROUT,
                SYS_Error, BPTRERR,

                TAG_DONE);


    if(BPTRERR)
    {
    Close(BPTRERR);
    }

    if(BPTROUT)
    {
    Close(BPTROUT);
    }

    if(BPTRIN)
    {
    Close(BPTRIN);
    }


Ich habe die Thematik auch schon bis zum Erbrechen auf #aros diskutiert aber bisher nichts erhellendes gefunden.

Das misteriöse ist ja, das Fehler wie "Datei nicht gefunden" oder "zuwenig speicher" vom gcc korrekt zurückkommen. Nur die interessanten Fehler, wie syntax error in line xyz, die kommen nicht.

Ich habe auch versucht mit gcc dateien optionen >ausgabe.txt

versucht die Ausgabe in eine Datei umzulenken. Das Resultat ist das selbe, nichts.

Allmählich glaube ich das es vielleicht am gcc selber liegt.

Siehe auch hier:




Mehr Details auf Aros-Exec
--
http://amidevcpp.amiga-world.de/

[ - Antworten - Zitieren - Direktlink - ]

14.06.2007, 14:21 Uhr

Holger
Posts: 8090
Nutzer
Zitat:
Original von Kaesebroetchen:
C++ code:
BPTRIN = Open("RAM:MURKSIN.txt",MODE_NEWFILE);
...
SYS_Input, BPTRIN,



Das wird zwar für Dein jetziges Problem nicht helfen, aber Du solltest mal ganz in Ruhe darüber nachdenken...

Ansonsten, wenn ein Programm explizit die Console anspricht, z.B. Open("*"), wird es deutlich komplizierter, den Output umzuleiten. Aber nicht gänzlich unmöglich. Vielleicht finde ich die Zeit, dazu etwas herauszukramen...
Aber eigentlich hätte ich gerade bei gcc so etwas nicht erwartet...

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

14.06.2007, 17:02 Uhr

ZeroG
Posts: 1486
Nutzer
Zitat:
Original von Kaesebroetchen:
Ich habe auch versucht mit gcc dateien optionen >ausgabe.txt

versucht die Ausgabe in eine Datei umzulenken. Das Resultat ist das selbe, nichts.


Weiß zwar nicht wie das unter Aros ist aber unter OS4 leitet man die Ausgaben von GCC so um:

gcc -o test test.c *>< >compile.log

[ - Antworten - Zitieren - Direktlink - ]

18.06.2007, 09:39 Uhr

gni
Posts: 1106
Nutzer
Zitat:
ZeroG:
Weiß zwar nicht wie das unter Aros ist aber unter OS4 leitet man die Ausgaben von GCC so um:
gcc -o test test.c *>< >compile.log

"*>" ist eine mit der Shell V45 eingeführte Neuerung: damit kann stderr umgeleitet werden.

[ - Antworten - Zitieren - Direktlink - ]

18.06.2007, 13:03 Uhr

whose
Posts: 2156
Nutzer
@Kaesebroetchen:

Hm, ist schon eine ganze Weile her, daß ich da reinschauen konnte, aber z.B. für StormC wurde ein eigener Console-Handler für diese Aufgabe verwendet (u.A. weil beim con-handler <=V44 eine Umleitung von stderr halt nicht möglich war). Cubic wird das vermutlich ähnlich lösen, evtl. hilft Dir Dietmar da weiter, wenn Du ihn fragst.

Da funktioniert es ja mit allen Ausgaben des gcc.

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

18.06.2007, 14:13 Uhr

Holger
Posts: 8090
Nutzer
Zitat:
Original von whose:
u.A. weil beim con-handler <=V44 eine Umleitung von stderr halt nicht möglich war


Das ist eine missverständliche Formulierung. Der con-handler hat keinerlei Einfluss auf die Frage, ob man stderr umleiten kann. Das ist ausschließlich Sache der shell und der Anwendung. Wenn diese beiden in Sachen stderr-Umleitung ordentlich zusammenarbeiten, funktioniert das selbstverständlich auch in Verbindung mit dem originalen con-handler.

Der Grund, diesen nicht einzusetzen, liegt in der Tatsache, dass man ja die Ausgabe auf der Standard-Konsole CON: gar nicht will.

Und einen eigenen Handler statt einer Datei oder Pipe zu verwenden, hat den Vorteil, dass man wesentlich bessere Kontrolle hat, wie sofortige Rückmeldung während des laufenden Vorgangs oder Interaktivität. Bzw. manche Programme arbeiten vielleicht auch gar nicht korrekt mit einem nicht-interaktiven FileHandle zusammen.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

18.06.2007, 19:55 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von Holger:
Zitat:
Original von whose:
u.A. weil beim con-handler <=V44 eine Umleitung von stderr halt nicht möglich war


Das ist eine missverständliche Formulierung. Der con-handler hat keinerlei Einfluss auf die Frage, ob man stderr umleiten kann. Das ist ausschließlich Sache der shell und der Anwendung. Wenn diese beiden in Sachen stderr-Umleitung ordentlich zusammenarbeiten, funktioniert das selbstverständlich auch in Verbindung mit dem originalen con-handler.


Oh, da hast Du allerdings Recht... ich hab da etwas zu kurz gedacht, sry. Mir fiel dabei halt "auf die Schnelle" der StormC ein, auf dessen Interna ich mal einen Blick werfen konnte, allerdings nicht tief genug, ums bis ins Detail hinein zu verstehen und ich hatte eine Aussage im Kopf, daß es da Probleme mit dem normalen con-handler gäbe, weshalb man einen eigenen implementiert hätte, um diese Probleme zu umgehen. Damit war sicherlich u.A. die direkte Reaktion auf Ausgaben auf stderr etc. gemeint.

Hoffen wir, daß sich jemand findet, der ihm da weiterhelfen kann (wie gesagt, Dietmar Eilert könnte da evtl. was zu sagen, GoldEd hat so eine Mimik ja eingebaut), ich kanns leider nicht direkt :(

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

19.06.2007, 11:45 Uhr

Holger
Posts: 8090
Nutzer
Zitat:
Original von whose:
... und ich hatte eine Aussage im Kopf, daß es da Probleme mit dem normalen con-handler gäbe, weshalb man einen eigenen implementiert hätte, um diese Probleme zu umgehen. Damit war sicherlich u.A. die direkte Reaktion auf Ausgaben auf stderr etc. gemeint.


Kann auch ein anderes Problem gemeint sein. Eine naheliegende Zielstellung bei der Entwicklung einer IDE ist es, eine möglichst universelle Möglichkeit zum Starten externer Build-Tools zu schaffen, bei der die Konsole auf ein eingebettetes Element der IDE-GUI umgeleitet wird (evtl. nicht nur Ausgabe, sondern auch Eingabe).

Das in AOS2.0 eingeführte Feature, eine CON: oder RAW: Konsole in einem eigenem Fenster eingebettet zu öffnen, erzeugt tatsächlich eine Reihe von Problemen mit der Event-Verarbeitung, wenn man andere Kontrollelement des eigenen GUIs in einem solchen Fenster abfragen will. Da kann man durchaus auf die Idee kommen, statt dessen lieber einen eigenen Konsole-Handler zu schreiben, der dann z.B. nicht im input.device rumpfuscht, sondern die Events von der IDE übergeben bekommt.

Insofern ergibt das schon alles einen Sinn.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]


-1- [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > Execute und input/output [ - Suche - Neue Beiträge - Registrieren - Login - ]


.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1998-2022 by amiga-news.de - alle Rechte vorbehalten.
.