You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(5) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(80) |
Feb
(10) |
Mar
|
Apr
(13) |
May
|
Jun
|
Jul
|
Aug
(22) |
Sep
(37) |
Oct
(27) |
Nov
(20) |
Dec
(2) |
2004 |
Jan
(20) |
Feb
(35) |
Mar
(17) |
Apr
(15) |
May
(44) |
Jun
(9) |
Jul
(14) |
Aug
(4) |
Sep
(1) |
Oct
(17) |
Nov
(23) |
Dec
(5) |
2005 |
Jan
(13) |
Feb
(4) |
Mar
(49) |
Apr
(30) |
May
(13) |
Jun
(24) |
Jul
(26) |
Aug
(13) |
Sep
(3) |
Oct
(38) |
Nov
(19) |
Dec
(68) |
2006 |
Jan
(14) |
Feb
(6) |
Mar
(12) |
Apr
(4) |
May
(16) |
Jun
(49) |
Jul
(40) |
Aug
(8) |
Sep
(2) |
Oct
(4) |
Nov
(16) |
Dec
(42) |
2007 |
Jan
(65) |
Feb
(36) |
Mar
(18) |
Apr
(70) |
May
(2) |
Jun
|
Jul
(9) |
Aug
(13) |
Sep
(13) |
Oct
(33) |
Nov
(173) |
Dec
(116) |
2008 |
Jan
(217) |
Feb
(5) |
Mar
(22) |
Apr
(1) |
May
|
Jun
(7) |
Jul
(4) |
Aug
(30) |
Sep
(6) |
Oct
(8) |
Nov
(17) |
Dec
(15) |
2009 |
Jan
(117) |
Feb
(2) |
Mar
(1) |
Apr
(24) |
May
(18) |
Jun
(30) |
Jul
(13) |
Aug
(51) |
Sep
(2) |
Oct
(5) |
Nov
(10) |
Dec
(47) |
2010 |
Jan
(9) |
Feb
(35) |
Mar
(84) |
Apr
|
May
(2) |
Jun
(8) |
Jul
(6) |
Aug
(1) |
Sep
(3) |
Oct
(2) |
Nov
(3) |
Dec
(24) |
2011 |
Jan
(7) |
Feb
(1) |
Mar
(2) |
Apr
(1) |
May
|
Jun
|
Jul
(10) |
Aug
(26) |
Sep
|
Oct
(12) |
Nov
(2) |
Dec
(4) |
2012 |
Jan
(38) |
Feb
(28) |
Mar
(1) |
Apr
(2) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(60) |
Nov
(13) |
Dec
|
2013 |
Jan
(32) |
Feb
(1) |
Mar
(16) |
Apr
(4) |
May
(7) |
Jun
(6) |
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
(1) |
Dec
(6) |
2014 |
Jan
(110) |
Feb
(38) |
Mar
(2) |
Apr
|
May
|
Jun
(1) |
Jul
(3) |
Aug
(1) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
(2) |
Mar
(11) |
Apr
(8) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
(3) |
Feb
|
Mar
|
Apr
(26) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
(13) |
Feb
(1) |
Mar
(1) |
Apr
(2) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(5) |
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
(46) |
Apr
(22) |
May
(12) |
Jun
(12) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2021 |
Jan
(5) |
Feb
(8) |
Mar
(2) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
2023 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2024 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Manuel B. <web...@ma...> - 2003-02-08 11:35:54
|
Hallöchen! Ich bin gerade dabei eine neue Hardware-Komponente für meine I2C-Steuerung zu entwickeln (besser gesagt, sie ist so gut wie fertig). Dabei habe ich dann auch die Möglichkeit den Bus abzuschalten, d.h. die Stromversorgung der folgenden Module zu deaktivieren. Dadurch "vergessen" die Relaiskarten aber alle ihren Zustand und wenn sie wieder mit Strom versorgt werden, ist alles deaktiviert wie nach einem Reset. Deshalb meine frage, wie die anderen Hardware-Varianten (m605x, etc) auf ein POWER OFF reagieren und vor allem, wie sie sich dann nach einem folgenden POWER ON verhalten. Setzten sie alles wieder so wie es vor dem POWER OFF war? Für Magnetartikel ist das ja unwichtig, die bleiben so stehen wie sie waren, aber da meine Steuerung für analoge Anlagen ausgelegt ist, kann ich mit den Relaiskarten auch Gleisabschnitte stromlos Schalten (Abstellgleise, z.B.) und genau dazu muss ich wissen, ob der srcpd nun quasi von der Hardware erwartet nach dem POWER ON wieder alles herzustellen, wie es vor dem POWER OFF war. Im Grunde hat diese Frage keinen Einfluss auf die Hardware, ich muss das nur wissen, um ggf. nach einem POWER ON per Software wieder alles auf den alten Stand zu setzten. Viele Grüße, Manuel -- web...@ma... http://www.matronix.de - http://www.e-online.de/public/borchers 12:28pm up 17 min, 2 users, load average: 0.33, 0.56, 0.38 |
From: Matthias T. <mt...@we...> - 2003-02-07 17:03:18
|
Hallole, der loopback Bus behauptet, er k=F6nne FB. Nur meldet der nie =C4nderungen bei solchen. W=E4re es eine gute Idee, da Abhilfe zu schaffen? - per Zufall zwischen 1..maxfb - der reihe nach von 1 bis maxfb jede xx Zeiteinheiten - es so lassen, wie es ist - ?? beim aktuellen srcpd habe ich das TIME Modul aktiviert. Nebenbei auch einige Dinge im INFO Modus ge=E4ndert, die potentiell zu Speicherlecks f=FChren k=F6nnen. Bei meinen Tests lief aber alles stabil (48 Stunden Dauerlauf mit laufender Zeit (faktor 100 beschleunigt) und heftiger SET Befehle, die an 10 INFO Sessions geschickt werden mu=DFten; dabei ist mir die eigentlich nicht vorhandene FB Unterst=FCtzung des loopback aufgefallen) Matthias |
From: Matthias T. <mt...@we...> - 2003-02-04 21:05:33
|
Franz Sieloff wrote: > Das ist schon richtig aber der Teufel ist ein Eichh=F6rnchen. Und ich = kann=20 > eigentlich auch =FCberall damit leben, ausser bei den R=FCckmeldungen. = Die sind=20 > schliesslich sicherheitsrelevant (hochtrabend). Aus denen wird geschlos= sen,=20 > ob ein Zug fahren darf oder nicht. Und da fehlt eigentlich schon eine I= NFO -=20 > - Meldung so wie fr=FCher in der alle gemeldet werden, egal welcher Zus= tand. So=20 > gesehen ist das mein einziger Kritikpunkt am srcp. Das mag gehen wen de= r srcp=20 > direkt an den Eingabebausteinen h=E4ngt. Aber wenn dann noch eine=20 > Steuerzentrale dazwischen liegt?=20 hmm. Die Logik ist eigentlich einfach: Irgendein System sammelt die=20 Daten von der/den Modellbahnger=E4ten und h=E4lt sie permanent aktuell. Das passiert alles serverintern. Sobald sich ein Client mit einer INFO Session anmeldet, bekommt er sofort den aktuellen Stand mitgeteilt und anschlie=DFend jegliche =C4nderungen. Eine gewisse Form der Optimieru= ng hierbei ist, das R=FCckmelder, die den Status 0 haben, nicht gemeldet werden. Dies erg=E4be eine sehr umfangreiche Flut von Meldungen, von denen wir =FCberzeugt waren, das sie unn=F6tig ist. Allerdings gebe ich d= ir recht: das ist eine Heuristik f=FCr den Client. Denn der kann den =DCberg= ang von der initialen Informationsflut zum Regelbetrieb nicht erkennen. Bislang. > Das ist einfach eine Sequenz wie lese alle Anlagedaten->=DCbertrage all= e zum=20 > Client... meiner Meinung nach notwendig weil es einfach zu viele Stelle= n=20 > gibt, wo etwas verloren gehen kann. Die IB =FCbertr=E4gt zwar w=E4hren= dem Power=20 > Off weiter alle S88-Daten (angeblich) aber ich hatte da schon definitiv= =20 > Schwierigkeiten hmm. erkennt der IB-Treiber den POWER OFF Zustand? Wenn ein SRCP Befehl POWER OFF kommt, wird jegliche Kommunikation mit der IB eingestellt. > Man k=F6nnte es was die IB betrifft, so l=F6sen, da=DF beim Power On im= mer alle S88=20 > eingelesen werden. Das gehrt ruck zuck. Dann werden auf jeden Fall alle= =20 > =C4nderungen =FCbertragen. hmm. Beim 6051 ist das auch so. Beim POWER OFF passiert gar nichts, sobald POWER ON kommt, werden die =C4nderungen gegen=FCber dem letzten PO= WER ON Stand ermittelt. Insofern etwas einfacher. Das 6051 kann aber auch keine Meldungen an den Rechner =FCbermitteln (erkennt ja nicht mal ein POWER OFF wegen Kurzschlu=DF oder so). Der Ablauf sollte eigentlich so sein, das der IB Treiber alle Ver=E4nderungen erkennen mu=DF, egal, ob zwischendurch ein POWER OFF (woh= er auch mmer) kommt. Wie auch immer. Das SRCP fordert das, dakann auch das srcpd-Framework nur bedingt hilfreich sein. >>W=E4re sch=F6n. Denn eigentlich will mal wieder eine Bin=E4rrelease >>basteln. Es sind hinreichend viele funktionierende Elemente >>am wirken, und auch viele Fehler weniger. >=20 >=20 > Ich glaube da brauch ich noch eine Weile bei ib.c. Schon klar. Nur =FCberlege ich, da es doch einiges bei den SRCP Befehlen gab, ob es derzeit nicht eine gute Idee w=E4re, mal wieder ein rpm zu basteln. Die IB ist zwar nicht uninteressant, aber eben nur ein Teil des srcpd. Ich stelle mir vor, das es durchaus Cliententwickler gibt, die aus dem loopback ihren Nutzen ziehen k=F6nnen. Und der ist ja erst jetzt so richtig einsetzbar, oder? >>>Es sind so etwa 15 St=FCck. =2E.. > Da sehe ich nicht. Ich glaube wenn ma die Fehlermeldungen nac Wawning/E= rror=20 > oder Syslog meldungen klassifiziert reicht das. ok. Alles, was sich in SRCP gie=DFen l=E4=DFt ("POWER OFF wegen Urlaub") sollte auch so kommen. Der Rest erst mal ins syslog. Ohne INFO an den Client. Ist vielleicht nicht der Weisheit letzter Schlu=DF, verhindert aber keine= Informationen. Non-SRCP konforme Meldungen will ich nicht an Clients senden. Wenn Du wirklich INFO's an die SRCP Clients schicken wolltest: Mit welcher Ger=E4tegruppe? Es gibt keine passende. IMHO. > Wer an den Mitarbeitern hat eigentlich auch eine IB. Michael ja wohl ni= cht,=20 > wenn ich das richtig verstanden habe. Und was ist mit Frank, der hat ja= =20 > schonl=E4nger nichts ge=E4ndert? Ja, nur Frank. Von dem habe ich seit dem Jahreswechsel aber nichts mehr geh=F6rt. Matthias |
From: Michael A. M. <Michael@Meiszl.De> - 2003-01-26 11:42:41
|
>Noch mal f=FCr mich zum mitmei=DFeln: Bitte keine Verhunzungen meines Namens :-) >Bei dem kann ich jedenfalls keine zwei Weichen gleichzeitig aktiv = halten. Wenn mich mein Eindruck nicht t=E4uscht, stimmt die Aussage nicht. Ich schaffe es zumindest drei Entkuppler gleichzeitig zu aktivieren, und da die am selben Dekoder wie die Weichen h=E4ngen, w=FCrd ich mal dreist = behaupten, auch der Weichenstrom bleibt anliegen, solange nicht ein 32 gesendet = wird. > Wahscheinlich mu=DF ich nur=20 > alles nac cc umbenennen und irgendwo im Makefile den Compiler = =E4ndern. N=F6, der gcc fri=DFt jeglichen Code, egal, wie er hei=DFt. >Was haltet ihr von einem Modulnamen wie srcpd++ ? BAH! |
From: Matthias T. <mt...@we...> - 2003-01-26 09:41:24
|
Hi, > Jetzt zu meinen Problemchen. Ich habe heute abend die IB-Schnittstelle = > getestet, und bekomme jetzt auch meine R=FCckmeldungen. Einer ist ein r= ichtiger=20 > Fehler und das werde ich zur=FCckchecken. Nur meine Init-Funktionen, di= e ja bei=20 > mir anders sind nicht.=20 hmm. Eigentlich w=E4rs w=FCnschenswert, wenn funktionierender Code nicht funkitonierenden Code ersetzen w=FCrde. Andererseits gehe ich mal davon aus, das der vorhandene Code irgendwo doch funktioniert. Da brauchen wir eben doch mal eine R=FCckmeldung der Tester. Und daf=FCr brauchen wir ein= en Alternative: Entweder ein Branch im CVS f=FCr die ib.c (ib.h?) oder die komplette Datei auf die Homepage des srcpd, zum selber kopieren. Oder wir machen beim n=E4chsten BETA Release einfach zwei binaries. Eines= mit dem "offziellem" Code und eines mit deinen. > Jetzt noch was anderes: > Wenn ich alle Signale auf einen Rutsch auf rot schalte, kommen nicht al= le=20 > R=FCckmeldungen, weil offensichtlich ein internes Feld zu klein ist und= dann=20 > =FCberl=E4uft. Noch mal f=FCr mich zum mitmei=DFeln: R=FCckmelder sind FB. Du hast demnach alle Signale mit R=FCckmeldern=20 verbandelt, die das aktuelle Signalbild anzeigen sollen. Die sind auch alle an der IB angeschlossen (das waren doch ein paar mehr S88 Module bei dir, oder?) > Geschaltet werden alle. Zumindes in ib.c werden dies interen=20 > Arrays noch noch jedesmal mit for... durchsucht, was auch nicht sehr ef= fektiv=20 > ist. Hmm. Wenn das ib Modul noch ein internes Array anlegt, im Framework gibts daf=FCr Queues. Frank hat jedoch eine andere L=F6sung f=FCr das Abschalten der Weichenantriebe gefunden. Die =FCber das tga-Array l=E4uft. Genaueres wei=DF ich da jedoch nicht, da die IB wohl auch an dieser Stelle besser als das 6021/6051 Gespann von M=E4rklin sein wird. Bei dem kann ich jedenfalls keine zwei Weichen gleichzeitig aktiv halten. > Eine inmeine Augen gute L=F6sung w=E4re folgende (habe ich schon mal ge= macht=20 > an anderer Stelle): [1 und 2 mal weggelassen wegen eigentlich nur Einleitung f=FCr 3] > 3. Anstelle der internen arrays stl-queues verwenden. Das geht auf jede= n Fall=20 > und man hat mehrere Vorteile: Wenn Du Dir den Rest des srcpd anschaust, wirst Du arrays im wesentlichen nur noch bei der Speicherung des Zustandes finden, die Kommunikation zwischen den einzelnen Modulen l=E4uft nur noch =FCber Queues. Was die Module dann intern machen, ist deren Problem. Jetzt C++: > Sieht zwar kryptisch=20 > aus aber im Prinzip sind das zwei Aufrufe und die Deklaration. Wenn ma= n dann=20 > noch eine mutex nicmmt, kann man den Thread solange stilllegen, bis etw= as in=20 > die Queue geschrieben wird. Er wird dan automatisch vom Betriebsystem=20 > weitergestartet. Schau dir die bestehenden Queues an. Die arbeiten allesamt (zumindest=20 sollten sie dies) genau so. > Als Nebenprodukt k=F6nnte man so nach und nach die ganzen strcmp ... st= rcopy =20 > usw mit Hilfe der stl string Klasse und die scanf mit streams erledigen= , was=20 > auch sehr elegant geht aber zugegebenermassen nicht ganz so einfach ist= =2E > Vor allem die Streams sind gew=F6hnungsbed=FCrftig.=20 ^^^^^^^^^^^^^^^^^^^ Genau dies hindert mich, C++ zu benutzen. Zus=E4tzlichdann kommt dann noch das ganze OO Thema hoch: Eigentlich sind die Busse ja Sub- und Superklassen voneinander und die Kommandos mit den Ger=E4ten sowieso. Und dann werden Messages von a nach b gesendet, die mit ....... Und dann streiten wir nicht mehr um lowlevel Kram, sondern um das "beste = OO Design" des srcpd. Deswegen halte ich die Umstellung des srcpd vom=20 nackten C hin zu C++ f=FCr nicht ganz so trivial und vor allem mit einem massiven Folgeaufwand verkn=FCpft. Da ist es mit Sicherheit einfacher (und f=FCr Programmierlaien=20 nachvollziehbarer), beim C zu bleiben und einige Bibliotheken zu nutzen. = Denn die gibt es auch f=FCr C (siehe die libxml2), queues sind f=FCr mich= kein Grund, die STL und damit C++ zu nutzen. F=FCr kryptische Stringverarbeitung kann mach auch das lex/yacc Gespann nutzen. In C ;=3D)= Und eine Priorit=E4tenqueue mit zeitlichen Events auf Millisekundenraster= (wie sie ja f=FCr die IB gedacht ist) d=FCrfte auch die STL einige N=FCss= e zum Knacken geben: Die Events d=FCrfen eben erst zur Zielzeit aus der Queue herausfallen. In der Zeit hat man auch den C Code der jetzigen Queues erweitert. IMHO (die mu=DF nicht stimmen, ich bin kein Programmierer) > Das mit der Umstellung auf c++ k=F6nnet ich schon machen. Nur m=FCsste = man sich=20 > =FCberlegen wie man vorgeht. Vielleicht einen neuen Tree tree unter cv= s=20 > aufsetzten. Vieleicht kannst du mal nachfragen was die anderen davon ha= lten.=20 > Ich werde morgen mal zuerst nach dem fehlenden File suchen und dann mal= =20 > ausprobieren wie kompliziert diese Umstellung ist.Wahscheinlich mu=DF i= ch nur=20 > alles nac cc umbenennen und irgendwo im Makefile den Compiler =E4ndern.= Du m=FC=DFtest autoconf umstellen. Das Makefile ist nur generiert. Wenn D= u=20 unbedingt C++ benutzen willst, k=F6nnen wir gerne ein Parallelmodul=20 aufsetzen, wie den jsrcpd, der auch parallel zum srcpd im CVS liegt und sonst keine Verbindung zum Rest hat. Zusammengefa=DFt: C++ halte ich nicht f=FCr die L=F6sung unserer Probleme= =20 sondern f=FCr die Quelle vieler neuer, wenn Du aber willst, werde ich dic= h=20 nicht hindern und eine Parallelwelt aufsetzen. Wenn sich herausstellt, das die C++ Implementierung besser ist (soll hei=DFen: robuster, f=FCr Einsteiger nachvollziehbarer, portabler, weniger Ressourcen verbrauchender), k=F6nnen wir immer noch wechseln. Die Rahmenbedingungen = sollten aber vergleichbar sein, um den Wechsel zwischen den zwei=20 Versionen einfach zu halten (die config-Datei, die Start/Stopmaschinerie usw). Was haltet ihr von einem Modulnamen wie srcpd++ ? Bis dahin bastele ich aber noch an der C Variante weiter. Matthias |
From: Michael A. M. <Michael@Meiszl.De> - 2003-01-23 09:40:49
|
Danke f=FCr den "Update often" Tip :-( Das meint meine Kiste zum "aktuellen" automake: Proxy:root:/usr/ports/devel/automake17#make =3D=3D=3D> automake17-1.7.1,1 is marked as broken: DON'T EVEN THINK = ABOUT IT.. |
From: Michael A. M. <Michael@Meiszl.De> - 2003-01-23 09:22:37
|
/usr/local/share/automake/am/depend2.am: AMDEP does not appear in = AM_CONDITIONAL /usr/local/share/automake/am/depend2.am: AMDEP does not appear in = AM_CONDITIONAL /usr/local/share/automake/am/depend2.am: AMDEP does not appear in = AM_CONDITIONAL /usr/local/share/automake/am/lang-compile.am: AMDEP does not appear in = AM_CONDITIONAL und nach configure: "Makefile", line 227: Need an operator "Makefile", line 228: Need an operator "Makefile", line 229: Need an operator "Makefile", line 230: Need an operator "Makefile", line 231: Need an operator "Makefile", line 232: Need an operator "Makefile", line 233: Need an operator .... (die anderen 1000 Zeilen spar ich mir) ??? MAM |
From: Matthias T. <mt...@we...> - 2003-01-19 11:11:39
|
Hallo zusammen, auf der Homepage des srcpd (http://srcpd.sourceforge.net/srcpd/ ) habe=20 die Doku entwas entflochten und erweitert. Ab sofort gibt es dort einen Bereich f=FCr die Konfiguration, einen f=FCr= =20 Client-Entwickler und einen f=FCr Serverentwickler. Die zugeh=F6rigen Dateien fangen alle mit srcpd2 an (au=DFer index-2). Die Konfiguration habe ich lediglich um den auto_power_on Teil erg=E4nzt = (damit k=F6nnen die Busse bei Serverstart automatisch eingeschaltet=20 werden, der Default des SRCP ist bekanntlich AUS) Bei den Serverentwicklern habe ich nur den Link zum HOWTO (mehr gibts ja = nicht, noch? Hallo Michael, wie weit bist Du mit den Bildern?) Bei den Cliententwicklern halte ich die Idee von Torsten Vogt mit den=20 Beispielsitzungen f=FCr brauchbar, da er aber nur DDL Sitzungen haben=20 will, machen wir eben unsere eigene Seite damit ... Wer weitere Sitzungen beisteuern will, sei herzlich dazu eingeladen. Mein kleines perl Sciptelchen f=FCr den INFO Modus kann ich gerne bereitstellen... Matthias |
From: Michael A. M. <Michael@Meiszl.De> - 2003-01-16 18:16:33
|
<Reply to!!!> >Ach ja: Wer macht das Codeaudit bzgl. Security, der srcp l=E4uft >schlie=DFlich mit root-Rechten im Netzwerk!? (hatten wir nicht einen >Security-Guru unter uns?) ich bin n=E4chsten Dienstag eh mal wieder beim BSI, soll ich mal fragen, = ob sich einer opfert ? :-))) Solange da scanf()-s drin sind, mach ich mir =FCber Bufferoverflows = keinen Kopp. Da m=FCssten ja alle Formatstrings =FCberarbeitet werden. Und dann noch malloc()... am besten #define malloc(x) calloc(x,1) |
From: Matthias T. <mt...@we...> - 2003-01-16 18:02:52
|
Michael A. Meiszl wrote: >>- GL k=F6nnen beliebig viele Funktionen haben, wieviele genau, steht im= >>INIT. Derzeit sind =FCberall 4 (resp.5) Funktionen hart codiert, das mu= =DF >>flexibler werden. Inkl. der passenden Fehlermeldungen. >=20 > Hmm, die sscanf Orgie ist mir auch schon aufgefallen, ich k=F6nnte mich= opfern, da > was universelleres mir auszudenken mit variablen parametern (so a-la ge= topt()). Aber deswegen gleich zu lex/yacc wechseln? Ist sowas wie mit Kanonen auf = Spatzen zu schie=DFen. Und einen wirklichen Reuse vom ddl-erddcd sehe ich= auch nicht als Ergebnis. >>- Der Zeitgeber (TIME) mu=DF ans fliegen kommen >=20 > Nicht meine Baustelle, ich hab noch garnicht verstanden, wof=FCr das pr= aktisch > verwendbar sein soll. Ich bastele an einem Fahrplanprogramm, das braucht Zeitinput. (Wenn Dir das nicht reicht: TIME steht im SRCP drin, also musses auch in den srcpd ;=3D) ) > Die Uhren sollten doch eh synchron sein (bei mir ist das so :-) ), Der Konjunktiv hat es treffend beschrieben. SRCP ist auch nicht als=20 Ersatz zum NTP zu sehen... [SM, DESCRIPTION] > (nicht als n=F6rgeln verstehen). > Ich hab da mal nur einen kurzen grausamen Blick drauf geworfen. Ausser > Nichtverstehen kam mir nur ein einziger Gedanke: "wof=FCr wurde eigentl= ich C++ entwickelt?" Das man auch in C OO hinbekommen kann, zeigt gtk (und dessen Abk=F6mmling= gnome). > Nicht dass ich der Objektguru bin (eher im Gegenteil, da ich mich mehr = auf den unteren > Etagen der Betriebssysteme rumtreibe), aber DER Kram sieht mir daf=FCr = recht pr=E4destiniert aus. Das steht als vage Idee ohnehin hinter ziemlich viel im SRCP: Busse,=20 Ger=E4te, Ger=E4tegruppen, Kommandos. >=20 > Was mir noch aufgefallen ist: in den einzelnen Treiber sind teilweise d= oppelte Funktionen=20 > f=FCr die gleiche Aktion enthalten (z.B writeByte() usw.), die k=F6nnte= ich mal einsammeln=20 > und in eine eigene Datei auslagern ?!?!? Meist gibt es einen Grund f=FCr diese Dopplung. Manchmal aber auch nicht.= =20 Wenn Du da aber zusammenfa=DFt, halte ich es f=FCr nicht so clever, in de= n "lowlevel" Routinen pl=F6tzlich Busparameter direkt zu benutzen. >>- Bei den R=FCckmeldern wird recht einfach alles durchgehechelt. Das ka= nn >>man effizienter machen. >=20 >=20 >>- Die internen Datenstrukturen bei den GA/GL/FB sind sehr >>verschwenderisch, was den Platzbedarf angeht. Eine doppelt indirekte >>Adressierung sollte da f=FCr weniger RAM Bedarf sorgen. Sie ist aber ni= cht >=20 > Der Speicherbedarf ist relativ unwichtig. RAM hat man :-) Nicht immer. Es soll Leute geben, die haben einen 486er mit 16MB. Nicht das ich das als oberstes Ziel einstufen wollte, aber wenn es mit vertretbarem Aufwand machbar ist, sollten die auch mitspielen k=F6nnen. > Was mir aufgefallen ist, ist die konsequent inkonsequente Mischung von > dynamischen (malloc (sollte eh besser calloc sein)) und statischen Arra= ys. Stimmt. > Etwas verwirrend und so ab der dritten Pointerebene fehlt mir ein Poste= r :-) Mal Dir doch eins. Nutzen h=E4tten wir alle davon ;=3D) >>- Manuel meinte, das die GA Datenstruktur zu schwach f=FCr die SRCP >>Forderung w=E4re. Ich habe es noch nicht gepr=FCft, aber er k=F6nnte Re= cht >>haben. >=20 > Die Struktur kommt mir "merkw=FCrdig" vor. Ich hab mal ne Stunde dar=FC= ber > gebr=FCtet, war mir dann aber mit mir selbst einig, dass ich es nicht v= erstanden > habe, wozu das eigentlich gut ist und es dann zum PAL (Problem andere L= eute) > definiert :-))) Du solltest SRCP daneben legen und vergleichen, ob dessen Anforderungen=20 mit der Datenstruktur erf=FCllt werden k=F6nnen. Ist doch ganz einfach ;=3D= ) >>- Doku, Doku, Doku. Sch=F6n w=E4ren ein paar Bilder mit der Architektur= des >>srcpd (Zielformat w=E4re alles, was Webkomaptibel ist: PNG, HTML, PDF).= >=20 > JAAAA HER DAMIT! (lechz, hechel!) Opensource hei=DFt immer: Wenn was fehlt, selber machen. Und ans Projekt = zur=FCckgeben (es h=E4uft sich, aber es mu=DF folgen: ;=3D) ) >>Auch ein Ausbau des loopback.c zu einer wirklichen "Schablone" f=FCr ne= ue >>Treiber w=E4re sch=F6n (da es f=FCr andere Hardware als "cut'n'play" ge= lten >>kann. >=20 > Das w=E4re kein Problem, wenn Du einer gewissen rigorosen Umstrukturier= en > von register_bus() zustimmst.=20 Welcher Art? Was hast Du vor? > Das eigentliche Problem besteht ja nicht darin, einen neuen Treiber > aus loopback zu clonen, sondern man mu=DF wissen, wie man ihn einbindet= =2E > Hier eine universelere Schnittstelle, schon kann loopback durch ein > paar Makros zum Template werden. -v (oder -vvv, wenn ersteres zuwenig sein sollte) >>- einiges, was im Zusammenhang mit dem XML Format der srcpd.conf steht:= =20 >>eine dtd, ein Editierprogramm (gerne auch Webbasiert), einen Validator = >>etc pp. >=20 > Meine Meinung zu xml hatte ich doch schon mal dargelegt, oder? Klar und deutlich. Aber irgendwo will ich doch mal Manager sein ;=3D) > Aber dann kennst Du bestimmt die Adresse von Martin Wolf??? Die steht doch bei der Schaltung dabei?! Sonst mal google fragen, ob der = ihn kennt. > PPS: back to mailling lists... > Na gut (ist aber der Fehler der Liste. Da sollte ein ordentliches Reply= -To: liste rein) Schaun mer mal. Vielleicht sollten wir mal eine Roadmap basteln. Damit absehbar wird, was wann wichtig wird. Aus meiner Sicht steht jetzt erst mal eine SRCP konforme Schnittstelle an. Wenn die hinreichend gut erledigt ist (und die letzten Bugs aus dem SRCP raus sind), k=F6nnen erst die bereits erw=E4hnten internen Umbauten (lex/yacc, register_bus, snmp usw) starten.= Denn dann haben wir erst die Zeit, denn die Cliententwickler brauchen offensichtlich noch etwas l=E4nger... Und bis zum ersten Release k=F6nnen wir, denke ich, noch gut mit dem=20 jetzigen "schlechten" Code leben. Und den noch hinreichend wetterfest=20 machen. Ach ja: Wer macht das Codeaudit bzgl. Security, der srcp l=E4uft schlie=DFlich mit root-Rechten im Netzwerk!? (hatten wir nicht einen Security-Guru unter uns?) Matthias |
From: Michael A. M. <Michael@Meiszl.De> - 2003-01-15 21:05:49
|
>Sowas ist kein _Server_. Keine Redundanz. Oooch eigentlich schon. Bei 1HE hat man nicht viel Platz. Da liegt in = der Mitte ein Schaufelrad und saugt durch einen recht trickreichen Kanal = Luft durch die Laufwerke an und bl=E4st =FCber eine Heatpipe. Nur ist das in meinem Falle v=F6llig =FCberfl=FCssig, da der 19" Schrank = selber klimatisiert ist. Redundant sind nur die Netzteile. >mit L=E4rm durchkommen k=F6nnte. (Von =FCbervollen Plattenstapeln mit >15000 RPM Festplatten mal abgesehen, aber die sind wirklich selten, die Sach nix gegen die Platten. Hab 10 St=FCck davon im Einsatz, die h=F6rt = man nicht, die werden nicht warm! Hab noch 8 =E4ltere 10000er am Laufen, das genaue Gegenteil davon. >Testen, Testen, Testen. hmm, da mir die meiste Hardware fehlt kann ich nicht viel dazu = beitragen. Meine M605x Versuche waren bislang eigentlich recht befriediegend. Gebe allerdings zu, dass mit meiner kleinen Anlage (2x1,20m mit 10 = Weichen, 3 Entkupplern und 31 Kontakten) nicht viel Traffic zu machen = ist. Mehr als drei Loks passen da nicht druff. Ohne Wagen kann ich 6 = laufen lassen. >Ich sitze momentan an den Feinheiten der SRCP Dekodierung. Ansonsten=20 >w=E4ren eigentlich die Feinarbeiten, wie >- GL k=F6nnen beliebig viele Funktionen haben, wieviele genau, steht im >INIT. Derzeit sind =FCberall 4 (resp.5) Funktionen hart codiert, das = mu=DF >flexibler werden. Inkl. der passenden Fehlermeldungen. Hmm, die sscanf Orgie ist mir auch schon aufgefallen, ich k=F6nnte mich = opfern, da was universelleres mir auszudenken mit variablen parametern (so a-la = getopt()). >- Der Zeitgeber (TIME) mu=DF ans fliegen kommen Nicht meine Baustelle, ich hab noch garnicht verstanden, wof=FCr das = praktisch verwendbar sein soll. Die Uhren sollten doch eh synchron sein (bei mir = ist das so :-) ), da kann der client seine eigene Zeit nehmen. Selbst, wenn die = differieren ist es egal, dann ist die Zeit eben relativ zum Client. >- DESCRIPTION, SESSION, LOCKS m=FCssen sauber (und komplett) erledigt >werden. Momentan wird nur eine gewisse Minimalforderung erf=FCllt. >- Die Formatierung der SM Ger=E4te (nein, nicht was Du jetzt wieder = denken >magst ;=3D) ) ist verstreut: sowohl in srcp-info als auch in srcp-sm. >Meine Vorstellung ist, das sich jede Ger=E4tegruppe in genau einer (c-) >Datei widerspiegelt, der Rest des Programms agiert nur =FCber = Funktionen. >Auch erscheint mir der srcp-info als zu =FCberladen. Viele der = Funktionen >sind eigentlich unn=F6tig (insb. die queueGA/queueGL etc). (nicht als n=F6rgeln verstehen). Ich hab da mal nur einen kurzen grausamen Blick drauf geworfen. Ausser Nichtverstehen kam mir nur ein einziger Gedanke: "wof=FCr wurde = eigentlich C++ entwickelt?" Nicht dass ich der Objektguru bin (eher im Gegenteil, da ich mich mehr = auf den unteren Etagen der Betriebssysteme rumtreibe), aber DER Kram sieht mir daf=FCr = recht pr=E4destiniert aus. Was mir noch aufgefallen ist: in den einzelnen Treiber sind teilweise = doppelte Funktionen=20 f=FCr die gleiche Aktion enthalten (z.B writeByte() usw.), die k=F6nnte = ich mal einsammeln=20 und in eine eigene Datei auslagern ?!?!? >- Bei den R=FCckmeldern wird recht einfach alles durchgehechelt. Das = kann >man effizienter machen. >- Die internen Datenstrukturen bei den GA/GL/FB sind sehr >verschwenderisch, was den Platzbedarf angeht. Eine doppelt indirekte >Adressierung sollte da f=FCr weniger RAM Bedarf sorgen. Sie ist aber = nicht Der Speicherbedarf ist relativ unwichtig. RAM hat man :-) Was mir aufgefallen ist, ist die konsequent inkonsequente Mischung von dynamischen (malloc (sollte eh besser calloc sein)) und statischen = Arrays. Etwas verwirrend und so ab der dritten Pointerebene fehlt mir ein Poster = :-) >- Manuel meinte, das die GA Datenstruktur zu schwach f=FCr die SRCP >Forderung w=E4re. Ich habe es noch nicht gepr=FCft, aber er k=F6nnte = Recht >haben. Die Struktur kommt mir "merkw=FCrdig" vor. Ich hab mal ne Stunde = dar=FCber gebr=FCtet, war mir dann aber mit mir selbst einig, dass ich es nicht = verstanden habe, wozu das eigentlich gut ist und es dann zum PAL (Problem andere = Leute) definiert :-))) >- Doku, Doku, Doku. Sch=F6n w=E4ren ein paar Bilder mit der Architektur = des >srcpd (Zielformat w=E4re alles, was Webkomaptibel ist: PNG, HTML, PDF). JAAAA HER DAMIT! (lechz, hechel!) >Auch ein Ausbau des loopback.c zu einer wirklichen "Schablone" f=FCr = neue >Treiber w=E4re sch=F6n (da es f=FCr andere Hardware als "cut'n'play" = gelten >kann. Das w=E4re kein Problem, wenn Du einer gewissen rigorosen = Umstrukturieren von register_bus() zustimmst.=20 Das eigentliche Problem besteht ja nicht darin, einen neuen Treiber aus loopback zu clonen, sondern man mu=DF wissen, wie man ihn einbindet. Hier eine universelere Schnittstelle, schon kann loopback durch ein paar Makros zum Template werden. >- einiges, was im Zusammenhang mit dem XML Format der srcpd.conf steht: = >eine dtd, ein Editierprogramm (gerne auch Webbasiert), einen Validator=20 >etc pp. Meine Meinung zu xml hatte ich doch schon mal dargelegt, oder? Wenn nicht, hier noch ein Zitat von mir, aus einer Besprechung letzter = Woche. Da meinte son T-Systems Heini, die gerade zwei Serveranwendungen auf der gleichen Maschine miteinander reden lassen sollten (beide von denen): "Dann schreiben wir einen XML Generator f=FCr Task 1, der die Daten = strukturiert auf der Platte ablegt, wo Task 2 sie dann zyklisch mit = einer neu zu entwickelnden Funktion einliest". MAM's Antwort: "Haben Sie keine richtigen Programmierer???" >Genau dies werd ich nicht tun. Jeder kann das machen, was nicht schon=20 >gemacht ist. Ich habe keine Lust, den gro=DFen Manager zu spielen ;=3D) s.u. >Reichen die obigen? Manche sind wirklich nur mit Kenntnis der = Algorithem=20 >und Datenstrukturen zu machen, und eher nicht f=FCr Hobbyprogrammierer. Na ja, ich glaub nicht, dass mit srcpd Geld verdienen kann :-) >Daneben: Torsten Vogt bastelt an seinem D=E4mon mit einem yacc/lex = parser=20 >f=FCr SRCP. Und hat schon =F6fter mal "gebarmt", das sich sonst keiner = daf=FCr=20 >interessiert. Meine L=F6sung mit den sscanf ist ja nicht wirklich = sch=F6n,=20 >sie hat nur den Charme, das sie keine "unverst=E4ndlichen" Tools = benutzt.... Sch=F6n das zu h=F6ren, w=E4re auch mein Vorschlag gewesen, gut, dass = ich noch nicht viel daran rumgestrickt habe (alter parser-generator-freak :-) ) (Fortsetzung von oben: Warum wu=DFte ich das nicht? Wo steht das? Fast = doppelt gemoppelt!) >Ich kenn auch keinen, der eine Platine hat. Nur eben den Martin Wolf, >der die _Schaltung_ entwickelt hat. Ob der eine Platine hat, keine >Ahnung. Aber dann kennst Du bestimmt die Adresse von Martin Wolf??? >PS: Im Februar wollte ich die n=E4chste Betarelease basteln. Die sollte = >dann schon hinreichend SRCP konform sein, um die Clientprogrammierer >auf ein sicheres Fundament zu stellen. PPS: back to mailling lists... Na gut (ist aber der Fehler der Liste. Da sollte ein ordentliches = Reply-To: liste rein) MAM |
From: Matthias T. <mt...@we...> - 2003-01-15 20:09:38
|
Hallo Michael, > denn der neue Server, der gestern eintraf, hat zwar nur einen einzigen = L=FCfter Sowas ist kein _Server_. Keine Redundanz. > Nachdem selbst im Nebenraum kein ruhiges Arbeiten mehr m=F6glich war, m= usste ich Hand anlegen... Huch? Ne 390 (oder ne BS2000)?, sonst kenn ich nichts, was durch W=E4nde= mit L=E4rm durchkommen k=F6nnte. (Von =FCbervollen Plattenstapeln mit 15000 RPM Festplatten mal abgesehen, aber die sind wirklich selten, die lauten Systeme). > Um wieder in Tritt zu kommen, sollten wir mal =FCberlegen, WAS zu tun i= st Testen, Testen, Testen. Ich sitze momentan an den Feinheiten der SRCP Dekodierung. Ansonsten=20 w=E4ren eigentlich die Feinarbeiten, wie - GL k=F6nnen beliebig viele Funktionen haben, wieviele genau, steht im INIT. Derzeit sind =FCberall 4 (resp.5) Funktionen hart codiert, das mu=DF= flexibler werden. Inkl. der passenden Fehlermeldungen. - Der Zeitgeber (TIME) mu=DF ans fliegen kommen - DESCRIPTION, SESSION, LOCKS m=FCssen sauber (und komplett) erledigt werden. Momentan wird nur eine gewisse Minimalforderung erf=FCllt. - Die Formatierung der SM Ger=E4te (nein, nicht was Du jetzt wieder denke= n magst ;=3D) ) ist verstreut: sowohl in srcp-info als auch in srcp-sm. Meine Vorstellung ist, das sich jede Ger=E4tegruppe in genau einer (c-) Datei widerspiegelt, der Rest des Programms agiert nur =FCber Funktionen.= Auch erscheint mir der srcp-info als zu =FCberladen. Viele der Funktionen= sind eigentlich unn=F6tig (insb. die queueGA/queueGL etc). - Bei den R=FCckmeldern wird recht einfach alles durchgehechelt. Das kann= man effizienter machen. - Die internen Datenstrukturen bei den GA/GL/FB sind sehr verschwenderisch, was den Platzbedarf angeht. Eine doppelt indirekte Adressierung sollte da f=FCr weniger RAM Bedarf sorgen. Sie ist aber nich= t so einfach zu implementieren (Wobei zu beachten w=E4re: Diese =C4nderung darf nichts an der API =E4ndern). Damit lassen sich vermutlich auch die INFO Queues beschleunigen (die dann ja nicht mehr stupide alle vorhandenen Adressen durchhecheln m=FCssen). - Manuel meinte, das die GA Datenstruktur zu schwach f=FCr die SRCP Forderung w=E4re. Ich habe es noch nicht gepr=FCft, aber er k=F6nnte Rech= t haben. - Doku, Doku, Doku. Sch=F6n w=E4ren ein paar Bilder mit der Architektur d= es srcpd (Zielformat w=E4re alles, was Webkomaptibel ist: PNG, HTML, PDF). Auch ein Ausbau des loopback.c zu einer wirklichen "Schablone" f=FCr neue= Treiber w=E4re sch=F6n (da es f=FCr andere Hardware als "cut'n'play" gelt= en kann. - einiges, was im Zusammenhang mit dem XML Format der srcpd.conf steht:=20 eine dtd, ein Editierprogramm (gerne auch Webbasiert), einen Validator=20 etc pp. - ..... >, und danach WER WAS zu tun hat. Genau dies werd ich nicht tun. Jeder kann das machen, was nicht schon=20 gemacht ist. Ich habe keine Lust, den gro=DFen Manager zu spielen ;=3D) > Bin im Moment unterbesch=E4ftigt (nur nervige Telefonate mit irgendwelc= hen Ministerien. Sowas zieht sich > wochenlang hin, bis man endlich was umkonfigurieren darf)... >=20 > Gib mal ne sinnvolle Aufgabe r=FCber... Reichen die obigen? Manche sind wirklich nur mit Kenntnis der Algorithem = und Datenstrukturen zu machen, und eher nicht f=FCr Hobbyprogrammierer. Daneben: Torsten Vogt bastelt an seinem D=E4mon mit einem yacc/lex parser= =20 f=FCr SRCP. Und hat schon =F6fter mal "gebarmt", das sich sonst keiner da= f=FCr=20 interessiert. Meine L=F6sung mit den sscanf ist ja nicht wirklich sch=F6n= ,=20 sie hat nur den Charme, das sie keine "unverst=E4ndlichen" Tools benutzt.= =2E.. > PS: hab nochnichtmal die Mailadresse von dem Typen mit der Platine gefu= nden. ?!?!? Ich kenn auch keinen, der eine Platine hat. Nur eben den Martin Wolf, der die _Schaltung_ entwickelt hat. Ob der eine Platine hat, keine Ahnung. Matthias PS: Im Februar wollte ich die n=E4chste Betarelease basteln. Die sollte=20 dann schon hinreichend SRCP konform sein, um die Clientprogrammierer auf ein sicheres Fundament zu stellen. PPS: back to mailling lists... |
From: Matthias T. <mt...@we...> - 2003-01-15 17:57:10
|
Michael A. Meiszl wrote: > netserver.c:72: conflicting types for `socket_writereply' > netserver.h:14: previous declaration of `socket_writereply' > > Wer wars ??? cvs log netserver.h sagt es Dir. (Wenn Du in der richtigen Sandbox bist) Matthias |
From: Michael A. M. <Michael@Meiszl.De> - 2003-01-15 07:58:56
|
netserver.c:72: conflicting types for `socket_writereply' netserver.h:14: previous declaration of `socket_writereply' Wer wars ??? |
From: Matthias T. <mt...@we...> - 2003-01-14 15:59:52
|
Hallo zusammen, Franz ist unserer neuestes Teammitglied. Einige werden ihn schon "erlebt" haben, da er einige Ideen zur Intellibox bereitgesteuert hat. Happy Hacking Matthias |
From: Manuel B. <web...@ma...> - 2003-01-12 16:41:38
|
Am Son, 2003-01-12 um 16.59 schrieb Matthias Trute: > grade beim checkin passiert: [...] Funktioniert alles noch nicht so ganz, wie ich mir das vorstelle, hab syncmail erst mal wieder deaktiviert. Werde da in den nächsten Tage dran basteln... Ciao, Manuel -- web...@ma... http://www.matronix.de - http://www.e-online.de/public/borchers 5:39pm up 1 day, 21:22, 5 users, load average: 0.08, 0.12, 0.12 |
From: Matthias T. <mt...@we...> - 2003-01-12 15:59:28
|
Hi, grade beim checkin passiert: Mailing src...@li...... Generating notification message... Generating notification message... done. Mailing src...@li...... Generating notification message... Traceback (innermost last): File "/cvsroot/srcpd/CVSROOT/syncmail", line 322, in ? main() File "/cvsroot/srcpd/CVSROOT/syncmail", line 315, in main blast_mail(subject, people, specs[1:], contextlines, fromhost) File "/cvsroot/srcpd/CVSROOT/syncmail", line 240, in blast_mail print calculate_diff(file, contextlines) File "/cvsroot/srcpd/CVSROOT/syncmail", line 139, in calculate_diff file, oldrev, newrev = string.split(filespec, ',') ValueError: unpack list of wrong size Ahoi Matthias |
From: Matthias T. <mt...@we...> - 2003-01-12 13:57:46
|
Hallo Michael, Deine Ratschl=E4ge mal beherzigend (und lange in altem Papier kramend)=20 habe ich meine IO Karte auf den von BSD gew=FCnschten Wert (0x378, IRQ7=20 (oder wars 5?, egal)) umgejumpert. srcpd neu =FCbersetzt (wie ist eigentlich das Packetmanagement unter=20 FreeBSD?) und gestartet. Ergebnis: Viele Phantommeldungen vom S88 Bus (das 605x habe ich nicht=20 getestet), darunter aber auch die, die ich verursacht hatte. Ein =E4hnliches verhalten (aber deutlich weniger Phantommeldungen) gabs=20 unter Linux. Daraus ziehe ich mal k=FChn die Schlu=DFfolgerung, das es=20 funktioniert, aber meine Konfiguration zu wackelig ist. Wir sollten vielleicht doch mal ein kleines tool basteln, das die=20 conf-Datei erzeugen kann. Tcl/TK w=FCrde sich anbieten (l=E4uft auch unte= r=20 Windows). Mu=DF ja f=FCr den Anfang keine vorhandene Datei einlesen, eine= =20 neu schreiben k=F6nnt erst mal reichen. Viele Gr=FC=DFe Matthias |
From: <mbo...@us...> - 2003-01-12 12:28:12
|
Update of /cvsroot/srcpd/CVSROOT In directory sc8-pr-cvs1:/tmp/cvs-serv15898 Modified Files: loginfo syncmail Log Message: only send info of commits, without including diffs Index: loginfo =================================================================== RCS file: /cvsroot/srcpd/CVSROOT/loginfo,v retrieving revision 1.2 retrieving revision 1.3 diff -C2 -d -r1.2 -r1.3 *** loginfo 11 Jan 2003 18:06:12 -0000 1.2 --- loginfo 12 Jan 2003 12:28:08 -0000 1.3 *************** *** 26,28 **** #DEFAULT (echo ""; id; echo %{sVv}; date; cat) >> $CVSROOT/CVSROOT/commitlog ! DEFAULT $CVSROOT/CVSROOT/syncmail %{sVv} src...@li... --- 26,28 ---- #DEFAULT (echo ""; id; echo %{sVv}; date; cat) >> $CVSROOT/CVSROOT/commitlog ! DEFAULT $CVSROOT/CVSROOT/syncmail %{s} src...@li... Index: syncmail =================================================================== RCS file: /cvsroot/srcpd/CVSROOT/syncmail,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -d -r1.1 -r1.2 *** syncmail 11 Jan 2003 18:06:12 -0000 1.1 --- syncmail 12 Jan 2003 12:28:09 -0000 1.2 *************** *** 229,233 **** From: %(author)s To: %(people)s ! Subject: %(subject)s ''' % {'author' : author, 'people' : string.join(people, COMMASPACE), --- 229,233 ---- From: %(author)s To: %(people)s ! Subject: CVS %(subject)s ''' % {'author' : author, 'people' : string.join(people, COMMASPACE), |
From: Manuel B. <web...@ma...> - 2003-01-12 12:25:25
|
Am Son, 2003-01-12 um 12.59 schrieb Matthias Trute: > die commit Mail ist mir zu umfangreich. Kann der Code-diff auch > entfallen? Die ersten Zeilen reichen vollkommen. Ich werde das Script umbasteln... Ciao, Manuel -- web...@ma... http://www.matronix.de - http://www.e-online.de/public/borchers 1:24pm up 1 day, 17:07, 5 users, load average: 0.37, 0.40, 0.35 |
From: Matthias T. <mt...@we...> - 2003-01-12 12:20:58
|
Hallo zusammen, die commit Mail ist mir zu umfangreich. Kann der Code-diff auch entfallen? Die ersten Zeilen reichen vollkommen. Matthias |
From: <mt...@us...> - 2003-01-12 11:56:24
|
Update of /cvsroot/srcpd/srcpd In directory sc8-pr-cvs1:/tmp/cvs-serv7823 Modified Files: config-srcpd.c config-srcpd.h m605x.c srcp-power.c Log Message: Powermanagement fuer 605x und neue conf-Option: auto_power_on fuer automatisches Einschalten eines Busses bei Programmstart Index: config-srcpd.c =================================================================== RCS file: /cvsroot/srcpd/srcpd/config-srcpd.c,v retrieving revision 1.41 retrieving revision 1.42 diff -C2 -d -r1.41 -r1.42 *** config-srcpd.c 9 Jan 2003 22:49:44 -0000 1.41 --- config-srcpd.c 12 Jan 2003 11:56:20 -0000 1.42 *************** *** 171,174 **** --- 171,180 ---- busses[busnumber].flags |= RESTORE_COM_SETTINGS; } + if (strcmp(child->name, "auto_power_on") == 0) + { + found = 1; + if (strcmp(txt, "yes") == 0) + busses[busnumber].flags |= AUTO_POWER_ON ; + } if (strcmp(child->name, "p_time") == 0) { *************** *** 255,263 **** /* need some more checks, may segfault! */ if (dbglevel <= busses[busnumber].debuglevel) { ! if (busses[busnumber].debuglevel>=DBG_DEBUG) { fprintf(stderr,"[bus %d] ",busnumber); vfprintf(stderr,fmt,parm); ! if (strchr(fmt,'\n'==NULL)) fprintf(stderr,"\n"); } else --- 261,269 ---- /* need some more checks, may segfault! */ if (dbglevel <= busses[busnumber].debuglevel) { ! if (busses[busnumber].debuglevel>DBG_WARN) { fprintf(stderr,"[bus %d] ",busnumber); vfprintf(stderr,fmt,parm); ! if (strchr(fmt,'\n')==NULL) fprintf(stderr,"\n"); } else Index: config-srcpd.h =================================================================== RCS file: /cvsroot/srcpd/srcpd/config-srcpd.h,v retrieving revision 1.16 retrieving revision 1.17 diff -C2 -d -r1.16 -r1.17 *** config-srcpd.h 5 Jan 2003 19:50:37 -0000 1.16 --- config-srcpd.h 12 Jan 2003 11:56:20 -0000 1.17 *************** *** 34,43 **** #define SERVER_I2C_DEV 8 // srcpd arbeitet als I2C-DEV-Server ! /* flags */ #define USE_WATCHDOG 0x0001 // use watchdog ! #define M6020_MODE 0x0002 // Subtyp zum M605X ! #define FB_ORDER_0 0x0010 // feedback port 0 is bit 0 ! #define FB_16_PORTS 0x0020 // feedback-modul has 16 ports ! #define RESTORE_COM_SETTINGS 0x0100 // restore com-port settings after close /* Busstruktur */ --- 34,47 ---- #define SERVER_I2C_DEV 8 // srcpd arbeitet als I2C-DEV-Server ! /* generic flags */ #define USE_WATCHDOG 0x0001 // use watchdog ! #define AUTO_POWER_ON 0x0002 // start Power on startup ! #define RESTORE_COM_SETTINGS 0x004 // restore com-port settings after close ! ! /* driver specific flags */ ! #define M6020_MODE 0x0100 // Subtyp zum M605X ! #define FB_ORDER_0 0x0110 // feedback port 0 is bit 0 ! #define FB_16_PORTS 0x0120 // feedback-modul has 16 ports ! /* Busstruktur */ Index: m605x.c =================================================================== RCS file: /cvsroot/srcpd/srcpd/m605x.c,v retrieving revision 1.35 retrieving revision 1.36 diff -C2 -d -r1.35 -r1.36 *** m605x.c 6 Jan 2003 20:16:24 -0000 1.35 --- m605x.c 12 Jan 2003 11:56:20 -0000 1.36 *************** *** 164,167 **** --- 164,168 ---- DBG(bus, DBG_INFO, "M605x init done, fd=%d", bus, busses[bus].fd); DBG(bus, DBG_INFO, "M605x: %s",busses[bus].description); + DBG(bus, DBG_INFO, "M605x flags: %d", busses[bus].flags & AUTO_POWER_ON); return 0; } *************** *** 197,201 **** ( (M6051_DATA *) busses[bus].driverdata) -> cmd32_pending = 0; } ! while (1) { --- 198,207 ---- ( (M6051_DATA *) busses[bus].driverdata) -> cmd32_pending = 0; } ! /* maybe, this little if() has to be elsewhere... */ ! if (( (busses[bus].flags & AUTO_POWER_ON) == AUTO_POWER_ON) ) { ! setPower(bus, 1, "AUTO POWER ON"); ! } else { ! setPower(bus, 0, "AUTO POWER OFF"); ! } while (1) { *************** *** 209,212 **** --- 215,223 ---- busses[bus].power_changed = 0; } + /* do nothing, if power off */ + if(busses[bus].power_state==0) { + usleep(1000); + continue; + } busses[bus].watchdog = 3; /* Lokdecoder */ *************** *** 240,244 **** writeByte(bus, &SendByte, pause_between_cmd); /* Erweiterte Funktionen des 6021 senden, manchmal */ ! if (( (busses[bus].flags & M6020_MODE) == 0) && (gltmp.funcs != glakt.funcs)) { c = (gltmp.funcs & 0x0f) + 64; --- 251,255 ---- writeByte(bus, &SendByte, pause_between_cmd); /* Erweiterte Funktionen des 6021 senden, manchmal */ ! if (( !(busses[bus].flags & M6020_MODE) == M6020_MODE) && (gltmp.funcs != glakt.funcs)) { c = (gltmp.funcs & 0x0f) + 64; Index: srcp-power.c =================================================================== RCS file: /cvsroot/srcpd/srcpd/srcp-power.c,v retrieving revision 1.11 retrieving revision 1.12 diff -C2 -d -r1.11 -r1.12 *** srcp-power.c 5 Jan 2003 16:10:39 -0000 1.11 --- srcp-power.c 12 Jan 2003 11:56:20 -0000 1.12 *************** *** 31,35 **** infoPower(int bus, char *msg) { ! sprintf(msg, "%d POWER %s %s", bus, busses[bus].power_state?"ON":"OFF", busses[bus].power_msg); return SRCP_INFO; } --- 31,35 ---- infoPower(int bus, char *msg) { ! sprintf(msg, "%d POWER %s %s\n", bus, busses[bus].power_state?"ON":"OFF", busses[bus].power_msg); return SRCP_INFO; } |
From: Manuel B. <web...@ma...> - 2003-01-11 18:08:40
|
Hi! Am Sam, 2003-01-11 um 18.39 schrieb Matthias Trute: > die cvs commit Messages sollten, wenn schon, an die srcpd-devel Liste > gehen. Keine zweite, andere (srcpd-cvs oder so). Praktikabel wär aber > der String CVS im Subject. CVS commits werden jetzt an srcpd-devel geschickt, das mit dem Subject müssen wir noch testen und ggf. syncmail anpassen... Ciao, Manuel -- web...@ma... http://www.matronix.de - http://www.e-online.de/public/borchers 7:06pm up 22:49, 5 users, load average: 0.34, 0.38, 0.45 |
From: Matthias T. <mt...@we...> - 2003-01-11 17:43:44
|
Manuel Borchers wrote: > Am Sam, 2003-01-11 um 11.43 schrieb Michael A. Meiszl: >=20 >>Warum schickst Du die commits nicht gleich auf die Hauptliste? >>Da sind eh nur Entwickler und eigentlich braucht jeder von denen die In= fo. >=20 >=20 > Na ja, ich dachte, dass dadurch vielleicht die normalen Diskussionen ei= n > wenig gest=F6rt werden... > Im Grunde ist es mir aber egal, mit Filterregeln im Mailer kann man die= > commits dann auch lokal noch trennen. Einfacher w=E4re es nat=FCrlich m= it > zwei getrennten Listen. >=20 > Wie steht der Rest dazu? die cvs commit Messages sollten, wenn schon, an die srcpd-devel Liste gehen. Keine zweite, andere (srcpd-cvs oder so). Praktikabel w=E4r aber der String CVS im Subject. >>Zwei Listen f=FCr Dev zu Null Listen f=FCr User ist etwas overdressed..= =2E >=20 >=20 > Das ist wahr... Wenigstens srcpd-main oder so f=FCr normale User sollte= n > wir schon noch einrichten... die kann dann srcpd-user hei=DFen. Aber die richte ich erst ein, wenn es Bedarf daf=FCr gibt. Im Moment sehe ich da keinen. Kann sich aber st=FCndlich =E4ndern ;=3D) Nebenbei bemerkt: Viel von dieser User-Kommunikation l=E4uft =FCber die DDL-Mailingliste, der Rest =FCber de.rec.modelle.bahn. Man sollte nicht z= u viel machen, dann verzettelt man sich nur. Und verwirrt die Anwender. > Ebenfalls w=E4re es vielleicht sinnvoll den Bug-Tracker auf der SF-Seit= e > zu aktivieren... Den wollte ich im Zuge der Fertigstellung vom srcpd-2 aktivieren. Momentan k=E4men IMHO zuviele Meldungen herein (vom SRCP sind vielleicht erst 30% implementiert), die allesamt bearbeitet werden m=FC=DFten, was oftmals l=E4nger dauert, als den Bug selbst zu fixen. (und zumindest ich habe keine Flatrate daheim, weswegen mir dies auch unn=FCtz Kosten verursachen w=FCrde.) Nicht das wir uns mi=DFverstehen, professionellerweise habe ich derartige= s Bugmanagement schon in sehr fr=FChen Entwicklungsstadien bei deutlich komplexeren Projekten einsetzen lassen. Mit Erfolg sogar. Matthias |
From: Manuel B. <web...@ma...> - 2003-01-11 11:07:34
|
Am Sam, 2003-01-11 um 11.43 schrieb Michael A. Meiszl: > Warum schickst Du die commits nicht gleich auf die Hauptliste? > Da sind eh nur Entwickler und eigentlich braucht jeder von denen die Info. Na ja, ich dachte, dass dadurch vielleicht die normalen Diskussionen ein wenig gestört werden... Im Grunde ist es mir aber egal, mit Filterregeln im Mailer kann man die commits dann auch lokal noch trennen. Einfacher wäre es natürlich mit zwei getrennten Listen. Wie steht der Rest dazu? > Zwei Listen für Dev zu Null Listen für User ist etwas overdressed... Das ist wahr... Wenigstens srcpd-main oder so für normale User sollten wir schon noch einrichten... Ebenfalls wäre es vielleicht sinnvoll den Bug-Tracker auf der SF-Seite zu aktivieren... Ciao, Manuel -- web...@ma... http://www.matronix.de - http://www.e-online.de/public/borchers 12:03pm up 15:45, 5 users, load average: 0.36, 0.15, 0.09 |