[DEV] nicht auf Eve umsteigen?

[pfeffer]

Liebe Mitentwickler,

Salzkammergut hat sehr viel Arbeit in den Umstieg von Ewe auf Eve investiert. Leider hängt es im Moment vor allem daran, dass es für Eve kein Programm gibt, das durch aufruf aus der Kommandozeile die entsprechenden .exe erzeugen könnte (was notwendig wäre, um automatisch Builds zu haben). Der Programmierer von Eve hat vor etwa 3 Monaten versprochen, so etwas ("heute") zu liefern (siehe http://www.ewesoft.com/cgi-local/eve-yabb/YaBB.pl?num=1220466108 ). Dass er es bis heute nicht getan hat, nährt nicht gerade meinen Optimimus, dass künftig Fehler in Eve zeitnah behoben werden.
Die Eve-VM ist zwar selbst Opensource, der EveMaker, der benötigt wird, um die .exe und .eve zu erstellen leider nicht, so dass wir es auch nicht selbst machen können.

Erste gefühlte Beobachtungen mit der Eve-Vm scheinen auch keine merkbaren Geschwindigkeitsvorteile zu offenbaren.

Der Umstieg auf Eve blockiert die Weiterentwicklung von Cachewolf jetzt bereits seit (gefühlt) fast einem Jahr und wir haben leider neue enthusiastische Entwickler erst mit dem Hinweis auf das Release und danach durch den Hinweis auf den Eve-Umstieg gebremst.

Welche Vorteile bietet Eve (auf die sich zu warten lohnen würde)?

Gruß,
Pfeffer.

 

[MiK]

Ich hatte auch schon die Idee, den Umstieg erst mal sein zu lassen. Dann werden wir aber auf Dauer mit manchen Problemen leben müssen. Z.B. können wir dann weiterhin auf einigen Plattformen keine externen Programme starten. Auch der HTML-Renderer von EVE soll ja wesentlich besser sein.
In der Anfangsphase, bis wir überhaupt wieder (auch auf dem PDA) auf dem Stand von EWE sind würde es genügen eine genaue Anleitung zu erstellen, wie man Exen baut. Damit sollten alle Entwickler zurecht kommen. Automatische Builds werden erst dann interessant, wenn wir wirklich wollen, dass sie auch von Usern getestet werden. Diesen Stand sehe ich jetzt noch nicht.
Und wenn es noch länger dauert, kann ich auch einmal in der Woche die Exen von Hand bauen. Das größere Problem ist, dass wir Entwickler uns die Zeit nehmen müssten wirklich an den bestehenden Problemen zu arbeiten.

Ich habe aber die EVE-Entwicklung selbst nicht verfolgt. Geht da in den letzten Monaten überhaupt etwas voran? Wie stabil und vollständig ist EVE selbst mittlerweile?

Das waren meine spontanen Gedanken dazu. Eine wirkliche Idee, wie es am besten weitergeht habe ich auch nicht.

 

[salzkammergut]

Mir fehlt vor allem die Möglichkeit am PDA die Cachebeschreibung im Browser darzustellen auch wenn es da einen Workaraound mit der "temp.html" gibt. Und dann sind da noch so einige (eher nur lästige) Bugs in EWE (wie das verkehrte Schreiben von Texten über das SIP und der Fehler beim Einfügen aus dem Clipboard). Und natürlich auch Probleme mit der Speicherverwaltung (garbage collector).

Bei der Portierung auf EVE habe ich auch versucht den Code etwas aufzuräumen, die Packages logischer zu gruppieren, die JAVA Namenskonventionen zu respektieren usw. Wäre schade wenn das alles umsonst wäre.

Ich habe jetzt noch einmal eine PN an Mike Brereton geschrieben - mal sehen ob er darauf antwortet.

Was die Weiterentwicklung betrifft - ich habe derzeit keine großen Wünsche. Mehr Speed am PDA wäre gut (da hoffe ich auf EVE habe aber noch keine Erfahrungswerte) aber ich bin nicht sicher ob dafür nicht ein fundamentales Redesign des EWE/EVE-UI notwendig wäre bzw. auch ein sehr tiefer Einstieg in die EWE/EVE-VM, die bei der Erzeugung von Objekten doch eher langsam ist. Die offensichtlichen Sachen haben wir im letzten Jahr ohnedies bereits realisiert.

Generell sehe ich die Gefahr dass jede Weiterentwicklung den Code noch weiter aufbläht was dem, für mich wichtigen, Ziel einer schlanken PDA Anwendung widerspricht. Wir können natürlich weitere Funktionen von GSAK implementieren, mit *einer* Codebase für PC und PDA wird das aber nicht zum Vorteil für die PDA Anwendung gereichen. Ich habe schon überlegt den Code so zu strukturieren, dass am PDA nur die Module geladen werden, die der User wirklich braucht. Wer also nie den Solver oder die MM nutzt, könnte diese Teile in einem Konfigurationsdialog abwählen und sie würden am PDA nicht geladen um Speicher und Ladezeit zu sparen. Das ist nicht so kompliziert, würde aber die Verwendung von Ant bedingen.

Ein anderes Thema wäre eine leistungsfähige aber schlanke Skriptsprache (eventuell basierend auf Fscript), die dann auch als Kommandozeilenversion die zahlreichen Funktionen von CW nutzbar machen könnte.

Grüße
salzkammergut

 

[MiK]

Generell stehe ich neuen Features auch kritisch gegenüber, aber es gibt schon noch einiges zu tun. In der MM steckt noch einiges an Optimierungspotential. Im Solver hätte ich gerne noch 1-2 Funktionen mehr. Die Darstellung von Addis könnte besser werden. Es gibt noch ein paar Dinge zu tun, damit CW sich auf hochauflösenden PDAs besser bedienen lässt. Auch die Tastenbedienung ist noch ausbaufähig. Und mit ein paar weiteren gesammelten Informationen und ein paar kleinen Änderungen am Export bekommen wir auch noch eine MyFinds.gpx hin, die dann von vielen Statistikprogrammen verwendet werden kann. Eine Statistikfunktion selbst möchte ich eher nicht einbauen. Außerdem gab es im Laufe der letzten Monate auch noch einige kleine Bugs, die man stopfen müsste.

Es gibt also noch viel zu tun, dass den Code nur wenig vergrößert, CW aber insgesamt noch runder macht. Ich hoffe ich finde bald mal die Zeit dazu, ein paar Sachen davon umzusetzen.

 

[pfeffer]

so, also an der Anleitung soll es nicht scheitern, siehe http://www.geoclub.de/viewtopic.php?f=40&t=23210&p=479310#p479310

Ich fänd's schon mal gut, wenn MiK wöchentlich Build per Hand bauen würde. Aber solange da nix gebaut wird, hab ich auch keine Lust, dadran zu programmieren...

Aber perspektivisch hätte ich schon gerne automatische Builds.

Gruß,
Pfeffer.

 

[MiK]

Ich fänd's schon mal gut, wenn MiK wöchentlich Build per Hand bauen würde. Aber solange da nix gebaut wird, hab ich auch keine Lust, dadran zu programmieren...

Welche Ziele sollen denn gebaut werden? Wo sollen sie dann hinterlegt werden? Im SVN? Auf dem NB-Server von "The Hawks"? Oder soll ich es in meinen Webspace legen?

Aber perspektivisch hätte ich schon gerne automatische Builds.

Das auf jeden Fall. Vielleicht erreicht ja SKG etwas...

 

[pfeffer]

mir ist es egal wohin, aber nicht ins SVN.
Welche Ziele - keine Ahnung.
Auf jeden Fall:
Windows PC, Windows Mobile 5, Windows Mobile 6, Eve für Linux.

Ich habe noch nicht probiert, ob es irgendwelche Vorteile bringt, wenn man auch .jar dabei angibt.
Brauchen wir noch ältere PocketPC2003 als Ziel?
Gibt es schöne neue Ziele (für Plam oder Nokia)?

Gruß,
Pfeffer.

 

[speerwerfer]

Brauchen wir noch ältere PocketPC2003 als Ziel?

Ja, sonst wäre ich mit meinem MDA Compact raus

 

[Engywuck]

Brauchen wir noch ältere PocketPC2003 als Ziel?

Wenn ich das hier lese, habe ich den Eindruck, dass die PocketPC2003-Variante die einzige ist, die VGA-Auflösung unterstützt.
Bislang habe ich es noch nicht ausprobieren können (zumindest nicht so richtig), weil ich es noch nicht geschafft habe, ein lauffähiges Cachewolf-Verzeichnis für den PDA zusammenzustellen. (Bislang gibts immer irgendeine Exception beim Bilderladen)

Gruß, E.

 

[arbor95]

mir auch 2003 bitte

 

[MiK]

Aber die prozessorspezifischen vor-2003 Varianten (gibt es die bei EVE überhaupt noch?) brauchen wir nicht mehr, oder?

 

[Engywuck]

Na wie schick.
Habe gerade gesehen, dass Eve 1.30 released ist. Damit funktioniert tatsächlich auch der EveMaker im Batchbetrieb
Ich habe daher mal den Eve-Stand im Repository aktualisiert und schon (im Verzeichnis programs) das ein oder andere Skript geschrieben. Den Praxistest habe ich noch nicht durchgeführt (siehe Posting weiter oben), aber im Prinzip könnte es jetzt losgehen...

Gute Nachrichten, finde ich

Grüße,
E.

 

[König Moderig]

Na wie schick, dann kann ich ja heute Abend den Nightly Build Service für Eve fertig bauen

Happy deving!

 

[König Moderig]

Grrrrr ...

Wieso denn imemr *.bat ?

-nik

P.S.: Ach, übrigens:

Exception in thread "main" java.awt.HeadlessException:
No X11 DISPLAY variable was set, but this program performed an operation which requires it.

Prost!

 

[pfeffer]

@The Hawk: also: geht immernoch nicht?

Gruß,
Pfeffer.

 

[Engywuck]

Wieso denn imemr *.bat ?

Gefällt Dir *.cmd besser? Was sind da eigentlich die Unterschiede?

P.S.: Ach, übrigens:

Exception in thread "main" java.awt.HeadlessException:
No X11 DISPLAY variable was set, but this program performed an operation which requires it.

Dann setz sie doch auf irgendwas

Gruß, E.

 

[MiK]

Wieso denn imemr *.bat ?

Gefällt Dir *.cmd besser? Was sind da eigentlich die Unterschiede?

Eigentlich keiner. Ich glaube er spielt wohl eher auf eine .sh an.

 

[huzzel]

Gefällt Dir *.cmd besser? Was sind da eigentlich die Unterschiede?

z.B.:
*.bat:

FOR /F "eol=; tokens=2,3* delims=, " %%i in (Datei.txt) do @echo %%i %%j %%k

*.cmd:

FOR /F "eol=; tokens=2,3* delims=, " %i in (Datei.txt) do @echo %i %j %k

 

[Christian und die Wutze]

Bastelt mir jemand eine VM für den Zaurus? *ganz lieb schau*

 

[Engywuck]

Wieso denn imemr *.bat ?

Gefällt Dir *.cmd besser? Was sind da eigentlich die Unterschiede?

Eigentlich keiner. Ich glaube er spielt wohl eher auf eine .sh an.

Da ich zuhause kein Unix hab, kann ich da auch keine .sh machen.
Wenn Du allerdings .cmd für besser hältst als.bat, kannst Du sie auch gerne umbenennen. Und wer der Meinung ist, bessere oder weitere Skripte schreiben zu wollen/können/müssen, darf das auch gerne tun. Wir arbeiten hier doch alle zusammen

Gruß,
E.