Schau mal unter linux/ctype.h
Funktion konvertiert c in ascii:
unsigned char toascii(unsigned char c)
Funktionen prüfen den variablen Inhalt:
unsigned char isalnum(unsigned char c)
unsigned char isalpha(unsigned char c)
unsigned char isascii(unsigned char c)
Hi, ich habe ein Problem mit dem LCGI. Der Code aus dem Buch geht, aber er kann die Bilder nicht laden, wo könnte der Fehler sein?
#include <stdlib.h>
#include <time.h>
#include <graphics.h>
#define EINH 5
int main( int argc, char *argv[] )
{
int i;
void *karte;
char name[30];
srand(time(NULL)); /* Zufallsgenerator initialisieren */
initgraph( 360, 360 );
setcolor(getmaxcolor());
/* Textstil festlegen */
settextstyle( "Times", 48 );
while (1) {
cleardevice( rand()%getmaxcolor() );
for ( i=0; i<7; i++ ) {
sprintf( name, "%d.bmp", rand()%52+1 ); /* aus 52 Karten eine
zufaellig auswaehlen */
loadimage( name, &karte );
putimage( 20+i*40, 20+i*40, karte, COPY_PUT );
freeimage( &karte );
}
if ( getch() == Key_Escape ) /* Abbruch mit Escape */
break;
}
getch();
closegraph();
return(0);
}
Das sagt der GCC zu dem Programm:
In file included from karten.c:3:
/usr/include/lcgi/graphics.h:8:1: Warnung: "__USE_XOPEN_EXTENDED" redefined
In file included from /usr/include/stdlib.h:25, from karten.c:1:
/usr/include/features.h:198:1: Warnung: this is the location of the previous definition
Grundsätzlich ist das (unter POSIX) kein Problem, wenn Parent und Child den gleichen File-Descriptor verwenden - im Prinzip ist das das gleiche, als wenn der Child-Prozess die gleich Datei neu öffnet.
Pipes sind natürlich keine "normalen" Dateien, aber selbst das sollte gehen. Nach meiner Erfahrung gehen beim gleichzeitigen Lesen aus der Pipe die Daten abwechselnd an beide Prozesse, sodass jeder Prozess nur die Hälfte der Zeichen erhält.
Ich wollte das Ganze aber anwenden auf ein Device (/dev/dsp), und hier scheint der Device-Treiber der Sound-Karte etwas anders zu ticken: gleichzeitiges Lesen und Schreiben über EINEN File-Descriptor (O_RDWR) mag der Treiber nicht.
Ich konnte das aber lösen, indem ich das Device ZWEIMAL im Parent-Prozess geöffnet habe, einmal O_RDONLY und einmal O_WRONLY. Dann geht's ohne Probleme, und auch hier nutze ich einen der beiden File-Descriptoren sowohl im Child als auch im Parent-Prozess.
Martin
Suchfunktion hilft...
Problem ist, die Memberfunktionen der Klasse müssen mit einem Objekt aufgerufen werden. Das lässt sich dann nicht in eine normal freistehende Funktion konvertieren.
So erstmal big thx an alle, die mir bis hier hin geholfen haben:
Es tut halbwegs booten tun.
Zumindest solange ich den IDE-Controller draussen lasse...
Sobald ich den wieder einsetze heisst es
Linux schrieb:
VFS: Cannot open root device "1643" or 16:43
Please append a correct "root=" boot option
Kernel panic: VFS: Unable to mount root fs on 16:43
Und schon wieder geht es net mehr weiter.
Ich raff es einfach nicht, warum hat dieses daemliche Teil solche ueblen Probleme mit meinem harmlosen kleinen zusaetzlichen IDE-Controller.
[edit]Scheint als waere die Platte jetzt wieder hdh.
Der Treiber fuer den zusaetzlichen IDE-Controller wird anscheinend zuerst geladen und bekommt deshalb hda-hdd zugewiesen...
Nun werde ich erstmal versuchen, die Boot-parameter entsprechend zu aendern.[/edit]
[edit2]
Jetzt bootet es - zumindest was die Laufwerke angeht - fehlerfrei.
Das war ja wirklich eine schwere Geburt.
[/edit2]
Hallo,
kann es sein, dass dort ein schwerer Bug drin ist? Ich hab herausgefunden, dass in der orbitcpp-1.3.7 etwas nicht stimmt. Ich habe jetzt ein die Source von 1.3.8 heruntergeladen und kompiliert. Immerhin kommen jetzt andere Meldungen, laufen tuts aber immer noch nicht.
Naja, irgendwie ist dieses ganze gtk und gnome Gedöns so miteinander verstrickt, dass mans besser nicht von Hand kompliliert.
Ah dankeschön für die ganzen Antworten! Wie erstelle ich dann einen vernünftig dimensionierten Buffer der genauso groß ist wie die Datei ist? Mit zwei lesedurchläufen?
bis dann morti
Hallo
Außerdem solltest du klären, ob der Motor RTS/CTS nutzt und, wenn ja, dieses aktivieren.
Nein ist leider nur eine ZweiDraht Leitung und das dumme Teil hat keine Fehlerkorrektur
Gehen die Zeichen wirklich "verloren"? Oder macht der Motor vielleicht nur eine Pause zwischen den Zeichen, sodass die read()-Funktion zunächst "abbricht" und die weiteren Zeichen erst mit einem weiteren read() verfügbar werden.
Inzwischen hab ich rausgefunden das er mir bei Bewegungskommandos richtig antwortet , bei anderen Komandos antwortet er mir mit Datenmuell.
Wobei ich inzwischen den datenmuell immer wieder richtige Daten sehe.
Mir kommt es manchmal so vor das Teile der Nachricht verschluckt werden.
Naja vielleicht liegt das ganze auch am Motor
Gruss Snoopy
Noch eine Lösung, die vielleicht etwas sauberer ist.
Du lockst mit pthread_mutexe_lock einfach den stdout Filedeskiptor im Thread, welcher gerade Ausgeführt werden soll.
Da ich keine Antwort erhalten habe, gehe ich mal davon aus, das es sowas nicht giebt.
Ursprünglich wollte ich an einer sinnlosen Portierung einer Windows - Bildverarbeitung basteln um Erfahrungen zu sammeln. Dort sind 'ne Menge Menueinträge zu machen.
Wäre es sinnvoll diese Menu - Geschichte zu automatisieren? IMHO schon -> ist ja mehr oder weniger nur sinnlose Schreibarbeit.
Schreibt einfach mal, ob so ein Tool sinnvoll wäre, oder ob ich mir einfach nur das Leben zu schwer mache.
Was willst du eigentlich machen? Netzwerkkarten werden mit ip-Adressen verbunden.
Diese ip-Adressen sind einem Netz zugeordnet. Willst du einen Rechner aus diesem
Netz ansprechen dann geht der Netzverkehr durch dieses Interface. Ausserdem gibt es noch die Moeglichkeit einen default gateway anzugeben. Zu diesem werden alle
Pakete geschickt, fuer die dein Rechner keinen (expliziten) Weg kennt.
Lies doch auch mal auf www.tldp.org unter howtos die net howto durch.