MSElang, der zukünftige Compiler für MSEide+MSEgui

Forum für alles rund um die MSEide und MSEgui
Antworten
mse
Beiträge: 2013
Registriert: Do 16. Okt 2008, 10:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.6,git master FPC 3.0.4,fixes_3_0)
CPU-Target: x86,x64,ARM

Re: MSElang, der zukünftige Compiler für MSEide+MSEgui

Beitrag von mse »

5: Teil:
Dateianhänge
mseguicomp17.png
mseguicomp18.png

marcov
Beiträge: 1100
Registriert: Di 5. Aug 2008, 09:37
OS, Lazarus, FPC: Windows ,Linux,FreeBSD,Dos (L trunk FPC trunk)
CPU-Target: 32/64,PPC(+64), ARM
Wohnort: Eindhoven (Niederlande)

Re: MSElang, der zukünftige Compiler für MSEide+MSEgui

Beitrag von marcov »

theo hat geschrieben:Christian hat recht und ich glaube ich habe dir das auch schon öfter gesagt Martin.

Niemand bezweifelt dein technisches Können.


Die selben Sentimenten leben auch in FPC Core Kreisen. Speziell bei die jenen die an FPC's Database Unterstützung arbeiten.

MSE war eine weile voran damit (aber nicht Delphi Kompatibel und wie immer isoliert auf seine eigene Insel), bis 2.4.0-2.4.2, wann die FCL-DB Entwicklung mehr kontinuierlich wurde (Joost, Ladislav, Reinier, Ludo) Ich kann nicht ganz Urteilen wer jetzt besser ist, aber die Vorsprung ist sicher viel kleiner geworden.

Daneben versucht Martin typisch zu viel am gleichen Zeit zu machen (IDE,Widgetset, andere Bibliotheken und jetzt auch Kompiler).
(spreads himself too thin, gibst eine ähnliches Sprichwort aufs Deutsch? )

Benutzeravatar
theo
Beiträge: 10497
Registriert: Mo 11. Sep 2006, 19:01

Re: MSElang, der zukünftige Compiler für MSEide+MSEgui

Beitrag von theo »

marcov hat geschrieben:(spreads himself too thin, gibst eine ähnliches Sprichwort aufs Deutsch? )

"sich verzetteln" http://www.duden.de/rechtschreibung/ver ... _aufhalten
Ich glaube aber nicht, dass Martin die Übersicht verloren hat.

mse
Beiträge: 2013
Registriert: Do 16. Okt 2008, 10:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.6,git master FPC 3.0.4,fixes_3_0)
CPU-Target: x86,x64,ARM

Re: MSElang, der zukünftige Compiler für MSEide+MSEgui

Beitrag von mse »

Ich glaube auch nicht. Im Gegensatz zu Free Pascal habe ich klar definierte Ziele und habe auch alles was ich mir vorgenommen habe termingerecht fertiggestellt. Ihr könnt nicht von mir erwarten, dass ich statt die Werzeuge die ich benötige zu bauen, meine Zeit mit eurem Delphi-Clone verbringe. Ich habe es versucht, musste aber einsehen, dass das grössten Teils vergebene Liebesmüh ist.
Ich finde es eigentlich recht grosszügig von mir, dass ich meine Arbeiten allen frei zur Verfügung stelle, obwohl ich öfters Häme und Missgunst ernte. ;-)

Benutzeravatar
theo
Beiträge: 10497
Registriert: Mo 11. Sep 2006, 19:01

Re: MSElang, der zukünftige Compiler für MSEide+MSEgui

Beitrag von theo »

mse hat geschrieben:obwohl ich öfters Häme und Missgunst ernte. ;-)

Das kommt dir nur so vor. Einige von uns versuchen nur deine Begabung in sinnvolle Bahnen zu lenken. :wink:
Deine Insellösungen finden einfach kein adäquates Pulbikum und werden es auch nie finden, da verwette ich meine Glaskugel.
Ich und sicher andere auch bewundern dein Talent und sind einfach enttäuscht darüber, dass du es für etwas einsetzt, das uns nichts nützt.
Wenn du einfach in deinem mse-Universum leben würdest, wäre das vielleicht gar kein Thema. Aber du suchst doch auch immer die Nähe zu den Lazarus Benutzern.

creed steiger
Beiträge: 957
Registriert: Mo 11. Sep 2006, 22:56

Re: MSElang, der zukünftige Compiler für MSEide+MSEgui

Beitrag von creed steiger »

Eine "Insel" kann auch ihre Vorteile haben (siehe Apple).
Der Reibungsverlust bei mehreren Entwicklern fällt weg was ein Vor aber auch ein Nachteil seien kann.

Ich bin auf jeden Fall gespannt was rauskommt.

Für den Raspberry hab ich MSE schon probiert, ist wirklich fix, leider macht der blöde VNC mir Probleme.

mse
Beiträge: 2013
Registriert: Do 16. Okt 2008, 10:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.6,git master FPC 3.0.4,fixes_3_0)
CPU-Target: x86,x64,ARM

Re: MSElang, der zukünftige Compiler für MSEide+MSEgui

Beitrag von mse »

Nicht unbedingt Lazarus sondern Free Pascal Nutzer. Es interessieren mich auch immer mögliche Problemstellungen.

Eine weitere MSElang-LLVM Kostprobe:

Code: Alles auswählen

 
program test1;
var
 gi1: int32;
 
function test(p1: int32): int32;
var
 i1: int32;
 pi1: ^int32;
begin
 pi1:= @i1;
 pi1^:= p1;
 result:= pi1^;
 exitcode:= result+2+gi1;
end;
 
begin
 gi1:= 123;
 gi1:= test(gi1);
 exitcode:= gi1;
end.
 


MSElang LLVM -O3:

Code: Alles auswählen

 
   .file   "test-opt.ll"
   .text
   .globl   main
   .align   16, 0x90
   .type   main,@function
main:                                   # @main
# BB#0:
   movl   $123, __unnamed_1
   movl   $123, %eax
   ret
.Ltmp0:
   .size   main, .Ltmp0-main
 
   .type   __unnamed_1,@object     # @0
   .local   __unnamed_1
   .comm   __unnamed_1,4,4
 
   .section   ".note.GNU-stack","",@progbits
 


Free Pascal -O3

Code: Alles auswählen

 
[...]
.section .text
   .balign 16,0x90
.globl   P$TEST1_TEST$LONGINT$$LONGINT
   .type   P$TEST1_TEST$LONGINT$$LONGINT,@function
P$TEST1_TEST$LONGINT$$LONGINT:
# Temps allocated between esp+4 and esp+4
# [test1.pas]
# [9] begin
   subl   $4,%esp
# Var p1 located in register eax
# Var $result located in register eax
# Var pi1 located in register edx
# Var i1 located at esp+0
# [10] pi1:= @i1;
   movl   %esp,%edx
# [11] pi1^:= p1;
   movl   %eax,(%edx)
# [13] exitcode:= result+2+gi1;
   movl   %eax,%edx
   addl   $2,%edx
   movl   U_P$TEST1_GI1,%ecx
   addl   %ecx,%edx
   movl   %edx,operatingsystem_result
# [14] end;
   addl   $4,%esp
   ret
[...]
main:
# Temps allocated between esp+0 and esp+0
# [16] begin
   call   FPC_INITIALIZEUNITS
# [17] gi1:= 123;
   movl   $123,%eax
# [18] gi1:= test(gi1);
   movl   %eax,U_P$TEST1_GI1
   call   P$TEST1_TEST$LONGINT$$LONGINT
   movl   %eax,U_P$TEST1_GI1
# [19] exitcode:= gi1;
   movl   %eax,operatingsystem_result
# [20] end.
   call   FPC_DO_EXIT
   ret
[...]
 

LLVM ist wirklich verblüffend.

mse
Beiträge: 2013
Registriert: Do 16. Okt 2008, 10:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.6,git master FPC 3.0.4,fixes_3_0)
CPU-Target: x86,x64,ARM

Re: MSElang, der zukünftige Compiler für MSEide+MSEgui

Beitrag von mse »

creed steiger hat geschrieben:Für den Raspberry hab ich MSE schon probiert, ist wirklich fix, leider macht der blöde VNC mir Probleme.

Was meinst du damit?

creed steiger
Beiträge: 957
Registriert: Mo 11. Sep 2006, 22:56

Re: MSElang, der zukünftige Compiler für MSEide+MSEgui

Beitrag von creed steiger »

Die Glyphen (Button,Memo usw) der IDE werden bei mir nicht angezeigt (X Error: BadDrawable).

Ich hab ein bissl recherchiert, scheint ein VNC Problem zu sein.

Wenn ich das Kistchen wieder angesteckt habe, mach ich einen eigenes Thema dazu auf, bevor es hier zu sehr OT wird.

marcov
Beiträge: 1100
Registriert: Di 5. Aug 2008, 09:37
OS, Lazarus, FPC: Windows ,Linux,FreeBSD,Dos (L trunk FPC trunk)
CPU-Target: 32/64,PPC(+64), ARM
Wohnort: Eindhoven (Niederlande)

Re: MSElang, der zukünftige Compiler für MSEide+MSEgui

Beitrag von marcov »

mse hat geschrieben:obwohl ich öfters Häme und Missgunst ernte. ;-)


Das ist weil du alle Kritik so interpretierst :_) Eben wenn das nicht so gemeinnt ist.

theo hat geschrieben:Deine Insellösungen finden einfach kein adäquates Pulbikum und werden es auch nie finden, da verwette ich meine Glaskugel.


(Also nicht so lange es ein Lazarus und eben Delphi gibt in direkter Wettbewerb. Wenn MSE der einzige Lösung dieser Magnitude wäre, würde es es viel besser tun)

theo hat geschrieben:Ich und sicher andere auch bewundern dein Talent und sind einfach enttäuscht darüber, dass du es für etwas einsetzt, das uns nichts nützt.
Wenn du einfach in deinem mse-Universum leben würdest, wäre das vielleicht gar kein Thema. Aber du suchst doch auch immer die Nähe zu den Lazarus Benutzern.


Genau.

theo hat geschrieben:Ich glaube aber nicht, dass Martin die Übersicht verloren hat.


Von seiner Gesichtspunkt mit seine Dogmas und Ziele ? Vielleicht nicht.

Aber es ist so schade das Insel Lösungen und alles alleine machen immer wieder Teil der Zielen ausmachen. Das setzt Grenzen an der Wachstum und der Zahl der Iterierungen der Individuelle Komponenten. Und das meinte ich damit das Martin sich verzettelte.

Christian
Beiträge: 6079
Registriert: Do 21. Sep 2006, 07:51
OS, Lazarus, FPC: iWinux (L 1.x.xy FPC 2.y.z)
CPU-Target: AVR,ARM,x86(-64)
Wohnort: Dessau
Kontaktdaten:

Re: MSElang, der zukünftige Compiler für MSEide+MSEgui

Beitrag von Christian »

Ich würde marcov s sprichwort eher mit "Auf zuvielen Hochzeiten tanzen" übersetzen.

Ich glaub das triffts aber nicht. Wenn man in einer Community wie beim fpc oder Lazarus entwickelt muss man viele Leute davon überzeugen das seine Lösung die beste ist. Man muss alles 100x erzählen und gegen vermeindlich schlechte Lösungen kämpfen. Das erfordert viel mühe, bringt aber allen etwas.

Wenn man das in seinem eigenen Universum tut, muss man keinen überzeugen. Man schafft ne Menge. Es nützt aber recht wenigen solang man nicht ALLES fertig hat.

Ich denke ein schönes Beispiel ist Apple und Steve Jobs. Er hat die Firma 2x verlassen weil sie nicht das durchhaltevermögen hatten seine Spinnerein zu finanzieren. Nach der 2. Rückkehr hat ers dann mit dem ipod geschafft....
W.m.k.A.h.e.m.F.h. -> http://www.gidf.de/

mse
Beiträge: 2013
Registriert: Do 16. Okt 2008, 10:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.6,git master FPC 3.0.4,fixes_3_0)
CPU-Target: x86,x64,ARM

Re: MSElang, der zukünftige Compiler für MSEide+MSEgui

Beitrag von mse »

marcov hat geschrieben:(Also nicht so lange es ein Lazarus und eben Delphi gibt in direkter Wettbewerb. Wenn MSE der einzige Lösung dieser Magnitude wäre, würde es es viel besser tun)

Ich denke, die Konkurrenz von MSEide+MSEgui hat Lazarus sehr gut getan, denke nur an die Debugging-Funktionen.
Ich bin überzeugt, dass die Konkurrenz von MSElang auch Free Pascal gut tun wird.
Zudem glaube ich, die von Marco erwähnten Fortschritte in FCL-DB währen ohne den Druck von MSEgui wohl nicht möglich gewesen. Zum Beispiel tsqlite3connection, da war die einhellige Meinung des FPC-Teams, dass es nicht geht Sqlite3 in Sqldb zu integrieren, da Sqlite3 "gar keine richtige Datenbank sei". Nachdem ich tsqlite3connection für MSEgui gemacht habe, konnte der Code in FCL-DB übernommen werden, die "revolutionären" Teile wurden allerdings entfernt, so dass nur eine mittelmässige Lösung entstanden ist. Ich mag keine mittelmässige Lösungen.
Der Vorsprung von MSEgui-Sqldb gegenüber FCL-Sqldb ist immer noch sehr gross und wird sich auch nicht verkleinern, da ja auch MSEgui laufend an neue Bedürfnisse angepasst wird.
Dank Michaels (EgonHugeist) Arbeit hat Zeos einen grossen Sprung vorwärts gemacht, Respekt. Auch hier, Michael ist ein "Einzeltäter".
Aber es ist so schade das Insel Lösungen und alles alleine machen immer wieder Teil der Zielen ausmachen. Das setzt Grenzen an der Wachstum und der Zahl der Iterierungen der Individuelle Komponenten. Und das meinte ich damit das Martin sich verzettelte.

Christian hat geschrieben:Wenn man das in seinem eigenen Universum tut, muss man keinen überzeugen. Man schafft ne Menge. Es nützt aber recht wenigen solang man nicht ALLES fertig hat.

Ich bin mit MSEide+MSEgui 1999 gestartet. Nach fünf Jahren war das Ziel erreicht, meine Software-Produktivität im Vergleich zum gewohnten Delphi zu verdoppeln. Seither sind weitere zehn Jahre intensiver Entwicklungsarbeit an MSEide+MSEgui ins Land gegangen und ich bin mit dem Erreichten rundum zufrieden. Wenn ich die im Deutschen Lazarus Forum verhandelten Probleme und vorgeschlagene Lösungen anschaue, glaube ich nicht, dass Lazarus heute meine Bedürfnisse voll befriedigen könnte und bin daher froh, dass ich eigene Werkzeuge zur Verfügung habe.
Free Pascal hat sich in den letzten zehn Jahren zunehmend von meinen Zielen entfernt, darum habe ich den Kampf gegen Windmühlen aufgegeben und das MSElang Projekt gestartet. Übrigens von Anfang an unter Einbezug der möglichen Interessenten, siehe auch dieses Thema hier.

mschnell
Beiträge: 3444
Registriert: Mo 11. Sep 2006, 10:24
OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
CPU-Target: X32 / X64 / ARMv5
Wohnort: Krefeld

Re: MSElang, der zukünftige Compiler für MSEide+MSEgui

Beitrag von mschnell »

mse hat geschrieben:Free Pascal hat sich in den letzten zehn Jahren zunehmend von meinen Zielen entfernt,

Für mich ist ganz schlimm, dass fpc versucht, die "Code-aware" Strings so zu implementieren, wie es in Delphi vorgegeben ist. Dabei ist offensichtlich (wie in der mailing-Liste diskutiert und nicht von mir vorgeschlagen (!) ), dass das Delphi-Team sich da untereinander offensichtlich nicht einig war.

Ich bin ein Fan von ordentlich definierten "Code-aware" Strings (siehe meinen Artikel darüber im Wiki (den ich auf expliziten Wunsch in der Mailing-Liste geschrieben habe) ). Aber es ist vermutlich sehr unwahrscheinlich, dass so etwas jemals realisiert wird (obwohl es nicht (sehr) schwierig wäre, und zu Delphi vermutlich voll abwärts-kompatibel ist).

Ich weiß, Du magst "Code-aware" Strings überhaupt nicht und wirst sie in MSE-Lang nicht verwenden. Kann ich akzeptieren. Besser gar keine als die von Delphi ! (Aber wie du ein ordentliches TStrings definieren willst habe ich noch nicht verstanden...)

-Michael

marcov
Beiträge: 1100
Registriert: Di 5. Aug 2008, 09:37
OS, Lazarus, FPC: Windows ,Linux,FreeBSD,Dos (L trunk FPC trunk)
CPU-Target: 32/64,PPC(+64), ARM
Wohnort: Eindhoven (Niederlande)

Re: MSElang, der zukünftige Compiler für MSEide+MSEgui

Beitrag von marcov »

EInfach, wie Delphi alle 1-byte Typen rauswerfen. Also TStrings ist auf UnicodeString basiert und basta.

(und TStrings ist ein Delphi Typ, also MSE(+lang) brauchen das gar nicht zu implementieren. Wenn man alles neu entwirft, ist es vielleicht logischer da ein Interface aus zu machen statt ein abstracter Basisklasse)

Christian
Beiträge: 6079
Registriert: Do 21. Sep 2006, 07:51
OS, Lazarus, FPC: iWinux (L 1.x.xy FPC 2.y.z)
CPU-Target: AVR,ARM,x86(-64)
Wohnort: Dessau
Kontaktdaten:

Re: MSElang, der zukünftige Compiler für MSEide+MSEgui

Beitrag von Christian »

Vielleicht wirds wirklich zeit das Lazarus mehrere compiler unterstützt...
W.m.k.A.h.e.m.F.h. -> http://www.gidf.de/

Antworten