Dev-Fragen

 
macemmi
Benutzer
Avatar
Geschlecht:
Homepage: pecuniabanking.de
Beiträge: 423
Dabei seit: 09 / 2009
Betreff:

Re: Dev-Fragen

 · 
Gepostet: 13.03.2010 - 23:43 Uhr  ·  #21
Die Quellen zu Version 0.2 sind seit ein paar Tagen als SVN verfügbar:
https://debugmode.de/svn/pecunia/
Vorteil ist die nahtlose Integration von SVN in XCode (ich kenne Git jetzt nicht, kann natürlich sein, dass das damit auch geht).
Die Quellen zu 0.3 kommen da auch rein, sobald die erste Testversion fertig ist. Damit können dann auch andere Entwickler beisteuern.
macemmi
Benutzer
Avatar
Geschlecht:
Homepage: pecuniabanking.de
Beiträge: 423
Dabei seit: 09 / 2009
Betreff:

Re: Dev-Fragen

 · 
Gepostet: 14.03.2010 - 00:12 Uhr  ·  #22
Zitat
Mein zweiter Vorschlag wäre, dass ich das meinem Cousin sage. Er wollte sich Dir letztes Jahr anbieten, aber dann hast Du wohl nicht mehr auf seine Mails reagiert. Ich sage Ihm das einfach mal, vielleicht hat er ja noch Interesse.

Ich kriege sehr viele Mails and die Supportadresse...da hab ich schon öfter eine übersehen, bzw. hintenangestellt (Problemlösungen haben Vorrang) und dann vergessen. Einfach hartnäckig bleiben... 8)

Zitat
Gerne. Ich kann etwas in Objective-C und C beisteuern; mit Java habe ich halt nichts am Hut. Und es wird erst mal ein recht kurzes Engagement, da wir in Kürze unser Haus renovieren.

Es gibt auch genug in Cocoa zu tun. Allerdings sollte man schon etwas Zeit mitbringen.

Zitat
Und wenn es ein öffentliches Repository gibt an dem man einfach ganz ungezwungen mitarbeiten kann, finden sich auch mehr Leute die sich spontan dafür entscheiden.

Mit "ungezwungen mitarbeiten" ist es so eine Sache. Ich habe nicht vor dass jeder beliebige Entwickler im SVN Beiträge committen kann. Wir haben es hier mit einer Banking-Anwendung zu tun und da ist Sicherheit und Stabilität von höchster Bedeutung. Ich hätte schon gerne eine gewisse Kontrolle darüber, was in eine Auslieferung kommt und was nicht - so ähnlich wie Linus Torvalds seine Hand auf dem Linux-Kernel hatte. Vielleicht geht das ja mit Git, ich hab mich noch nicht damit beschäftigt.
Ich stelle mir das so vor, dass es eine (wachsende) Entwicklergemeinde um Pecunia gibt, in der jeder einen definierten Beitrag leistet und damit natürlich auch Quellen committen kann.
yesman
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 144
Dabei seit: 03 / 2009
Betreff:

Re: Dev-Fragen

 · 
Gepostet: 15.03.2010 - 19:47 Uhr  ·  #23
Zitat geschrieben von macemmi
Vorteil ist die nahtlose Integration von SVN in XCode (ich kenne Git jetzt nicht, kann natürlich sein, dass das damit auch geht).

Das geht noch nicht mit git oder hg.

Zitat geschrieben von macemmi
Zitat
Und wenn es ein öffentliches Repository gibt an dem man einfach ganz ungezwungen mitarbeiten kann, finden sich auch mehr Leute die sich spontan dafür entscheiden.

Mit "ungezwungen mitarbeiten" ist es so eine Sache. Ich habe nicht vor dass jeder beliebige Entwickler im SVN Beiträge committen kann. Wir haben es hier mit einer Banking-Anwendung zu tun und da ist Sicherheit und Stabilität von höchster Bedeutung. Ich hätte schon gerne eine gewisse Kontrolle darüber, was in eine Auslieferung kommt und was nicht - so ähnlich wie Linus Torvalds seine Hand auf dem Linux-Kernel hatte. Vielleicht geht das ja mit Git, ich hab mich noch nicht damit beschäftigt.
Ich stelle mir das so vor, dass es eine (wachsende) Entwicklergemeinde um Pecunia gibt, in der jeder einen definierten Beitrag leistet und damit natürlich auch Quellen committen kann.

Das ist mir klar. Aber so habe ich das auch nicht gemeint. Da soll natürlich nicht jeder committen können.

Sondern wenn jemand einen Bug findet, kann er sich einfach den aktuellen Sourcecode holen, und ihn wenn möglich beheben. Dann braucht er Euch nur noch einen diff/patch zu schicken. - Aber ohne dass man sich vorher wieder irgendwo an einem Portal anmelden muss.
aquamaniac
Benutzer
Avatar
Geschlecht: keine Angabe
Herkunft: Hamburg
Homepage: aqbanking.de/
Beiträge: 642
Dabei seit: 03 / 2005
Betreff:

Re: Dev-Fragen

 · 
Gepostet: 08.04.2010 - 01:30 Uhr  ·  #24
Zitat geschrieben von macemmi

Noch ein paar Worte zu hbci4java vs. AqBanking:
Die Arbeit mit AqBanking war auf dem Mac sehr mühsam. Insbesondere die libs soweit zu bringen, dass sie relokierbar sind (Modifikationen nötig!). Außerdem lassen sie sich (zumindest bei mir) nicht debuggen, ich hab schon alles Mögliche versucht. Ein Problem, nämlich der Timeout unter Netzwerklast, kann ich bis heute nicht erklären - ist einfach nicht zu fixen. Und: ich musste immer wieder um Fehler in den libs "rumprogrammieren".


Ehrlich gesagt verstehe ich das jetzt nicht: Ich verwende AqBanking, Gwen und Libchipcard schon lange fuer meine Aqbanking-CLI mit EBICS-Support als relozierbare Bibliotheken. Dafuer habe ich ja extra die entsprechenden Switches in die configure-Scripts eingebaut. Und dass das ganz gut funktioniert, sieht man jetzt auch an AqFinance: Das ist eine grafische Finanzapplikation, die ebenfalls die beteiligten Bibliotheken relozierbar enthaelt.

Und das Debuggen funktioniert bei mir auch gut (halt simpel mit gdb). Soll heissen: Haettest Du vor dem Umstieg nach Hbci4Java bei mir nachgefragt, haette ich Dir da sicher ein paar Tips geben koennen...

Zitat geschrieben von macemmi

Da ich wusste, dass 0.3 eine neue Version der libs benötigt hab ich Martin gefragt, ob bestimmte GVs (z.B. Investments, etc.) in nächster Zeit in AqBanking implementiert werden. Er meinte er hätte wenig Zeit, d.h. nein.


Ein weiterer Grund ist halt, dass es fuer Investment-GVs bisher so gut wie keine Anfragen gab.

Zitat geschrieben von macemmi

Der Stand heute ist der, dass hbci4java integriert und 0.3 quasi kurz vor der ersten Auslieferung steht. Natürlich ist es immer noch möglich, AqBanking wieder drunterzulegen - ich bin mir aber nicht sicher, ob das die bessere Alternative ist.


Ich glaube auch nicht, dass man hier von besser oder schlechter sprechen kann. Beide Projekte haben ihre Vor- und Nachteile. Ich denke nur, Du haettest vor dem Umstieg vielleicht etwas mehr kommunizieren koennen.

An AqBanking wird derzeit jedenfalls ziemlich aktiv gearbeitett. Unter anderem arbeite ich an neuen Einrichtungs-Assistenten, die eventuell auch von MacOSX aus verwendet werden koennten (wenn die entsprechenden GUI-Klassen zur Verfuegung gestellt werden).


Gruss
Martin
macemmi
Benutzer
Avatar
Geschlecht:
Homepage: pecuniabanking.de
Beiträge: 423
Dabei seit: 09 / 2009
Betreff:

Re: Dev-Fragen

 · 
Gepostet: 08.04.2010 - 17:33 Uhr  ·  #25
Hallo Martin,

Zitat
Ehrlich gesagt verstehe ich das jetzt nicht: Ich verwende AqBanking, Gwen und Libchipcard schon lange fuer meine Aqbanking-CLI mit EBICS-Support als relozierbare Bibliotheken. Dafuer habe ich ja extra die entsprechenden Switches in die configure-Scripts eingebaut. Und dass das ganz gut funktioniert, sieht man jetzt auch an AqFinance: Das ist eine grafische Finanzapplikation, die ebenfalls die beteiligten Bibliotheken relozierbar enthaelt.

Und das Debuggen funktioniert bei mir auch gut (halt simpel mit gdb). Soll heissen: Haettest Du vor dem Umstieg nach Hbci4Java bei mir nachgefragt, haette ich Dir da sicher ein paar Tips geben koennen...


ich hab ja nachgefragt, mehr als einmal. Und du hattest mir ja auch geholfen. Ohne deine Tipps bezüglich der Configure-Parameter wäre mein Versuch ja schon im Ansatz gescheitert. Nur: es hat trotzdem nicht funktioniert. Möglicherweise liegt das an den verschiedenen libloadern in Linux und BSD, keine Ahnung. Und auch der XCode benutzt letztendlich gdb, trotzdem hat das Debuggen von GWEN nicht funktioniert, egal was ich in configure angegeben hatte. Zum Schluss bin ich sogar hingegangen und hab GWEN und Aq soweit modifiziert dass alles in einer statischen Lib gebunden war. Der Umfang der Änderungen war mir aber letztendlich zu groß. Wie schon erwähnt, ich hab sehr viel Zeit mit den Libs verbracht, streckenweise hab ich sogar nichts anderes gemacht. Letztendlich sind sie in der derzeitigen Form relozierbar - das war aber sehr viel Arbeit und die möchte ich nicht jedesmal machen wenn ein neues Update kommt.
Es wird einfach Zeit, dass du dir mal einen Mac zulegst...;-)

Zitat
Ich glaube auch nicht, dass man hier von besser oder schlechter sprechen kann. Beide Projekte haben ihre Vor- und Nachteile. Ich denke nur, Du haettest vor dem Umstieg vielleicht etwas mehr kommunizieren koennen.

Ich wollte erstmal ausprobieren ob's überhaupt funktionieren kann. Das Timeout-Problem z.B. (hier konnte ich in deinem Code keinerlei Fehler feststellen, reiner POSIX-Standard, trotzdem macht der Mac Probleme) tritt mit hbci4java nicht mehr auf.
aquamaniac
Benutzer
Avatar
Geschlecht: keine Angabe
Herkunft: Hamburg
Homepage: aqbanking.de/
Beiträge: 642
Dabei seit: 03 / 2005
Betreff:

Re: Dev-Fragen

 · 
Gepostet: 08.04.2010 - 17:53 Uhr  ·  #26
Zitat geschrieben von macemmi

der Änderungen war mir aber letztendlich zu groß. Wie schon erwähnt, ich hab sehr viel Zeit mit den Libs verbracht, streckenweise hab ich sogar nichts anderes gemacht. Letztendlich sind sie in der derzeitigen Form relozierbar - das war aber sehr viel Arbeit und die möchte ich nicht jedesmal machen wenn ein neues Update kommt.


Die gesamte AqBanking-Familie ist vollstaendig relozierbar, wenn man bestimmte ./configure-Parameter angibt. Das klappt in aqbanking-cli (die bisherigen Version der EBICS-Variante von AqBanking-CLI enthalten ja auch die Bibliotheken in statisch gelinkter Form) und in AqFinance.

Das es auch auf dem Mac gehen muss, zeigt das leicht kontroverse Beispiel "Saldomat": Auch die linken die Bibliotheken statisch.

Aber: Ich persoenlich bin vom statischen Linken weg, da es durch einfaches Setzen einer Umgebungsvariable zumindest unter Linux sehr leicht moeglich ist, den Pfad zu den Bibliotheken anzugeben. Das macht bei mir nun jeweils ein Skript. Man ruft also nicht mehr direkt die Tools auf, sondern ueber ein Skript, welches vorher LD_LIBRARY_PATH entsprechend setzt. Die beteiligten Bibliotheken (BTW: Auch die Dependencies) werden dann in einem Gesamtpaket einfach mitgeliefert.

Da wir intern die Relozier-API von libgwen verwenden, kann auch nach der Installation noch das gesamte Paket beliebig verschoben werden, auch von einem Rechner zum anderen. Soll heissen: Da ich selbst auch auf relozierbaren Code angewiesen bin, wird das unter Linux und Windows vollstaendig unterstuetzt.

Allerdings kenne ich mich mit den Macs ueberhaupt nicht aus. Ich weiss z.B. nicht, wie man auf dem System den Pfad des laufenden Binary ermitteln kann (unter Linux geht das durch das /proc-Dateisystem).

Es wuerde auch nichts bringen, wenn ich mir einen Mac besorgen wuerde: Tatsaechlich hatte ich mir vor ein paar Jahren mal einen alten iMac angeschafft. Dafuer ein MacOSX zu bekommen, war schon nicht soo preiswert. Und dann muss man - wenn man darauf programmieren will - jeweils die neuesten Version von MacOSX nachkaufen, und das geht mir auf die Dauer zu sehr ins Geld. Hinzukam, dass ich dann z.B. bei manchen Fink-Sachen feststellen musste, dass ich bestimmte Development-Kits irgendwie nicht finden konnte (war damals irgendein Audio-Krams) oder wohl auch wieder nachkaufen muesste. Da habe ich dann nach ein paar Wochen probierens aufgehoert, mich um den Mac zu kuemmern.

Wenn ich selbst von MacOSX begeistert waere, wuerde ich das ja noch hinnehmen, aber fuer mich persoenlich kaeme MacOSX nur zum Erstellen von Paketen fuer dieses System in Frage, nicht als taegliches Arbeitssytem.


Gruss
Martin
bugmenot
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 196
Dabei seit: 11 / 2009
Betreff:

Re: Dev-Fragen

 · 
Gepostet: 13.04.2010 - 10:09 Uhr  ·  #27
Zitat geschrieben von aquamaniac
Das es auch auf dem Mac gehen muss, zeigt das leicht kontroverse Beispiel "Saldomat": Auch die linken die Bibliotheken statisch.

Ich kenne das nicht. Was ist daran kontrovers?

Zitat geschrieben von aquamaniac
Allerdings kenne ich mich mit den Macs ueberhaupt nicht aus. Ich weiss z.B. nicht, wie man auf dem System den Pfad des laufenden Binary ermitteln kann (unter Linux geht das durch das /proc-Dateisystem).

Das wäre nicht schwer.
Code
#include <sys/param.h> 
#include <stdlib.h> 
  
  char binarypath[1024]; 
  uint32_t pathsize = sizeof(binarypath); 
  
  _NSGetExecutablePath(binarypath, &pathsize); 
  printf("binarypath: %s \n", binarypath);


Zitat geschrieben von aquamaniac
... hatte ich mir vor ein paar Jahren mal einen alten iMac angeschafft. Dafuer ein MacOSX zu bekommen, war schon nicht soo preiswert.

Ein Mac OS X Tiger hätte ich Dir bei Bedarf geschenkt. Und Snow Leo bekommt man aktuell bei Amazon für etwa 25 €.
aquamaniac
Benutzer
Avatar
Geschlecht: keine Angabe
Herkunft: Hamburg
Homepage: aqbanking.de/
Beiträge: 642
Dabei seit: 03 / 2005
Betreff:

Re: Dev-Fragen

 · 
Gepostet: 13.04.2010 - 11:00 Uhr  ·  #28
Zitat geschrieben von www.bugmenot.com
Zitat geschrieben von aquamaniac
Das es auch auf dem Mac gehen muss, zeigt das leicht kontroverse Beispiel "Saldomat": Auch die linken die Bibliotheken statisch.

Ich kenne das nicht. Was ist daran kontrovers?


Kontrovers ist die Art der Verwendung von AqBanking. Man umgeht dort die GPL dadurch, dass man nicht direkt AqBanking verwendet, sondern stattdessen ein kleines Tool geschrieben hat, welches aus Saldomat heraus aufgerufen wird. Dadurch faellt vermutlich nur das Tool unter die GPL und die Leute koennen trotzdem meine Arbeit benutzen, damit Geld machen und muessen die Software nicht unter die GPL stellen.

Diese Vorgehensweise hat nur einen Nutzniesser (naemlich den Hersteller der proprietaeren Anwendung), daher finde ich persoenlich das "kontrovers".

Zitat geschrieben von www.bugmenot.com

Das wäre nicht schwer.
Code
#include <sys/param.h>
#include <stdlib.h>

char binarypath[1024];
uint32_t pathsize = sizeof(binarypath);

_NSGetExecutablePath(binarypath, &pathsize);
printf()"binarypath: %s \n", binarypath);


Ok, d.h. "binarypath" enthaelt dann den volstaendigen PFad und Namen des Binary?

Zitat geschrieben von www.bugmenot.com

Ein Mac OS X Tiger hätte ich Dir bei Bedarf geschenkt. Und Snow Leo bekommt man aktuell bei Amazon für etwa 25 €.


Danke, das ist nett gemeint, aber wie gesagt: Es mangelt bei mir dann an den Setup-Moeglichkeiten (daran bin ich damals jedenfalls gescheitert: Irgendwelche Teile fehlten immer und waren irgendwie nicht frei erhaeltlich).


Gruss
Martin
bugmenot
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 196
Dabei seit: 11 / 2009
Betreff:

Re: Dev-Fragen

 · 
Gepostet: 13.04.2010 - 13:42 Uhr  ·  #29
Zitat geschrieben von aquamaniac
Kontrovers ist die Art der Verwendung von AqBanking. Man umgeht dort die GPL dadurch, dass man nicht direkt AqBanking verwendet, sondern stattdessen ein kleines Tool geschrieben hat, welches aus Saldomat heraus aufgerufen wird. Dadurch faellt vermutlich nur das Tool unter die GPL und die Leute koennen trotzdem meine Arbeit benutzen, damit Geld machen und muessen die Software nicht unter die GPL stellen.

Diese Vorgehensweise hat nur einen Nutzniesser (naemlich den Hersteller der proprietaeren Anwendung), daher finde ich persoenlich das "kontrovers".

Oha! Das ist in der Tat kontrovers. Da wäre ich aber etwas verstimmt.

Zitat geschrieben von aquamaniac
Ok, d.h. "binarypath" enthaelt dann den volstaendigen PFad und Namen des Binary?

Ja, genau. - PS: Dieser Pfad kann auch relative Elemente (wie SymLinks) enthalten.

Wenn man den absoluten Pfad braucht, kann man den einfach hiermit "entfalten":
Code
  char absolutepath[1024];
  realpath(binarypath, absolutepath);

  printf("absolutepath: %s\n", absolutepath); // Ausgabe
Gewählte Zitate für Mehrfachzitierung:   0