Delphi 10.4 Beta

[Bbommel]

Moin,

huch, ein ausführlicher Artikel bei Heise über die 10.4 Beta vom RAD Studio und niemand hier schreibt etwas dazu? :-)

Naja, bin mal gespannt. Die Zusammenführung der Installationswege (Iso+GetIt) wird uns mittelfristig hier in der DP bestimmt manchen Threads ersparen (und zuerst vielleicht ein paar bringen) ;-). Auch auf das Language Server Protocol bin ich gespannt - also eher indirekt darauf, wie das z.B. die Codevervollständigung vielleicht besser werden lässt.

Wie lange dauert es meistens so grob von der Beta bis zum Release?

[arnof]

Zitat:

Zitat von Bbommel (Beitrag 1462071)

Die Zusammenführung der Installationswege (Iso+GetIt) wird uns mittelfristig hier in der DP bestimmt manchen Threads

Ich bin ja ein bekennender Delphi Fanboy (weil ich nichts anderes "richtig" kann ;-) ), aber die Zusammenführung von Installationswegen, ist so wichtig wie der Sack Reis in China .....

Eine 64 BIT IDE, das währe mal was .....

Ich will das nicht ständig neu installieren, einmal installiert fertig (das wünscht sich wohl jeder), dann entsprechende Komponenten Nachinstallieren fertig .....

Keine neue interne Versionsnr des Compilers, wo wieder alles anders ist und jemand bei Firemonkey wieder mal eine tolle Idee hat und alles passt ggf. falls nicht mehr.

Ich verdiene mit Delphi mein Geld, deshalb muss es einfach laufen, ich zahle gerne Maintenence, wenn ich danach meine Ruhe habe und die benötigten Updates für die AppStoresysteme bekomme und ich meine Ruhe habe .....

PS: ich habe mal lange mit den Betatests mitgemacht; RAD Studio XE3 Beta, XE3.5 Beta usw. das kostet aber zuviel Zeit und die NDA tut Ihr übriges ....

[greenmile]

100% unterschrieben.

[jaenicke]

Zitat:

Zitat von arnof (Beitrag 1462082)

Eine 64 BIT IDE, das währe mal was .....

Die Speicherprobleme sind allerdings deutlich besser geworden. Und wenn ich überlege was das für einen Rattenschwanz nach sich sieht bin ich mir nicht so sicher, ob das zeitnah viel bringen würde. Aber prinzipiell sollte es einmal eine geben, ja.

Zitat:

Zitat von arnof (Beitrag 1462082)

Ich will das nicht ständig neu installieren, einmal installiert fertig (das wünscht sich wohl jeder), dann entsprechende Komponenten Nachinstallieren fertig .....

Wobei das in den letzten Versionen nicht mehr so problematisch ist wie früher.
Hauptsächlich muss ich in unserem Build- und Installationsskript die Version der IDE ändern, sprich in einer Datei eine Stelle.
Und dann muss ich nur die Delphi und die JEDIs installieren, unser Installationsskript laufen lassen und alles läuft wieder.

Mal schauen, ob ich auch in die Beta hineinschaue, wenn sie angeboten wird...

[Bbommel]

Naja, ich denke, dass die Zusammenführung der Installationswege dabei helfen kann, den Update-Prozess zu vereinfachen. Grundsätzlich sehe ich das auch so: das muss schneller und "geräuschloser" gehen als bisher - aber so lange man weiterhin zwei Installationswege betreuen muss, wird das sicherlich nichts werden. Insofern ist die Änderung jetzt sicherlich ein wichtiger Schritt, um eurem Wunsch entgegen zu kommen.

Und der andere Punkt mit "einfach meine Ruhe haben": vielleicht habe ich das auch einfach falsch verstanden. Natürlich möchte ich, dass mein Code im Großen und Ganzen nach einem Update weiterhin funktioniert. Aber meine Ruhe haben möchte ich eigentlich nicht - ich bin froh, dass sich unter der Haube einiges tut und finde es ziemlich großartig, was sich in den letzten Jahren im Bereich Linux, Web Services und so weiter getan hat. Das geht aber nicht immer alles ohne ein paar tiefere Eingriffe. Möglicherweise liegt die Erwartung aber auch daran, was man für Programme entwickelt.

[Der schöne Günther]

Zitat:

In einem späteren Update soll auch RAD Studio selbst für HighDPI Bildschirme angepasst werden

Wird wirklich Zeit. Windows macht seine Pixel-Skalierung wirklich gut, aber eine richtige Lösung ist wirklich überfällig.

Hoffentlich stößt diese ganze LSP-Geschichte auch ein Entkoppeln des Debuggers an. Dann könnte man langfristig evtl. auch mit anderen IDEs vollständig Delphi entwickeln (natürlich ohne VCL/FMX-Formulardesigner).

[jaenicke]

Zitat:

Zitat von Der schöne Günther (Beitrag 1462088)

Dann könnte man langfristig evtl. auch mit anderen IDEs vollständig Delphi entwickeln (natürlich ohne VCL/FMX-Formulardesigner).

Wenn es denn bessere IDEs geben würde, wäre das von Vorteil...
Aber wenn ich mir so die IDEs von RemObjects oder z.B. Visual Studio oder Lazarus anschaue... Ja, es gibt weniger Bugs und sie laufen (abgesehen von Lazarus) flüssiger, aber von der Funktionalität her sind sie halt auch leider bei Weitem nicht vergleichbar.

[himitsu]

Zitat:

Zitat von arnof (Beitrag 1462082)

Ich bin ja ein bekennender Delphi Fanboy (weil ich nichts anderes "richtig" kann ;-) ), aber die Zusammenführung von Installationswegen, ist so wichtig wie der Sack Reis in China .....

Nja, da im Moment die beiden Installer inkompatibel sind, was Reparaturen und Updates betrifft, ist das schon wichtig, dass es englich wieder Eins wird.

Und die 64 Bit IDE ... nja, da zu diesem Zeitpunkt praktisch auch sämtliche Erweiterungen und interierte Zusatzkomponenten erstmal nicht mehr funktionieren werden, wird dir das nicht so viel Spaß bereiten, wie du vielleicht denkst.
Bei den Komponenten kann man die ja dann erstmal zur Laufzeit erzeugen. Die selbst sollten ja inzwischen hoffentlich größtenteils mit 64 Bit arbeiten können ... fehlen dann nur noch die DesignTime-Funktionen.

[Sherlock]

Wenn die IDE einfach mal aus einem Guss und nicht drei verschiedenen Flickenteppichen bestünde, wäre das schon ein enormer Gewinn.

Sherlock

[Rollo62]

Zitat:

Zitat von arnof (Beitrag 1462082)

PS: ich habe mal lange mit den Betatests mitgemacht; RAD Studio XE3 Beta, XE3.5 Beta usw. das kostet aber zuviel Zeit und die NDA tut Ihr übriges ....

Wohl wahr.
Warum zahle ich eine teure Subscription, die mir angeblich immer aktuelle Updates und Hotfixes liefert, bei der ich dann das Kompilat einer mit Beta erstellten App nicht nutzen darf ?

Für Windows ist das womöglich nicht ganz so relevant, aber mit Mobile hänge ich meistens an den letzten Änderungen der OS, und bin gefühlt immer zu spät dran.

Eine NDA die Kompilate verbietet ( OK: nicht immer, siehe letzte Beta ),
das mutet für mich wie ein Relikt aus dem letzten Jahrtausend an.
Man muss alle Register zihen um eine App AppStore-fähig zu halten, und dann sowas.

Wir reden von CI und Nightly Builds, aber die NDA spricht leider dagegen (ohne Grund) :pale:
(ganz so als hätte ich meine Subscription nicht ordentlich bezahlt).

[arnof]

Zitat:

Zitat von himitsu (Beitrag 1462093)

Zitat:

Zitat von arnof (Beitrag 1462082)

Ich bin ja ein bekennender Delphi Fanboy (weil ich nichts anderes "richtig" kann ;-) ), aber die Zusammenführung von Installationswegen, ist so wichtig wie der Sack Reis in China .....

Nja, da im Moment die beiden Installer inkompatibel sind, was Reparaturen und Updates betrifft, ist sas schon wichtig, dass es englich wieder Eins wird.

Und die 64 Bit IDE ... nja, da zu diesem Zeitpunkt praktisch auch sämtliche Erweiterungen und interierte Zusatzkomponenten erstmal nicht mehr funktionieren werden, wird dir das nicht so viel Spaß bereiten, wie du vielleicht denkst.
Bei den Komponenten kann man die ja dann erstmal zur Laufzeit erzeugen. Die selbst sollten ja inzwischen hoffentlich größtenteils mit 64 Bit arbeiten können ... fehlen dann nur noch die DesignTime-Funktionen.

Komponenten gehen i.d.R. sowie so nicht mit der neuen Version und müssen angepasst werden , also ist das keine Neuigkeit, seidenn Du hast die Quelltexte, dann macht 64 BIT keinen Unterschied ...


Zur 64 BIT IDE:

Ich meine mich an eine Roadshow 2009 erinnern zu können da hatten Codegeare/Embacadero schon mal den Codename "Commodore" für die 64 BIT IDE ...., da das der nächste logische Schritt währe, da die IDE auch in Delphi entwickelt wäre ...

Hallo Herr Eissing ;-)

[MEissing]

Zitat:

Zitat von arnof (Beitrag 1462099)

Hallo Herr Eissing ;-)

Hallo! :wiejetzt:

(Ankündigungen sind keine zugesicherten Produkteigenschaften und können sich jederzeit ändern)

[DeddyH]

Mir würde es schon genügen, wenn man weniger Wert auf Featuritis als auf Stabilität (zumindest der IDE) legen würde. Dann müsste ich mich auch nicht mehr aufregen, dass mir die Code-Vervollständigung in einer Unit, in der von anonymen Methoden heftig Gebrauch gemacht wird, hinter jedem manuellen Zeilenumbruch ein "end;" einfügt, obwohl dort keins hingehört. Error-Inside (:mrgreen:) nervt seit über 10 Jahren mit Falschmeldungen, in komplexeren Units funktioniert die Navigation zwischen Deklaration und Implementation nicht und und und... Von FMX fange ich erst gar nicht an, das habe ich schon lange ad acta gelegt, da sind andere weit voraus und auch noch kostenlos.

[DieDolly]

Das hier ist interessnter, weil doch etwas mehr Detail drin steckt. Aber nur etwas.
https://community.idera.com/develope...udio-10-4-beta

Aber das Bild mit dem Schriftzug Denali sieht aus, als hätte es ein 12-jähriges Kind gemalt

Ist echt nur das in 10.4 drin? Und dafür muss man so lange warten?
Wurde denn CodeInsight behoben, sodass keine inline-deklarierten variablen mehr als Fehler angezeigt werden?

[Sherlock]

Den Umstieg von OpenGL auf Metal2 als "nur" zu bezeichnen halte ich für heftig. LSP ist auch nicht ohne.
Es ist in diesem Release halt wieder mehr für Nicht-Windosen dabei. Man kann es nicht allen Recht machen.

Sherlock

[DieDolly]

Mir sind eher die IDE Bugfixes wichtig oder generell eine vernünftige IDE, nicht Windows speziell.
Aber ich bin leider nur ich. Die Mehrheit ist jemand anders.

[Sherlock]

Ich wünsche mir schon seit Jahren ein reines Bugfix Release, dazu fehlt jedoch der Mut. Also wurschtelt man ein mehr oder minder Überflüssiges "heißes" Sprachfeature nach dem anderen hinzu, und vergrault sich die langjährigen Nutzer, nur um den einen oder anderen verirrten Javaisten oder Pythoniker einzufangen.

Für App-Entwickler, muss aber ziemlich oft und auch regelmäßig viel getan werden, damit die nicht wieder abspringen. FMX für iOS/macOS ist wirklich gut geworden, wenn es nur nicht so unperformant wäre. Metal2 könnte der richtige Schritt sein, Dampf zu machen. Bin leider seit gut 6 Monaten weg von FMX für iOS, jetzt nur noch Win/macOS. Vielleicht geht es ja mit 10.4 wieder besser.

Sherlock

[mschaefer]

Eigentlich sollte es möglich sein, dass auch Fremd-Komponenten nur zu Main-Reeases neu kompiliert werden müssen. Das zu jeder Version Änderungen im dcu-Format nötig/gewollt sind, sollte mal überdacht werden.

[Uwe Raabe]

Zitat:

Zitat von mschaefer (Beitrag 1462157)

Eigentlich sollte es möglich sein, dass auch Fremd-Komponenten nur zu Main-Reeases neu kompiliert werden müssen. Das zu jeder Version Änderungen im dcu-Format nötig/gewollt sind, sollte mal überdacht werden.

Hier geht es ja ausschließlich um Main-Releases. Innerhalb einer Delphi Version (z.B. 10.2.x, 10.3.x) bleibt das DCU-Format ja konstant.

[mschaefer]

ok, dann update ich mich da mal, Danke :-)

[himitsu]

Die asynchrone Codevervollständigung.
Ich hoffe nur, dass es nicht so wird, wie ich es im Android Studio kennenlernte.

Man will was machen und klickt z.B. in einem Menü auf einen Punkt, aber weil nicht passiert, klickt man noch 20 Mal und gibt dann auf.
10 Minuten später poppen dann plötzlich viele Fenster auf.

Zitat:

Einheitliches Speichermodell für alle Plattformen
Die mobilen Plattformen Android und iOS nutzen (bis einschliesslich Version 10.3) noch das ARC (Automatic Reference Counting) für die Speicherverwaltung.
Ziel ist es, mit 10.4, dieses Speichermodell zu vereinheitlichen
Das hat Vorteile bei der Migration bestehender Windows-Anwendungen auf die mobilen Plattformen und auch leichte Performance Vorteile!

Auf den Teil wäre ich mal gespannt, denn aktuell macht es wirklich keinen Spaß platformübergreifende Komponenten zu erstellen, außer man will alles x-fach doppelt deklarieren und für alles ein Interface erstellen, mit unnötigen Gettern und Settern, weil das Interface sonst nicht will.

Abwärtskompatiblen Code hab ich fast schon aufgegeben, da stören dann Änderungen im Windows-Compiler nun auch nicht mehr.

Und wenn das [Weak] im Windows nicht mehr still und heimlich ignoriert wird, das wäre zu schön, um wahr zu sein.

[DieDolly]

Wenn 10.4 schlechter ist als 10.3, einfach kurz vorher noch schnell eine 10.3 Lizenz holen und unter neuer Email aktivieren. Dann hat man ein Jahr Ruhe.

[TurboMagic]

Warum sollte 10.4 schlechter als 10.3 werden?
Evtl. kann man ja die asynchrone Code Vervollständigung auch auschalten und das alte Verfahren benutzen? Wer weiß...

Aber auch das: einfach am Beta Test teilnehmen. Je mehr Leute das vor der Veröffentlichung testen um so
höher die Chance, dass die wesentlichen Bugs vorher gefunden und beseitigt werden können!
Also nicht spekulieren, sondern testen! ;-)

[Rollo62]

Zitat:

Zitat von TurboMagic (Beitrag 1462180)

Warum sollte 10.4 schlechter als 10.3 werden?

Weil da wieder an 100 Baustellen gleichzeitig rumgebaut wurde (ARC, LSP, managed records, ...).

[mkinzler]

Zitat:

Weil da wieder an 100 Baustellen gleichzeitig rumgebaut wurde (ARC, LSP, managed records, ...).

Eigentlich ist nichts davon wirklich neu. Die Win64 und Linux64-Compiler sind ja schon non-arc, LSP gibt es schon für C++ und die managed records waren schon zu 10.3 fertig und wurden nur kurz vor dem Release entfernt.
Eigentlich gibt es nichts wirklich Neues!

[jaenicke]

Zitat:

Zitat von TurboMagic (Beitrag 1462180)

Warum sollte 10.4 schlechter als 10.3 werden?
Evtl. kann man ja die asynchrone Code Vervollständigung auch auschalten und das alte Verfahren benutzen? Wer weiß...

Das kann man, ja, zumindest ist das so angekündigt.

[DeddyH]

Naja:

Zitat:

Zitat von MEissing (Beitrag 1462110)

(Ankündigungen sind keine zugesicherten Produkteigenschaften und können sich jederzeit ändern)

[Rollo62]

Zitat:

Zitat von mkinzler (Beitrag 1462183)

Eigentlich gibt es nichts wirklich Neues!

Das hoffe ich sehr, dann wären da viele sinnvolle Bugfixes drin ohne neue Bugs aufzumachen :stupid:

[p80286]

Zitat:

Zitat von TurboMagic (Beitrag 1462180)

Aber auch das: einfach am Beta Test teilnehmen. Je mehr Leute das vor der Veröffentlichung testen um so
höher die Chance, dass die wesentlichen Bugs vorher gefunden und beseitigt werden können!
Also nicht spekulieren, sondern testen! ;-)

Wenn man das konsequent zu Ende denkt: ich bin schuld, daß das Werkzeug das ich nutze nicht fehlerfrei ist, weil ich nicht getestet habe. Auf eine solche Idee kann auch nur jemand verfallen,der in einer Branche ist, in der Chief-Evangelist(en) beschäftigt werden. Hier geht es schließlich nicht um ein Projekt eines engagierten Kreises sondern schlicht um eine Software für die einige Leute viel Geld auf den Tisch legen.

Gruß
K-H

@DeddyH
Nicht alle Hühner die gackern haben Eier gelegt. Der gute Wille zählt!

[Uwe Raabe]

Zitat:

Zitat von p80286 (Beitrag 1462191)

Wenn man das konsequent zu Ende denkt: ich bin schuld, daß das Werkzeug das ich nutze nicht fehlerfrei ist, weil ich nicht getestet habe.

Man kann wirklich alles schlecht reden. Immerhin bekommen viele Leute zumindest die Möglichkeit zu testen. Das war auch schon anders und hat ebenfalls für Unmut gesorgt.

Es zwingt dich ja auch keiner zu testen. Lass es halt die anderen tun. Nur solltest du dich dann hinterher nicht beschweren, wenn die dich nervenden Fehler nicht gefunden wurden. Nicht alle Delphi-Nutzer arbeiten gleich und bei ausreichend komplexen Programmsystemen ist ein systematischer Test aller Anwendungsfälle praktisch nicht durchführbar.

Nebenbei: Fehlerfreie Software - gibt es sowas überhaupt?

[p80286]

Zitat:

Zitat von Uwe Raabe (Beitrag 1462194)

Nicht alle Delphi-Nutzer arbeiten gleich und bei ausreichend komplexen Programmsystemen ist ein systematischer Test aller Anwendungsfälle praktisch nicht durchführbar.

Nebenbei: Fehlerfreie Software - gibt es sowas überhaupt?

Nö fehlerfrei geht nicht. soviel Phantasie hat kein Entwickler.
Was mich nervt, ist diese unterstellte Selbstverständlichkeit, daß ich testen soll. Ich weiß wie nervend Testarbeit ist. Nichts macht mehr Spaß als Fehlerbedingungen einzugrenzen.
Aber ein wenig mehr Demut und Selbstkritik auf der Lieferantenseite könnte nicht schaden. Wenn man tagelang einen Fehler einkreist, dessen Ursache findet, dem Chefentwickler die (getestete) Lösung präsentiert und dann stundenlang auf ihn einwirken muß, daß er die Möglichkeit dieses Fehlers in Betracht zieht...

Gruß
K-H

[DieDolly]

Zitat:

Eigentlich gibt es nichts wirklich Neues!

Macht das den Fakt, dass es rund 1 Jahr dauert von 10.3 zu 10.4, nicht nur noch schlimmer? :lol:

[Daniel]

Ihr führt diese Diskussion ad absurdum.
Selbstverständlich gibt es Neuerungen, einige von ihnen listet Sarina in ihrem Blog-Eintrag auf. Jetzt zu behaupten, es gebe nichts Neues ist in der Sache schlicht falsch.

[DieDolly]

Die Liste der gefixten Bugs ist sicherlich wieder ellenlang. Das ist ja mehr als nix.

[Uwe Raabe]

Zitat:

Zitat von Daniel (Beitrag 1462231)

Ihr führt diese Diskussion ad absurdum.

Die, die es wissen, dürfen nichts sagen und die, die es nicht wissen, sollten nichts sagen.

[jaenicke]

Zitat:

Zitat von Uwe Raabe (Beitrag 1462233)

Die, die es wissen, dürfen nichts sagen und die, die es nicht wissen, sollten nichts sagen.

Die Regeln kommen an der Stelle halt immer noch von denen, die glauben, dass bei Bekanntwerden von Features 4 Wochen vor dem Release die Konkurrenz diese in Lichtgeschwindigkeit nachbauen könnte und würde... Dass das nicht einmal nach dem Release passiert und wenn, dann nicht so schnell, wird dabei gerne vergessen.

Die Qualität ist jedenfalls in den letzten Releases schon deutlich besser geworden. Aber ein Problem zieht sich halt leider wie ein roter Faden durch einen großen Teil der mitgelieferten Klassen:
Die Entwickler meinen sie sind unfehlbar und ihre Klassen können alles Notwendige. Und deshalb wird sehr viel hart einprogrammiert ohne einen Gedanken daran zu verschwenden, dass jemand vielleicht die Klassen doch anders verwenden möchte. Entsprechende Tickets werden ja auch entsprechend abgeblockt.

Und das ist wirklich ein großer Nervfaktor:
Dass man oft nicht umhin kommt eine schon vorhandene Funktionalität neu selbst zu bauen, aus der RTL usw. zu kopieren und zu ändern oder Fremdkomponenten zu kaufen, weil eine Kleinigkeit nicht so ist wie benötigt.
Leider wird sich das aber weder mit 10.4 noch in absehbarer Zukunft ändern...

Die Antwort ist leider tatsächlich: Dann kopiere doch die Unit und ändere sie wie es benötigt wird, wir werden es nicht tun... :evil:

[Rollo62]

Ich denke eher es geht um die Angst 4 Wochen vor Release könnte die Konkurrenz die tollen Features schlechtreden.
Dabei interessiert das die Konkurrenz gar nicht mehr, dafür haben wir ja das Forum.

[TurboMagic]

Zitat:

Zitat von DeddyH (Beitrag 1462188)

Naja:

Zitat:

Zitat von MEissing (Beitrag 1462110)

(Ankündigungen sind keine zugesicherten Produkteigenschaften und können sich jederzeit ändern)

Das steht unter jeder Roadmap Präsentation von EMBT so oder so ähnlich drunter.
Liegt also nicht an ihm und ist vermutlich nötig, weil es immer mal kurzfristig Änderungen
geben kann und jemand dann ankommt: aber ich hab' meinen Wartungsvertrag genau deswegen
verlängert und jetzt ist es nicht drin...

Ich glaube da gibt es wichtigeres...

[TurboMagic]

Zitat:

Zitat von DieDolly (Beitrag 1462229)

Zitat:

Eigentlich gibt es nichts wirklich Neues!

Macht das den Fakt, dass es rund 1 Jahr dauert von 10.3 zu 10.4, nicht nur noch schlimmer? :lol:

Ich vermute es wird auch noch weitere Neuigkeiten im Produkt geben. Wenn du's frühzeitig wissen willst, kannst du dich ja gerne für den Betatest anmelden. Dann hast du sicher viele Infos früher...

[Sherlock]

Zitat:

Zitat von Rollo62 (Beitrag 1462271)

Ich denke eher es geht um die Angst 4 Wochen vor Release könnte die Konkurrenz die tollen Features schlechtreden.
Dabei interessiert das die Konkurrenz gar nicht mehr, dafür haben wir ja das Forum.

Das ist definitiv nicht der Grund. Vielmehr könnten noch während der Beta schwerwiegende Probleme mit Feature X festgestellt werden, die eben dazu führen, daß es doch noch zurückgezogen werden muss.

Sherlock