Menu
▾
▴
openautomation-devel — Developer's mailinglist
You can subscribe to this list here.
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2011 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
| 2013 |
Jan
(7) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
|
|
From: Christian M. <ma...@Ch...> - 2014-11-02 11:16:00
|
Hello Robert, what part of the project do you want? CometVisu has official releases so you can get packaged files to download. Other parts of the project are available through the SVN repository. All necessary information is either in the Wiki (http://www.cometvisu.de/wiki/index.php?title=Open_Automation) and/or in the source files. With kind regards, Christian Am 01.11.2014 um 16:28 schrieb robert evans: > I am trying to download "Open Automation" but the only choice presented > is " CometVisu_0.8.tar.bz2". I am reluctant to download this as it has > no similarilty to Open Automation and I have had some very negative > experiences with this site with downloading zip file openers and games > and web browser toolbars and other BS that I have no interest in. Why is > this so devious? I am not a really sophistigated user but this seems > intentionally misleading. |
|
From: robert e. <rob...@gm...> - 2014-11-01 15:28:08
|
I am trying to download "Open Automation" but the only choice presented is " CometVisu_0.8.tar.bz2". I am reluctant to download this as it has no similarilty to Open Automation and I have had some very negative experiences with this site with downloading zip file openers and games and web browser toolbars and other BS that I have no interest in. Why is this so devious? I am not a really sophistigated user but this seems intentionally misleading. -- Robert Evans, DO |
|
From: robert e. <rob...@gm...> - 2014-11-01 14:58:13
|
I am trying to download the software but all I get is zip file and game BS that is not what I want. I can't seem to find the files that download and I have updated my Java files but the prompt doesn't match the idea of a root but wants to know a "value" rather than a root path. I am not a complete novice at this but it is very confusing and encumbered with commercial intervention! Any help would be appreciated! -- Robert Evans, DO |
|
From: Michael H. <mi...@ha...> - 2013-07-21 19:34:03
|
Da ich schon ein paar Ungereimheiten bei der Verwendung der neuen jQuery-Version entdeckt habe, würde ich das auch lieber sein lassen. Ich habe zwar nicht den Eindruck, dass wir irgendwie einem Release näher kommen, da sich wenig tut bezüglich des Editors, aber es wäre mir dennoch zu heikel. Das sollten wir tatsächlich erst nach dem nächsten Release machen. Ich baue gerade einen Workaround dafür ein, dass es trotzdem eine ordentliche Fehlermeldung gibt, auch mit der aktuellen jQuery-Version. Grüße Michael Am Sonntag, den 21.07.2013, 17:23 +0200 schrieb Christian Mayer: > Am 21.07.2013 16:18, schrieb Michael Hausl: > > > > Meine Frage: Können wir die jQuery-Bibliotheken auf die aktuelle > > Version 1.10.2 anheben? > > Nun, so kurz vor einem Release bin ich bei so etwas immer eher vorsichtig. > > Andererseits sehe ich gerade nicht den noch notwendigen Schritt beim > Editor und es wäre ja auch nicht aus Featuritis sondern als Bug-Fix... > > Da die Entwicklerabsprache zur CometVisu im Forum und nicht wirklich > hier abläuft, schlage ich vor, dass Du dort in einem neuen Thread > fragst, ob es Einwände gibt. Falls nicht, können wir von mir aus wechseln. > > CU, > Chris > > > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > Openautomation-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openautomation-devel |
|
From: Christian M. <ma...@Ch...> - 2013-07-21 15:24:02
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 21.07.2013 16:18, schrieb Michael Hausl: > > Meine Frage: Können wir die jQuery-Bibliotheken auf die aktuelle > Version 1.10.2 anheben? Nun, so kurz vor einem Release bin ich bei so etwas immer eher vorsichtig. Andererseits sehe ich gerade nicht den noch notwendigen Schritt beim Editor und es wäre ja auch nicht aus Featuritis sondern als Bug-Fix... Da die Entwicklerabsprache zur CometVisu im Forum und nicht wirklich hier abläuft, schlage ich vor, dass Du dort in einem neuen Thread fragst, ob es Einwände gibt. Falls nicht, können wir von mir aus wechseln. CU, Chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEAREIAAYFAlHr/QYACgkQoWM1JLkHou084wCglYKprs2dTip8w0SC6G8iWAmR MeEAoJGR0hT4em+xRf2/eXV+9TcMWM1a =sh9f -----END PGP SIGNATURE----- |
|
From: Michael H. <mi...@ha...> - 2013-07-21 14:31:43
|
Ich habe mir das JQuery-Verhalten im Zusammenhang mit diesem Problem hier angeschaut: http://knx-user-forum.de/cometvisu/28447-design-css-wird-nicht-mehr-geladen.html Die aktuelle jQuery-Version 1.8.3 parst die XML-Datei und hat tatsächlich einen Parser-Error, aber zeigt diesen im AJAX-Request nicht an. Die TemplateEngine denkt, das XML is ok, aber bei der weiteren Verarbeitung gibt es einen Fehler wegen des Parser-Errors. Ich habe einfach mal die aktuelle jQuery-Version 1.10.2 ausprobiert, und dort gibt es keinen Parserfehler mehr. Meine Frage: Können wir die jQuery-Bibliotheken auf die aktuelle Version 1.10.2 anheben? Grüße Michael |
|
From: Christian M. <ma...@Ch...> - 2013-06-14 22:04:57
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hallo Rudi, openautomation stellt nur den SVN-Server bereit (bzw. macht das SourceForge, wir haben einfach ein Verzeichnis da drinnen dafür bereit gestellt...). Anfragen sollten daher am Besten über das Forum dafür laufen (http://knx-user-forum.de/knx-uf-iconset/). SVG ist definitiv Ziel und auch schon öfters besprochen, aber aus verschiedenen Gründen noch nicht zustande gekommen. Die CometVisu, die auch diese Icons nutzt, hat daher die Icons per externem Skript umskaliert und umgefärbt (vgl. CometVisu im SVN). Und um das ganze zu optimieren wird das nun in den neuesten Revisions auf dem Client durchgeführt (Canvas sei Dank). Der Iconhandler (eine JavaScript-Bibliothek) ist wie der Rest der CometVisu Open Source unter der GPL und darf natürlich zu den Bedingungen der GPL weiterbenutzt werden. Viele Grüße, Chris Am 11.06.2013 10:57, schrieb Rudolf Koenig: > Hallo > > einer der FHEM Benutzer hat mich auf die schoene Icon-Sammlung von > openautomation (raw_480x480) aufmerksam gemacht, und ich wuerde > diese Bilder gerne mit FHEM ausliefern, ich hoffe Ihr habt nichts > dagegen. > > Koennte man diese Sammlung auch als SVG bekommen? Das wuerde uns > das Skalieren und das dynamische Einfaerben erleichtern. > > Gruss, Rudi > > ------------------------------------------------------------------------------ > > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Openautomation-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openautomation-devel > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEAREIAAYFAlG7k34ACgkQoWM1JLkHou3xtgCfXwTIsAlr39dES2O4cjP2g7bT MFMAoIDryaquu7JN5D8GXN+bPwVsLGxM =cwtd -----END PGP SIGNATURE----- |
|
From: Rudolf K. <in...@ko...> - 2013-06-11 09:22:15
|
Hallo einer der FHEM Benutzer hat mich auf die schoene Icon-Sammlung von openautomation (raw_480x480) aufmerksam gemacht, und ich wuerde diese Bilder gerne mit FHEM ausliefern, ich hoffe Ihr habt nichts dagegen. Koennte man diese Sammlung auch als SVG bekommen? Das wuerde uns das Skalieren und das dynamische Einfaerben erleichtern. Gruss, Rudi |
|
From: Christian M. <ma...@Ch...> - 2013-01-05 00:38:16
|
Da's wohl untergegangen ist (hat sich mit dem Subscriben überschnitten) hier nochmal die Frage: Am 14.12.2012 23:39, schrieb Christian Mayer: > Am 14.12.2012 23:21, schrieb Michael Markstaller: >> On 14.12.2012 19:30, Christian Mayer wrote: >>> => Da beides sinnvoll erscheint: wie machen das denn die >>> anderen, wie z.B. HS? >> Im HS läuft das so: Diesen Fall angenommen, 2 Telegramme (21 + 22°) >> an eine GA binnen 10sek.; Logik1 (thread1 bzw. event-timer intern >> glaube ich) verzögert stur den Wert 20sek - nachfolgende Logiken/BS >> bekommen aber BEIDE Werte - mit eben dieser Verzögerung. > >> Logik2 ohne Telegrammverzögerung rechnet (sofort) z.B. eine >> Temperatur-tendenz aus, also erst mit 21, dann mit 22° (das >> Beispiel ist blöde, ich weiss, sollte aber sagen wie es tut..) > > Ui - das habe ich jetzt nicht verstanden :( > > Nehmen wir mal an, das hier wäre eine HS Logik, bzw. halt eine "Seite": > > ----------- ----------- > GA -+->| Block 1 |-------->| | > | ----------- | Block 2 |---> Out > | |--->| | > ------------------| ----------- > > Und Block 1 braucht 20 Sekunden zwischen Aufruf und Ausgabe, Block 2 > geht schnell. Jetzt kommen auf GA 2 Werte innerhalb von 10 Sekunden. > Wann wird die Gesammt-Logik und wann welcher Block aufgerufen? > > CU, > Chris > > |
|
From: Michael M. <mm...@el...> - 2013-01-03 20:55:43
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03.01.2013 10:16, Christian Mayer wrote: > Am 03.01.2013 01:39, schrieb Michael Markstaller: >> On 02.01.2013 20:58, Christian Mayer wrote: >>> deb http://ppa.launchpad.net/ubuntu-toolchain-r/test/ubuntu >>> precise main deb-src >>> http://ppa.launchpad.net/ubuntu-toolchain-r/test/ubuntu precise >>> main > >> Ah nö Chris, also ich steh ja auch mal gerne auf fummeln aber >> der will meine libstdc++6 updaten - das gehört echt zu den >> Punkten, wo ich kein Stoppschild überfahre; sowas macht man >> nicht, wenn man mit dem System auch nochmal arbeiten will :p > >> Also in ne VM mach ich das mal zum Spass, plötzlich gehts auch, >> für eine mittelfristige Release-Planung zwischen 2014-2015 wärs >> aber ehrlichgesagt realistischer wenn sich das mitm gcc 4.6 oder >> besser 4.4 (squeeze/stable) begnügen könnte.. Also libzmq3.2 und >> boost kann man - unter grossen schmerzen - backporten (ich meine >> jetzt auf Ubuntu/Debian stable, nicht lenny/WG..) aber die >> libstdcpp fasse ich nicht an, weil dann mach ich nen Fork von >> einer Distro; das ist nicht lustig sowas zu pflegen.. > >> Und erklärt bekommt man das auch niemandem, ich mein ich press >> mir gcc 4.7 dann halt mal drauf aber jetzt nehmen wir Otto der >> sich bei der Aktion sein komplettes System lötet, weil er vorher >> nicht nachsieht das ne ganze Menge seiner SW gegen die "alte" >> libstdcpp der Distro kompiliert wurden.. > > Ich sehe beide Seiten - aber schaun wir uns das Problem vorher > lieber mal genauer an: > > - Es kompiliert Out-of-the-Box auf einem [K]Ubuntu 12.10 (nämlich > mein Entwicklungssystem). Wird auch in Zukunft so bleiben - was auf > einem aktuellen [K]Ubuntu nicht Out-of-the-Box läuft, wird nicht im > Code landen (so sehr ich ein std::map.emplace() haben will...) - Es > kompiliert nicht mehr auf dem aktuellen Ubuntu LTS, da 12.04, hier > kann man mit o.g. PPA das ganze wieder zum Kompilieren bringen. > (Von mir nicht ausprobiert, aber evtl. wäre gcc-snapshot > harmloser?) - Das nächste LTS wird für 14.04 erwartet - da wird's > sicher kompilieren und somit bei einem gewünschten Release > 2014-2015 auch auf einem LTS Out-of-the-Box laufen > > => Bei den dicken Kisten sehe ich kein grobes Problem (und wenn > man sich eine VirtualBox dafür aufmacht...) > > Spannend und schwierig wirds auf den Embedded Kisten. Bei neu > aufgesetzen (Dirk?) mag man sich drum kümmern können, aber das > WireGate z.B. hätte ja nur einen 4.3 im Angebot. Da ist die C++11 > Unterstützung aber nur sehr mager: > http://gcc.gnu.org/projects/cxx0x.html Da ich in den paar Tagen, > seit dem ich C++11-Features nutze, vergessen habe, wie man vorher > C++ Code schreiben konnte, würde ich ungerne darauf verzichten - > erst recht nicht, bei einem neuen Projekt (d.h. im Grunde genommen, > kann man noch gar nichts kaputt machen...). > > Noch nicht ausprobiert, aber wäre ein "-static-libstdc++" nicht > ein gangbarer Kompromiss? D.h. auf einem aktuellen System bauen und > das statisch gelinkte Paket für's WireGate anbieten? Klar ist das > Binary dann dicker, aber das WireGate sollte das noch locker > abkönnen (v.a. da zig fette Perl-Prozesse nicht mehr rumschwirren > müssen). Für ganz kleine Systeme ist's aber natürlich kaum eine > Lösung... > > CU, Chris Ok, sorry ich hatte nicht geblickt, das 4.7 default in 12.10 ist (und die eigene Kiste bleibt auf 12.04 weil das geficke bis ich den ganzen Kram mit Dualgrafik usw. hingefummelt hatte brauch ich grad nicht..) Hab jetzt ne frische VM gemacht, irgendwie war die zwischen 12.04 und 12.10.. Sollte also gangbar sein, ich teste nachher mal cross für ARM und MIPS, mal sehen. Das WireGate können wir erstmal aussen vor lassen, da muss ich mir eh was ausdenken, nachdem bereits diverse Backports aus testing laufen wirds eh auf 7.0 hinauslaufen. Und das mit statisch sollte schon irgendwie auch übergänglich gehen.. Grüsse Makki -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlDl8DoACgkQaWRHV2kMuAKzoQCfYoH3eZrAHbAsSDN9H5sdYKW4 bxIAoMBdkI6ilHj/WhDk/a17bnJIDbN8 =97HF -----END PGP SIGNATURE----- |
|
From: Dirk O. <di...@op...> - 2013-01-03 10:40:34
|
Hallo Chris, > Spannend und schwierig wirds auf den Embedded Kisten. > Bei neu aufgesetzen (Dirk?) mag man sich drum kümmern können, aber das > WireGate z.B. hätte ja nur einen 4.3 im Angebot. Da ist die C++11 > Unterstützung aber nur sehr mager: > http://gcc.gnu.org/projects/cxx0x.html > Da ich in den paar Tagen, seit dem ich C++11-Features nutze, vergessen > habe, wie man vorher C++ Code schreiben konnte, würde ich ungerne > darauf verzichten - erst recht nicht, bei einem neuen Projekt (d.h. im > Grunde genommen, kann man noch gar nichts kaputt machen...). Deine Argumente verstehe ich voll und ganz. Ich hatte letztes Jahr zwar 4.5.x als CrossCompiler benutzt, sollte aber inzwischen auch mit was aktuellerem (also 4.7) gehen. Hängt noch etwas von der zu verwendeten Distro ab. Das müsste ich sowieso mit Makki noch etwas ausfechten. Vor mir aus würde dem 4.7 also nichts im Wege stehen. Problematisch wird es halt auf dem WireGate. Wenn du dann jeden Daemon statisch linken willst dürfte auch einiges zusammen kommen. Ob das dann so der beste Weg ist? Gruß Dirk PS: Chris sorry, meine Liste mit offenen Baustellen ist noch etwas umfangreicher geworden. Bin leider immer noch stiller Mitleser. |
|
From: Christian M. <ma...@Ch...> - 2013-01-03 09:16:46
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 03.01.2013 01:39, schrieb Michael Markstaller: > On 02.01.2013 20:58, Christian Mayer wrote: >> deb http://ppa.launchpad.net/ubuntu-toolchain-r/test/ubuntu >> precise main deb-src >> http://ppa.launchpad.net/ubuntu-toolchain-r/test/ubuntu precise >> main > > Ah nö Chris, also ich steh ja auch mal gerne auf fummeln aber der > will meine libstdc++6 updaten - das gehört echt zu den Punkten, wo > ich kein Stoppschild überfahre; sowas macht man nicht, wenn man mit > dem System auch nochmal arbeiten will :p > > Also in ne VM mach ich das mal zum Spass, plötzlich gehts auch, > für eine mittelfristige Release-Planung zwischen 2014-2015 wärs > aber ehrlichgesagt realistischer wenn sich das mitm gcc 4.6 oder > besser 4.4 (squeeze/stable) begnügen könnte.. Also libzmq3.2 und > boost kann man - unter grossen schmerzen - backporten (ich meine > jetzt auf Ubuntu/Debian stable, nicht lenny/WG..) aber die > libstdcpp fasse ich nicht an, weil dann mach ich nen Fork von einer > Distro; das ist nicht lustig sowas zu pflegen.. > > Und erklärt bekommt man das auch niemandem, ich mein ich press mir > gcc 4.7 dann halt mal drauf aber jetzt nehmen wir Otto der sich bei > der Aktion sein komplettes System lötet, weil er vorher nicht > nachsieht das ne ganze Menge seiner SW gegen die "alte" libstdcpp > der Distro kompiliert wurden.. Ich sehe beide Seiten - aber schaun wir uns das Problem vorher lieber mal genauer an: - - Es kompiliert Out-of-the-Box auf einem [K]Ubuntu 12.10 (nämlich mein Entwicklungssystem). Wird auch in Zukunft so bleiben - was auf einem aktuellen [K]Ubuntu nicht Out-of-the-Box läuft, wird nicht im Code landen (so sehr ich ein std::map.emplace() haben will...) - - Es kompiliert nicht mehr auf dem aktuellen Ubuntu LTS, da 12.04, hier kann man mit o.g. PPA das ganze wieder zum Kompilieren bringen. (Von mir nicht ausprobiert, aber evtl. wäre gcc-snapshot harmloser?) - - Das nächste LTS wird für 14.04 erwartet - da wird's sicher kompilieren und somit bei einem gewünschten Release 2014-2015 auch auf einem LTS Out-of-the-Box laufen => Bei den dicken Kisten sehe ich kein grobes Problem (und wenn man sich eine VirtualBox dafür aufmacht...) Spannend und schwierig wirds auf den Embedded Kisten. Bei neu aufgesetzen (Dirk?) mag man sich drum kümmern können, aber das WireGate z.B. hätte ja nur einen 4.3 im Angebot. Da ist die C++11 Unterstützung aber nur sehr mager: http://gcc.gnu.org/projects/cxx0x.html Da ich in den paar Tagen, seit dem ich C++11-Features nutze, vergessen habe, wie man vorher C++ Code schreiben konnte, würde ich ungerne darauf verzichten - erst recht nicht, bei einem neuen Projekt (d.h. im Grunde genommen, kann man noch gar nichts kaputt machen...). Noch nicht ausprobiert, aber wäre ein "-static-libstdc++" nicht ein gangbarer Kompromiss? D.h. auf einem aktuellen System bauen und das statisch gelinkte Paket für's WireGate anbieten? Klar ist das Binary dann dicker, aber das WireGate sollte das noch locker abkönnen (v.a. da zig fette Perl-Prozesse nicht mehr rumschwirren müssen). Für ganz kleine Systeme ist's aber natürlich kaum eine Lösung... CU, Chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEAREIAAYFAlDlTHMACgkQoWM1JLkHou2xuQCfUi7HmzzS+C/8K5zZ1+LxvOOf H4EAni4EU14H9/T0C6ZgRPkn3SQ7vvQo =oP1h -----END PGP SIGNATURE----- |
|
From: Michael M. <mm...@el...> - 2013-01-03 00:40:22
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02.01.2013 20:58, Christian Mayer wrote: > deb http://ppa.launchpad.net/ubuntu-toolchain-r/test/ubuntu precise > main deb-src > http://ppa.launchpad.net/ubuntu-toolchain-r/test/ubuntu precise > main Ah nö Chris, also ich steh ja auch mal gerne auf fummeln aber der will meine libstdc++6 updaten - das gehört echt zu den Punkten, wo ich kein Stoppschild überfahre; sowas macht man nicht, wenn man mit dem System auch nochmal arbeiten will :p Also in ne VM mach ich das mal zum Spass, plötzlich gehts auch, für eine mittelfristige Release-Planung zwischen 2014-2015 wärs aber ehrlichgesagt realistischer wenn sich das mitm gcc 4.6 oder besser 4.4 (squeeze/stable) begnügen könnte.. Also libzmq3.2 und boost kann man - unter grossen schmerzen - backporten (ich meine jetzt auf Ubuntu/Debian stable, nicht lenny/WG..) aber die libstdcpp fasse ich nicht an, weil dann mach ich nen Fork von einer Distro; das ist nicht lustig sowas zu pflegen.. Und erklärt bekommt man das auch niemandem, ich mein ich press mir gcc 4.7 dann halt mal drauf aber jetzt nehmen wir Otto der sich bei der Aktion sein komplettes System lötet, weil er vorher nicht nachsieht das ne ganze Menge seiner SW gegen die "alte" libstdcpp der Distro kompiliert wurden.. Grüsse Makki -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEUEARECAAYFAlDk0y4ACgkQaWRHV2kMuALIJwCgxnlvP0EgODdDC6SOiKZy6xwH nrMAmP63NgcG8jNFf9BugtJ/5e7BfHA= =kSbN -----END PGP SIGNATURE----- |
|
From: Christian M. <ma...@Ch...> - 2013-01-02 19:58:54
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 02.01.2013 20:43, schrieb Michael Markstaller: > Also, ich glaub ich bin zu blöd, cmake ist nicht meins oder da > gibts noch ne andere Dependency/Version von libs oder so; Ubuntu > 12.04, libzmq ist 3.2.2 ausm tarball: > > --- cut --- Aktualisiert zu Revision 1285. >> make: *** [all] Fehler 2 > --- cut ---- > > Any idea? LMGTFY hat nicht funktioniert ;) Wie gut, dass ich's vorhin auf meinem extra eingerichtetem, virtuellem 32 Bit Ubuntu LTE (also 12.04) getestet habe :) Die schlechte Nachricht: der GCC (und evtl. auch BOOST, bin mir da aber nicht sicher) ist dort zu alt. Im Code verwende ich ein paar C++11 Konstrukte, die die Compiler ja erst nach und nach umsetzen. Aktuell brauche ich den gcc 4.7 (und eigentlich würde ich auch gerne etwas nutzen, was wohl erst im 4.8 kommt...) => Daher kommt der Fehler Zum Glück kann man aber den 4.8 leicht nachrüsten: deb http://ppa.launchpad.net/ubuntu-toolchain-r/test/ubuntu precise main deb-src http://ppa.launchpad.net/ubuntu-toolchain-r/test/ubuntu precise main (Bei BOOST habe ich dabei auf die 1.48 aktuallisiert - aber die scheinst Du ja schon zu haben...) Das und die frische Revision 1286 sollte hoffentlich durchlaufen :) Zum bauen habe ich für die Kommando-Zeile noch dieses kleine Skript, dass direkt unter ..../GrAF liegt: *********************** #!/bin/bash cd logicd mkdir Debug cd Debug cmake -DCMAKE_BUILD_TYPE=Debug .. make cd .. mkdir Release cd Release cmake -DCMAKE_BUILD_TYPE=MinSizeRel .. make cd .. cd .. cd GrAFd mkdir Debug cd Debug cmake -DCMAKE_BUILD_TYPE=Debug .. make cd .. mkdir Release cd Release cmake -DCMAKE_BUILD_TYPE=MinSizeRel .. make cd .. *********************** Wenn's mal durchkompiliert, kann ich mal schreiben, was inzwischen gehen sollte - und wie. Noch sind da ein paar Dinge hart codiert bzw. anderes (wie z.B. der lighttpd) muss auch passend konfiguriert werden. CU, Chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEAREIAAYFAlDkkXQACgkQoWM1JLkHou2mCQCfXzqGCwn7X21sZAkW2C7qUI41 Eq8An3Snt6BTVMg7V2m5ao7iunfRJhR7 =xrV2 -----END PGP SIGNATURE----- |
|
From: Michael M. <mm...@el...> - 2013-01-02 19:44:14
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Also, ich glaub ich bin zu blöd, cmake ist nicht meins oder da gibts
noch ne andere Dependency/Version von libs oder so;
Ubuntu 12.04, libzmq ist 3.2.2 ausm tarball:
- --- cut ---
Aktualisiert zu Revision 1285.
markstaller@v3750mm:~/devel/openautomation/GrAF/trunk$ cd GrAFd/
markstaller@v3750mm:~/devel/openautomation/GrAF/trunk/GrAFd$ cmake .
- -- The C compiler identification is GNU
- -- The CXX compiler identification is GNU
- -- Check for working C compiler: /usr/bin/gcc
- -- Check for working C compiler: /usr/bin/gcc -- works
- -- Detecting C compiler ABI info
- -- Detecting C compiler ABI info - done
- -- Check for working CXX compiler: /usr/bin/c++
- -- Check for working CXX compiler: /usr/bin/c++ -- works
- -- Detecting CXX compiler ABI info
- -- Detecting CXX compiler ABI info - done
- -- Boost version: 1.48.0
- -- Found the following Boost libraries:
- -- filesystem
- -- system
- -- Found zeromq (lib) in: /usr/local/lib/libzmq.so
Building type:
- -- Found Doxygen: /usr/bin/doxygen
- -- Boost version: 1.48.0
- -- Found the following Boost libraries:
- -- unit_test_framework
- -- Configuring done
- -- Generating done
- -- Build files have been written to:
/home/markstaller/devel/openautomation/GrAF/trunk/GrAFd
markstaller@v3750mm:~/devel/openautomation/GrAF/trunk/GrAFd$ make
Scanning dependencies of target GrAFd
[ 7%] Building CXX object CMakeFiles/GrAFd.dir/src/graphsignal.cpp.o
In file included from
/home/markstaller/devel/openautomation/GrAF/trunk/GrAFd/src/graph.hpp:34:0,
from
/home/markstaller/devel/openautomation/GrAF/trunk/GrAFd/src/graphsignal.cpp:23:
/home/markstaller/devel/openautomation/GrAF/trunk/GrAFd/src/logicengine.hpp:59:58:
Fehler: a brace-enclosed initializer is not allowed here before »{« token
/home/markstaller/devel/openautomation/GrAF/trunk/GrAFd/src/logicengine.hpp:59:91:
Fehler: »const« und »constexpr« können hier nicht zusammen verwendet
werden
In file included from
/home/markstaller/devel/openautomation/GrAF/trunk/GrAFd/src/graphsignal.cpp:23:0:
/home/markstaller/devel/openautomation/GrAF/trunk/GrAFd/src/graph.hpp:88:3:
Fehler: ein Klassenschlüssel muss bei Deklaration als »friend«
verwendet werden
/home/markstaller/devel/openautomation/GrAF/trunk/GrAFd/src/graph.hpp:88:3:
Fehler: »friend«-Deklaration benennt keine Klasse oder Funktion
/home/markstaller/devel/openautomation/GrAF/trunk/GrAFd/src/graph.hpp:89:3:
Fehler: ein Klassenschlüssel muss bei Deklaration als »friend«
verwendet werden
/home/markstaller/devel/openautomation/GrAF/trunk/GrAFd/src/graph.hpp:89:3:
Fehler: »friend«-Deklaration benennt keine Klasse oder Funktion
/home/markstaller/devel/openautomation/GrAF/trunk/GrAFd/src/graph.hpp:
In Lambda-Funktion:
/home/markstaller/devel/openautomation/GrAF/trunk/GrAFd/src/graph.hpp:115:21:
Fehler: »const GraphBlock& Graph::libLookup(const string&) const« ist
privat
/home/markstaller/devel/openautomation/GrAF/trunk/GrAFd/src/graphsignal.cpp:58:61:
Fehler: in diesem Zusammenhang
/home/markstaller/devel/openautomation/GrAF/trunk/GrAFd/src/graph.hpp:105:17:
Fehler: »Graph::blockLookup_t Graph::blockLookup« ist privat
/home/markstaller/devel/openautomation/GrAF/trunk/GrAFd/src/graphsignal.cpp:63:49:
Fehler: in diesem Zusammenhang
/home/markstaller/devel/openautomation/GrAF/trunk/GrAFd/src/graph.hpp:105:17:
Fehler: »Graph::blockLookup_t Graph::blockLookup« ist privat
/home/markstaller/devel/openautomation/GrAF/trunk/GrAFd/src/graphsignal.cpp:63:79:
Fehler: in diesem Zusammenhang
/home/markstaller/devel/openautomation/GrAF/trunk/GrAFd/src/graph.hpp:100:20:
Fehler: »Graph::DirecetedGraph_t Graph::g« ist privat
/home/markstaller/devel/openautomation/GrAF/trunk/GrAFd/src/graphsignal.cpp:63:107:
Fehler: in diesem Zusammenhang
/home/markstaller/devel/openautomation/GrAF/trunk/GrAFd/src/graph.hpp:100:20:
Fehler: »Graph::DirecetedGraph_t Graph::g« ist privat
/home/markstaller/devel/openautomation/GrAF/trunk/GrAFd/src/graphsignal.cpp:64:9:
Fehler: in diesem Zusammenhang
/home/markstaller/devel/openautomation/GrAF/trunk/GrAFd/src/graph.hpp:100:20:
Fehler: »Graph::DirecetedGraph_t Graph::g« ist privat
/home/markstaller/devel/openautomation/GrAF/trunk/GrAFd/src/graphsignal.cpp:65:9:
Fehler: in diesem Zusammenhang
make[2]: *** [CMakeFiles/GrAFd.dir/src/graphsignal.cpp.o] Fehler 1
make[1]: *** [CMakeFiles/GrAFd.dir/all] Fehler 2
make: *** [all] Fehler 2
markstaller@v3750mm:~/devel/openautomation/GrAF/trunk/GrAFd$ cd ../logicd/
markstaller@v3750mm:~/devel/openautomation/GrAF/trunk/logicd$ make
make: *** Keine Targets angegeben und keine »make«-Steuerdatei
gefunden. Schluss.
markstaller@v3750mm:~/devel/openautomation/GrAF/trunk/logicd$ cma
cmake cmap2enc
markstaller@v3750mm:~/devel/openautomation/GrAF/trunk/logicd$ cmake .
- -- The C compiler identification is GNU
- -- The CXX compiler identification is GNU
- -- Check for working C compiler: /usr/bin/gcc
- -- Check for working C compiler: /usr/bin/gcc -- works
- -- Detecting C compiler ABI info
- -- Detecting C compiler ABI info - done
- -- Check for working CXX compiler: /usr/bin/c++
- -- Check for working CXX compiler: /usr/bin/c++ -- works
- -- Detecting CXX compiler ABI info
- -- Detecting CXX compiler ABI info - done
- -- Boost version: 1.48.0
- -- Found the following Boost libraries:
- -- program_options
- -- system
Building type:
- -- Found zeromq (lib) in: /usr/local/lib/libzmq.so
- -- Configuring done
- -- Generating done
- -- Build files have been written to:
/home/markstaller/devel/openautomation/GrAF/trunk/logicd
markstaller@v3750mm:~/devel/openautomation/GrAF/trunk/logicd$ make
Scanning dependencies of target client
[ 12%] Building CXX object CMakeFiles/client.dir/src/testclient.cpp.o
In file included from
/home/markstaller/devel/openautomation/GrAF/trunk/logicd/src/testclient.cpp:25:0:
/home/markstaller/devel/openautomation/GrAF/trunk/logicd/include/message.hpp:474:3:
Warnung: diese Dezimalkonstante ist nur in ISO-C90 vorzeichenlos
[standardmäßig aktiviert]
/home/markstaller/devel/openautomation/GrAF/trunk/logicd/src/testclient.cpp:28:5:
Warnung: unbenutzter Parameter »argc« [-Wunused-parameter]
/home/markstaller/devel/openautomation/GrAF/trunk/logicd/src/testclient.cpp:28:5:
Warnung: unbenutzter Parameter »argv« [-Wunused-parameter]
Linking CXX executable client
[ 12%] Built target client
Scanning dependencies of target cometvisu2logic
[ 25%] Building CXX object
CMakeFiles/cometvisu2logic.dir/src/cometvisu2logic.cpp.o
In file included from
/home/markstaller/devel/openautomation/GrAF/trunk/logicd/src/cometvisu2logic.cpp:32:0:
/home/markstaller/devel/openautomation/GrAF/trunk/logicd/include/message.hpp:474:3:
Warnung: diese Dezimalkonstante ist nur in ISO-C90 vorzeichenlos
[standardmäßig aktiviert]
/home/markstaller/devel/openautomation/GrAF/trunk/logicd/src/cometvisu2logic.cpp:207:8:
Warnung: unbenutzter Parameter »bytes_transferred« [-Wunused-parameter]
/home/markstaller/devel/openautomation/GrAF/trunk/logicd/src/cometvisu2logic.cpp:432:8:
Warnung: unbenutzter Parameter »error« [-Wunused-parameter]
/home/markstaller/devel/openautomation/GrAF/trunk/logicd/src/cometvisu2logic.cpp:
In Elementfunktion »void ZMQ_server::handle_read(const
boost::system::error_code&)«:
/home/markstaller/devel/openautomation/GrAF/trunk/logicd/src/cometvisu2logic.cpp:559:15:
Warnung: Variable »FIXME_tmp« wird nicht verwendet [-Wunused-variable]
Linking CXX executable cometvisu2logic
CMakeFiles/cometvisu2logic.dir/src/cometvisu2logic.cpp.o: In function
`SCGI_session::handle_read(boost::system::error_code const&, unsigned
int)':
cometvisu2logic.cpp:(.text._ZN12SCGI_session11handle_readERKN5boost6system10error_codeEj[SCGI_session::handle_read(boost::system::error_code
const&, unsigned int)]+0x643): undefined reference to
`LogicMessage::invalidIndex'
cometvisu2logic.cpp:(.text._ZN12SCGI_session11handle_readERKN5boost6system10error_codeEj[SCGI_session::handle_read(boost::system::error_code
const&, unsigned int)]+0x831): undefined reference to
`LogicMessage::invalidIndex'
collect2: ld gab 1 als Ende-Status zurück
make[2]: *** [cometvisu2logic] Fehler 1
make[1]: *** [CMakeFiles/cometvisu2logic.dir/all] Fehler 2
make: *** [all] Fehler 2
- --- cut ----
Any idea? LMGTFY hat nicht funktioniert ;)
Makki
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iEYEARECAAYFAlDkjfcACgkQaWRHV2kMuAJwdQCgpn7kq2zy8LGezkjDMzoJndJz
IIsAoNXoBgscVjWCo9YA72OfLdRQ157T
=2rBN
-----END PGP SIGNATURE-----
|
|
From: Christian M. <ma...@Ch...> - 2012-12-14 22:39:20
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Am 14.12.2012 23:21, schrieb Michael Markstaller:
> On 14.12.2012 19:30, Christian Mayer wrote:
>> So, habe gerade mal den Stand in's SVN gebracht, an dem ich die
>> letzten Abenden dran war.
> Da war noch was mit dem backporten von boost bzw. libzmq :o ("make
> install" auf Produktivsystemen ist in meinem Hirn ganz fest mit
> Stromschlägen verdrahtet)
Nimm libzmq nicht zu ernst - ich glaube da ist richtig dicker Bloat
drinnen. Die Größen der Binaries hat mich nämlich für die lächerliche
Größe etwas geschockt.
Das gleiche mit Boost::ASIO.
=> Beides ist auf der Liste der zu ersetzenden Systeme.
(Aber vorher soll's mal grundsätzlich laufen)
D.h. auf einem Test-System (mit Dreiklang configure; make; make
install :) gerne mal machen, sauber für's WireGate ist noch nicht der
Anspruch.
>> => Da beides sinnvoll erscheint: wie machen das denn die
>> anderen, wie z.B. HS?
> Im HS läuft das so: Diesen Fall angenommen, 2 Telegramme (21 + 22°)
> an eine GA binnen 10sek.; Logik1 (thread1 bzw. event-timer intern
> glaube ich) verzögert stur den Wert 20sek - nachfolgende Logiken/BS
> bekommen aber BEIDE Werte - mit eben dieser Verzögerung.
>
> Logik2 ohne Telegrammverzögerung rechnet (sofort) z.B. eine
> Temperatur-tendenz aus, also erst mit 21, dann mit 22° (das
> Beispiel ist blöde, ich weiss, sollte aber sagen wie es tut..)
Ui - das habe ich jetzt nicht verstanden :(
Nehmen wir mal an, das hier wäre eine HS Logik, bzw. halt eine "Seite":
----------- -----------
GA -+->| Block 1 |-------->| |
| ----------- | Block 2 |---> Out
| |--->| |
------------------| -----------
Und Block 1 braucht 20 Sekunden zwischen Aufruf und Ausgabe, Block 2
geht schnell. Jetzt kommen auf GA 2 Werte innerhalb von 10 Sekunden.
Wann wird die Gesammt-Logik und wann welcher Block aufgerufen?
CU,
Chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEAREIAAYFAlDLqowACgkQoWM1JLkHou24cgCfSCpAH3p1DoD29CKy1SBc+hO5
a2AAn1VsY7MJfbLCCuq3EAvJIQNcJVP2
=Hewh
-----END PGP SIGNATURE-----
|
|
From: Michael M. <mm...@el...> - 2012-12-14 22:21:41
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 14.12.2012 19:30, Christian Mayer wrote:
> So, habe gerade mal den Stand in's SVN gebracht, an dem ich die
> letzten Abenden dran war.
Da war noch was mit dem backporten von boost bzw. libzmq :o ("make
install" auf Produktivsystemen ist in meinem Hirn ganz fest mit
Stromschlägen verdrahtet)
> => Man sieht schön, wie das Skript (nicht der GrAFd!) beim ersten
> "baz" die 20 Sekunden (bewusst) blockiert um dann das "blub" um
> 19:22:40 zu senden. Die zwischenzeitlichen Nachrichten "bar" und
> "baz" werden zwischengespeichert und sofort danach gemeinsam
> abgearbeitet.
>
> Dieser Stand wird nun dann ein "Problem" haben, wenn in der
> blockierenden Zeit mehr als eine Nachricht pro Adresse kommt. Das
> kann nun gut oder schlecht sein: - ist es etwas vergängliches wie
> ein Temperaturwert passt das, denn da will ich wohl kaum um die
> Historie kümmern müssen und gleich den aktuellen verarbeiten - ist
> es etwas wie ein Impulszähler könnte es doof sein (wäre aber lösbar
> durch ein kleines Skript das nur zählt und das komplexe,
> blockierende, dass dann diesen Wert weiterverwendet)
>
> => Da beides sinnvoll erscheint: wie machen das denn die anderen,
> wie z.B. HS?
Im HS läuft das so:
Diesen Fall angenommen, 2 Telegramme (21 + 22°) an eine GA binnen 10sek.;
Logik1 (thread1 bzw. event-timer intern glaube ich) verzögert stur den
Wert 20sek - nachfolgende Logiken/BS bekommen aber BEIDE Werte - mit
eben dieser Verzögerung.
Logik2 ohne Telegrammverzögerung rechnet (sofort) z.B. eine
Temperatur-tendenz aus, also erst mit 21, dann mit 22°
(das Beispiel ist blöde, ich weiss, sollte aber sagen wie es tut..)
> PS @Dirk, Julian und Makki: ab jetzt, wie besprochen, über die
> Mailingliste. Ich befürchte, da fehlt noch Euere Anmeldung über
> die Projekt-Seite...
Ich bin druff..
- --
Mit freundlichen Grüssen
Michael Markstaller
Elaborated Networks GmbH
www.elabnet.de
Lise-Meitner-Str. 1, D-85662 Hohenbrunn, Germany
fon: +49-8102-8951-60, fax: +49-8102-8951-80
Geschäftsführer: Stefan Werner, Michael Markstaller
Amtsgericht München HRB 125120, Ust-ID: DE201281054
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iEYEARECAAYFAlDLpmkACgkQaWRHV2kMuAKYDACfZVCwTVMRmGPUGNXOabxQ8HTk
ZHMAnRLxuT573wgrxJw8AYUJnWrCA4eX
=bZz3
-----END PGP SIGNATURE-----
|
|
From: Christian M. <ma...@Ch...> - 2012-12-14 18:31:09
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
So, habe gerade mal den Stand in's SVN gebracht, an dem ich die
letzten Abenden dran war.
=> GrAFd macht nun schon sinnvolleres als vorher
Er spricht nun nämlich mit dem logicd und kann mehere Skripte
gleichzeitig ausführen (per Thread Pool). Konkret gibt es nun zwei,
eines hört nur auf die Nachricht "baz", der andere auf "bar" und "baz".
Der andere nimmt den INT Wert, der auf "bar" gesendet wurde und
schickt den verdoppelt und "baz" Millisekunden später an die Adresse
"blub".
Oder etwas konkreter, logicd und GrAF läuft (letzteres gerne mit "-v
- -v -v" als Parameter) in einem Terminal:
cm@obiwan:/mnt/hdd/devel/GrAF/logicd/build$ ./send2logic bar INT 2
cm@obiwan:/mnt/hdd/devel/GrAF/logicd/build$ ./send2logic baz INT 20000
cm@obiwan:/mnt/hdd/devel/GrAF/logicd/build$ ./send2logic bar INT 3
cm@obiwan:/mnt/hdd/devel/GrAF/logicd/build$ ./send2logic baz INT 40000
Gibt im anderen:
cm@obiwan:/mnt/hdd/devel/GrAF/logicd/build$ ./logicspy -c -t
[2012-12-14 19:22:19.266] bar (<- NoSrc){8}: INT: 2 0x2; additonal 0
bytes of raw:
[2012-12-14 19:22:19.267] blub (<- NoSrc){9}: INT: 4 0x4; additonal 0
bytes of raw:
[2012-12-14 19:22:20.252] baz (<- NoSrc){10}: INT: 20000 0x4e20;
additonal 0 bytes of raw:
[2012-12-14 19:22:22.262] bar (<- NoSrc){11}: INT: 3 0x3; additonal 0
bytes of raw:
[2012-12-14 19:22:24.577] baz (<- NoSrc){12}: INT: 40000 0x9c40;
additonal 0 bytes of raw:
[2012-12-14 19:22:40.253] blub (<- NoSrc){13}: INT: 4 0x4; additonal 0
bytes of raw:
[2012-12-14 19:23:20.254] blub (<- NoSrc){14}: INT: 6 0x6; additonal 0
bytes of raw:
=> Man sieht schön, wie das Skript (nicht der GrAFd!) beim ersten
"baz" die 20 Sekunden (bewusst) blockiert um dann das "blub" um
19:22:40 zu senden. Die zwischenzeitlichen Nachrichten "bar" und "baz"
werden zwischengespeichert und sofort danach gemeinsam abgearbeitet.
Dieser Stand wird nun dann ein "Problem" haben, wenn in der
blockierenden Zeit mehr als eine Nachricht pro Adresse kommt. Das kann
nun gut oder schlecht sein:
- - ist es etwas vergängliches wie ein Temperaturwert passt das, denn da
will ich wohl kaum um die Historie kümmern müssen und gleich den
aktuellen verarbeiten
- - ist es etwas wie ein Impulszähler könnte es doof sein (wäre aber
lösbar durch ein kleines Skript das nur zählt und das komplexe,
blockierende, dass dann diesen Wert weiterverwendet)
=> Da beides sinnvoll erscheint: wie machen das denn die anderen, wie
z.B. HS?
CU,
Chris
PS @Dirk, Julian und Makki: ab jetzt, wie besprochen, über die
Mailingliste. Ich befürchte, da fehlt noch Euere Anmeldung über die
Projekt-Seite...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEAREIAAYFAlDLcGIACgkQoWM1JLkHou3kmQCgjgiIGQTHQOS5aBXclI0Xj+vG
GpwAoJY44jSKb0txexo4sFYtxoXEeuoD
=jdTv
-----END PGP SIGNATURE-----
|
|
From: Christian M. <ma...@Ch...> - 2011-10-12 19:34:44
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 File is deleted Am 10.10.2011 15:41, schrieb Matthias Lemke: > Hoi, > > ich habe versehentlich einen Desktop Screenshot heraufgeladen. > Bitte mal löschen. > https://sourceforge.net/apps/mediawiki/openautomation/index.php?title=File:Bildschirmfoto1.png > > danke und gruß > > greentux -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEAREIAAYFAk6V68kACgkQoWM1JLkHou1xlACfaMGnxFH7Zco62FsOM37pJTpI dQ4An1tFzRJAN7B9JrO0np4RKipNxMW6 =AJ69 -----END PGP SIGNATURE----- |
|
From: Matthias L. <m...@bo...> - 2011-10-10 14:11:02
|
Hoi, ich habe versehentlich einen Desktop Screenshot heraufgeladen. Bitte mal löschen. https://sourceforge.net/apps/mediawiki/openautomation/index.php?title=File:Bildschirmfoto1.png danke und gruß greentux |
|
From: Christian M. <ma...@Ch...> - 2011-06-10 21:05:31
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I've just released the version 0.6.0-pre1 that can be downloaded at http://sourceforge.net/projects/openautomation/files/CometVisu/CometVisu_0.6.0-pre1.tar.bz2/download This is the start of the stabilizing phase that will finally lead to the version 0.6.0 that will become the first public beta version. The 0.6.0-pre1 release is just the feature freeze, so that the remaining bugs can be more easily fixed. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEAREIAAYFAk3yhxEACgkQoWM1JLkHou0fBwCgmrwa4ElGrAT74pNyVYK3QeoN ed8An2z5JePXVDWGJb+kSRHF15gMWprV =E15E -----END PGP SIGNATURE----- |
|
From: Christian M. <ma...@Ch...> - 2011-02-06 20:25:01
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The newest internal beta release was just branched :) This will be the last release before our release candidates for the release 0.6.0 which will be the first public beta release. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEAREIAAYFAk1PA5MACgkQoWM1JLkHou3QCgCeIVFHh3bYFxk/V8MYw+cUVu4p 1eUAoJihnLQVFJfz8fWTR0RsSG1QQPKg =9tog -----END PGP SIGNATURE----- |
|
From: Christian M. <ma...@Ch...> - 2010-12-11 11:12:18
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The newest internal beta release was just branched :) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREIAAYFAk0DXIoACgkQoWM1JLkHou37cgCbBCfl0obeleRgSnjozQkWGGfH 8KgAn2HqgwENU/c8Zrn8Z2qrltIAr2wB =++51 -----END PGP SIGNATURE----- |
|
From: Christian M. <ma...@Ch...> - 2010-10-31 23:15:45
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi all, there is a new mailinglist to show all Subversion commits. The relevant information to subscribe is on the project homepage. CU, Christian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREIAAYFAkzN+JgACgkQoWM1JLkHou2jSACeIOEALBppwTjQ+JNKBj4dkWYs 5RkAnjHBf52vzdG2cX3yjaW5FX707PTi =7i5u -----END PGP SIGNATURE----- |
