Seiten: [1] 2 
|
 |
|
Autor
|
Thema: Funktionen in STLCD (Gelesen 9891 mal)
|
Jobe
Gast
|
Hi,
so, da es nun endlich funktioniert, mache ich mich natürlich gleich ans konfigurieren, und muss feststellen das man ja nicht wirklich viel anzeigen lassen kann... oder hab ich was übersehen?
ich hatte damals jalcd und dort gabs ne menge plug-ins und auch von hause aus schon viel einzurichten... was mir spontan fehlt sind emailabfragen... oder einfach nur graphischer schnick-schnack .. ne große UHR .. , ip/comp.name/ winamp visiolisation... etc...
kommt das noch? Ist das plug-in technisch was in planung?
Danke
Jan
|
|
|
|
|
Gespeichert
|
|
|
|
xonom
Gast
|
stlcd ist ansich ja nicht grafisch!! so sachen wie schnick schnack wird es denke ich nicht geben!! du kannst ja noch screens einfügen und da deinen eigene kram reinschreiben!! oder wie meinste das?
|
|
|
|
|
Gespeichert
|
|
|
|
Jobe
Gast
|
naja, ich kann zwar eigene Screens machen, aber die Variablen sind ja begrenzt.. und wie ich finde ziemlich wenige ... oder hab ich die variable übersehen ,die mir meine email postfächer abfragt und anzeigt? es ist zwar ein character display, dennoch lassen sich damit graphiken zaubern.. (siehe jalcd) .. das fehlt mir n bissel.. plug-ins eben!
|
|
|
|
|
Gespeichert
|
|
|
|
Klinkerstein
Gast
|
hm das mit dem mail gesülze sollte definitv nicht drin vorkommen, ebnso so kleine "ping" scripte. das führt einfach zu zu hohen latenzen in den threads selber, was die cpu last in die höhe schießen lassen würde. und genau dagegen ist stlcd ja programmiert.
|
|
|
|
|
Gespeichert
|
|
|
|
OlafSt
Global Moderator
Karma: +13/-0
 Offline
Geschlecht: 
Beiträge: 2138
Master of STLCD and LISA III
|
Als ich meine LISA-III mit einem LCD ausstattete, mußte ich zum Spielen erstmal mein LCD abschalten, weil mir mal eben 15% CPU-Power fehlten. Das hat mich echt abgenervt. Weiterhin störte mich diese enorm komplizierte Konfig bei allen Featueritis-Programmen. Ich wollte n paar Daten aufm LCD, 99% des ganzen andern Krams habe ich nicht mal angeschaut. Aber es war drin und fraß Rechenzeit.
Dies habe ich abgestellt, als ich STLCD schrieb. Ich finde, meine 3% können sich sehen lassen (0.025% über 24 Stunden gemittelt).
Das ganze hat natürlich seinen Preis, denn alle Zeitaufwändigen Geschichten müssen rausbleiben. Dazu gehört ALLES, was irgendwie mit dem Internet zu tun hat.
Das gilt auch für Plug-Ins, denn die würden genau das verursachen, was ich nicht haben will. Und: an wen wendet man sich, wenn ein Whimpy-VBS-Scripter s*** baut ? Sorry, dafür habe ich keine Zeit...
Ähnliches bei UDF, die dann jedesmal ans LCD gesendet werden müßten... Vom IO-Warrior reden wir da lieber erst gar nicht.
Versteh mich nicht falsch. Natürlich ließe sich ne PI-Schnitte machen und natürlich könnte ich bergeweise Schnickschnak mit einprogrammieren - es mangelt sicher nicht an Fähigkeiten oder Recherche. Aber dann hätten wir wieder "nur" ein weiteres jaLCD, das ebenso kompliziert zu bedienen und ebenso Leistungshungrig ist. Das war nicht das Ziel von STLCD.
Vielleicht mache ich mal ein STLCD "Premium Edition" mit all diesem Kram drinnen, wo ich mich nen Dreck um CPU-Power schere. Wäre sicher interessant zu erfahren, was möglich wäre, wenn... Dann aber kein gejammer, weil die Games rumruckeln und kein Gejammer, das das nix mit IOW wird 
Eine Frage am Rande: Wer wird beim messen von Ping-Zeiten eigentlich angepingt... Stelle ich das selber ein ?
|
|
|
|
|
Gespeichert
|
Erstens: Lies was da steht. Zweitens: Denk drüber nach. Drittens: Dann erst fragen
|
|
|
xonom
Gast
|
da gabs doch mal so nen Befehl für Dos wo man Abf*gen konnte wie hoch der eigene Ping ist!!
ALso ich finde du solltest keine Zeit damit verschwenden so nen Kram einzubauen!! Ich hab lieber nur die wichtigen Daten auf dem Lcd und wer so einen Kram will der kann ja die schon existirenden Programme benutzen!!
|
|
|
|
|
Gespeichert
|
|
|
|
TechnikMaster
Gast
|
da gabs doch mal so nen Befehl für Dos wo man Abf*gen konnte wie hoch der eigene Ping ist!!
Und wer hätte es Gedacht, der Befehl dazu heisst: *Trommelwirbel* PING ;-)
Zusätzlich muss noch die Adresse (bei Funktiontüchtigem DNS) bzw. IP des Anzupingenden Rechners angeben. Kann also von Localhost (*g*) über den Router oder den Provider bis hin zur letzen ICQ-Bekanntschaft alles sein ;-) Der Befehl funktioniert (mit anderen Zusatzparametern) genauso unter Linux (oder zumindest den meisten Linux-Distributionen).
Wen nicht nur der Ping, sondern auch die Route interessiert, sollte sein Glück mal mit dem Befehl TraceRT versuchen ;-)
Ich finde allerdings, das solche spielereien nichts in nem LCD-Programm zu suchen haben, selbst wenn es keine performance kosten würde. Just my 5 cents.
|
|
|
|
« Letzte Änderung: April 7, 2004, 18:55:36 von TechnikMaster »
|
Gespeichert
|
|
|
|
Jobe
Gast
|
Huhu,
ok... ich verstehe was hinter STLCD steckt... mir sind performanceprobleme egal, da das eh mein 2. Rechner ist der so rumsteht .. über ihn würde ich halt gern schnell informationen auf dem display sehen wollen... da interessiert es mich herzlich wenig, wieviel proz. Auslastung ich habe, oder wieviel free mem! ..
daher würd ich es begrüßen, wenn der user die wahl hätte, was er anzeigen will... und das STLCD einzigartig ist, zeigt ja schon die IOW Unterstützung... das teil gibts nun schon ziemlich lange, und nur STLCD kann es!
PS: gibts da wirklich probleme mit dem IOW und performance schluckenden anfragen?
Bye
Jan
|
|
|
|
|
Gespeichert
|
|
|
|
Klinkerstein
Gast
|
Jobe's "PS:" würd mich auch interessieren
Kann man nicht in STLCD quasi sagen, was man abgerufen haben will? oder meinetwegen noch so "performanceschluckende" sachen dazu-aktivieren, wenn man möchte? das wär vielleicht gut. versteh mich nicht falsch, ich will nicht hetzen.
|
|
|
|
|
Gespeichert
|
|
|
|
TechnikMaster
Gast
|
Sobald es auch nur die option gibt, das es Dinge gibt, für die die Antwortzeit unbekannt ist (z.B. PINGs) muss das ganze programm so umgeschrieben werden, das alles mit solch hohen latenzen Funktioniert. Und das kannst du nicht abstellen, wenn du es nicht willst. Also entweder die Funktionen drin und immer langsam oder ohne die Funktionen. An eurer Stelle würde ich Olafs entscheidung akzeptieren und nicht hier rumnerven, bis ihn das so ser nervt das er das ganze Projekt ad Acta legt. Wenn ihr mehr Funktionen haben wollt und euch die performance egal ist nehmt JaLCD und Co (und hängt euer LCD halt wieder an den Parralelport) oder gebt euch mit dem zufrieden, was ihr habt. Olaf macht das ganze schliesslich für seine Bedürfnisse und aus Spass und nicht in eurem Auftrag!
|
|
|
|
|
Gespeichert
|
|
|
|
OlafSt
Global Moderator
Karma: +13/-0
Offline
Geschlecht:
Beiträge: 2138
Master of STLCD and LISA III
|
TM hat das schon sehr gut erklärt: Ich habe einen Thread abgestellt, der alle Daten sammelt, die man so anzeigen lassen kann. Er macht nur das, immer wieder von vorne.
Jetzt machen wir ein PING. Der Thread läuft also durch die Ping-Routine und wartet auf die Antwort - Zu blöd, das das 56K-Modem gerade aufgelegt hat. Also wählt es neu, das übliche Modemgekreische findet statt, Einlog-Prozedur, Ping-Daten rausschicken, Antwort dauert eine Sekunde, fertig.
Dieser ganze Vorgang dauert in der Regel etwa eine Minute. Daraus folgt, EINE VOLLE MINUTE passiert auf dem LCD überhaupt nichts, denn das Aktualisieren hängt von eben diesem, auf das Modem wartenden Thread ab.
Auch wenn jetzt alle aufheulen "Wer hat denn noch n Modem" - mir fallen auf einen Schlag ein dutzend davon ein. Und irgendeiner wird garantiert losjammern "STLCD bleibt stehen - einfach so".
Also: Gibts nicht in STLCD. Wenns nicht gefällt, nimm ne andere Software.
|
|
|
|
|
Gespeichert
|
Erstens: Lies was da steht. Zweitens: Denk drüber nach. Drittens: Dann erst fragen
|
|
|
Jobe
Gast
|
Hey,
ja verstehe... ich will auch nicht hetzen, finde es gut, wenn die man die philosophy so festlegt, muss man mit leben.
Was mir spontan aber noch einfällt  Ich bin was proigramieren angeht nicht wirklich bewandert, aber könnte man das problem mit den latenzzeiten nicht anders regeln... im hintergrund fragt ein thread die ganzen zeitkritischen dinge ab, wenns lange dauert dauert eben lange.. aber das was das LCD tool anzeigt kommt aus einer variable, die eben den aktuellen wert besitzt.. wenn im hintergrund nun noch gewählt wird, sollte das doch den aktualisierungsprozess nicht stören... der soll doch nur anzeigen was eine variable enthällt, und die wird eben erst aktualisiert, wenn die daten verfübar sind.
Was ich mir nun denke ist, das STLCD nicht dafür ausgelegt ist/war und es nachträglich einzubauen zu umständlich ist.
) Also weiter so, finde STLCD super... ich hab ja nur gefragt!
... bye und Frohe Ostern!
|
|
|
|
|
Gespeichert
|
|
|
|
xonom
Gast
|
klar das läuft doch sowieso im hintergrund!! das prob ist doch ein anderes, auch ein programm was im hintergrund läuft verbraucht prozi-power!! das andere ist es mag ja sein dass das lcd seine daten aus einer variablen bekommt aber wenn dass abfragen der daten für einen neuen Wert 2 minuten dauert, schickst du währen dieser Zeit ständig den selben Wert der Variablen zum LCD!! Etwas was sich so langsam verändert macht keinen Sinn!! Auch muss ich sagen STLCD ist gut so wie es ist!! Über das Tray-Icon lässt sich streiten aber ansonsten find ichs top! !!!!!!DER DAUMEN HOCH SMILIE FEHLT!!!
Lass olaf lieber an stglcd basteln!! das ist viel interessanter!
|
|
|
|
|
Gespeichert
|
|
|
|
OlafSt
Global Moderator
Karma: +13/-0
Offline
Geschlecht:
Beiträge: 2138
Master of STLCD and LISA III
|
@Jobe: STLCD besteht bereits aus ungelogen 5 (fünf) nebeneinanderlaufen Programmen, sogenannten Threads. Und natürlich werden alle gesammelten Daten in einem einzigen Block im Speicher abgelegt, also soweit schon richtig.
Das Problem ist nur, das drei von den fünf Threads GLEICHZEITIG (und ich meine das wirklich ernst - kein Pfusch von wegen kooperativ) auf eben diesen Datenblock zugreifen, schreibend wie lesend. Das heißt, man muß die drei miteinander abstimmen - ohne dabei wild Prozessorzeit zu verheizen, den Datenblock zu zerfetzen oder Deadlocks zu produzieren.
Einer der drei liefert dabei die endgültigen Daten für's Display; diese werden in einem Extrathread ans Display geschickt, das heißt, diese beiden müssen auch noch aufeinander getimed werden.
Wer es nicht selbst versucht hat, kann nur schwer erahnen, was für ein Aufwand das ist, denn jeder (!) dieser Threads läuft unterschiedlich oft und unterschiedlich lange (allerdings einigermaßen berechenbar). Weiterhin hat jeder Thread seine eigene Priorität - das Betriebssystem entscheidet, wann der Thread denn nun tatsächlich zum Zuge kommt und ist somit nicht kontrollierbar.
Das alles ist im Idle-Betrieb kein Problem, wenn aber ein Spiel läuft und massenhaft CPU-Zeit konsumiert, wird es spannend - bei einer HT-CPU wird es noch wesentlich lustiger, weil wir dann ZWEI CPU's haben.
Und nun leg einen sechsten Thread auf, der mit den anderen drei abgestimmt werden muß, dabei aber gänzlich unberechenbare Laufzeiten hat. Du kannst es selbst versuchen mit fünf eigenen Programmen, zu dem noch ein sechstes hinzukommt.
@xonom & all: Kühlt mal wieder etwas ab. Immer locker bleiben
|
|
|
|
|
Gespeichert
|
Erstens: Lies was da steht. Zweitens: Denk drüber nach. Drittens: Dann erst fragen
|
|
|
xonom
Gast
|
wie jetzt warum abkühlen? war doch noch garnet heiß!!! 
bin nur auf stglcd gespannt!
@olaf und das was du geschrieben hast habsch doch auch gesagt! 
PS:Du bist der beste!
|
|
|
|
|
Gespeichert
|
|
|
|
Seiten: [1] 2 
|
|
|
|
|
