Lukas K. schrieb:> Coole sache! Wäre es arg viel Mehraufwand auch Fragen aus dem #horizon> IRC-Channel auf freenode anzunehmen?
Gute Idee! Ich kann mal versuchen ein Auge parallel auf den IRC zu
werfen und auch dort Fragen zu klären. Dann muss ich nicht unnötiger
Weise Menschen in den Walled Garden "Twitch" locken.
Danke an alle Zuseher! Hab mich sehr gefreut, dass ich nicht alleine im
Stream war. Hat Spaß gemacht :)
Martin S. schrieb:> Scheint ja doch geklappt zu haben mit der Aufzeichnung. Schöne Sache.> Dann hab ich mal wieder was nettes auf meiner Watch-List.
Jup. Für zwei Wochen hier nachzusehen:
https://www.twitch.tv/videos/919019498
Ich bin heute schon gut vorangekommen. Ich werde dann voraussichtlich
nächsten Mittwoch für den Rest am streamen sein.
VG Jue
Jürgen F. schrieb:> Für zwei Wochen hier nachzusehen:
Wer sich's aufheben will: youtube-dl kann das auch runterladen.
Sind aber wohl um die 6 GiB, meint es …
Jürgen F. schrieb:> Danke an alle Zuseher! Hab mich sehr gefreut, dass ich nicht alleine im> Stream war. Hat Spaß gemacht :)
Danke für den Stream, war mal schön zu sehen, dass viele den
implementieren Ideen auch trotz der eher spärlichen Dokumentation
verständlich sind.
Im Stream sind mir einige Dinge aufgefallen, die inzwischen behoben
sind:
- Reichelt und Conrad zählen nun zu den unerwünschten
Datenblatt-Domains
- Beim Platzieren eines Bauteils im Board wird es auch korrekt im
Schaltplan highlighted
- Wenn man die Anzahl an Innenlagen erhöht, bekommen die in der
Layer-box links auch gleich die richtige Farbe
- Beim mergen von Parts werden auch Symbole mit vorausgewählt
Jürgen F. schrieb:> Danke an alle Zuseher! Hab mich sehr gefreut, dass ich nicht> alleine im> Stream war. Hat Spaß gemacht :)>> Martin S. schrieb:>> Scheint ja doch geklappt zu haben mit der Aufzeichnung. Schöne Sache.>> Dann hab ich mal wieder was nettes auf meiner Watch-List.>> Jup. Für zwei Wochen hier nachzusehen:> https://www.twitch.tv/videos/919019498>> Ich bin heute schon gut vorangekommen. Ich werde dann voraussichtlich> nächsten Mittwoch für den Rest am streamen sein.>> VG Jue
Hab gerade ein bisschen in den Stream reingesehen - echt sehr
interessant und lehrreich. Vielen Dank für die Mühe!
Rein aus Interesse: Gibt's eigentlich nen Grund, warum du auf Twitch und
nicht auf Youtube streamst? Ich muss gestehen, dass ich Twitch jetzt
nicht so auf dem Radar hatte und ich bisher auch nicht wusste, dass das
auch Leute aus der Maker Szene nutzen.
Was ich ein bisschen schade finde ist, dass die Videos anscheinend auf
Twitch nur für 2 Wochen verfügbar sind. Hast du vor, die Videos evt.
auch auf YT hochzuladen? Wäre sehr schade, wenn das Video hier nach 2
Wochen wieder verschwindet.
Was auch immer "MSAA" heißen mag :-) (YAA - yet another acronym), es
scheint mit dem Antialiasing zu tun zu haben. Nachdem ich die
Einstellungen sowohl für Schematic als auch Board auf "MSAA 1x" geändert
habe, taucht die Warnung nicht mehr auf.
Danke fürs Zuhören. :-)
Edit: beim 3D-Viewer taucht es immer noch auf. Dafür finde ich irgendwie
keine Einstellmöglichkeit.
Jörg W. schrieb:> Edit: beim 3D-Viewer taucht es immer noch auf. Dafür finde ich irgendwie> keine Einstellmöglichkeit.
In der 3D-Ansicht ist das im Settings-Overlay (Knopf ist oben links) zu
finden.
Was hast du für eine GPU, die kein MSAA kann?
Lukas K. schrieb:> In der 3D-Ansicht ist das im Settings-Overlay (Knopf ist oben links) zu> finden.
OK.
> Was hast du für eine GPU, die kein MSAA kann?
Gute Frage, irgendeine Radeon. Vielleicht ist da auch was
fehlkonfiguriert?
Bisschen seltsam im Xorg log:
1
[ 147.933] (==) Automatically adding devices
2
[ 147.933] (==) Automatically enabling devices
3
[ 147.933] (==) Not automatically adding GPU devices
Dafür wiederum geht 3D trotzdem verdammt gut …
pciconf sagt:
Bernhard B. schrieb:> Hab gerade ein bisschen in den Stream reingesehen - echt sehr> interessant und lehrreich. Vielen Dank für die Mühe!
Schön, dass es dir etwas bringt :)
> Rein aus Interesse: Gibt's eigentlich nen Grund, warum du auf Twitch und> nicht auf Youtube streamst? Ich muss gestehen, dass ich Twitch jetzt> nicht so auf dem Radar hatte und ich bisher auch nicht wusste, dass das> auch Leute aus der Maker Szene nutzen.
Ich schaue tatsächlich gerne den ganzen Maker-Kanälen auf Twitch zu. So
war das für mich der logische Schluss auch dort zu streamen. Aber nichts
ist in Stein gemeißelt. Ich bin noch sehr viel am Lernen und
Ausprobieren.
> Was ich ein bisschen schade finde ist, dass die Videos anscheinend auf> Twitch nur für 2 Wochen verfügbar sind. Hast du vor, die Videos evt.> auch auf YT hochzuladen? Wäre sehr schade, wenn das Video hier nach 2> Wochen wieder verschwindet.
Ich werde das Video etwas zusammendampfen - also Gestammel
rausschneiden, Redepausen rausschneiden. Ich glaube die Form ist für die
Nachwelt interessanter als der vollständige Stream ;) Das Ergebnis lade
ich dann auf YT hoch.
VG Jue
Bin nun inzwischen ein gutes Stück durch dein Filmchen durch und habe
versucht, das Ganze hier mal mit einem leicht anders gearteten Relais
(Reed-Relais in SIL-Gehäuse) nachzuvollziehen.
Worüber ich am ende stolpere ist eine Verifikationswarnung "Pin x has
improper orientation".
Interessanterweise bekomme ich diese nicht für das zuvor angelegte
einfache Relais-Symbol, sondern nur für das hier mit der integrierten
Freilaufdiode. Dafür habe ich das vorige Symbol dupliziert und die Box
etwas vergrößert.
Was will mir diese Warnung sagen?
Jörg W. schrieb:> Was will mir diese Warnung sagen?
Ich vermute mal, dass dein Symbol nicht horizontal zentriert ist. Die
helle Box im Hintergrund ist die um den Ursprung zentrierte bounding
box, auf der alle Pins liegen sollten. Bei dir kommen die Pins rechts
auf der oberen/unteren Kante zu liegen und sollten daher nach dem
Symbol-Regeln nach oben/unten zeigen.
Gtk im Motif-fensterrahmen ist ja auch eine sehr interessante
Kombination ;) Eigentlich sollte bei dem Rules-Fenster da Gtk deinen
Fenstermanager davon überzeugen, dass dieses Fenster keinen Rahmen
braucht, weil ja Gtk den schon malt. Was ist eigentlich mit den
schließen-icons schief gelaufen? Die sehen ein wenig verunglückt aus.
Lukas K. schrieb:> Jörg W. schrieb:>> Was will mir diese Warnung sagen?>> Ich vermute mal, dass dein Symbol nicht horizontal zentriert ist. Die> helle Box im Hintergrund ist die um den Ursprung zentrierte bounding> box, auf der alle Pins liegen sollten.
Ah OK. Das erklärt es: ich hatte die Box nach links vergrößert, um Platz
für die Freilaufdiode zu bekommen. Da hätte ich sie auch nach rechts
vergrößern müssen.
Habe ich nun getan, jetzt ist das alles OK.
Ich fände es gut, wenn es dafür irgendwo bei den Fehlermeldungen eine
Hilfe gäbe, die ein paar Details erklärt. Mir ist ohnehin gerade nicht
ganz klar, wo diese Rules denn genau stehen (ansonsten hätte ich dort
mal nachgeschaut, was sie genau besagen).
> Gtk im Motif-fensterrahmen ist ja auch eine sehr interessante> Kombination ;)
Ich bin seit mehr als 25 Jahren halt fvwm-Nutzer. Damals war Motif-Look
das, dem sie alle nachgeeifert hatten, und fvwm hatte das ganz gut hin
bekommen.
Irgendwie hat dieser Windowmanager schlicht alles, was ich brauche, und
ich habe mich gut dran gewöhnt. Hatte auf meinem neuen Dienst-Laptop
(auf dem Unbuntu läuft, anders als mein handgestricktes FreeBSD hier)
mal eine Weile lang Mate als Desktop laufen, aber irgendwie bin ich auch
dort dann zu fvwm zurück.
> Eigentlich sollte bei dem Rules-Fenster da Gtk deinen> Fenstermanager davon überzeugen, dass dieses Fenster keinen Rahmen> braucht, weil ja Gtk den schon malt.
Wobei das eben eigentlich dem Sinn von X11 nicht entspricht: Dekoration
war schon immer Aufgabe des Windowmanagers. Der bestimmt damit auch das
look&feel.
> Was ist eigentlich mit den> schließen-icons schief gelaufen? Die sehen ein wenig verunglückt aus.
Nicht nur die, alle Gtk-Icons. Ich bin mir nicht ganz sicher, ob das nur
ein verunglückter Gtk-Build ist, oder ob das mit den weiter oben ja
schon festgestellten Problemen zusammenhängt, dass der X-Server beim
Start die Grafikkarte nicht erkannt hatte. Bin noch nicht dazu gekommen,
mich mal auszuloggen und den X-Server neu zu starten. Ist so lästig,
sind so viele Dinge offen, die man danach dann wieder neu zusammen
suchen müsste. ;-) Da diese verhunzten Icons ein reiner Schönheitsfehler
sind, ist mir das auch nicht allzu wichtig. (Der Radeon-Treiber im
X-Server wäre mir schon wichtiger, aber irgendwas spinnt auch an einem
SATA-Kabel, ich würde dann wohl die Kiste gleich mal komplett booten
wollen.)
Jörg W. schrieb:>> Was ist eigentlich mit den>> schließen-icons schief gelaufen? Die sehen ein wenig verunglückt aus.>> Nicht nur die, alle Gtk-Icons. Ich bin mir nicht ganz sicher, ob das nur> ein verunglückter Gtk-Build ist, oder ob das mit den weiter oben ja> schon festgestellten Problemen zusammenhängt, dass der X-Server beim> Start die Grafikkarte nicht erkannt hatte.
Nö, auch nach dem Neustart sind die noch verhunzt.
Anyway, wollte nun einen Pull Request für mein hübsches SIL-Relais
machen, aber:
Assertion failed: (buf && sig), function git_signature__writebuf, file /usr/ports/devel/libgit2/work/libgit2-1.0.1/src/signature.c, line 305.
17
18
[1] Abort horizon-eda (core dumped)
Core-File liegt noch rum, falls du denkst, dass man dem noch was
entnehmen kann.
Coredump ist reproduzierbar. Ich kann den pull request natürlich noch
mit der Hand erzeugen auf Github.
Jörg W. schrieb:>> Was hast du für eine GPU, die kein MSAA kann?>> Gute Frage, irgendeine Radeon.
Selbst mit passendem Treiber macht sie aber nur MSAA 1x.
Jörg W. schrieb:> Core-File liegt noch rum, falls du denkst, dass man dem noch was> entnehmen kann.
Ein Backtrace wäre ganz nützlich.
So ins blaue hineingeraten, guck mal ob in
https://github.com/horizon-eda/horizon/blob/master/src/pool-prj-mgr/pool-mgr/pool_remote_box.cpp#L1241
signature nicht vielleicht ein nullpointer ist. Allerdings sehe ich
gerade nicht so recht, wie das auftreten könnte, da in dem Dialog davor
eigentlich vom remote-repo user.name und user.email gesetzt werden. Wäre
vielleicht doch besser gewesen, den return-code von
git_signature_default zu überprüfen.
Tja, jetzt habe ich es aus dem Buildverzeichnis unter GDB-Steuerung
laufen lassen, und alles rennt durch. :-/ Hmm, damit hast du jetzt
meinen ersten Pool-Pullrequest. :-)
Hier ist der Stacktrace aus dem Coredump:
1
Core was generated by `horizon-eda'.
2
Program terminated with signal SIGABRT, Aborted.
3
4
warning: Unexpected size of section `.reg-xstate/102284' in core file.
5
#0 thr_kill () at thr_kill.S:3
6
3 RSYSCALL(thr_kill)
7
[Current thread is 1 (LWP 102284)]
8
(gdb) bt
9
#0 thr_kill () at thr_kill.S:3
10
#1 0x0000000803b4b094 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52
11
#2 0x0000000803ac1289 in abort () at /usr/src/lib/libc/stdlib/abort.c:67
12
#3 0x0000000803b3b2a1 in __assert (func=<optimized out>, file=<optimized out>, line=<optimized out>, failedexpr=<optimized out>) at /usr/src/lib/libc/gen/assert.c:51
13
#4 0x0000000803851106 in () at /usr/local/lib/libgit2.so.1.0
14
#5 0x00000008037dc494 in () at /usr/local/lib/libgit2.so.1.0
15
#6 0x00000008037da932 in () at /usr/local/lib/libgit2.so.1.0
16
#7 0x00000008037dac9f in git_commit_create () at /usr/local/lib/libgit2.so.1.0
17
#8 0x0000000000649e89 in horizon::PoolRemoteBox::create_pr_thread() (this=0x80766ed00) at src/pool-prj-mgr/pool-mgr/pool_remote_box.cpp:1241
18
#9 0x000000000065336d in _ZNSt3__18__invokeIMN7horizon13PoolRemoteBoxEFvvEPS2_JEvEEDTcldsdeclsr3std3__1E7forwardIT0_Efp0_Efp_spclsr3std3__1E7forwardIT1_Efp1_EEEOT_OS6_DpOS7_
Jürgen F. schrieb:> Danke an alle Zuseher!
Danke dir nochmal für deine Aktivität!
Hat mich dazu bewogen, mein Horizon mal auf aktuellen Stand zu bringen
und wirklich mal wieder zu testen – siehe ersten Merge Request für den
Pool. Ganz zufällig :) habe ich mir auch ein Relais rausgesucht, aber
ein Reed-Relais, von dem ich gerade noch 5 Stück rumliegen habe (und
welches man auch aktuell noch kaufen kann).
Was mir bei der Datenblatt-Geschichte auffällt: könnte man dafür (oder
ist vielleicht schon?) einen lokalen Cache einrichten, in dem die die
runter geladenen PDFs zwischengespeichert werden? Dann muss man erstens
nicht jedesmal das Netz dafür belästigen, und zweitens kann ich mir die
gecacheten Datenblätter halt auch in der Regionalbahn in
Hinterposemuckel noch ansehen, wo meine Internetverbindung vielleicht
gerade nur mit viel Glück von einer 30 km entfernten polnischen
GSM-Basisstation erbracht wird. (Tatsächlich schon so erlebt in der
Uckermark.)
Was mir an Horizon generell auffällt: die 3D-Darstellung ist um
mindestens eine Größenordnung schneller als die von Kicad. Liegt das
daran, dass Lukas hier von vornherein (gab damals viele Diskussionen)
auf neuere OpenGL-Versionen gesetzt hat?
Hmm, bei den vielen offenen Pull-Requests auf Github bin ich mir gerade
nicht ganz sicher: gibt es wirklich noch nirgends ein SOT-23 Package?
Ich sehe SOT-23-5 und SOT-23-6, aber kein Standard-Package mit 3 Pins.
Jörg W. schrieb:> Kann das die Ursache sein?
Ja, war es. Wird nun im "Confirm PR"-Dialog überprüft.
Jörg W. schrieb:> einen lokalen Cache einrichten, in dem die die> runter geladenen PDFs zwischengespeichert werden?
Die Idee hatte ich auch mal gehabt. Wenn jemand anders die Idee auch
hat, kann sie ja so schlecht nicht sein.
Jörg W. schrieb:> die 3D-Darstellung ist um> mindestens eine Größenordnung schneller als die von Kicad. Liegt das> daran, dass Lukas hier von vornherein (gab damals viele Diskussionen)> auf neuere OpenGL-Versionen gesetzt hat
Ich hatte die 3D-Darstellung von KiCad nie als übermäßig langsam
empfunden. Ich hab gerade mal einen blick in den 3D-Code von KiCad
geworfen und die verwenden tatsächlich die doch gut abgehangenen display
lists. Dank modernerem OpenGL werden in Horizon durch Verwendung von
Instancing alle Bauteile mit dem selben Modell in einem Rutsch
gezeichnet.
Auch ist der 3D-Code in Horizon erheblich schlanker: Ein wc -l der
sourcen von der 3D-Ansicht in KiCad ergibt ca. 25kLOC, bei mir sind's
ca. 3700, wobei da noch Code zum ausrichten oder projizieren von
3D-Modellen drin ist.
Jörg W. schrieb:> gibt es wirklich noch nirgends ein SOT-23 Package?> Ich sehe SOT-23-5 und SOT-23-6, aber kein Standard-Package mit 3 Pins.
Ich meine mich zu erinnern, das mal in einen Pull request gesehen haben,
weiß leider nicht mehr welcher.
Lustig, dass aufgrund des ellenlangen Threads nun nach 4 Jahren immer
noch "halbfertig" drüber steht. ;-)
Wenn du willst, kann ich auch den Titel des initialen Postings mal
ändern. Der geänderte Titel erscheint ja dann in der Threadliste.
Lukas K. schrieb:> Ich hab gerade mal einen blick in den 3D-Code von KiCad geworfen und die> verwenden tatsächlich die doch gut abgehangenen display lists. Dank> modernerem OpenGL werden in Horizon durch Verwendung von Instancing alle> Bauteile mit dem selben Modell in einem Rutsch gezeichnet.
Ich weiß nicht mehr, ob das schonmal gefragt wurde, aber welchen
Hintergrund hast du eigentlich? Das Projekt ist absolut nicht trivial
und spielt imho in der Profi Liga aus Entwicklerperspektive. Ich hätte
dich in die Richtung hauptberuflicher Dev gesehen aber dafür ist das
Thema irgendwie zu elektrotechnisch. Was ist denn deine biographie?
Von 1000 Menschen, die sich an so eine Software heranwagen, schaffen
vielleicht 10 ein brauchbares Ergebnis. Horizon ist aber gefühlt ein bis
zwei Klassen über brauchbar.
Und woher nimmst du die Zeit?
Martin S. schrieb:> Das Projekt ist absolut nicht trivial> und spielt imho in der Profi Liga aus Entwicklerperspektive.
Da bin ich absolut mit dir einverstanden.
Soweit ich mal in einem Talk von Lukas auf YouTube gesehen habe hat er
Elektrotechnik studiert (und hat vor ~5 Jahren abgeschlossen, mit einer
Entwicklung welche er in einer frühen Version von Horizon zeichnen
durfte)
Gibt es eigentlich einen Ort wo man dir etwas Geld schicken kann (z.B.
Patreon, ...)? Ich bezahle gerne etwas fü gute Software, und finde es
nobel, dass du es erstens als OS anbietest und zweitens nirgends etwas
über spenden geschrieben hast.
Eine Frage kommt mir gerade in den Sinn:
Ich habe hier eine Datenbank (PostgresQL), in der ich so gut wie alle
meiner SMD-Bauteile katalogisiert habe. Primärschlüssel der Datenbank
ist letztlich einfach eine laufende Nummer, die dann als so eine Art
"Lagerhaltungsnummer" fungiert. (Im Moment noch ziemlich chaotisch im
"Lager". :)
Wenn ich mir nun einen Widerstand oder Kondensator in die Schaltung
einplane, würde ich natürlich vorzugsweise einen solchen nehmen (Wert,
Bauform), der bereits "im Lager" ist. U.U. würde ich halt beispielsweise
von der "Standardbauform" (derzeit 0603 bei mir) abweichen, wenn der
gewünschte Wert in großer Stückzahl in 0805 gerade da ist. Oder, mein
einziger Mini-MELF-Widerstand (aber davon dann knapp 200 Stück) hat 36,5
kΩ. Könnte man oftmals überall da benutzen, wo man jetzt gerade "nach
Nase" einen mit 33 kΩ einsetzen würde.
Dafür wäre es cool, wenn man im Pool dafür irgendein Attribut
hinterlegen könnte und dann danach filtern. Die Verbindung zur PgSQL-DB
muss nicht unbedingt "live" sein, ich könnte mir auch vorstellen, dass
per Batch irgendwie nächtlich zu propagieren oder immer nur dann
manuell, wenn ich mal wieder "shoppen" war.
Jörg W. schrieb:> Lustig, dass aufgrund des ellenlangen Threads nun nach 4 Jahren immer> noch "halbfertig" drüber steht. ;-)
Wenn mir ein besserer Titel einfallen würde... Unpassende Threadnamen
gehören ja schon fast zum guten Ton hier, man denke nur an "Brauche
Hilfe beim Bau eine Uhr".
Martin S. schrieb:> Ich weiß nicht mehr, ob das schonmal gefragt wurde, aber welchen> Hintergrund hast du eigentlich? Das Projekt ist absolut nicht trivial> und spielt imho in der Profi Liga aus Entwicklerperspektive.
Mit Elektronik angefangen, dann Richtung Software abgerutscht.
Aus Software-Sicht ist Horizon EDA eigentlich nichts herausragendes,
alles algorithmisch annnährend komplexe wie z.B. Polygonoperationen oder
der push&shove Router und Airwire-Berechnung kommt aus Libraries, bzw.
aus KiCad. Die 3D-Ansicht entstand u.a. durch Nachprogrammieren von
OpenGL-Tutorials wie https://open.gl/.
Jörg W. schrieb:> Dafür wäre es cool, wenn man im Pool dafür irgendein Attribut> hinterlegen könnte und dann danach filtern.
Das einfachste könnte sein, mit einem Skript alles vorhandene
Hühnerfutter zu erzeugen. Kann z.B. so aussehen:
https://github.com/horizon-eda/horizon-pool/blob/master/scripts/panasonic-erj/gen.py
Wichtig ist dabei, dass die UUID gleich bleibt.
Eine anderer Ansatz ist, einen eigenen StockInfoProvider zu
implementieren, der dann mit deiner Datenbank redet und so abfragt was
gerade da ist. Wäre dann an der Stelle von
https://horizon-eda.readthedocs.io/en/latest/feature-overview.html#stock-information
Lukas K. schrieb:>> Lustig, dass aufgrund des ellenlangen Threads nun nach 4 Jahren immer>> noch "halbfertig" drüber steht. ;-)>> Wenn mir ein besserer Titel einfallen würde...
Wie wäre es schlicht und einfach mit "Horizon-EDA"?
> Mit Elektronik angefangen, dann Richtung Software abgerutscht.
Willkommen im Klub. :-)
> Eine anderer Ansatz ist, einen eigenen StockInfoProvider zu> implementieren, der dann mit deiner Datenbank redet und so abfragt was> gerade da ist. Wäre dann an der Stelle von> https://horizon-eda.readthedocs.io/en/latest/feature-overview.html#stock-information
Schau ich mir mal an, klingt zumindest passend von der Richtung her.
Kurze schamlose Eigenwerbung: Heute bin ich um 18:00 Uhr wieder online
und bastle weiter mit Horizon EDA rum. Thema heute: einen
USB-Seriell-Adapter für den Debug-Header zusammenklicken. Speziell ist
heute, dass wir uns mit USB beschäftigen und somit differentielle
Leitungen auf dem PCB verlegen werden.
03.03.21 18:00 Uhr - https://www.twitch.tv/electrifried
Mein Grober Plan für die nächsten Wochen wird übrigens dann etwas
Software-lastiger. Die Mikrocontroller bekommen ein RTOS verpasst, mit
dem ich mich auch schon ein bisschen länger beschäftigt habe:
https://riot-os.org/
Hi! Ich habe heute (mal wieder) Horizon (versucht) zu kompilieren.
Leider bleibt es in der Datei zmq_helper.cpp stecken:
1
src/util/zmq_helper.cpp: In function ‘void horizon::zmq_helper::subscribe_int(zmq::socket_t&, uint32_t)’:
2
src/util/zmq_helper.cpp:33:10: error: ‘class zmq::socket_t’ has no member named ‘set’
3
33 | sock.set(zmq::sockopt::subscribe, buf);
4
| ^~~
5
src/util/zmq_helper.cpp:33:19: error: ‘zmq::sockopt’ has not been declared
6
33 | sock.set(zmq::sockopt::subscribe, buf);
7
| ^~~~~~~
8
src/util/zmq_helper.cpp: In function ‘Glib::RefPtr<Glib::IOChannel> horizon::zmq_helper::io_channel_from_socket(zmq::socket_t&)’:
9
src/util/zmq_helper.cpp:42:20: error: ‘class zmq::socket_t’ has no member named ‘get’
10
42 | auto fd = sock.get(zmq::sockopt::fd);
11
| ^~~
Anscheinend funktioniert die Versions-Erkennung nicht richtig.
Kommentiere ich diese aus, läuft der build weiter
1
#include "zmq_helper.hpp"
2
3
//#ifdef CPPZMQ_VERSION
4
//#if CPPZMQ_VERSION >= ZMQ_MAKE_VERSION(4, 3, 1)
5
//#define V431
6
//#endif
7
//#endif
8
9
namespace horizon::zmq_helper {
10
...
Leider gibts dann ein paar Warnings, angeblich habe ich Version >=4.3.1
von zmq. Lt. apt habe ich libzmq3-dev (4.3.2-2ubuntu1).
Kann es sein, dass die open angemeckerte get/set Methoden erst in einer
späteren Version vom zmq eingebaut wurden? Oder in 4.3.2 schon wieder
angeschafft?
1
src/util/zmq_helper.cpp: In function ‘bool horizon::zmq_helper::recv(zmq::socket_t&, zmq::message_t&)’:
2
src/util/zmq_helper.cpp:16:26: warning: ‘bool zmq::detail::socket_base::recv(zmq::message_t*, int)’ is deprecated: from 4.3.1, use recv taking a reference to message_t and recv_flags [-Wdeprecated-declarations]
3
16 | return sock.recv(&msg);
4
| ^
5
In file included from src/util/zmq_helper.hpp:2,
6
from src/util/zmq_helper.cpp:1:
7
/usr/include/zmq.hpp:1407:10: note: declared here
8
1407 | bool recv(message_t *msg_, int flags_ = 0)
9
| ^~~~
10
src/util/zmq_helper.cpp: In function ‘bool horizon::zmq_helper::send(zmq::socket_t&, zmq::message_t&)’:
11
src/util/zmq_helper.cpp:25:25: warning: ‘bool zmq::detail::socket_base::send(zmq::message_t&, int)’ is deprecated: from 4.3.1, use send taking message_t and send_flags [-Wdeprecated-declarations]
12
25 | return sock.send(msg);
13
| ^
14
In file included from src/util/zmq_helper.hpp:2,
15
from src/util/zmq_helper.cpp:1:
16
/usr/include/zmq.hpp:1326:10: note: declared here
17
1326 | bool send(message_t &msg_,
18
| ^~~~
Ach ja: XUbuntu 20.04. horizon lässt sich dann starten, habe aber nicht
intensiv getestet!
Übrigens danke fürs programmieren von Horizon!
Jörg schrieb
>Lustig, dass aufgrund des ellenlangen Threads nun nach 4 Jahren immer>noch "halbfertig" drüber steht. ;-)
Also ich finde den Thread-Titel sehr lustig. Mir gefällt diese Art des
Understatements.
Viele übertreiben ja bei der Beschreibung ihrer Werke und da ist es
wohltuend, mal das Gegenteil zu erleben.
chris_ schrieb:> Understatements
Understatement ist echt eine Untertreibung für das, wass diese
One-man-show in nichtmal der Hälfte der Zeit aus dem Boden gestampft
hat. Ich müsste wahrscheinlich die nächsten 30 Jahre nonstop
programmieren lernen, um das zustande zu bringen. Und hätte dann
vermutlich schlichtweg keine Lust dazu :-)
> Kann es sein, dass die open angemeckerte get/set Methoden erst in einer
späteren Version vom zmq eingebaut wurden? Oder in 4.3.2 schon wieder
angeschafft?
Danke für den Hinweis, tatsächlich war die Versionserkennung bei mir
falsch. Die get/set gibt's erst ab 4.7.0 und nicht schon ab 4.3.1.
Doch damit es leider nicht getan: Die Spezialisten von Ubuntu haben
statt ein Release von cppzmq zu paketieren, wohl das genommen, was
irgendwann auf deren master-Branch rumlag. Das gibt sich zwar als 4.7.0
aus, hat aber die benötigten Funktionen noch nicht. Deswegen tut es auch
mit eigentlich korrekter Versionserkennung auf fast keinem Ubuntu:
https://github.com/horizon-eda/horizon/runs/2605278090?check_suite_focus=true
Magst du einen Bugreport bei Ubuntu aufmachen, oder soll ich?
Eigentlich ist der der Eiertanz mit Versionserkennung nur drin, um
nervige deprecation-Warnings beim Bauen zu vermeiden...
Habe gerade neue Updates auf mein Linux gezogen und horizon Versucht neu
zu bauen (hing voher wegen zmq). Dabei kam es zu einem neuen Fehler und
ich habe
1
#include <optional>
in "src/parameter/program.hpp" und
"src/widgets/parameter_set_editor.hpp" einfügen müssen.
Damit war "gcc 11.1.0" zufrieden.
neuer PIC Freund schrieb im Beitrag #6700866:
> Damit war "gcc 11.1.0" zufrieden.
Danke für die Erinnerung daran, auf meinem Arch Linux mal wieder updates
zu installieren ;) Kam gerade noch rechtzeitig für das bevorstehende 2.0
Release.
chris_ schrieb:> Jörg schrieb>>Lustig, dass aufgrund des ellenlangen Threads nun nach 4 Jahren immer>>noch "halbfertig" drüber steht. ;-)>> Also ich finde den Thread-Titel sehr lustig. Mir gefällt diese Art des> Understatements.> Viele übertreiben ja bei der Beschreibung ihrer Werke und da ist es> wohltuend, mal das Gegenteil zu erleben.
Mich verwirrt es aber ...
Ist es nun eher eine Alpha oder schon für den produktiven Einsatz
geeignet?
Martin schrieb:> chris_ schrieb:>> Jörg schrieb>>>Lustig, dass aufgrund des ellenlangen Threads nun nach 4 Jahren immer>>>noch "halbfertig" drüber steht. ;-)>>>> Also ich finde den Thread-Titel sehr lustig. Mir gefällt diese Art des>> Understatements.>> Viele übertreiben ja bei der Beschreibung ihrer Werke und da ist es>> wohltuend, mal das Gegenteil zu erleben.>> Mich verwirrt es aber ...>> Ist es nun eher eine Alpha oder schon für den produktiven Einsatz> geeignet?
und warum genau, folgst Du dann nicht dem Link im ersten Post und
schaust den Zustand des Projektes an?
Hier für dich der Link direkt zur Release Seite, in der Hoffnung, dass
dies Deine Verwirrung auflöst:
https://github.com/horizon-eda/horizon/releases
Ralf M. M. schrieb:> Martin schrieb:>> chris_ schrieb:>>> Jörg schrieb>>>>Lustig, dass aufgrund des ellenlangen Threads nun nach 4 Jahren immer>>>>noch "halbfertig" drüber steht. ;-)>>>>>> Also ich finde den Thread-Titel sehr lustig. Mir gefällt diese Art des>>> Understatements.>>> Viele übertreiben ja bei der Beschreibung ihrer Werke und da ist es>>> wohltuend, mal das Gegenteil zu erleben.>>>> Mich verwirrt es aber ...>>>> Ist es nun eher eine Alpha oder schon für den produktiven Einsatz>> geeignet?>> und warum genau, folgst Du dann nicht dem Link im ersten Post und> schaust den Zustand des Projektes an?>> Hier für dich der Link direkt zur Release Seite, in der Hoffnung, dass> dies Deine Verwirrung auflöst:> https://github.com/horizon-eda/horizon/releases
Naja, die Reife eines Projekts abzuschätzen ist nicht so einfach und
nicht jeder hat die Zeit, es erstmal nen Tag zu testen. Und um das so
wirklich einzuschätzen braucht man etwas Einarbeitung.
Ich habe das vorhin auch gemacht und festgtestellt, dass es eine Version
2.0 gibt. Dass OSS sich mit Versionsnummer >1.0 noch nicht als
produktionsreif sieht, habe ich auch schon gesehen.
Und da im Betreff sogar explizit halbfertig steht, finde ich die Frage
mehr als gerechtfertigt und so einer schroffen Antwort unwürdig.
Bei dieser Frage ist außerdem ein eventuelles Statement regelmäßiger
Nutzer oder sogar des Autors deutlich hilfreicher als ne halbe Stunde
Changelog lesen und rumprobieren.
Jemand schrieb:> und nicht jeder hat die Zeit, es erstmal nen Tag zu testen
Dann bist du bei EDA komplett falsch.
Kommerzielle EDA-Tools kannst du kaum unter einer Woche
Einarbeitungszeit benutzen.
Den Tag wirst du dir schon gönnen müssen um zu sehen, ob du damit klar
kommst. Da helfen auch keine Einschätzungen anderer Nutzer (die ja dann
typischerweise sehr wohl bereits damit klar kommen).
Jörg W. schrieb:> Jemand schrieb:>> und nicht jeder hat die Zeit, es erstmal nen Tag zu testen>> Dann bist du bei EDA komplett falsch.>> Kommerzielle EDA-Tools kannst du kaum unter einer Woche> Einarbeitungszeit benutzen.>> Den Tag wirst du dir schon gönnen müssen um zu sehen, ob du damit klar> kommst. Da helfen auch keine Einschätzungen anderer Nutzer (die ja dann> typischerweise sehr wohl bereits damit klar kommen).
Okay, der Tag war auch sportlich geschätzt, da hast du Recht. Effektiv
verstärkt dieser Einwand die Aussage aber noch.
In obigem Post ging es ja eher um die Ausgereiftheit. Da finde ich
zumindest es echt hilfreich, andere Meinungen zu hören. Insbesondere,
wenn die Urheber der Meinungen schon geübter mit der Software sind.
Jemand schrieb:> oder sogar des Autors deutlich hilfreicher als ne halbe Stunde> Changelog lesen und rumprobieren.
Gerne doch. Bereits vor fast 3 Jahren habe ich damit das hier layoutet:
https://github.com/carrotIndustries/x-band-tx/ Wobei allerdings
anzumerken ist, dass Leute auch schon mit weitaus primitiverer Software
komplexere Boards entwickelt haben.
Für kleine bis mittelgroße Projekte ist Horizon EDA seit einiger Zeit,
spätestens seit Version 1.0 geeignet.
Nachteil gegenüber anderen Programmen, die schon etliche Jahre mehr auf
dem Buckel haben ist natürlich der geringere Bauteilvorrat und das
Fehlen von Dokumentation jenseits der auf https://docs.horizon-eda.org/
Auch ist die wahrscheinlich geringer, dass jemand vor dir ein Problem
schonmal hatte und dazu eine Lösung gefunden hat.
Lukas K. schrieb:> Nachteil gegenüber anderen Programmen, die schon etliche Jahre mehr auf> dem Buckel haben ist natürlich der geringere Bauteilvorrat
Na klar, in der Werbung zählen nur große Zahlen :( Im Vergleichstest
muss man aber alle Punkte gewichten und Bauteilevorrat sollte maximal zu
1% ins Testergebnis einfließen. Wenn man das anders bewertet, kommt so
ein Schrott wie die Eagle-Bibliotheken dabei raus.
Der Vorrat sollte groß genug sein, dass für jedes Feature ein Beispiel
dabei ist. Und das auch nur, weil zu einem guten Handbuch eben auch
Beispiele gehören. 3854 verschiedene Stecker (Eagle) verschwenden nur
Speicherplatz und der eine, den ich jetzt brauche, ist doch nicht dabei
oder, noch schlimmer, unbrauchbar bis falsch.
Lukas K. schrieb:> Für kleine bis mittelgroße Projekte ist Horizon EDA seit einiger Zeit,> spätestens seit Version 1.0 geeignet.
Dann wäre es vielleicht doch gut, wenn ein Moderator den Titel des
Ursprungsbeitrags mal anpassen würde. Er hat zwar schon Kultstatus, aber
um neue Nutzer anzuziehen, ist "halbfertig" kein guter Werbetext.
Lukas hat meine Frage jetzt schon beantwortet. Danke und einen Daumen
hoch für dein Projekt.
Mit dem Einarbeiten bekomme ich schon hin. Ich kann auch ein paar Fehler
in kauf nehmen. Aber wenn es quasi nicht möglich wäre am Ende eine
funktionstüchtigen Schaltplan und eine Platiene heraus zu bekommen würde
ich mir die Arbeit NOCH nicht machen mich einzuarbeiten.
Lukas K. schrieb:> Jemand schrieb:>> oder sogar des Autors deutlich hilfreicher als ne halbe Stunde>> Changelog lesen und rumprobieren.>> Gerne doch. Bereits vor fast 3 Jahren habe ich damit das hier layoutet:> https://github.com/carrotIndustries/x-band-tx/ Wobei allerdings> anzumerken ist, dass Leute auch schon mit weitaus primitiverer Software> komplexere Boards entwickelt haben.>> Für kleine bis mittelgroße Projekte ist Horizon EDA seit einiger Zeit,> spätestens seit Version 1.0 geeignet.>> Nachteil gegenüber anderen Programmen, die schon etliche Jahre mehr auf> dem Buckel haben ist natürlich der geringere Bauteilvorrat und das> Fehlen von Dokumentation jenseits der auf https://docs.horizon-eda.org/> Auch ist die wahrscheinlich geringer, dass jemand vor dir ein Problem> schonmal hatte und dazu eine Lösung gefunden hat.
Super, danke für die Antwort!
Ich werde es mir dann auch noch mal bei Zeiten anschauen, aktuell habe
ich für sowas keinen Kopf …
Seit dem Lesen des Changelogs und der Features habe ich echt Respekt vor
der Leistung, so ein Programm aus dem Boden zu stampfen :)
Jemand schrieb:> Seit dem Lesen des Changelogs und der Features habe ich echt Respekt vor> der Leistung, so ein Programm aus dem Boden zu stampfen :)
und wenn man sich jetzt zum Vergleich überlegt, wie sich solche
Programme wie EAGLE in der gleichen Zeit weiterentwickelt haben ...
Markus W. schrieb:> und wenn man sich jetzt zum Vergleich überlegt, wie sich solche> Programme wie EAGLE in der gleichen Zeit weiterentwickelt haben
Paretoprinzip bei der Arbeit: die ersten 80% brauchen 20% des Aufwandes.
Auch hilfreich ist bestimmt, keine Vergangenheit zu haben, die bis in
die DOS-Ära zurückreicht.
Außerdem gab es einige weitere günstige Umstände:
- Alles algorithmisch anspruchsvolle wie z.B. Polygonoperationen zum
Berechnen von Planes, das Berechnen der Luftlinien oder der interaktive
Router kommt aus Libraries:
https://github.com/horizon-eda/horizon/blob/master/README.md#included-third-party-software
- Da alles mit OpenGL gezeichnet wird, muss ich mir deutlich weniger
Gedanken darüber machen, welcher Teil vom Fenster sich nun geändert hat
und neu gezeichnet werden muss. Einfach alles neu malen, OpenGL ist
schon schnell genug. Wäre 10 Jahre früher nicht so einfach gewesen.
- Computer sind schnell: Für Undo/redo wird (fast) das gesamte Board
kopiert, anstatt sich zu merken, was tatsächlich geändert wurde. Ist
zwar nicht so effizient, aber dafür einfacher korrekt zu implementieren.
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten