Announcement: there is an English version of this forum on Hallo Zusammen, nach einigen Monaten ist mein Elektronik-CAD-Programm endlich halbwegs vorzeigbar: https://github.com/carrotIndustries/horizon Auch wenn es schon alles von Schaltplan bis Gerber-Export da ist, gibt es immer noch mehr als genug Dinge, die anders/besser werden müssen, bis man damit ernsthaft Platinen entwickeln kann. Viel Spaß damit, Lukas
:
Bearbeitet durch Moderator
Und du bist dir sicher, das eine Vielzahl von Leuten dein Programm
ausprobieren, nutzen und weiterempfehlen werden, weil es sich ja so
leicht von jedermann installieren läßt ?!?
Jeder "Electronic-CAD-Programm" - Nutzer ist ja automatisch auch ein
fähiger Programmierer, der sich mit sowas
"For building on Windows, use MSYS2
Dependencies:
Gtkmm3
libepoxy
cairomm-pdf
librsvg
util-linux (on linux only)
yaml-cpp
sqlite "
easy
("It's as easy as make.")
auskennt ....
[Wer Ironie gefunden hat, darf sie behalten ]
:
Bearbeitet durch User
Lukas K. schrieb: > nach einigen Monaten ist mein Elektronik-CAD-Programm endlich halbwegs > vorzeigbar: https://github.com/carrotIndustries/horizon Was ist den hier los ? Hat hier jemand den CAD-ÖTZI aus Versehen aufgetaut ? ? Ob er wohl checkt wie es in dieser bösen CAD-Welt zugeht. Es bleibt zu hoffen, dass er nicht dieser listigen Autodesk-Schlange anheimfällt :-( ? ---- Bitte nicht allzu ernst nehmen ;-)? Ich frage mich halt, ob es mit deinem Wissen nicht andere Projekte gibt die einen weitaus größeren Nährwert versprechen, als wie hier alte 'Suppen' aufzuwärmen.
Wer was kostenloses sucht und nicht scharf auf Frust ist, der greift zu Kicad...
Lukas K. schrieb: > Hallo Zusammen, > > nach einigen Monaten ist mein Elektronik-CAD-Programm endlich halbwegs > vorzeigbar: https://github.com/carrotIndustries/horizon > > Auch wenn es schon alles von Schaltplan bis Gerber-Export da ist, gibt > es immer noch mehr als genug Dinge, die anders/besser werden müssen, bis > man damit ernsthaft Platinen entwickeln kann. > > Viel Spaß damit, > Lukas Nur 6 commits auf github?? Sieht auf den Screenshots aber schonmal vielversprechend aus. Werde es bei Gelegenheit mal ausprobieren. @hardyf: Wenn Du erwartest, dass Dir andere Leute das Denken abnehmen, dann solltest Du Dir vielleicht ein anderes Hobby suchen.
Lukas K. schrieb: > Viel Spaß damit Schön, daß sich jemand bemüht, etwas zu erschaffen. Aber meinst du wirklich, daß noch eines nötig war ? https://en.wikipedia.org/wiki/Comparison_of_EDA_software http://www.eevblog.com/forum/eda/pcbeda-software-list/ Vielleicht hätte man besser bei den anderen halbfertigen Projekten mithelfen können. AutoTrax macht beispielsweise eigentlich alles richtig, schönes Programm, alles möglich dabei, nicht zu teuer. Und bekommt trotzdem seit 10 Jahren keinen Fuss an den Boden. https://dexpcb.com/ Wenn man schon von vorne anfängt, hat man wenigstens keine Altlasten und kann bei Standards beginnen: https://de.wikipedia.org/wiki/Electronic_Design_Interchange_Format http://pcad-libs.embedders.org/rules/ref_617.pdf http://wiki.fed.de/index.php/Lageorientierung_von_Bauteilen_in_Bibliotheken http://www.lp-akademie.de/publikationen/cad-bg/vom_layout_zur_bg.html http://www.k-state.edu/edl/docs/pubs/technical-resources/Technote8.pdf
:
Bearbeitet durch User
Michael B. schrieb: > Wenn man schon von vorne anfängt, hat man wenigstens > keine Altlasten und kann bei Standards beginnen: Das ist zwar im Prinzip richtig, aber ein Standard nutzt wenig, wenn man ihn als einziger benutzt. Den firmenübergreifenden Standard für Leiterplatten-CAD gibt es nicht, und meiner Ansicht nach besteht auch wenig Hoffnung. Ich habe selbst schon Konversionsprogramme geschrieben und weiss, an welchen Kleinigkeiten eine 1:1 Umwandlung scheitert - nur als ganz einfaches Beispiel, man hat 6eckige Lötaugen und im Zielsystem gibt es das nicht. Von komplexeren Sachen wie differential Lines garnicht erst zu reden. Georg PS besonders "beliebt" sind grundsätzliche Unterschiede in der Definition von beliebigen Flächen.
> @hardyf: Wenn Du erwartest, dass Dir andere Leute das Denken abnehmen, > dann solltest Du Dir vielleicht ein anderes Hobby suchen. Ja, und die Keramikkondensatoren töpfern wir auch selbst.
Was Ich an Gihub überhaupt nicht leiden kann, ist das komplett unsoriterte und unübersichtliche Schema! Man kriegt ein Repository hingeknallt, das weder Übersicht hat noch schafft! Und die Nutzer führen auch keine Übersicht ein! Richtig wäre, mal 1) Beschreiben, WAS das ist 2) für welchen Nutzerkreis es sein soll 3) Wie es funktioniert! Dazu braucht es ein Übersichtsdigramm, welche Module es gibt, wie man sie benutzt, was man dazu noch braucht und in dem Fall, dass es nur sourven sind, wie man sie zusammenbaut. Also a) Schnittstellen zur Aussenwelt b) Schnittstellen inten c) Bedienerfunktionalität. All das wäre in einigem richtigen Projekt sauber und übersichlich vorhanden und dokumentiert, damit es auch einer nutzen kann. So ist das einfach nur ein großer Saustall und Chaos! Leider gilt das auch für dieses Projekt. Das macht es unmöglich, da mit einzusteigen, Interesse zu wecken oder einen in die Lage zu versetzen, einzuschätzen, ob man es verwenden kann. DAS IST DER GRUND; WARUM AUS SOLCHEN PROJEKTEN NIX WIRD. DA ENTWROGT JEMAND NUR SEINEN MÜLL; DEN ER IM KOPF HAT IN FORM VON SOFTWARE AUF EINEM OFFENEN SERVER. eigentlich ist das dann nicht viel mehr, als eine Müllhalde ... ............ und wenn Ich jetzt noch etwas zu der Notwendigkeit eines CAD-Programmes sagen würde, wäre es ganz haarig ...
Ingenieur schrieb: > Was Ich an Gihub überhaupt nicht leiden kann Und was hat das mit Github zu tun?
Bernd K. schrieb: > Ingenieur schrieb: >> Was Ich an Gihub überhaupt nicht leiden kann > > Und was hat das mit Github zu tun? Nix. Aber wenn man schon gewohnt ist alles umsonst haben zu wollen dann ist es doch auch egal worüber man meckert^^ Ansonsten @ingenieur: Ja, etwas mehr Effort könnte so ein Projekt sicher vertragen. Wann willst Du mit was helfen? Hardy F. hat ja schon festgestellt, dass ein Build für Windows hilfreich wäre... @Lukas K.: Nette Idee :-) Aber wenn Du nicht "Alleinunterhalter" bleiben willst, dann solltest Du evtl. eine minimale SW Beschreibung anlegen (meist reichen die "normalen" Doxygen Kommentare schon aus). DU (!) weisst ja, was Du wie implementiert hast. Alle Anderen müssten sich das erst zusammensuchen, was unnötiger Aufwand ist. Hast Du schon eine Idee wie sich das Projekt weiterentwickeln soll? /regards
Wenn Push&shove Routing dabei ist, dann tue ich mir sogar komplizierte Installation an ;) Ohne Push&shove ist es doch sinnlos
Ich bekomms es nicht compiliert:
In file included from /usr/include/c++/5/bits/stl_algobase.h:64:0,
from /usr/include/c++/5/bits/char_traits.h:39,
from /usr/include/c++/5/ios:40,
from /usr/include/c++/5/ostream:38,
from /usr/include/c++/5/iostream:39,
from util/uuid.hpp:8,
from pool/part.hpp:2,
from pool/part.cpp:1:
/usr/include/c++/5/bits/stl_pair.h: In instantiation of ‘constexpr
std::pair<_T1, _T2>::pair(_U1&&, _U2&&) [with _U1 = const
nlohmann::basic_json<>&; _U2 = const nlohmann::basic_json<>&;
<template-parameter-2-3> = void; _T1 = bool; _T2 =
std::__cxx11::basic_string<char>]’:
pool/part.cpp:10:30: required from here
/usr/include/c++/5/bits/stl_pair.h:145:64: error: call of overloaded
‘basic_string(const nlohmann::basic_json<>&)’ is ambiguous
: first(std::forward<_U1>(__x)), second(std::forward<_U2>(__y)) { }
^
In file included from /usr/include/c++/5/string:52:0,
from /usr/include/c++/5/bits/locale_classes.h:40,
from /usr/include/c++/5/bits/ios_base.h:41,
from /usr/include/c++/5/ios:42,
from /usr/include/c++/5/ostream:38,
from /usr/include/c++/5/iostream:39,
from util/uuid.hpp:8,
from pool/part.hpp:2,
from pool/part.cpp:1:
/usr/include/c++/5/bits/basic_string.h:476:7: note: candidate:
std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::basic_string(std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>&&) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc
= std::allocator<char>]
basic_string(basic_string&& __str) noexcept
^
/usr/include/c++/5/bits/basic_string.h:398:7: note: candidate:
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(const
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT =
char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>]
basic_string(const basic_string& __str)
^
/usr/include/c++/5/bits/basic_string.h:390:7: note: candidate:
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(const
_Alloc&) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc =
std::allocator<char>]
basic_string(const _Alloc& __a)
^
Makefile:238: die Regel für Ziel „pool/part.o“ scheiterte
make: *** [pool/part.o] Fehler 1
tester schrieb: > Ich bekomms es nicht compiliert: Wieso ???? Ist doch easy.... Oder ? Dann bleib ich mal lieber bei meinem Hobby ;-)
tester schrieb: > Ich bekomms es nicht compiliert: Hm, welcher GCC? Bei mir hier baut's mit GCC 6.3.1 und clang 3.9.1. Ich hab mir die Zeile mal angesehen, versuch mal das zu ändern: Wo vorher war:
1 | attributes[Attribute::MPN] = {j.at("MPN").at(0),j.at("MPN").at(1)};
|
Das:
1 | attributes[Attribute::MPN] = {j.at("MPN").at(0).get<bool>(),j.at("MPN").at(1).get<std::string>()};
|
bei den beiden Zeilen drunter analog dazu.
3162534373 .. schrieb: > Wenn Push&shove Routing dabei ist, dann tue ich mir sogar komplizierte > Installation an ;) > Ohne Push&shove ist es doch sinnlos Push-and-shove gibt's noch nicht, aber der Router weicht immerhin schon den meisten Hindernissen aus. Der push-and-shove-Router von KiCAD hat änhlich viele lines of code wie horizon derzeit, um mal so die Komplexität darzustellen...
@ Lukas Ich würde sehr gern dein Programm mal ausprobieren. Ich komme aber mit Selbstcompilieren nicht klar. Da habe ich in der Schule wohl nicht aufgepasst damals vor 5x Jahren... Also bitte versuche einen fertigen Windows-Build mit dazuzustellen auf der Seite. Es dürften sicher paar mehr Leute ganz dankbar dafür sein so wie auch ich.
Lukas K. schrieb: > Hm, welcher GCC? Bei mir hier baut's mit GCC 6.3.1 und clang 3.9.1. Bei mir der Standard gcc/g++ 5.4 von Ubuntu 16.04. Aber der Patch läuft, ich konnte part.cpp kompilieren. Jetzt hängt er bei schematic.cpp. Die Meldung ist dieses Mal etwas länger. Ist als Anhang dabei...
Andreas H. schrieb: > Aber wenn Du nicht "Alleinunterhalter" bleiben willst, dann solltest Du > evtl. eine minimale SW Beschreibung anlegen (meist reichen die > "normalen" Doxygen Kommentare schon aus). > DU (!) weisst ja, was Du wie implementiert hast. Alle Anderen müssten > sich das erst zusammensuchen, was unnötiger Aufwand ist. Als ganz groben Anhaltspunkt gibt's den Abschmitt "Theory of operation" in der README, damit sollte man schonmal halbwegs wissen wo vorne ist. Doxygen-Dokumentation hatte ich persönlich nie als wirklich hilfreich empfunden, da darin oft erklärt ist, was auch eine Zeile drunter im Code steht, aber die grobe Struktur fehlt. > Hast Du schon eine Idee wie sich das Projekt weiterentwickeln soll? Unabhängig von dem Programm selber: Pool befüllen, dass man auch sinnvolle Schaltpläne und Boards machen kann. Kurz/mittelfristige ziele: - Platzieren von Bauteilen einfacher machen Liste von zuletzt benutzten Bauteilen; den Dialog "Select Part" auch als nicht modales Fenster zur Verfügung stellen. - Parametrische Suche: Die pool-parametric.db wird schon erzeugt, fehlt "nur noch" ne hübsche GUI drüber. - DRC: mit der clipper-Library ist der algorithmisch schwere Teil (Polygon-Operationen) schon erledigt, fehlt noch die gesamte Infrastruktur außenrum. - GUI für die constraints. Die als JSON zu bearbeiten und mit UUIDs zu hantieren macht derzeit gar keinen Spaß. - "Projekt-Manager", dass man sich nicht mehr die Argumente für horizon-imp selber ausdenken muss, sondern einfach Klicken kann. Nicht vergessen: Rom wurde auch nicht an einem Tag erbaut (und auch nicht in einer Nacht)
tester schrieb: > Ich bekomms es nicht compiliert Schön das Du es probierst :-) Benutzt Du MSYS2 (<-- 2 !!!)? Lukas K. schrieb: > Bei mir hier baut's mit GCC 6.3.1 Unter MSYS2 ist afaik GCC5 erst seit Anfang Januar verfügbar. Vieleicht liegt es daran? /regards
Michael B. schrieb: > AutoTrax macht beispielsweise eigentlich alles richtig, schönes > Programm, alles möglich dabei, nicht zu teuer. Und bekommt trotzdem seit > 10 Jahren keinen Fuss an den Boden. > > https://dexpcb.com/ Das Programm sieht super aus. Aber die Webseite aus dem letzten Jahrtausend. Vorallem mit diesen käsig eingefügten Stock-Fotos: https://dexpcb.com/Company Es scheint aber alles zu haben... Ich versteh aber auch nicht wieso es noch ein neues gibt. LibreCAD ist doch auch gerade durchs Forum hier gehuscht... Prinzipiell find ichs aber gut, man weiss ja nie, welches von den vielen Free Software Programmen dann letztendlich die breitere User-Basis bekommt. Was ich aus meinen Softwareprojekten aber gelernt hatte: Wenn man in einem Forum, in dem es nicht hauptsächlich um Softwareentwicklung geht, postet, dann sollte man eine ZIP oder EXE oder tar.gz/.deb (für Ubuntu) parat haben. Sonst bekommt man eben genau die Sprüche und Probleme zu lesen wie oben (been there, done that). Es ist letztendlich immer die Frage welche Motivation hinter dem Projekt steckt. Wenn man nur ausprobieren will, ob man es theoretisch hinbekommt sowas zu programmieren, dann ist ca. ab dem jetzt erreichten Stand die Luft raus. Wenn man etwas schreibt, damit mans selbst benutzt, dann gehts meist noch weiter. Aber selbst gebastelte Lösungen, die nicht noch von anderen mit getragen werden, werden erfahrungsgemäß irgendwann abgelöst. Beispielsweise wenn man in ein paar Jahren selbst ein Feature braucht welches andere Programme (KiCAD, Eagle, ...) haben, aber nicht die Zeit hat es selbst zu implementieren, weil man das Projekt seit 5 Monaten nicht mehr angefasst hat und zu faul ist sich wieder in den Code einzuarbeiten. Prinzipiell kann ich es aber nur unterstützen und finde es absolut großartig, dass Entwickler weiterhin Projekte für die Allgemeinheit schreiben und den Quelltext veröffentlichen. Würde aber gerne wissen wo sich Horizon und bspw. auch LibreCAD relativ zu KiCAD positionieren. Ein Problem bei KiCAD ist ja nachweislich die etwas merkwürdige Benutzerführung. Wenn man sich aber einmal zurecht gefunden hat, kommt man sehr gut damit klar - "eigentlich".
Andreas H. schrieb: > Benutzt Du MSYS2 (<-- 2 !!!)? Evtl. verstehe ich dich falsch, aber MSYS2 ist doch für Windows der Cygwin Posix Layer, oder? Ich versuche, das ganze unter Ubuntu 16.04 zu kompilieren, also brauche ich kein MSYS!
tester schrieb: > Ich versuche, das ganze unter Ubuntu 16.04 zu > kompilieren, also brauche ich kein MSYS! Ne,das brauchst Du dann wirklich nicht, Ich dachte dass Du unter Windows arbeitest :-) /regards
Lukas K. schrieb: > Als ganz groben Anhaltspunkt gibt's den Abschmitt "Theory of operation" > in der README, damit sollte man schonmal halbwegs wissen wo vorne ist. Den Teil fand ich (nicht böse gemeint) eher wirr. "Unit" ist sehr ungünstig gewählt, weil man bei CAD als Unit immer an eine Masseinheit denkt (typischerweise gibt es davon ja Mehrere, die der Benutzer nur zum Teil sieht. Anyway. Lt. README wäre die atomare "Unit" ein Gate? Also ist ein Pin (des Gates) was? Und ein Pin(-typ) kann ja auch in mehreren unterschiedlichen "Units" vorkommen. Du verstehst meine Verwunderung? > Doxygen-Dokumentation hatte ich persönlich nie als wirklich hilfreich > empfunden, da darin oft erklärt ist, was auch eine Zeile drunter im Code > steht, aber die grobe Struktur fehlt. Das ist leider SOOOO wahr. Aber man muss solche Fehler ja nicht unbedingt wiederholen^^ > >> Hast Du schon eine Idee wie sich das Projekt weiterentwickeln soll? > Unabhängig von dem Programm selber: > Pool befüllen, dass man auch sinnvolle Schaltpläne und Boards machen > kann. Spricht etwas dagegen einen Eagle/KiCad/Whatever -> Horizon Converter zu basteln? Dann füllt sich das von selbst. > > Kurz/mittelfristige ziele: Ich Deinen Text etwas umsortiert schreib da mal frech meine Gedanken dazwischen :-D > - Platzieren von Bauteilen einfacher machen > Liste von zuletzt benutzten Bauteilen; den Dialog "Select Part" > auch als nicht modales Fenster zur Verfügung stellen. > - Parametrische Suche: Die pool-parametric.db wird schon erzeugt, fehlt > "nur noch" ne hübsche GUI drüber. > - GUI für die constraints. Die als JSON zu bearbeiten und mit UUIDs zu > hantieren macht derzeit gar keinen Spaß. > - "Projekt-Manager", dass man sich nicht mehr die Argumente für > horizon-imp selber ausdenken muss, sondern einfach Klicken kann. Wäre es nicht sinnvoller Horizon erst mal vollständig zum laufen zu kriegen bevor man "Comfortfkt's" einbaut? Z.B.: > - DRC: mit der clipper-Library ist der algorithmisch schwere Teil > (Polygon-Operationen) schon erledigt, fehlt noch die gesamte > Infrastruktur außenrum. > Was behandelt der DRC denn? Clearance & width sind ja die Minimalforderungen. Wenn der Router Necking können soll, dann muss der DRC aber auch Mintracewidth handhaben können, ggf. auch mit Längenbeschränkungen. Ist Dein Router (if any) schon DRC aware (d.h. berücksichtigt er alle DRC Rules)? Ansonsten hast Du da noch eine große Baustelle. Appropos Baustelle: Du schreibst "der Router weicht immerhin schon den meisten Hindernissen aus". Was für einen Router hast Du denn da am Start? (SOWAS habe ich z.B. gesucht) Und finally: ERC? Ich hab nur kurz in die Quellen reingeschaut aber I/O directions bei den Gates ist mir nicht aufgefallen. > Nicht vergessen: Rom wurde auch nicht an einem Tag erbaut (und auch > nicht in einer Nacht) Du hattest doch in diesem Leben nichts anderes mehr vor (hoffe ich)? /regards
Andreas H. schrieb: > Lukas K. schrieb: >> Als ganz groben Anhaltspunkt gibt's den Abschmitt "Theory of operation" >> in der README, damit sollte man schonmal halbwegs wissen wo vorne ist. > > Den Teil fand ich (nicht böse gemeint) eher wirr. > "Unit" ist sehr ungünstig gewählt, weil man bei CAD als Unit immer an > eine Masseinheit denkt (typischerweise gibt es davon ja Mehrere, die der > Benutzer nur zum Teil sieht. > > Anyway. Lt. README wäre die atomare "Unit" ein Gate? Also ist ein Pin > (des Gates) was? Und ein Pin(-typ) kann ja auch in mehreren > unterschiedlichen "Units" vorkommen. > Du verstehst meine Verwunderung? Bei KiCAD gibt's auch "Unit" im sinne von nicht-Maßeinheit. Schlechte Ausrede, aber so ist's nun eben... Ich versuch's nochmal zu erklären, diesmal andersherum: Das logische Bauteil (ohne Gehäuse, etc) ist in einer "Entity" definiert. Eine solche Enity kann mehrere Gates haben (Gatter, Opamps, IO-Bänke, etc). Nun haben mehrere Entities die selben Gates, z.B. Quad- und Doppel-opamp haben beide vier bzw zwei Opamp-Gates. Daher bietet es sich an, die Gates mit ihren Pins nicht innerhalb der Entities zu definieren, sondern extern davon und die Gates diese Definition referenzieren zu lassen. Ebendiese nennt sich dann "Unit". Ich hoffe ich habe damit nicht noch mehr Verwirrung gestiftet... > Spricht etwas dagegen einen Eagle/KiCad/Whatever -> Horizon Converter zu > basteln? > Dann füllt sich das von selbst. Wäre ein doch bedeutender Aufwand, man müsste eben gemeinsame Gates über Bauteile hinweg finden, daraus Units machen, etc. Die Platzierung von Texten ist dann wahrscheinlich vollkommens im Eimer, weil das jeder geringfügig anders macht. Für einzelne Bauteile (große Mikrocontroller z.B.) kann ein solcher Importer durchaus sinnvoll sein. Einen Massenimport ohne Qualitätskontrolle wünsche ich mir allerdings nicht. Auch ist man ohne Importer gezwungen, horizon zu benutzen und gibt dann hoffentlich sinnvolles Feedback, was einen nicht so gefällt... Wenn jemand einen schreibt, der zufriedenstellend funktioniert, habe ich nichts dagegen :) > > Wäre es nicht sinnvoller Horizon erst mal vollständig zum laufen zu > kriegen bevor man "Comfortfkt's" einbaut? Z.B.: Durchaus, alles eine Sache der Prioritäten. > Was behandelt der DRC denn? Clearance & width sind ja die > Minimalforderungen. Wenn der Router Necking können soll, dann muss der > DRC aber auch Mintracewidth handhaben können, ggf. auch mit > Längenbeschränkungen. Genau, das war auch so mein Gedanke. > Ist Dein Router (if any) schon DRC aware (d.h. berücksichtigt er alle > DRC Rules)? Ansonsten hast Du da noch eine große Baustelle. Er legt keine Leiterbahn, so dass der Minimalabstand zu anderen Netzen unterschritten wird, aber schmiegt sich nicht an diese auf DRC-Abstand an. > Appropos Baustelle: Du schreibst "der Router weicht immerhin schon > den meisten Hindernissen aus". > Was für einen Router hast Du denn da am Start? > (SOWAS habe ich z.B. gesucht) Ist recht primitiv: Der routet immer zwei Segmente (eines davon horziontal/vertikal und eines im 45°-Winkel), und versucht durch "umdrehen" der zwei Segmente DRC-Fehler zu vermeiden. Wenn das nicht klappt, bleibt der Track da stehen, wo's als letztes keinen DRC-fehler gab. Nicht vergleichbar mit dem was KiCAD macht, aber immerhin etwas. > Und finally: ERC? Ich hab nur kurz in die Quellen reingeschaut aber I/O > directions bei den Gates ist mir nicht aufgefallen. Die gibt es, allerdings nur in der Datenstruktur: https://github.com/carrotIndustries/horizon/blob/master/pool/unit.hpp#L25 Wenn es DRC gibt, sollte dabei als Nebenprodukt eine Infrastruktur für "Checks" rausfallen, in die man dann auch ERC einhängen können sollte.
Lukas K. schrieb: > Doxygen-Dokumentation hatte ich persönlich nie als wirklich hilfreich > empfunden, da darin oft erklärt ist, was auch eine Zeile drunter im Code > steht, aber die grobe Struktur fehlt. Das habe ich früher auch mal gedacht. Mittlerweile habe ich -- dank der freundlichen Hilfe eines großen Meisters und meiner Erfahrung -- jedoch festgestellt, daß doxygen & Co. hervorragende und nützliche Dokumentation erzeugen können, wenn der Entwickler seinen Code sauber dokumentiert hat. Ganz unabhängig davon, ob Du doxygen oder ähnliche Werkzeuge magst oder nicht: wenn Du andere Entwickler dazu animieren willst, bei Deinem Projekt mitzuhelfen, solltest Du ihnen den Einstieg so einfach wie möglich machen. Und das beginnt nun einmal mit einer ordentlichen Dokumentation. Solche Werkzeuge können einem natürlich nicht die Arbeit abnehmen, seinen Code ordentlich und verständlich zu dokumentieren. Aber wenn man das macht, also: Klassen, Methoden, Variablen und vor allem die Konzepte und Schichten der Software vernünftig dokumentiert, dann können doxygen & Co. daraus eine sehr gute Dokumentation erzeugen. Und mit dieser Dokumentation können dann die vorhandenen und neuen Entwickler viel schneller verstehen, was gemacht wird, wo es gemacht wird, wie es gemacht wird und warum. Klar, so wie Dein Code bisher dokumentiert ist -- nämlich gar nicht, wie ein zugegeben oberflächlicher Blick zeigt -- wird kein Werkzeug der Welt daraus etwas Sinnvolles machen können. Keine Software kann Informationen aus dem Nichts generieren. Nicht einmal doxygen. ;-)
tester schrieb: > Lukas K. schrieb: >> Hm, welcher GCC? Bei mir hier baut's mit GCC 6.3.1 und clang 3.9.1. > > Bei mir der Standard gcc/g++ 5.4 von Ubuntu 16.04. Aber der Patch läuft, > ich konnte part.cpp kompilieren. Jetzt hängt er bei schematic.cpp. > Die Meldung ist dieses Mal etwas länger. Ist als Anhang dabei... Ubuntu im Allgemeinen ist wohl ne mittelgroße Baustelle, da auch in Ubuntu 16.10 nur Gtk 3.20 dabei ist, ich aber Funktionen von Gtk benutze, die es erst seit 3.22 gibt. Nichts was unbedingt notwendig ist, aber die #if GTK_CHECK_VERSION() kommen auch nicht von alleine... Schaut also aus, als liefe horizon derzeit nur auf Arch Linux und Fedora 25. Hoppla.
Baendiger schrieb: > Gibt es gar keine Screenshots? Ich finde auch, dass fehlende Scennshots abschreckend wirken. Wer weiß, was man sich da im Worst-Case-Fall einfängt und nicht alles findet der Virenscanner. Vielleicht lernst der TO noch, sonst kann er sein Projekt gleich begraben.
Cyborg schrieb: > Baendiger schrieb: >> Gibt es gar keine Screenshots? > > Ich finde auch, dass fehlende Scennshots abschreckend wirken. > Wer weiß, was man sich da im Worst-Case-Fall einfängt und nicht > alles findet der Virenscanner. Vielleicht lernst der TO noch, sonst > kann er sein Projekt gleich begraben. EDA Sw für Leute die nicht lesen können wäre bestimmt eine Marktlücke. Der lesekundige Teil der Menschheit wird dann damit abgespeist: https://github.com/carrotIndustries/horizon/tree/master/screenshots /regads
tester schrieb: > Lukas K. schrieb: >> Hm, welcher GCC? Bei mir hier baut's mit GCC 6.3.1 und clang 3.9.1. > > Bei mir der Standard gcc/g++ 5.4 von Ubuntu 16.04. Aber der Patch läuft, > ich konnte part.cpp kompilieren. Jetzt hängt er bei schematic.cpp. > Die Meldung ist dieses Mal etwas länger. Ist als Anhang dabei... War nun doch weniger aufwändig als gedacht: https://github.com/carrotIndustries/horizon/commit/bf16b4bfb8179641f8a21b1eee4dfbbb7cf2a065 Baut nun auf Ubuntu 16.04, der Part-Editor tut auch, ob der interaktive Manipulator funktioniert, konnte ich nicht testen, da meine VM kein OpenGL 3 kann.
Lukas K. schrieb: > Bei KiCAD gibt's auch "Unit" im sinne von nicht-Maßeinheit. Schlechte > Ausrede, aber so ist's nun eben... Genau das. Schlechte Ausrede :-) > > Ich versuch's nochmal zu erklären, diesmal andersherum: > Das logische Bauteil (ohne Gehäuse, etc) ist in einer "Entity" > definiert. Eine solche Enity kann mehrere Gates haben (Gatter, Opamps, > IO-Bänke, etc). > Nun haben mehrere Entities die selben Gates, z.B. Quad- und Doppel-opamp > haben beide vier bzw zwei Opamp-Gates. Daher bietet es sich an, die > Gates mit ihren Pins nicht innerhalb der Entities zu definieren, sondern > extern davon und die Gates diese Definition referenzieren zu lassen. > Ebendiese nennt sich dann "Unit". > > Ich hoffe ich habe damit nicht noch mehr Verwirrung gestiftet... > Nö, leider nicht. Ein "logisches Bauteil" ist doch nur eine Funktion (ggf mit einem Symbol). Den Parametern muss man, genau wie dem Result einen Namen geben (Ports). Die vergibt man pro Funktion (z.B. Q = A & B). Mehr kann man jetzt noch nicht zuordnen. Erst wenn das Ganze in ein Device wandert, dann ist die Art & Anzahl der Funktionen definiert. Und erst jetzt kann (und muss) man den Ports eindeutic Pins zuordnen (Pin == das wo Du Dich raufsetzen und pieksen kannst, zumindest bei z.B. THT Bauteilen). Dann hätten Deine Funktionen endlich unterschiedliche "Namen" für die Pors der jeweiligen Funktionen (Q1 = A1 & B1, Q2 = A2 & B2 usw). Du hast also ZWEI Sachen. Die "Ports" an der "Funktion" und die "Pins" am Gehäuse. Ports haben z.B. elektrische Parameter (z.B In-/Output), Pins eher Mechanische (Fläche, evtl. Drill usw.). Ob es wirklich sinnvoll ist, dem jetzt nochmal "frei gewählte" Bezeichnungen zuzuordnen? Ich sehe da wenig Sinn. >> Spricht etwas dagegen einen Eagle/KiCad/Whatever -> Horizon Converter zu >> basteln? >> Dann füllt sich das von selbst. > > Wäre ein doch bedeutender Aufwand, man müsste eben gemeinsame Gates über > Bauteile hinweg finden, daraus Units machen, etc. Die Platzierung von > Texten ist dann wahrscheinlich vollkommens im Eimer, weil das jeder > geringfügig anders macht. > > Für einzelne Bauteile (große Mikrocontroller z.B.) kann ein solcher > Importer durchaus sinnvoll sein. Einen Massenimport ohne > Qualitätskontrolle wünsche ich mir allerdings nicht. > Checken muss man das sowieso. Ich kenne auch kaum Leute, die die Libs der Tools benutzen, ohne vorher die Bauteile, die sie benutzen, mal geprüft zu haben. Auch EDA Hersteller machen Fehler^^ > Auch ist man ohne Importer gezwungen, horizon zu benutzen und gibt dann > hoffentlich sinnvolles Feedback, was einen nicht so gefällt... Das ist Mutig. Denn niemand ist GEZWUNGEN horizon für irgendetwas zu benutzen. Im Gegenteil. Ich würde meine eigenen Libs ungern nochmal einhacken müssen. >> Was behandelt der DRC denn? Clearance & width sind ja die >> Minimalforderungen. Wenn der Router Necking können soll, dann muss der >> DRC aber auch Mintracewidth handhaben können, ggf. auch mit >> Längenbeschränkungen. > > Genau, das war auch so mein Gedanke. > Ich habe beim Überfliegen auch nirgens irgendwelche Grids gefunden (übersehen?) Man kann ja gridless routen. Aber wenn Du Gridless Placen willst, dann hast Du evtl. interessante Diskussionen mit dem Bestücker (zumindest ältere PicknPlace Automaten hatten da Limits). >> Ist Dein Router (if any) schon DRC aware (d.h. berücksichtigt er alle >> DRC Rules)? Ansonsten hast Du da noch eine große Baustelle. > > Er legt keine Leiterbahn, so dass der Minimalabstand zu anderen Netzen > unterschritten wird, aber schmiegt sich nicht an diese auf DRC-Abstand > an. > Muss er auch nicht unbedingt (Diff-Pairs mal ausgenommen). >> Und finally: ERC? Ich hab nur kurz in die Quellen reingeschaut aber I/O >> directions bei den Gates ist mir nicht aufgefallen. > > Die gibt es, allerdings nur in der Datenstruktur: > https://github.com/carrotIndustries/horizon/blob/master/pool/unit.hpp#L25 > > Wenn es DRC gibt, sollte dabei als Nebenprodukt eine Infrastruktur für > "Checks" rausfallen, in die man dann auch ERC einhängen können sollte. Nö. Das sind zwei (fast) komplett unterschiedliche Baustellen. Ob da zwei Pins geneinander treiben ist dem Router genauso egal, wie die Tatsache, das ein Netz nur Eingänge als Pins hat. Andersherum interessiert es den ERC nicht wenn Du 20A über eine 6mil Leitung jagst oder 20KV mit 10mil clearance routest. /regards
Lukas K. schrieb: > Schaut also aus, als liefe horizon derzeit nur auf Arch Linux und Fedora > 25. Lukas K. schrieb: > konnte ich nicht testen, da meine VM kein > OpenGL 3 kann. Wäre vielleicht sinnvoll, die Anforderungen (compiler, HW) etwas zu reduzieren. Ansonsten fallen viele potentielle Tester schon mal weg, selbst wenn du es Dir antust für diverse OS Packages zu bauen. Spätestens bei Graphikkarten kanns eng werden. KiCad hat z.B. eine ganze Zeit mit einem Problem von WxWidgets mit GTK3 gekämpft. Und da konnte KiCad garnichts dafür. Was spricht denn gegen eine "konservative" Toolchain (bei Linux z.B. Debian Jessie oder RH/CentOs6, bei Windows Win7, bei Mac k.A.^^)? Das Ganze mit AutoConf oder cMake erleichtert auch das Portieren. Auch GTK3 erfreut sich ja anscheinend zunehmender Unbeliebtheit, wenn man so einigen Foren glauben darf. /regards
Hardy F. schrieb: > Also bitte versuche einen fertigen Windows-Build mit dazuzustellen auf > der Seite. Hardy: wenn sich ein Programm selbst noch als „halbfertig“ bezeichnet, dann sind Leute, die es sich nicht selbst compilieren können oder wollen ohnehin keine sinnvollen Alpha-Tester. Falls da wirklich „was abgeht“, dann musst du damit rechnen, dass du das täglich oder aller zwei Tage neu bauen musst, damit du nicht die Bugs nochmal versuchst zu finden, die seither schon beseitigt sind. In dieser Phase kann man sowas einfach nicht durch vorgekochte Builds erschlagen. Ich weiß auch nicht, inwiefern es wirklich Sinn hat, das x-te Programm dieser Art anzufangen, aber das wird die Zeit sicher zeigen. Solange es Lukas erstmal nur aus Spaß an der Freude gemacht hat, ist es doch nur fair, wenn er anderen die Möglichkeit einräumt, es ebenfalls zu testen und ggf. Verbesserungen vorzuschlagen. Aus eigener Erfahrung kann ich natürlich sagen, dass solche Vorschläge am besten die Form eines "diff" annehmen :) (oder bei github wahrscheinlich eines pull requests).
Vielleicht orientiert ihr euch an bereits bestehenden Workflows. Kicad erinnert mich an OrCad und lässt sich so von mir fast intuitiv bedienen. Vielleicht springt ihr in die Bresche und macht nen Adler-Kompatiblen Workflow. Da dürfte dann für viele User der Grund zum Wechsel werden.
Andreas H. schrieb: > Erst wenn das Ganze in ein Device wandert, dann ist die Art & Anzahl der > Funktionen definiert. Da liegt der Hund begraben. In horizon gibt es da noch den Zwischenschritt "Entity". Für die Netzliste ist ein Quad-Nand-Gatter in CMOS-4000er Logik in DIP Gleichwertig mit einem 74HC in (theoretisch BGA). Wenn man sich mitten im Design-Prozess anders entscheidet, ist es problemlos bei einem Component (instantiierte Entity) das Part auszutauschen, ohne dass die Netzliste was davon mitbekommt. Andreas H. schrieb: > Ich habe beim Überfliegen auch nirgens irgendwelche Grids gefunden > (übersehen?) Man kann ja gridless routen. Aber wenn Du Gridless Placen > willst, dann hast Du evtl. interessante Diskussionen mit dem Bestücker > (zumindest ältere PicknPlace Automaten hatten da Limits). Das Raster kommt daher, dass der Cursor auf's grid einschnappt. Andreas H. schrieb: >> Wenn es DRC gibt, sollte dabei als Nebenprodukt eine Infrastruktur für >> "Checks" rausfallen, in die man dann auch ERC einhängen können sollte. > > Nö. Das sind zwei (fast) komplett unterschiedliche Baustellen. Klar, die Implementierung der Checks ist vollständig verschieden, am Ende vom Tag können beide aber die gleiche Infrastruktur zur Konfiguration und Darstellung der Ergebnisse nutzen. Was Toolchains, etc anbetrifft: Mittlerweile baut's ja auf Ubuntu 16.04 und kommt auch mit Gtk 3.18 zurecht. OpenGL 3.2 ist leider Pflicht, da zum Rendern u.A. geometry shader verwendet werden. Mag zwar erstmal unnütz klingen, ist voraussichtlich bei großen Boards von Vorteil. Ist jetzt auch schon über 7 Jahre her, dass das wirklich neu war. Andreas H. schrieb: > Auch GTK3 erfreut sich ja anscheinend zunehmender Unbeliebtheit, wenn > man so einigen Foren glauben darf. War absehbar, dass das kommt ;) Ich persönlich kann das Gejammer nicht nachvollziehen, works for me. Jörg W. schrieb: > Hardy: wenn sich ein Programm selbst noch als „halbfertig“ bezeichnet, > dann sind Leute, die es sich nicht selbst compilieren können oder > wollen ohnehin keine sinnvollen Alpha-Tester. Da ist was wahres dran. Rein technisch sind windows-Builds kein Problem [1], nur erwarten viele Windows-user, dass dann eine Exe rausfällt, auf die sie doppelklicken können und was sinnvolles passiert - so weit ist horizon nun noch nicht. Auch wünsche ich mir, dass von den Anwendern backtraces, etc kommen. "horizon-imp.exe funktioniert nicht mehr" ist da nicht wirklich hilfreich. Auch bräuchte ich für die Windows-Builds sowas wie nen buildbot, denn ich will nicht nach jedem commit meine Windows-VM anwerfen müssen. [1] https://github.com/carrotIndustries/horizon/blob/master/make_bindist.sh
Lukas K. schrieb: > Auch bräuchte ich für die Windows-Builds sowas wie nen buildbot, denn > ich will nicht nach jedem commit meine Windows-VM anwerfen müssen. ich würd jetzt in dieser frühen Phase erstmal primär kein Gewicht auf zeitnahe Windows-Builds (oder andere Exotenplatformen) legen sondern auf das System konzentrieren unter dem auch primär die Entwicklung stattfindet, und da brauchst Du auch keine Binaries zu bauen, das machen die Tester und Mitentwickler eh selbst. Früher oder später wirst Du dann jemanden finden der genug Interesse an Windows hat daß der sich um die Windows-Builds kümmert.
:
Bearbeitet durch User
Bernd K. schrieb: > Früher oder später wirst Du dann jemanden finden der genug Interesse an > Windows hat daß der sich um die Windows-Builds kümmert. Oder man kann sich dann auch wirklich die Infrastruktur selbst mal aufsetzen. Ich habe mittlerweile (bei AVRDUDE) lernen müssen, dass das am Ende schneller geht als zu hoffen, dass sich einer der Windowsianer zu sowas freiwillig hinreißen lässt. :( Das hat dann das Kuriosum, dass dabei Windows-Builds enstehen, die selbst beim Bauen nie ein Windows gesehen haben. :-)
Bernd K. schrieb: > Früher oder später wirst Du dann > jemanden finden der genug Interesse an Windows hat Es ist allerdings fragwürdig, die überwiegende Mehrheit der CAD-Benutzer von vornherein vom Testen auszuschliessen. Aber für Linux-Fanatiker ist das natürlich konsequent. Der grundlegende Irrtum ist wohl, dass man eine abgeschottete Linux-Brüderschaft als "Kunden" sieht, und nicht Leute, die Leiterplatten entwerfen. Muss aber jeder Entwickler selber wissen. Nur nicht später wundern, wenn keiner das Programm benutzt. Georg
Georg schrieb: > Der grundlegende Irrtum ist wohl, dass man eine abgeschottete > Linux-Brüderschaft als "Kunden" sieht, Wieso Linux? Das Ding compiliert ja offenbar unter Windows. Vermutlich bekommt man es auch unter anderen Systemen zum Laufen. Es sind also nicht Windows-Nutzer per se ausgeschlossen, wie du das unterschwellig darstellst. > und nicht Leute, die > Leiterplatten entwerfen. Das ist erstmal völlig unabhängig vom OS: in solch einer frühen Entwicklungsphase wirst du so oder so keine Platinendesigner groß finden, die da ernsthaft gewillt wären mitzuentwickeln. Es wurde ja schon dargelegt, dass „Kunden“, die als Feedback dann lediglich „horizon.exe hat einen Fehler verursacht und wurde beendet“ oder „ich hätte gern Feature XYZ, bevor ich mir das ansehe“ in so einer Entwicklunsphase sowieso nicht zielführend sind. In dieser Phase braucht man Leute, die Bugs nicht nur melden, sondern zumindest analysieren, oder die eben auch mal anfangen, wenigstens über die Implementierung eines Features nachzudenken. Opensource kennt in diesem Sinne erstmal keine „Kunden“, sondern eher „Macher“ (auch wenn dieser Begriff mittlerweile anderweitig verzerrt worden ist). Das ist ein sehr grundlegender Unterschied zu Bezahlsoftware. Übrigens ignorierst du geflissentlich, dass ein großer Teil der CAD-Szene im IC-Design, das ja durchaus mit Platinendesign verwandt ist, historisch auf großen UNIXen und heute nach wie vor massiv auf Linux abläuft. Ist also keineswegs so, dass es da keine Anwender gäbe. Aber das wissen natürlich Leute, die in ihrer abgeschotteten Windows-Brüderschaft herumwerkeln, vermutlich gar nicht (um mal deine Worte zu gebrauchen).
:
Bearbeitet durch Moderator
was ist an Autotrax nicht gut? Nutze selber Target, aber AT sieht gut aus auch die Aufmachung der Seite
Stefan schrieb: > was ist an Autotrax nicht gut? Das sollte ihr bitte in einem eigenen Thread diskutieren. Den hier hat Lukas angefangen, um über horizon zu diskutieren.
das wird noch sowieso nie einer benutzen also völlig wertlos
Stefan schrieb: > das wird noch sowieso nie einer benutzen also völlig wertlos Also ich mache als Hobby auch viele Dinge die niemand benutzt. Beim Hobby ist der Weg das Ziel. Solange es Spaß macht spricht nichts dagegen.
Wer sich ins Abenteuer stürzen will, und auf Windows bauen möchte: https://github.com/carrotIndustries/horizon/blob/master/build_win32.md
Lukas K. schrieb: > Wer sich ins Abenteuer stürzen will.. Nun ja, so ganz im Prinzip ist es allemal lobenswert, wenn jemand anfängt, sich mit so einem Projekt eine Mühe zu geben. Aber wer soll sich da zusätzlich ins Abenteuer stürzen? Eigentlich müßte man mMn so ein Projekt völlig anders angehen, nämlich mit einem Dokument, PDF oder LibreOffice oder so, wo die Grundprinzipien entwickelt und dargestellt sind. Dort gehört also hinein, wie das ganze Programm von seiner ineren Logik her funktionieren soll, wie die Daten gehalten werden sollen, wie das Userinterface funktionieren soll, also wie man mit dem Programm später umgehen kann. So etwas ist tausendmal wichtiger als sofort in die Tasten zu hauen. Es ist aber nötig vor jeglichen Programmieranstrengungen - zum einen damit man selber sowie eventuelle Mitarbeiter wissen, wie das Ganze zusammenspielen soll und zum anderen, damit interessierte Anwender ihre Sicht auf die Dinge einbringen können. Sonst wird das Ganze mal wieder ein Ding, das nur aus Sicht der Programmierer konstruiert wurde und an den tatsächlichen Bedürfnissen der Benutzer vorbeigeht. Man mag sowas ein Pflichtenheft nennen, ich würde das zunächst nur ein Papier zur Ideen-konsolidierung nennen. Wenn sich das dann entwickelt, kommen interne Schnittstellen-Definitionen hinzu, damit verschiedene Leute an verschiedenen Teilen arbeiten können ohne sich gegenseitig zu hakeln. Aber so, wie es vorliegt? Wer soll sich da hineinknien, um mühselig herauszufinden, wie hier was funktionieren soll? Nee, ich selber bin da außen vor, ich mache nix in cpp, sondern allenfalls mit Delphi oder Lazarus. Aber die Wahl einer Programmiersprache oder einer Toolchain ist mMn zweitrangig. Zuerst geht es um den tatsächlichen Systementwurf - und den vermisse ich hier. W.S.
Lukas K. schrieb: > Andreas H. schrieb: >> Erst wenn das Ganze in ein Device wandert, dann ist die Art & Anzahl der >> Funktionen definiert. > > Da liegt der Hund begraben. In horizon gibt es da noch den > Zwischenschritt "Entity". Für die Netzliste ist ein Quad-Nand-Gatter in > CMOS-4000er Logik in DIP Gleichwertig mit einem 74HC in (theoretisch > BGA). Wenn man sich mitten im Design-Prozess anders entscheidet, ist es > problemlos bei einem Component (instantiierte Entity) das Part > auszutauschen, ohne dass die Netzliste was davon mitbekommt. Was bringt das? Eine Netzliste ist doch on-the-fly erzeugt und ändert sich während des Schematic entrys laufend (bei Backanotation ja auch noch). Der Sinn will sich mir nicht erschliessen, sry. Ich sehe da z.Z. nur potentielle Fehlerquellen. > > Andreas H. schrieb: >> Ich habe beim Überfliegen auch nirgens irgendwelche Grids gefunden >> (übersehen?) Man kann ja gridless routen. Aber wenn Du Gridless Placen >> willst, dann hast Du evtl. interessante Diskussionen mit dem Bestücker >> (zumindest ältere PicknPlace Automaten hatten da Limits). > Das Raster kommt daher, dass der Cursor auf's grid einschnappt. > Das Raster IST das Grid. Und das ist ja nicht nur dort wo der Cursor ist. Ich entnehme Deiner Aussage mal, dass es mindestens ein Grid gibt :-) > Andreas H. schrieb: >>> Wenn es DRC gibt, sollte dabei als Nebenprodukt eine Infrastruktur für >>> "Checks" rausfallen, in die man dann auch ERC einhängen können sollte. >> >> Nö. Das sind zwei (fast) komplett unterschiedliche Baustellen. > Klar, die Implementierung der Checks ist vollständig verschieden, am > Ende vom Tag können beide aber die gleiche Infrastruktur zur > Konfiguration und Darstellung der Ergebnisse nutzen. Never. DRC geht auf geometische Daten, dem ERC reicht eine "annotierte" Netzliste (annotiert meint hier, das die Pins noch die "Direction" Attribute brauchen). Ansonsten könntest Du keinen ERC machen, bevor das Layout steht^ (Ok, theoretisch könntest Du Parasitics aus dem Layout extrahieren & prüfen. Aber das ist eine GAAANZ andere Geschichte.) >> Auch GTK3 erfreut sich ja anscheinend zunehmender Unbeliebtheit, wenn >> man so einigen Foren glauben darf. > > War absehbar, dass das kommt ;) Ich persönlich kann das Gejammer nicht > nachvollziehen, works for me. Nimm was Dir Spass macht. Aber wenn es nachher nur bei 30% der Leute läuft dann macht es auch wenig Sinn, oder? Und einen kleinen Vorgeschmack hast Du ja gestern schon bei tester mitbekommen. Das Ganze dann *100^^ /regards
Georg schrieb: > Der grundlegende Irrtum ist wohl, dass man eine abgeschottete > Linux-Brüderschaft als "Kunden" sieht, und nicht Leute, die > Leiterplatten entwerfen. DEIN grundlegender Irrtum ist, dass OSS Entwickler soviel Zeit haben, dass sie neben der Weiterentwicklung auch noch Unmengen an Hilferufen bearbeiten können. Das wird meist noch nerviger wenn die "Kunden", wie Du sie nennst, meist nicht mal vernünftige Fehler-/Environmentbeschreibungen liefern. Und das findest Du bei Linux/Windows/Mac "Kunden" gleichermassen.
W.S. schrieb: > Eigentlich müßte man mMn so ein Projekt völlig anders angehen, nämlich > mit einem Dokument, PDF oder LibreOffice oder so, wo die Grundprinzipien > entwickelt und dargestellt sind. Im Prinzip schon. Aber das kann man auch im Forum diskutieren. Gerade am Anfang fliessen dann auch Erfahrungn von Anderen ein ohne das erst mal viel "Papier" gemacht wird. Mir würde es auch nur bedingt Spass machen, erst mal eine komplette Spec zu schreiben (das V-Modell nervt auf Arbeit schon genug). > Aber so, wie es vorliegt? Wer soll sich da hineinknien, um mühselig > herauszufinden, wie hier was funktionieren soll? Da gibts aber einige Hinweise auf der Projektseite. /regards P.S: W.S. schrieb: > Nee, ich selber bin da außen vor, ich mache nix in cpp, sondern > allenfalls mit Delphi oder Lazarus. Ich leiste mir meist nicht den Luxus mich auf eine Programmiersprache festzubeissen. Aber bei Lazarus wäre ich dabei (Delphi geht ja leider nur unter Windows). Dann wäre man z.B. schon einen Großteil des "Buildwahns" los.
Lukas K. schrieb: > OpenGL 3.2 ist leider Pflicht Tja, das ist z.Zt. das Problem. Nach dem letzet git pull ist die Compilierung durchgelaufen, danke dafür. Aber starten kann ich es nicht: xxxxx@HPi7:~/src/horizon$ ./horizon-imp -c sch.json block.json constr.json (horizon-imp:5550): GLib-GObject-CRITICAL **: g_value_take_object: assertion 'G_IS_OBJECT (v_object)' failed horizon-imp: Couldn't find current GLX or EGL context. Mein X.org Server scheint nur OpenGL 3.0 zu haben: xxxxx@HPi7:~/src/horizon$ glmark2 ======================================================= glmark2 2014.03+git20150611.fa71af2d ======================================================= OpenGL Information GL_VENDOR: X.Org GL_RENDERER: Gallium 0.4 on AMD TURKS (DRM 2.43.0, LLVM 3.8.0) GL_VERSION: 3.0 Mesa 11.2.0 ======================================================= Hm... eingebaut ist eine Radeon HD6570, die sollte das eigentlich können. Nach https://wiki.ubuntuusers.de/Grafikkarten/AMD/radeon/ sogar OpenGL4.1, aber mindestens OpenGL3.3. Mal sehen...
Also, prüfst du irgendwo im Quelltext die OpenGL Version? Die
Grafikkarte sollte Shader 3.3 können, der Treiber scheint aber nach
außen hin
nur die 3.0 zu melden. Den Error-String "Couldn't find current GLX or
EGL context" habe ich im Quelltext nicht gefunden, um die Stelle zu
lokalisieren...
xxxxx@HPi7:~/src/horizon$ glxinfo | grep version
#server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
Max core profile version: 3.3
Max compat profile version: 3.0
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.0
OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.2.0
OpenGL core profile shading language version string: 3.30
OpenGL version string: 3.0 Mesa 11.2.0
OpenGL shading language version string: 1.30
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 11.2.0
OpenGL ES profile shading language version string: OpenGL ES GLSL ES
3.00
Fehler hatte wohl doch nichts mit OpenGL zu tun. Aus
imp/main_window.cpp:
[...] x->add_from_resource("/net/carrotIndustries/horizon/window.ui");
Wie viele hardcodierte Pfade sind denn da drin?
xxxxx@HPi7:~/src/horizon$ grep -r -i "/net/carrotIndustries/horizon" |
wc
36 151 4173
Ok, habe jetzt mal einen Symlink angelegt. Recht viel weiter komme ich leider nicht: xxxxx@HPi7:/net/carrotIndustries/horizon$ ./horizon-imp -c sch.json block.json constr.json terminate called after throwing an instance of 'Gio::ResourceError' Abgebrochen (Speicherabzug geschrieben) Gut für heute...
Das OpenGL-Problem sollte nun behoben sein, hatte mal wieder mit älteren Gtk-versionen zu tun: https://github.com/carrotIndustries/horizon/commit/3df57bea51b54b41e15d4d45c9bf844e2c1c8469 Die Pfade da sind keine Pfade im engeren Sinne: https://developer.gnome.org/gio/stable/GResource.html Mit den "resources" können Dateien, die das Programm zur Laufzeit benötigt mit in die Binary gebacken werden.
Andreas H. schrieb: > Aber das kann man auch im Forum diskutieren. Im Prinzip - ja. Aber so ganz blank - ohne wenigstens ein Anfangspapier? Nee. geht nicht. Du siehst ja an den Beiträgen kurz unter deinem, was da losgeht. Ärger mit OpenGL ist doch eigentlich etwas, das so unendlich lowlevel ist, daß es die eigentliche Funktionalität garnicht berührt. Also MUSS man eine Trennung einziehen zwischen der CAD-Funktionalität und solch niederen Dingen wie Betriebssystem, GraKa und so weiter - versteh das richtig: es ist beides vonnöten, aber es muß strikt auseinander gehalten werden. Womit wir wieder beim Papier mit der Grundsatzrede (a la Honecker.. oder lieber nicht) sind. Es hat wirklich keinen Zweck, draufloszucoden, solange kein "Honecker"-Papier existiert, das wenigstens einigermaßen ausdiskutiert ist. Beruflich kenne ich das so, daß im Gremium ein Papier im Word-Format existiert, wo reihum jeder seinen Senf reinschreibt - und das wird dann beim nächsten Treffen diskutiert. Dann geht die nächste Runde los.. eben so lange, bis alle abgenickt haben. W.S.
W.S. schrieb: > das wird dann > beim nächsten Treffen diskutiert. Dann geht die nächste Runde los.. eben > so lange, bis alle abgenickt haben. Da hast du die Zeichen der Zeit nicht erkannt - in Zukunft zählt nur noch die Methode Trump, Abweichler werden sofort standrechtlich erschossen und technische Fragen werden durch alternative Fakten gelöst. Im Ernst, Konsens ist sowas von gestrig. Georg
Lukas K. schrieb: > mein Elektronik-CAD-Programm endlich halbwegs > vorzeigbar: Hallo Lukas! Ja was soll ich sagen? Zunächst sollte ich Dir wohl mal meine Anerkennung aussprechen -- Du bist einer der wenigen hier, die mal etwas zustande bringen, statt immer nur rumzumosern. Du kennst ja sicher meinen Schaltplaneditor, den ich vor einigen Jahren mal in Ruby programmiert hatte (http://ssalewski.de/PetEd.html.en), und auch meinen Toporouter(http://ssalewski.de/Router.html.en). Da war das Interesse ja praktisch null. Oder den Schaltplaneditor, den hier jemand vor etwa einem jahr in Jawa präsentiert hatte -- auch null Interesse. Aber du wirst wohl eh nicht erwarten, dass sich jemand an Deinem Projekt beteiligt. Was mich doch etwas wundert: Wenn Du schon in C++ programmieren magst, warum hast Du dann nicht gleich Qt verwendet? Die Kombination ist doch eigentlich ganz gut. Und GTK ist ja momentan extrem unbeliebt bei Anwendern. Manch mal denke ich, dass ich der Einzige bin, der es noch verwendet. Community ist ja auch so gut wie tod. Aber gut, einige wenige arbeiten im stillen Kämmerlein wohl doch noch an GTK4, vielleicht wird GTK dann wieder populärer. Es soll ja immerhin ein Vulkan Backend geben! Und wenn schon GTK, dann hätte man ja auch eine moderne und schönere Sprache nehmen können. Language Bindings gibt es ja reichlich, vom mir für GTK3, aber auch für Rust oder Crystal hatte ich welche gesehen. Oder aber, man hätte das ganze eher Web-basiert aufziehen können -- davon schwärmen ja einige (ich selber weniger). Also Java-Script, HTLM5 oder so. Tablet Support. Du hast OpenCL verwendet -- alle Achtung, dass hatte ich mir damals nicht zugetraut. Aber Cairo ist eigentlich auch noch schnell genug -- na ja gerade so. Ja ich werde mir Dein Projekt wahrscheinlich mal ansehen. Falls Du es tatsächlich fortführst, künnte ich ja drüber nachdenken, Dein Dateiformat zu übernehmen. Momentan verwende ich das gEDA Format, aber das gEDA Projekt ist ja wohl auch recht tod. Allerdings, wenn ich irgendwann mal daran weiterarbeite, werde ich von Ruby wohl auf Nim umsteigen. Abernatürlich gibt es genügend andere interessante Aufgaben.
Angehängte Dateien:
Stefan S. schrieb: > Ja was soll ich sagen? Zunächst sollte ich Dir wohl mal meine > Anerkennung aussprechen -- Du bist einer der wenigen hier, die mal etwas > zustande bringen, statt immer nur rumzumosern. Freut mich sehr auch mal das zu lesen :) In gewisser maßen kann man horizon als "opinionated software" bezeichnen. Horizon ist die Materialisierung eines EDA-Programms, so wie ich es mit meiner Erfahrung für richtig und sinnvoll erachte. Dass das andere Leute nicht so sehen, ist dann eben so. Allen kann man's eh nie recht machen. Stefan S. schrieb: > Du kennst ja sicher meinen Schaltplaneditor, den ich vor einigen Jahren > mal in Ruby programmiert hatte (http://ssalewski.de/PetEd.html.en), und > auch meinen Toporouter(http://ssalewski.de/Router.html.en). Da war das > Interesse ja praktisch null. Leider nicht, aber in der Tat scheint das Interesse der Leute hier an nicht-mainstream EDA-Tools im allgemeinen eher gering zu sein. Vor einiger Zeit hatte ich hier mal (keine Ahnung warum im Forum "Markt") auf PCB elegance aufmerksam gemacht: Beitrag "PCB Elegance" Hat genau niemanden interessiert. Ähnlich mit librepcb: Beitrag "librepcb Free Schematic und PCB Editor Erfahrungen Leistungsvergleich" Auf das Projekt wurde ich auch erst zufällig auf dem 33C3 aufmerksam. Stefan S. schrieb: > Was mich doch etwas wundert: Wenn Du schon in C++ programmieren magst, > warum hast Du dann nicht gleich Qt verwendet? Historisch gewachsen. Ich hatte schon seit ca. 5 Jahren GUIs mit Gtk programmiert, praktisch nur mit Python und hab hab damit sehr gute Erfahrungen gemacht. Horizon hatte ursprünglich als eine Kombination von C und python angefangen, wurd' mir dann irgendwann zu doof und ich hab' dann C genommen. Das ging gut, bis ich UUIDs durch GObject schieben wollte und mir der GObject-Krams zu umständlich erschien. Dann hatte ich mir mal C++ und Gtkmm angesehen und die Kombination für perfekt befunden. Mit Qt hatte ich noch nie wirklich was am Hut, hatte aber auch nie das Gefühl, dass mir als Entwickler was bei Gtkmm fehlt. Vielleicht auch eine Mischung aus Vendor-Lockin und Stockholm-Syndrom... Die Gtk-Entwickler sind im IRC und in bugreports auch durchaus hilfreich, kann mich diesbezüglich nicht beschweren. Persönlich gefallen mir auch die Client-Side decorations von Gtk nach anfänglicher Skepsis gut, als Beispiel der Footprint-Generator aus horizon im Anhang. Stefan S. schrieb: > Language Bindings gibt es ja reichlich, vom mir > für GTK3, aber auch für Rust oder Crystal hatte ich welche gesehen. C++ mag zwar ein wenig altbacken wirken, aber mit C++ hat man noch die größte Chance Leute zu finden die das auch können. Außerdem ist die Nutzerbasis von Gtk-Bindings zu z.B. Rust nochmal geringer, als die von Gtkmm. >Oder > aber, man hätte das ganze eher Web-basiert aufziehen können -- davon > schwärmen ja einige (ich selber weniger). Also Java-Script, HTLM5 oder > so. Tablet Support. Bloß nicht. Die Frameworks im Web-bereich haben eine gefühlte Haltbarkeitszeit von 3 Monaten, danach ist schon wieder das nächste hip. Gtk und C++ sind da deutlich gemächlicher. Stefan S. schrieb: > Du hast OpenCL verwendet -- alle Achtung, dass hatte ich mir damals > nicht zugetraut. Aber Cairo ist eigentlich auch noch schnell genug -- na > ja gerade so. Eben. OpenGL war mehr so nen Angstreflex, dass später auch mal größere Boards halbwegs schnell rendern. Auch dreht die GPU eh größtenteils Däumchen, warum die nicht mit Malen vom Grid, Linien mit runden Enden und schraffierten Dreiecken beauftragen? Schaden kann's ja nicht und das OpenGL-programmieren mit shadern und so macht auch Spaß.
Lukas K. schrieb: > aber in der Tat scheint das Interesse der Leute hier an > nicht-mainstream EDA-Tools im allgemeinen eher gering zu sein. Stefan S. schrieb: > Du kennst ja sicher meinen Schaltplaneditor, den ich vor einigen Jahren > mal in Ruby programmiert hatte (http://ssalewski.de/PetEd.html.en), und > auch meinen Toporouter(http://ssalewski.de/Router.html.en). Da war das > Interesse ja praktisch null. Oder den Schaltplaneditor, den hier jemand > vor etwa einem jahr in Jawa präsentiert hatte -- auch null Interesse. Ihr solltet mal eure Scheukappen bei Seite schieben und mal überlegen warum das so ist. Euer Wissen, das ja anscheinend vorhanden ist, könnte man sicherlich 'gewinnbringender' an den Mann bringen.
il Conte schrieb: > Ihr solltet mal eure Scheukappen bei Seite schieben und mal überlegen > warum das so ist. ... wenn die Fähigkeit, das Programmieren zu beherrschen, nur mit Gleichgesinnten geteilt wird, dann darf man sich nicht beklagen, wenn die "Übriggebliebenen" sich leider mangels ebendieser Fähigkeiten abwenden... Wenn man jemandem etwas hinstellt, mit dem er nicht umgehen kann, wird er sich damit nicht beschäftigen.
Lukas K. schrieb: > Leider nicht, aber in der Tat scheint das Interesse der Leute hier an > nicht-mainstream EDA-Tools im allgemeinen eher gering zu sein. Vor > einiger Zeit hatte ich hier mal (keine Ahnung warum im Forum "Markt") > auf PCB elegance aufmerksam gemacht: > Beitrag "PCB Elegance" Hat genau niemanden > interessiert. Doch. Nur ist ein EDA-Tool einfach nur dazu da seine Schaltung mit einer Leiterplatte zu verheiraten. Es muß schon einen Grund geben sein bisher verwendetes Tool ersetzen zu wollen, da die Einarbeitung bis man mit was Neuem produktiv arbeiten kann ganz schön lange dauert. Und Leute die wirklich gut programmieren können und richtig gut Entwickeln/Entflechten können sind wirklich rar.
Michael X. schrieb: > Und Leute die wirklich gut programmieren können und richtig gut > Entwickeln/Entflechten können sind wirklich rar. Wobei ich die Idee des Toporouters schon mal nett fände. Weiß ja nicht, inwiefern man den vielleicht auch mit KiCad verheiraten könnte? Ist aber 'ne andere Baustelle, hier geht's um horizon. Auch, wenn ich selbst keine Ressourcen frei habe, finde ich die Diskussion darum allemal interessant und werde hier weiter mitlesen.
Michael X. schrieb: > Es muß schon einen Grund geben sein bisher > verwendetes Tool ersetzen zu wollen, da die Einarbeitung bis man mit was > Neuem produktiv arbeiten kann ganz schön lange dauert. Das ist nur ein Teil des Problems, wichtiger ist meist die Tatsache, dass zahlreiche, u.U. hunderte fertige Layouts existieren, die weiter gepflegt werden müssen. Für Elektronik-Firmen ist CAD-Layout eine strategische Software, die die Existenz der Firma beeinflussen kann. Es kann schon zur Katastophe werden, wenn die BWLer entscheiden, dass die Entwickler plötzlich mit anderer Software arbeiten müssen. Es ist also vernünftig, bei solchen Fragen sehr konservativ zu sein. Georg
Georg schrieb: > Das ist nur ein Teil des Problems, wichtiger ist meist die Tatsache, > dass zahlreiche, u.U. hunderte fertige Layouts existieren, die weiter > gepflegt werden müssen. Kein großes Argument: die Benutzung einer neuen Software zwingt doch keinen dazu, die alte deswegen gleich zu verschrotten. Aber Georg, für derartige Entscheidungsfragen ist es bei horizon ganz gewiss zu früh, ich schätze mal wenigstens 5 Jahre zu früh. Das ist jetzt keine Missachtung von Lukas' Leistung, aber er nennt es ja selbst „halbfertig“. Erst müsste es also mal fertig werden, und dann noch so interessant für Platinendesigner werden, dass sie überhaupt drüber nachdenken, sich in eine weitere Software einzuarbeiten. Wenn Lukas ein wenig eher damit fertig geworden wäre, hätte er jetzt vielleicht ein paar angep***ste Adler-Nutzer als willige Betatester haben können, aber dazu hätte horizon erstmal Beta-Charakter haben müssen. So weit ist es wohl noch nicht.
Jörg W. schrieb: > Wenn Lukas ein wenig eher damit fertig geworden wäre, hätte er jetzt > vielleicht ein paar angep***ste Adler-Nutzer als willige Betatester > haben können, aber dazu hätte horizon erstmal Beta-Charakter haben > müssen. So weit ist es wohl noch nicht. Was Du da schreibst gilt aber eher für kommerzielle Software, und ich glaube nicht, dass Lukas ersthaft hofft, sein Programm mal teuer verkaufen zu können. Bei EDA-CAD wäre gerade in der frühen Phase, wenn etwa 30 % fertig sind, die Mitwirkung anderer sinnvoll und hilfreich -- etwa durch gut durchdachte Vorschläge, Problemlösungen, oder womöglich sogar durch Programmcode. Wenn alles schon fast fertig ist, dann kann man nicht mehr viel ändern, und es bleibt im wesentlichen nur das Mosern. Aber die breite Masse postet heute eben lieber Fotos von ihrem Mittagessen auf Fakebook, sucht Pokemons oder guckt Videos. Und das ist auch völlig OK.
Stefan S. schrieb: > Aber die breite Masse postet heute eben lieber Fotos von ihrem > Mittagessen auf Fakebook, sucht Pokemons oder guckt Videos. Jetzt erinnerst du an Sokrates. > Bei EDA-CAD wäre gerade in der frühen Phase, wenn etwa 30 % fertig sind, > die Mitwirkung anderer sinnvoll und hilfreich Nur, dass du in dieser Phase eben noch niemanden da bekommen wirst, der das wenigstens halbwegs produktiv benutzen will. Diese Leute hatte ich als Eagle-Umsteiger im Blick, von denen es gerade ein paar mehr geben dürfte als zuvor.
Entwickeln und "produktiv benutzen" sind bei einem größeren Softwareprojekt schon sehr verschiedene Sachen. In der Anfangsphase kann man Ideen und Problemlösungen einbringen, die Software damit aktiv mitgestalten und womöglich Freude daran haben. Produktiv nutzen kann man so ein Programm in dieser Phase aber eher nicht, schon gar nicht wenn man wirklich Platinen herstellen lässt und auf deren Funktionsfähigkeit angewiesen ist. Später, wenn das Programm weitgehend fertig ist, kann man es hoffentlich produktiv nutzen, aber dann wird man sich auf Fehlerberichte beschränken und hoffen das sie irgendwann behoben werden. Letzteres hatte ich lange Jahre bei gEDA beobachtet -- fast alle neuen Ideen oder größeren Erweiterungen wurden von einigen Altusern abgelehnt, und selbst ohne diese Ablehnung wäre es für Neulinge schwer diese ohne Hilfe der ursprünglichen Entwickler zu implementieren.
Ach Lukas, was mir gerade noch einfällt... Wie machst Du das mit der Textausgabe in den Gerber-Dateien? Am Bildschirm hat man ja zunächst hochwertige Fonts, etwa Truetype oder was auch immer, bei mir wäre das Pango-Rendering. Gerber hat ja aber keine wirklichen Fonts, man muss also alles durch Linien und Kreisbögen darstellen. gEDA/PCB verwendet auch am Bildschirm primitive Fonts, die aus Kreisbögen und Linien bestehen, darunter leidet aber die Darstellungsqualität. Mein Ansatz wäre gewesen, zunächst echte Fonts zu verwenden und die dann in Linien/Kreisbögen für Gerber zu wandeln. Und noch eine andere Bemerkung: Wenn ich ein C++ Freund wäre, hätte ich womoglich auf Qucs mit Qt aufgebaut -- da hätte man Schaltplan- und Simulation schon mal, und müsste dann nur noch den Platinenteil machen. Hast Du schon über Simulations-Anbindung nachgedacht? Dein Git-Reposity werde ich mir demnächst ansehen, ich bin mir eigentlich sicher dass es sich lohnt, blos momentan ist die Zeit etwas knapp...
Stefan Salewski schrieb: > Mein Ansatz wäre gewesen, zunächst echte Fonts zu verwenden und die dann > in Linien/Kreisbögen für Gerber zu wandeln. Den Vorteil dieses Ansatzes sehe ich darin, dass man schon alles für den Bildschirm fix & fertig hat und dass die Geschwindigkeit dafür optimiert ist. Der Nachteil ist, dass man eine deutlich höhere Genauigkeit vorgegaukelt bekommt, als sich am Ende erzielen lässt. Man neigt meiner Erfahrung nach dann dazu, viel zu kleine Schriften zu benutzen.
Ja, das ist richtig. Ergänzung: Vielleicht möchte man ja auf der Platine chinesische oder kyrillische Schrift haben. Deshalb denke ich, dass man tatsächlich die Wandlung von einer echten hochwertigen Unicode-Schrift am Bildschirm zu Linien/Bögen auf Gerber machen sollte. Vielleicht kennt ja jemand eine Bibliothek die so etwas schon gut macht? Ist extended Gerber eigentlich immer noch "State of the Art"? Vor ca. 5 Jahren war das noch so, ich glaube ich hatte dazu sogar hier mal gefragt. Neueres weiß ich dazu aber nicht, aber ich errinnere mich dunkel, dass es zwei "modernere" Alternativ-Formate gab.
Stefan Salewski schrieb: > aber ich errinnere mich > dunkel, dass es zwei "modernere" Alternativ-Formate gab Modern muss nicht besser heissen. ODB++ löst zwar manche Probleme, andere aber nicht, auch weil sie garnicht lösbar sind - es gibt nun mal keine Norm für Lagenbezeichnungen, das macht jeder wie er will, und neben üblichen wie "Top" oder "Bestückungsseite" gibt es ungefähr so viele wie Layouter. Ausserdem, was heisst bei einer heutigen Schaltung überhaupt "BS" oder "Oben"? Und ist die Lage 1 die obere oder die erste innen?? Folglich muss der CAD-Mann beim Hersteller selber interpretieren, welche Datei im Layerstack wohin gehört, genau wie bei Gerber auch, das ist die Hauptarbeit den ganzen Tag über. Dazu ist ODB++ eine traditioneller Unix-Albtraum, für jedes Objekt wird eine eigene Datei in einem bestimmten Verzeichnis angelegt, so dass ein Layout mit ODB++ leicht aus tausend kleinen Dateien besteht, selbstverständlich ohne Dateiendung, von denen auch unzählige den gleichen Dateinamen haben, reisst das mal auseinander, sind alle Daten verloren. Aber du kannst dich ja mal im Netz über ODB++ einlesen. Georg
Stefan Salewski schrieb: > Ist extended Gerber eigentlich immer noch "State of the Art"? An sich schon, es gibt aber eine neuere Spec von Ucamco, die sich Gerber X2 nennt.
Sehe ich das richtig das ich zum Testen erst ein mal das Zeug compillieren muss?
So schaut es wohl aus. Das dürfte wohl die beste Abschreckung sein.
@Stefan Salewski Kannst du den Toporouter Algorithmus beschreiben, so dass man ihn in C nachbauen kann?
Hallo Stefan. Stefan Salewski schrieb: > Ergänzung: Vielleicht möchte man ja auf der Platine chinesische oder > kyrillische Schrift haben. Deshalb denke ich, dass man tatsächlich die > Wandlung von einer echten hochwertigen Unicode-Schrift am Bildschirm zu > Linien/Bögen auf Gerber machen sollte. Vielleicht kennt ja jemand eine > Bibliothek die so etwas schon gut macht? Schau mal nach dem Cenon Projekt. Die bearbeiten allgemein Vektor Formate und darunter auch SVG und Gerber. Die könnten passende Bibliotheken entwickelt haben. http://www.cenon.info > Ist extended Gerber eigentlich immer noch "State of the Art"? Grundsätzlich ja. Es gibt zwar mittlerweile ein "X2", aber das ist voll rückwärtskompatibel zu extended Gerber. Die einzige Ergänzung sind "Attribute" Desweiteren taucht bei vielen Gerber Elementen in der Ucamco Dokumentation der Hinweis auf, dass sie nach Möglichkeit nicht mehr verwendet werden sollen. Damit soll Gerber weiter vereinfacht werden. Trozdem bleiben sie bestehen, damit auf diesen Unterlagen basierende Gerber Software immer noch mit alten Daten umgehen kann. FAQ zu Gerber X2: https://www.ucamco.com/files/downloads/file/131/the_gerber_file_format_version_2_faq_de.pdf?ffadb605ad51e2ab5d87820700d9d26c Die z.Z. aktuelle Spezifikation von Gerber X2 Revision 2016.12 ist hier: https://www.ucamco.com/files/downloads/file/81/the_gerber_file_format_specification.pdf?cb3475a30bcf27121f13b2f307f8231b > Vor ca. 5 > Jahren war das noch so, ich glaube ich hatte dazu sogar hier mal > gefragt. Neueres weiß ich dazu aber nicht, aber ich errinnere mich > dunkel, dass es zwei "modernere" Alternativ-Formate gab. Ja, OBD++ und IPC-2581. Ersteres ist aber nicht offen, und zweiteres nur halb, was für Austauschformate ein "No-Go" ist. Desweiteren sind auf XML basierende Verfahren wie IPC-2581 schon wieder deutlich komplizierter als Gerber. Gerber schlägt halt so leicht keiner. Und wenn ich mir unbedingt eine Alternative ausdenken müsste, würde ich z.B. eher zu einer Art Lisp Notation greifen. ;O) http://www.mikrocontroller.net/articles/Gerber-Tools#Alternativen_zu_Gerber Mit freundlichem Gruß: Bernd Wiebus alias dl1eic
Hallo C lover. C lover schrieb: > @Stefan Salewski > Kannst du den Toporouter Algorithmus beschreiben, > so dass man ihn in C nachbauen kann? Bis er soweit ist, hast Du hier was Lesefutter: https://pdfs.semanticscholar.org/1003/57a8a958587baca5b930ce9a6d439c11970d.pdf https://pdfs.semanticscholar.org/91ce/7726d0b103db47ab5db433ed75b538e6e7f8.pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.49.8349&rep=rep1&type=pdf Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
C lover schrieb: > @Stefan Salewski > Kannst du den Toporouter Algorithmus beschreiben, > so dass man ihn in C nachbauen kann? Besser wohl in C++, weil CGAL benutzt wird, aber mit etwas Mühe geht es sicher auch in C. Du guckst am Besten zunächst mal kurz in die zugrunde liegende Doktorarbeit, zumindest in die ersten Kapitel. Constrained-Delaunay-Triangulation und Appolonius Graph von CGAL. Und der Rest ist eben der Ruby Code, der sollte mit minimalen Ruby-Kenntnissen lesbar sein und ist eigentlich schon die vollständige Dokumentation, mehr braucht man wirklich nicht. Ich glaube es waren rund 2k lines of code Ruby, alles recht einfach. Gut bis auf das Sortieren der Bahnen von innen nach aussen, das ist so als ob man solche Aussteckformen für Kuchenteig sortiert, so dass sie ineinander passen. Da habe ich mir wirklich einen abgebrochen, mein räumliches Vorstellungsvermögen ist wohl nicht so gut. Mit C wird es natürlich etwas mehr Code, die Doktorarbeit sprach von 14k, aber die hatten wohl auch nicht CGAL als Grundlage. Übrigens, wenn ich das gleich von Anfang an in C probiert hätte, hätte ich das nie in annehmbarer Zeit hinbekommen. Aber jetzt die Übertragung von Ruby nach C sollte schon möglich sein. Die Frage wäre ob man es gleich komplett portiert, oder in Teilen. Weiss ich nicht. Nach Nim würde ich es komplett Portieren, ich kenne mich mit Ruby und Nim etwas aus, da ist das keine große Sache. Blos ich müsste die Bindings für Nim zu CGAL machen, auch keine große Sache, aber ich habe keine Lust momentan. Das sparst Du Dir mit C oder C++. Noch eine Warnung: Der Toporouter verträgt sich ganz schlecht mit bereits manuell gerouteten Bahnen. Das war der Haupt-Kritikpunkt der gEDA-Leute. Deshabl macht es auch nicht viel Sinn den Router als externes Programm einzusetzten, man müsste ihn schon in ein PCB-Programm einbinden, so dass man dann interaktiv Bauteile verschieben kann, so dass der Router alles fertig bekommt. Ein paar weitere Gedanken mag man auf der gEDA Mailingliste im Archiv finden, ich habe viele Details schon wieder etwas vergessen und errinnere mich gerade so Stück für Stück wieder...
Hallo Georg. Georg schrieb: > Es ist allerdings fragwürdig, die überwiegende Mehrheit der CAD-Benutzer > von vornherein vom Testen auszuschliessen. Aber für Linux-Fanatiker ist > das natürlich konsequent. Der Grund, dafür Linux zu nehmen ist wohl eher der, dass sich dort leichter etwas entwickeln lässt. Und in dem Stadium können das eigentlich auch nur Leute testen, die weit genug wären, selber daran zu programmieren. > > Der grundlegende Irrtum ist wohl, dass man eine abgeschottete > Linux-Brüderschaft als "Kunden" sieht, und nicht Leute, die > Leiterplatten entwerfen. Muss aber jeder Entwickler selber wissen. Nur > nicht später wundern, wenn keiner das Programm benutzt. Wer open source macht, hat in dem Sinne keine "Kunden". Und bei open source Nutzern sind viele mit Linux Kenntnissen. ;O) Und bei ser viel kommerzieller Software sehe ich, dass als "Kunde" der Entscheider betrachtet wird, der das Zeug kauft, und nicht der, der damit umgehen muss. ;O) Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Bernd W. schrieb: > Lesefutter Die erste Arbeit kannte ich gar nicht. Aber das entscheidende Werk ist die Arbeit von Tal Dayan von 1997. Übrigens, ich habe nicht wirklich alles verstanden, insbesondere nicht wie das Ripup and Retry funktionieren könnte. Übrigens, einen alternativen Toporouter gab es ja in gEDA/PCB, war als Google Summer als Code Project um 2008 gemacht, gleich in C. Hat Ansatzweise funktioniert, hat aber niemand verstanden, und der Autor war dann schnell wieder weg. Der Code ist wohl noch in gEDA/PCB, soll aber entfernt werden, da damit niemend zurecht kommt.
Der entscheidende Teil damit ein neues Layoutprogramm überhaupt angenommen wird ist garantiert nicht der Autorouter egal ob das Ding Topo, Gridless, "Freestyle" oder sonstwas heißt bzw. kann. Mir scheint, dass die Programmierer lieber so einen Autorouter schreiben da man da viel weniger Schnittstellen zur Außenwelt hat und sich nicht mit den Wünschen der Anwender auseinandersetzen muss. Viel wichtiger sind die folgenden Punkte die leicht erlernbar und bedienbar sein müssen. Schaltplansymbole erstellen; Bibliotheken Schaltplaneingabe Bauteile für das Layout aufsetzen (pads, drills, ...); Bibliotheken Bauteile platzieren Verdrahten: Leitungen ziehen, schieben abknicken, 45°; Flächen zeichnen, Flächen füllen; online DRC,.... Gerber Ausgabe
Bernd W. schrieb: > Und bei ser viel kommerzieller Software sehe ich, dass als "Kunde" der > Entscheider betrachtet wird, der das Zeug kauft Aber das ist doch auch genau richtig - ich habe es schon erlebt, dass die Entwickler sich vollkommen eindeutig nach sorgfältiger Evaluation für eine bestimmte Software entschieden haben, aber eine ganz andere gekauft wurde, weil die Geschäftsführer mit den Managern des Herstellers zusammen Golf spielten. Das war in dem speziellen Fall nicht nur sowieso eine Katastrophe, sondern die Software wurde im folgenden Jahr eingestellt und so waren einige Millionen in den Sand gesetzt. Aber egal was man davon hält, man muss sich danach richten, wie beim Kunden die Entscheidungen getroffen werden, auch wenn das absurd oder auch völlig korrupt ist. Dem Ingenieur kann man nichts verkaufen. Georg
Helmut S. schrieb: > Mir scheint, > dass die Programmierer lieber so einen Autorouter schreiben da man da > viel weniger Schnittstellen zur Außenwelt hat und sich nicht mit den > Wünschen der Anwender auseinandersetzen muss. Ja sicher. Man macht halt das, womit man seinen Lebensunterhalt verdient, oder das, was interessant ist und was man sich noch halbwegs zutraut. Nur selten fällt beides zusammen. Manchmal macht man auch öde Dinge unentgeltlich, weil man denkt dass sie für die Allgemeinheit nützlich sind oder Leute danach fragen -- aber letzteres trifft auf den EDA-Bereich weniger zu, Eagle oder KiCad ist den meisten gut genug.
Ja, ich würde es in ein bestehendes PCB Programm einfügen, programmiert in C++, 82% ist aber C mit gplv2 Lizenz, nur v2, keine v2+ .
Hallo Georg. Georg schrieb: >> Und bei ser viel kommerzieller Software sehe ich, dass als "Kunde" der >> Entscheider betrachtet wird, der das Zeug kauft, und nicht der, der >> damit umgehen muss. ;O) > Aber das ist doch auch genau richtig - ~~~~ ~~~ ~~ ~ > Aber egal was man davon hält, man muss sich danach richten, wie beim > Kunden die Entscheidungen getroffen werden, auch wenn das absurd oder > auch völlig korrupt ist. Eben. Und open Source hat in dem Sinne halt keine "Kunden". Ser viel open Source wird aus Spass geschrieben, weil man es mal endlich so machen möchte, wie man es selber für richtig hält, oder open Source wird aus Verzweiflung und mit einem "dicken Hals" geschrieben, weil man sich über den gekauften Kram geärgert hat oder man einfach nichts passendes findet. Letzteres kann durchaus der Fall sein, wenn die Anwendung so speziell ist, das kein Markt existiert. Das kommt öfter vor als man denkt. Letztendlich ist man damit selber sein eigener "Kunde" und Entscheider. ;O) Und aus allen den Gründen ist die Funktionalität von kommerzieller Software nur sehr bedingt ein Masstab für open Source, auch wenn vieles halt ähnlich ist. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
:
Bearbeitet durch User
Helmut S. schrieb: > Mir scheint, > dass die Programmierer lieber so einen Autorouter schreiben da man da > viel weniger Schnittstellen zur Außenwelt hat und sich nicht mit den > Wünschen der Anwender auseinandersetzen muss. Was soll diese Bemerkung denn eigentlich im Kontext dieses Threads bedeuten? Hier geht's um "horizon", und dafür ist dein Kommentar wohl völlig daneben. Das kümmert sich just um die Dinge, die du da genannt hast, zumindest bereits zu einem großen Teil (und nennt sich ja selbst nur „halbfertig“). Der Topo-Router würde mich als externe Engine für ein KiCad wohl schon interessieren, da könnte einem auch die Programmiersprache egal sein – aber das gehört dann nicht mehr in diesen Thread. BTT: habe mir mal einen GCC 5.x installiert und versucht, das Teil auf meinem FreeBSD zu compilieren. Allerdings kommen da nicht nur Warnungen, sondern an vielen Stellen noch Fehlermeldungen des Compilers. Meine C++-Kenntnisse sind vermutlich nicht gut genug um einzuschätzen, ob dabei das eigentliche Problem in meiner Umgebung zu suchen ist oder im Code von "horizon". Lukas, wenn es dich interessiert, kann ich das Buildlog mal hochladen. Ein Beispiel, welches ich jetzt schon mehrmals gesehen habe:
1 | ./json.hpp:10455:51: error: 'to_string' is not a member of 'std' |
2 | {"path", path + "/" + std::to_string(i)},
|
> Was soll diese Bemerkung denn eigentlich im Kontext dieses Threads
bedeuten? Hier geht's um "horizon", und dafür ist dein Kommentar
wohl völlig daneben.
Der Thread gleitet hier im Moment in Richtung Autorouter. Hier geht es
aber nicht um einen Autorouter sonder um Horizon, ein neues
Layout-Programm. Da ist der Autorouter nur ein kleiner Teil davon und
der wird erst interessant, wenn alles andere fertig ist und Anhänger
gefunden hat. Macht doch einen Extra-Thread auf mit dem Thema ich
schreibe einen Autorouter.
Jörg W. schrieb: > BTT: habe mir mal einen GCC 5.x installiert und versucht, das Teil auf > meinem FreeBSD zu compilieren. Allerdings kommen da nicht nur > Warnungen, sondern an vielen Stellen noch Fehlermeldungen des Compilers. > Meine C++-Kenntnisse sind vermutlich nicht gut genug um einzuschätzen, > ob dabei das eigentliche Problem in meiner Umgebung zu suchen ist oder > im Code von "horizon". > > Ein Beispiel, welches ich jetzt schon mehrmals gesehen habe: > >
1 | > ./json.hpp:10455:51: error: 'to_string' is not a member of 'std' |
2 | > {"path", path + "/" + std::to_string(i)},
|
3 | > |
Eigentlich gehört die Funktion to_string() seit C++11 zum Namensraum std: http://de.cppreference.com/w/cpp/string/basic_string/to_string Da das Makefile allerdings "-std=c++14" vorgibt, ist der Fehler zumindest etwas merkwürdig. Wie sieht denn der Compileraufruf vor dem Fehler aus?
Ohne jetzt die einzelnen Leute zu zitieren: Als Font nehme ich die Hershey-Fonts: http://paulbourke.net/dataformats/hershey/ Da sind durchaus auch nicht-ASCII Zeichen drin, nur sind die älter als Unicode, d.h. man muss die Zuordnung von Codepoint zu index manuell machen: https://github.com/carrotIndustries/horizon/blob/master/canvas/text.cpp#L242 Truetype-Fonts mache ich aus von Jörg angesprochenen Gründen nicht. Autorouter sind gleichauf mit Simulation "out of scope" für mich, stehen also auf keinerlei (imaginären) Roadmap. Bevor man an sowas überhaupt denkt, braucht man wichtigere Dinge wie, ERC, DRC oder mehr GUI. Bauen auf Freebsd: Man hat mir gesagt, dass das mit der libc++ von FreeBSD zusammenhängt. Probier mal http://stackoverflow.com/questions/35869206/freebsd-error-to-string-is-not-a-member-of-std Wenn's das repariert, bau ich das so in die Makefile ein.
Lukas K. schrieb: > Als Font nehme ich die Hershey-Fonts: Das ist ein interessanter Kompromiss! Ich vermute mal, für den übrigen Text, der nicht auf der Leiterplatte erscheinen wird, benutzt Du einen echten Font? DRC hast Du also noch nicht? Für Liniensegmente ist das ja wohl noch einfach, aber ich wüsste so spontan nicht, wie man das für Kreisbögen effizient macht, insbesondere wenn die Bogensegmente auch noch unter einem beliebigen Winkel gedreht sind.
Stefan Salewski schrieb: > Lukas K. schrieb: >> Als Font nehme ich die Hershey-Fonts: > > Das ist ein interessanter Kompromiss! > > Ich vermute mal, für den übrigen Text, der nicht auf der Leiterplatte > erscheinen wird, benutzt Du einen echten Font? Nein. Truetype=Fonts machen unter Umständen Probleme bei der Skalierung und sind schwerer zu rendern. Und so unansehnlich sind die Hershey-Fonts nun auch nicht. > DRC hast Du also noch nicht? Für Liniensegmente ist das ja wohl noch > einfach, aber ich wüsste so spontan nicht, wie man das für Kreisbögen > effizient macht, insbesondere wenn die Bogensegmente auch noch unter > einem beliebigen Winkel gedreht sind. Bögen hab' ich derzeit nicht. Für Polygon-Operationen (online-drc) verwende ich http://www.angusj.com/delphi/clipper.php. Eigentlich ist DRC ganz einfach: Alles Kupfer auf einem Layer einsammeln, nach Netzen gruppieren, das zu testende Netz um die Clearance expandieren und mit den übrigen Netzen schneiden. Der ganze algorithmisch schwere teil ist schon in clipper gelöst.
Sheeva P. schrieb: > Eigentlich gehört die Funktion to_string() seit C++11 zum Namensraum > std: > > http://de.cppreference.com/w/cpp/string/basic_string/to_string > > Da das Makefile allerdings "-std=c++14" vorgibt, ist der Fehler > zumindest etwas merkwürdig. Wie sieht denn der Compileraufruf vor dem > Fehler aus?
1 | g++5 -c -I. -Iblock -Iboard -Icommon -Iimp -Ipackage -Ipool -Ischematic -Iutil -Iconstraints -g3 -D_USE_MATH_DEFINES -fdata-sections -ffunction-sections -I/usr/local/include -I/usr/local/include/uuid -I/usr/local/include/gtkmm-3.0 -I/usr/local/lib/gtkmm-3.0/include -I/usr/local/include/atkmm-1.6 -I/usr/local/include/atk-1.0 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/glibmm-2.4 -I/usr/local/lib/glibmm-2.4/include -I/usr/local/include/sigc++-2.0 -I/usr/local/lib/sigc++-2.0/include -I/usr/local/include/giomm-2.4 -I/usr/local/lib/giomm-2.4/include -I/usr/local/include/pangomm-1.4 -I/usr/local/lib/pangomm-1.4/include -I/usr/local/include/cairomm-1.0 -I/usr/local/lib/cairomm-1.0/include -I/usr/local/include/cairo -I/usr/local/include/pixman-1 -I/usr/local/include/freetype2 -I/usr/local/include/freetype2 -I/usr/local/include/libdrm -I/usr/local/include/libpng16 -I/usr/local/include/pango-1.0 -I/usr/local/include/harfbuzz -I/usr/local/include/gtk-3.0 -I/usr/local/include/gdk-pixbuf-2.0 -I/usr/local/include/gio-unix-2.0/ -I/usr/local/include/at-spi2-atk/2.0 -I/usr/local/include/at-spi-2.0 -I/usr/local/include/dbus-1.0 -I/usr/local/include/dbus-1.0/include -I/usr/local/include/gtk-3.0/unix-print -I/usr/local/include/gdkmm-3.0 -I/usr/local/lib/gdkmm-3.0/include -I/usr/local/include/librsvg-2.0 -pthread -D_THREAD_SAFE -MP -MMD -pthread -Wall -Wshadow -std=c++14 pool/unit.cpp -o pool/unit.o |
2 | In file included from pool/unit.cpp:3:0: |
3 | ./json.hpp: In member function 'nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::value_type& nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::at(nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::size_type)': |
4 | ./json.hpp:3163:58: error: 'to_string' is not a member of 'std' |
5 | throw std::out_of_range("array index " + std::to_string(idx) + " is out of range");
|
6 | ^ |
7 | ./json.hpp: In member function 'const value_type& nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::at(nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::size_type) const': |
8 | ./json.hpp:3206:58: error: 'to_string' is not a member of 'std' |
9 | throw std::out_of_range("array index " + std::to_string(idx) + " is out of range");
|
10 | ^ |
11 | ./json.hpp: In member function 'void nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::erase(nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::size_type)': |
12 | ./json.hpp:4176:58: error: 'to_string' is not a member of 'std' |
13 | throw std::out_of_range("array index " + std::to_string(idx) + " is out of range");
|
14 | ^ |
15 | ./json.hpp: In member function 'nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::string_t nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::iteration_proxy<IteratorType>::iteration_proxy_internal::key() const': |
16 | ./json.hpp:6649:32: error: 'to_string' is not a member of 'std' |
17 | return std::to_string(array_index); |
18 | ^ |
19 | ./json.hpp: In member function 'long double nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::lexer::str_to_float_t(long double*, char**) const': |
20 | ./json.hpp:8820:20: error: 'strtold' is not a member of 'std' |
21 | return std::strtold(reinterpret_cast<typename string_t::const_pointer>(m_start), endptr); |
22 | ^ |
23 | ./json.hpp:8820:20: note: suggested alternative: |
24 | In file included from /usr/local/lib/gcc5/include/c++/cstdlib:72:0, |
25 | from /usr/local/include/boost/assert.hpp:83, |
26 | from /usr/local/include/boost/smart_ptr/shared_ptr.hpp:29, |
27 | from /usr/local/include/boost/shared_ptr.hpp:17, |
28 | from /usr/local/include/yaml-cpp/node/ptr.h:11, |
29 | from /usr/local/include/yaml-cpp/node/node.h:17, |
30 | from /usr/local/include/yaml-cpp/yaml.h:16, |
31 | from pool/unit.hpp:5, |
32 | from pool/unit.cpp:1: |
33 | /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd10.0/5.3.0/include-fixed/stdlib.h:127:3: note: 'strtold' |
34 | strtold(const char * __restrict, char ** __restrict); |
35 | ^ |
36 | In file included from pool/unit.cpp:3:0: |
37 | ./json.hpp: In member function 'float nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::lexer::str_to_float_t(float*, char**) const': |
38 | ./json.hpp:8860:20: error: 'strtof' is not a member of 'std' |
39 | return std::strtof(reinterpret_cast<typename string_t::const_pointer>(m_start), endptr); |
40 | ^ |
41 | ./json.hpp:8860:20: note: suggested alternative: |
42 | In file included from /usr/local/lib/gcc5/include/c++/cstdlib:72:0, |
43 | from /usr/local/include/boost/assert.hpp:83, |
44 | from /usr/local/include/boost/smart_ptr/shared_ptr.hpp:29, |
45 | from /usr/local/include/boost/shared_ptr.hpp:17, |
46 | from /usr/local/include/yaml-cpp/node/ptr.h:11, |
47 | from /usr/local/include/yaml-cpp/node/node.h:17, |
48 | from /usr/local/include/yaml-cpp/yaml.h:16, |
49 | from pool/unit.hpp:5, |
50 | from pool/unit.cpp:1: |
51 | /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd10.0/5.3.0/include-fixed/stdlib.h:124:8: note: 'strtof' |
52 | float strtof(const char * __restrict, char ** __restrict); |
53 | ^ |
54 | In file included from pool/unit.cpp:3:0: |
55 | ./json.hpp: In member function 'nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::value_type& nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::json_pointer::get_and_create(nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::reference) const': |
56 | ./json.hpp:9419:77: error: 'stoi' is not a member of 'std' |
57 | result = &result->operator[](static_cast<size_type>(std::stoi(reference_token))); |
58 | ^ |
59 | ./json.hpp: In member function 'nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::value_type& nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::json_pointer::get_unchecked(nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::pointer) const': |
60 | ./json.hpp:9511:75: error: 'stoi' is not a member of 'std' |
61 | ptr = &ptr->operator[](static_cast<size_type>(std::stoi(reference_token))); |
62 | ^ |
63 | ./json.hpp: In member function 'nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::value_type& nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::json_pointer::get_checked(nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::pointer) const': |
64 | ./json.hpp:9545:53: error: 'to_string' is not a member of 'std' |
65 | std::to_string(ptr->m_value.array->size()) + |
66 | ^ |
67 | ./json.hpp:9556:63: error: 'stoi' is not a member of 'std' |
68 | ptr = &ptr->at(static_cast<size_type>(std::stoi(reference_token))); |
69 | ^ |
70 | ./json.hpp: In member function 'const value_type& nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::json_pointer::get_unchecked(nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::const_pointer) const': |
71 | ./json.hpp:9597:53: error: 'to_string' is not a member of 'std' |
72 | std::to_string(ptr->m_value.array->size()) + |
73 | ^ |
74 | ./json.hpp:9608:71: error: 'stoi' is not a member of 'std' |
75 | ptr = &ptr->operator[](static_cast<size_type>(std::stoi(reference_token))); |
76 | ^ |
77 | ./json.hpp: In member function 'const value_type& nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::json_pointer::get_checked(nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::const_pointer) const': |
78 | ./json.hpp:9641:53: error: 'to_string' is not a member of 'std' |
79 | std::to_string(ptr->m_value.array->size()) + |
80 | ^ |
81 | ./json.hpp:9652:63: error: 'stoi' is not a member of 'std' |
82 | ptr = &ptr->at(static_cast<size_type>(std::stoi(reference_token))); |
83 | ^ |
84 | ./json.hpp: In static member function 'static void nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::json_pointer::flatten(const string&, const nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>&, nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>&)': |
85 | ./json.hpp:9799:62: error: 'to_string' is not a member of 'std' |
86 | flatten(reference_string + "/" + std::to_string(i), |
87 | ^ |
88 | ./json.hpp: In lambda function: |
89 | ./json.hpp:10178:46: error: 'stoi' is not a member of 'std' |
90 | const auto idx = std::stoi(last_path); |
91 | ^ |
92 | ./json.hpp:10182:74: error: 'to_string' is not a member of 'std' |
93 | throw std::out_of_range("array index " + std::to_string(idx) + " is out of range");
|
94 | ^ |
95 | ./json.hpp: In lambda function: |
96 | ./json.hpp:10226:53: error: 'stoi' is not a member of 'std' |
97 | parent.erase(static_cast<size_type>(std::stoi(last_path))); |
98 | ^ |
99 | ./json.hpp: In static member function 'static nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType> nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::diff(const nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>&, const nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>&, const string&)': |
100 | ./json.hpp:10427:82: error: 'to_string' is not a member of 'std' |
101 | auto temp_diff = diff(source[i], target[i], path + "/" + std::to_string(i)); |
102 | ^ |
103 | ./json.hpp:10444:51: error: 'to_string' is not a member of 'std' |
104 | {"path", path + "/" + std::to_string(i)}
|
105 | ^ |
106 | ./json.hpp:10455:51: error: 'to_string' is not a member of 'std' |
107 | {"path", path + "/" + std::to_string(i)},
|
108 | ^ |
Das wäre der erste Fehler, bei dem "make" anhält. Bei "make -k" rennt er zwar insgesamt weiter, stolpert aber immer wieder über sowas.
:
Bearbeitet durch Moderator
Eigentlich gehört das Thema in die Programmiererecke verschoben. So richtig sehe ich hier nichts mehr von "Platinen".....
Hardy F. schrieb: > Eigentlich gehört das Thema in die Programmiererecke verschoben. Man könnte es auch nach "Projekte & Code" schieben. Gibt es Meinungen, wo es sinnvoller wäre?
Jörg W. schrieb: > Man könnte es auch nach "Projekte & Code" schieben. Das wollte ich auch schon anmerken. Nachdem ich diesen Thread zum ersten mal gesehen hatte, hatte ich ein paar Tage später Probleme ihn zu finden, ich hatte mir schon gedacht, Lukas hätte ihn ob blöder Kommentare wieder gelöscht! Übrigens, den Thread mit dem Java Schaltplaneditor kann ich auch nicht wieder finden, muss gut ein jahr her sein. An den Namen des Tools kann ich mich nicht errinnern. Eigentlich müsste man solche Projekte im Wiki sammeln!
Stefan Salewski schrieb: > Eigentlich müsste man solche Projekte im Wiki sammeln! Es gibt doch einen Artikel Schaltplaneditoren. Da spräche doch nichts dagegen, am Ende eine Liste mit Links auf entsprechende Threads einzufügen. Edit: Habe mit einem Link auf diesen Thread begonnen. Wer noch weitere Threads kennt, möge sie einfach einfügen.
:
Bearbeitet durch Moderator
Sheeva P. schrieb: > Eigentlich gehört die Funktion to_string() seit C++11 zum Namensraum > std: OK, nachdem ich das hier ergugelt habe: http://www.bsdforen.de/threads/problem-gcc-and-std-to_string.31386/ sieht es mir mittlerweile einfach so aus, als wäre GCC völlig glibc-zentrisch geworden. Die vielen _GLIBCXX_VISIBILITY() in den vom GCC installierten Headern weisen auch alle in diese Richtung. Daher habe ich mir clang 3.8 installiert und benutzt. Nun kommen wenigstens keine Trivialitäten mehr als Fehler raus. Anbei das Buildlog eines "gmake -k". Es sind eine ganze Reihe davon dabei:
1 | In file included from util/uuid.hpp:8: |
2 | In file included from /usr/include/c++/v1/iostream:38: |
3 | In file included from /usr/include/c++/v1/ios:216: |
4 | In file included from /usr/include/c++/v1/__locale:15: |
5 | In file included from /usr/include/c++/v1/string:439: |
6 | In file included from /usr/include/c++/v1/algorithm:626: |
7 | /usr/include/c++/v1/utility:294:15: error: no viable overloaded '=' |
8 | first = __p.first; |
9 | ~~~~~ ^ ~~~~~~~~~ |
Da sind Verweise auf die FreeBSD-Headers drin, möglicherweise sind diese zu alt? Vielleicht ließe sich aber auch ein Workaround finden? Es gibt aber auch eine Reihe anderer Dinge, die mir schon Probleme in horizon zu sein scheinen. Vielleicht will Lukas ja mal einen Blick reinwerfen. Kann mir vorstellen, dass ein clang unter Linux die genauso anmeckern würde.
Diese Fehler kommen Wohl daher, dass einige der in der map gespeicherten Felder const sind. Unabhängig davon braucht horizon mindestens Gtkmm 3.18. Aus unerfindlichen Gründen ist Gtk 3.18 zwar in den Freebsd-ports, Gtkmm aber nur in 3.16...
Ich habe das Java-Tool dann doch noch mit google gefunden: Beitrag "HobbyCi Schaltplan Entwicklungsprogramm" Ist doch schon zwei Jahre her, und war wohl, wie ich bereits vermutet hatte, eher ein Osterferienprojekt. Aber wer mag kann es ja auch im Wiki eintragen.
Lukas K. schrieb: > Diese Fehler kommen Wohl daher, dass einige der in der map gespeicherten > Felder const sind. Siehst du da eine Abhilfe? > Unabhängig davon braucht horizon mindestens Gtkmm 3.18. Aus > unerfindlichen Gründen ist Gtk 3.18 zwar in den Freebsd-ports, Gtkmm > aber nur in 3.16... Der Port wird vom gnome-Team bei FreeBSD gepflegt. Ich kann mir vorstellen, dass man da mit Upgrades vorsichtig ist, um nicht das gesamte Gnome komplett nachziehen zu müssen. Da ich Gnome nicht als Desktop-Umgebung benutze, riskiere ich nicht sehr viel, wenn ich mal einen Upgrade von gtkmm versuche. Edit: naja, man hätte es sich denken können:
1 | Package dependency requirement 'giomm-2.4 >= 2.46.1' could not be satisfied. |
2 | Package 'giomm-2.4' has version '2.44.0', required version is '>= 2.46.1' |
3 | Package dependency requirement 'pangomm-1.4 >= 2.38.1' could not be satisfied. |
4 | Package 'pangomm-1.4' has version '2.36.0', required version is '>= 2.38.1' |
5 | Package dependency requirement 'cairomm-1.0 >= 1.12.0' could not be satisfied. |
6 | Package 'cairomm-1.0' has version '1.10.0', required version is '>= 1.12.0' |
Das zöge dann eine größere Update-Orgie nach sich, da habe ich gerade nicht die Zeit dafür. Eventuell kann ich das mal in einem Jail probieren (lightweight VM).
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Siehst du da eine Abhilfe? Die Felder nicht-const machen. Tut der Anwendung als solcher keinen Abbruch, ist aber unschön.
Michael B. schrieb: > AutoTrax macht beispielsweise eigentlich alles richtig, schönes > Programm, alles möglich dabei, nicht zu teuer. Und bekommt trotzdem seit > 10 Jahren keinen Fuss an den Boden. > > https://dexpcb.com/ Hmm. Download kostenlos ... alles außer Gerber Export ... Kompatibel mit Windows (Liste von Windows-Versionen) Das ist die komischste Variante von "macht beispielsweise eigentlich alles richtig" die ich seit langem gesehen habe. Wenn ich bereit wäre, für EDA auf Windows zurück zu gehen, dann hätte ich aber ganz andere Auswahl. Will ich aber gar nicht. Genauso wenig, wie ich die Postkutsche als Alternative zum ICE in Betracht ziehe ... Ach so, zurück zum Thema ... OpenGL zwingend für ein EDA? GTK und & Freunde in einer "blutige Kante" Version? Nein, danke. Wirklich. Ich brauche meine Kiste hier zum arbeiten. Sind die bleeding edge features von GTK & Co wirklich notwendig? Kann ich mir irgendwie nicht so recht vorstellen. Und andererseits ist mein Leidensdruck gar nicht mal besonders hoch. pcb funktioniert prima für meine Bedürfnisse. Versteh mich recht: ich bin Neuem gegenüber eigentlich recht aufgeschlossen. Aber das Problem ist nicht so sehr ein Mangel an EDA-Systemen, als vielmehr die Unzahl an (selbstredend zueinander inkompatiblen) Nischenlösungen. Ein weiteres Produkt in einer weiteren Nische erscheint mir daher wenig verlockend.
Axel S. schrieb: > OpenGL zwingend für ein EDA? Ist bei KiCad am Ende auch so. Naja, man kann dort auch den Cairo-Renderer noch nehmen, aber der ist langsamer. Ich stecke da nicht drin, aber OpenGL scheint außer 3D eben auch im 2D-Bereich einige Nettigkeiten gegenüber Standard-X11 zu bieten zu haben (shading und dergleichen). > GTK und & Freunde in einer "blutige Kante" > Version? Vielleicht könnte Lukas ja hier ein bisschen erzählen, was seine Motivation ist. Aber: das ist ja im Moment (bezüglich der Anwender) noch reiner Entwicklungs-Vorlauf. Dahingehend finde ich es nicht grundsätzlich daneben, mit vergleichsweise „moderner Technik“ ins Rennen zu gehen, denn man kann getrost davon ausgehen, dass das in zwei, drei Jahren dann bei den potenziellen Anwendern in der Tat Standard sein wird. CAD/EDA macht man ja nun seit jeher nicht gerade auf der letzten Kiste, die gerade noch irgendwo in der Ecke zu finden ist.
Gibt es auch eine downloadbare ausführbare Datei für Win und Linux? Ich will nicht anfangen zu compilieren, nur um es zu testen!
Alex W. schrieb: > Gibt es auch eine downloadbare ausführbare Datei für Win und Linux? Ich > will nicht anfangen zu compilieren, nur um es zu testen! Geduld, mein lieber. Ich bin gerade am Projekt-Manager, wenn der halbwegs fertig ist, gibt es auch eine Executable auf die man doppelklicken kann und was sinnvolles geschieht. Für Windows sollt's dann sogar für 'ne mit NSIS zusammengeklickte setup.exe reichen. Binaries für Linux gibt's von mir nicht, da solche unüblich sind und eh immer gegen die falschen Bibliotheken linken. Git pull und make sollten nun für den durchschnittlichen Linux-user auch keine schwarze Magie sein... Betreffend OpenGL und Gtk: Kicad verwendet im Gegensatz zu horizon die veraltete OpenGL API mit glBegin/glEnd. Funktioniert zwar überall, wird dies auch auf absehbare Zeit tun, aber ist eben obsolet und wird auch von Gtk nicht unterstützt. OpenGL in Version 3 haben wir nun auch schon seit über 5 Jahren, wird Zeit, dass das auch eingesetzt wird. Bleeding edge wär's wenn ich Vulkan verlangen würde... Warum nicht auf der CPU mit cairo oder so malen? In jedem Computer steckt eine Grafikkarte die genau für so Dinge wie Polygone malen, etc da ist. Wär' ja schade, wenn die sich langweilt. Gtk 3.18 gibt's auch schon seit über einem Jahr, auch nicht mehr bleeding edge. Wie auch schon von Jörg angesprochen, horizon ist ein Projekt für die Zukunft, insofern ist es nur richtig mit nicht-obsoleter Technik anzufangen. Warum Gtk und nicht Qt? (alles andere muss nicht wirklich sein) Mir gefällt die Art, wie die Entwickler von Gtk (und Gnome) über UI-Schemata von Windows 95 hinausdenken und dabei einen gelungene Kombination aus Konzepten aus dem Mobile- und Desktop-Umfeld finden. Mag nicht jedermanns Geschmack sein, ich mag's.
Mag sein. Das stört Lukas aber nicht, und es ist sein Projekt. Wer bleeding edge haben will (und das ist sein Projekt), sollte sich daran nicht stören. Es verbietet übrigens m.W. niemand, .deb- oder .rpm-Packages zu bauen und zur Verfügung zu stellen. Nein, ich tue es nicht, keine Zeit.
Lukas K. schrieb: > Git pull und make sollten > nun für den durchschnittlichen Linux-user auch keine schwarze Magie > sein... Als Softwareentwickler sollte ich dem eigentlich nur zustimmen können. Aber es ist eben nicht nur "git pull" und dann einfach "make" in das Terminal kloppen. Man muss schon wissen was man tut wenn es Probleme gibt. Meine Frau würde ich als "durschnittlichen" Linux-user bezeichnen. Sie hat Linux gute 10 Jahre als Anwender benutzt (sie hat es sogar selbstständig ohne mein Wissen installiert). Ein Tutorial für einen trivialen Build-Prozess hätte sie auch ohne Probleme durchgearbeitet bekommen. Aber sobald da Abhängigkeiten dazu kommen, die man installieren muss, und wissen muss, dass Gtk1 != Gtk2 != Gtk3 != Qt begibt man sich als "durchschnittlicher" doch schnell aufs Glatteis. Und wenn dann noch ein Compiler-Fehler dazu kommt, und man mangels Verständnis rätselraten muss woher das Problem wohl kommen mag, dann ist auch dem letzten 0815-Anwender die Laune vergangen. Unter Anleitung ist das alles kein Problem, aber wenn man sonst niemanden hat den man direkt fragen kann und der die Zeit hat sich mit einem hinzusetzen, ist das alles nix. Als fortgeschrittener Softwareentwickler überschätzt man meist auch seine Kollegen. Ich seh doch schon wie meine Kollegen auf Arbeit von weitergehenden Funktionalitäten von SVN (Also bspw. mal das Tortoise-Diff-Tool aufrufen, oder ein Tag setzen, oder ein Update auf eine spezifische Revision machen) überfordert sind. Das betrifft nicht nur meine 50+ Kollegen, sondern auch den einen frischen Uni-Abgänger. Das ist breit gestreut, viele unserer FH/Uni-Praktikanten sind extrem fähig. Die kennen sich zum Teil auch bestens mit Github aus und können sich fix in neues einarbeiten. Ist aber alles meiner Erfahrung nach sehr individuell und breit gestreut.
:
Bearbeitet durch User
Lukas K. schrieb: > Binaries für Linux gibt's von mir nicht, da solche unüblich sind und eh > immer gegen die falschen Bibliotheken linken. Git pull und make sollten > nun für den durchschnittlichen Linux-user auch keine schwarze Magie > sein... Völlig korrekt. Bin ganz deiner Meinung. Ich finde es bei Linux grade so gut dass es da nicht überall Binaries gibt sondern man immer selber bauen kann.
Zwei Hinweise: a) sollte -Wall enabled sein, das ist lobenswerterweise im Makefile der Fall. Ich würde aber ruhig noch -Werror dazusetzen. b) check den Source mal mit CppCheck. Da kommen Tonnen von Warnungen. Idealerweise sollte da gar nichts kommen, und bei den Dingen, die wirklich so gehören, sollte in der Projektdokumentation (später!) begründet werden, wieso diese Warnungen trotzdem OK sind. c) das sind eine Menge an Abhängigkeiten von verschiedenen Autoren. Das wird noch viel Arbeit mit Build, Troubleshooting und Wartung werden, wenn es mehr als "auf meinem Rechner läuft's ja" werden soll. Da sollte man sich frühzeitig Gedanken um die Versionsverwaltung der Gesamtkette machen. d) Doku: wenn ich im Readme lese: "To explain horizon's operation it's best to start with the library structure:", ist das ein Warnzeichen. Klar, die Erklärung, wie das Programm intern arbeitet, geht logischerweise über Interna. Aber man muß da aufpassen, darüber nicht den Nutzer aus den Augen zu verlieren - und statt eines Designs für einen Workflow dann haufenweise Interna zu exportieren und dem Benutzer um die Ohren zu hauen. Das passiert schnell mal, wenn kein UI-Design stattfindet bzw. dies als nachrangig betrachtet wird, bis es zu spät ist.
Ach ja.. mal Sourcemonitor drüberlaufen lassen. Scheint gut aufgeteilt zu sein, keine extremen Monsterfunktionen - Kompliment. Besonders json.hpp könnte ein Kandidat für etwas Refactoring werden, aber in geringerem Maße sollte man auch clipper.cpp, tool_delete.cpp, schematic.cpp und polypartition.cpp im Auge behalten. Was aber die Code-Doku angeht, es sind insgesamt gesehen arg wenig Kommentare drin. Man kann das auch als undokumentierten Code ansehen. Solange Du das Projekt eh alleine machen willst, mag es noch halbwegs angehen, obwohl ich persönlich bei so undokumentiertem Code ja schon nach 6 Monaten Probleme hätte zu erinnern, was ich mir dabei gedacht hatte. Das kann die spätere Fehlersuche schwierig machen, weil Du dann aus dem Code entnehmen mußt, was er hätte tun sollen, was er stattdessen tut, und wie der Bug aussieht. Mit "was er hätte tun sollen" meine ich natürlich keine Redundanzkommentare wie "i++; // increment i by 1", sondern welche, die den Sinn dahinter erläutern, denn der ist nicht im Quelltext. Quelltext sagt, WAS denn WIE implementiert ist, aber nicht WARUM und WOZU.
Nop schrieb: > Solange Du das Projekt eh alleine machen willst, mag es noch halbwegs > angehen, obwohl ich persönlich bei so undokumentiertem Code ja schon > nach 6 Monaten Probleme hätte zu erinnern, was ich mir dabei gedacht > hatte. Ich bin also nicht allein ;-) > Das kann die spätere Fehlersuche schwierig machen, weil Du dann aus dem > Code entnehmen mußt, was er hätte tun sollen, was er stattdessen tut, > und wie der Bug aussieht. > > Mit "was er hätte tun sollen" meine ich natürlich keine > Redundanzkommentare wie "i++; // increment i by 1", sondern welche, die > den Sinn dahinter erläutern, denn der ist nicht im Quelltext. Quelltext > sagt, WAS denn WIE implementiert ist, aber nicht WARUM und WOZU. Ja. Es muss noch nicht einmal jede Funktion extra kommentiert werden. Es ist wichtiger, bspw. zu jedem Modul wirklich einen richtigen ausführlichen Text zu schreiben, in dem erklärt wird, was das Modul überhaupt macht und wie dessen einzelne Funktionen zusammenspielen. Dann kann man sich viel besser in die Denkweise dessen hineinversetzen, der das Modul geschrieben hat. Nach sechs Monaten (und noch mehr nach ein paar Jahren) sind diese Texte mehr als Gold wert :-}
:
Bearbeitet durch Moderator
Nop schrieb: > Besonders json.hpp könnte ein Kandidat für etwas Refactoring werden, Ja, Code von dritten immer refaktorieren! Stabiler Code ist toter Code.
Ein weiterer Tip: Nicht das Projekt über-organisieren. Im frühen Stadium ist es glaub ich wichtiger, dass es gut genug funktioniert um bei anderen Entwicklern erstmal Interesse auszulösen. Bekomm die Grundfunktionalität so früh wie möglich stabil. Bau ein paar automatisierte Tests, damit du noch effektiv refaktorieren kannst ohne zuviel kaputt zu machen. Genug Tests dass du dich sicher fühlst, und nicht soviele dass sie dich nerven wenn du eine API mal änderst. Das ist so meine Pi*Daumen-Regel dabei. Hier sind viele gute Tipps, auch Code-Doku die von "Nop" erwähnt wird ist nicht allzu unwichtig. Aber übertreibs nicht, wenn jemand wirklich einen nenneswerten Beitrag liefern will, dann lässt er sich auch nicht von fehlenden Kommentaren aufhalten. Wichtig ist da eher, dass du zur Kommunikation da bist. Bspw. ein IRC-Channel oder ein nicht zugespammtes E-Mail-Verzeichnis.
Robin R. schrieb: > Nop schrieb: >> Besonders json.hpp könnte ein Kandidat für etwas Refactoring werden, > > Ja, Code von dritten immer refaktorieren! Stabiler Code ist toter Code. Den Spruch werd ich ausdrucken und in Großformat an den Eingang zu unserem Entwickler-Keller hängen.
Robin R. schrieb: > Ja, Code von dritten immer refaktorieren! Stabiler Code ist toter Code. Muß man abwägen. Wenn der Code von jenen Dritten noch aktiv weiterentwickelt wird, hat Refactoring keinen Sinn, weil es das Updaten unnötig schwierig macht. Andererseits habe ich auch schon Code übernommen - zigtausend Zeilen mit diversen Funktionalitäten in einer einzigen Datei. Wenn ich die Funktion "alle Vorkommnisse in der aktiven Datei suchen" regelmäßig brauche, um die Definition einer Funktion überhaupt noch zu finden, dann weiß ich, daß ein Refactoring überfällig ist. > wenn jemand wirklich einen nenneswerten Beitrag liefern will, >dann lässt er sich auch nicht von fehlenden Kommentaren aufhalten Doch, denn sinnvolle Kommentare setzen hätte den Entwickler wenig Zeit gekostet - das so herauszufinden würde mich als Nachfolger die fünffache Zeit kosten. Wer so mit meiner Zeit umgeht, bekommt davon einfach keine. Chris D. schrieb: > Ich bin also nicht allein ;-) So ziemlich jeder, der schonmal seinen eigenen Senf drei Jahre danach nochmal anfassen mußte, hat sich entweder über gute Kommentierung gefreut, oder in dem Moment verstanden, wieso sie gut gewesen wäre. :-)
Mal für Dumme Windows User wie mich, gibt es auch einen fertigen Installer? VG, Peter
Peter schrieb: > Mal für Dumme Windows User wie mich, gibt es auch einen fertigen > Installer? Nein, wurde doch schon geschrieben. Einfach mal den ganzen Thread lesen … Das ist im Moment eher Entwickler-Baustelle, also was für Leute, die wirklich in irgendeiner Weise mitmachen wollen. „Mitmachen“ heißt dabei nicht notwendigerweise, eigenen Code beizutragen, aber wenn man als Tester mitmachen will, muss man in so einer frühen Phase damit rechnen, in kürzeren Abständen (immer, wenn sich wesentlich was getan hat) neu zu bauen, ansonsten testet man Dinge, die so schon gar nicht mehr aktuell sind. Alternative: die Tests in einer VM machen, allerdings muss die VM dann die gewünschte OpenGL-Funktionalität unterstützen.
:
Bearbeitet durch Moderator
Das habe ich dann wohl überlesen, dabei hatte ich mich recht gut von oben bis unten durch gekämpft. Auch ein 2 Tage alter Intaller würde mir zeigen ob ich dem Projekt weiter folgen sollte. Vg, Peter
Peter schrieb: > Auch ein 2 Tage alter Intaller würde mir zeigen ob ich dem Projekt > weiter folgen sollte. Das mag ich dir glauben, aber sowas zu pflegen bindet einiges an Energie beim Entwickler, die er in dieser Phase wohl lieber in die Sache selbst steckt.
Nop schrieb: > Zwei Hinweise: > > a) sollte -Wall enabled sein, das ist lobenswerterweise im Makefile der > Fall. Ich würde aber ruhig noch -Werror dazusetzen. Hm, einige Warnungen könnte ich in der Tat noch ausbügeln, war bis jetzt bloß zu faul dafür. Werror muss jetzt nicht unbedingt sein, je nach Compiler und dessen Version können schon mal Warnings dazu kommen > b) check den Source mal mit CppCheck. Danke für den Tip, mit welchen Optionen hast du cppcheck laufen lassen? Vieles scheinen ja implizite Konstruktoren zu sein, manchmal war das auch so gewünscht. Horizon ist mein erstes C++-Projekt, wenn jemand Tipps zu C++14 hat, her damit. > c) das sind eine Menge an Abhängigkeiten von verschiedenen Autoren. Meinst du mit Abhänigkeiten, die die im Repository selber drin sind (json, clipper, etc) oder das ganze externe (Gtk, etc)? Viele von den externen Abhängigkeiten sind Projekte mit recht guten "Track record", denke mal, daran wird's nicht scheitern. > d) Doku: wenn ich im Readme lese: "To explain horizon's operation it's... Vielleicht habe ich hier eine etwas verzerrte sich auf die Dinge, aber Units, Entitites, etc. Sind Begriffe die auch in der GUI auftauchen, insofern sollte man als Anwender schon wissen, was damit gemeint ist. Die Tools sind ein anderes Beispiel dafür: Alle Änderungen am Dokument (Schaltplan, Board, etc) müssen durch ein Tool (oder property editor) stattfinden: von Verschieben über löschen bis zum einfügen aus der Zwischenablage. Andere Programme mögen das intern vielleicht ähnlich lösen, bei horizon wird das so direkt an den Anwender durchgereicht. Ich bevorzuge es Dinge, die ich benutze halbwegs zu verstehen. Wenn das mentale Modell mit dem Tatsächlichen Aufbau der Anwendung übereinstimmt, umso besser. Nop schrieb: > Ach ja.. mal Sourcemonitor drüberlaufen lassen. Scheint gut aufgeteilt > zu sein, keine extremen Monsterfunktionen - Kompliment. Hätte ich anders erwartet, insb. die expand()-Methoden von Board und Schematic sind doch ein wenig ausufernd... > Besonders json.hpp könnte ein Kandidat für etwas Refactoring werden, > aber in geringerem Maße sollte man auch clipper.cpp, tool_delete.cpp, > schematic.cpp und polypartition.cpp im Auge behalten. json, clipper und polypartition sind externe Libraries, die damit angepriesen werden nur aus 1...2 Dateien zu bestehen. Solang die funktionieren ist mir's egal, ob die 10kLOC haben. Das tool_delete ist leider der Architektur geschuldet. Da der interaktive manipulator der selbe für alles von Symbol bis Board ist, sind auch die tools die selben - das Tool zum Löschen von einem Symbol ist das selbe wie zum Löschen von einem Track. Einiges aus dem Tool könnte man allerdings in's Schematic/Board/etc verschieben. > Was aber die Code-Doku angeht, es sind insgesamt gesehen arg wenig > Kommentare drin. Man kann das auch als undokumentierten Code ansehen. Das stimmt in der Tat, vielleicht wird's bald besser... Robin R. schrieb: > Wichtig ist da eher, dass du > zur Kommunikation da bist. Bspw. ein IRC-Channel oder ein > nicht zugespammtes E-Mail-Verzeichnis. Dazu sind der Thread hier und issues auf github vorgesehen.
Lukas K. schrieb: > Werror muss jetzt nicht unbedingt sein, je nach > Compiler und dessen Version können schon mal Warnings dazu kommen Stimmt, aber im Moment sind die Versionen ja ohnehin festgezogen, auch bei den Libraries. Für "später", wenn Du ins richtige Release gehst, kann's sinnvoll sein, das wieder rauszunehmen. Vorteil: Du kriegst bei den jetztigen pre-alpha-Testern keine Bugreports, die letztlich an Dingen lagen, welche der Compiler schon bemerkt hatte. > Danke für den Tip, mit welchen Optionen hast du cppcheck laufen lassen? Einfach Defaults und alles an, inklusive Stilwarnungen. Ich nehm aber auch Windows und die GUI dafür - auch wenn ich dann u.a. mit Cygwin entwickele. Stilwarnungen kann man aber auch kollektiv wegklicken, wenn sie so gar nicht zum eigenen Stil passen. > Vieles scheinen ja implizite Konstruktoren zu sein, manchmal war das > auch so gewünscht. Ich vermeide Warnungen wegen Implizitheit, damit der nachfolgende Programmierer sieht, daß ich da nichts vergessen habe, sondern das genau so gewollt habe. > Meinst du mit Abhänigkeiten, die die im Repository selber drin sind > (json, clipper, etc) oder das ganze externe (Gtk, etc)? Die im Repo sind noch unkritisch, weil Du selber derjenige bist, der da mögliche Updates zentral einpflegen und testen wird. > Viele von den > externen Abhängigkeiten sind Projekte mit recht guten "Track record", > denke mal, daran wird's nicht scheitern. Ich denke dabei gar nicht mal an Bugs, sondern an Änderungen, die bestehende Funktionalität unabsichtlich zerbrechen. Sowas wie neulich bei Cryptkeeper plus Enc_FS. Allein schon die Bugreports später werden schwer auszuwerten: Geht mit Lib X in Version Y, aber nicht mit Version Z. Dummerweise kann man auch nicht dem Anwender sagen, er soll halt nur Lib X bis maximal Version Y installieren, weil ein anderes Programm dann garantiert Version Y+1 als Mindestanforderung hat. > Vielleicht habe ich hier eine etwas verzerrte sich auf die Dinge, aber > Units, Entitites, etc. Sind Begriffe die auch in der GUI auftauchen, > insofern sollte man als Anwender schon wissen, was damit gemeint ist. Ich würde die Anleitung für den Endnutzer strikt getrennt von der Doku für andere Programmierer halten, und auch das technische Niveau sollte ein ganz anderes sein. Beim Endnutzer geht es letztlich als Grundanliegen nicht darum, das Programm selber zu verstehen, sondern darum, wie man mit dem Programm die Aufgaben löst, zu denen es da ist. Ganz andere Mentalität. Ein epic fail in der Nutzerführung ist es, wenn man das Programm dazu verstehen muß. Daß man die Materie an sich verstehen muß bei so einer Software, ist hingegen klar - wer nicht weiß, was ein Layout überhaupt ist, zählt aber auch nicht zur Zielgruppe. > Andere Programme mögen das intern vielleicht ähnlich > lösen, bei horizon wird das so direkt an den Anwender durchgereicht. Autsch. Das ist Offenlegung von Interna und Vermeidung von Designentscheidungen, was letztlich beim Anwender abgeladen wird. Ist nicht verkehrt, wenn man diese Möglichkeit eröffnet, aber dann als Fallback, den man zum Troubleshooting nehmen kann, wenn das Programm nicht geht wie gewünscht. An sich sollte das Programm aber selber das tun, was es tun muß, um die gewünschte Aufgabe zu erreichen, ohne daß man ihm das alles erst manuell sagen muß. Das macht Nutzerführung schwieriger, als es aussieht, und deswegen ist es nicht damit getan, am Ende einen GUI-Wrapper drüberzulegen. Der Schlüssel als Entwickler ist es, nicht feature-orientiert zu denken, sondern Workflow-oriientiert. > Ich bevorzuge es Dinge, die ich benutze halbwegs zu verstehen. Da geht das Programmiererdenken los, und wenn es das Grunddesign der Anwendung ist, werden Anwender damit nie glücklich. Das bleibt ein Tool von Programmierern für Programmierer. Wenn ich in Word einen Text schreibe, mache ich mir ja auch keine Gedanken über die internen Datenstrukturen von Word. > Hätte ich anders erwartet, insb. die expand()-Methoden von Board und > Schematic sind doch ein wenig ausufernd... Sourcemonitor mißt Komplexität, nicht Zeilenlänge. Viele einfache Zeilen sind gut zu verstehen, wenige komplexe auch, aber viele komplexe (lokaler Spaghetticode) nicht. > json, clipper und polypartition sind externe Libraries, die damit > angepriesen werden nur aus 1...2 Dateien zu bestehen. OK, dann ist das ein Feature. Wobei Refactoring auch nicht unbedingt heißt, die Dateien zu zerlegen, sondern auch einzelne Funktionen, die in der Komplexität nach oben gehen. Aber wenn's eh externe Dinge sind, die aktiv gepflegt werden, ergibt ein Fork keinen Sinn. > Dazu sind der Thread hier und issues auf github vorgesehen. Ich würde vor allem auf Dauer kein synchrones Kommunikationsmedium wie IRC empfehlen. Das kostet nämlich aasig Zeit. Es ist effizienter, die Fragen zu sammeln, und wenn 10 Leute mehr oder weniger dasselbe wissen wollen, das in der Online-FAQ einmal zu beantworten. Deine Zeit als Entwickler ist schließlich kostbar. Auf jeden Fall wünsche ich bei dem Projekt gutes Gelingen!
Lukas K. schrieb: > Doxygen-Dokumentation hatte ich persönlich nie als wirklich hilfreich > empfunden, da darin oft erklärt ist, was auch eine Zeile drunter im Code > steht, aber die grobe Struktur fehlt. Du siehst das Problem, aber ziehst den falschen Schluss daraus! Es wird häufig falsch dokumentiert. Aber das ist nicht Doxygen anzulasten, sondern dem, der falsch dokumentiert. Ich benutze Doxygen fast von Anfang an, und mache damit (und graphviz) nicht nur meine Codedokumentation, sondern erstelle nebenbei auch noch die Onlinehilfe zum Programm als html + chm, und für Papierfetischisten alles auch als pdf zum selberausdrucken.
Michael L. schrieb: > Ich benutze Doxygen fast von Anfang an, und mache damit (und graphviz) > nicht nur meine Codedokumentation, sondern erstelle nebenbei auch noch > die Onlinehilfe zum Programm als html + chm, und für Papierfetischisten > alles auch als pdf zum selberausdrucken. Ja und? Dann steht auf dem Ausgedruckten auch bloß das, was im Quelltext zwei Zeilen drunter auch bloß steht - sowas ist keine Dokumentation! Egal ob im chm oder pdf Format. Merke dir mal, daß eine Dokumentation - wenn sie gut ist - eine Menge Informationen beinhaltet, die eben NICHT aus anderen Quellen auf dem PC zusammengesammelt werden können, sondern aus dem Vermögen eines menschlichen Autors kommen, Dinge sinnvoll und erhellend erklären zu können. Ein Programm hingegen kann immer nur aus Maschinentext einen anderen Maschinentext erzeugen - es fehlt einfach die menschliche Kreativität und der menschliche Geistes-Horizont. W.S.
W.S. schrieb: > Ein Programm hingegen kann immer nur aus Maschinentext einen anderen > Maschinentext erzeugen - es fehlt einfach die menschliche Kreativität > und der menschliche Geistes-Horizont. Die Doku ist natürlich immer nur so gut wie deren Autor. Doxygen kann deutlich mehr als nur wiederzukäuen, was zwei Zeilen darunter im Code steht … Kreative Inhalte muss jedoch natürlich immer noch der Mensch liefern, das ist bei Doxygen nicht anders als bei Word, LibreOffice, DocBook oder LaTeX.
Gute Doku zu schreiben braucht auch Erfahrung, ganz besonders mit den WTF-Momenten bei schlecht dokumentierten Projekten. Außerdem noch den Willen, es besser zu machen. Viele Opensource-Projekte kranken entweder daran, daß der Entwickler von Doku keine Ahnung hat, weder von technischer Doku noch von Userdoku (und von Usability auch nicht), oder an der "scratch-my-itch"-Einstellung. Letztere führt im Wesentlichen dazu, totalen Müll zusammenzustoppeln, aber sich dank der Ausrede "Opensource" dabei auch noch großartig vorzukommen. Ganz nach dem Motto "sobald ich kein Geld bekomme, kann ich auch endlich mal Mist machen".
Michael L. schrieb: > Es wird häufig falsch dokumentiert. Aber das ist nicht Doxygen anzulasten, sondern dem, der falsch dokumentiert. Hast du einen Vorschlag, wie man in Doxygen sinnvoll dokumentiert? Ich setze Doxygen ein, lerne aber gerne dazu. EDIT: gibt es für SourceMonitor eine grobe Richtlinie, welche Komplexität noch ok ist und wo man was tun sollte? Gruß von Max, der in diesem Thread schon eine Menge gelernt hat
:
Bearbeitet durch User
Max G. schrieb: > Hast du einen Vorschlag, wie man in Doxygen sinnvoll dokumentiert? Es gehört halt nicht nur ein Stück Beschreibung vor jedem Funktionskopf dazu, die möglichst mehr als nur die Parameter erklärt, sondern jede logische Einheit (kann eine Datei sein, muss nicht) sollte oben einen größeren Textblock haben, der zum „Großen Ganzen“ dieser Einheit eine Beschreibung enthält. Man kann auch logische Gruppen über mehrere Dateien bilden. Für Dinge, die nicht in den normalen Sourcecode passen, kann man immer noch „Additional Pages“ hinterlegen. Es hat sich eingebürgert, dass man dafür Dateien mit der Endung .dox schreibt, die inhaltlich einfach Doxygen-Sourcecode sind (also wie ein einziger großer /** ... */ Kommentar aussehen). Weiß nicht, mittlerweile kann Doxygen wohl auch Markdown verarbeiten, damit habe ich noch keine Erfahrung, vielleicht sieht das ja besser aus. Was sich auch bewährt hat ist, dass man zu „verknispelte“ Dinge vor dem Leser der Doku verbirgt, so in etwa:
1 | /**
|
2 | * This function implements some foo bar.
|
3 | */
|
4 | #ifdef DOXYGEN
|
5 | void foobar(int mumble); |
6 | #else
|
7 | static inline void foobar(int mumble) { |
8 | __asm__ ("foo bar\n" |
9 | : mumble); |
10 | #endif
|
Der Makro „DOXYGEN“ wird dann im doxygen.conf gesetzt. Ohne das #ifdef würde Doxygen den Nutzer mit dem gesamten inline-Asm überfallen, mit dem #ifdef dagegen hinterlegt man etwas Lesbareres. p.s.: Natürlich ist und bleibt Doxygen ein Tool in erster Linie für Programmierer-Dokumentation. Eine Anwenderdoku würde ich damit nicht schreiben, aber so weit dürfte „horizon“ noch nicht sein.
:
Bearbeitet durch Moderator
Max G. schrieb: > Hast du einen Vorschlag, wie man in Doxygen sinnvoll dokumentiert? Ich > setze Doxygen ein, lerne aber gerne dazu. Es geht bei der Dokumentation von Klassen, Funktionen und Methoden weniger darum den Inhalt des Namens der Jeweiligen Abstraktion zu wiederholen alla:
1 | int countAnswers; // Antworten-Zähler der die Antworten zählt |
Es geht darum, dass du dem nächsten sinnvolle Tips für die Verwendung mit gibst. Meine Daumenregel heisst: "Wenn du nichts sinnvolles schreiben kannst, schreib wenigstens ein Beispiel wie man es Verwendet." Ein Beispiel aus einem meiner Projekte:
1 | /// Setzt den Datenbank-Cursor auf die nächste Ergebnis-Zeile und liest die Zeile aus. |
2 | /// Es ist notwendig beim ersten Zugriff auf die Ergebnisse auch Result::next |
3 | /// aufzurufen, daher ergibt sich folgendes Idiom um über die Zeilen eines |
4 | /// SQL-Ergebnisses zu iterieren: |
5 | /// |
6 | ///~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
7 | /// ResultPtr r = db.execute(...); |
8 | /// for (r->next(); r->available(); r->next()) |
9 | /// {
|
10 | /// // ... r->row() ... |
11 | /// } |
12 | ///~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
13 | /// @return true wenn eine Ergebnis-Zeile verfügbar ist und nicht das Ende der Datenmenge erreicht wurde. |
14 | /// (das selbe wie available() zurückgeben würde) |
15 | /// @sa available() |
16 | bool next(); |
Und wie Jörg schon schrieb, genau das selbe gilt auch für die gesamte Klasse. Sag dem Leser, wie er die Klasse benutzt, was er für andere Klassen braucht, welche Methoden in welcher Reihenfolge aufgerufen werden müssen und wie sie im Zusammenhang stehen. Bei der Dokumentation von bisher undokumentiertem Code sehe ich auch immer zu, dass mindestens die "äußeren" APIs dokumentiert sind. Also die High-Level APIs die für einen Anwender wichtig sind. Komplett internen code der den kram nur implementiert versehe ich meist nur mit API-Dokumentation wenn ich die Zeit und Muße dazu habe. In den Internas ist es mir meist wichtiger komplizierte Code-Teile mit hilfreichen Kommentaren zu versehen, damit der nächste weiß wieso etwas so komisch implementiert ist, oder wo die Fallstricke sind bei der Modifikation. PS: Ich schreib die Doku auch häufig für mich selbst. Weil ich nach 2 Wochen auch nicht mehr ganz genau weiss wie man eine API benutzt. Darum sind mir Beispiel so wichtig. Da kann ich schnell Copy&Paste machen wenn ich faul bin und anpassen. Die Doxygen-Doku ist auch meistens schneller aufgerufen als die Tests der jeweiligen Bibliothek, in welchen die API ja meist nochmal Beispielhaft niedergeschrieben ist. Achja, und für generische Komponenten kann ich wirklich automatisierte Tests empfehlen. Ich persönlich nutze booost::test - aber das Setup davon kann manchmal etwas kompliziert sein.
:
Bearbeitet durch User
Es gibt endlich Binaries! https://github.com/carrotIndustries/horizon#quickstart-using-the-project-manager Für nen Installer war ich noch zu faul, ist aber auch noch zu früh dafür. Abgesehen vom initialen Einrichten des Pools braucht man nun zum Erzeugen und Bearbeiten eines Projektes keine Kommandozeile mehr.
Läuft bei mir unter Windows 10. Hab leider keine Komponenten sichtbar platziert bekommen im Schematic. Konnte sie auswählen und hatte dann son Magenta-Farbenen Marker aufm Plan. Reinzoomen ging nicht, liegt aber vermutlich eher dran, dass ich keine Maus zur Hand hatte? Der Tool-Popover reagiert teilweise sehr langsam. Bspw hab ich versucht "zoom" zu tippen, aber er hat sehr träge reagiert. Konnte aber aufm ersten Blick nix am Code erkennen, was das Verhalten erklärt. Zum Code habe ich nur folgende, vollkommen subjektive und auf Geschmack basierende Gedanken, die sich hauptsächlich um die Formatierung drehen: Ich rücke lieber mit Spaces ein. Die Zeilen sind ´relativ unlesbar, weil 152 Zeichen lange Zeilen mit dem Auge schwer zu lesen sind (Das Auge muss die Höhe ja bei jedem horizontalen Sprung justieren). Manche Methoden sind recht lang. bspw. Schematic::expand. Und ich bin ein Freund von Leerräumen beim Formatieren. Also "if (a == b)" statt "if(a == b)" und mehr Leerzeilen. Die Kopplung der Klassen untereinander ist relativ hoch. Bspw. muss Schematic offenbar sehr genau wissen, wie ein Symbol genau funktioniert und aufgebaut ist: "sym->component->entity->prefix" - das koppelt die Implementierung vom Symbol sehr stark an Schematic.
bzgl. meines letzten Posts: Das sind natürlich zum Teil auch Stil-/Geschmacks-Fragen. Aber meiner Erfahrung nach ist gut lesbarer Code auch einfach zu wartender Code. Dass Schematic etwas über die Komponenten mit denen es hantiert ist auch kein gravierendes Problem, aber man sollte ein Auge drauf haben wenn der Code anfängt (stark) zu wachsen. Unter Windows 7 öffnet sich leider weder der Schematic noch das Board, es kommt nur ein weißer Kasten - und es scheinen unsichtbare Bedienelemente vorhanden zu sein, der Cursor ändert nämlich seine Form an bestimmten Positionen und der Kasten lässt sich auch größer/kleiner ziehen.
Robin R. schrieb: > Läuft bei mir unter Windows 10. Hab leider keine Komponenten sichtbar > platziert bekommen im Schematic. Konnte sie auswählen und hatte dann son > Magenta-Farbenen Marker aufm Plan. Reinzoomen ging nicht, liegt aber > vermutlich eher dran, dass ich keine Maus zur Hand hatte? Hört sich nach OpenGL-Problem an (Shader für den Inhalt konnten nicht kompiliert werden). Was für eine Grafikkarte hast du? CAD ohne Maus macht natürlich nur wenig Sinn.. Wenn du debuggen willst, musst du wohl selber Bauen und den imp direkt auf mingw starten: https://github.com/carrotIndustries/horizon/blob/master/build_win32.md Dann kommt auch sinnvolle Ausgabe, was schief gelaufen ist. Robin R. schrieb: > Der Tool-Popover reagiert teilweise sehr langsam. Keine Ahnung was 'sehr' heißt, eine gewisse Verzögerung ist aber drin: https://developer.gnome.org/gtk3/stable/GtkSearchEntry.html Robin R. schrieb: > Unter Windows 7 öffnet sich leider weder der Schematic noch das Board, > es kommt nur ein weißer Kasten - und es scheinen unsichtbare > Bedienelemente > vorhanden zu sein, der Cursor ändert nämlich seine Form an bestimmten > Positionen und der Kasten lässt sich auch größer/kleiner ziehen. Der Projektmanager tut aber? Hört sich wieder nach OpenGL-Problem an...
Windows 7: Intel HD Graphics 4000, GPU Caps Viewer liefert folgende
Infos:
OpenGL 3.3 (Intel(R) HD Graphics 4000 with 132 ext.)
OpenCL 1.1, Intel(R) HD Graphics 4000 compute units:16@350MHz
Report hab ich hier hochgeladen (gpu_caps_viewer_report_win7.txt)
Windows 10: Nvidia GeForce 840M
OpenGL 4.5 (GeForce 840M/PCIe/SSE2 with 360 ext.)
OpenCL 1.2, GeForce 840M compute units:3@1124MHz
Report hab ich auch hochgeladen (gpu_caps_viewer_report_win10.txt)
PS: Die Intel-Karte scheint offenbar keine Geometry Shader Texture Units
zu haben. Daher kann da natürlich auch der Shader nicht laufen.
:
Bearbeitet durch User
Lukas K. schrieb: > Robin R. schrieb: >> Läuft bei mir unter Windows 10. Hab leider keine Komponenten sichtbar [.snip.] > Was für eine Grafikkarte hast du? CAD ohne Maus > macht natürlich nur wenig Sinn.. Habs jetzt nochmal mit Maus (via VNC nach Hause) probiert, das Problem ist nur der initiale Zoom. Wenn ich weiter rein Zoome (mit Mausrad) sehe ich die Komponente auch richtig, und nicht nur den mangenta-farbenen Selektionsmarker. Touch-Pad-Support is auch ersmtal nicht wichtig, bei KiCAD bleibt mir auch nur F2/F3 zum Zoomen übrig. Morgens/Abends im Bett hab ich halt keine Maus zur Hand ;-) Finds übrigens super, dass Undo/Redo bereits in so früher Phase eingebaut ist - sowas nachträglich einbauen is immer ein Krampf... OpenGL-Mäßig ist die NVidia-Karte halt eher aufm aktuellen Stand. Ist auch ein Lenovo-Consumer-Laptop, die Windows 7 Kiste ist ein 3-4 Jahre alter Büro-Dell-Rechner. Ich kann gut verstehen, dass man aktuelle OpenGL-Features nutzen will. Aber sollte es nicht schon ausreichen wenn man mit vertext buffer objects arbeitet? PS: Auf dem Windows 7 Rechner bekomme ich folgende Fehlerausgabe (mit einer selbst-compilierten Version ausm Git):
1 | (horizon-imp.exe:2356): Gdk-WARNING **: Compile failure in fragment shader: |
2 | ERROR: 0:10: 'texture2D' : no matching overloaded function found (using implicit conversion) |
3 | ERROR: 0:10: 'assign' : cannot convert from 'const float' to 'FragUserData 4-component vector of float' |
:
Bearbeitet durch User
Robin R. schrieb: > PS: Auf dem Windows 7 Rechner bekomme ich folgende Fehlerausgabe (mit > einer selbst-compilierten Version ausm Git): > >
1 | (horizon-imp.exe:2356): Gdk-WARNING **: Compile failure in fragment |
2 | shader: |
3 | ERROR: 0:10: 'texture2D' : no matching overloaded function found |
4 | (using implicit conversion) |
5 | ERROR: 0:10: 'assign' : cannot convert from 'const float' to |
6 | 'FragUserData 4-component vector of float' |
Oh, das schaut nach einem Bug in Gtk/Gdk bzw. dem Intel-Treiber aus. Ist der aktuell? Passt auch dazu, dass das Fenster komplett leer ist. Zum Test, starte mal gtk3-demo aus der mingw-Konsole und öffne die OpenGL-Demo. Die sollte dann auch kaputt sein. Schnapp' dir nen Hexeditor und mach die libgdk-3-0.dll aus dem mingw-Verzeichnis auf. Nach Offset 0x87340 texture2D durch texture ersezten (2D durch zwei Leerzeichen ersetzen) Schau mal nach, ob's dann klappt.
Lukas K. schrieb: > Oh, das schaut nach einem Bug in Gtk/Gdk bzw. dem Intel-Treiber aus. Ist > der aktuell? Passt auch dazu, dass das Fenster komplett leer ist. Zum > Test, starte mal gtk3-demo aus der mingw-Konsole und öffne die > OpenGL-Demo. Die sollte dann auch kaputt sein. Jo, die OpenGL-Demo is auch kaputt, selbe Symptome. Bzgl. der Treiber hab ich keine Ahnung. > > Schnapp' dir nen Hexeditor und mach die libgdk-3-0.dll aus dem > mingw-Verzeichnis auf. Nach Offset 0x87340 texture2D durch texture > ersezten (2D durch zwei Leerzeichen ersetzen) Schau mal nach, ob's dann > klappt. Hmm, damit hab ich bei mir die gtk3-demo nur komplett kaputt bekommen.
In dem von dir Angehängten Report steht was von - Driver: 8.15.10.2639 (2-1-2012) - GL:ig7icd64.dll bei Intel gibt's einen von 2016 https://downloadcenter.intel.com/download/25977/Intel-Graphics-Driver-for-Windows-10-and-Windows-7-8-1-15-33-?product=81499 Wenn du magst, kannst du mal mit dem dein Glück versuchen. Robin R. schrieb: > Touch-Pad-Support is auch ersmtal nicht wichtig, > bei KiCAD bleibt mir auch nur F2/F3 zum Zoomen übrig. Morgens/Abends > im Bett hab ich halt keine Maus zur Hand ;-) Auf X11 und Wayland erkennt das Canvas-Widget, wenn ein Input-Event von 'nem Trackpoint kam und "pannt" dann, anstatt zu scrollen. Zum zoomen dann ctrl festhalten. Damit ist horizon auch recht brauchbar ohne Maus zu bedienen. Robin R. schrieb: > Ich kann gut verstehen, dass man aktuelle OpenGL-Features nutzen will. > Aber sollte es nicht schon ausreichen wenn man mit vertext buffer > objects arbeitet? Mit geometry shadern macht's eben mehr Spaß ;) Lästiger Kram, wie z.B. Linien mit abgerundeten Ecken malen geht recht bequem im Zusammenspiel von Geometry- und Fragment-Shader.
Lukas K. schrieb: > In dem von dir Angehängten Report steht was von > - Driver: 8.15.10.2639 (2-1-2012) - GL:ig7icd64.dll > bei Intel gibt's einen von 2016 > https://downloadcenter.intel.com/download/25977/Intel-Graphics-Driver-for-Windows-10-and-Windows-7-8-1-15-33-?product=81499 > > Wenn du magst, kannst du mal mit dem dein Glück versuchen. Die Intel-Treiber wollen leider nicht direkt auf diesem Dell-Rechner, aber die Treiber von der Dell-Webseite haben dann zumindest das Fehlerbild geändert. Jetzt bekomme ich immerhin ein Fenster, aber der Canvas ist nicht zu sehen (nur der graue Gtk-Hintergrund). Selbes Bild auch mit gtk3-demo. Immerhin gehts unter Win10 auf dem neueren Rechner.
Auch wenn's hier die letzten Monate doch eher still geworden ist, ist die Entwicklung von horizon nicht stehen geblieben. Neben Annehmlichkeiten wie GUI zum Verwalten von Bauteilen und Projeken sind Funktionen wie interaktives regelbasiertes Routing und DRC hinzugekommen. Seht selbst: https://github.com/carrotIndustries/horizon#horizon-is-a-free-eda-package
Ja, ich hatte vor einigen Tagen auch mal kurz hineingeschaut. Mitstreiter haben sich ja wohl sogut wie keine gefunden, und hier in dem Thread gab es soweit ich mich errinnere nur gemecker --war ja auch nicht anders zu erwarten. Ich werde mir demnächst mal dein Dateiformat und dein Vorgehen beim Bauteilentwurf ansehen. Denn mein high level GTK3 Nim wrapper ist nun endlich weitgehend fertig, so dass ich auch mal wieder etwas an meinen Programmen arbeiten könnte. Die kompatibilität mit gEDA werde ich wohl aufgeben, das scheint ja eh keiner mehr zu benutzen. Hast Du eigentlich mal probiert, wie viel schneller Dein GL Zeichnen im Vergleich zu Cairo's CPU Backend ist? Denn Cairo's GL Backend ist ja seltsamerweise langsamer als das CPU Backend. Kürzlich fand ich Intels https://github.com/intel/fastuidraw Das ist schon ganz interessant, aber wohl noch unfertig. 9 mal schneller als cairo CPU.
Stefan S. schrieb: > Hast Du eigentlich mal probiert, wie viel schneller Dein GL Zeichnen im > Vergleich zu Cairo's CPU Backend ist? Denn Cairo's GL Backend ist ja > seltsamerweise langsamer als das CPU Backend. Ausprobiert habe ich da noch nichts, wenn man sich aber mal ansieht wie furchtbar langsam Kicads Cairo-GAL canvas ist... Cairo mit OpenGL zu beschleunigen halte ich auch für nur mäßig zielführend, da cairos Zeichenmodell nicht so wirklich zu dem von OpenGL passt.
Ja das ist richtig. Nach https://www.x.org/wiki/Events/XDC2016/Program/rogovin_fast_ui_draw/ ist SkiaGL ja auch nicht wesentlich schneller als Cairo. Aber wenn man schon mit OpenGL zeichnet sollte man schon geglättete diagonale Linien, Bezier-Kurven und auch hochwerttige Fonts haben. Und dann wird es leider schon wieder aufwendiger und langsamer. Hast Du Deine GL Zeichenroutinen auf dem GL-Area Demo mit dem Dreieck aufgebaut?
Stefan S. schrieb: > Ja das ist richtig. > > Nach > > https://www.x.org/wiki/Events/XDC2016/Program/rogovin_fast_ui_draw/ > > ist SkiaGL ja auch nicht wesentlich schneller als Cairo. > > Aber wenn man schon mit OpenGL zeichnet sollte man schon geglättete > diagonale Linien, Bezier-Kurven und auch hochwerttige Fonts haben. Und > dann wird es leider schon wieder aufwendiger und langsamer. MSAA wäre in der Tat machbar, ist halt Aufwand: https://www.khronos.org/opengl/wiki/Multisampling#Render-to-FBO Für die anderen Methoden müsste der GdkGLContext MSAA können, was nicht der Fall ist. Was Fonts anbetrifft: Die derzeit verwendeten Hershey-Fonts sind mir hübsch genug. Andere Programme, die echte Truetype-Schriften verwenden haben mitunter Probleme damit, diese entsprechend dem Rest drum herum zu skalieren. Text, der bei einer Zoomstufe passt, ragt dann bei einer anderen schon ins Symbol nebendran... > Hast Du Deine GL Zeichenroutinen auf dem GL-Area Demo mit dem Dreieck > aufgebaut? Jep, hauptsächlich der Boilerplate-Code zum Shader aufsetzen ist größtenteils aus der Demo übernommen. Irgendwo muss man ja mal anfangen ;)
Stefan S. schrieb: > Mitstreiter haben sich ja wohl sogut wie keine gefunden, Naja, interessieren würde es mich schon, aber ich denke, ich bin technisch und mental nicht mit euch kompatibel. Mein normales Desktop Environment ist der fvwm2, und übliche Projekte umfassen bei mir 1000 Zeilen tcl/tk-Code (eher weniger als mehr). > [...] so dass ich auch mal wieder etwas an meinen Programmen > arbeiten könnte. Du bist der Stefan S., der die psychedelischen Bilder, die der topologische Router produziert hat, auf der Homepage zeigt!? > Die kompatibilität mit gEDA werde ich wohl aufgeben, Sehr schade. > das scheint ja eh keiner mehr zu benutzen. Ich spiele gelegentlich damit herum. -- Das Projekt scheint sich totgelaufen zu haben. Kennt jemand Hintergründe? Ich habe den diffusen Eindruck, dass sich die Entwickler auf faule Kompromisse "geeinigt" haben, die dann doch niemand wirklich wollte. Im Vergleich zum nächsten, (n+1)ten All-in-one-Klotz fände ich es WIRKLICH wichtig, eine Software zu haben, die eine klare Aufgabenteilung ermöglicht. Generell scheint meine persönliche Vorstellung von Software- ergonomie mit der der Programmierer absolut inkompatibel zu sein. Ideen gäbe es schon -- allein, ich bin programmier- technisch nicht versiert genug, sie umzusetzen.
Possetitjel schrieb: > Du bist der Stefan S., der die psychedelischen Bilder, die > der topologische Router produziert hat, auf der Homepage > zeigt!? Ja sicher. > >> Die kompatibilität mit gEDA werde ich wohl aufgeben, > > Sehr schade. > >> das scheint ja eh keiner mehr zu benutzen. > > Ich spiele gelegentlich damit herum. -- Das Projekt scheint > sich totgelaufen zu haben. Kennt jemand Hintergründe? Da gibt es eine vielzahl von Gründen. Der ursprüngliche Hauptentwickler und auch auch viele andere Entwickler haben sich nach und nach zurückgezogen. Neue Ideen oder größere Veränderungen wurden von den wenigen alten Usern stets abgelehnt. Dann war gEDA/PCB ja nur mit Mühe unter Windows zum Laufen zu bringen. GTK ist eh nicht mehr so beliebt, und die Entwicklung mit plain C ist eben auch sehr zäh. Und Scheme als Script- und Konfigurationssprache ist auch nicht jedermanns Sache. Wobei es seit gut einem Jahr wohl ein neues Project PCB-RND bzw. gEDA-RND gibt. Ich hatte aber nur die Ankündigung gesehen, u.a. C89 und soll auch mit reinem X11 funktionieren, also auch ohne GTK. So macht man sich das Leben wieder sehr schwer. > > Im Vergleich zum nächsten, (n+1)ten All-in-one-Klotz fände > ich es WIRKLICH wichtig, eine Software zu haben, die eine > klare Aufgabenteilung ermöglicht. Das war gEDA/PCB ja, und gerade das wurde aber sehr viel kritisiert. Die meisten wollten lieber alles in einem Programm und sind dann zum Teil zu KiCad abgewandert. > Generell scheint meine persönliche Vorstellung von Software- > ergonomie mit der der Programmierer absolut inkompatibel zu > sein. Ideen gäbe es schon -- allein, ich bin programmier- > technisch nicht versiert genug, sie umzusetzen. Man muss ja nicht unbedingt C++ verwenden. Und auch nicht Haskell oder Rust. Es gibt ja heute eine Reihe von recht einfachen aber doch sehr leistungsfähigen Sprachen, da kann schon jeder, der etwas denken kann auch programmieren. Mit den GUI's sieht es natürlich noch immer schlechter aus, für Qt kommt wohl im wesentlichen nur C++ in frage, oder eventuell Python. Für GTK gibt es Bindings für viele Sprachen, mit unterschiedlicher Qualität. Aber Programmieren kann man ja auch Dinge die keine GUI benötigen. Oder man macht Webanwendungen, Java-Script und Konsorten scheinten ja immer beliebter zu werden. Oder C# oder Android Apps.
Wird hier eigentlich das selbe Programm vorgestellt, über das hier diskutiert wird? https://www.youtube.com/watch?v=OpwMhz_3Tbs
Davon würde ich angesichts des Programmnamens und des Namens "lukas" ausgehen. :)
ich schrieb: > Wird hier eigentlich das selbe Programm vorgestellt, über das hier > diskutiert wird? > https://www.youtube.com/watch?v=OpwMhz_3Tbs Ja. In dem Video präsentiert Lukas sein Projekt. Man findet die Videoaufzeichnung auch hier. https://media.ccc.de/v/gpn17-8592-neues_ecad-programm_horizon
:
Bearbeitet durch User
ich schrieb: > Wird hier eigentlich das selbe Programm vorgestellt, über das hier > diskutiert wird? > Youtube-Video "Neues ECAD-Programm horizon (GPN17)" Mein Gott, diese abhackte Sprechweise ist für mein Gehör einfach nicht kompatibel. Für mich wieder mal ein Beispiel für die vielen nahezu unzumutbaren "Tutorials" (um es mal so zu nennen) die eher abschrecken als motivieren. Abgesehen davon, brauchbare EDA-Software zu schreiben gehört nach meiner Erfahrung (als Nutzer) mit zum Schwierigsten was man sich vornehmen kann und ist unmöglich als One-Man-Show erfolgreich umzusetzen. Wieviel Mann-Jahre developer time beispielsweise wurden bisher an eagle ver(sch)wendet und bis heute hat eagle quirks, die manch einen zur Verzweiflung oder zur Konkurrenz treiben. Das Problem bei EDA ist nämlich, dass es extrem um die Feinheiten, d.h. das Zusammenspiel zwischen Schaltplan, Layout und Bibliothekshandling (schnelle Erstellung, Pflege, hohe Vollständigkeit, 3D etc.) geht und schon Kleinigkeiten einem das Leben schwer machen können. Für ein Ein-Mann-Projekt ist das in absehbarer Zeit (wir reden über JAHRE!!) viel zu schwierig umzusetzen und alle die hier falsche Hoffnung und Schulterklopf befördern werden selber so eine halbgare Software NIEMALS einsetzen. Was bleibt ist später eines der unzähligen angefangenen und verwaisten Projekte, bei denen der Ersteller schlicht die Lust daran verloren hat.
Leute, Leute schrieb: > Mein Gott, diese abhackte Sprechweise ist für mein Gehör einfach nicht > kompatibel. Hast du mal ein Video (oder Audio) von einem Konferenzvortrag, den du gehalten hast? Klingt er denn viel besser? > Für mich wieder mal ein Beispiel für die vielen nahezu > unzumutbaren "Tutorials" (um es mal so zu nennen) die eher abschrecken > als motivieren. Thread nicht gelesen, aber rummaulen. Das Teil ist absolut noch nichts, was irgendwie Nutzern derzeit zugemutet werden soll. Folglich ist das Video auch kein „Tutorial“, sondern eine Darstellung des Arbeitsstandes. Wenn du hier nur als Nutzer daherkommen willst, bist du wohl mehr als ein Jahr zu früh. > Abgesehen davon, brauchbare EDA-Software zu schreiben gehört nach meiner > Erfahrung (als Nutzer) mit zum Schwierigsten was man sich vornehmen kann > und ist unmöglich als One-Man-Show erfolgreich umzusetzen. Aha. Du erklärst, dass du selbst nur Nutzer bist, weißt aber dabei sofort, dass das als One-Man-Show nicht zu machen ist. Das leuchtet sofort ein. Deine Erfahrungen als Nutzer ermöglichen dir natürlich einen grundlegenden Rundumblick dafür, wie ein Entwickler in diesem Bereich so arbeiten muss …
Leute, Leute schrieb: > Was bleibt ist später eines der unzähligen angefangenen und > verwaisten Projekte, bei denen der Ersteller schlicht die Lust daran > verloren hat. Na und? Selbst wenn es so kommen würde, was gibts daran auszusetzen? Wer was macht hat recht, wie man in der Szene sagt. Ich meine die Kritik war ja nicht mal konstruktiv... man hätte ja zum Beispiel das was gut ist herausstellen und vorschlagen können seine Mann-Jahre in ein vorhandenes Projekt wie KiCad einzubringen? Whatever - dem TO viel Erfolg und hört nicht auf Miesepeter. Wer macht, hat recht!
Jörg W. schrieb: > Leute, Leute schrieb: > >> Mein Gott, diese abhackte Sprechweise ist für mein Gehör einfach nicht >> kompatibel. > > Hast du mal ein Video (oder Audio) von einem Konferenzvortrag, den > du gehalten hast? Klingt er denn viel besser? > >> Für mich wieder mal ein Beispiel für die vielen nahezu >> unzumutbaren "Tutorials" (um es mal so zu nennen) die eher abschrecken >> als motivieren. > > Thread nicht gelesen, aber rummaulen. Kannst es ja überlesen wenn es dir nicht passt. > Das Teil ist absolut noch nichts, was irgendwie Nutzern derzeit > zugemutet werden soll. Folglich ist das Video auch kein „Tutorial“, > sondern eine Darstellung des Arbeitsstandes. Es wird auch später niemandem nutzen, weil der Ersteller bereits mit dem Vortrag selbst überfordert ist. Sorry, aber so wirkt das nun mal auf mich. > Wenn du hier nur als Nutzer daherkommen willst, bist du wohl mehr > als ein Jahr zu früh. Man sein, aber auch in einem Jahr wird sich daran nichts ändern. Ist meine Prognose. Du brauchst sie nicht zu teilen. >> Abgesehen davon, brauchbare EDA-Software zu schreiben gehört nach meiner >> Erfahrung (als Nutzer) mit zum Schwierigsten was man sich vornehmen kann >> und ist unmöglich als One-Man-Show erfolgreich umzusetzen. > > Aha. Du erklärst, dass du selbst nur Nutzer bist, weißt aber dabei > sofort, dass das als One-Man-Show nicht zu machen ist. Ja, ich schreibe keine EDA SW. So verrückt kann ich gar nicht sein. Schau dir doch mal an was z.B. Abacom als EDA so anbietet. Wieviele Leute haben an deren SW nun seit wie vielen Jahren geschrieben und noch immer wird deren SW mehr als "Platinenmaler" angesehen, als als echte EDA-SW. Glaubst du der Threadersteller wird es jemals schaffen auch nur auf deren Niveau aufzuschließen? > Das leuchtet sofort ein. Deine Erfahrungen als Nutzer ermöglichen > dir natürlich einen grundlegenden Rundumblick dafür, wie ein Entwickler > in diesem Bereich so arbeiten muss … Darum geht es nicht. Es geht darum zu erkennen, wann man sich mit einer Aufgabe übernimmt. Hier werden womöglich falsche Hoffnungen geweckt oder warum wurde dieser Thread hier eröffnet? Irgendwann soll die SW hier doch mal benutzbar sein oder etwa nicht? Schau dir doch nur mal den Mist bei gEDA an. Wer will denn sowas benutzen? Das Netz strotzt nur so von halbgaren Projekten, gerade im Bereich der SW-Entwicklung. Wer will denn seine Platinen mit einer SW layouten, deren Möglichkeiten extrem beschnitten sind und Schicksal ungewiss ist? Mir reichen übrigens meine Quirks bei Diptrace. Mit denen kann ich einigermaßen leben.
Miesepeter schrieb: > Leute, Leute schrieb: >> Was bleibt ist später eines der unzähligen angefangenen und >> verwaisten Projekte, bei denen der Ersteller schlicht die Lust daran >> verloren hat. > > Na und? Selbst wenn es so kommen würde, was gibts daran auszusetzen? Anscheinend bist du noch nie auf schlechte SW hereingefallen. > Wer > was macht hat recht, wie man in der Szene sagt. "Die Szene"? Was soll das sein? Leute die auf die schnelle was zusammencodieren und meinen dann das Ei des Kolumbus neu erfunden zu haben? Davon gibt es mehr als genug. Nach ein paar Jahren ist die Lust dann weg und zurück bleibt eine Baustelle, die keiner mehr braucht bzw. verprellte Nutzer. > Ich meine die Kritik war > ja nicht mal konstruktiv... Doch ist sie. Lass es sein! Verbessere meinetwegen lieber KiCAD aber versuche die nicht an Dingen die in die Hose gehen müssen. > Whatever - dem TO viel Erfolg und hört nicht auf Miesepeter. Wer macht, > hat recht! Wer das falsche macht gerät in seine Sackgasse. Wer das überdies nicht erkennt ist doof. Sorry, aber so ist es. Wer einfach mal ein bisschen herumcodieren möchte darf das natürlich tun. Aber dann den Ball flach halten und nicht falsche Hoffnungen wecken.
Jörg W. schrieb: > Das Teil ist absolut noch nichts, was irgendwie Nutzern derzeit > zugemutet werden soll. Hast du dir's in der aktuellen Version mal angesehen? Inzwischen hat's einige Annehmlichkeiten, die man so in anderer EDA-Software (z.B. KiCad) doch sehr vermisst: - Schaltplaneditor, der mehr als nur ein Malprogramm ist - Sinnvolles Bauteilmanagement - Flexible Regeln für Abstände, Leiterbahnbreite, etc. Im Gegensatz zu vor 9 Monaten kann man nun auch alles aus der GUI machen und muss keine Shell mehr anfassen. (Für dich wahrscheinlich weniger ein Problem) https://github.com/carrotIndustries/horizon/wiki/Feature-overview
:
Bearbeitet durch User
Leute, Leute schrieb: > Kannst es ja überlesen wenn es dir nicht passt. Genauso gut könntest du deinen Beitrag zu Thema auch bleiben lassen. In der dargebotenen Form mag dein Beitrag deinem Ego vielleicht helfen, mehr auch nicht. Vom TE haben wir im Gegensatz zumindest durchaus verwertbare Dinge sehen können, einschließlich des Auftritts auf einer Konferenz. Er hat eine Software geschaffen, die zumindest in gar nicht so kleinen Teilen das tut, was sie soll. Das ist deutlich mehr als die Miesmacherei, die du hier ablässt. (Dabei bestreite ich keineswegs, dass es noch ein langer Weg bis zum fertigen "Produkt" ist, > Es geht darum zu erkennen, wann man sich mit einer Aufgabe übernimmt. Wer bist du denn, dass ausgerechnet du dazu berufen sein mögst, das zu erkennen? Im Gegensatz zum TE bist du einfach nur ein anonymer Forenposter. Wenn es an der Substanz fehlt, muss man sich dann an Äußerlichkeiten aufziehen („Mein Gott, diese abhackte [sic] Sprechweise …“). Geh bitte wieder zurück irgendwo hin, wo du produktiver wirken kannst, aber verschon diesen Thread einfach mit deiner Miesepeterei.
Jörg W. schrieb: >> Abgesehen davon, brauchbare EDA-Software zu schreiben >> gehört nach meiner Erfahrung (als Nutzer) mit zum >> Schwierigsten was man sich vornehmen kann und ist >> unmöglich als One-Man-Show erfolgreich umzusetzen. > > Aha. Du erklärst, dass du selbst nur Nutzer bist, weißt > aber dabei sofort, dass das als One-Man-Show nicht zu > machen ist. Das ist ein Umkehrschluss, der naheligend -- und meiner Meinung nach auch zutreffend -- ist: Wäre es als One-Man-Show machbar, dann hätte es schon jemand gemacht. EDA-Software gibt es schließlich reichlich. Was mich verzweifeln lässt, das ist der Eindruck, dass niemand -- wirklich NIEMAND -- Interesse daran hat, eine echt modularisierte Software auf die Beine zu stellen. Mit "modularisiert" meine ich nicht "Quelltext besteht aus mehreren Teilen", sondern: alle missionskritischen Interfaces (Dateiformate, ggf. auch APIs) sind offengelegt und werden aktiv gepflegt. Das würde natürlich voraussetzen, dass reichlich Arbeit in das Entwickeln eines tragfähigen Datenmodelles geht, und diese Zeit steht dann natürlich nicht mehr dafür zur Verfügung, sich über die "modernste" Grafik-Bibliothek die Köpfe einzuschlagen... Der Vorteil dieser Modularisierung liegt auf der Hand: Es sind alle Abstufungen von All-in-one-Mammutsoftware bis hin zu einzelnen Werkzeugen für jeden Zweck machbar, und der Anwender müsste keine exclusive Entscheidung für EIN Werkzeug treffen, die dann alle anderen ausschließt. Das kommerzielle Anbieter das nicht wollen (weil es den "Vendor- lock-in" verhindert), ist mir ohne weiteres klar. Warum aber die FOSS-Gemeinde nicht in der Lage ist, das hinzubekommen, wird mir auf Dauer ein Rätsel bleiben.
Lukas K. schrieb: > Hast du dir's in der aktuellen Version mal angesehen? Nein, sorry, ich fürchte, dass ich schon auf zu vielen Hochzeiten selbst tanze. :) Ich wünsche dir aber auf jeden Fall viel Erfolg damit, und es würde mich durchaus freuen, wenn das Projekt an Fahrt aufnimmt (einschließlich weiterer Mitwirkender).
Possetitjel schrieb: > Mit "modularisiert" meine ich nicht "Quelltext besteht aus mehreren > Teilen", sondern: alle missionskritischen Interfaces (Dateiformate, ggf. > auch APIs) sind offengelegt und werden aktiv gepflegt. Leute, die Opensource Datenmodelle abstrahieren, sind halt noch deutlich dünner geseht als Opensource-Programmierer. Programmieren macht Spaß, diejenigen, denen das Pflegen von Datenmodellen so viel Spaß macht, dass sie dies auch noch in ihrer Freizeit tun, dürfte es nur wenige geben.
Leute, Leute schrieb: > Wer das falsche macht gerät in seine Sackgasse. Wer das > überdies nicht erkennt ist doof. Sorry, aber so ist es. > Wer einfach mal ein bisschen herumcodieren möchte darf > das natürlich tun. Aber dann den Ball flach halten und > nicht falsche Hoffnungen wecken. Könnte es sein, dass Du Deine Prioritäten etwas merkwürdig setzt? Ist Dir das Diffamieren fremder Leistungen tatsächlich SO wichtig, dass am Ende keine Energie mehr über bleibt, ein Sachargument zu formulieren?
Jörg W. schrieb: > Leute, Leute schrieb: >> Kannst es ja überlesen wenn es dir nicht passt. > > Genauso gut könntest du deinen Beitrag zu Thema auch bleiben lassen. Und das bestimmst du also? > In der dargebotenen Form mag dein Beitrag deinem Ego vielleicht helfen, > mehr auch nicht. Ach Gott, spar dir deine persönliche Agitation. > Vom TE haben wir im Gegensatz zumindest durchaus > verwertbare Dinge sehen können, einschließlich des Auftritts auf einer > Konferenz. Die ziemlich unerträglich ist. Für meine Ohren jedenfalls. > Er hat eine Software geschaffen, Nö. Er hat mal was zusammencodiert, das niemand braucht und auch niemand benutzen wird. Ginge das alles so einfach hätten wird zig gute EDA Pakete. Haben wird aber nicht. Warum wohl?! > die zumindest in gar nicht > so kleinen Teilen das tut, was sie soll. Das reicht nicht. Nicht mal ansatzweise. > Das ist deutlich mehr als > die Miesmacherei, die du hier ablässt. (Dabei bestreite ich keineswegs, > dass es noch ein langer Weg bis zum fertigen "Produkt" ist, DU Bist es der auf Mies macht mein lieber. Nur mal zu deiner Erinnerung. Hier hat jemand einen Thread aufgemacht und zum BENUTZEN seines Programms aufgefordert. Zitat "Viel Spaß damit," Welcher Spaß??? Wer Platinen erstellt braucht keine Spaßbaustelle, sondern ein ZUVERLÄSSIGES Programm. Alles andere ist Mumpitz. Und Beta Tester einer Pre-Alpha-Software spielen ist auch kein Spaß. >> Es geht darum zu erkennen, wann man sich mit einer Aufgabe übernimmt. > > Wer bist du denn, dass ausgerechnet du dazu berufen sein mögst, das > zu erkennen? Das ist inhärent mit der ausgesuchten Aufgabe verknüpft. Dazu brauche ich keine Berufung um das zu erkennen. Mir genügt meine Erfahrung bisheriger EDA-SW, um zu beurteilen, wie viel wichtige aber oft schlecht umgesetzte Details einen zur Weißglut bringen können. Es braucht nicht noch mehr halbgare EDA. Gerade Leiterplattenprojekte sind wenig geeignet um mit SW gepflegt zu werden, die das Schicksal verwaister Projekte in wenigen Jahren teilen werden. Besser man bedenkt das vorher als hinterher dumm dazustehen. > Im Gegensatz zum TE bist du einfach nur ein anonymer Forenposter. Wenn > es an der Substanz fehlt, muss man sich dann an Äußerlichkeiten > aufziehen („Mein Gott, diese abhackte [sic] Sprechweise …“). Ja, ich bin es leid auf diese YouTube Videos hereinzufallen, die keinen Mehrwert beeinhalten, weil sie ziemlich unerträglich sind. Wenn ich nicht tanzen kann gehe ich auch nicht auf die Bühne zum vortanzen. > Geh bitte wieder zurück irgendwo hin, wo du produktiver wirken kannst, > aber verschon diesen Thread einfach mit deiner Miesepeterei. Spare dir diese billige Polemik. Mit falschem Schulterklopf erweist du dem TE nur einen Bärendienst.
Possetitjel schrieb: > Ist Dir das Diffamieren fremder Leistungen tatsächlich SO > wichtig, dass am Ende keine Energie mehr über bleibt, ein > Sachargument zu formulieren? Ich diffamiere hier niemandem. Hier wird aber wie schon im Mittelalter der Überbringer der Nachricht mal wieder gesteinigt und somit ein Forum wie des Öfteren ad absurdum geführt. Mal abgesehen davon, was erwartest du? Das ich meine Zeit damit verbringe eine SW zu testen, die ich nie benutzen werde? Wozu? Ich gab meine Meinung dazu ab und Meinungsfreiheit besteht doch hoffentlich noch oder etwa nicht mehr?! Speichere den Thread hier ab, hole ihn in 5 Jahren wieder heraus und schaue, ob die SW dann beispielsweise KiCAD überholt hat. Ich sage dir voraus, in 5 Jahren (oder deutlich früher) wird diese SW in der Versenkung verschwunden sein und mit sowas verschwende ich nicht meine kostbare Zeit. Vergleiche einfach mal mit der Verbesserung über die Zeit bei anderer EDA SW, wie wenig wirklich neues hinzukommt und wieviel Bugs ausgeräumt werden müssen, die die Anwender nerven. Das willst du dir nicht freiwillig antun. Und achte mal darauf, wer welche Ausreden benutzt, um die SW des TE erst gar nicht anzufassen.
Jörg W. schrieb: > Possetitjel schrieb: >> Mit "modularisiert" meine ich nicht "Quelltext besteht >> aus mehreren Teilen", sondern: alle missionskritischen >> Interfaces (Dateiformate, ggf. auch APIs) sind offengelegt >> und werden aktiv gepflegt. > > Leute, die Opensource Datenmodelle abstrahieren, sind halt > noch deutlich dünner geseht als Opensource-Programmierer. > Programmieren macht Spaß, diejenigen, denen das Pflegen > von Datenmodellen so viel Spaß macht, dass sie dies auch > noch in ihrer Freizeit tun, dürfte es nur wenige geben. Das ist eine sehr interessante Antwort. Bitte korrigiere mich, wenn ich Dich missverstehe. -- Ich lese aus Deiner Anwort drei Gedanken heraus (oder inter- pretiere sie hinein -- wie man will): 1. Du bietest eine Erklärung für den von mir geschilderten Sachverhalt an. Das bedeutet implizit, dass Du meine Darstellung (dass sich nämlich niemand wirklich um die Interoperabilität über Projektgrenzen hinweg schert) im Kern für zutreffend hältst. 2. Du widersprichst meinem Wunsch nach mehr Interoperabilität nicht. Das heißt für mich: Hier spricht nicht (nur) meine subjektive, völlig fehlgeleitete Wahrnehmung, sondern hier steckt möglicherweise ein WIRKLICHES Problem, mit dem noch andere Leute außer mir kämpfen. 3. Im Grunde hast Du ja nur die Binsenweisheit "FOSS- Programmierer programmieren genau das, was sie selbst haben und benutzen wollen" auf den konkreten Fall angewendet. (Die Formel scheint mir im Großen und Ganzen auch zuzutreffen; sie erklärt zumindest, warum es deutlich mehr Compiler als fehlerfreie WYSIWYG-Bürosoftware gibt.) Daraus ergibt sich: Die Chancen, Mitglieder des Kernteams eines Projektes zu mehr Interoperabilität zu überreden, sind begrenzt. Dinge, die fehlen, werden eher ins eigene Projekt aufgenommen, als die Möglichkeit zu schaffen, sie "außerhalb" zu erledigen. Man müsste also von außen her, d.h. als Nicht-Projektmitglied sehen, was man tun kann.
Leute, Leute schrieb: > Possetitjel schrieb: >> Ist Dir das Diffamieren fremder Leistungen tatsächlich SO >> wichtig, dass am Ende keine Energie mehr über bleibt, ein >> Sachargument zu formulieren? > > Ich diffamiere hier niemandem. Hmm. Lass mich bitte als Vorrede folgendes feststellen: Ich bin infolge gewisser Akkumulation von Lebenserfahrung inzwischen ein Verfechter des Prinzips "Erkläre nichts durch bösen Willen, was durch Blödheit hinreichend erklärt ist". Daher bemühe ich mich weiterhin, Dir keine pure Lust an der Beleidigung zu unterstellen, sondern gehen davon aus, dass Du TATSÄCHLICH NICHT MERKST, dass jeder zweite Satz von Dir eine Unverschämtheit ist. > Mal abgesehen davon, was erwartest du? Reden wir mal nicht von "erwarten", bleiben wir bei "wünschen": Ich wünsche mir, dass Du beginnst, zwischen Deinem persönlichen Frust auf der einen und den Sachargumenten auf der anderen Seite zu unterscheiden. > Ich gab meine Meinung dazu ab und Meinungsfreiheit besteht > doch hoffentlich noch oder etwa nicht mehr?! Die Meinungsfreiheit besteht aber "leider" auch für die Leute, die Dich für einen Rüpel und Pöbelmeier halten und dies auch deutlich zum Ausdruck bringen. > Vergleiche einfach mal mit der Verbesserung über die Zeit > bei anderer EDA SW, wie wenig wirklich neues hinzukommt und > wieviel Bugs ausgeräumt werden müssen, die die Anwender > nerven. Das willst du dir nicht freiwillig antun. Das ist ja eine durchaus zutreffende Beobachtung. Auch wenn ich den Frust (vermutlich besser, als Du glaubst) verstehen kann -- bist Du WIRKLICH der Meinung, Lukas hört Dir zu, wenn Du ihn im Wesentlichen mit Beleidigungen überschüttest? Vergessen wir nicht: Er hat diesen Faden aufgemacht, um sein Projekt vorzustellen. > Und achte mal darauf, wer welche Ausreden benutzt, um die > SW des TE erst gar nicht anzufassen. Schon wieder: "Ausreden". Du unterstellst SOFORT Unredlichkeit, ohne auch nur den Versuch zu unternehmen, den Gegenüber zu verstehen (nein, ich meine nicht "auf nette Weise Verständnis heucheln", ich meine: Echtes Verstehen. Ganz altmodisch.) So -- abseits der Formfragen: Du machst meiner Meinung nach einen Fehler, wenn Du kommerzielle und freie Software in einen Topf wirfst. Natürlich sind die Probleme für den Anwender in beiden Fällen dieselben -- nämlich mangelnde Interoperabilität unterschiedlicher Produkte. Die Ursachen sind aber verschieden: Bei kommerzieller Software ist der "Vendor-lock-in" gewolltes und erklärtes Ziel; man umschreibt das höflich als "Kunden- bindung". Bei freier Software ist es lediglich die Folge der Mentalität der Programmierer. Ich halte diesen kleinen, aber feinen Unterschied für wichtig: Es ist eine Sache, wenn Programmierer nicht unbedingt von sich aus auf Interoperabilität hinarbeiten -- wer in einem Projektteam mitarbeitet, will ja DIESES Projekt voranbringen, und nicht dafür sorgen, dass der Anwender ebensogut auch eine andere Software benutzen kann :) Eine völlig andere Geschichte wäre es aber, sich der Zusammen- arbeit mit dem "EDA Interoperability Project" zu verweigern, wenn es denn ein solches gäbe. Das ist meiner Meinung nach der Punkt, an dem man ansetzen muss.
Stefan S. schrieb: > Possetitjel schrieb: >> Ich spiele gelegentlich damit herum. -- Das Projekt [gEDA] >> scheint sich totgelaufen zu haben. Kennt jemand Hintergründe? > > Da gibt es eine vielzahl von Gründen. [...] Danke; ungefähr so etwas hatte ich vermutet. > Wobei es seit gut einem Jahr wohl ein neues Project PCB-RND > bzw. gEDA-RND gibt. Tausend Dank für diesen Hinweis. Es scheint so zu sein, dass es das Projekt faktisch seit ungefähr 2013 gibt, nur "offiziell" ist der Fork erst seit Kurzem. Verblüffend: Für pcb-rnd gibt's ein Debian-Paket (ab 9.x). Das Kernteam ist zwar mit 8 Leuten ziemlich klein, scheint aber aktiv zu sein. Noch ist also nicht alles verloren :) Mal schauen.
Possetitjel schrieb: > Lass mich bitte als Vorrede folgendes feststellen: Ich > bin infolge gewisser Akkumulation von Lebenserfahrung > inzwischen ein Verfechter des Prinzips "Erkläre nichts > durch bösen Willen, was durch Blödheit hinreichend erklärt > ist". Deine Lebensweisheiten behalte bitte für dich. > Daher bemühe ich mich weiterhin, Dir keine pure Lust an > der Beleidigung zu unterstellen, sondern gehen davon aus, > dass Du TATSÄCHLICH NICHT MERKST, dass jeder zweite Satz > von Dir eine Unverschämtheit ist. Deine Unterstellung ist eine Unverschämtheit. Greife dir bitte mal an die eigene Nase. >> Mal abgesehen davon, was erwartest du? Hier in diesem Forum erwarte ich absolut nichts mehr. Ich gebe hier dann und wann nur noch meine Meinung zum besten. > Reden wir mal nicht von "erwarten", bleiben wir bei "wünschen": > > Ich wünsche mir, dass Du beginnst, zwischen Deinem persönlichen > Frust auf der einen und den Sachargumenten auf der anderen > Seite zu unterscheiden. Schon wieder eine Unterstellung. Merkst du eigentlich, dass du hier anderen den Umgangston anmahnst und selber zu Unverschämtheiten greifst? >> Ich gab meine Meinung dazu ab und Meinungsfreiheit besteht >> doch hoffentlich noch oder etwa nicht mehr?! > > Die Meinungsfreiheit besteht aber "leider" auch für die > Leute, die Dich für einen Rüpel und Pöbelmeier halten und > dies auch deutlich zum Ausdruck bringen. Ich will dir mal was sagen, wenn man hier nicht mal mehr feststellen kann, dass gewisse YouTube Videos einfach eine Zumutung sind, dann ist es traurig um uns alle bestellt. Seid ihr inzwischen so vergutmenschelt, so empfindlich geworden, dass man euch das nicht mehr sagen darf? Ist dieses Land mittlerweile total verweichlicht? Auf der anderen Seite reagieren Gutmenschen wie ihr bei jeder kleinen Kritik dann sofort mit Schaum vorm Mund und Beleidigungen. Wie reagierst du denn beispielsweise, wenn ein talentloser Sänger auf der Bühne meint er sei ein toller Hecht. In Wahrheit aber ist der Kerl nur eine akustische Zumutung. Lobst du ihn dann vor deinen Kumpels über Klee, weil er's "doch irgendwie probiert hat und dafür Anerkennung verdient"? Meinst du, du tust so einem Menschen damit einen Gefallen? > bist Du WIRKLICH der Meinung, Lukas hört Dir zu, wenn > Du ihn im Wesentlichen mit Beleidigungen überschüttest? Nochmal zum Mitschreiben für dich, ich habe hier niemanden beleidigt. Ich habe bloß zwei Dinge angemerkt, nämlich 1. der Vortrag tut mir in den Ohren weh (zu deinem Trost, die meisten Youtuber können keine gescheiten Vorträge abliefern) 2. ein 1-Mann-EDA-Projekt wird NIEMANLS was werden. Dazu ist EDA-Software einfach zu komplex. Wo ist da bitte jetzt die Beleidigung? > Vergessen wir nicht: Er hat diesen Faden aufgemacht, um sein > Projekt vorzustellen. Und wozu dann, wenn ihn Kommentare nicht interessieren? Geht's ihm dann um Lobhudelei? Wir sind hier nun mal nicht auf bzw. in der Walldorfschule. Zwischen gut gemeint und gut gemacht liegt oftmals ein großer und entscheidender Unterschied. Wer so viel Zeit und Power über hat sollte die besser für sinnvolleres einsetzen (was er natürlich darf, aber ich muss es ja nicht gut finden oder?!). Da es aber wie meistens völlig sinnlos ist hier weiter zu kommentieren beenden wir das Thema halt. Die Zeit wird zeigen wer recht behält. Hier ist übrigens schon mal einer erschienen der (angeblich) eine EDA SW erstellen wollte. Daraus wurde auch nix.
Leute, Leute schrieb: >> Lass mich bitte als Vorrede folgendes feststellen: Ich >> bin infolge gewisser Akkumulation von Lebenserfahrung >> inzwischen ein Verfechter des Prinzips "Erkläre nichts >> durch bösen Willen, was durch Blödheit hinreichend erklärt >> ist". > > Deine Lebensweisheiten behalte bitte für dich. Aber Deine eigene Lebenserfahrung soll hier als guter Rat taugen? Warum nur Deine, aber nicht die von Possetitjel oder Jörg? Doppelmoral? > Deine Unterstellung ist eine Unverschämtheit. Greife dir bitte mal an > die eigene Nase. Der Ton macht die Musik, und Du hast den Ton zuerst angeschlagen. > 1. der Vortrag tut mir in den Ohren weh (zu deinem Trost, die meisten > Youtuber können keine gescheiten Vorträge abliefern) Ich tue mir Videos nur im Notfall an. Text/Grafik ist mir lieber. Videos erfordern eine zu hohe Konzentration. > 2. ein 1-Mann-EDA-Projekt wird NIEMANLS was werden. Dazu ist > EDA-Software einfach zu komplex. Als Projekt sicher nicht. Trozdem wird derjenige, der sich in dieser Form damit befasst, eine Menge lernen. 1) Über Programmieren 2) Darüber, wie Schaltungen entwickelt werden, und wie man Platinen layoutet. 3) Wie Platinen in der Fabrik hergestellt werden 4) Über sich selber. Unter diesen Aspekten sehr sinnvoll. > Wo ist da bitte jetzt die Beleidigung? Die steckt im Tonfall und in Deiner Missachtung der Tatsache, dass es noch andere als die von Dir angeführten Gründe gibt. ;O) > Wir sind hier nun mal nicht auf bzw. in der Walldorfschule. Und das ist auch gut so <grusel> ....trozdem macht auch hier der Ton die Musik, und wenn Du halt als testosteronschwangerer Vollmacho rumtrötest, musst Du Dich wegen des Zurücktrötens nicht wundern. Wenn ein Hirsch im Wald röhrt, wird schon ein anderer antworten. ;O) Nicht das mich der Krach stört, aber konstruktiv ist halt was anderes. > Wer so viel Zeit und Power über hat sollte die besser für > sinnvolleres einsetzen (was er natürlich darf, aber ich muss es ja nicht > gut finden oder?!). Es steht Dir nicht an, darüber zu Urteilen, wie andere Leute ihr Leben einrichten. Abgesehen davon, das es viele verschiedene gleichberechtigte Ansichten geben wird, spielt da viel zu viel Zufall und Kompromiss hinein, um ein Hineinreden zu rechtfertigen. Wir alle kennen die Deteils der Hintergründe und Randbedingungen des TO nicht. Dein Rat könnte zwar möglicherweise willkommen sein, aber wer in diesem Tonfall rät, will in wirklichkeit Kommandieren. Persönlich sehe ich es eher als Hybris, wenn man den Versuch macht, sein Leben zu planen. > Die Zeit wird zeigen wer recht behält. Hier > ist übrigens schon mal einer erschienen der (angeblich) eine EDA SW > erstellen wollte. Daraus wurde auch nix. Na und? Ich habe auch mal mit sowas herumgespielt. Ist stecken geblieben. War aber lehrreich und hat Spass gemacht. Jetzt habe ich es auch seit Jahren nicht mehr angefasst, obwohl es mich hin und wieder kitzelt. Und, wenn die Umstände günstiger (oder ungünstiger, interpretationsfrage) sind, mache ich das vieleicht auch wieder. Ich habe aber auch nie erwartet, dass etwas grossartiges dabei heraus kommt.**) Damit Du nicht meinst, ich wüsste nicht, wovon ich spreche, hier der Link darauf: https://www.mikrocontroller.net/wikifiles/5/5a/PyGerberAnalyse_B5_13Jun2013.zip Leute, Leute schrieb: > Mir reichen übrigens meine Quirks bei Diptrace. Mit denen kann ich > einigermaßen leben. Liegt hier der Hase im Pfeffer? Machst Du in Wirklichkeit Werbung auf eine unterschwellige Art und Weise? ;O) Irgendwie habe ich aber den Verdacht, als Werbung ist das auch ein Schuss in den Ofen. ;O) **) Immerhin hätte ich durch die Beschäftigung damit zweimal fast eine Stelle bekommen. ;O) Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
:
Bearbeitet durch User
Hallo Lukas, Ich habe mit WIN7 und WIN10 getestet. Ich wollte in Rules -> Copper Clearance die 0,1mm ändern. Seit dem Versuch sind da nur noch 0.000mmm egal welche Zahl ich eintippe. Im Layout werden dadurch pads und traces in planes nicht mehr ausgespart. Übrigens scheint die eingebaute Abstandsfunktion fälschlicher Weise die Mitte der Traces zu nehmen statt deren Rand. Das ist jetzt für mich nicht tragisch, weil ich eh nur die Bedienung teste. Gibt es eine Liste welche Funktionen nicht gehen aber bereits ein Fenster öffnen? Dein Demo-Projekt funktioniert nicht in WIN7,10. Da kommt die Fehlermeldung: Error opening project parse error - unexpected '<' OK Gruß Helmut
> Ich wollte in Rules -> Copper Clearance die 0,1mm ändern. Seit dem
Versuch sind da nur noch 0.000mmm egal welche Zahl ich eintippe.
Hab mal nochmals versucht den Wert zu ändern. Ergebins: Man kann nur
ganze Millimeter eingeben, z. B. 1, 2... bis 100mm. 1mm will ich
natürlich da nie haben. Scheint ein echter Bug zu sein.
:
Bearbeitet durch User
Ins Blaue gefragt: Könnte das ein Dezimalpunkt ./. Dezimalkomma-Problem sein? Versuch mal, statt "0.1" "0,1" einzugeben, oder umgekehrt.
Rufus Τ. F. schrieb: > Ins Blaue gefragt: Könnte das ein Dezimalpunkt ./. Dezimalkomma-Problem > sein? Versuch mal, statt "0.1" "0,1" einzugeben, oder umgekehrt. Hallo Rufus, danke, das hat geholfen. Wenn ich 0,2 eintippe statt 0.2, dann funktioniert es. Angezeigt wird dann 0.200.
Angehängte Dateien:
-
trace_on_polygon.PNG
3,2 KB
1. > Übrigens scheint die eingebaute Abstandsfunktion fälschlicher Weise die Mitte der Traces zu nehmen statt deren Rand. Diese Aussage ziehe ich zurück. Der Abstand wird richtig berechnet. Dafür habe ich ein anderes Problem. Wenn ich in dem Fall im angehängten screenshot ein Update Planes mache, dann bleibt von dem gefüllten Polygon nur noch eine einzige vertikale Linie an dessen ursprünglich linkem Rand übrig. Auch ein erhöhen der Priorität hat da nicht geholfen. Was mache ich da falsch? 2. > KiCad's awesome push'n shove router Bei mir schiebt wird da nichts geschoben. Wo schaltet man den in horizon ein?
:
Bearbeitet durch User
Das mit den Dezimaltrenner ist nun repariert. Helmut S. schrieb: > 1. > >> Übrigens scheint die eingebaute Abstandsfunktion fälschlicher Weise die > Mitte der Traces zu nehmen statt deren Rand. > > > Diese Aussage ziehe ich zurück. Der Abstand wird richtig berechnet. > > Dafür habe ich ein anderes Problem. Wenn ich in dem Fall im angehängten > screenshot ein Update Planes mache, dann bleibt von dem gefüllten > Polygon nur noch eine einzige vertikale Linie an dessen ursprünglich > linkem Rand übrig. Auch ein erhöhen der Priorität hat da nicht geholfen. > Was mache ich da falsch? > Ich kann jetzt auf dem Bild nicht erkennen, zu welchen Netzen der Track da rechts und die Plane gehören. Gehören die zum selben Netz? Wenn ja, muss die Mittellinie das Tracks (derzeit) innerhalb (nicht auf der Kante) des Polygons liegen, damit die als verbunden erkannt werden. Wenn die Plane sonst nirgendwo angeschlossen ist, wird die nicht gefüllt, wenn orphans deaktiviert sind. > 2. > >> KiCad's awesome push'n shove router > > Bei mir schiebt wird da nichts geschoben. > Wo schaltet man den in horizon ein? Die Shove-Funktionalität wird derzeit von horizon noch nicht unterstützt, ich hab' mal die Doku angepasst... Helmut S. schrieb: > Dein Demo-Projekt funktioniert nicht in WIN7,10. Da kommt die > Fehlermeldung: > Error opening project > parse error - unexpected '<' Seltsam, in der Projektdatei ist kein '<' enthalten: https://github.com/carrotIndustries/horizon-test-project/blob/master/pic32-eth.hprj Hast du auch das Zip heruntergeladen und entpackt? Das '<' sieht mir doch nach einer HTML-Datei aus.
Hallo, welche Abhängigkeit bringt die profile.h Datei mit?
1 | [ 118s] router/router/pns_shove.cpp:44:10: fatal error: profile.h: No such file or directory |
2 | [ 118s] #include <profile.h> |
3 | [ 118s] ^~~~~~~~~~~ |
Gruß, Frank
:
Bearbeitet durch User
Frank K. schrieb: > Hallo, > > welche Abhängigkeit bringt die profile.h Datei mit? > >
1 | > [ 118s] router/router/pns_shove.cpp:44:10: fatal error: profile.h: No |
2 | > such file or directory |
3 | > [ 118s] #include <profile.h> |
4 | > [ 118s] ^~~~~~~~~~~ |
5 | > |
> > Gruß, > Frank Ist entfernt, war ein Überbleibsel aus dem KiCad-Tree, der auf meinem System dann wohl von Kerberos bereitgestellt wurde...
Hallo Lukas, 1. Das mit dem Update Planes funktioniert jetzt auch mit den traces entlang und in der plane. Am Anfang ging es nicht. Vielleicht habe ich einfach etwas falsch bedient. 2. > Seltsam, in der Projektdatei ist kein '<' enthalten: https://github.com/carrotIndustries/horizon-test-p... Hast du auch das Zip heruntergeladen und entpackt? Das '<' sieht mir doch nach einer HTML-Datei aus. Ich habe das Demo-Projekt als Einzeldateien heruntergeladen. Wo gibt es da einen zip-file? 2. Wo ist eigentlich das GND-Symbol im Schaltplaneditor? Ich finde es nicht.
:
Bearbeitet durch User
Helmut S. schrieb: > Hallo Lukas, > > 1. > Das mit den Update Planes funktioniert jetzt auch mit den traces entlang > und in der Plane. Am Anfang ging es nicht. Vielleicht habe ich einfach > etwas falsch bedient. Ist in der aktuellsten Version auch repariert ;) > > 2. >> Seltsam, in der Projektdatei ist kein '<' enthalten: > https://github.com/carrotIndustries/horizon-test-p... > Hast du auch das Zip heruntergeladen und entpackt? Das '<' sieht mir > doch nach einer HTML-Datei aus. > > > Ich habe das Demo-Projekt als Einzeldateien heruntergeladen. > Wo gibt es da einen zip-file? https://github.com/carrotIndustries/horizon-test-project Bei dem grünen Knopf "Clone or Download" gibt es die Option "Download ZIP". > > 2. > Wo ist eigentlich das GND-Symbol im Schaltplaneditor? Ich finde es > nicht. Die GND-Symbole sind deutlich anders gelöst als in anderen Applikationen: https://github.com/carrotIndustries/horizon/wiki/Schematic-editor#power-symbols
Compilieren geht soweit, jedoch weigert sich rpmbuild ein Package zu erstellen da noch ein paar Warnings im Code sind:
1 | [ 313s] I: Program is using uninitialized variables. |
2 | [ 313s] Note the difference between "is used" and "may be used" |
3 | [ 313s] W: horizon uninitialized-variable dxflib/dl_entities.h:1449 |
4 | [ 313s] |
5 | [ 313s] I: Program returns random data in a function |
6 | [ 313s] E: horizon no-return-in-nonvoid-function rules/rule_match.cpp:90 |
7 | [ 313s] |
8 | [ 313s] I: Program returns random data in a function |
9 | [ 313s] E: horizon no-return-in-nonvoid-function rules/rule_match.cpp:90 |
Gruß, Frank
Horizon is a free EDA package ... Nach Monaten des Schweigens kommt dieses Horizon wieder in die Diskussion. Na fein, sagt unsereiner sich... ..aber wenn man sich mal die zugehörige Seite "https://github.com/carrotIndustries/horizon"; anschaut, dann landet man in einer hoffnungslos mit LowLevel-Details überfrachteten Seite. Wo ist da der Anfang? Wo ist da die nötige Struktur? Erwartet der Autor, daß man sich als eventueller Interessent durch alle Details (block, board, canvas, canvas3d, clipper, ...) durchwühlt? Nee, Leute. So wird das nix bis ewig. Ein simples blinky.c kann jeder auch ohne jegliche Projektplanung schreiben, aber bei einem Projekt wie ein komplettes EDA-System es darstellt, braucht es ganz am Anfang ein gut durchdachtes und schriftlich fixiertes Konzept und die Struktur des Ganzen. Wer das nicht formulieren will oder kann, der wird unweigerlich scheitern. Und wenn man dann sowas lesen darf: "Seems like people really want to have Windows binaries, so I made some: horizon-zip" ...dann vergeht einem die Lust, die 34 MB herunterzuladen und eventuell sogar auch noch auszuprobieren. Also: Es fehlt das Konzept. Mal wieder. Ich hatte dies ja bereits bei Diptrace angemahnt, später ebenfalls bei Kicad. Aber es ist wohl immer so bei hochambitionierten Programmierern, daß sie ihr Baby nur nach ihren eigenen Gesichtspunkten bepflegen, keinen wirklichen Blick für die eventuellen Anwender haben und auf die Frage nach ihrem Konzept mit persönlicher Beleidigtheit reagieren. Also Horizon ist offenbar dediziert NICHT für Windows-Benutzer gedacht. Auch eine echte Darstellung, wie Horizon denn überhaupt funktioniert, also wie das Zusammenspiel zwischen Schematics, Layout und anderen Teilen wie Bibliotheken, Rulechecks (erc, drc, hf, therm, usw.) organisiert ist, glänzt durch vollständige Abwesenheit. Von einem User-Manual will ich erst garnicht reden. Auch von angedachten Interfaces zu Dingen, die über den gewöhnlichen Kram hinausgehen, wie z.B. distributed elements, Feldanalysen usw. kann man nichts lesen. Jaja, unsereiner wäre durchaus an einem ECAD interessiert, das wenigstens ansatzweise die Dinge, die man mit Ansoft oder Sonnet sich gestalten kann, importieren oder wenigstens nachbilden kann. Aber das wären ja wieder Dinge aus der vernachlässigbaren Windows-Ecke... Nein, Horizon ist keineswegs "a free EDA package", sondern bislang nur ne Art Fingerübung die so tut, als ob sie sowas wäre. Der einzigen Rat, den ich hier geben könnte würde lauten: der/die Autoren täten besser, wenn sie ihre Arbeitskraft einsetzen würden, um Kicad vom Kopf auf die Füße zu stellen, also dessen Geburtsfehler ausmerzen. Das wäre zielführender. W.S.
Frank K. schrieb: > Compilieren geht soweit, jedoch weigert sich rpmbuild ein Package zu > erstellen da noch ein paar Warnings im Code sind: Sind repariert.
Hallo Lukas, mit dem zip-download funktioniert das Demo-design. Das Power-Symbol für GND bekomme ich jetzt auch hin nach deinem letzten Hinweis. Die clearance rules werden jetzt mit',' angezeigt. Ich möchte bei einigen traces die Breite ändern. Warum ist eigentlich im Layout das Feld für Track->width grau(nicht änderbar)? Gruß Helmut
:
Bearbeitet durch User
Helmut S. schrieb: > Warum ist eigentlich im Layout das Feld für Track->width grau(nicht > änderbar)? Das liegt daran, dass der Schalter "Width from rules" an ist. Damit werden die Leiterbahnbreiten entsprechend der Regeln unter "Track Width" gesetzt. Wie bei allen anderen Regeln auch wird die angewendet, die als erstes zutrifft.
Lukas K. schrieb: > Helmut S. schrieb: >> Warum ist eigentlich im Layout das Feld für Track->width grau(nicht >> änderbar)? > > Das liegt daran, dass der Schalter "Width from rules" an ist. Damit > werden die Leiterbahnbreiten entsprechend der Regeln unter "Track Width" > gesetzt. Wie bei allen anderen Regeln auch wird die angewendet, die als > erstes zutrifft. Danke, darauf hätte ich selber kommen sollen. :-) Das Kupfer geht ja bis zur Boardkante bei dem Demoboard. Das solltest mal ändern und z. B. 0,8mm Abstand einbauen. Muss dazu die GND-plane verkleinert werden oder gibt es eine "routing outline"?
:
Bearbeitet durch User
Für Windows-Benutzer Hier loslegen https://github.com/carrotIndustries/horizon Ganz unten auf der Seite "Getting Started" > See the "wiki" Dann ist man hier. https://github.com/carrotIndustries/horizon/wiki/Getting-started "Get Horizon" Windows -> "here" -> horizon.zip -> neueste Version nehmen. Die zip-Datei in einem beliebigen Verzeichnis entpacken, z. B. C:\horizon Wieder auf diese Seite gehen: https://github.com/carrotIndustries/horizon/wiki/Getting-started Get the pool -> download the zipped pool Auch in C:\horizon speichern und dort entpacken. https://github.com/carrotIndustries/horizon/wiki/Getting-started "Open the project manager" C:\horizon\horizon\horizon-prj-mgr.exe starten. Siehe Wiki wie man den "pool" anlegt. Dabei dort pool.json in C:\horizon\horizon-pool-master wählen. C:\horizon\horizon-pool-master Jetzt kann man entweder mit einem Schaltplan starten. Am besten erst noch das Demo-Design laden. Den Link zum Demo-Design gibt es unter "Example project". https://github.com/carrotIndustries/horizon-test-project "Clone or download" wählen -> Download zip Den in C:\horizon speichern und auspacken. Open Project -> C:\horizon\horizon-test-project-master\pic32-eth.hprj Jetzt auf Top Schematic und/oder Board klicken.
:
Bearbeitet durch User
W.S. schrieb: > Ein simples blinky.c kann jeder auch ohne jegliche > Projektplanung schreiben, aber bei einem Projekt wie > ein komplettes EDA-System es darstellt, braucht es > ganz am Anfang ein gut durchdachtes und schriftlich > fixiertes Konzept und die Struktur des Ganzen. Naja, was hältst Du von folgender Interpretation: Du brauchst (genauso wie ich) für alles, was komplizierter als blinky.c ist, ein durchdachtes Konzept. Lukas hat (nach eigener Aussage) bisher 26'000 Zeilen Code geschrieben (und brauchte offenbar kein Konzept). Also ist "horizon" für Lukas nicht komplizierter als für uns blinky.c. Betrüblich für uns, aber erfreulich für Lukas :) > Also: Es fehlt das Konzept. Mal wieder. Ich hatte dies ja > bereits bei Diptrace angemahnt, später ebenfalls bei Kicad. Niemand will Probleme. Alle wollen Lösungen. Gilt auch für Programmierer. Und im Hobby will man sich ganz sicher von niemandem mahnen lassen. > Aber es ist wohl immer so bei hochambitionierten > Programmierern, daß sie ihr Baby nur nach ihren eigenen > Gesichtspunkten bepflegen, keinen wirklichen Blick für > die eventuellen Anwender haben Entschuldigung: Hat Lukas IRGENDWO zugesichert, dass er Dich, mich oder die Welt mit seinem Programm glücklich machen will? Ich wüsste nicht, wo. Er sagt in seinem Vortragsvideo nur: Er sei mit den vorhandenen EDA-Programmen nicht zufrieden gewesen und hätte daher begonnen, sein eigenes zu schreiben. Genau das tut er. Jetzt braucht er Tester, und deswegen bittet er darum, das Programm zu testen. > Auch eine echte Darstellung, wie Horizon denn überhaupt > funktioniert, Wozu? Hat Lukas IRGENDWO um Hilfe beim Programmieren gebeten? > Nein, Horizon ist keineswegs "a free EDA package", sondern > bislang nur ne Art Fingerübung die so tut, als ob sie sowas > wäre. Hältst Du es für denkbar, dass Deine Ansicht darüber, was ein "free EDA package" können muss, NICHT die einzig richtige ist? > Der einzigen Rat, den ich hier geben könnte würde lauten: > der/die Autoren täten besser, wenn sie ihre Arbeitskraft > einsetzen würden, um Kicad vom Kopf auf die Füße zu stellen, > also dessen Geburtsfehler ausmerzen. Das wäre zielführender. Habe ich das richtig verstanden: Es wäre das Beste für Lukas, wenn er die Software programmieren würde, die W.S. gerne haben will? Nee, also ganz ehrlich: Für die Software, die DU gerne haben willst, musst schon DU SELBST das Projekt auf die Beine stellen. (Das bedeutet nicht zwingend, dass Du auch alles selbst programmieren musst.)
Helmut S. schrieb: > Das Kupfer geht ja bis zur Boardkante bei dem Demoboard. Das solltest > mal ändern und z. B. 0,8mm Abstand einbauen. Muss dazu die GND-plane > verkleinert werden oder gibt es eine "routing outline"? Genau da bin ich gerade dran ;) Aus der "Clearance Copper - NPTH"-Regel wird eine "Copper - Non copper Regel", die dann den Abstand von Kupferdingen, wie Track, Plane, etc. zu Nicht-Kupferdingen wie NPTH-Löchern und eben Boardkante beschreibt.
Possetitjel schrieb: > Lukas hat (nach eigener Aussage) bisher 26'000 Zeilen Code > geschrieben (und brauchte offenbar kein Konzept). Wer sagt denn, dass er kein Konzept hat? Ein solches muss ja nicht zwingend irgendwo aufgeschrieben sein, vor allem dann nicht, wenn man es als One-Man-Show startet. Dafür reicht ein Konzept im Kopf völlig aus. Auch KiCad ist mal als One-Man-Show gestartet worden … Wenn ich mal mein OS (und damit auch den Compiler) aktualisiert habe, schau ich mir Horizon auf jeden Fall auch mal an. Vermutlich wird Lukas dann von mir als erstes einen Satz Patches für FreeBSD erhalten. :-)
Jörg W. schrieb: > Auch KiCad ist mal als One-Man-Show gestartet worden … Das wollte ich gerade schreiben. Bis auf sehr wenige Teile, die von seinen Studenten beigesteuert wurden, hat der gute Jean-Pierre das bis 2006 ganz alleine aus dem Boden gestampft. Und 2006 war es definitiv benutzbar, denn zu dem Zeitpunkt bin ich damals von Eagle zu Kicad gewechselt (u.a. wegen fehlender Hierarchie-Möglichkeiten) und habe nicht wirklich etwas vermisst - insbesondere nicht die Einschränkungen bei Eagle ;-) Es ist wie immer: viele reden und haben überall Bedenken - und die anderen fangen einfach mal an. Also: dass man für eine brauchbare ECAD-Software ein vielköpfiges, permanentes Entwicklerteam benötigt, ist offenbar falsch. > Wenn ich mal mein OS (und damit auch den Compiler) aktualisiert habe, > schau ich mir Horizon auf jeden Fall auch mal an. Vermutlich wird > Lukas dann von mir als erstes einen Satz Patches für FreeBSD erhalten. > :-) Wir sind mit Kicad zufrieden, aber trotzdem ist das ein tolles Projekt. Hut ab vor Deiner Leistung, Lukas!
Jörg W. schrieb: > Wer sagt denn, dass er kein Konzept hat? > > Ein solches muss ja nicht zwingend irgendwo aufgeschrieben sein, > vor allem dann nicht, wenn man es als One-Man-Show startet. Dafür > reicht ein Konzept im Kopf völlig aus. Genau so ist's. Das "Konzept" ist ja auch nichts feststehendes, sondern mehr etwas, das sich im Laufe der Zeit an neue Gegebenheiten und Gelerntes anpasst. Was aufgeschriebenes wäre derzeit eh nach kürzester Zeit veraltet. Führt halt dazu, dass man einige Dinge mehrfach grundlegend überarbeiten muss. Ganz ohne Plan läuft die Entwicklung auch nicht ab, siehe eine der letzten Folien aus dem Vortrag: Aktuelle / Zeitnahe Entwicklungen ================================= • DRC, Verbesserung des Routers Insb. ersteres ist geschehen. Ohne mir jetzt alle Opensource-EDA Applikationen im Detail angesehen zu haben, behaupte ich mal, mittlerweile, das leistungsfähigste und flexibelste Regelsystem zu haben. • Netzklassen aufräumen Ist geschen. • Layer erweitern Ebnefalls. • Kupferflächen füllen Auch. Zukunft ======= • ERC Gibt's noch nicht wirklich, ist auch mehr Arbeit als kompliziert zu implementieren. • 3D-Export/Darstellung 3D-Darstellung (ohne Bauteile) gibt's. Seit gestern auch mit Innenlagen. 3D-Export wird darauf hinauslaufen kicad2step zu portieren: https://github.com/KiCad/kicad-source-mirror/tree/master/utils/kicad2step • GUI für Pool, Entities, etc. Gibt's. • Parametrische Suche War noch nicht wichtig genug, ist aber auch mehr ein nice-to-have. • Integration des KiCAD-Routers Ist geschehen, wenn auch noch Dinge wie Routen von diffpairs und length-tuning noch nicht unterstützt werden. (Shove ist so gut wie fertig) Chris D. schrieb: > Hut ab vor Deiner Leistung, Lukas! Danke an dich und einige andere für die netten Worte!
Jörg W. schrieb: > Possetitjel schrieb: > >> Lukas hat (nach eigener Aussage) bisher 26'000 Zeilen >> Code geschrieben (und brauchte offenbar kein Konzept). > > Wer sagt denn, dass er kein Konzept hat? Och, Menno. Das sagt niemand -- das war nur eine notwendige Annahme, damit mein boshafter Vergleich funktioniert.
Angehängte Dateien:
-
HORIZON-IMP.PNG
97 KB
Hallo Lukas, in deiner neuesten Version für WIN stürzt horizon-imp.exe bei "Update Planes" ab. Bitte wieder lauffähig machen. Version: horizon-2017-10-23-1433.zip Gruß Helmut
Helmut S. schrieb: > in deiner neuesten Version für WIN stürzt horizon-imp.exe bei "Update > Planes" ab. Bitte wieder lauffähig machen. Bis die neue Version kompiliert ist, reicht's wenn du in den Rules bei Copper - Non-Copper Clearance was einträgst. Ohnehin sollte da was drin stehen, damit auch was sinnvolles verwendet wird.
Lukas K. schrieb: > Helmut S. schrieb: >> in deiner neuesten Version für WIN stürzt horizon-imp.exe bei "Update >> Planes" ab. Bitte wieder lauffähig machen. > > Bis die neue Version kompiliert ist, reicht's wenn du in den Rules bei > Copper - Non-Copper Clearance was einträgst. Ohnehin sollte da was drin > stehen, damit auch was sinnvolles verwendet wird. Hallo Lukas, danke. Damit funktioniert "Update Planes" wieder. Gruß Helmut
W.S. schrieb: > Horizon is a free EDA package ... > > Nach Monaten des Schweigens kommt dieses Horizon wieder in die > Diskussion. Na fein, sagt unsereiner sich... > > ..aber wenn man sich mal die zugehörige Seite > "https://github.com/carrotIndustries/horizon"; > anschaut, dann landet man in einer hoffnungslos mit LowLevel-Details > überfrachteten Seite. Links oben auf der Seite gibt's den Punkt Issues... > ... bei einem Projekt wie ein komplettes EDA-System es > darstellt, braucht es ganz am Anfang ein gut durchdachtes und > schriftlich fixiertes Konzept und die Struktur des Ganzen. Wer das nicht > formulieren will oder kann, der wird unweigerlich scheitern. Allumfassende, am besten noch perfekte Konzepte? Viel Spaß in der Realität... Im besten Fall gibt's genügend Zeit/Geld, um mehrere Iterationen zu machen, die sich dem annähern > Also: Es fehlt das Konzept. Mal wieder. Ich hatte dies ja bereits bei > Diptrace angemahnt, später ebenfalls bei Kicad. Aber es ist wohl immer > so bei hochambitionierten Programmierern, daß sie ihr Baby nur nach > ihren eigenen Gesichtspunkten bepflegen, keinen wirklichen Blick für die > eventuellen Anwender haben und auf die Frage nach ihrem Konzept mit > persönlicher Beleidigtheit reagieren. 1. Muss jemand die genannten Programme verwenden? 2. Gibt's Alternativen? 3. Wo ist dann das Problem? > Also Horizon ist offenbar dediziert NICHT für Windows-Benutzer gedacht. s.o. > ... > Auch von angedachten Interfaces zu Dingen, die über den gewöhnlichen > Kram hinausgehen, wie z.B. distributed elements, Feldanalysen usw. kann > man nichts lesen. Jaja, unsereiner wäre durchaus an einem ECAD > interessiert, das wenigstens ansatzweise die Dinge, die man mit Ansoft > oder Sonnet sich gestalten kann, importieren oder wenigstens nachbilden > kann. Aber das wären ja wieder Dinge aus der vernachlässigbaren > Windows-Ecke... 1. Seit wann sind Ansys bzw. Ansoft oder Sonnet Windows-only? 2. "It's far from finished" heißt, zumindest für mich, vielleicht Alpha-Version. Ob man noch Alpha dazuschreiben muss? Vielleicht gar nicht so verkehrt... 3. Ist das ganze Open Source und etwas Hilfe bspw. mit Links zu den Dateiformaten der genannten Systeme oder zu Libraries/Kovertierern, die damit umgehen können, wären vielleicht nicht schlecht. 4. In einer Alpha-Version würde ich so was nicht implementieren, da gibt's wichtigeres. Ansonsten siehe 3. und vielleicht einen netten Feature Request schreiben. > Nein, Horizon ist keineswegs "a free EDA package", sondern bislang nur > ne Art Fingerübung die so tut, als ob sie sowas wäre. Der einzigen Rat, > den ich hier geben könnte würde lauten: der/die Autoren täten besser, > wenn sie ihre Arbeitskraft einsetzen würden, um Kicad vom Kopf auf die > Füße zu stellen, also dessen Geburtsfehler ausmerzen. Das wäre > zielführender. Warum? Wenn einem Kicad bspw. nicht gefällt, warum sollte man dann dort Zeit investieren?
Arc N. schrieb: > Warum? Wenn einem Kicad bspw. nicht gefällt, warum sollte > man dann dort Zeit investieren? Den allerwenigsten gefällt GAR NICHTS an KiCAD. Wer aber den Schaltplaneditor von gEDA, den Layouteditor von KiCAD und die Bauteilverwaltung von Horizon verwenden will, ist angeschissen.
Sag mal Lukas, hast Du eigentlich schon eine Idee bezüglich Simulation? Ich habe da leider überhaupt nichts -- das ist auch einer der Gründe warum ich in den letzten Jahren an meinen Programmen nicht weitergearbeitet habe. Mit gEDA war Simulation mit Spice oder GnuCap ja sehr zäh. Ich vermute mal KiCad und sämtliche kommerziellen Programme unterstützen jetzt Simulation. Tina-Ti hatte ich mal kurz verwendet, das war schon recht gut nutzbar. (Leider war das Ergebnis völlig falsch, weil das Modell eines OP falsch war.) Ich vermute mal, dass Simulation heute ein entscheidendes Kriterium für eine EDA Software ist.
Das ist ein gutes Argument. Ich bin auch ehe dafür die Simulation mit KiCAD weiterzutreiben und dort zu investieren, als noch ein neues Programm aufzuziehen.
Ich würde das nicht zu sehr in den Vordergrund stellen. Es wäre natürlich nett, wenn man einen Simulator andocken könnte, aber mal ehrlich, sowie da ein Mikrocontroller oder sowas im Spiel ist, kannst du sowieso nie mehr alles simulieren, weil die Gesamtfunktion der Schaltung massiv von der Software abhängt. Dafür müsste man dann jeweils wieder Modelle in die Simulation einklinken können. Da hat es eher Sinn, einzelne Teilbaugruppen gelegentlich zu simulieren. Simulation ist ohnehin ein weites Feld. Der Anfänger will seinen Colpitts-Oszillator simulieren, der UHF-Entwickler dagegen wird das fertige Layout auf einem HF-Material simulieren wollen …
Stefan S. schrieb: > Sag mal Lukas, hast Du eigentlich schon eine Idee bezüglich > Simulation? Simulation ist wohl nicht geplant, siehe Vortrag: https://www.youtube.com/watch?v=OpwMhz_3Tbs&feature=youtu.be&t=18m35s 18:35
Stefan S. schrieb: > Sag mal Lukas, hast Du eigentlich schon eine Idee bezüglich > Simulation? Worauf zielt die Frage? Klassische Schaltungssimulation (konzentrierte Bauelemente) oder Simulation parasitärer Elemente im Layout? > Mit gEDA war Simulation mit Spice oder GnuCap ja sehr zäh. Was bedeutet das? > Ich vermute mal, dass Simulation heute ein entscheidendes > Kriterium für eine EDA Software ist. Also irgendwie verstehe ich die Welt nicht mehr... ist vemutlich eine Altersfrage... Ich verlange doch von meinem Oszi auch nicht, dass er Kaffee kocht, Kinderlieder singt, Bratkartoffeln brät und eine Bandbreite von 1GHz hat. Wenn ich einen Schaltplan zeichnen will, möchte ich ein Schaltplanzeichenprogramm nehmen. Wenn ich ein Layout entwickeln will, möchte ich einen Layouteditor starten. Wenn ich simulieren will, starte ich einen Simulator.
Possetitjel schrieb: > Wenn ich simulieren will, starte ich einen Simulator. Naja, es ist natürlich schon hübsch, wenn man den Schaltplan für eine Simulation nicht nochmal zeichnen muss, sondern den bereits im EDA-Tool gezeichneten dafür nehmen kann. Gleiches fürs Layout bezüglich einer EM-Feld-Simulation. Aber ich halte das auch eher für ein untergeordnetes Argument. Eine Simulation steht und fällt ohnehin mit den Modellen.
Possetitjel schrieb: > Wenn ich einen Schaltplan zeichnen will, möchte ich ein > Schaltplanzeichenprogramm nehmen. > Wenn ich ein Layout entwickeln will, möchte ich einen > Layouteditor starten. > Wenn ich simulieren will, starte ich einen Simulator. full ack! vor allem ist das schematic für die simulation sicher nicht ident mit dem für's layout. 73
Jörg W. schrieb: > Possetitjel schrieb: >> Wenn ich simulieren will, starte ich einen Simulator. > > Naja, es ist natürlich schon hübsch, wenn man den Schaltplan > für eine Simulation nicht nochmal zeichnen muss, sondern den > bereits im EDA-Tool gezeichneten dafür nehmen kann. Gleiches > fürs Layout bezüglich einer EM-Feld-Simulation. Na klar. Kompatible DATEIFORMATE setze ich eigentlich voraus; notfalls tut's ein funktionierender Export/Import. Aber genau DAS ist ja offensichtlich nicht gegeben. > Aber ich halte das auch eher für ein untergeordnetes Argument. > Eine Simulation steht und fällt ohnehin mit den Modellen. Naja... ich gehe schon soweit mit, dass Software, die praktisch anwendbar sein will, auch die in der Praxis auftretenden Arbeits- abläufe unterstützen muss. Ich vertrete aber die -- offenbar völlig veraltete -- Meinung, dass die Software MIR dienen soll, und nicht umgekehrt ich die Software loben, preisen und ihre Schlingen und Windungen besser und besser studieren muss.
Jörg W. schrieb: > aja, es ist natürlich schon hübsch, wenn man den Schaltplan für > eine Simulation nicht nochmal zeichnen muss, Das ist mit Verlaub nicht nur "hübsch" sondern essenziell! Bei einer größeren Schaltung möchte Ich nicht alles zweimal eingeben. Zumindest eine Netzliste muss exportierbar sein und dabei müssen vor allem die leeren, nicht vorhanden Bautteile als dummies mit verdrahtet sein, damit man sie in der Simulation direkt ersetzen kann.
Hans schrieb: > vor allem ist das schematic für die simulation sicher > nicht ident mit dem für's layout. Ja. Und das geht noch weiter. Viele Schaltpläne, die hier auf µC.net so vorgestellt werden, sehen einfach besch***en aus und sind eine Zumutung. Ich habe mal darüber nachgedacht, warum das so oft so ist, und bin zu dem Ergebnis gekommen, dass der klassische Schaltplan aus der Zeit der diskreten Bauelemente stammt: Relativ viele Bauteile, einfache, klar erkennbare Funktion für jedes Bauteil, wenige Anschlüsse an jedem Bauteil. Mikrocontroller oder FPGAs sind aber das genaue Gegenteil von diskreten Bauelementen. Der klassische Schaltplan ist also für diese Schaltungsteile vielleicht gar nicht die optimale Darstellungsform. Wünschenswert wäre vielleicht, dass man auch Daten in tabellarischer Form (Pinbelegungen z.B.) in die Software hineinfüttern kann. Aber damit ist natürlich NICHT gemeint, dass die EDA-Software ein "Spreadsheet-Plugin" bekommt, das sich selbstverständlich ganz anders bedient als Excel oder OOCalc und dessen Datenformat selbstverständlich zu nichts anderem auf der Welt kompatibel ist. Notwendig wäre, dass Daten, die heutzutage sowieso schon irgendwo (außerhalb der EDA-Software) anfallen, vernünftig weiterverarbeitet werden können.
Mar. W. schrieb: > Jörg W. schrieb: >> aja, es ist natürlich schon hübsch, wenn man den Schaltplan >> für eine Simulation nicht nochmal zeichnen muss, > > Das ist mit Verlaub nicht nur "hübsch" sondern essenziell! > Bei einer größeren Schaltung möchte Ich nicht alles zweimal > eingeben. Genau mein Reden. Nur muss das auch für die Schaltung gelten, die der Kollege vor fünf Jahren mit KiCAD entwickelt hat und die ich heute mit Horizon weiterentwickeln muss. Jeder Koch hat einerseits Bratpfannen und andererseits das Schnitzel. Nur die so moderne und fortschrittliche Software-Branche hält es für normal, dass man natürlich Meier-Schnitzel nur mit Meier-Eiern und Meier-Semmelbröseln verfeinern und auch NUR in Meier-Bratpfannen auf Meier-Herden mit Meier-Gas braten darf, wobei die Flamme mit Meier-Hölzern angezündet worden sein muss.
Possetitjel schrieb: > notfalls tut's ein funktionierender Export/Import. Darauf wird's hinauslaufen.
Simulation unmittelbar in horizon will ich in der Tat nicht haben. Horizon soll in erster Linie ein gutes Programm werden um Schaltpläne zu zeichnen und damit Boards zu machen. Erstmal nicht mehr. Warum schreit keiner, dass ERC noch vollständig fehlt, man keine differentiellen Leitungen routen kann, es keine Thermals in Flächen gibt, oder die Darstellung von Pad-Namen im Board noch sehr zu wünschen Übrig lässt? Was ich sagen will: Es mag sinnvoll sein, Simulation in das Tool, mit dem man auch Boards macht integriert zu haben. Derzeit gibt es aber noch unzählige andere Baustellen, Simulation wäre dann ein doch sehr aufwändiges I-Tüpfelchen. Daher spreche ich mich derzeit aktiv gegen jegliche Art von Simulations-Integration in horizon aus. Siehe auch: Wenn andere Programme (z.B. KiCad) nachwievor einen Schaltplaneditor haben, der keine Ahnung von Netzen hat und den Anwender Junctions nach Gutdünken platzieren lässt, aber schon dabei sind SPICE-Integration zu entwickeln liegt meines Erachtens der Fokus bei der Entwicklung falsch. Ja, Standards wären in der Tat schön, doch abgesehen von recht primitiven Spice-Netzlisten und Gerber gibt es in der Branche nichts wirklich brauchbares, was auch Anwendung findet. Possetitjel schrieb: > Wünschenswert wäre vielleicht, dass man auch Daten in > tabellarischer Form (Pinbelegungen z.B.) in die Software > hineinfüttern kann. Geht schon: https://github.com/carrotIndustries/horizon/wiki/Working-with-the-Pool-Manager-and-Part-Wizard#create-all-new-part Verbindungen nicht nur im Schaltplan zu zeichnen ist in der Architektur schon seit Anfang an vorgesehen, da in Horizon die Netzliste und nicht der Schaltplan die Primärquelle ist. Wenn z.B. an einem Netz ein Label hängt, drückt dieses Label nicht etwa dem Netzegment den eingetippten Namen auf, sondern zeigt eben den Name des Netzes an.
Lukas K. schrieb: > Simulation unmittelbar in horizon will ich in der Tat > nicht haben. Was bedeutet das? Also: Was soll "unmittelbar in horizon" bedeuten? 1. Interpretation: "Horizon bringt eigenen Simulator mit". Naja... also ich weiss nicht, wie KiCAD das tatsächlich macht, aber wenn die KiCAD-Leute in Anbetracht von gnucap, qucs, Spice, LTSpice... ihre eigene Numerik schreiben, dann haben sie nicht mehr alle Tassen im Schrank. Meine Meinung. Die Numerik komplett neu zu entwickeln, wenn es Simulatoren mit bereits etablierten und akzeptierten Schnittstellen gibt, die man integrieren kann, ist komplett dämlich. 2. Interpretation: "Keine Möglichkeit, externen Simulator auf Knopfdruck aufzurufen". ??? Warum nicht? Das bekomme ja sogar ich mit Tcl/Tk hin, wenn ich mir Mühe gebe. Wo ist das Problem? > Horizon soll in erster Linie ein gutes Programm werden um > Schaltpläne zu zeichnen und damit Boards zu machen. Erstmal > nicht mehr. Warum schreit keiner, dass ERC noch vollständig > fehlt, man keine differentiellen Leitungen routen kann, es > keine Thermals in Flächen gibt, oder die Darstellung von > Pad-Namen im Board noch sehr zu wünschen Übrig lässt? Weil Du auf technische Details fixiert bist, die vom Standpunkt eines Selbständigen bzw. einer kleinen Klitsche aus völlig nebensächlich sind. > Ja, Standards wären in der Tat schön, Tja, das sehen wir offenbar etwas verschieden. Meiner Meinung nach sind Standards im industriellen Zeitalter und im Zeichen des weltweiten Handels nicht "schön", sondern eine absolute Notwendigkeit. Was glaubst Du, wie der Maschinenbau ohne Normteile und ohne Standards für die technischen Zeichnungen aussähe? Richtig: Wie im Mittelalter. Jetzt weisst Du auch, welche Meinung ich zum Stand der EDA- Software habe (nicht DEINER EDA-Software, sondern DER EDA- Software ganz allgemein). > doch abgesehen von recht primitiven Spice-Netzlisten > und Gerber gibt es in der Branche nichts wirklich > brauchbares, was auch Anwendung findet. Richtig. Warum das bei kommerziellen Programmen so ist, ist augen- scheinlich: Der Wunsch nach "Kundenbindung" bewirkt das. (Es gibt da einen hübschen Wikipädie-Artikel dazu. Sinn- gemäßes Zitat: "Die Hersteller von EDA-Software waren erst nach massiver Intervention durch große Kunden bereit, Exportschnittstellen in ihrer Software vorzusehen.") Warum aber machen FOSS-Programmierer, die frei von vielen Zwängen der kommerziellen Anbieter sind, diesen Scheissdreck nach? > Possetitjel schrieb: >> Wünschenswert wäre vielleicht, dass man auch Daten in >> tabellarischer Form (Pinbelegungen z.B.) in die Software >> hineinfüttern kann. > > Geht schon: Um so besser. Ändert aber nichts am grundsätzlichen Problem. > Verbindungen nicht nur im Schaltplan zu zeichnen ist in der > Architektur schon seit Anfang an vorgesehen, da in Horizon > die Netzliste und nicht der Schaltplan die Primärquelle ist. Ich hatte schon damals herausgelesen, dass Du einige sehr sinnvolle Ansätze verfolgst, die ich von anderen Projekten nicht kenne. Trotzdem sehe ich Dein Projekt wie Baumgartners Stratosphären- sprung: Ich bewundere die persönliche Leistung aufrichtig -- aber es ist letztlich für mich uninteressant, weil nichts konkret für mein eigenes Leben, mein eigenes Tun daraus folgt. Bitte nicht falsch versehen: Das ist keine Kritik an Deinem Tun oder Deinen Entscheidungen. Es ist Dein Projekt (und schätzungsweise ein Hobby und kein Broterwerb), und Du bist völlig frei in Deinem Tun und Lassen. Meine Worte sind keine Kritik an Dir, sondern sollen nur eine Erklärung meines Verhaltens sein: Obwohl ich auf der Suche nach für mich geeigneter EDA-Software bin, habe ich (bis jetzt) nicht den Eindruck, dass Deine Software für mich in Frage kommt. Die Schwerpunkte, die Du in Deiner Arbeit setzt, scheinen mir mit meinen Wünschen in keiner Weise kompatibel.
Hi, ich wollte die aktuelle Version auch mal wieder testen, unter
Xubuntu 16.04. Problem: imp.cpp bricht ab. Zur Info habe ich noch die
Versionen der Abhängokgeiten angehängt. Geclont habe ich heute.
tester@HPi7:~/src/horizon/horizon$ sudo apt install libyaml-cpp-dev
libsqlite3-dev util-linux librsvg2-dev libcairomm-1.0-dev
libepoxy-dev libgtkmm-3.0-dev uuid-dev libboost-dev libzmq5
libzmq3-dev libglm-dev
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
»libboost-dev« ist bereits die neuste Version (1.58.0.1ubuntu1).
»libcairomm-1.0-dev« ist bereits die neuste Version (1.12.0-1).
»libglm-dev« ist bereits die neuste Version (0.9.7.2-1).
»libgtkmm-3.0-dev« ist bereits die neuste Version (3.18.0-1).
»librsvg2-dev« ist bereits die neuste Version (2.40.13-3).
»libsqlite3-dev« ist bereits die neuste Version (3.11.0-1ubuntu1).
»libyaml-cpp-dev« ist bereits die neuste Version (0.5.2-3).
»libzmq3-dev« ist bereits die neuste Version (4.1.4-7).
»libzmq5« ist bereits die neuste Version (4.1.4-7).
»libepoxy-dev« ist bereits die neuste Version (1.3.1-1ubuntu0.16.04.2).
»util-linux« ist bereits die neuste Version (2.27.1-6ubuntu3.3).
»uuid-dev« ist bereits die neuste Version (2.27.1-6ubuntu3.3).
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 47 nicht
aktualisiert.
g++ -c -I. -Iblock -Iboard -Icommon -Iimp -Ipackage -Ipool -Ischematic
-Iutil -Iconstraints -g3 -D_USE_MATH_DEFINES -fdata-sections
-ffunction-sections -pthread -std=c++11 -pthread -I/usr/include/uuid
-I/usr/include/gtkmm-3.0 -I/usr/lib/x86_64-linux-gnu/gtkmm-3.0/include
-I/usr/include/atkmm-1.6 -I/usr/include/gtk-3.0/unix-print
-I/usr/include/gdkmm-3.0 -I/usr/lib/x86_64-linux-gnu/gdkmm-3.0/include
-I/usr/include/giomm-2.4 -I/usr/lib/x86_64-linux-gnu/giomm-2.4/include
-I/usr/include/pangomm-1.4
-I/usr/lib/x86_64-linux-gnu/pangomm-1.4/include
-I/usr/include/glibmm-2.4 -I/usr/lib/x86_64-linux-gnu/glibmm-2.4/include
-I/usr/include/gtk-3.0 -I/usr/include/at-spi2-atk/2.0
-I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0
-I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/gtk-3.0
-I/usr/include/gio-unix-2.0/ -I/usr/include/mirclient
-I/usr/include/mircore -I/usr/include/mircookie -I/usr/include/cairo
-I/usr/include/pango-1.0 -I/usr/include/harfbuzz
-I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo
-I/usr/include/cairomm-1.0
-I/usr/lib/x86_64-linux-gnu/cairomm-1.0/include
-I/usr/include/sigc++-2.0 -I/usr/lib/x86_64-linux-gnu/sigc++-2.0/include
-I/usr/include/cairo -I/usr/include/librsvg-2.0
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng12
-I/usr/include/cairo -I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1
-I/usr/include/freetype2 -I/usr/include/libpng12 -MP -MMD -pthread -Wall
-Wshadow -std=c++14 -O3 imp/imp.cpp -o imp/imp.o
imp/imp.cpp: In member function ‘bool
horizon::ImpBase::handle_click(GdkEventButton*)’:
imp/imp.cpp:498:20: error: ‘class Gtk::Menu’ has no member named
‘popup_at_pointer’
context_menu->popup_at_pointer((GdkEvent*)button_event);
^
imp/imp.cpp:516:19: error: ‘class Gtk::Menu’ has no member named
‘popup_at_pointer’
context_menu->popup_at_pointer((GdkEvent*)button_event);
^
Makefile:419: die Regel für Ziel „imp/imp.o“ scheiterte
make: *** [imp/imp.o] Fehler 1
Hm... das Problem ist wohl, dass
1 | context_menu->popup_at_pointer((GdkEvent*)button_event); |
erst ab libgtkmm 3.22 dabei ist. Ich hab' nur libgtkmm3.18.
Selbes Problem habe ich auch, ich versuche es auf openSUSE Leap42.3 zu bauen.
Hoppla, hab ich das wohl übersehen. Sollte nun funktionieren.
Es werden wohl noch mehr Funktionen von >gtkmm3.18 verwendet: GtkFileChooserNative ist erst ab 3.20 dabei
1 | imp/imp_schematic.cpp: In member function ‘void horizon::ImpSchematic::handle_export_pdf()’: |
2 | imp/imp_schematic.cpp:123:3: error: ‘GtkFileChooserNative’ was not declared in this scope |
3 | GtkFileChooserNative *native = gtk_file_chooser_native_new ("Save PDF", |
4 | ^
|
5 | imp/imp_schematic.cpp:123:25: error: ‘native’ was not declared in this scope |
6 | GtkFileChooserNative *native = gtk_file_chooser_native_new ("Save PDF", |
7 | ^
|
8 | imp/imp_schematic.cpp:127:13: error: ‘gtk_file_chooser_native_new’ was not declared in this scope |
9 | "_Cancel"); |
10 | ^
|
11 | imp/imp_schematic.cpp:137:54: error: ‘GTK_NATIVE_DIALOG’ was not declared in this scope |
12 | if(gtk_native_dialog_run (GTK_NATIVE_DIALOG (native))==GTK_RESPONSE_ACCEPT) { |
13 | ^
|
14 | imp/imp_schematic.cpp:137:55: error: ‘gtk_native_dialog_run’ was not declared in this scope |
15 | if(gtk_native_dialog_run (GTK_NATIVE_DIALOG (native))==GTK_RESPONSE_ACCEPT) { |
16 | ^
|
17 | Makefile:419: die Regel für Ziel „imp/imp_schematic.o“ scheiterte |
18 | make: *** [imp/imp_schematic.o] Fehler 1 |
Brauche wohl ein Ubuntu 17.04 oder 17.10...
Ich baue grade openSUSE rpms, Tumbleweed geht schon, leap 42.3 baut gerade, und auch für Raspi (ARM). Unter openSUSE können die Binaries mit
1 | zypper ar https://download.opensuse.org/repositories/home:/frank_kunz/openSUSE_Tumbleweed/ horizon_repo |
2 | zypper ref |
3 | zypper in horizon |
installiert werden. Oder einfach yast nehmen. Zudem versuche ich mich an einem Appimage. Damit soll es möglich sein das Programm auf (nahezu) beliebigen Distros auszuführen, also so was ähnliches wie das Windows Package für Linux. Mal sehen ob es klappt. Die rpm Packages enthalten nur die kompilierten Binaries, der Pool und das Beispielprojekt muss separat von github geladen werden (wie im wiki beschrieben). Gruß, Frank ps: Benutzung auf eigene Gefahr.
:
Bearbeitet durch User
tester schrieb: > Brauche wohl ein Ubuntu 17.04 oder 17.10... Ja ist natürlich etwas schade dass es für dich nun nicht funktioniert hat. Aber GTK 3.20 oder 3.22 sollte man schon haben, wenn man denn testen will. Viele Dinge waren vor 3.20 unspezifiziert, und 3.22 ist ja wohl nun auch schon seit ca. einem Jahr erhältlich und das ist ja praktisch auch die Langzeitversion, bis dann GTK4 kommt. Einen Hinweis welche GTK Version nötig ist hatte ich auf Lukas Seite so auf den ersten Blick auch nicht gesehen.
Läuft es bei dir durch? Ich habe noch mehr Probleme. Ist mein gcc zu alt? gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5)
1 | core/tool_move.cpp: In constructor ‘horizon::ToolMove::ToolMove(horizon::Core*, horizon::ToolID)’: |
2 | core/tool_move.cpp:14:58: error: use of deleted function ‘horizon::ToolHelperMove::ToolHelperMove()’ |
3 | ToolMove::ToolMove(Core *c, ToolID tid): ToolBase(c, tid) { |
4 | ^
|
5 | In file included from core/tool_move.hpp:3:0, |
6 | from core/tool_move.cpp:1: |
7 | core/tool_helper_move.hpp:5:8: note: ‘horizon::ToolHelperMove::ToolHelperMove()’ is implicitly deleted because the default definition would be ill-formed: |
8 | class ToolHelperMove : public virtual ToolBase { |
9 | ^
|
10 | core/tool_helper_move.hpp:5:8: error: no matching function for call to ‘horizon::ToolBase::ToolBase()’ |
11 | In file included from core/tool_move.hpp:2:0, |
12 | from core/tool_move.cpp:1: |
13 | core/core.hpp:86:4: note: candidate: horizon::ToolBase::ToolBase(horizon::Core*, horizon::ToolID) |
14 | ToolBase(class Core *c, ToolID tid); |
15 | ^
|
16 | core/core.hpp:86:4: note: candidate expects 2 arguments, 0 provided |
17 | core/core.hpp:84:8: note: candidate: horizon::ToolBase::ToolBase(const horizon::ToolBase&) |
18 | class ToolBase { |
19 | ^
|
20 | core/core.hpp:84:8: note: candidate expects 1 argument, 0 provided |
21 | core/tool_move.cpp:14:58: error: use of deleted function ‘horizon::ToolHelperMerge::ToolHelperMerge()’ |
22 | ToolMove::ToolMove(Core *c, ToolID tid): ToolBase(c, tid) { |
23 | ^
|
24 | In file included from core/tool_move.hpp:4:0, |
25 | from core/tool_move.cpp:1: |
26 | core/tool_helper_merge.hpp:5:8: note: ‘horizon::ToolHelperMerge::ToolHelperMerge()’ is implicitly deleted because the default definition would be ill-formed: |
27 | class ToolHelperMerge: public virtual ToolBase { |
28 | ^
|
29 | core/tool_helper_merge.hpp:5:8: error: no matching function for call to ‘horizon::ToolBase::ToolBase()’ |
30 | In file included from core/tool_move.hpp:2:0, |
31 | from core/tool_move.cpp:1: |
32 | core/core.hpp:86:4: note: candidate: horizon::ToolBase::ToolBase(horizon::Core*, horizon::ToolID) |
33 | ToolBase(class Core *c, ToolID tid); |
34 | ^
|
35 | core/core.hpp:86:4: note: candidate expects 2 arguments, 0 provided |
36 | core/core.hpp:84:8: note: candidate: horizon::ToolBase::ToolBase(const horizon::ToolBase&) |
37 | class ToolBase { |
38 | ^
|
39 | core/core.hpp:84:8: note: candidate expects 1 argument, 0 provided |
40 | core/tool_move.cpp: In member function ‘void horizon::ToolMove::expand_selection()’: |
41 | core/tool_move.cpp:74:22: warning: unused variable ‘itv’ [-Wunused-variable] |
42 | for(const auto &itv: poly->vertices) { |
43 | ^
|
44 | Makefile:419: die Regel für Ziel „core/tool_move.o“ scheiterte |
45 | make: *** [core/tool_move.o] Fehler 1 |
gcc5 hat bei mir auch nicht funktioniert, mit gcc6-c++-6.2.1+r239768-6.19 geht es. Gruß, Frank
Mar. W. schrieb: > Das ist ein gutes Argument. Ich bin auch ehe dafür die Simulation mit > KiCAD weiterzutreiben und dort zu investieren, als noch ein neues > Programm aufzuziehen. Eine Simulation die aus dem PCB-Programm kommt und nicht alle benötigten SPICE-Modelle bereits kennt hat verloren. Die Pin-Reihenfolge in einem SPICE-Modell(subcircuit) hat überhaupt nichts mit der Pin-Reihenfolge des realen Bauteils zu tun. Selbst die Anzahl der Pins ist unterschiedlich. Ohne dieses Wissen, kann das PCB-Programm keine vernünftige Netzliste für SPICE generieren. Man müsste bereits beim Aufsetzen der Symbole im Schaltplan-Programm auch die Pins des SPICE-Modells definieren. Daran scheitern schon die meisten die wenig über SPICE wissen. So etwas kann man z. B. in der Software von Cadence und Mentor machen. KiCad hat dazu vermutlich überhaupt nichts vorgesehen. Lukas sollte die komplette Zeit in das PCB-Programm, den Schaltplaneditor und in den Bauteileeditor investieren und besser keine Zeit für Simulationstools investieren.
Hallo, mit gcc6-c++-6.2.1+r239768-6.19 bekomme ich den Fehler:
1 | [ 341s] core/tool_move.cpp: In constructor 'horizon::ToolMove::ToolMove(horizon::Core*, horizon::ToolID)': |
2 | [ 341s] core/tool_move.cpp:14:58: error: use of deleted function 'horizon::ToolHelperMove::ToolHelperMove()' |
3 | [ 341s] ToolMove::ToolMove(Core *c, ToolID tid): ToolBase(c, tid) {
|
4 | [ 341s] ^ |
5 | [ 341s] In file included from core/tool_move.hpp:3:0, |
6 | [ 341s] from core/tool_move.cpp:1: |
7 | [ 341s] core/tool_helper_move.hpp:5:8: note: 'horizon::ToolHelperMove::ToolHelperMove()' is implicitly deleted because the default de |
8 | finition would be ill-formed: |
9 | [ 341s] class ToolHelperMove : public virtual ToolBase {
|
10 | [ 341s] ^~~~~~~~~~~~~~ |
11 | [ 341s] core/tool_helper_move.hpp:5:8: error: no matching function for call to 'horizon::ToolBase::ToolBase()' |
12 | [ 341s] In file included from core/tool_move.hpp:2:0, |
13 | [ 341s] from core/tool_move.cpp:1: |
14 | [ 341s] core/core.hpp:86:4: note: candidate: horizon::ToolBase::ToolBase(horizon::Core*, horizon::ToolID) |
15 | [ 341s] ToolBase(class Core *c, ToolID tid); |
16 | [ 341s] ^~~~~~~~ |
17 | [ 341s] core/core.hpp:86:4: note: candidate expects 2 arguments, 0 provided |
18 | [ 341s] core/core.hpp:84:8: note: candidate: horizon::ToolBase::ToolBase(const horizon::ToolBase&) |
19 | [ 341s] class ToolBase {
|
20 | [ 341s] ^~~~~~~~ |
21 | [ 341s] core/core.hpp:84:8: note: candidate expects 1 argument, 0 provided |
22 | [ 341s] core/tool_move.cpp:14:58: error: use of deleted function 'horizon::ToolHelperMerge::ToolHelperMerge()' |
23 | [ 341s] ToolMove::ToolMove(Core *c, ToolID tid): ToolBase(c, tid) {
|
24 | [ 341s] ^ |