Warum Delphi 64-Bit-IDE

[freimatz]

... die gibt es nicht.

Nur interessehalber: Warum sollte man die haben wollen?

Dass früher mal Fehlermeldungen wegen zu wenig Speicher kamen, lag ja wohl an Memory-Leaks und nicht dass die IDE nur 3GB RAM bekommt.

Oder liegt es dass man zum Debuggen von 64-Bit, den Remote Debugger nehmen muss?
Oder hofft man dass dann die Problem beim debuggen von 64-Bit weg sind?

[hoika]

Hall,
1. RAM-Verbrauch bei großen Projekte
2. RemoteDebugger
3. andere IDEs können das auch (...)

[arnof]

ich sehe mehrmals täglich: "zu wenig Arbeitsspeicher" oder "out of memory"

Dies tritt auf, wenn die bds.exe über 1.2 GByte RAM zugewiesen bekommt. Mein Entwicklungssystem hat 64 GB und genug freien Speicher im Block ...

Meine Lösungen bisher:

- möglichst wenige Fenster in der IDE zur Bearbeitung auf haben
- Release erzeugen und Debugmodus in nur den Sachen die mich gerade interessieren

Regelmäßig neu starten ......

Aber ich benutze aktuell zum Arbeiten XE2 mit vielen Komponenten Devexpress, TMS usw.

Mit RIO und den Vorgängern mach ich nur "Spass" Prgs wie Apps, WEB und REST

[Stevie]

Zitat:

Zitat von hoika (Beitrag 1463891)

andere IDEs können das auch (...)

Fun fact: Visual Studio ist auch in der 2019er Version nicht 64bit, besteht aber aus einer Vielzahl von Prozessen, die miteinander kommunizieren.

Auch interessant: https://stackoverflow.com/a/46510321/587106

[Bernhard Geyer]

Zitat:

Zitat von arnof (Beitrag 1463893)

Aber ich benutze aktuell zum Arbeiten XE2 mit vielen Komponenten Devexpress, TMS usw.

Mit aktuellen 10.xer Versionen würdest du dir vermutlich fast alle Restarts sparen.
Da hat sich schon gewaltig viel getan.

[jaenicke]

Zitat:

Zitat von arnof (Beitrag 1463893)

Aber ich benutze aktuell zum Arbeiten XE2 mit vielen Komponenten Devexpress, TMS usw.

Ja, da war das noch ein größeres Problem. Bis XE6 oder XE7 ging das glaube ich so.
Mit XE8 und 10 wurde das aber größtenteils behoben. Und die IDE kann nun auch 3 statt 2 GB RAM ansprechen.

Jetzt kann man auch weitestgehend problemlos in größeren Projektgruppen gleichzeitig Haltepunkte in DLL und Hostprogramm nutzen und zwischen den Projekten umschalten usw. ohne dass es gleich Abstürze gibt.

In den aktuellen Versionen gibt es daher vom Speicherverbrauch her nicht mehr die große Notwendigkeit einer 64-Bit IDE. Und man sollte bedenken, dass man dann die ganzen Komponentenpackages auch in 64-Bit Versionen bereitstellen und haben muss.

[arnof]

Nach dem TSE Kram, hatte ich vor auf RIO zu wechseln; jetzt kommt aber 10.4, dann warte ich halt wieder bis alle Komponentenhersteller liefern können, dann ist wieder Herbst und man hat keine Zeit zu wechseln. Dann kommt 10.5, so geht das Jahr für Jahr bzw halbjährlich ....

Der Wechsel von Delphi 5 auf XE2 hat sicherlich, bis man das was rauskommt an Kunden liefern kann 2-3 Monate gedauert, die Zeit hat man halt nicht immer ...

[DieDolly]

Zitat:

dann ist wieder Herbst und man hat keine Zeit zu wechseln. Dann kommt 10.5

Lass es Sommer 2021 sein, bis 10.5 kommt. Vorher bestimmt nicht. Du hast also genug Zeit.

Ich muss die IDE zwar mehrmals täglich wegen irgendwelcher unbehandelten Fehler, von denen es viele gibt, neustarten. Aber an Speicherlimits bin ich bisher nie gekommen.

[Bernhard Geyer]

Zitat:

Zitat von arnof (Beitrag 1463899)

Nach dem TSE Kram, hatte ich vor auf RIO zu wechseln; jetzt kommt aber 10.4, dann warte ich halt wieder bis alle Komponentenhersteller liefern können, dann ist wieder Herbst und man hat keine Zeit zu wechseln. Dann kommt 10.5, so geht das Jahr für Jahr bzw halbjährlich ....

Also ich habe meine Komponentensammlung selbständig innerhalb weniger Stunden "auf Vordermann" gebracht.
Ist bei vielen nur 1-2 inc-Datei die man nach "Schema F" ergänzen muss.
Die Quellcodeanpassungen (wegen Verschobener Klassen) sind auch in den letzen XEx und 10.xer Versionen auch sehr übersichtlich geworden.

Zitat:

Zitat von arnof (Beitrag 1463899)

Der Wechsel von Delphi 5 auf XE2 hat sicherlich, bis man das was rauskommt an Kunden liefern kann 2-3 Monate gedauert,

Yo. Der Wechsel von Nicht-Unicode auf Unicode-Version hat bei uns auch gedauert (D6->XE6)
Der folgende Wechsel von XE6 auf 10.2 war erheblich schneller "durch".
Und die Produktivität ist auch mit XE6 -> 10.2 wieder merklich gestiegen (wenn man mal "Spaß" an den neuen Sprachfeatures findet ...)
Stabilität auch (bei uns) merklich besser.

Zitat:

Zitat von arnof (Beitrag 1463899)

die Zeit hat man halt nicht immer ...

Man hat auch noch viel weniger Zeit die Einschränkungen von alten Compilern "zu umschiffen".

[himitsu]

1,2 GB sagt nichts aus.
* Es kommt drauf an wieviel Speicher reserviert werden sollte (auch bei nur 10 MB RAM wird gemeckert, wenn jemand 2 GB reservieren will)
* und wie fragmentiert der Speicher schon ist
** meiner Erfahrung nach, gibt es schon ab GetMem(700 MB) Probleme, dass es oft in einem ganz kleinen Programm keinen freien "zusammenhängenden" Bereich mit dieser Größe mehr gibt

Die Delphi-IDE wurde vor "kurzem" zumindestens schonmal mit der 4GB-Option ausgestattet.
* in 32 Bit-Windows bis 3 GB (weil das OS für Kernel und Treiber bissl was braucht) und in 64 Bit-Windows bis 4 GB (nja, 3.9xx) virtueller Speicher

Problem ist auch, dass der Inline-Compiler gern ein Speicherleck hat.
Nja, nicht direkt Leck ... beim gleichzeitigen beim Kompilieren mehrerer Projekte, wird der Cache erst am Ende geleert, was ihn vorher gern mal volllaufen lässt.
Da man nun aber etwas mehr Speicher hat, knallt es nicht mehr so schnell (wenn wir es bald hoffentlich geschafft haben von XE auf 10.x upzugraden, denn jetzt hab ich den Bug noch)



Problem ist halt, dass dann auch alle DesignTime-Komponenten (die sollten das meistens schon können) und vor allem auch die DesignTime-Editoren dieser Komponenten und sämtliche andere IDE-Experten/Plugins ebenfalls in 64 Bit vorliegen müssen,
denn sonst hast zwar eine schöne IDE, aber die dann ein bissl leer.


Von mir aus kann man die 32 Bit-IDE dann auch einstampfen, um nicht doppelt weiterentwickeln zu müssen, dann effektiv gibt es keine kaum noch Entwicklungsrechner mit einem 32 Bit-Windows, wo ein nagelneues Delphi drauf muß.

[Sinspin]

Zitat:

Zitat von arnof (Beitrag 1463893)

Aber ich benutze aktuell zum Arbeiten XE2 mit vielen Komponenten Devexpress, TMS usw.

Ich war zum Schluss soweit dass ich alles an Komponenten raus gehauen habe was nur ging.

Das war für uns der Grund auf Rio umzusteigen. Aber wenn Du ein Projekt in der größe hast dass es mit XE2 Speicherprobleme gibt würde ich versuchen noch zu warten. Rio wirft zwar bisher keine Speicherfehler, aber dafür ist die IDE voller Bugs (MouseOver Hinweise: sporadisch; Autovervollständigung: sporadisch; Menüzeilen nach einer Größenänderung zerhagelt: jedesmal, ...), und der Compiler findet alle paar mal beim übersetzen Fehler die es nicht gibt. Und ErrorInsight ...nunja... wozu ist das eigentlich nochmal da? Zum abschalten!

Warum solche Fehler nicht in Revisionen der aktuellen Version behoben werden kann ich nicht verstehen. Aber es war bisher immer so das einige IDE Schrott waren und es geblieben sind. Dafür aber alle X Jahre mal eine stabile dabei war die man dann nutzen konnte.

Zur 64 Bit IDE. Das klingt schon verlockend. Ich habe eines meiner Projekte mit bestehenden Sourcen in 64Bit umgesetzt und muss sagen, das es schon eine ganze Weile gedauert hat bis es nicht mehr geknallt hat.
Eine 64 Bit IDE würde dann voraussetzen dass alle Komponenten die Du verwendest auch 64 Bit können.
Ich habe noch immer gekaufte Komponenten dabei die kein 64 Bit können. So lange das noch so ist würde auch eine 64 Bit IDE keinen Sinn machen.

Interessanter ist da eher den Compiler als 64 Bit auszulegen und in einem eigenen Prozess laufen zu lassen.

€dit: CodeInsight war falsch, ErrorInsight war gemeint. Und letzteres ist das Böse. Das andere funktioniert nur zu oft nicht.

[DasWolf]

Zitat:

Zitat von DieDolly (Beitrag 1463901)

Ich muss die IDE zwar mehrmals täglich wegen irgendwelcher unbehandelten Fehler, von denen es viele gibt, neustarten. Aber an Speicherlimits bin ich bisher nie gekommen.

Na dann provoziere mal zirkuläre Unit-Referenzen. Das legt nicht nur die IDE lahm, sondern auch gleich den ganzen Rechner.

[DieDolly]

Zitat:

Na dann provoziere mal zirkuläre Unit-Referenzen.

Bei mir weder noch. Es kommt eine nichtssagende Fehlermeldung im unteren Ausgabebereich und der Kompiliervorgang wird normal abgebrochen.

[Uwe Raabe]

Zitat:

Zitat von DasWolf (Beitrag 1463911)

Na dann provoziere mal zirkuläre Unit-Referenzen.

Umgekehrt: Die Empfehlung ist zirkuläre Unit-Referenzen zu eliminieren! Ohne lebt es sich gleich viel besser.

[himitsu]

Darum auch möglichst alle Uses nur im Interface und bei den Uses in der Implementation gut überlegen, ob es so richtig und nötig ist.

Zitat:

Und CodeInsight ...nunja... wozu ist das eigentlich nochmal da?

Sicher dass du dass Code-Insight meinst und nicht vielleicht doch das Error-Insight?

Error-Insight = Fehlerhervorhebung (das nie funktionierende Untersteichen usw.)
Code-Insight = Codevervollständigung und Hints mit den Infos (Unit der Delkarations und die Parameter)
Help-Insight = die Hints mit dem Hilfetext
andere-Insights = ...

[Sinspin]

Zitat:

Zitat von himitsu (Beitrag 1463915)

Zitat:

Und CodeInsight ...nunja... wozu ist das eigentlich nochmal da?

Sicher dass du dass Code-Insight meinst und nicht vielleicht doch das Error-Insight?

Danke. :oops: Verbessert.

[freimatz]

Was habe ich da schcon wieder angeleiert? :oops:

Habe zwar alles gelesen, aber eine eine Antwort habe ich noch nicht. hoika hat zwar geantwortet (Danke), aber die Argumente sind hinfällig - oder? Es ging viel um Speicher und ein Update auf neueste Delphi-Version sollte da doch reichen.
Zumindest bei uns sind Speicherprobleme weg - und wir haben im Hauptprojekt 333 dproj (incl. 142 von Fremdkomponenten)

[Moombas]

Dann bringe ich mal ein anderes Argument, das wohl aber erst in der (?fernen?) Zukunft greifen wird:

Keine Unterstützung von 32-Bit Programmen mehr, so wie es bereits für 16-Bit passiert ist.

Und je eher man umstellt, umso eher kann man ggf. Baustellen schon umgehen und ist vorbereitet.

[win568]

Hi

Also wir würden dringendst eine 64 Bit IDE benötigen. Der Umfang unseres Projektes sprengt derzeit fast die IDE.
Laden des Projektes und einmal Compilieren und 4GB erreicht. Neustart, nochmal compilieren und es geht mal gerade so (3,7 GB virtueller Speicherverbrauch). Und ja, bevor jemand da zum Belehren anfängt, wir haben unser Projekt bereits in Packages
aufgeteilt (95 Stück an der Zahl). Leider ist hier die Unterstützung der IDE Funktionen (CodeInsight, ErrorInsight, CodeCompletion usw.) mehr als Mangelhaft, weshalb ich lieber noch mit dem Monolithen arbeite. Dort funktionieren die genannten Funktionen
interessanterweise.

[himitsu]

Zitat:

Zitat von win568 (Beitrag 1463922)

wir haben unser Projekt bereits in Packages aufgeteilt (95 Stück an der Zahl)

Jo, unmengen an Packages und DLLs, die nicht alle bei Programmstart geladen werden, sondern erst wenn benötigt,
aber die komplette Projektgruppe auf einmal kompilieren, naja ...

Zitat:

Zitat von himitsu (Beitrag 1463905)

Problem ist auch, dass der Inline-Compiler gern ein Speicherleck hat.
Nja, nicht direkt Leck ... beim gleichzeitigen beim Kompilieren mehrerer Projekte, wird der Cache erst am Ende geleert, was ihn vorher gern mal volllaufen lässt.

[jbg]

Zitat:

Zitat von himitsu (Beitrag 1463931)

aber die komplette Projektgruppe auf einmal kompilieren, naja ...

Bei vielen Packages sind dann viele Units mehrfach im Speicher des Compilers und im Speicher von ErrorInsight. Der Compiler hält für jedes Projekt der Projekgruppe eine eigene Kopie der genutzten Units, unabhängig ob sie explizit ("uses MyUnit in 'MyUnit.pas'") oder implizit (uses YourUnit) eingebunden sind.


Package A:
- Unit A1
- Unit A2

Package B:
- requires A
- Unit B1: uses A1, A2
- Unit B2

EXE-Projekt:
- Runtime Packages: A, B
- Unit C1 uses B1, B2
- Unit C2


Das führt beim Kompilieren und beim CodeInsight zu folgenden Units im Speicher:
- Package A: (SysInit, System, A1, A2)
- Package B: (SysInit, System, A1, A2, B1, B2)
- EXE-Projekt: (SysInit, System, A1, A2, B1, B2, C1, C2)

Und das ganze zwei Mal, da ErrorInsight auch noch alle expliziten Units im Speicher hält.


Wenn man das auf mehrere Packages hochrechnet, dann sieht man recht schnell das Ende des virtuellen Adressraums.


Es wird interessant was bei Delphi 10.4 mit seinem LSP Server herauskommt. Ob pro Projekt ein eigener Prozess läuft oder die Prozesse nur für unterschiedlichen Aufgaben (ErrorInsight, CodeInsight) zuständig sind und man nur ein wenig mehr "Luft" wegen der Aufsplittung hat. Der LSP Server ist ja laut TaskManager-Screenshot immernoch 32Bit.

[win568]

Hi Andi

Wäre natürlich wieder zu viel zu erwarten gewesen, dass Emba hier einen 64 Bit LSP Server spendiert hätte. Das hätte auf jeden Fall das Problem entschärft.

Habe mir die Beta schon installiert, aber derzeit funktioniert bei unseren Projekten keine der genannten Funktionen. Werde mal auf die nächste Version warten

[Daniel]

Zitat:

Zitat von win568 (Beitrag 1463943)

Wäre natürlich wieder zu viel zu erwarten gewesen, dass Emba hier einen 64 Bit LSP Server spendiert hätte. Das hätte auf jeden Fall das Problem entschärft

Nachdem 64 Bit ihn nicht schneller gemacht hätten, kann es nur um die Menge an verfügbarem Speicher gehen. Inwiefern sollte ihn die 32 Bit Architektur in dieser Hinsicht ausbremsen? Auch bei umfangreichen Projekten liegt dessen Speicherverbrauch weit unterhalb jeglicher Limits. Welches Problem also würde jetzt durch die 64 Bit Architektur konkret entschärft?

[win568]

Hi Daniel

In unserem Fall das Speicherproblem. Ein 32Bit Prozess kann maximal 4GB Speicher belegen. Wie Andi ja bereits beschrieben hat, wird das Problem mit den Packages potenziert. Daher wäre hier eine vorausschauende Entscheidung gewesen, den LSP Server Dienst unter 64Bit zu bauen.

Damit bei uns die Windows Entwicklung funktioniert, räume ich Delphi aus. Alle nicht für 32/64Bit benötigten Known IDE Packages werden entfernt. Damit gewinnt man schon mal 400 MB an virtuellem Speicher. Wir haben eigen Experts entwickelt, die sowohl Packages als auch Monolithen "Out of Delphi" compilieren können. Der Grund darin liegt, dass Delphi bei Erzeugen anscheinend mit Speicherlecks zu kämpfen hat. Beim Erzeugen geht der Speicher über 4GB, starte ich neu und führe es erneut aus, werden die restlichen Units dazucompiliert und der Speicher bleibt unter 4GB. Mit dem "Out of Delphi" erzeugen funkt es auch so.

[Sherlock]

Also zugunsten einer Komfortfunktion (Projektgruppe) verzichtet Ihr auf alles andere? Das spricht dann doch viel eher dafür, lieber mal die Gruppe zu entkrauten und auf andere Technologien wie Jenkins zu setzen.

Sherlock

[win568]

Hmm. Welche Komfortfunktion ?? Die Packages bauen aufeinander auf. Dadurch sind diese in einer Gruppe zu halten, da viele Programmierer an unterschiedlichen Dateien arbeiten und einchecken. Mit dem nächsten Svn Abgleich müssen teilweise die Packages wieder neu erzeugt werden. Wir verwenden Jenkins zwar als Unittestserver, aber was soll es uns bei der Entwicklung bringen ??

[Moombas]

Also ich denke wie gesagt, das man sagen kann:

• Für die meisten Projekte wird durch 64-Bit sich nichts ändern
• Durch 64-Bit wird es nicht schneller, es steht nur mehr Speicher zur Verfügung (im Prinzip Zukunftssicherer wenn man die steigende Komplexität bei vielen Anwendungen betrachtet)
• Sollte mit 32-Bit mal das gleiche passieren wie mit 16-Bit (nicht mehr von der CPU unterstützt), wäre man darauf bereits vorbereitet (bei Android z.B. kann man ja soweit ich weiß nur noch 64-Bit hoch laden, da ist der Weg zur "nicht mehr Unterstützung" nicht mehr weit). Man wäre hier also auch Zukunftssicherer.

[himitsu]

Zitat:

Zitat von Sherlock (Beitrag 1463968)

Also zugunsten einer Komfortfunktion (Projektgruppe) verzichtet Ihr auf alles andere?

Wir nutzen FinalBuilder und ein CI, was aktuell nur das Testen, aber "noch" nicht das Kompilieren übernimmt,
aber leider haben wir beim Debuggen ein kleines Problem, wodurch der FinalBuilder+Eurekalog die Debugginfos von Delphi schrottet und der Delphi-Debugger somit diese Projekte nicht debuggen kann, außer man kommpiliert im Delphi neu.

Meistens reicht es im Delphi dann nur 1-3 EXE/DLL/BPL zu kompilieren,
aber bis vor Kurzem ist Delphi bei Kompilieren der untersten 25 Packages fast immer komplett abgeraucht. (ja, das war unsere eigene Schuld, aber es hatte ewig bebraucht die Fehler zu finden)
Somit mußte ich öfters, wenn ich "schlimmes" Fehler überall suchen wollte, woher alles löschen, Delphi sauber starten und konnte/musste dann einmal alles durchkompilieren.

PS: Die eine alte Funktion von Delphi ist echt saublöd.
"Automatisch speichern beim Kompilieren" speichert nach dem erfolgreichen Kommpilieren, also erst nachdem Delphi abgestürzt ist, und somit war dann alles futsch.

Auch wird der "Desktop" nicht gespeichert (XE), wenn man "Speichert", sondern erst wenn man Delphi schließt. Und keine Ahnung wie die das machen, aber wenn Delphi abstürzte, dann wart das auch oft futsch und Delphi startet dann ohne das letzte Projekt zu öffnen mit eimen zerlegten Layout (alles abgedockt und fehlende Module, aber gespeicherter Desktop laden geht zum glück), aber auch nach anschließenden dem Öffnen der Projektgruppe fehlt dann alles, wie geöffnete Dateien und vor allem sind die Haltepunkte weg.


PS: 16 Bit läuft doch noch?
Wenn man DOS, Windows 1 oder ein 32 Bit Windows nutzt. Das 16 Bit-Subsystem wurde doch nur im 64 Bit-Windows entfernt, oder ist es nun auch schon aus 32 Bit raus?

[jaenicke]

Zitat:

Zitat von win568 (Beitrag 1463965)

Wir haben eigen Experts entwickelt, die sowohl Packages als auch Monolithen "Out of Delphi" compilieren können.

Dafür gibt es auch ein Häkchen in den Projektoptionen, dass msbuild extern verwendet werden soll.

Zitat:

Zitat von win568 (Beitrag 1463969)

Hmm. Welche Komfortfunktion ?? Die Packages bauen aufeinander auf. Dadurch sind diese in einer Gruppe zu halten, da viele Programmierer an unterschiedlichen Dateien arbeiten und einchecken. Mit dem nächsten Svn Abgleich müssen teilweise die Packages wieder neu erzeugt werden.

Dafür braucht man aber keine Projektgruppe mit allen Packages. Bei uns ist das z.B. unterteilt in die Packages mit gemeinsamen Units und Komponenten, die von den verschiedenen Projekten für Anwendungen und DLLs dann verwendet werden. Diese Packages werden per Kommandozeile installiert und mit msbuild erzeugt.

Beim Debuggen usw. haben wir dann nur die Projektgruppe oder das Einzelprojekt offen, an dem wir konkret arbeiten.

Würden wir das anders machen, hätten wir insbesondere bei Versionen wie XE6 deutliche Probleme gehabt. So funktionierte es selbst da schon recht gut und in den 10er Versionen haben wir so gut wie gar keine Probleme mehr damit.

Zitat:

Zitat von himitsu (Beitrag 1463977)

PS: Die eine alte Funktion von Delphi ist echt saublöd.
"Automatisch speichern beim Kompilieren" speichert nach dem erfolgreichen Kommpilieren, also erst nachdem Delphi abgestürzt ist, und somit war dann alles futsch.

Man sieht bereits beim Kompilieren, dass sich der Speicherknopf deaktiviert. Das Speichern passiert vor dem Kompilieren.

Zitat:

Zitat von himitsu (Beitrag 1463977)

Auch wird der "Desktop" nicht gespeichert (XE), wenn man "Speichert", sondern erst wenn man Delphi schließt.

Das stimmt. Das hat aber den Vorteil, dass es bei Abstürzen durch eine bestimmte offene Unit oder ein Projekt nicht gleich beim Start wieder einen Absturz gibt.

[Moombas]

Zitat:

Zitat von himitsu (Beitrag 1463977)

PS: 16 Bit läuft doch noch?
Wenn man DOS, Windows 1 oder ein 32 Bit Windows nutzt. Das 16 Bit-Subsystem wurde doch nur im 64 Bit-Windows entfernt, oder ist es nun auch schon aus 32 Bit raus?

Das hängt von deiner CPU ab (oder dessen benötigter Chipsatz), nicht vom verwendeten Betriebssystem (zumindest ist es mir beim letzteren nicht bekannt).
Bei uns der I3-6100 mit Intel Q270er Chipsatz.
Intel hat bei allen neuen Prozessoren die Unterstützung dessen abgeschaltet.

Bei uns musste ein Softwarelieferant daher viele Routinen nochmal in 32-Bit neu kompilieren, weil das mit der neuen PC-Hardware für die Stores nicht mehr lief (OS ist gleich geblieben; NTVDM hing sich dann immer mit 25% auf).
Wobei er laut Wiki es können soll...

Und die Software ist auch schon uralt...

[win568]

Zitat:

Zitat von win568 (Beitrag 1463965)

Wir haben eigen Experts entwickelt, die sowohl Packages als auch Monolithen "Out of Delphi" compilieren können.

Zitat:

Zitat von jaenicke (Beitrag 1463987)

Dafür gibt es auch ein Häkchen in den Projektoptionen, dass msbuild extern verwendet werden soll.

Haben wie bereits versucht, aber hier ist das gleiche Problem, das dem msbuild der Speicher ausgeht. Daher verwenden wir den fastdcc32, unsichtbar ausgeführt in einer Dos Kommandozeile. Die Ergebnisse werden geholt und in einer eigenen übersichtlicheren Liste, in der man Warnings, Errors filtern und farblich trennen kann, dargestellt.

Zitat:

Zitat von win568 (Beitrag 1463969)

Hmm. Welche Komfortfunktion ?? Die Packages bauen aufeinander auf. Dadurch sind diese in einer Gruppe zu halten, da viele Programmierer an unterschiedlichen Dateien arbeiten und einchecken. Mit dem nächsten Svn Abgleich müssen teilweise die Packages wieder neu erzeugt werden.

Zitat:

Zitat von jaenicke (Beitrag 1463987)

Dafür braucht man aber keine Projektgruppe mit allen Packages. Bei uns ist das z.B. unterteilt in die Packages mit gemeinsamen Units und Komponenten, die von den verschiedenen Projekten für Anwendungen und DLLs dann verwendet werden. Diese Packages werden per Kommandozeile installiert und mit msbuild erzeugt.

Beim Debuggen usw. haben wir dann nur die Projektgruppe oder das Einzelprojekt offen, an dem wir konkret arbeiten.

Würden wir das anders machen, hätten wir insbesondere bei Versionen wie XE6 deutliche Probleme gehabt. So funktionierte es selbst da schon recht gut und in den 10er Versionen haben wir so gut wie gar keine Probleme mehr damit.

Auch hier verwenden wir die Standardgruppen nicht. Wir haben sowohl statische Packages, also Packages die aufeinander aufbauen, als auch dynamische Packages (die unabhängig sind). Das Compilercenter checkt diese Abhängigkeiten und erzeugt die dynamischen, je nach Ressource auf der Maschine, parallel.
Da bei uns viele Programmierer gleichzeitig ab Code arbeiten und diese wiederrum in unterschiedlichen Packages Änderungen vornehmen, ist so ein Einspielen im Hintergrund auch nicht praktikabel

[himitsu]

Zitat:

Zitat von Moombas (Beitrag 1463990)

Das hängt von deiner CPU ab ...

Ohh, wusste nur noch, dass es im Windows mal ausgebaut wurde.
Wenn die CPU es nicht mehr kann, dann kann man doch seine geliebte VM mit Windows 1 und Delphi 1 nicht mehr starten
und Turbo Pascal ist dann auch tot. :cry:

Mal sehn wie die DOS-Emulatoren damit zurecht kommen.

Rechner/VM starten, Windows booten, Delphi starten und kompilieren in weniger als einer Sekunde ... wo geht das denn sonst noch, außer bei Delphi 1 auf 'ner halbwegs modernen CPU mit SSD. :stupid: