CometVisu - (interner) Beta-Test

[swiss]

Ich meine die Javascript animation beim seitenübergang. Aber das wird von extern nicht möglich sein, das das Javascript direkt auf dem Client ausgeführt wird.

Machst Du nen Feature-Request? Dann schau ich mir das mal an. Aber ich will nix versprechen.

Ok mach ich bei Gelegenheit. Hat aber überhaubt keine Eile. Ich habe noch genug mit der Doku im SF zu tun

[JNK]

Ich meine die Javascript animation beim seitenübergang. Aber das wird von extern nicht möglich sein, das das Javascript direkt auf dem Client ausgeführt wird.

Achso. Das ist einfach. Habe ich schlichtweg übersehen. Wird gefixt.

Gruss,

der Jan

[JNK]

Ok mach ich bei Gelegenheit. Hat aber überhaubt keine Eile. Ich habe noch genug mit der Doku im SF zu tun

Hab ich dann mal erledigt.

Gruss,

der Jan

[Chris M.]

Ich wünsche mir bis dahin bitte eindeutige Nummerische Versionsnummern (1..1000 mit Punkten dazwischen )

Da wir für "trunk" im Feature-Freeze sind, habe ich das in post_0.6.0-branch committed. [...]
Ich finde das Verfahren etwas unglücklich, nach der 0.6.0 sollten wir uns über die Frage Release/Branch/Trunk usw. nochmal unterhalten. Ich würde da das "mozilla"-Verfahren glaube ich vorziehen.

Passt beides grob zusammen.

Zu Benamungsschemata und Branch-Verfahren bin ich gerne offen für Diskussionen.

Mein aktueller Standpunkt:
Zu den Namen:
Eine 1.0... wollte ich erst vergeben, wenn's für die Masse stabil und nutzbar ist, so wie die für mich essentiellen Features (d.h. auch 2D und 3D!) hat.
=> Bis dahin sind wir unter 0.x...

Die erste öffentliche Version war 0.5.0.
Die öffentliche Beta wird 0.6.0 sein. Die Zwischenschritte zu 1.0.0 sind noch nicht definiert.

Jetzt in der Stabilisierungsphase ist die große Frage wie man mit den Versionsnummern umgeht.
Eine 0.5.99 (gab's bei KDE IIRC)? Finde ich unschön.
Eine 0.6.0-pre und 0.6.0-RC1 / 0.6.0-RC2 fand ich deutlich passender. Dabei habe ich sogar darauf geachtet, dass eine lexikografische Sortierung dafür sorgt, dass die Reihenfolger bzgl. der Neuigkeit erhalten bleibt...

Zum Branch-Verfahren:
Ich bin eigentlich davon ausgegangen, dass wir eine sehr lineare Arbeitsweise haben. D.h. einen Branch gibt es nur für ein Release und ggf. notwendige minimale Korrekturen. D.h. alle arbeiten eigentlich unter HEAD.

Nun stellte sich aber das Problem, dass sich Änderungen angesammelt haben, die erst nach dem Feature Freeze wieder dazu kommen sollten. Also quasi ein Merge Window erforderlich machen würden.

Mir ist nun wichtig, dass maximal viele unter HEAD testen, aber ich will auch keine Weiterentwicklungen auf den Platten versauern lassen, nicht dass ein HDD-Crash kommt

Einen zweiten Wunsch hätte ich aber immernoch fürs finale Release: das minify der JS im release statt das danach im Packerl zu machen (was auch nur bisher zu 50%-> ich machs auch, machs jetzt ja auch halbwegs händisch im packerl..)

Kann ich gerne machen, ich release ja auch inzwischen per Skript, da kann ich das gut einbauen...
Was verwendest Du für's Minify?

Diese Änderung würde ich aber gerne erst nach 0.6.0 machen...

Ich hab da nochmal eine Frage. Jetzt wo mit Rev. 476 alle DPT gehandelt werden: wäre es nicht sinnvoll in der transform_knx.js folgende Änderung vorzunehmen:

Das "default-decode" kommt z.B. in

DPT1 statt DPT1.001

Alle nicht-spezial-Transformationen werden entfernt (werden ja eh durch den Standard erledigt.

Das würde den Code wahnsinnig aufräumen.

Ja und Nein.

Gerade so Feinheiten wie Einheiten werden wir so nicht abhandeln können.

[swiss]

Hab ich dann mal erledigt.

Gruss,

der Jan

Wooow! Das ging ja fix. DANKE Mir fallen gerade 1'000 Dinge ein für was man das gebrauchen kann... (Warnseiten, Adminseiten, Benutzerseiten...)

Genau dass hat mich beim HS immer gestört.

[Chris M.]

Mir fallen gerade 1'000 Dinge ein für was man das gebrauchen kann... (Warnseiten, Adminseiten, Benutzerseiten...)

Wobei wir auch noch die Popups haben.

Aber IMHO ergänzt sich beides sehr gut!

[greentux]

Huch, Popus per GA? Hab ich was übersehen?

Zur Releaseproblematik.

Sobald Du für einen Release Feature Freeze machst, mußt Du zwangsläufig branchen, wenn denn in HEAD fröhlich weitergearbeitet werden soll. Oder man hat Merge Windows und stabilsiert dann gemeinsam.
Abwägungssache. Das eine erzeugt mehr Arbeit (Merges zwischen Branche(s) und HEAD), das andere läßt die Neuerungen bei den Entwicklern auf der Platte...

[Chris M.]

Huch, Popus per GA? Hab ich was übersehen?

Nein.

Popups sind zur Zeit noch eher stiefmütterlich behandelt (ich hab schon seit ein paar Monaten dort nicht mehr in den Code geschaut...), insbesondere weil der Editor keine Möglichkeit hat die mit Inhalt zu befüllen. Ist also etwas Henne/Ei.

[makki]

Zu Benamungsschemata und Branch-Verfahren bin ich gerne offen für Diskussionen.

Nun, was SVN angeht bin ich glaube ich Halb-Anfänger wie wir alle, bei .debs vielleicht ambitionierter Intermediate (nicht-nummerische Upstream-Nummern sind jedenfalls rückblickend nicht so ganz praktisch.. das weiss ich aber auch erst seit ich es mit -preX und -rcY mal ausprobiert habe )
-> das mit den branches ist glaub ich gut
(einziges Missverständniss: wenn ich einen Fix habe, dann wird der so wie ich das kenne in trunk commited und dann in die branch gemerged aber ich bin da wirklich auch nur halbwissender laie!)
Ausserdem fehlen uns hierzu wie Chris schon anmerkte evtl. dann doch deutlich die Resourcen, mehrere releases so zu pflegen..
(beim WG halte ich das ja ähnlich/nicht anders obwohl es technisch vorgesehen&möglich wäre beta&release zu unterscheiden: no way das organisatorisch mit vertretbarem Aufwand zu machen!)

-> kann dazu neben dem aktuellen Modell nur einbringen: lieber ein "trunk" als 3, irgendwer muss es vor dem release dann aber aufwändig testen!

(ich glaube ich hatte die Frage schonmal gestellt: hat jemand Erfahrung mit automatischen Testroutinen für sowas? das wäre IMHO ein essentieller Beitrag! Fehler dürfen passieren, aber bitte nur 1x, beim 2. mal sollte das Makefile den finden.. Beim transform_knx würde ich das auch übernehmen aber ohne Vorlage.. AFAIR sind z.B. 90% des codes von sqllite nur testroutinen..)
Mag aus meinem Mund komisch klingen, aber wenn man Testroutinen fürs WG hat, dann auch für den Rest und hier viel schlimmmer: tausende mögliche Clients!?

Mein aktueller Standpunkt:
Zu den Namen:
Eine 1.0... wollte ich erst vergeben, wenn's für die Masse stabil und nutzbar ist, so wie die für mich essentiellen Features (d.h. auch 2D und 3D!) hat.

Jede OSS die etwas auf sich hält und jünger als 10J ist hat 0.x Vielleicht ein Form von Respekt, understatement oder Hohn ggü. "Profis" wo nach vielen Jahren in Version 11.0.1.152 immernoch jeden Tag der Browser von Millionen Anwendern wegen diesem Stück Sch** abkachelt (so bei mir gerade, genau hier, der Fehler war natürlich im anderen Tab, eine AW 2x zu schreiben macht keinen Spass und treibt den Blutdruck enorm..)

Dabei habe ich sogar darauf geachtet, dass eine lexikografische Sortierung dafür sorgt, dass die Reihenfolger bzgl. der Neuigkeit erhalten bleibt...

Theoretisch gut, in der Praxis bringt apt* da aber einige - nennen wir es mal Eigenheiten - mit. Ich mag ja perl.. meistens.. hier nicht..

Was verwendest Du für's Minify?
jsmin

Als wir seinerzeit (ca. 30-80 Seiten zurück) darüber sprachen habe ich mir alle angesehen, drei blieben übrig, eins war schrott (#3: Name vergessen, das menschliche Hirn kann das ja zum Glück: unrelevantes einfach wieder automatisch löschen) ein anderes in Java, das war objektiv wenige % besser funktionierte aber Java-typisch erstmal nicht und gab stattdessen seitenlange Exception: in.ist.mir.egal.ob.du.das.kapierst.will.ich.garnic ht.wissen.warum.der.programmierer.ein.gaskopf.ist. der.fehler.nicht.sauber.abfängt.im.Source.stehts.v ielleicht.wenn.du.den.auch.hast.und.lesen.kannst

Das fiel also auch aus, daher fiel die Wahl auf jsmin; das recht alt, recht ehrlich, verständlich. Aber alt ist nicht zwangsweise schlecht weil das kann auch bedeuten das es da einfach mal jemand richtig gemacht hat Und das gab bisher keine Probleme..

+

#!/bin/bash

for FILE in $( find ../var/www/visu/ ! -name *.min.js -name *.js ); do
        echo "Process $FILE"
        FILENAME=`basename $FILE`
        BASEPATH=`echo $FILE | sed 's/\.[^\.]*$//'`
        #echo "baspatch $BASEPATH"
        if [ ! -e $BASEPATH.min.js ]; then
                echo "NO minified for $FILE - creating"
                jsmin < $FILE > $BASEPATH.min.js "(c) see LICENSE or according non-minified versions shipped with this package"
        fi
        # Now replace all occurences in include 
        #FIXME: look on path also!
        sed -i s/$FILENAME\.js/$FILENAME\.min\.js/g ../var/www/visu/*.html

WG_custom_debian_packages/cometvisu-0.6-rc2/DEBIAN/minify.sh

Den Rest mache ich - wo es sich rentiert (ich hab das echt mal ausprobiert..) wirklich ganz von hand..

Diese Änderung würde ich aber gerne erst nach 0.6.0 machen...

Klar, prio hat das keine, ich beantrage aber schonmal das das finale release von 0.6 -> 0.6.1+=(nummer-danach-beliebig) heisst. Weil 3-4 haben meine teils verzweifelten versuche, apt zu überlisten runtergeladen (ich kenne nur die IP, nicht den User) und es ist einfacher die Nummer hochzuzählen als den 4 zu erklären warum das update nicht ging.. Ist auch egal (jeder der eine 0.6>rc1 [menschliche lesart] hat ist bei -rc2)
Mein interner Nummernzwang legt mir das aber auch auf

Ja und Nein.
Gerade so Feinheiten wie Einheiten werden wir so nicht abhandeln können.

Definitiv, aber dafür müsste man DPT's konsequent umsetzen (was zwar IMHO sinnvoll wäre - bisher aber absolut niemand so macht, also keine Hektik..) Aber das wäre ein Killer-feature, das die Visu automatisch weiss, das es sich da um einen 2byte DPT9 in °C handelt, nur weil man das einmal in der ETS eingestellt hat.. (ehrlich, für was sind die DPTs sonst gut? um zu wissen ob man eins oder zwei Byte vom bus wertfrei zu lesen sollte EIS auch reichen..
Ich mache weiter, steter Tropfen höhlt den Stein und jeder der es noch nicht verinnerlicht hat, denkt mal dran, warum DPT's mit impliziten Datentyp+Einheit eigentlich verdammt hilfreich wären - wenn es denn irgendwer nutzen täte..(also in einfach: man beim empfänger vorher wüsste das es sich hier nicht nur um 2 byte sondern um einen DPT9.001 float mit der Einheit °C handelt und das nicht erst zusammenklicken müsste..)

Makki

[greentux]

(einziges Missverständniss: wenn ich einen Fix habe, dann wird der so wie ich das kenne in trunk commited und dann in die branch gemerged aber ich bin da wirklich auch nur halbwissender laie!)

So sollte es sein. In der Praxis ist es meistens andersrum, da das Release Prio hat wird dort gefixt und anschliessend gesammlet nach HEAD (Trunk) also in den Upstream Zweig übertragen.

Die nächste Version, die abgespalten wird, sollte dann 0.7.0 heissen, 0.6.1 wäre aus meiner Sicht ein Bugfix zur 0.6.0, der aus dem 0.6.x Branch kommen müsste... Wenn man so einen Bugfixrelease machen möchte.

[netzkind]

PS @Julian: Was ich jetzt noch gerne hätte, wäre dem Editor sagen zu können, welchen "Datentyp" ich bei Variant erwarte ähnlich den normalen Attributen. Dann könnte man da auch Listen hinterlegen, die dem Endanwender deutlich weiterhelfen könnten...

Hm, da müsste man dann einiges an den structure_*.js ändern - derzeit gibt man ja nur an dass man address haben will. Zusätzlich muss der Editor darauf reagieren und select anstelle der inputs anbieten.
Geht sicher irgendwie, aber ich hab leider (wie man auch an meiner Beteiligung hier merkt) meinen Kopf derzeit mit ganz anderen Dingen voll

Wenn jemand anderes da bei will, dann ab dafür!

Grüße,
Julian

[chriss1980]

Hallo zusammen,

auch wenn ich hier nicht aktiv mithelfe, nur kurz zu meiner beruflichen Erfahrung mit SVN.
Generell sollte unterschieden werden in taggen von Versionen, die freigegeben sind (also als .deb in Repository wandern) und branchen von Versionen als Nebenentwicklungszweig.
Ein Release 0.6.0 sollte also folglich zum einen getaggt (ab da read-only) und, wenn gleichzeitig im trunk weitere Features entwickelt werden, für das bugfixing gebrancht werden. Wenn es nun Bugfix-Releases gibt, so wird einfach aus dem 0.6.0-branch ein entsprechendes 0.6.x getaggt.
Die nächste Version mit neuen Features wird nach gleichem Schema getaggt/gebrancht und im besten Fall wird der 0.6.0-Branch vorher vollständig mit trunk gemergt und verschwindet damit als eigener Pfad aus dem Repository.

just my 2c
Christian

[JNK]

Ich versuche mich gerade am Rendering-Problem der Diagramme, und ich habe einen Verdacht, was das Problem ist, nur müsste ich dazu durch die jquery.flot.js debuggen. Die sehe ich leider im Firebug nicht. Hat jemand eine Idee, woran das liegen könnte?

templateengine.js und die structure_plugin.js und sowas sind alle da.

gruss,

der Jan

[Chris M.]

Ich versuche mich gerade am Rendering-Problem der Diagramme, und ich habe einen Verdacht, was das Problem ist, nur müsste ich dazu durch die jquery.flot.js debuggen. Die sehe ich leider im Firebug nicht. Hat jemand eine Idee, woran das liegen könnte?

Das Problem ist das verschachtelte

$("body").append("<script type=\"text/javascript\" src=\"plugins/diagram/flot/jquery.flot.js\"></script>");

Das ist ein bekanntes Problem, und der Chromium ist da nicht besser...

Wenn's nur zum debuggen ist: ändert einfach die index.html und lade das Skript direkt (wahrscheinlich muss dazu die o.g. Zeile entfernt werden)

Bevor Du aber die jquery.flot.js anpasst, sollten wir das ggf. auf eine neue Version wechseln und/oder nach upstream schieben

[makki]

Das Problem ist das verschachtelte

Jep, da bin ich auch schonmal drübergestolpert (ohne damals zu verstehen warum..)

Bevor Du aber die jquery.flot.js anpasst, sollten wir das ggf. auf eine neue Version wechseln und/oder nach upstream schieben

110% Ack! Wir haben echt schon genug "lokale" sonderlocken (die alle aber keineswegs direkt "gewollt" sind.. sobald ich die Zeit finde und es allgemeiner wird, will ich solche Sachen wie eibread/write-cgi, rrdtool fetchj upstream bringen! Da traue ich mir aber aktuell zu, das einfach noch hier im Griff zu halten..)

Die Diagramme gehören ja echt zu meinen "Lieblingsfeatures" (und es gibt da ein paar Probleme..)-> wenn es ein Problem in Flot ist (da steige ich aus!) sollten wir versuchen - und ich mach da gerne mit - es "upstream" zu melden/beheben, bevor wir einen lokalen CV-workaround bauen..
Denn genau das, Probleme in jQuery oder Plugins "lokal" zu umgehen ist langfristig IMHO ein Fehler, so anstregend es manchmal ist(!)..

Makki