cfranz

OK, hier das erstaunliche resultat: Brickv 1.1.16 startet NICHT (CoreText fehler) Brickv 1.1.17 funktioniert gut (danke für link!) -ch

ich teste gerne 16 und 17 -- haste schnell einen link (bin *sehr* faul) -ch

frohes neues jahr, tinkers! habe eben mein brickv von 1.1.13 auf 1.1.18 (vom 27.12. letzten jahres) upgraded - mit dem resultat, dass Brickv nicht mehr läuft. Soweit ich weiss ist das Framework CoreText erst ab 10.8 (Mountain Lion) in /System/Library/Frameworks/ verfügbar. Das Problem mit den scripting additions verstehe ich nicht, da ich ich nie Python verwendet habe. Hier die relevanten 'consolations': 02/01/2013 16:43:49 [0x0-0x25025].com.tinkerforge.brickv[333] Traceback (most recent call last): 02/01/2013 16:43:49 [0x0-0x25025].com.tinkerforge.brickv[333] File "/Applications/Brickv.app/Contents/Resources/__boot__.py", line 340, in <module> 02/01/2013 16:43:49 [0x0-0x25025].com.tinkerforge.brickv[333] _run('main.py') 02/01/2013 16:43:49 [0x0-0x25025].com.tinkerforge.brickv[333] File "/Applications/Brickv.app/Contents/Resources/__boot__.py", line 337, in _run 02/01/2013 16:43:49 [0x0-0x25025].com.tinkerforge.brickv[333] execfile(path, globals(), globals()) 02/01/2013 16:43:49 [0x0-0x25025].com.tinkerforge.brickv[333] File "/Applications/Brickv.app/Contents/Resources/main.py", line 37, in <module> 02/01/2013 16:43:49 [0x0-0x25025].com.tinkerforge.brickv[333] from PyQt4.QtGui import QApplication 02/01/2013 16:43:49 [0x0-0x25025].com.tinkerforge.brickv[333] File "PyQt4/QtGui.pyc", line 18, in <module> 02/01/2013 16:43:49 [0x0-0x25025].com.tinkerforge.brickv[333] File "PyQt4/QtGui.pyc", line 11, in __load 02/01/2013 16:43:49 [0x0-0x25025].com.tinkerforge.brickv[333] ImportError: dlopen(/Applications/Brickv.app/Contents/Resources/lib/python2.6/lib-dynload/PyQt4/QtGui.so, 2): Library not loaded: /System/Library/Frameworks/CoreText.framework/Versions/A/CoreText 02/01/2013 16:43:49 [0x0-0x25025].com.tinkerforge.brickv[333] Referenced from: /Applications/Brickv.app/Contents/MacOS/../Frameworks/libQtGui.4.dylib 02/01/2013 16:43:49 [0x0-0x25025].com.tinkerforge.brickv[333] Reason: image not found 02/01/2013 16:43:49 main[333] Brickv Error 02/01/2013 16:43:51 osascript[345] Error loading /Library/ScriptingAdditions/QXPScriptingAdditions.osax/Contents/MacOS/QXPScriptingAdditions: dlopen(/Library/ScriptingAdditions/QXPScriptingAdditions.osax/Contents/MacOS/QXPScriptingAdditions, 262): no suitable image found. Did find: /Library/ScriptingAdditions/QXPScriptingAdditions.osax/Contents/MacOS/QXPScriptingAdditions: mach-o, but wrong architecture 02/01/2013 16:44:00 com.apple.launchd.peruser.501[242] ([0x0-0x25025].com.tinkerforge.brickv[333]) Exited with exit code: 255 Werde nun zu 1.1.13 reverten -- habt ihr ein paar schnelle tipps, was ich sonst machen sollte? Was ist die minimale OS version für Brickv? Habe nix auf der download page gefunden (aber ehrlichgesagt auch nicht lange gesucht). -ch

(English summary: another short example app, this one shows how I subclassed TDLCD20x4 to create an LCD display that shows a short message with animated 'snow flakes' - using asterisks '*'. Zip also contains Cocoa Layer ) Ein weiteres Cocoa Layer Beispiel, in dem ich das TDLCD20x4 erweitert habe zu einem Display, welches eine Nachricht in einem 'Schneesturm' aus Sternchen '*' zeigt. Das 'wirkliche' Programm sind nur ~20 Zeilen, der Rest der 108KB ist eine neue Version des Layers: erweitert um eine winzige Funktion für die TDLCD Klasse. Gruss -ch snowy.zip

Please see here: http://www.tinkerunity.org/forum/index.php/topic,1192.0.html -ch

[english summary: this post contains the first partly-complete cocoa layer for TF bricks/bricklets. Not all bricklets are currently supported. Please read the enclosed documentation and feedback here] Dieser Post ist nur interessant für iOS/OSX Tinkerer! Da ich in meinem 'echten Leben' für iOS und OSX programmiere, habe ich mir einen Cocoa Layer für meine TF bricklets gechrieben, den ich gerne jedem interessierten zugänglich mache. Der Cocoa-Layer sitzt auf den normalen C/C++ Bindings (die musst du also auch herunterladen) und macht das Arbeiten mit den TF bricklets *sehr* viel einfacher. Der Cocoa Layer ist sehr viel mehr als bloss ein Wrapper - er ist hierarchisch, baut auf NSObject auf und enthält eine Reihe von (für mich) wichtigen Vereinfachungen: - Alle TF bricks sind nun NSObject descendants - Relays und IO-Bricks können in IOArrays oder RelayArrays zu grossen virtuellen superbricklets zusammengefasst werden - Die LCD-Klasse kann mit writeLn und NSStrings arbeiten - Die TinkerIO (IPconnection) Klasse ist auf Plug&Play via delegates vorbereitet (noch nicht umgesetzt) Die beiden Attachments sind - der Cocoa Layer (source und extensive dokumentation in Englisch) - ein demo-programm, welches mit einem LCD und Distance IR arbeitet Momentan sind nur die bricklets umgesetzt, die ich selber besitze: Dual Relay, IO4, LCD 20x4, Ambient Light, Distance IR, Dreh-poti Feedback, Erfahrungen, Anregungen, Kommentare bitte in diesem Thread, bis die freundlichen TinkerForger eine Ecke für handgestrickte Bindings/Layer bereitstellen. Viel Spass, -ch Tinkerforge_Cocoa_Layer.zip starter_demo_dist_and_lcd.zip

Klasse! ... wenn ich schon dabei bin: der Cocoa-Layer sollte transparent diese callbacks verwalten, weshalb ich auf das Problem gestossen bin. Ich selber habe es nicht ausprobiert (das Bricklet ist noch auf dem Weg zu mir), aber kann ich momentan (oder unter API 2.0) *zwei* oder mehr unterschiedliche callbacks für das gleiche bricklet aktiv haben. Z.B. für den Entfernungsmesser einen, der feuert, wenn die Distanz < 100 mm und einen anderen, wenn die distanz > 700mm? Ich frage nur, weil für eine generelle Verwaltung dieser callbacks im Cocoa Layer dann ein 'unregister' eine gute Idee wäre. Gruss, -ch

Es ist immer blöd auf seinen eigenen Post zu antworten, sorry. Was ich eigentlich anregen möchte: In einer neuen, späteren Version der APIs für alle Bricklets/Bricks sollte einer generelle Erweiterung aller callbacks um (void *) oder UID aufgenommen werden. -ch

Ich bin gerade dabei, einen Cocoa-Layer zu schreiben, der auf den normalen Interfaces sitzt und die Verwendung der Bricks noch bequemer machen soll. So ist es z.b relativ einfach mit dem Layer so etwas zu machen: // theConnection ist ein cocoa-objekt, welches IPconnection kapselt NSArray *alleBricklets = [theConnection getAll]; // alle momentan angeschlossene bricklets TinkerDevice *aDevice for (aDevice in alleBricklets) { if ([[aDevice deviceName] containsString:@"Relay"]) { // mach etwas mit dem relay, egal ob dual, quad oder indu } } So weit, so gut. Allerdings laufe ich bei allen callbacks in das gleiche Problem. Solange die Stacks klein sind, ist dieses Problem irrelevant, oder kann spezifisch gelöst werden. Bei grösseren stacks oder komplexeren Programmen wäre es gut, wenn den callbacks noch ein (void *) mitgegeben werden kann, der zur Interrupt/Callback-zeit zurückgegeben wird. der callback sieht also immer so (ähnlich) aus: void cb_Whatevah (..., void *data) {} und der register call void device_register_callback( ..., void *callback, void *data) Auf diese Art kann der Interrupt/Callback-handler Zugriff erhalten auf den Speicherbereich, der mit diesem Callback assoziiert ist. In dem fall von cocoa ist es natürlich das Objekt, das diesen callback angefordert hat. Warum das Ganze? Im Prinzip brauche ich eine Möglichkeit, während eines callbacks herauszufinden, welches Bricklet (wenn mehr als eines vom gleichen Typ verwendet werden) den callback auslöst, um dann das richtige Objekt zuzuordnen. Es würde also auch ausreichen, wenn während des Callbacks die UID des Bricklets verfügbar ist, das den Interrupt ausgelöst hat. Die (void *) Variante ist etwas genereller verwendbar. Ich bin sicher, dass ich ich die Sources für meine Bedürfnisse entsprechend ändern kann. Das Problem ist dann, dass der Cocoa Layer nicht mehr mit den 'echten' TF sources kompatibel ist. Und das gibt dann ein ziehmliches Gewürge für jeden, der den Layer verwenden will (grosskotzig setze ich mal voraus, dass es jemanden ausser mir gibt, der an sowas überhaupt Interesse hat ) Oder habe ich etwas elementares übersehen und das gibt es schon längst? -ch

> Fuer so eine Anwort gibt es eigentlich nur 2 Erklaerungen [...] Na ja. Das nächste Mal, wenn Du nichts zur Beantwortung der ursprünglichen Frage beitragen willst, sondern statt dessen stark persönlichkeitsgefärbte, eher unpassende Vergleiche feilbietest, dann wundere Dich nicht, wenn ich deinen Beitrag als unreif abtue. Es geht in meinem Post um alles *ausser* Dich oder Dein Kommentar. Welches Wort in "Lötkolben's Kommentar mal beiseite gelassen" hast Du nicht verstanden? Was ich definitiv nicht will, ist hier eine sinnlose Diskussion darüber abhalten ob Apple / MS / Google / Debian / RedHat / Ultrix / IBM / Oracle / Kaufhof / Undwersonstnoch das Neue Böse ist. Ich bin hier, um mit den Produkten von TinkerForge etwas zu bauen, Hilfe zu suchen und, wenn jemand eine Frage hat, zu versuchen, der Person so gut ich kann zu helfen. Allerdings: wer in einem Thread über iOS nichts besseres zu tun hat, als die Nutzer des OS pauschal als Sektenanhänger abzuurteilen, sucht Streit. Für Flamewars gehst du aber besser aufs Usenet in comp.sys.religious-wars - da kannst Du es Dir mit echten Profis geben. Die reagieren dann auch auch auf Vorwürfe des Realitätsverlustes. -ch

Lötkolben's etwas infantiler Kommentar mal beiseite gelassen, stimmt es im Grossen und Ganzen, dass Du ein Entwickler-Account für $99 lösen musst, bevor du (ohne Jailbreak) Deine App aufs iPad laden kannst. Früher (vor iOS 4, wenn ich mich recht erinnere), war es möglich, von XCode aus direkt Apps auf iPod und iPhone zu laden, ohne es vorher via Apple zu 'Provisionieren'. Wie Armin schon kommentiert hat, kannst Du auch ohne Developerlizenz vorher in XCode mit dem Simulator viel testen. Ich habe es selber noch nicht ausprobiert, aber wenn dein Mac WiFi hat, solltest Du auch vom Simulator aus Zugriff auf den Brick bekommen. Also, wenn du was auf dein iPad laden willst und Bricks steuern willst, brauchst du: 1. Einen Mac zum Entwickeln (geht nicht mit Linux oder Win, aber ein FrankenMac tut es auch) 2. ein iPad 3. eine $99 (pro Jahr) teure Lizenz von Apple 4. XCode (gratisdownload) 5. Einen WiFi-brick (Persönliche Anmerkung: auch wenn die $99 weh tun und m.E. absolut unnötig sind - aber um die $99 rumzunölen bei der Rechnung für den Rest - Mac, iPad, WiFi-Brick - ist kleinlich. Berechtigt, aber kleinlich. Du kannst versuchen, die Lizenzkosten wieder rauszuholen, indem du die zwei Developer Incidents ausnutzt, die Du damit 'gratis' bekommst: zwei code-level Fragen beantworten Dir da Apple-Angestellte. Ich habe ein paar davon in Anspruch genommen, als ich absolut nicht weiter wusste und kann sagen, dass die wirklich was drauf haben) Sobald Du die Lizenz bezahlt hast, gehst Du auf Apple's Developer seiten zum Provisioning Portal, registrierst dein Gerät und beziehst ein Developer Certificate. Wenn Du es an den Mac anschliesst und XCode startest, sollte XCode dann das iPad erkennen und signierte Apps direkt draufladen und ausführen können. Da Du dann eine Entwicklerlizenz hast, kannst Du dann auch versuchen, sie gleich im AppStore der Welt zur Verfügung zu stellen / zu verticken (allerdings musst Du dann erst am App Review vorbei). -ch

Bevor ich das Rad neu erfinde, schnell eine Frage an die Community: Hat irgendjemand die C Bindings bereits auf Cocoa/ObjC übersetzt? Insbesondere ein Wechsel von PThreads auf NSOperation, Verwendung von CFNetwork und eine gemeiname Inheritance der TDevice und TIPConnection von NSObject wären mir ein Anliegen. Der Aufwand dafür ist allerings alles andere als elementar - und ich bin faul. Also, hat da schon jemand etwas gemacht, was er/sie bereit wäre zu teilen? Danke und Gruss aus der Schweiz, -ch