[MSEide-MSEgui-talk] Another MSElang bechmark
Hi,
The attached program on Linux-x86:
MSElang with LLVM 3.8.0 -O3
time ./test1.bin
real0m2.582s
user0m2.467s
sys 0m0.111s
Binary size 18088 bytes after strip.
FPC 3.0.3 -O3:
time ./test1_fpc
real0m4.074s
user0m3.955s
sys 0m0.119s
Binary size 177576 bytes after strip.
Looks good! :-)
Martin
program test1;
{$ifdef FPC}{$mode objfpc}{$h+}{$goto on}{$endif}
const
stringcount = 200;
defaultmwcseedw = 521288629;
defaultmwcseedz = 362436069;
type
{$ifdef FPC}
card8 = byte;
card32 = cardinal;
char8 = char;
string8 = string;
{$endif}
mwcinfoty = record
fw,fz: card32; //call checkmwcseed() after init
end;
pstring8 = ^string8;
pcard8 = ^card8;
ppointer = ^pointer;
pointerarty = array of pointer;
arraysortcomparety = function (const l,r: ppointer): int32;
// arraysortcomparety = function (const l,r): int32;
function comparestring(const l,r: ppointer): int32;
var
pl,pr,pe: pcard8;
c: int8;
i1,i2: int32;
begin
result:= 0;
pl:= l^;
pr:= r^;
if pl <> pr then begin
if pl = nil then begin
result:= -1;
end
else begin
if pr = nil then begin
result:= 1;
end
else begin
i1:= length(string8(pointer(pl)));
i2:= length(string8(pointer(pr)));
if i1 < i2 then begin
pe:= pl+i1;
while pl < pe do begin
c:= pl^-pr^;
if c <> 0 then begin
result:= c;
exit;
end;
inc(pl);
inc(pr);
end;
end
else begin
pe:= pr+i1;
while pr < pe do begin
c:= pl^-pr^;
if c <> 0 then begin
result:= c;
exit;
end;
inc(pl);
inc(pr);
end;
end;
result:= i1-i2;
end;
end;
end;
end;
procedure sortarray(var dest: pointerarty; {const} compare: arraysortcomparety);
var
ar1: pointerarty;
step: integer;
l,r,d: ppointer;
stopl,stopr,stops: ppointer;
sourcepo,destpo: ppointer;
acount: integer;
label
endstep;
begin
setlength(ar1,length(dest));
sourcepo:= pointer(dest);
destpo:= pointer(ar1);
step:= 1;
acount:= length(dest);
while step < acount do begin
d:= destpo;
l:= sourcepo;
r:= sourcepo + step;
stopl:= r;
stopr:= r+step;
stops:= sourcepo + acount;
if stopr > stops then begin
stopr:= stops;
end;
while true do begin //runs
while true do begin //steps
while compare(l,r) <= 0 do begin //merge from left
d^:= l^;
inc(l);
inc(d);
if l = stopl then begin
while r <> stopr do begin
d^:= r^; //copy rest
inc(d);
inc(r);
end;
goto endstep;
end;
end;
while compare(l,r) > 0 do begin //merge from right;
d^:= r^;
inc(r);
inc(d);
if r = stopr then begin
while l <> stopl do begin
d^:= l^; //copy rest
inc(d);
inc(l);
end;
goto endstep;
end;
end;
end;
endstep:
if stopr = stops then begin
break; //run finished
end;
l:= stopr; //next step
r:= l + step;
if r >= stops then begin
r:= stops-1;
end;
if r = l then begin
d^:= l^;
break;
end;
stopl:= r;
stopr:= r + step;
if stopr > stops then begin
stopr:= stops;
end;
end;
d:= sourcepo; //swap buffer
sourcepo:= destpo;
destpo:= d;
step:= step*2;
end;
if sourcepo <> pointer(dest) then begin
dest:= ar1;
end;
end;
function mwcnoise(var state: mwcinfoty): card32;
begin
with state do begin
fz:= 36969 * (fz and $) + (fz shr 16);
fw:= 18000 * (fw and $) + (fw shr 16);
result:= fz shl 16 + fw;
end;
end;
procedure test1();
var
mwc: mwcinfoty;
ar1: array of string8;
i1,i2: int32;
ch1: char8;
begin
mwc.fw:= defaultmwcseedw;
mwc.fz:= defaultmwcseedz;
setlength(ar1,stringcount);
for i1:= 0 to high(ar1) do begin
mwcnoise(mwc);
setlength(ar1[i1],card8(mwcnoise(mwc)));
for i2:= 1 to length(ar1[i1]) do begin
ch1:= char8(card8(((mwcnoise(mwc) and $ff) * 95) div 255 + 32)); //32..127
ar1[i1][i2]:= ch1;
end;
end;
sortarray(pointerarty(pointer(ar1)),@comparestring);
for i1:= 1 to high(ar1) do begin
{
if ar1[i1] = '' then begin
writeln(i1,':');
end
else begin
writeln(i1,':',card8(ar1[i1][1]),': ', ar1[i1]);
end;
}
if ar1[i1-1] > ar1[i1] then begin
exitcode:= 1;
exit;
end;
end;
end;
begin
test1();
end.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Another MSElang benchmark
On Friday 21 April 2017 17:14:00 Graeme Geldenhuys wrote: > On 2017-04-21 15:52, Martin Schreiber wrote: > > The attached program on Linux-x86: > > MSElang with LLVM 3.8.0 -O3 > > So I assume the MSElang compiler will generate the same output (or very > close at least) as Delphi's new Linux compiler. Seeing as both are using > LLVM. > MSElang produces LLVM bitcode - a kind of target independed machine code in SSA form https://en.wikipedia.org/wiki/Static_single_assignment_form which will be optimized and compiled to target specific machine code by LLVM. It is also possible to execute LLVM bitcode directly in a LLVM runtime environment with just in time compilation. > It seems Embarcadero/Idera couldn't be bothered to implement their own > Linux compiler again - like they did for Kylix. So instead they simply > use LLVM. I've heard quite a lot of developers are not happy with that, > because some language behaviour and data types are now different between > Windows and Linux. So code sharing is not as good as it was with Delphi > + Kylix. > That is not caused by LLVM but by the changes in the language specification in the Delphi frontend. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Another MSElang benchmark
On Friday 21 April 2017 21:20:14 Graeme Geldenhuys wrote: > On 2017-04-21 17:34, Martin Schreiber wrote: > > That is not caused by LLVM but by the changes in the language > > specification in the Delphi frontend. > > I have no clue... I'll try and find the URL of that conversation and > forward it on to you. Just in case MSELang might fall into the same trap. > In the Delphi NEXTGEN compilers they removed AnsiStrings and added ARC to classes, string indices are 0-based. There was also a talk about to remove pointers, I don't know if it really happened. Again, that changes have nothing to do with LLVM but mostly with marketing and the needs of the mobile targets and their target audience maybe. The Linux compiler is also NEXTGEN AFAIK. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Another MSElang bechmark
On Friday 21 April 2017 16:52:39 Martin Schreiber wrote: [...] > > FPC 3.0.3 -O3: > > time ./test1_fpc > > real0m4.074s > user0m3.955s > sys 0m0.119s > Binary size 177576 bytes after strip. > Correction: Binary size 26072 bytes after strip. There was a missing -XX. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Another MSElang bechmark
On Saturday 22 April 2017 03:50:24 Jon Foster wrote: > Now you're catching my attention... However when I compile test1.pas with > fpc v3.0.0-3 the finished size is only 26,004 bytes. I don't think you used > smart linking. Yup, there was a missing -XX. The correct size with 3.0.2 is 26072 bytes. > Still it looks impressive. Does your binary require libc? Yes. ldd test1.bin linux-gate.so.1 (0xb77d3000) libm.so.6 => /lib/libm.so.6 (0xb775c000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb773f000) libc.so.6 => /lib/libc.so.6 (0xb7591000) /lib/ld-linux.so.2 (0xb77d6000) > FPC exes don't require any libs so they pack a bit more in the run time, > rather than linking with libc. MSEgui also links to libc. There was not a single libc incompatibility issue since 1999 so I think it is doable. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Another MSElang benchmark
On Saturday 22 April 2017 11:37:36 Graeme Geldenhuys wrote: > On 2017-04-22 08:26, Martin Schreiber wrote: > > Again, that changes have nothing to do with LLVM > > Well all the Delphi compilers that use LLVM apparently have different > data type size too for 2-3 data types. LongWord, LongInt I think. > Coincidence with LLVM vs native compiler? Maybe not. > The ordinal types of LLVM are i1..i8388607 where the number is the bitsize. http://llvm.org/docs/LangRef.html#single-value-types So it completely belongs to the language frontend which sizes it maps to the type names. > I was pretty sure I read this information in the Delphi group on > Google+, but searching is so sh*t on Google+, for the life of me I can't > find that post. Sorry. > I tried to find information at Embarcadero about the differences of NEXTGEN - without success too. ;-) Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Another MSElang benchmark
On Saturday 22 April 2017 11:48:46 Graeme Geldenhuys wrote: > On 2017-04-22 10:37, Graeme Geldenhuys wrote: > > for the life of me I can't find that post. > > Saying that, I did track down the Delphi blog post that sparked the > conversation on Google+ I'm looking for. > > https://web.archive.org/web/20170217114422/http://blog.marcocantu.com/blog/ >2017-february-delphi-linux-compiler.html > MSElang/MSEpas does not use basic datatypes with variable size. MSEpas has int8, int16, int32, int64, card8, card16, card32 and card64 which can be mapped to the traditional pascal type names as you like. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Another MSElang benchmark
On Saturday 22 April 2017 17:29:07 Jon Foster wrote: > On 04/22/2017 03:18 AM, Martin Schreiber wrote: > > On Saturday 22 April 2017 11:48:46 Graeme Geldenhuys wrote: > >> On 2017-04-22 10:37, Graeme Geldenhuys wrote: > >>> for the life of me I can't find that post. > >> > >> Saying that, I did track down the Delphi blog post that sparked the > >> conversation on Google+ I'm looking for. > >> > >> https://web.archive.org/web/20170217114422/http://blog.marcocantu.com/bl > >>og/ 2017-february-delphi-linux-compiler.html > > > > MSElang/MSEpas does not use basic datatypes with variable size. MSEpas > > has int8, int16, int32, int64, card8, card16, card32 and card64 which can > > be mapped to the traditional pascal type names as you like. > > > > Martin > > Considering how many different architectures out there it is probably a > wise choice to name types by size. I would. :-) Or maybe just two generic > names followed by a bit size modifier like with C structures. That way you > could use a 4 bit unsigned int where ever it might be convenient... not > just in structures. The developer could "type" them too for type safety > (type nibble = unsigned:4;). > That's the case for MSElang please see the Wiki: https://gitlab.com/mseide-msegui/mselang/wikis/home MSElang base types are ranges. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] config dialog
On Wednesday 03 May 2017 19:28:43 code dz wrote: > Hi > if you noticed , when resizing mseide config dialog , the target text > edit stuck at small size . maybe wrong anchors value !. Please try again with git master 4431c0f6a064cf104f156ec6a3914c2180198b75, thanks for reporting. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
[MSEide-MSEgui-talk] MSElang Objects
Hi, I implemented objects and classes in MSElang: https://gitlab.com/mseide-msegui/mselang/wikis/home/Mselang_objects Thoughts? Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang Objects
On Saturday 06 May 2017 11:29:42 Fred van Stappen wrote: > > By the way, what can we do already with mselang ? > It is not ready for public use. > Do you have some examples ? > Testcases for the Free Pascal dialect: https://gitlab.com/mseide-msegui/mselang/tree/master/mselang/test > Is it possible already to compile msegui or fpgui applications ? > No. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang Objects
On Saturday 06 May 2017 15:13:45 Marcos Douglas B. Santos wrote: > On Sat, May 6, 2017 at 6:20 AM, Martin Schreiber wrote: > > Hi, > > I implemented objects and classes in MSElang: > > https://gitlab.com/mseide-msegui/mselang/wikis/home/Mselang_objects > > > > Thoughts? > > In wiki home you wrote: "records, objects and classes could be unified > in a single concept: Objects." > But you continue using objects and classes... > > Use only objects and change this syntax... > o1: ^obj5ty; > ...to this one > o1: obj5ty; > Correct. Plus o1^.f1 <-> c1.f1 for access of heap instance elements and that "class" instances always are on heap. "class" is for people who are accustomed to Free Pascal. Do you think "class" should be removed? Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang Objects
On Saturday 06 May 2017 20:30:56 Graeme Geldenhuys wrote: > On 2017-05-06 10:20, Martin Schreiber wrote: > > Thoughts? > > What "string" and "character" types will MSElang support? Hopefully not as > huge a list as FPC and Delphi. > https://gitlab.com/mseide-msegui/mselang/wikis/home MSElang and MSEpas (a subset of Free Pascal) have "string8" (utf-8) "string16" (utf-16) "string32" (ucs-4) and "bytestring" for any 8-bit encoding and binary data. Character types are "char8", "char16" and "char32". > hint: >Java makes this simple. One string type (class), one character type and > 8 other primitive data types. Much simpler and easier to understand than > the mess Object Pascal has, thanks to FPC and Delphi. > MSElang has been designed as a high performance language so it can't be so simple. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang Objects
On Sunday 07 May 2017 11:01:40 code dz wrote: > congratulation :) > what about the rtl , would you uses fpc one of write your own ? > MSElang itself will only have a minimal RTL. For "daily business tasks" we have the MSEgui environment already. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang Objects
On Sunday 07 May 2017 11:10:48 code dz wrote:
> btw the keyword (method) looks weird , (sub) is much better or
> typical pascal (procedure , function) . its only my opinion ;)
>
I wanted to remove the distinction between "procedure" and "function",
so "sub". Object procedures and functions have an implicit data pointer
parameter ("self") so I thought that an own name ("method") is justified.
> also the attribuates mechanism really looks cool .
>
I plan to use method attributes for operator overloading too:
"
type
complexty = object
real,imm: flo64;
method add(const a,b: complexty): complexty ['+'];
method sub(const a,b: complexty): complexty ['-'];
method mul(const a,b: complexty): complexty ['*'];
method tostring8(const source: complexty): string8 [':='];
end;
"
Martin
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang Objects
On Sunday 07 May 2017 12:05:40 Graeme Geldenhuys wrote: > On 2017-05-07 08:20, Martin Schreiber wrote: > > MSElang and MSEpas (a subset of Free Pascal) have "string8" (utf-8) > > "string16" (utf-16) "string32" (ucs-4) > > That sounds good. > > > and "bytestring" for any 8-bit encoding and > > binary data. > > Why this? Why not simply Byte or an array of bytes. The term "bytestring" > introduces confusion again. > Because of compatibility with string8 where the index base can be 1 and string concatenation. > Also why bother with any other text encoding than the Unicode standard. The > Unicode standard was designed to support ALL languages and finally get rid > of the 8-bit mess. All you need is conversions from all the 8-bit encodings > to Unicode, and then be done with it. > You probably never made software for bus systems and communication with hardware devices. There it often happens that bytestreams contain binary and text components. A reference counted buffer datatype which can be concatenated from strings and binary data is convenient and effective. > >>Java makes this simple. One string type (class), one character type > >> and 8 other primitive data types. Much simpler and easier to understand > >> than the mess Object Pascal has, thanks to FPC and Delphi. > > > > MSElang has been designed as a high performance language so it can't be > > so simple. > > Huh? Java is an excellent performance language. Please ignore all > statements on the Internet older than say 5 years. The Java language has > come a long way, and is *very* fast now. In fact, it actually generates > binary code that is magnitudes faster than what FPC can achieve. There are situations where 8 bit string code units are the best, there are others where 16 bit codeunits are appropriate and some where 32 bit codeunits provide the best performance. I like to control that myself instead to use an opaque string class. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang Objects
On Sunday 07 May 2017 12:11:06 code dz wrote: > > sounds good , but i think it add some complexity to the code > readability, because the name (add) already indicates the operation , > so why ['+'] , maybe operator instead of method should be fine ! . > just thought > The method names can be choosen freely: " complexty = object real,imm: flo64; method add(const a,b: complexty): complexty ['+']; method sub(const a,b: complexty): complexty ['-']; method mulblabla(const a,b: complexty): complexty ['*']; method tostring8(const source: complexty): string8 [':=']; method tostring16(const source: complexty): string16 [':=']; end; complex2ty object(complexty) scale: flo64; method addscaled(const a,b: complexty): complexty ['+']; method subscaled(const a,b: complexty): complexty ['-']; end; " so "operator" instead of an attachment would not work. " complexty = object real,imm: flo64; operator add(const a,b: complexty): complexty; operator sub(const a,b: complexty): complexty; operator mulblabla(const a,b: complexty): complexty; operator tostring8(const source: complexty): string8; operator tostring16(const source: complexty): string16; end; complex2ty object(complexty) scale: flo64; operator addscaled(const a,b: complexty): complexty; operator subscaled(const a,b: complexty): complexty; end; " Also " method add(const a,b: complexty): complexty ['+']; " can be used as ordinary object method so I don't think it should be named "operator". " method complexty.add(const a,b: complexty): complexty; begin result.real:= a.real + b.real; result.imm:= a.imm + b.imm; end; var a,b,c: complexty; [...] a:= b + c; a:= add(b,c); " Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang Objects
On Sunday 07 May 2017 16:18:09 Marcos Douglas B. Santos wrote: > > I think every language should be as simple as possible. > So, if you can mix every Pascal concept in just one concept, called > object, it is better. > > But if you care about programmers that came from another language and > you care if they are confortable using the same concepts they have in > another languages, it is up to you decide if it worth continue with > this concepts. > > Classes should not exists in object-oriented programming. This is a > mistake. Only objects should exists. In MSElang "class" = "^object" on heap. So you mean there should be no object heap pointers but stack allocated objects only? I probably misunderstood. > I'm following and participate (more or less) of a new language called > EO https://github.com/yegor256/eo that do not have classes, NULL and > other things that should not exists in OOP. > That looks a little bit abstract to me. A general purpose programming language should be handy and not necessarily academically clean. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang Objects
On Sunday 07 May 2017 18:48:13 Marcos Douglas B. Santos wrote: > On Sun, May 7, 2017 at 1:14 PM, Martin Schreiber wrote: > >> Classes should not exists in object-oriented programming. This is a > >> mistake. Only objects should exists. > > > > In MSElang "class" = "^object" on heap. So you mean there should be no > > object heap pointers but stack allocated objects only? I probably > > misunderstood. > > No. I'm talking just about design concepts. > I want to work with objects. If they are created in heap or not, I don't > care. But... forget that. This concept will change all in MSElang. > > About your design, if "class" = "^object", why do not keep only one? > > Using your syntax, I propose this: > > 1. TObj = object [static] << this is like record > > 2. TObj = object [dynamic] << this is like class > Currently it can be defined in "var" section " var obj1: TObj; //on stack obj2: ^TObj; //on heap begin //obj1 does not need to be created obj2:= tobj.create(); obj2.destroy(); " or in "type" section " type TObj = object end; PObj = ^TObj; var obj1 = TObj; obj2 = PObj; begin //obj1 does not need to be created obj2:= tobj.create(); obj2.destroy(); " One does not need to use "class", it can be removed. I thought that people comming from Free Pascal will like it. ;-) > But a clean syntax that is much BETTER is only: > > TObj = object > > ...and the compiler should know if that should be on heap or not. > > For me, every object is a "dynamic" instance. I don't work with records. > I think a programmer should know what happens. See for example how slow LLVM-optimizer and compiler are. One reason is the excessive use of "advanced" C++ technics in the LLVM tools. Step through the code and check what happens behind the scene in almost every statement, it is crazy. > > Another questions: > > 1. "Methods can be virtual, interfaces are listed after the possible > ancestor." obj6ty = object(obj5ty,testintf) [virtual] > method donothing() [virtual]; > end; > > Q: to make virtual methods , I need to declare the "object" [virtual] at > first? > Yes, or inherit from a virtual object. The purpose is that a virtual method table pointer in the data record will be reserved and initialized. The reason why to define it explicitely is also that IMO programmers should know what happens. > 2. "Virtual object not initialized with zeros." > obj4ty = object [virtual,nozeroinit] > private > ffield1: int32; > method getfield1(): int32; > method setfield1(const avalue: int32); > public > method dosomething() [virtual]; > property field1 read getfield1 write setfield1; > end; > > Q: What is the point about "nozeroinit"? What the advantages? > Performance. There is no need to zeroing the data if it is initialized in code anyway. > 3. Ancestor class: > > obj9ty = object(,testintf) [virtual] //no ancestor > > Q: Why this ugly syntax? You are simplifying some Pascal syntax (eg: > every line should have a ";", every block has an "end", etc) but here > you are committing a mistake, IMHO. > > If you allow this: > > obj4ty = object" << without ancestor > > you should allow this: > obj9ty = object(testintf) << not an acestor, but an interface > > ...and the compiler should know that is an interface, not a class. > For me code structures should always look the same. An object header is (ancestor,interface1,interface2...), I don't like to have an interface at the first position where normally the ancestor is placed. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang Objects
On Monday 08 May 2017 04:01:02 Marcos Douglas B. Santos wrote: > > > > Currently it can be defined in "var" section > > " > > var > > obj1: TObj; //on stack > > obj2: ^TObj; //on heap > > begin > > //obj1 does not need to be created > > obj2:= tobj.create(); > > obj2.destroy(); > > " > > or in "type" section > > " > > type > > TObj = object > > end; > > PObj = ^TObj; > > var > > obj1 = TObj; > > obj2 = PObj; > > begin > > //obj1 does not need to be created > > obj2:= tobj.create(); > > obj2.destroy(); > > " > > Two ways to define the same thing. > Do you think this is good? > Yes. > > One does not need to use "class", it can be removed. I thought that > > people comming from Free Pascal will like it. ;-) > > You could be right, but I think they will like more if not exist ambiguity. > :) Other opinions? Should "class" be removed? [...] > > >> 3. Ancestor class: > >> > >> obj9ty = object(,testintf) [virtual] //no ancestor > >> > >> Q: Why this ugly syntax? You are simplifying some Pascal syntax (eg: > >> every line should have a ";", every block has an "end", etc) but here > >> you are committing a mistake, IMHO. > >> > >> If you allow this: > >> > >> obj4ty = object" << without ancestor > >> > >> you should allow this: > >> obj9ty = object(testintf) << not an acestor, but an interface > >> > >> ...and the compiler should know that is an interface, not a class. > > > > For me code structures should always look the same. An object header is > > (ancestor,interface1,interface2...), I don't like to have an interface at > > the first position where normally the ancestor is placed. > > So, is not better to do this? > > 1. obj4ty = object(tobject) > 2. obj9ty = object(tobject, testintf) > > I mean, we always need to write the ancestor. > It will always look the same. > MSElang supports objects with interfaces but no ancestor. TObject is no part of language but part of the RTL for Free Pascal compatibility. The syntax has been be changed to " type obj9ty = object(nil,testinf) end; " Reading https://github.com/yegor256/eo I fear you are against NIL too. ;-) Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang Objects
On Monday 08 May 2017 14:11:28 Marcos Douglas B. Santos wrote: > On Mon, May 8, 2017 at 2:39 AM, Martin Schreiber wrote: > >> > One does not need to use "class", it can be removed. I thought that > >> > people comming from Free Pascal will like it. ;-) > >> > >> You could be right, but I think they will like more if not exist > >> ambiguity. > >> > >> :) > > > > Other opinions? Should "class" be removed? > > Well, if ^TObj is the same as class and you will continue using this > syntax then, yes, I think class should be removed. > But maybe we should think more about it. > In order to clarify the difference of "object" and "class": "object" can be allocated on stack or on heap. "class" is an object which always is allocated on heap -> it always must be instantiated by a call of a constructor by .TheConstructor() and it must be destroyed by a call of a destructor by .TheDestructor() and it has an implicit dereference for element access. " type objty = object f1: int32; f2: int32; constructor create(); destructor destroy(); end; pobjty = ^objty; TObj = class(objty) end; constructor objty.create(); begin end; destructor objty.destroy(); begin end; var obj1: objty; //an instance on stack, needs no create() or destroy() obj2: ^objty; //on heap obj3: pobjty; obj4: TObj; //on heap begin obj1.f1:= 123; //no create() call necessary, no destroy() call necessary obj2:= objty.create(); obj2^.f1:= 123; //note the '^' dereference obj3:= objty.create(); obj3^.f1:= 123; //note the '^' dereference obj4:= TObj.create(); obj4.f1:= 123;//no '^' dereference obj2.destroy(); obj3.destroy(); obj4.destroy(); " Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang Objects
On Monday 08 May 2017 16:49:40 Marcos Douglas B. Santos wrote: > > Some questions: > > 1. In this case: > obj1: objty; //an instance on stack, needs no create() or destroy() > > if my object has create() or destroy() they will be executed automatically? > No. Call it "manually": " obj1.create(); obj1.destroy(); " or use "ini", "fini" methods: " objty = object method theinimethod() [ini]; //called after object initialization method thefinimethod() [fini]; //called before object finalization end; " "ini" and "fini" work for stack and heap. > 2. In this case: > obj2: ^objty; //on heap > > Is it possible to remove the "^"? > obj2.f1:= 123; > No, obj2 is a pointer. > I think this distinction exists because "class" exists, right? The other way around, "class" exists for convenience and where one needs the guarantee that the instance never is allocated on stack. > If is possible to remove, well, this is +1 to remove class and mantain > just object but without "^" in calls, but we can continue using in > definition. > And how to access object elements if they are allocated on stack and not addressed via pointer? "@obj1.f1" or "obj1↓.f1" or...? Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang Objects
On Monday 08 May 2017 18:12:19 Marcos Douglas B. Santos wrote: > On Mon, May 8, 2017 at 12:40 PM, Martin Schreiber wrote: > > " > > "ini" and "fini" work for stack and heap. > > In fact, this is a good idea. But why don't use [initialization] and > [finalization]? > The IDE has code-completion so, is better to see a code more readable, > don't you think? > MSEide has no code-completion, I don't like automatism which fiddle with my code and I don't like popping-up windows which disturb the flow of thoughts while programming. ;-) > > You've already answered "No, obj2 is a pointer." but what about if the > compiler change this by itself, putting a "^" because the variable > declaration has one? > > var > obj1: objty; //an instance on stack, needs no create() or destroy() > obj2: ^objty; //on heap > begin > obj1.f1:= 123; > > obj2:= objty.create(); > try > // I did not write the '^' but the compiler will use because the > declaration in VAR > obj2.f1:= 123; > finally > obj2.destroy(); > end; > end; > It contradicts the usual Pascal and MSElang pointer notation: " type recty: record a: int32; b: int32; end; precty = ^recty; objty: object a: int32; b: int32; constructor create(); end; pobjty = ^objty; var rec1: recty; rec2: precty; rect3: ^recty; obj1:= objty; obj2:= pobjty; obj3:= ^objty; begin new(rec2); //new is probably not available in MSElang rec3:= @rec1; rec1.a:= 123; rec2^.a:= 123; rec3^.b:= 456; obj2:= objty.create(); obj3:= @obj1; obj1.a:= 123; obj2^.a:= 123; // obj2.a:= 123; inconsequent! obj3^.b:= 456; // obj3.b:= 456; inconsequent! " Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang Objects
On Monday 08 May 2017 21:05:33 Sieghard wrote: > Hallo Marcos, > > Du schriebst am Mon, 8 May 2017 13:12:19 -0300: > > >> 2. In this case: > > >> obj2: ^objty; //on heap > > >> > > >> Is it possible to remove the "^"? > > >> obj2.f1:= 123; > > > > > > No, obj2 is a pointer. > > > > > >> I think this distinction exists because "class" exists, right? > > How does that behave in case of _nested objects_, possibly with identically > named fields, which might even be of different types? Is that manageable, > or will the construct break down, at least on "pathological" casses? > Example? Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang Objects
On Monday 08 May 2017 22:44:39 Marcos Douglas B. Santos wrote: > On Mon, May 8, 2017 at 4:05 PM, Sieghard wrote: > > Hallo Marcos, > > > > Du schriebst am Mon, 8 May 2017 13:12:19 -0300: > >> >> 2. In this case: > >> >> obj2: ^objty; //on heap > >> >> > >> >> Is it possible to remove the "^"? > >> >> obj2.f1:= 123; > >> > > >> > No, obj2 is a pointer. > >> > > >> >> I think this distinction exists because "class" exists, right? > > > > How does that behave in case of _nested objects_, possibly with > > identically named fields, which might even be of different types? Is that > > manageable, or will the construct break down, at least on "pathological" > > casses? > > > > (I'm afraid it _will_ break down.) > > For me it would be the same as today, using classes. But classes always are a pointer to a memory area on heap. Objects can be in global static memory, on stack or on heap so I think it should be visible at element access if the object reference is an address or the content. " type tcla = class end; objty = object f1: int32; end; pobjty = ^objty; var cla1: tcla; cla2: tcla; obj1: objty; obj2: objty; obj3: ^objty; //or pobjty obj4: ^objty; //or pobjty begin obj1: objty; cla1:= cla2; //copies the address of content obj1:= obj2; //copies the content obj1.f1:= 123; obj3:= obj4; //copies the address of content obj3:= @obj2;//copies the address of content obj3^.f1:= 123; //or with o: obj3^ do o.f1:= 123; end; > But Martin have already disagreed about this single syntax. > I must work some time with "object"s in order to decide if an additional "class" type is rectified. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang Objects
On Tuesday 09 May 2017 10:41:00 Fred van Stappen wrote: > Hello. > > > If I may give my HO, I see more future for libraries than for executables > for Pascal. > > > So I hope that mselang will take (much more) care for the size and speed of > libraries than fpc does. > MSElang uses LLVM to produce the binaries so I assume if you get good results with Clang you will get good results with MSElang too. > > It is sad that still a fpc library with same code is 5 times bigger than a > fpc executable ( and montain times bigger than same C code compiled with > gcc or clang). > Do you know why? > > I ask it regularly to fpc forum but (still same answer for more than 15 > years now !) ---> "It is on the todo list". > > > fpc libraries can be compiled for Java-native-libraries too. > > > I have to confess also that my plan are to use Pascal only for creating > libraries (and Java for the rest). > Why? Doesn't this make debugging much more difficult? Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang Objects
On Tuesday 09 May 2017 14:08:39 Marcos Douglas B. Santos wrote: > > I understand your point of view but I think this could be confusing... > Well, first of all we should understand the proposal this new language: > > 1. Is it a low level language that will works like C to make libs, OS and > so on? 2. Is it a high level language that abstract the details, but allow > us to use these details *if* we wish? > > I see Object Pascal inside second option. > Me too, but "abstract details" and "hide details" is not the same for me. Agreed, if a developer is confused about pointers and copying contents/references he/she should not use MSElang nor Free Pascal. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang Objects
On Tuesday 09 May 2017 15:26:24 Marcos Douglas B. Santos wrote: > > It is not about if these languages are better, but if they are easy to > do the work. > Thats the reason why I proposed the additional and possibly redundant "class". You are against the "class" which eliminates the explicit "^" dereference and you are against the "^" which eliminates the uncertainty of value/reference object item access with the same notation. :-) Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang Objects
On Thursday 11 May 2017 14:27:51 Fred van Stappen wrote: > Hello Martin > > >> It is sad that still a fpc library with same code is 5 times bigger than > >> a fpc executable ( and montain times bigger than same C code compiled > >> with gcc or clang). > > > > Do you know why? > > Huh, the answers in fpc forum are nebulous: > > - One said it is because parameter -fPIC is added automatic even when not > entered by code. It seems that fpc has problems if -fPIC is not used. > > - Other said it is because dynamic runtime packages are not supported yet: > > http://free-pascal-general.1045716.n5.nabble.com/Size-of-program-vs-library >-td5718200.html > > - There was other answers too but I do not find it back. > You compare a smartlinked executable (-XX -CX) with the size of the correspondent libraries. It is logical that the libraries are bigger because the libraries contain all named code, the smartlinked executable contains the actually used code only. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang Objects
On Friday 12 May 2017 00:07:09 Fred van Stappen wrote: > > It is logical that the libraries are bigger because the libraries contain > > all named code > > Huh, : > > > program prognude ; > begin > end. > => 26.9 k > > library libnude ; > begin > end. > => 196.3 k Have you checked with objdump what is in libnude? Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang Objects
On Friday 12 May 2017 03:44:30 Edson H wrote:
>
> In order to avoid confusion I would suggest to use some standard or
> recommendation on names, something like "All class names must be preceded
> by the letter C"
>
In MSEgui I use "T" as prefix for class types. All other custom types have no
prefix but "ty" postfix. There is also the {"P"} prefix for pointer
types. "T" could be replaced by "C" which looks more correct.
>
> Sometime I think all the names of identifiers must be clear indicative of
> their type and even of the scope. Something, like PHP do with variables,
> but it would be another language.
>
I strongly am against the hungarian notation and generally use prefixes with
caution. I think the start of a designator should contain the most important
part in order to speed up vertical or block source scanning. For variables
the most important part is the name IMO.
>
> I see MSELang like a new proposal for a modern language. I'm including some
> changes too, to the Pascal language in my compiler. There are people who
> thinks Pascal is perfect like it is, but I see, fortunately, you are not
> that kind of people, like I'm not.
>
Yup!
>
> I believe, I will be glad on using MSElang. I don't like you are using
> LLVM, but anyway you are doing a great work.
>
Why, what would be the alternatives?
MSElang produces an intermediate code representation
https://gitlab.com/mseide-msegui/mselang/blob/master/mselang/opglob.pas
which can be interpreted directly (mostly for testing purpose)
https://gitlab.com/mseide-msegui/mselang/blob/master/mselang/stackops.pas
or converted to LLVM bitcode
https://gitlab.com/mseide-msegui/mselang/blob/master/mselang/llvmops.pas
https://gitlab.com/mseide-msegui/mselang/blob/master/mselang/llvmbcwriter.pas
If you like to write your own optimizer and code generator you can use the
intermediate code. The quality of LLVM produced binaries is impressive, see
for example
https://gitlab.com/mseide-msegui/mselang/wikis/home/mselang_benchmarks
>
> Congratulations.
>
Thanks!
Martin
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang Objects
On Friday 12 May 2017 03:44:30 Edson H wrote: > > I'm currently developing a Pascal Compiler Do you refer to https://github.com/t-edson/PicPas ? Looks good! Does the IDE have integrated debug capabilities? I worked many years with PIC16xxx. Programming always was done in assembler. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang Objects
On Friday 12 May 2017 06:06:41 Martin Schreiber wrote: > On Friday 12 May 2017 00:07:09 Fred van Stappen wrote: > > > It is logical that the libraries are bigger because the libraries > > > contain all named code > > > > Huh, : > > > > > > program prognude ; > > begin > > end. > > => 26.9 k > > > > library libnude ; > > begin > > end. > > => 196.3 k > > Have you checked with objdump what is in libnude? > BTW, the mergesort benchmark binary also was 177576 bytes with accidentally not working -XX, with active smartlinking it was reduced to 26072 bytes. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang Objects
On Friday 12 May 2017 13:52:36 Fred van Stappen wrote: > > BTW, the mergesort benchmark binary also was 177576 bytes with > > accidentally not working -XX, with active smartlinking it was reduced to > > 26072 bytes. > > Hello Martin. > > In a other topic, they talk about to use : -k--gc-sections. > Yup, I get 29.9 KB with fpc -k--gc-sections libnude.pas " library libnude ; procedure test(); begin end; exports test; end. " " objdump -h -T -t liblibnude.so liblibnude.so: file format elf32-i386 Sections: Idx Name Size VMA LMA File off Algn 0 .hash 0014 00d4 00d4 00d4 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 1 .gnu.hash 0020 00e8 00e8 00e8 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .dynsym 0020 0108 0108 0108 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .dynstr 0022 0128 0128 0128 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .rel.dyn 1528 014c 014c 014c 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 5 .text 4af0 1680 1680 1680 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE 6 .rodata 01b0 6170 6170 6170 2**4 CONTENTS, ALLOC, LOAD, READONLY, DATA 7 .eh_frame 6320 6320 6320 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 8 .dynamic 00a8 7f58 7f58 6f58 2**2 CONTENTS, ALLOC, LOAD, DATA 9 .data 03f0 8000 8000 7000 2**4 CONTENTS, ALLOC, LOAD, DATA 10 .bss 1664 83f0 83f0 73f0 2**4 ALLOC SYMBOL TABLE: 00d4 ld .hash .hash 00e8 ld .gnu.hash .gnu.hash 0108 ld .dynsym .dynsym 0128 ld .dynstr .dynstr 014c ld .rel.dyn .rel.dyn 1680 ld .text .text 6170 ld .rodata .rodata 6320 ld .eh_frame .eh_frame 7f58 ld .dynamic .dynamic 8000 ld .data .data 83f0 ld .bss .bss 1680 g F .text 0005 test DYNAMIC SYMBOL TABLE: 1680 gDF .text 0005 test " Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang Objects
On Friday 12 May 2017 20:28:54 Fred van Stappen wrote:
>
> > accidentally not working -XX, with active smartlinking it was reduced to
> > 26072 bytes.
>
> Do you mean that you have a trick to do smartlinking working for libraries
> ?
>
No, the first time I presented the benchmark results in the meaning I had
added -XX to the FPC parameters but actually I had not.
> > Yup, I get 29.9 KB with fpc -k--gc-sections libnude.pas
>
> So what is the conclusion, what is the trick ?
>
Compile with
"
fpc -k--gc-sections libnude.pas
"
Every FPC program or library contains system.o which is 710KB before strip.
It seems that -XX does not work with "library" so the --gc-sections linker
command must be supplied to the linker directly.
"
fpc -XX -s prognude.pas
"
produces ppas.sh:
===
#!/bin/sh
DoExitAsm ()
{ echo "An error occurred while assembling $1"; exit 1; }
DoExitLink ()
{ echo "An error occurred while linking $1"; exit 1; }
echo Linking prognude
OFS=$IFS
IFS="
"
/usr/bin/ld -b elf32-i386 -m elf_i386--gc-sections -s -L. -o prognude
link.res
if [ $? != 0 ]; then DoExitLink prognude; fi
IFS=$OFS
===
"
fpc -XX -s libnude.pas
"
produces ppas.sh:
===
#!/bin/sh
DoExitAsm ()
{ echo "An error occurred while assembling $1"; exit 1; }
DoExitLink ()
{ echo "An error occurred while linking $1"; exit 1; }
echo Linking liblibnude.so
OFS=$IFS
IFS="
"
/usr/bin/ld -b elf32-i386 -m elf_i386 -init FPC_SHARED_LIB_START -fini
FPC_LIB_EXIT -soname liblibnude.so -shared -L. -o liblibnude.so link.res
if [ $? != 0 ]; then DoExitLink liblibnude.so; fi
IFS=$OFS
echo Linking liblibnude.so
OFS=$IFS
IFS="
"
/usr/bin/strip --discard-all --strip-debug liblibnude.so
if [ $? != 0 ]; then DoExitLink liblibnude.so; fi
IFS=$OFS
===
Note the missing --gc-sections.
Martin
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang Objects
On Saturday 13 May 2017 11:14:18 Fred van Stappen wrote: > > Compile with fpc -k--gc-sections libnude.pas > > Ha, so this is the trick: using -k--gc-sections ? > > Should I sent a advice in > http://free-pascal-general.1045716.n5.nabble.com/Size-of-program-vs-library >-td5718200.html ? > Yes, and the question is why FPC does not provide --gc-sections to the linker with the -XX paramer for libraries. A bug? And you should check if the *.so still is working with -k--gc-sections. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang Objects
On Monday 15 May 2017 10:32:01 Fred van Stappen wrote: > Pff, no answers (as usual). > > > I begin to be lazy of fpc. > Make a feature request? " -XX should work for libraries. " or so. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang Objects
On Friday 19 May 2017 18:06:18 Jon Foster wrote: [...] > If MSElang is far enough along it would be interesting to see what it can > do with with Graeme's ray-caster. I've dumbed it down to <300 lines and > removed the external SDL dependency so it can be run as a raw computational > benchmark. > > If you have the time to perform a translation and want to give it a whirl > the reduced code is at https://github.com/jafcobend/fpcflop in the > "mctest.pas" > I'll take a look. I hope I don't forget to CC you. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang Objects
On Monday 22 May 2017 11:39:28 Fred van Stappen wrote: > > Make a feature request? > > Hello Martin. > > OK, I try to do my best. ---> > http://free-pascal-general.1045716.n5.nabble.com/Size-of-program-vs-library >-td5718200i40.html > > But to accept the request, the fpc team ask to --> > > >> Before filing a request, you can already check yourself what happens > >> with > >> form data if you compile a lazarus form into the library. > > Sorry, I am not able to compile a LCL form into library. > I spent hours and loose lot of hair for that --> no success. > > So I will not do a feature request, I do not have time for this (and no > passion). > I would submit a "feature request" (for me it is more a bug ;-) ) anyway so it will not be forgotten. > PS: By the way, as you know, compiling MSEgui and fpGUI forms into library > works like charm and no data is loosed when using -k--gc-sections. > MSEgui does not use the FPC resource system. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] fpcflop benchmark
On Wednesday 24 May 2017 04:46:04 Jon Foster wrote:
> On 05/23/2017 10:45 AM, Martin Schreiber wrote:
> > On Friday 19 May 2017 18:06:18 Jon Foster wrote:
> >> On 05/07/2017 03:05 AM, Graeme Geldenhuys wrote:
> >>> On 2017-05-07 08:20, Martin Schreiber wrote:
> >>>> MSElang has been designed as a high performance language so it can't
> >>>> be so simple.
> >>>
> >>> [...]
> >>> Although many on the FPC mailing list seem content to come up with
> >>> excuses or blame Graeme for poor design it seems to me the real
> >>> questions is: Why is x/y, when both are declared as singles, so
> >>> much slower in FPC then it is in language X. So I'd really like to see
> >>> how MSElang scores in this arena. I've been contemplating some game
> >>> scenarios and I've been keeping my eye out for an improved language.
> >>> Maybe I should get on board with MSElang.
> >
> > Please read Jonas mail about the problems of the testcase:
> > https://www.mail-archive.com/fpc-pascal%40lists.freepascal.org/msg46162.h
> >tml
>
> Yes, I've read his post and he had an idea or two that might improve FPC's
> performance somewhat. I think Graeme addressed him with a reply. The bottom
> line was that the identical code runs amazingly faster in other languages.
That is wrong, the code is not identical. Please read the mail again,
especially about the differences of round().
[...]
> Your image looks like its probably doing things right but the output is
> scrambled. The x & y dimensions in the array that I substituted for the SDL
> drawing surface are probably reversed.
So it is better:
"
var
screen: array [0..s_h-1, 0..s_w-1] of LongInt;
texmap : array[0..16*16*16*3-1] of LongInt;
map : array[0..64*64*64-1] of smallint;
procedure plot(x,y,c : LongInt) {$ifdef FPC}inline{$endif};
begin
screen[y, x] := c;
end;
"
> So what's MSElang's frame rate and on what kind of machine/OS?
>
Not ready yet.
Martin
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] fpcflop benchmark
On Wednesday 24 May 2017 07:47:09 Martin Schreiber wrote: > > > So what's MSElang's frame rate and on what kind of machine/OS? > > Not ready yet. > Linux 32 bit Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz With round() operations https://gitlab.com/mseide-msegui/mselang/blob/master/mselang/benchmark/mctest/mctest.pas FPC 3.0.2 -O- -> 8 FPS -O4 -CfSSE3 -CpCOREI -> access violation -O3 -CfSSE3 -CpCOREI -> access violation -O4 -CpCOREI -> 8.2 FPS MSElang, LLVM 3.8.0 No options -> 4.2 FPS -O3 -> 5.9 FPS -O3 -mcpu=corei7 -mattr=+sse3,+ssse3 -> 33.5 FPS With trunci32() operations https://gitlab.com/mseide-msegui/mselang/blob/master/mselang/benchmark/mctest/mctest_trunc.pas -O3 -> 8.1 -O3 -mcpu=corei7 -mattr=+sse3,+ssse3 -> 41.5 FPS Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] fpcflop benchmark
On Wednesday 24 May 2017 15:32:05 Graeme Geldenhuys wrote: > On 2017-05-24 14:15, Martin Schreiber wrote: > > FPC 3.0.2 > > -O- -> 8 FPS > > -O4 -CfSSE3 -CpCOREI -> access violation > > -O3 -CfSSE3 -CpCOREI -> access violation > > -O4 -CpCOREI -> 8.2 FPS > > Bottom line FPC sucks for game development - unless you offload > pretty much everything onto a GPU - something I was hoping wouldn't be > needed for that project. > > FPC's saving grace is that most applications seem to be console, web or > desktop apps, so those inefficient binaries go unnoticed. > Maybe with working SSE3 on 64 bit it is not so bad. Without SSE3 FPC is faster than LLVM. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] fpcflop benchmark
On Wednesday 24 May 2017 15:15:15 Martin Schreiber wrote: > On Wednesday 24 May 2017 07:47:09 Martin Schreiber wrote: > > > So what's MSElang's frame rate and on what kind of machine/OS? > > > > Not ready yet. > > Linux 32 bit > Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz > > With round() operations > https://gitlab.com/mseide-msegui/mselang/blob/master/mselang/benchmark/mcte >st/mctest.pas > > FPC 3.0.2 > -O- -> 8 FPS > -O4 -CfSSE3 -CpCOREI -> access violation > -O3 -CfSSE3 -CpCOREI -> access violation -O1 -CpCOREI -CfSSE3 -> 12.5 FPS Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] fpcflop benchmark
On Wednesday 24 May 2017 17:25:02 Jon Foster wrote:
>
> MSElang is using LLVM, right? Are you using an upstream provided x86 back
> end or did you have to write that?
MSElang produces LLVM bitcode
http://llvm.org/docs/BitCodeFormat.html
which will be optimized ("opt") and compiled to machine code ("llc") or runned
by a just in time compiler or interpreter ("lli").
Martin
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] fpcflop benchmark
On Wednesday 24 May 2017 18:58:40 Graeme Geldenhuys wrote:
> On 2017-05-24 17:52, Martin Schreiber wrote:
> > which will be optimized ("opt") and compiled to machine code ("llc") or
> > runned by a just in time compiler or interpreter ("lli").
>
> So LLVM does something like what Java's compiler does. I know nothing
> about LLVM. :)
>
There is also a Java Script backend for LLVM (LLVM bitcode -> Java Script).
Martin
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] fpcflop benchmark
On Thursday 25 May 2017 00:50:46 Jon Foster wrote: > > > Apple traded out GCC for CLang / LLVM some time ago. The only downside > I've heard about LLVM is that its slow. Like GCC & friends weren't. But I > think a lot GCC slowness is inherited from binutils and that's probably the > same for CLang/LLVM. I fear the slowness of LLVM - and it really slow - is also caused by the excessive use of "advanced C++ techniques". Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] fpcflop benchmark
On Friday 26 May 2017 12:02:00 Fred van Stappen wrote: > Do you have a idea when it will be possible to compile a library that uses > those units ? : > > > ---> Classes, ctypes, Math, sysutils. dynlibs, Pipes, cthreads, unixtype. > Not in near future, it still is much work to do. > Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
[MSEide-MSEgui-talk] Operator overloading in MSElang
Hi, Operator overloading has been implemented: https://gitlab.com/mseide-msegui/mselang/wikis/home/mselang_objects#operator Thoughts? Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
[MSEide-MSEgui-talk] Variant part in MSElang objects
Hi, Variant object parts have been implemented: https://gitlab.com/mseide-msegui/mselang/wikis/home/mselang_objects#variantpart Thoughts? Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Variant part in MSElang objects
On Saturday 03 June 2017 18:46:20 code dz wrote: > do you mean like union in c++ > Yes, and the replacement of "case" in pascal records. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Variant part in MSElang objects
On Sunday 04 June 2017 15:34:14 code dz wrote: > good , even the brackets is not informative for that purpose . Alternatives? Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Variant part in MSElang objects
On Tuesday 06 June 2017 11:36:34 Michael Schnell wrote: > On 04.06.2017 06:21, Martin Schreiber wrote: > > Yes, and the replacement of "case" in pascal records. > > Why introduce a completely new notation instead of just stay with > "case" ? This would be rather obvious in Pascal. > Because case in records is crap. It misleadingly pretends that there is access type control by the tags and it is clumsy. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Variant part in MSElang objects
On Tuesday 06 June 2017 13:32:28 Michael Schnell wrote: > On 06.06.2017 13:12, Martin Schreiber wrote: > > Because case in records is crap. It misleadingly pretends that there is > > access type control by the tags and it is clumsy. > > Right you are. But it never had been different in Pascal :( > And it is not a completely new notation, it is the Pascal notation for variant parts without the "case". Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang Objects
On Saturday 10 June 2017 06:15:09 Edson H wrote: > Hi Martin, > > > I have seen you use "sub" for procedures or functions, and "method" for > object. Is it? > Yes. > I think you can use only PROCEDURE keyword, for procedures and functions > (and probably for objects), like Modula-2, do. > I don't like "sub" much but found nothing better up to now. I think that object methods deserve an own token "method" because of the implicit "self" parameter. Comming from a Pascal background "procedure" implies that there must be a "function" too but there is none in MSElang. Maybe "proc" instead of "sub" and "meth" instead of "method" what do you think? " proc test1(a: int32): flo64; proc test2(const a: string8); meth objty.test3(a: int32): flo64; meth objty.test4(const a: string8); meth ctest.test3(a: int32): flo64; meth ctest.test4(const a: string8); " It has the advantage that procedure and method names are aligned. More experiments are needed. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang Objects
On Saturday 10 June 2017 07:52:31 Edson H wrote:
> I was thinking in using the two forms:
>
>
> "proc" (short word) and "procedure" (long word).
>
> "meth" (short word) and "method" (long word).
>
>
> I would like to keep the PROCEDURE, in the honor of Pascal/Modula-2.
>
That contradicts the guideline that code allways should look the same. I just
implemented dialect switching in MSElang, with {$mode pascal} the FPC objpas
syntax can be used. "*.pas" and "*.pp" file use {$mode pascal} by
default, "*.mla" use {$mode mselang}.
Martin
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang Objects
On Saturday 10 June 2017 06:54:15 Martin Schreiber wrote: > " > proc test1(a: int32): flo64; > proc test2(const a: string8); > meth objty.test3(a: int32): flo64; > meth objty.test4(const a: string8); > meth ctest.test3(a: int32): flo64; > meth ctest.test4(const a: string8); > " > It has the advantage that procedure and method names are aligned. More > experiments are needed. > It looks ugly. Currently I think "method" and "procedure" as you propose is better. " procedure test1(a: int32): flo64; procedure test2(const a: string8); method objty.test3(a: int32): flo64; method objty.test4(const a: string8); method ctest.test3(a: int32): flo64; method ctest.test4(const a: string8); " Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang Objects
On Saturday 10 June 2017 14:21:45 code dz wrote: > i think (method) is good abridgement for both function & procedure . > why another keyword! > Because a method has an implicit "self" parameter which "procedure" and "function" don't have. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang Objects
On Saturday 10 June 2017 18:45:34 Marcos Douglas B. Santos wrote: > My "vote" is to use "function" anywhere. > > You've said: > > ...object methods deserve an own token "method" because of the implicit > > "self" parameter. > > But the object itself is a context to the functions (methods) so, I > can't see any problems. > I like " var meth1: method(a,b: int32); " more than " var meth1: procedure(a,b: int32) of object; " > About the procedures vs functions vs "sub"... well, as I've said, just > use "function". > If you have a return, use the same as Pascal: > function Foo: Boolean; > > If you don't have a return, don't write the last part: > function Foo; > > IMHO a function that doesn't have a return — doesn't matter if is a > method or a "sub" — isn't a good design. Agreed, a "function" should return a value. Because MSElang subroutines return a value only if it is useful they should not be named "function". > You need to have a return. If you have a object with a method "exec", > eg, why not return the object itself? Just return something. Why? Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang Objects
On Saturday 10 June 2017 17:39:14 Edson H wrote: > > By the way, I haven't seen the keyword ELSIF in your IF syntax. > MSElang has no "elsif". I think nested structures should be written so that the nested character is visible. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang Objects
On Sunday 11 June 2017 17:31:33 Edson H wrote: > It's strange. Do you prefer to write? > > > if ... then > > ... > > else > > if ... then > > ... > > else > > if ... then > > ... > > else > > ... > > end; > > end; > > end; > > > Instead of? > > > if ... then > > ... > > elsif ... then > > ... > > elsif ... then > > ... > > else > > ... > > end; > Yes. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang Objects
On Sunday 11 June 2017 16:58:23 Marcos Douglas B. Santos wrote: > On Sun, Jun 11, 2017 at 1:29 AM, Martin Schreiber wrote: > >> You need to have a return. If you have a object with a method "exec", > >> eg, why not return the object itself? Just return something. > > > > Why? > > Because you could write a more elegant code. > If you return "self" even in methods that don't need to specify a > return, you can codify using a style more declarative instead of a > procedural style. > > Instead of this: > --- > obj.exec; > obj.foo; > obj.bar; > --- > > We can do this: > --- > obj.exec.foo.bar; > --- > I don't like it. Now one has to check what obj.exec() returns, what obj.exec.foo() returns and so on while reading th code. Another concern is performance. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang Objects
On Sunday 11 June 2017 02:36:46 Sieghard wrote: > Hallo Martin, > > Du schriebst am Sat, 10 Jun 2017 06:54:15 +0200: > > I don't like "sub" much but found nothing better up to now. I think that > > "sub" seems to me to imply you're about to create a new BASIC variant. > Why not use "function" for all such things, if you don't like to > explicitely state that some won't return a value. Looks like C then, > but Delphi and fpc allow for discarding a return value already anyway. > The separate names of Wirth's Pascal _did_ have a reason, and that was to > discern between real functions, which ought to _only_ calculate something > and return the result of the calculation, like a mathematical function > does, and a multiply used sequence of commands that produce a "side > effect", something the programm doesn't really need internally, but that > provides "useful" information for its environment (e.g. the user). > Considering the implementation of "VAR" parameters, i.e. parameters that > can transport a value from within a procedure to its program surroundings, > this difference has been blurred quite a lot by careless use(ers). > "function" in C always has a type identifier. As you write, a mathematical function returns something. So "procedure" like in Wirth's Modula2. > > object methods deserve an own token "method" because of the implicit > > "self" parameter. > > This _might_ be considered a valid argument, except that _any_ method > _must_ always be specified in conjunction with its containing object so > that there shouldn't be room for uncertainty. A "method" combines a code address and a data pointer which is different from "procedure" which is a code address only. "method" also eliminates the need of the ugly " var meth1: procedure (a,b: int32) of object; " construct. > You might argue with "WITH" > here, but even that is strictly defined in Pascal as to imply the scope of > the referenced object as the outermost one, and therefore has to be used > in case of multiple candidates. Alternatively, you might consider to do > away with "WITH", as some even say they consider it harmful. You should > remember, though, that this may mean a lot more typing (all those > qualifiers that are otherwise implied). > MSElang provides a safe "with" statement with mandatory local qualifier. [...] > > It has the advantage that procedure and method names are aligned. More > > That _might_ be a disadvantage at times, as it might make reading the > source text more difficult. > Please explain. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang Objects
On Monday 12 June 2017 22:13:32 Sieghard wrote: > Hallo Martin, > > [functions & procedures] > > > "function" in C always has a type identifier. As you write, a > > mathematical function returns something. So "procedure" like in Wirth's > > Modula2. > > Or so. In any case, you lose the ability to immediately recognize whether > such a thing can be used in an expression (returning a value) or has to be > used standing alone (classical Pascal "PROCEDURE"). IIRC you proposed to use "function" for both? Sometimes I have the impression you are against anything. > Yes, that _is_ ugly. But it is never needed within the context of an > object, it is _only_ used (needed) for the declaration of a type referring > to an object method. You could just as well specify the containing object > type as a qualifier, like this: > > SomeObjectMethod = SomeObject.procedure (a, b: int32); > > or, like your example, which defines the type only implicitely: > > ObjectMethodVariable: SomeObject.procedure (a, b: int32); > > if it refers to a method of a different object type, or just omit the > qualifier if it refers to the currently defined object type. I think this > should be unmistakable. > I probably understand wrong, but do "SomeObjectMethod" and "SomeMethodVariable" work with "SomeObject" only? That's not how Delphi and MSElang method variables work. > [WITH] > > > MSElang provides a safe "with" statement with mandatory local qualifier. > > Something like the "Modula" version? > I.e. effectively variable (object) renaming, without opening a new scope? Yes. > I definitely dislike this kind. This aliasing makes reading the code much > more difficult than the Pascal version of "WITH". Maybe MSElang will support this version too, not yet decided. > The Modula variant might reduce typing a bit, because the alias names can > be shorter, but it still requires explicit qualification of each > identifier, whereas the Pascal variant, while still stating each referred > object instance, completely does away with qualification where the > reference is unique and still allows for explicit resolution if conflicts > can occur. > You probably know what the problem with the Pascal variant is, don't you?. IIRC you even wrote about it: " > Alternatively, you might consider to do > away with "WITH", as some even say they consider it harmful. " The problem is that if there are members added to the referenced "with" container they override elements with the same name and type in existing code. > > [...] > > > > > > It has the advantage that procedure and method names are aligned. > > > > More > > > > > > That _might_ be a disadvantage at times, as it might make reading the > > > source text more difficult. > > > > Please explain. > > Citing you in "<201706101259.59446.mse00...@gmail.com>": > > " > > proc test1(a: int32): flo64; > > proc test2(const a: string8); > > meth objty.test3(a: int32): flo64; > > meth objty.test4(const a: string8); > > meth ctest.test3(a: int32): flo64; > > meth ctest.test4(const a: string8); > > " > > It has the advantage that procedure and method names are aligned. More > > experiments are needed. > > It looks ugly. > " > You said. > That's not "it might make reading the source text more difficult". Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang Objects
On Tuesday 13 June 2017 17:27:41 Edson H wrote: > Ok. I understand what Martin does. I have implemented this syntax too, in > my compiler. > > > I just was asking for the keyword ELSIF, to avoid nested IF, for several > comparisons, but Martin prefers to have a lot of THEN ... END, nested. I > think the best way is to include ELSIF, to have a clear syntax (like > Modula-2): > > > IF ... THEN > > > ELSIF ... THEN > > > ELSIF ... THEN > > > END; > > > And that's how it's implemented in my compiler, so it's compatible with > MSElang, except that MSElang doesn't support ELSIF. > It can be added to MSElang too, not yet decided. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang Objects
On Tuesday 13 June 2017 22:29:21 Sieghard wrote: > Using this as a reference, a syntax like > > MethodType = object function (; > or > MethodVariable: object function (; > > might be considered. Yes, this is more typing. > (Perhaps abbreviate it with just usind a (leading) period? Like > ".function (;" Nay, too C-ish...) > What is wrong with "method" instead of "object function"? > > [Pascal-ish "with"] > > > The problem is that if there are members added to the referenced "with" > > container they override elements with the same name and type in existing > > code. > > Only if not explicitely qualified - you can always "break out" of the > current scope using qualifiers. For the current object, the qualifier > is always "self". And for elements outside of any object context, it is the > unit name. What's your problem then? and how should the Modula variant be > better in that respect? > Example: " unit widgets interface type pointty = record x,y: int32; end; cwidget = class() pos: pointty; end; " " unit test uses widgets; procedure test(); var widget: cwidget; left: int32; [...] with widget do pos.x:= left; end; " Now the author of the widget library adds a new property to "cwidget" " cwidget = class() pos: pointty; property left: int32 read pos.x write pos.x; end; " and brakes the functionality of your "test()" procedure. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] fpcflop benchmark
On Sunday 25 June 2017 14:56:52 Fred van Stappen wrote:
>
> - Would it be possible to compile fpc-code with mselang (would be the
> fpc-syntax compatible) ?
>
Yes, as long you use the subset used in MSEide+MSEgui, especially no macros
and no generics.
>
> - Do you have plan to make work some (needed) features that do not work
> with fpc ?
>
Sure.
> I will be happy if this (that does not work correctly with fpc) work with
> mselang :
>
>
>
> - {$I something.inc} and friends ---> the fpc compiler can not deal if
> something was changed in something.inc, need to re-build all.
>
Are you sure? I vaguely remember that I read somewhare that FPC tracks changed
include files.
> - {$UNITPATH ../../src} and friends ---> the fpc compiler can not deal
> if something was changed in UNITPATH, need to re-build all.
>
I don't know that option. Is it a good idea to define paths in source?
Martin
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] fpcflop benchmark
> Personally, I do not like ^, @ and friends. > > See that topic: > http://forum.lazarus.freepascal.org/index.php/topic,18928.msg107215.html > For me reference and dereference operations are operations like addition and substraction. For me " dest:= s1 + s1 - delta + p1^.a.b + p2^.r^; " is easier to read than " dest:= s1 plus s1 minus delta plus refptr(p1).a.b plus refptr(refptr(p2).r)); " Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] fpcflop benchmark
On Tuesday 27 June 2017 14:32:16 Fred van Stappen wrote: > > Other thing... > > In fpc, to initialize a variable: > > var > x : integer = -1 ; > y : integer = -1 ; > z: integer = -1 ; > > I would prefer: > > var > x, y, z : integer = -1 ; > MSElang probably will have no initializers for local variables. " var x, y, z : integer = -1 ; " actually is " var x, y, z : integer; begin x:= -1; y:= -1; z:= -1; " so I think it should be written in this style. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSEide fails to compile
On Thursday 29 June 2017 09:42:26 Julio Jiménez wrote: > Probably due latest changes in FPC, MSEide fails to compile. > > OS; Linux amd64 (Ubuntu 16:04) > FPC 3.0.3 r36616 (fixes_3_0 branch) > MSEide+MSEgui: git updated today > > Error: > Compiling ./lib/common/sysutils/mseprocess.pas > mseguiintf.pas(6249,26) Error: Incompatible types: got " procedure(TXIM;TXPointer;TXPointer);CDecl>" expected " type of procedure(PXIM;TXPointer;TXPointer);CDecl>" > mseguiintf.pas(6740,4) Fatal: There were 1 errors compiling module, > stopping Fatal: Compilation aborted > Please try again with git master 7b98483dd55859e1ca65d2b5eb95cd9b2893ba97. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
[MSEide-MSEgui-talk] MSElang: "forward" property fields and getters/setters?
Hi, MSElang object and class properties accept fields and getters/setters which are defined after the property. Rationale is that it is more convenient for object/class users to have the public interface on top. " type cbase = class()[virtual] destructor destroy() [virtual]; end; cexception = class(cbase) //default visibility is "public" constructor create(const message: string8); property message: string8 read fmessage write fmessage; protected fmessage: string8; end; " instead of " cexception = class(cbase) //default visibility is "public" protected fmessage: string8; public constructor create(const message: string8); property message: string8 read fmessage write fmessage; end; What do you think? Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Timage and FreeBSD 64 ?
On Saturday 08 July 2017 16:12:45 Fred van Stappen wrote: > Hello Martin. > > > A Timage filled with a jpg is not show with FreeBSD 64. > Please send a simple test program. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Timage and FreeBSD 64 ?
On Saturday 08 July 2017 21:46:08 Fred van Stappen wrote: > > Please send a simple test program. > > Code: https://github.com/fredvs/drumspract > It doesn't look simple. ;-) Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Timage and FreeBSD 64 ?
On 07/08/2017 10:55 PM, Fred van Stappen wrote: > > OK, see simple attachment. > Looks OK for me, see attachment. What is the bug? Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Timage and FreeBSD 64 ?
On Sunday 09 July 2017 16:51:05 Fred van Stappen wrote: > > What is the bug? > > See attachment. > Aha, it does not compile! Please try again with git master afc5b9485624448b85ce4bf8da6ecf0b6c7a273d, it has removed the dependency on "cuserid". Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Android & iOS
On Sunday 09 July 2017 18:05:29 Marcos Douglas B. Santos wrote: > Hi, > > Direct to the subject: > Can I create Apps for Android and iOS using MSEgui nowadays? > > I saw Martin's comment > https://forum.lazarus.freepascal.org/index.php/topic,31996.msg205787.html?P >HPSESSID=f3n3hkv8am2kh2ohvugg1v3p00#msg205787 and looks MSE isn't prepared > yet. > The situation has not changed. I don't need it myself and there is no sponsor. iOS is a closed environment, Apple tries with big effort and good results to lock out aliens. I don't know if Android is better in this regard. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Timage and FreeBSD 64 ?
On Saturday 08 July 2017 16:12:45 Fred van Stappen wrote: > > PS: If you want to learn to play drums-set in 4 lessons (each lesson = +- 3 > minutes), DrumsPract is for you: https://github.com/fredvs/drumspract . > Nice program! :-) A tip, if you like to automatically store the program state between sessions place a "tstatfile" from tab 'NoGui' on the form and select it in the "statfile" properties of the form and the edit widgets which should store their values. Please use "oncreate" instead of "oncreated" for "oncreateform", the statfile will be loaded after "oncreate" but before "oncreated". Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Timage and FreeBSD 64 ?
On Monday 10 July 2017 14:37:51 Fred van Stappen wrote: > > Huh, did you try the drum-machine ? If yes, is the synchro ok ? (I had > problems with uos on Windows 10 for fast synchro but it seems to be fixed > now using a endless muted input for each instrument.) > I don't know, sound never worked on Linux for me. I just tried it again on my current working machine, no success. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Timage and FreeBSD 64 ?
On Tuesday 11 July 2017 00:55:31 Fred van Stappen wrote: > > I don't know, sound never worked on Linux for me. > > > > I just tried it again on my current working machine, no success. > > Huh... and how do you test mse taudioout and tmidisource then ? > With another machine, so "never" actually should read "never without hassle". Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Hint on FreeBSD64 ?
On Wednesday 12 July 2017 21:20:17 Fred van Stappen wrote: > Hello Martin. > > I have a strange problem with hints and FreeBSD64. > > With one of my projects, with same code, the hints are ok for Linux32/64, > Win32/64 but for FreeBSD64, the hints are not show anymore ;-( > > After deep and heavy investigations, I found the guilty. > > It appends if a thread was created. > > thethread := TDummyThread.create(true); // ---> after this, no more > hints > Please try again with git master 7932ad6b03f248648d8ebc4d59e3f8cdfed6ee24. FreeBSD seems not to report signals to main thread poll() if there is a suspended thread. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Hint on FreeBSD64 ?
On Thursday 13 July 2017 16:11:26 Fred van Stappen wrote: > > infotitle.caption := 'Title: ' + AnsiToUtf8(uos_InputGetTagTitle(theplayer, > 0)); > > Maybe you have a idea how to show the good characters. > If you know that the pchar is encoded in utf-8: " infotitle.caption:= 'Title: ' + utf8tostringansi(ansistring(thepchar)); " utf8tostringansi() is in unit msestrings. If it is in system encoding: " infotitle.caption:= 'Title: ' + msestring(ansistring(thepchar)); " Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Hint on FreeBSD64 ?
On Friday 14 July 2017 00:38:08 Fred van Stappen wrote: > Hello. > > > infotitle.caption:= 'Title: ' + utf8tostringansi(ansistring(thepchar)); > > infotitle.caption:= 'Title: ' + msestring(ansistring(thepchar)); > > Sadly both still give strange characters. ;-( > What is the encoding of the pchar? What means "strange characters"? Can you provide a simple complete example? Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Hint on FreeBSD64 ?
On Friday 14 July 2017 14:04:04 Fred van Stappen wrote: > > PS: Your Thistoryedit is magic. > Did you notice that it can automatically save its state in a "tstatfile"? Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] TSlider and onmouseevent/onkeydown/onkeyup ?
On Friday 14 July 2017 18:21:16 Fred van Stappen wrote: > > Other thing... > > When manually changing the position of the slider, how to get the position > of the slider before to release the mouse-button ? > > I did try with Tslider.onchange but the position does not change until the > button is released. > All MSEgui editwidgets (including tslider) have the properties "onsetvalue", "ondataentered" and "onchange". "onsetvalue" will be called when the user enters a value. In case of tslider the signature is " procedure tmainfo.slidersetvalev(const sender: TObject; var avalue: realty; var accept: Boolean); " "avalue" is the new value, ".value" still has the old value. Here the new value can be changed by changing "avalue" or be rejected by setting "accept" to false. If the new value has been accepted will be set to the new value and "ondataentered" will be called. "ondataentered" has the signature " procedure tmainfo.sliderdatentev(const sender: TObject); " "onchange" will be called when the "value" changes. "onchange" has the signature " procedure tmainfo.sliderchangeev(const sender: TObject); " In order to trigger value settings before releasing the mouse button activate .scrollbar.options sbo_thumbtrack (default true). I do not like to publish mouse events because this events are used internally by tslider and are not intended to be used by the component users. For the the problem with the thread I would do " procedure tmainfo.threadexeev(const sender: tthreadcomp); var val1: realty; begin val1:= 0; while true do begin sleep(100); if sender.terminated then begin break; end; val1:= val1 + 0.01; if val1 > 1.001 then begin break; end; try application.lock(); if not tslider1.clicked then begin tslider1.value:= val1; end; finally application.unlock(); end; end; end; " Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] TSlider and onmouseevent/onkeydown/onkeyup ?
On Saturday 15 July 2017 18:38:28 Fred van Stappen wrote: > > In order to trigger value settings before releasing the mouse button > > activate .scrollbar.options sbo_thumbtrack (default true). > > Yep, perfect, I get exactly what I want, thanks. > > > For the the problem with the thread I would do > > Oooops, that is much more complicated than using: > "onmouseevent" + "onkeyup" + "onkeydown" with "Slider1.tag := 0 (or 1);". > You need to call application.lock()/unlock() or use another synchronizing mechanism while accessing main thread elements from a worker thread or there will be problems (most likely crashes) sooner or later. How do you protect gui resources in your code? " if not tslider1.clicked then begin " replaces your " procedure ASlider.onmousedown(sender: TObject); // idem for onkeydown begin ASlider.tag := 1; end; procedure ASlider.onmouseup(sender: TObject); // idem for onkeyup begin ASlider.tag := 0; end; and in the loop of the thread: ... if ASlider.tag = 0 then ASlider.position := somewhere; " why do you think it is "much more complicated"? your code has nine lines, mine only one and doesn't need event properties. The code I showed is a working example of a 0..1.0 loop in a thread in order to demonstrate "tslider1.clicked", > Also I use in a unit a fpc TThread (not a tthreadcomp), so your code is not > compatible... And where/when to use that procedure? > application.lock()/unlock() and .clicked can be used everywhere. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Some question about MSE thread...
On Sunday 16 July 2017 00:04:48 Fred van Stappen wrote: > Hello Martin > > Some question about MSE threads (tthreadcomp?)... > > Mainly how to convert fpc TThread into mse tthreadcomp... > > How do you convert this in mse code (+ some tips are welcome)? > > > TMSEthread = class(TThread) > TMSEthread = class(tthreadcomp) > ok > ? > tthreadcomp is a container of teventthread which can be placed in a form. In order to replace a FPC TThread one probably would use tmsethread or one of its descendants (tmutexthread -> tsemthread -> teventthread). tmutexthread has a mutex, tsemthread a semaphore and teventthread an event queue. > constructor TMSEthread.Create(CreateSuspended: boolean; > const StackSize: SizeUInt) > ? > constructor create(const athreadproc: threadprocty; const afreeonterminate: boolean = false; const astacksizekb: integer = 0); overload; virtual; > destructor Destroy; override > ? > destructor destroy; override; > procedure Execute; override > ? > function execute(thread: tmsethread): integer; virtual; > procedure DoTerminate; override > ? > Does not exist, there is tthreadcomp.onterminate and tthreadcomp.onterminated. > ... > > TMSEthread.Start > ? > tmsethread starts automatically, there is tthreadcomp.active. > TMSEthread.Queue > ? > application.postevent(). Often application.lock()/unlock() is more convenient. > TMSEthread.FreeOnTerminate := true > ? > tmsethread.freeonterminate:= true; > TMSEthread.Priority := tpTimeCritical > ? Not implemented. > ... > > About using MSEThreads outside a MSE project... > Is it possible? Not easy, it needs the MSE-infrastructure. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Some question about MSE thread...
On Monday 17 July 2017 01:45:03 Fred van Stappen wrote: > Hello Martin. > > OK, the conversion (seems) done. > There are no more errors, crashs nor warnings. > But there is no sound too. ;-( > > I do not catch what to do with the main-procedure-loop of the mse thread. > An example is here: https://gitlab.com/mseide-msegui/mseuniverse/tree/master/samples/thread/delayedstart Why do you need the delayed start? > > Other thing. > I use RTLEvent for pausing threads. > Does msethreads accept it ? > Probably. MSEgui also has " function sys_condcreate(out cond: condty): syserrorty; function sys_conddestroy(var cond: condty): syserrorty; function sys_condlock(var cond: condty): syserrorty; function sys_condunlock(var cond: condty): syserrorty; function sys_condsignal(var cond: condty): syserrorty; function sys_condbroadcast(var cond: condty): syserrorty; function sys_condwait(var cond: condty; timeoutusec: integer): syserrorty; //timeoutusec = 0 -> no timeout //sye_ok -> condition signaled //sye_timeout -> timeout //sye_cond -> error " or use a tsemthread which has " function semwait(const atimeoutus: integer = 0): boolean; function sempost: boolean; //true if not destroyed function semtrywait: boolean; function semcount: integer; " Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Some question about MSE thread...
On Monday 17 July 2017 07:30:45 Martin Schreiber wrote: > On Monday 17 July 2017 01:45:03 Fred van Stappen wrote: > > Hello Martin. > > > > OK, the conversion (seems) done. > > There are no more errors, crashs nor warnings. > > But there is no sound too. ;-( > > > > I do not catch what to do with the main-procedure-loop of the mse thread. > > An example is here: > https://gitlab.com/mseide-msegui/mseuniverse/tree/master/samples/thread/del needs MSEgui current git master version. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Some question about MSE thread...
On Monday 17 July 2017 14:38:15 Fred van Stappen wrote: > > An example is here: > > > > https://gitlab.com/mseide-msegui/mseuniverse/tree/master/samples/thread/d > >elayedstart > > Ha, ok sorry for previous mail. > > I will study it, write you later. > > I need a delayed thread because somethings must be done after creation of > the thread and the main-loop has to wait for this before begin. > Can't it been done in constructor of the thread? Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Some question about MSE thread...
On Monday 17 July 2017 14:44:32 Fred van Stappen wrote: > > Can't it been done in constructor of the thread? > > No. > Please explain, I am interested on the background. Maritn -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Some question about MSE thread...
On Monday 17 July 2017 23:03:42 Fred van Stappen wrote: > > > > Can't it been done in constructor of the thread? > > > > > >No. > > > > Please explain, I am interested on the background. > > Huh... > > After creating the thread, there are other things to do, like adding > input-output, setting dsp's, ... And before all that work is done, the main > loop-method has to wait before to run. Of course you may add condition in > the main-loop (like a "while notstarted do sleep(10)") or use a RTL pause > event. The idea is that one uses parameters of tmythread.create() or one has a main container object with the thread worker loop and where the tmsehread is a subobject like in tthreadcomp. The thread will be created after setting up the environment. The question is if you need the thread-id for further settings. I assume not. > But a published "run", like you did in your last commit (many thanks > for this) is much more easy. > "tmsethread.fstate" with its "ts_norun" flag has been placed in "private" by accident earlier. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Some question about MSE thread...
On Tuesday 18 July 2017 06:48:05 Martin Schreiber wrote: > > The idea is that one uses parameters of tmythread.create() or one has a > main container object with the thread worker loop and where the tmsehread > is a subobject like in tthreadcomp. The thread will be created after > setting up the environment. An example is here: https://gitlab.com/mseide-msegui/mseuniverse/tree/master/samples/thread/classwiththread Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Some question about MSE thread...
On Tuesday 18 July 2017 15:15:01 Fred van Stappen wrote: > >An example is here: > > https://gitlab.com/mseide-msegui/mseuniverse/tree/master/samples/thread/c > >lasswiththread > > Re-re hello Martin. > > > Aaargh, you make me full of doubt. > > If I understand ok, for you, uos_play() must be the creator of the thread ? > It can if you like the idea of the thread(s) as standard sub-object(s) of a sound class. But doing it in FPC-way as tmsethread descendant is OK too. > But, would it not be faster to create the thread paused before and at > os_play() only resume the thread (like uos does) ? > If that time matters waiting on a semaphore in the worker thread probably provides the least delay, yes. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Some question about MSE thread...
On Tuesday 18 July 2017 14:53:53 Fred van Stappen wrote: > >An example is here: > > > > https://gitlab.com/mseide-msegui/mseuniverse/tree/master/samples/thread/c > >lasswiththread > > Ha, ok, I see. > > Hum, what are the advantage to use a custom class with a thread inside and > all the objects part of the class vs a custom thread with all the objects > part of the thread ? > No need of a custom thread. ;-) The idea is that the custom class implements the whole functionality and can inherit from any class you want, it must not necessarily be a tmsethread. The thread itself is a standard sub-object like a stream or a list. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Some question about MSE thread...
On 07/19/2017 02:38 AM, Fred van Stappen wrote:
>
> It is about mse and memory leak.
> I do not find how to kill those memory leaks, it seems to me that all
> was freed before to close the mse application but I get this, how can I
> debug that ? (huh, it comes with the
> project https://github.com/fredvs/strumpract and I am sure that the
> leaks do not com from uos) :
>
Compiled with -ghl -O- -B the Output is
"
...
Call trace for block $77FEF860 size 144
$006A19DD line 2054 of uos_flat.pas
$004631FE line 670 of main.pas
$00465742 line 1107 of main.pas
$00667D7A line 1011 of
../../../mseide-msegui/lib/common/widgets/mseforms.pas
$0066811A line 1103 of
../../../mseide-msegui/lib/common/widgets/mseforms.pas
$004A182A line 6753 of
../../../mseide-msegui/lib/common/fpccompatibility/mclasses.pas
$004FD102 line 2269 of
../../../mseide-msegui/lib/common/kernel/mseclasses.pas
...
"
uos_flat.pas:2054 is
"
uosPlayers[PlayerIndex] := Tuos_Player.Create();
"
-> uosPlayers[] are not freed.
"
It works for me with
"
diff --git a/src/uos_flat.pas b/src/uos_flat.pas
index 18d0860..c73cd7b 100644
--- a/src/uos_flat.pas
+++ b/src/uos_flat.pas
@@ -1794,7 +1794,9 @@ begin
begin
uosPlayers[PlayerIndex].Stop() ;
{$IF DEFINED(mse)}
- uosPlayers[PlayerIndex] := nil;
+// uosPlayers[PlayerIndex] := nil;
+ freeandnil(uosPlayers[PlayerIndex]);
+
uosPlayersStat[PlayerIndex] := -1 ;
{$endif}
end;
"
"
diff --git a/src/uos.pas b/src/uos.pas
index 03d08d7..0699c54 100644
--- a/src/uos.pas
+++ b/src/uos.pas
@@ -7844,8 +7844,8 @@ begin
{$endif}
{$IF DEFINED(mse)}
- thethread.terminate();
- freeandnil(self);
+// thethread.terminate();
+// freeandnil(self); //the instance is still in use!
{$else}
FreeOnTerminate:=True;
terminate();
@@ -8424,7 +8424,14 @@ destructor Tuos_Player.Destroy;
var
x: cint32;
begin
-
+ {$ifdef mse}
+ if thethread <> nil then begin
+ thethread.terminate();
+ application.waitforthread(thethread);
+//calls unlockall()/relockall in order to avoid possible deadlock
+ thethread.destroy();
+ end;
+ {$endif}
if assigned(evPause) then RTLeventdestroy(evPause);
if length(StreamOut) > 0 then
"
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] mailing list confirmations emails?
On Wednesday 19 July 2017 10:05:43 Graeme Geldenhuys wrote: > Hi Martin, > > Is this something you triggered on the mailing list server? Spam? Or > something SourceForge does? I am subscribed to a few mailing lists from > SF.net, and the MSEide+MSEgui mailing list is the only one that sends me > these emails. I've received two in the last two weeks now. > AFAIK something what SourceForge does. I got them for all SourceForge mailinglists I registered some years ago. Don't forget to switch off all newsletter and the like they want to send you. ;-) Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] face.fade wow.
On Friday 21 July 2017 18:11:55 Fred van Stappen wrote: > Hello Martin. > > > I like the face.fade feature. (see attachment). > Looks good! :-) tface and tframe exist since more than 10 years BTW. ;-) A tip: define the color gradient in a "tfacecomp" and select the "tfacecomp"-component in the .template properties in order to centralize the face settings. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] face.fade wow.
On Friday 21 July 2017 19:10:58 Fred van Stappen wrote: > Do you have a "gallery of demos using mesgui" ? > > > We, mse users, could add our projects in this page to show what mse can do. > Please put them to MSEuniverse, maybe in a special section. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] face.fade wow.
On Friday 21 July 2017 18:49:29 Fred van Stappen wrote: > > tface and tframe exist since more than 10 years BTW. ;-) > > Huh, is it not time to show better what you can be done with mse ? > I do that also since more than 10 years. Most of the people ignore it, many are bugged out. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] face.fade wow.
On Saturday 22 July 2017 07:16:07 Martin Schreiber wrote: > On Friday 21 July 2017 18:49:29 Fred van Stappen wrote: > > > tface and tframe exist since more than 10 years BTW. ;-) > > > > Huh, is it not time to show better what you can be done with mse ? > > I do that also since more than 10 years. Most of the people ignore it, many > are bugged out. > There is also a section on msegui.com: http://msegui.com/?q=node/9 IIRC Patrick asked several times for contributions - zero result AFAIK. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] Screenshot of your MSE project.
On Saturday 22 July 2017 17:38:15 Fred van Stappen wrote: > Hello happy MSE users. > > > Could you, please, answer to this topic with a screenshot of your project? > > > It can be only part of the form, a widget that you have customized for > example. > > > This to show to the world what we have done with MSE gui. > > > Those images will be part of a new MSE gallery page. > The current gallery is here: http://wiki.freepascal.org/MSEide_&_MSEgui#Application_examples_and_screenshots Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
