Ich bin mir nicht sicher, ob's eine on-fits-all Lösung dafür gibt. Aber wahrscheinlich irgendwas mit look-ahead. Ich bin auch schon eine Weile raus aus diesem Thema. So... ca... 12 Jahre.
Bevor du ein Programm schreibst, dass die Synchronisation von der DropBox an und ausschaltet, würde ich lieber im Post/Pre-Build in eine richtige Versionsverwaltung einchecken, dafür musst du nicht mal ein Programm schreiben, sondern einfach nur git mit den richtigen Parametern aufrufen.
Danke! Ich denke, das ist tatsächlich die gangbarste Lösung. Dann werden wirklich auch nur Dinge eingecheckt, die erfolgreich kompilieren und ich muss mich auf der Gegenseite nur ums Auschecken kümmern, was ja nicht so sehr Problem ist, wie das Einchecken. Warum bin ich da nicht selbst drauf gekommen? Egal... ich klopf das mal auf Usability ab.
MrSparkle, danke für den Hinweis. Ich dachte eigentlich, dass mit Hilfe des Videos die Frage eindeutig genug gestellt sei... was ist denn für dich nicht klar ersichtlich?
Ich kann keine Pixel in einer Bitmap malen. In einer anderen, die nicht im VS erzeugt ist, geht's.
Ergänzung (18:45): "Ich kann keine Pixel [...] malen" heißt hier: sie lassen sich im Visual Studio Bitmap Editor zwar malen, verschwinden aber sofort wieder, sobald ich die Maustaste loslasse. Es handelt sich um Visual Studio Professional 2012 (DEU).
Nein, keine Sourcecodeverwaltung im Sinne von git/svn/cvs, sondern lediglich Synchronisation. Ich nutze DropBox, weil es automatisch synchronisiert und ich mich nicht um Checkin/Checkout kümmern muss - ich bin vergesslich und mein Arbeitsweg ist zu lang, um vergessene Checkins/manuelle Syncs zu korrigieren.
Das Verfahren habe ich schon verwendet, allerdings musste ich die Erfahrung machen, dass ich manchmal vergesse, es wieder einzuschalten und dann am jeweils anderen Ende einen alten Stand habe... leider ungeeignet ob dieser persönlichen Charakterschwäche.
ich habe eine meiner Solutions in meiner DropBox liegen, damit ich sowohl von zuhause als auch aus dem Labor daran arbeiten kann. Das funktioniert weitestgehend problemlos, bis auf eine kleine nervige Kleinigkeit: immer mal wieder kommt es beim Kompilieren vor, dass sich DropBox und Visual Studio bezüglich der Zugriffsrechte auf die zu erstellenden bzw. zu synchronisierenden Dateien in die Haare kriegen. Zu merken ist das immer dann, wenn VS den Streit verliert und sich beschwert, dass es eine PDB oder eine DLL oder eine EXE nicht erzeugen kann, weil sie von einem anderen Prozess verwendet wird.
Hat da eventuell jemand eine Lösung oder einen Workaround parat, mit dem man möglichst genau so komfortabel, aber ohne die lästige Zankerei ("Ich will!" - "Nein ich!!!"... Kinder... tzzz) in der DropBox arbeiten kann?
Okay, mein Problem ist einerseits die Darstellung, also die Struktur des HTML Dokuments mittels dessen ich die Daten editierbar mache und andererseits die Rückgabe der geänderten Daten an das Backend.
Da will mir irgendwie nichts vernünftiges einfallen, wie man das am besten realisiert. Als ein Gesamtformular? Als ein Formular pro Unterknoten auf Ebene 1? Jeden Node in einem eigenen Formular?
Wie bekomme ich den Baum, der ja aus vielen Instanzen unterschiedlichster Klassen besteht, sauber an das Backend zurückgegeben?
a) ... bereits Daten existieren (als XML-Datei)
b) ... die Datenstruktur feststeht, bis auf eine Ausnahme: die Nodenamen der Ebenen 1 - 3 unterhalb des Root-Knotens
Ich hatte diese Datenstruktur schon in einem anderen Thread angesprochen wegen eines XML Schemas und ob es möglich ist, ein solches für eine solche etwas ungewöhnliche XML Struktur zu erstellen.
Die Daten, um die es geht, sind, für Browser mit einem XSLT versehen, dort einzusehen: http://bit.ly/XRgzxJ (verzeiht, dass ich einen Shortener nutze; ich möchte vermeiden, und hoffe es damit zu erreichen, dass die URL über Google gefunden werden kann).
Die grundsätzliche Struktur wird sich nicht mehr ändern. Was sich ändern kann, sind jedoch, wie angedeutet, die Node-Namen und Positionen auf den Ebenen 1 - 3 unterhalb des Root-Knotens. Die Anzahl von 3 Ebenen bleibt vorerst bestehen.
ich habe einen Haufen in einer Baumstruktur organisierte Daten (Objekte verschiedener Klassen). Diese Daten möchte ich gerne in ASP.NET zentral, also ales auf einer einzigen Seite, editierbar machen. Dazu zählt nicht nur, dass einzelne Attribute dieser Daten verändert werden können sollen, sondern auch weitere "Zweige" und "Blätter" zu dem Baum hinzugefügt, (rekursiv) gelöscht und (ebenfalls rekursiv) verschoben werden können sollen.
Hat da jemand eine zündenden Idee, wie man das am besten mit ASP.NET MVC 3 realisiert?
Für C# definitiv Unity3D. Nicht nur für Spiele geeignet; wir haben sie im letzten Jahr als KI-Engine für unseren Roboter verwendet (Wegfindungsroutine; leider auch ein Alleinstellungsmerkmal der Pro-Version).
ist es möglich, in einem XML Schema zu definieren, dass n Ebenen unterhalb des Rootnodes Nodes kommen, die keinen festen Namen, aber dennoch mindestens ein festes Attribut haben? Und ist es möglich, zu definieren, dass ab Ebenen unterhalb dieser n Ebenen mit unspezifiziertem Namen nur noch eine fest definierte Struktur folgen darf?
Folgender Hintergrund: ich definiere mir Adress-IDs mittels einer XML-Datei. Diese Adress-IDs bestehen aus drei Bytes. Ich verwende sie, um eine selbstentwickelte Hardware über UDP-Pakete zu steuern (die drei Adress-Bytes legen fest, welche Komponente ich anspreche). Sie sind in der XML Datei so definiert, dass ich sie per XPath direkt erreichen kann. Beispiel (rot = variabel/unspezifiziert; grün=fest/spezifiziert:
<IDTree>
<!-- Zwischen hier... -->
<Staubsauger id="0x00">
<Sensoren id="0x00">
<FilterFuellstand id="0x00" />
<DrehzahlVentilator id="0x01" />
</Sensoren>
<Aktoren id="0x01">
<DrehzahlVentilator id="0x00">
<!-- ... und hier in der Hierarchie sind die Node-Namen unspezifiziert -->
<!-- Unterhalb dieser Ebene sind die Node-Namen und die Hierarchie fest spezifiziert -->
<Description>
<ShortDesc>Setzt die Drehzahl und Richtung des Saugventilators</ShortDesc>
<Field type="int" bitLength="32" name="Drehzahl" />
<Field type="byte" bitLength="8" name="Drehrichtung">
<Value value="0x00" means="Ansaugen" />
<Value value="0x01" means="Ausblasen" />
</Field>
</Description>
</DrehzahlVentilator>
</Aktoren>
</Staubsauger>
</IDTree>
Somit kann ich eine Adress-Bytesequenz über /IDTree/Staubsauger/Sensoren/DrehzahlVentilator ansprechen und erhalte dadurch a) bessere Lesbarkeit, b) bessere und c) zentrale Wartbarkeit, wenn sich was an den IDs ändert. Da ich in einem Team an der Hardware arbeite, ist c) wichtig, weil Änderungen oder Erweiterungen an den Adressen natürlich für alle Bereiche des Projekts gelten sollen. Wildwuchs soll vermieden werden.
Fest spezifiziert sein sollen ausnahmslos alle Attribute, wie ich sie im Beispiel genannt habe. Das id-Attribut soll für die Adress-Zweige verpflichtend sein. Die anderen Attribute sollen teilweise optional (mit Standardwert) oder ebenfalls pflicht sein.
Unterhalb der Ebene, auf der sich beispielsweise FilterFuellstand oder DrehzahlVentilator befinden, lege ich, wie im Beispiel zu sehen, eine Dokumentationsstruktur ab. Sie ist fest definiert, beginnt mit einem Node mit spezifischem Namen "Description" und erhält darunter ein paar ebenfalls fest benamte Nodes mit definierter Hierarchie.
Nun ist die kurze und knackige Frage: ist es möglich, diese Vorgaben in ein XML Schema zu gießen?
Und wenn das alles sauber umgesetzt ist dann sollte das auch keine Hirnvermusung sein.
Und genau das ist das Problem... Die Anwendung ist über Jahre gewachsen, nein, lass es mich "gewuchert" nennen. Da ist leider nichts mehr sauber drin umgesetzt. Aber um von vorn anzufangen und all die Erfahrungen, die ich im Laufe der Zeit gemacht habe, sauber in einer neuen Software zu verpacken, fehlt leider auch die Zeit. ****** Deadline.
Okay, das mit den WaitHandles funktioniert. Ist allerdings gewaltige Hirnvermusung. Parallel in Threads zu denken, macht keinen Spaß. Gibt es da Methoden, die das Mitdenken bei Multithreading-Anwendungen vereinfachen, den Kopfcompiler verbessern?
ich habe hier ein Problem, das mir das Gehirn ein wenig vermust... folgendes:
in einer Anwendung wird ein IronPython-Script ausgeführt, das sequenziell bestimmte Methoden einer C#-Klasse abarbeitet. Diese Methoden laufen im IronPython-Thread synchron, blockieren also die Ausführung des IronPython-Scripts, sodass jede Methode wirklich erst dann aufgerufen wird, wenn die vorherige beendet ist.
Intern laufen diese Methoden hingegen asynchron. Sie führen in einem eigenen Thread ein Kommando auf einer Hardware aus und der Thread wartet dann auf ein von der Hardware ausgelöstes Complete-Ereignis. Dieses Ereignis lässt die Methode dann letztlich auch im IronPython-Script zurückkehren und selbiges die nächste Methode starten. Das funktioniert bis jetzt ganz brauchbar, auch wenn ich da noch auf die echten Thread-Sync Mechanismen verzichte und an deren Stelle quick'n'dirty zyklisch eine volatile bool'sche Variable abfrage. Beziehungsweise derer zwei, weil die Methoden eigentlich immer darauf warten müssen, dass genau zwei Geräte "Complete" zurückmelden.
Darüber hinaus möchte ich nun aber eine Möglichkeit einbauen, die Ausführung der einzelnen Methoden aus einem anderen Thread heraus zu pausieren. Das heißt, es soll nicht mehr nur auf die "Complete"-Ereignisse der Hardware gewartet werden, sondern zusätzlich und nur sofern von außen angefordert noch auf ein "Vorgang-Fortsetzen"-Ereignis.
Wie ist bei so etwas der Königsweg, um das zu erreichen? Welche Mechanismen zur Threadsynchronisierung nutzt man dabei am besten?
Vielen Dank!
Cheers,
Hendrik
//edit: by the way: ich nutze async/await und Task
... oder den Compiler/die Sprache entsprechend erweitern, dass die Zahl der Parameter explizit angegeben werden kann und nach oben praktisch keine Grenze hat.
Ich stimme da Herbivore zu. Besser haben als brauchen.
Hmm... könnte sowas sein wie die Artefakte bei Games, die auftreten, wenn man VSync deaktiviert hat und schnelle Bewegungen ausführt... ist aber nur eine sehr unbegründete Vermutung.
kann man die selbe Instanz eines UdpClient nutzen, um sowohl einerseits Broadcast Pakete zu empfangen und andererseits Pakete an eine spezifische Adresse zu versenden? Oder macht das Probleme?
Okay. Hab ich das korrekt verstanden, ich sollte das derzeit quasi "event"-basierte Lesen in einen Thread auslagern, der zyklisch pollt und neue Daten in eine Queue<byte[]> packt?
Die Queue<byte[]> habe ich schon, nur dass derzeit noch mittels BeginReceive/EndReceive die Datenpakete dort hineingelegt werden. Ich werde mal ausprobieren, sofern ich deinen Vorschlag richtig interpretiert habe, inwiefern Polling an dem Verhalten etwas ändert.
Bei der Gegenstelle handelt es sich zwar derzeit noch um ein C# Programm, das unter Mono auf einem RaspberryPi läuft. Jedoch wird es mittelfristig durch ein anderes ARM Cortex Board auf Basis des STM32 ersetzt, das die UDP Pakete quasi "direkt" generiert, ohne den Overhead eines CLR-Prozesses auf einem richtigen Betriebssystem. Die darauf laufende Firmware übernimmt das Verpacken direkt. Performanceprobleme sollten auf der Seite also schon bald keine Rolle mehr spielen.
Ich werde die oben erwähnt Queue<byte[]> nun, der Threadsicherheit wegen, durch eine ConcurrentQueue<byte[]> ersetzen. Bisher habe ich aber auch mit der normalen Queue keine Probleme.
Ich habe eine Steuersoftware für einen autonomen Roboter geschrieben, die mit der Roboterhardware inzwischen über UDP (vorher direkt per UART, dort kam mir ein ganz ähnliches Verhalten unter) kommuniziert. Die Firmware auf der Bridge zwischen dem CAN-Bus und dem Steuerrechner verpackt CAN-Nachrichten in ein UDP Paket und verschickt dieses an die Broadcast-Adresse des Subnetzes. Meine Software empfängt diese Pakete, wertet sie aus und verschickt ihrerseits Kommandos an die Bridge.
Die Fahr- und Drehgeschwindigkeit des Roboters ist per Regelkreis geregelt. Die Regler (P/PI/PD/PID, je nach Anwendungsfall) können während einer Regelabweichung durchaus mal bis zu 1000 UDP Pakete (Kommandos für die zwei Fahrmotoren mit Geschwindigkeit und Drehrichtung) pro Sekunde rausfeuern, die alle so ca. 20 - 30 Byte Payload haben. Damit soll möglichst verzögerungsfrei (Totzeiten sind der Tod jeder Regelung) geregelt werden können.
Als Erleichterung habe ich meiner Steuersoftware gesagt, sie soll Pakete wirklich nur noch dann rausschicken, wenn sich die Payload gegenüber dem letzten gesendeten Paket verändert hat, also keine Kommandos mehrfach. Das bewirkt schonmal eine gewisse Entlastung.
Wir nutzen UDP Broadcast, damit zur selben Zeit nicht nur der Steuer-PC im Roboter selbst, sondern auch beliebig viele Entwicklersysteme mit dem Roboter kommunizieren und die Sensordaten und Kommandos mitschneiden können. Bei UART vorher war immer nur ein Gerät zur Zeit anschließbar.
Und, bevor ihr fragt, ja, die Steuersoftware ist in C# geschrieben, der Steuer-PC läuft auf Windows 7 und es funktioniert bis auf ein paar Krücken. Sogar performant und nahezu totzeitfrei. Hätte ich auch nicht gedacht. Ist alles ein bisschen mit Kanonen auf Spatzen geschossen, aber der Effekt auf interessierte Zuschauer ist enorm beeindruckend, wenn sie die Steuersoftware in Kombination mit der auf Unity3D basierenden K.I. in Aktion sehen. :)
kann es sein, dass sich zwei UdpClients in die Quere kommen, wenn der eine per BeginReceive/EndReceive-Schleife auf Broadcast Pakete horcht und der andere plötzlich anfängt, auf die Adresse eines Broadcastsenders in schneller Folge Pakete abzufeuern?
Der BC-Versender schickt unentwegt UDP Pakete an die Broadcast-Adresse. Er horcht aber auch auf einem anderen Port auf eingehende UDP Pakete.
Es erscheint mir, dass der BC-Empfänger-UdpClient auf einmal mit Empfangen aufhört, solange der Sender-UdpClient seine Pakete rauspumpt. Erst wenn der Sender-UdpClient mit dem Flooden aufhört, reagiert der BC-Empfänger-UdpClient wieder...
Wireshark sagt mir, dass der BC-Versender auch noch sendet, während er den Flood empfängt und auch verarbeitet. Aber im BC-Empfängerprozess kommt halt während er flutet nix an, obwohl der UdpClient definitiv in einem BeginReceive steht.