Softwareverteilung unter Debian – Gambas Runtime

Probleme, Fragen und Lösungen
Antworten
Benutzeravatar
4tionov
Site Admin
Beiträge: 186
Registriert: So 18. Mai 2014, 22:40
Kontaktdaten:

Softwareverteilung unter Debian – Gambas Runtime

Beitrag von 4tionov » Di 9. Sep 2014, 15:48

Hallo,

wir haben im Betrieb einen Debian-Server mit einem eigenen Apt-Repository, von dem die Clients die hauseigene, (u.a.) in Gambas geschriebene Software ziehen. Dort würde ich auch gerne Gambas selbst paketiert ablegen, damit wir die Kontrolle darüber haben, was auf den Clients läuft. Die Clients sind derzeit nur 64-Bit Maschinen, aber das kann sich ja auch ändern.

Wie werden eigentlich die Launchpad-Repos paketiert? Gibt es da einen Automatismus, Skripte etc? Ich kann das schon alles rauskriegen, wie die Paketierung sinnvoll funktioniert, aber vielleicht gibt es ja hier schon Erfahrungen oder jemand kann mir Links zu Materialien geben ...
Alles Gute,

4tionov

tux_
Moderator
Beiträge: 944
Registriert: Di 11. Nov 2008, 20:05
Kontaktdaten:

Re: Softwareverteilung unter Debian – Gambas Runtime

Beitrag von tux_ » Mi 10. Sep 2014, 21:57

Du koenntest den Sebastian Kulesz (sebikul) von den Launchpad-Paketierern selbst fragen. Der ist ein netter Kerl, aber gelegentlich zu sehr beschaeftigt, um sofort zu antworten. Von der Seite des Gambas-Teams[0] aus findest du sicher seine EMail-Adresse irgendwo.

[0] https://launchpad.net/~gambas-team
Achtung: Es passiert, dass ich einen frisch geschrieben Beitrag innerhalb von 10 Minuten noch 3-4 Mal aendere!

Benutzeravatar
4tionov
Site Admin
Beiträge: 186
Registriert: So 18. Mai 2014, 22:40
Kontaktdaten:

Re: Softwareverteilung unter Debian – Gambas Runtime

Beitrag von 4tionov » Mi 10. Sep 2014, 23:03

tux_ hat geschrieben:Du koenntest den Sebastian Kulesz (sebikul) von den Launchpad-Paketierern selbst fragen. Der ist ein netter Kerl, aber gelegentlich zu sehr beschaeftigt, um sofort zu antworten. Von der Seite des Gambas-Teams[0] aus findest du sicher seine EMail-Adresse irgendwo.

[0] https://launchpad.net/~gambas-team


Ok, danke, ich habe mir jetzt gedacht, dass ich einfach jeweils einen funktionierenden Stand des Launchpad-Reps intern spiegeln werde. Das ist wahrscheinlich der vorläufig einfachste Weg. Wenn es nicht hinhaut, frage ich nach.

Jetzt habe ich noch eine Frage: Wie viel Leute arbeiten eigentlich aktiv an Gambas? Ich hätte zwar Lust, mich auch zu beteiligen, aber ich habe einen eigenen Betrieb und daher auch nicht soo viel Zeit ... :-/
Alles Gute,

4tionov

tux_
Moderator
Beiträge: 944
Registriert: Di 11. Nov 2008, 20:05
Kontaktdaten:

Re: Softwareverteilung unter Debian – Gambas Runtime

Beitrag von tux_ » Do 11. Sep 2014, 01:43

Regelmaeszig sieht man vier Gesichter: Benoit Minisini (>= 80% aller Beitraege, ueberall), Fabien Bodard (gb.report), Adrien Prokopowicz (gb.xml.*) und mich (hauptsaechlich gb.data) -- neben Uebersetzern und Leuten, die auftauchen und dann wieder fuer eine Zeit verschwinden.

Weiszt du schon, welcher Art deine Mitarbeit sein soll, wenn es dazu kommt? Hast du eine Idee fuer eine neue Komponente, Verbesserungen der IDE oder gar der Kernkomponenten, neue Icons, neue Beispiele, etc.? Hier im Forum fehlt noch eine Ecke fuer Fragen zur Entwicklung *fuer* Gambas (nicht nur *in* Gambas). Die koennte ich einrichten, wenn es denn jemanden gibt, der solche Fragen stellen kann.

Was Zeit betrifft: als Komponenten-Entwickler ist es schnuppe, wann du an deiner Komponente weiterarbeitest. Niemand sieht dir da auf die Finger. Was aber kritische Dinge angeht, wie den Compiler, Interpreter oder die IDE: da solltest du dich nach Minisini richten, denn wenn dort etwas nur halb fertig ist, gibt es erst einmal keine stabile Version.
Achtung: Es passiert, dass ich einen frisch geschrieben Beitrag innerhalb von 10 Minuten noch 3-4 Mal aendere!

Benutzeravatar
4tionov
Site Admin
Beiträge: 186
Registriert: So 18. Mai 2014, 22:40
Kontaktdaten:

Re: Softwareverteilung unter Debian – Gambas Runtime

Beitrag von 4tionov » Do 11. Sep 2014, 06:42

tux_ hat geschrieben:Regelmaeszig sieht man vier Gesichter: Benoit Minisini (>= 80% aller Beitraege, ueberall), Fabien Bodard (gb.report), Adrien Prokopowicz (gb.xml.*) und mich (hauptsaechlich gb.data) -- neben Uebersetzern und Leuten, die auftauchen und dann wieder fuer eine Zeit verschwinden.

Danke. Also vier Leute :-)
Donnerwetter, dafür ist wirklich viel entstanden.
Weiszt du schon, welcher Art deine Mitarbeit sein soll, wenn es dazu kommt? Hast du eine Idee fuer eine neue Komponente, Verbesserungen der IDE oder gar der Kernkomponenten, neue Icons, neue Beispiele, etc.? Hier im Forum fehlt noch eine Ecke fuer Fragen zur Entwicklung *fuer* Gambas (nicht nur *in* Gambas). Die koennte ich einrichten, wenn es denn jemanden gibt, der solche Fragen stellen kann.


Ich bin ein altgedienter VBA Programmierer, der die Software für seinen eigenen Betrieb seit 20 Jahren selbst baut. Wir haben sehr früh Postgresql und Debian entdeckt, nachdem Access unendlich buggy war und daher habe ich ein gutes Verständnis für Datenbanken, Git, Mail, das Linux Systemumfeld, PHP, Apache und Webprogrammierung, Netzwerkgeschichten. C lange ich nur im Notfall (Performance) an, am liebsten gar nicht. Da fehlt mir das Verständnis, das über absolut banale Grundlagen hinausgeht.

Im Moment bin ich dabei, unwesentliche Teile unserer Betriebssoftware auf Gambas zu portieren, nur um es mal auszuprobieren. Je längere ich damit arbeite, desto schöner finde ich Gambas. Es ist einfach, elegant und (in meinen alten Augen ;-) ) sehr modern. Und es hat einen unschlagbaren Vorteil: Ich kann große Teile unsers alten Visual Basic und VBA Code unter Linux wiederverwenden! Großartig!

Dabei fällt mir natürlich auf, dass Dinge fehlen, z.B. eine Combobox mit Autocompete, wie Access sie bietet. Deshalb habe ich mich auch mal in der Mailingliste gemeldet zu "[Gambas-user] extended Combobox". Ich bin noch nicht in der Lage, so eine Komponente zu programmieren, da fehlt mir noch das tiefere Verständnis. Aber ich fange an, "normales" Gambas einigermaßen fließend zu sprechen. Es kann also nicht mehr so arg lange dauern, bis da auch solche Komponenten kommen können.

Dann fehlt mir für eine Sprache in der heutigen Zeit eine wichtige Sache: UnitTests. Ich habe gesucht und COMUnit entdeckt, ein VB Open Source JUnit-Port. Ich habe mir das nicht so ganz genau angesehen, aber mir scheint, das könnte man einigermaßen leicht auf Gambas portieren. Das ist aber die Kür und nicht die Pflicht.

Was Zeit betrifft: als Komponenten-Entwickler ist es schnuppe, wann du an deiner Komponente weiterarbeitest. Niemand sieht dir da auf die Finger. Was aber kritische Dinge angeht, wie den Compiler, Interpreter oder die IDE: da solltest du dich nach Minisini richten, denn wenn dort etwas nur halb fertig ist, gibt es erst einmal keine stabile Version.


Also, Komponenten könnten von mir kommen, an der IDE könnte ich eventuell auch mitarbeiten, wenn ich beim Arbeiten sehe, dass da was hakt und z.B. Patches liefern (aber ich arbeite viel lieber mit Git als SVN und habe bei uns alles auf Git umgestellt, weil Linus komplett recht hat, das SVN dagegen nichts taugt).

Ob es nun sinnvoll ist, dafür ein eigenes Unterforum einzurichten, weiß ich nicht. Es würde im Moment erst mal leer bleiben, wenn es dabei nur um mich geht. Und im Forum selbst kommen ist ja eher spärlich Beiträge, da sieht ein weiterer Hungerleider auch nicht soo toll aus. Vielleicht könnte man erst mal entsprechende Beiträge entsprechend taggen, a la "[Für Gambas entwickeln]". Musst du wissen.

Aber ich sehe noch ein großes Potential für Gambas und mache gerade Werbung dafür, wo es nur geht.
Alles Gute,

4tionov

tux_
Moderator
Beiträge: 944
Registriert: Di 11. Nov 2008, 20:05
Kontaktdaten:

Re: Softwareverteilung unter Debian – Gambas Runtime

Beitrag von tux_ » Do 11. Sep 2014, 16:54

Dabei fällt mir natürlich auf, dass Dinge fehlen, z.B. eine Combobox mit Autocompete, wie Access sie bietet. Deshalb habe ich mich auch mal in der Mailingliste gemeldet zu "[Gambas-user] extended Combobox". Ich bin noch nicht in der Lage, so eine Komponente zu programmieren, da fehlt mir noch das tiefere Verständnis. Aber ich fange an, "normales" Gambas einigermaßen fließend zu sprechen. Es kann also nicht mehr so arg lange dauern, bis da auch solche Komponenten kommen können.


Um aus meiner Erfahrung zu sprechen: ganz genau! Ich habe mich erst gestern zu diesem Thema auf gambas-devel[0] geaeuszert. Der ganze Thread koennte dich interessieren (Link "View entire thread" ganz unten), wenn du wissen moechtest, wie man eigene Steuerelemente schreibt. Leider Gottes habe ich durch meine EMail-CCs nur einen Teil der Antworten (naemlich nur meine eigenen) nach gambas-user kopieren koennen (dort gehoeren solche Themen eigentlich hin).

Eine kleine Baustelle, die ich in gb.data habe, ist ein sog. Trie[1] (neben der riesigen Baustelle, der ich mich momentan widme: Graphen). Das ist die praedestinierte Datenstruktur, um Autocompletes zu implementieren. Haettest du bereits einen Trie zur Verfuegung koenntest du wahrscheinlich in <= 20 Zeilen alle ComboBoxen deines Projekts transparent (d.h. ohne den Code deiner Formulare zu aendern oder eine neue Klasse einzufuehren) auf Autocomplete umstellen..... ;-)

aber ich arbeite viel lieber mit Git als SVN und habe bei uns alles auf Git umgestellt, weil Linus komplett recht hat, das SVN dagegen nichts taugt


Das letzte Mal, als ich den Sprung nach Git vorgeschlagen habe, war Minisinis Antwort, dass er im Moment keine Zeit haette, ein fuer ihn komplett neues VCS (und mit Git ja einen anderen Arbeitsablauf) zu lernen. Wir werden sehen, was die Zeit bringt...

[0] http://sourceforge.net/p/gambas/mailman/message/32816310/
[1] http://de.wikipedia.org/wiki/Trie bzw. sieht man in einem Patricia-Trie besser, wie einfach hier Autocomplete ist: http://de.wikipedia.org/wiki/Patricia-Trie
Achtung: Es passiert, dass ich einen frisch geschrieben Beitrag innerhalb von 10 Minuten noch 3-4 Mal aendere!

Benutzeravatar
4tionov
Site Admin
Beiträge: 186
Registriert: So 18. Mai 2014, 22:40
Kontaktdaten:

Re: Softwareverteilung unter Debian – Gambas Runtime

Beitrag von 4tionov » Fr 12. Sep 2014, 07:06

tux_ hat geschrieben:Um aus meiner Erfahrung zu sprechen: ganz genau! Ich habe mich erst gestern zu diesem Thema auf gambas-devel[0] geaeuszert. Der ganze Thread koennte dich interessieren (Link "View entire thread" ganz unten), wenn du wissen moechtest, wie man eigene Steuerelemente schreibt.


Danke, ich habe das oberflächlich verfolgt. Das schaue ich mir an, wenn es so weit ist.

Eine kleine Baustelle, die ich in gb.data habe, ist ein sog. Trie[1] (neben der riesigen Baustelle, der ich mich momentan widme: Graphen). Das ist die praedestinierte Datenstruktur, um Autocompletes zu implementieren. Haettest du bereits einen Trie zur Verfuegung koenntest du wahrscheinlich in <= 20 Zeilen alle ComboBoxen deines Projekts transparent (d.h. ohne den Code deiner Formulare zu aendern oder eine neue Klasse einzufuehren) auf Autocomplete umstellen..... ;-)


Hmm, da müsste ich ein Beispiel sehen. Ich verstehe das schon, aber normalerweise reicht für Autocomplete in einer Combobox auch eine Liste (die ja eh schon vorhanden ist) und durch die man iteriert. Ich brauche das für Datenbank-Frontends. Da ist eigentlich eher das Problem, zügig (und je nach Benutzereingabe) Daten nachzuladen, wenn du eine Combobox hast und 15000 Einträge ... ;-) Besonders, wenn die DB remote läuft und durch einen langsamen VPN-Tunnel angesprochen wird.

Aber im Normalfall hat man nur bis zu hundert Einträge in der Liste, da mit For ... Each durchzugehen ist eigentlich kein Problem.

aber ich arbeite viel lieber mit Git als SVN und habe bei uns alles auf Git umgestellt, weil Linus komplett recht hat, das SVN dagegen nichts taugt


Das letzte Mal, als ich den Sprung nach Git vorgeschlagen habe, war Minisinis Antwort, dass er im Moment keine Zeit haette, ein fuer ihn komplett neues VCS (und mit Git ja einen anderen Arbeitsablauf) zu lernen. Wir werden sehen, was die Zeit bringt...


Wenn man den Produktivitätsschub sieht, den Git mit sich bringt, dann kommt Freude auf. Aber bis man den sieht, muss man erst mal lernen. ich habe mich auch erst davor gescheut, aber Git ist wirklich großartig.

Sag mal, was hältst du von dem Unittest-Ding?
Alles Gute,

4tionov

tux_
Moderator
Beiträge: 944
Registriert: Di 11. Nov 2008, 20:05
Kontaktdaten:

Re: Softwareverteilung unter Debian – Gambas Runtime

Beitrag von tux_ » Fr 12. Sep 2014, 12:47

Hmm, da müsste ich ein Beispiel sehen. Ich verstehe das schon, aber normalerweise reicht für Autocomplete in einer Combobox auch eine Liste (die ja eh schon vorhanden ist) und durch die man iteriert. Ich brauche das für Datenbank-Frontends. Da ist eigentlich eher das Problem, zügig (und je nach Benutzereingabe) Daten nachzuladen, wenn du eine Combobox hast und 15000 Einträge ... ;-) Besonders, wenn die DB remote läuft und durch einen langsamen VPN-Tunnel angesprochen wird.

Aber im Normalfall hat man nur bis zu hundert Einträge in der Liste, da mit For ... Each durchzugehen ist eigentlich kein Problem.


Richtig, das koenntest du auch ueber Iteration ueber alle Strings loesen. Aber die einzige Moeglichkeit dabei, die *ich* sehe, ist: du hast N Strings und eine Benutzereingabe. Dann musst du deine N Strings filtern -- nur die ueberleben, welche am Anfang mit der Eingabe uebereinstimmen (z.B. ueber Left$()). Unter den uebrigen M Strings besteht die Aufgabe nun darin, das laengste gemeinsame Praefix zu finden: das ist naemlich der String, der die Eingabe soweit wie moeglich (eindeutig) fortsetzt. Aber diese Loesung ist O(N*k+M*x), wenn k die Laenge der Eingabe ist, N Eintraege in der ComboBox sind, davon M den Filter ueberleben und x eine Abschaetzung fuer die Laenge des gesuchten laengsten Praefixes ist, also O((N+M)m), wobei m das Maximum der Stringlaengen in der ComboBox ist. Das fuer *jeden* Autocomplete.

Ist dein Trie der ComboBox-Liste *einmal* aufgebaut, O(N*m), wuerdest du lediglich eine Suche, O(k), im Trie ausfuehren und auf das Ende des Trie-Knotens vervollstaendigen, O(1). Der Vorteil ist beim Trie, dass du mehrere Strings simultan durchsuchst. Der Nachteil ist, dass die ComboBox-Liste ein einem Trie gespeichert werden muss. Das geht zwar recht fix, braucht aber auch mit der Patricia-Komprimierung i.A. so viel Speicher wie die Liste in der ComboBox.

Sag mal, was hältst du von dem Unittest-Ding?


Kann ich mir gut in der IDE vorstellen. Wuerde ich wohl auch nutzen und im Hinblick auf das Gambas-Buch eine gute Idee. Am liebsten haette ich ein eigenstaendiges Gambas-Programm dafuer, das von der IDE aufgerufen werden kann. Das laesst die Option offen, auch selbst Unittests von auszen zu skripten, z.B. ueber einen Cron-Job. Gambas ist ja eine sich entwickelnde Sprache und wir wuerden beim Gambas-Buch gern schnell wissen, wann Kapitel ueberarbeitet werden muessen. Bisher erledigt das mein Hirn, indem ich jeden Commit-Log lese.

Denkbar waere, dass man der Gambas-Projekthierarchie dann einen neuen Ordner hinzufuegt ".unittest" oder aehnlich, in der die IDE die Unittests haelt und ggf. durch das Unittest-Programm jagt.
Achtung: Es passiert, dass ich einen frisch geschrieben Beitrag innerhalb von 10 Minuten noch 3-4 Mal aendere!

Benutzeravatar
4tionov
Site Admin
Beiträge: 186
Registriert: So 18. Mai 2014, 22:40
Kontaktdaten:

Re: Softwareverteilung unter Debian – Gambas Runtime

Beitrag von 4tionov » Fr 12. Sep 2014, 23:06

tux_ hat geschrieben:Richtig, das koenntest du auch ueber Iteration ueber alle Strings loesen. Aber die einzige Moeglichkeit dabei, die *ich* sehe, ist: du hast N Strings und eine Benutzereingabe. Dann musst du deine N Strings filtern -- nur die ueberleben, welche am Anfang mit der Eingabe uebereinstimmen (z.B. ueber Left$()). Unter den uebrigen M Strings besteht die Aufgabe nun darin, das laengste gemeinsame Praefix zu finden: das ist naemlich der String, der die Eingabe soweit wie moeglich (eindeutig) fortsetzt. Aber diese Loesung ist O(N*k+M*x), wenn k die Laenge der Eingabe ist, N Eintraege in der ComboBox sind, davon M den Filter ueberleben und x eine Abschaetzung fuer die Laenge des gesuchten laengsten Praefixes ist, also O((N+M)m), wobei m das Maximum der Stringlaengen in der ComboBox ist. Das fuer *jeden* Autocomplete.

Ist dein Trie der ComboBox-Liste *einmal* aufgebaut, O(N*m), wuerdest du lediglich eine Suche, O(k), im Trie ausfuehren und auf das Ende des Trie-Knotens vervollstaendigen, O(1). Der Vorteil ist beim Trie, dass du mehrere Strings simultan durchsuchst. Der Nachteil ist, dass die ComboBox-Liste ein einem Trie gespeichert werden muss. Das geht zwar recht fix, braucht aber auch mit der Patricia-Komprimierung i.A. so viel Speicher wie die Liste in der ComboBox.

Hm, du verlangst aber jetzt aber nicht, dass ich das mathematisch nachvollziehen kann? ;-)

Ich denke, ich verstehe es intuitiv. Es ist eine schnelle (und vor allem bei großen Mengen an Daten nicht überproportional langsamer werdende) Art und Weise, zu dem gewünschten passenden Ergebnis zu gelangen. Nun sehe ich eine Combobox aus der Sicht eine DB-Programmierers. Sprich: Die Aufgabe des Auswählens und Sortierens überlasse ich der DB. Sehe ich z.B. die Eingabe "Mül", dann sage ich der DB "liefere mir alle Einträge in der Spalte Nachname, die mit 'Mül' beginnen, aufsteigend sortiert, und liefere bitte nur 100 Ergebnisse."

Ich kriege also eine sortierte Liste, durch die ich nicht mal groß iterieren, sondern sie nur anzuzeigen brauche. Mit dem Trie solltest du dich also bei denen melden, die Datenbanken programmieren. ;-)
Sag mal, was hältst du von dem Unittest-Ding?

Kann ich mir gut in der IDE vorstellen. Wuerde ich wohl auch nutzen und im Hinblick auf das Gambas-Buch eine gute Idee. Am liebsten haette ich ein eigenstaendiges Gambas-Programm dafuer, das von der IDE aufgerufen werden kann. Das laesst die Option offen, auch selbst Unittests von auszen zu skripten, z.B. ueber einen Cron-Job. Gambas ist ja eine sich entwickelnde Sprache und wir wuerden beim Gambas-Buch gern schnell wissen, wann Kapitel ueberarbeitet werden muessen. Bisher erledigt das mein Hirn, indem ich jeden Commit-Log lese.

Unbedingt sollten Unittests unabhängig von grafischen Ausgaben funktionieren. Bei mir läuft ein Jenkins, der meinen Code untersucht, testet und bewertet. Eine große Hilfe. Wenn du weißt, dass das, was du gerade gecodet hast, nicht wichtigen älteren Code bricht, der an anderer Stelle läuft, ist das schon sehr fein. Dazu gehört aber, dass man so programmiert, dass die einzelnen Funktionen oder Klassen möglichst wenig Abhängigkeiten haben und für sich selbst funktionieren.
Denkbar waere, dass man der Gambas-Projekthierarchie dann einen neuen Ordner hinzufuegt ".unittest" oder aehnlich, in der die IDE die Unittests haelt und ggf. durch das Unittest-Programm jagt.


Ja, das wäre schick. Träum ...
Alles Gute,

4tionov

Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast