Re: [fpc-pascal] Adding a array of float in ressource and use it ?
Am 04.03.2017 16:06 schrieb "fredvs" : > > Hello. > > Is it possible to add a array of float into ressource ? > > For example, there is myarray : array of cfloat. > > Is it possible to store that array myarray ressource and, when I want to use > it from ressource, I get also a array of float ? > > In wiki : http://wiki.freepascal.org/Lazarus_Resources tey speak only how to > add files into ressource. No, you can't. Resources are not intended for this. What are you trying to achieve? Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Adding a array of float in ressource and use it ?
Am 05.03.2017 18:33 schrieb "fredvs" : > > Hello. > > I have saved the buffer into file with a TFileStream. > > With lot of success for array of cint16 and cint32. > > But for array of cfloat --> much less success. Define "much less success". How are you writing the array and how are you reading it? > Could it be that TFileStream does accept only integers as data ? > If yes, a conversion would be needed ? One can write and read any blob of data with the stream classes if one knows what one is doing. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Adding a array of float in ressource and use it ?
Am 06.03.2017 13:42 schrieb "fredvs" : > > > I don't know. By all logic, it should not work either. > > Yes, it is I think too. > > Some more explanation: > > I use a "global" buffer of float to store data. > Those data can be int16, int32 or float32. > > For example, > > If data are integer (16 or 32 bit), I do: > > bufferfloat[x] := 127.0 ; (for int16) > > bufferfloat[x] := 2147483646.0; (for int32) > > If data are float 32 bit, I do: > > bufferfloat[x] := 0.2147483646 ; (for float32) > > So it seems to me Sizeof(bufferfloat[x]) is the same in the 3 cases (alway > sizeof(float)). Of course it's always the same size as it's an array of cfloat after all and no assignment will change that. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Adding a array of float in ressource and use it ?
On 06.03.2017 19:31, fredvs wrote:
>> Or, quite comically maybe: use a text file
>
> Or maybe, like in my second post, convert float32 ---> integer32
>
> for x := 0 to length(floatbuffer) -1 do
> begin
>floatbuffer[x] := round(floatbuffer[x] * 2147483647);
>if floatbuffer[x] > 2147483647 then floatbuffer[x] := 2147483647;
>if floatbuffer[x] < -2147483647 then floatbuffer[x] := -2147483647;
> end;
>
> And do the reverse when reading from the file ?
I don't know what you're doing wrong, but the following works:
=== code begin ===
program tfloatbuf;
{$mode objfpc}
uses
SysUtils, Classes, ctypes;
var
fbuf: array of cfloat;
i: LongInt;
fs: TFileStream;
begin
SetLength(fbuf, 42);
for i := Low(fbuf) to High(fbuf) do
fbuf[i] := 3.1415;
Writeln('Writing data to ', ParamStr(1));
fs := TFileStream.Create(ParamStr(1), fmOpenWrite or fmCreate);
try
fs.WriteBuffer(fbuf[0], Length(fbuf) * SizeOf(fbuf[0]));
finally
fs.Free;
end;
SetLength(fbuf, 0);
SetLength(fbuf, 42);
Writeln('Reading data from ', ParamStr(1));
fs := TFileStream.Create(ParamStr(1), fmOpenRead);
try
fs.ReadBuffer(fbuf[0], Length(fbuf) * SizeOf(fbuf[0]));
finally
fs.Free;
end;
for i := Low(fbuf) to High(fbuf) do
Writeln(fbuf[i]);
end.
=== code end ===
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Adding a array of float in ressource and use it ?
Am 06.03.2017 22:45 schrieb "fredvs" : > > > I don't know what you're doing wrong, but the following works: > > Huh, it is exactly what I (think to) do. > And re-reading hundred times my code does not see any difference. > > OK, I will re-read thousand times the code, maybe I will find what is wrong. Then try to minimize your code as much as possible and then show it here (an as small as possible compileable example that shows your problem). Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Adding a array of float in ressource and use it ?
Am 06.03.2017 23:57 schrieb "fredvs" :
>
> Re-hello.
>
> Ok, I do not find yet the guilty in my code, I will re-try a other day.
> By the way, your code is working perfectly Sven.
>
> Now, last part of the question: how to convert that file stored into
> ressource but without to write to the disk (only memory stream)?
>
> A TFileStream could be used but it needs a path.
> And in ressource there is no path to use in
> TFileStream.Create('/the/path/filename', fmOpenRead);
>
> What could be the solution ?
To access a file stored as a resource you need to use TResourceStream.
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Adding a array of float in ressource and use it ?
Am 07.03.2017 13:49 schrieb "fredvs" : > > > To access a file stored as a resource you need to use TResourceStream. > > Ho my Dog, I did not know this one. > More than perfect, many thanks Sven. > > PS: About array of float into TFileStream, after Googling a while, it s not > possible to do directly like fpc does for C compilers. > You need a conversion (like explained by Lukasz Sokol). > And it is the reason why I am (once again) very impressed by fpc. Huh? Of course you can do that rather similary in C as well. > Many thanks Sven for your help. > Do you agree if I add your name into the list of the "great contributors" of > uos (https://github.com/fredvs/uos) ? > I don't think that's necessary. I'm merely doing my "job"... Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Adding a array of float in ressource and use it ?
On 07.03.2017 16:30, fredvs wrote:
>>> Many thanks Sven for your help.
>>> Do you agree if I add your name into the list of the "great contributors"
>>> of
>>> uos (https://github.com/fredvs/uos) ?
>> I don't think that's necessary. I'm merely doing my "job"...
>
> OK, I understand. (But I ask it always when I get great help, it is a matter
> of conscience and respect.)
>
>>> Huh? Of course you can do that rather similary in C as well.
>> Indeed. You can do exactly the same. You can do this:
>
> Huh in C, in one shot, like fpc does, without conversion and working?
The following code reads the floatbuf.txt file that my Pascal example
code generated and correctly prints 3.141500 42 times:
=== code begin ===
#include
int main()
{
float* floatbuf;
FILE* file;
file = fopen("floatbuf.txt", "rb");
if (!file)
{
printf("Failed to open file\n");
return 1;
}
floatbuf = malloc(sizeof(float) * 42);
if (fread(floatbuf, sizeof(float), 42, file) != 42)
{
printf("Failed to read data\n");
fclose(file);
free(floatbuf);
return 1;
}
for (int i = 0; i < 42; i++)
printf("%f\n", (double)floatbuf[i]);
fclose(file);
free(floatbuf);
return 0;
}
=== code end ===
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Adding a array of float in ressource and use it ?
On 07.03.2017 22:39, fredvs wrote: > OK, Sven you win (and http://stackoverflow.com should follow fpc forum). > But you will not convince me that c does better than fpc, maybe equal but > surely not better. Despite me definitely favoring Object Pascal as well, I can't you have spreading incorrect information on C, can I? ;) Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Forward Generic Type Declaration Bug
Am 18.03.2017 19:20 schrieb "African Wild Dog" : > > Hello, > > Please confirm if this is a bug. > > When I try to compile the unit below I get the error: > > "generics_bug.pas(14,43) Fatal: Internal error 2012101001" > > It seems the compiler has bug when handling forward generics declaration. Forward declarations for generic types are not supported. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generics Bug
Am 18.03.2017 19:55 schrieb "African Wild Dog" :
>
> Hello,
>
>
> Please confirm this bug.
>
> The unit code bellow won't compile (fpc 3.0.2 - debian jessie amd64):
>
> "generics_bug.pas(17,48) Fatal: Syntax error, "," expected but "<" found"
>
> === CODE ===
>
> unit generics_bug;
>
> {$mode delphi}
>
> interface
>
> type
>
> TPair = record
> Key: TKey;
> Value: TValue;
> end;
>
> TEnumerator = class
> end;
>
> TGenericClass = class(TEnumerator>)
> end;
>
> implementation
>
> end.
>
> ===
Nested specializations are currently not supported though they *might* work
with 3.1.1.
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generics Bug
Am 18.03.2017 22:41 schrieb "Sven Barth" :
>
> Am 18.03.2017 19:55 schrieb "African Wild Dog" :
> >
> > Hello,
> >
> >
> > Please confirm this bug.
> >
> > The unit code bellow won't compile (fpc 3.0.2 - debian jessie amd64):
> >
> > "generics_bug.pas(17,48) Fatal: Syntax error, "," expected but "<"
found"
> >
> > === CODE ===
> >
> > unit generics_bug;
> >
> > {$mode delphi}
> >
> > interface
> >
> > type
> >
> > TPair = record
> > Key: TKey;
> > Value: TValue;
> > end;
> >
> > TEnumerator = class
> > end;
> >
> > TGenericClass = class(TEnumerator>)
> > end;
> >
> > implementation
> >
> > end.
> >
> > ===
>
> Nested specializations are currently not supported though they *might*
work with 3.1.1.
Note: "they" in the sense of "this specific case".
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Forward Generic Type Declaration Bug
Am 18.03.2017 23:27 schrieb "African Wild Dog" : > > 2017-03-18 18:40 GMT-03:00 Sven Barth via fpc-pascal < fpc-pascal@lists.freepascal.org>: >> >> Forward declarations for generic types are not supported. > > Are there plans for add suport for this in fpc 3.2? No, there are not. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Forward Generic Type Declaration Bug
Am 19.03.2017 00:02 schrieb "Bart" : > > On 3/18/17, Sven Barth via fpc-pascal wrote: > > > Forward declarations for generic types are not supported. > > But it should not give an internal error. With that I agree. Would you please check with 3.1.1 and if it's still the case there report a bug so that this isn't forgotten? Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Interface Inheritance Bug
Am 19.03.2017 05:07 schrieb "African Wild Dog" : > > Hello, > > Test env: debian jessie amd64 - fpc 3.0.2 > > It seems free pascal have a bug when handling interface inheritance using generics. > > When i try to compile the unit bellow, i get this error: > > "interface_bug.pas(41,44) Error: Incompatible types: got "TImplementor" expected "IParentInterface"" I think this will happen with non-generic interfaces as well. So please test with those and if possible also with 3.1.1 and report a bug if necessary (preferable with a non-generic example, makes things easier to debug ;) ). Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] rtl-generics vs fgl
Am 19.03.2017 10:10 schrieb "Graeme Geldenhuys" < mailingli...@geldenhuys.co.uk>: > > Hi, > > Sorry if this is a silly question, I didn't really follow Generics > discussions in the past. If the "rtl-generics" package a replacement for > the fgl unit? The fgl unit is more lightweight while rtl-generics might provide better performance. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Forward Generic Type Declaration Bug
Am 19.03.2017 11:30 schrieb "Bart" : > > On 3/19/17, Sven Barth via fpc-pascal wrote: > > >> But it should not give an internal error. > > > > With that I agree. Would you please check with 3.1.1 and if it's still the > > case there report a bug so that this isn't forgotten? > > A quick search in the bugtracker for this IE showed: > http://bugs.freepascal.org/view.php?id=26452 (Internal error > 2012101001 with forward template declaration). > It's the same issue I guess? Yes. Thank you for checking. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Interface Inheritance Bug
Am 19.03.2017 17:55 schrieb "African Wild Dog" : > > 2017-03-19 5:25 GMT-03:00 Sven Barth via fpc-pascal < fpc-pascal@lists.freepascal.org>: >> >> I think this will happen with non-generic interfaces as well. So please test with those and if possible also with 3.1.1 and report a bug if necessary (preferable with a non-generic example, makes things easier to debug ;) ). > > > With non-generic types there is a workaround: cast to parent interface: > > ... > > ParentImplementorInstance := TImplementor.Create as IParentInterface; But without the cast you get the same error, yes? Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TypeInfo question
Am 23.03.2017 16:29 schrieb "Ryan Joseph" : > > I have some generics which operate on multiple types and instead of making subclasses for certain types and overriding methods I wonder if using the RTTI like: > > PTypeInfo(TypeInfo(T))^.kind = tkClass > > would be a good idea. How is TypeInfo() implemented exactly? I’m curious if there are any string comparing, allocating memory etc... that would adversely affect performance since these classes need to perform fast data lookups/insertions. TypeInfo() simply inserts the load of a pointer value, so there's not even a call. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delphi for Linux is out
Am 23.03.2017 13:05 schrieb "Graeme Geldenhuys" < mailingli...@geldenhuys.co.uk>: > > Hi, > > Just thought I would mention, yesterday Delphi 10.2 was released which > includes Linux support (I assume a cross-compiler). It is only available > in the Enterprise edition product line though, and only Linux Server > style apps are supported (no GUI/desktop apps). In the end you'll just need the correct units to do GUI applications as well though one would need to do everything by hand as there'd be no VCL or FM :P Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delphi for Linux is out
On 23.03.2017 18:35, Florian Klämpfl wrote: > Am 23.03.2017 um 16:47 schrieb Mattias Gaertner: >> On Thu, 23 Mar 2017 16:08:20 +0100 (CET) >> Michael Van Canneyt wrote: >> >>> [...] When did FPC start to run on Linux? 1999? >>> >>> I got the first "hello world" around 1995-1996, I think, >>> together with Mark May. (if memory serves well) >> >> Well, Delphi didn't start with a "Hello World". So that would be a >> little unfair as comparison. >> What about the time when FPC was able to compile itself? > > 9th august 1996 :) > > Mail from Michael: [...] >> I think we should synchronise our versions of the compiler. I've put a list >> of changes at the end of this mail, so you can update your sources. >> before you release the next version of the compiler, I think it would be >> nice if you send me the sources, so I can try to compile them under Linux. >> This way we can always keep the DOS and Linux version synchronised. I take it this was before a version control system was used? :P Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TypeInfo question
Am 24.03.2017 03:51 schrieb "Ryan Joseph" : > Is there anyway I could push the type checking to runtime? I wanted to using writeln also to perform some printing for debugging but I get stuck at compile time again trying to mix, integers, strings, records, classes etc… in the generic. I would use an interface but there are compiler types and records involved so that’s not an option. > > type > TLongIntMatrix = specialize TMatrix; > TObjectMatrix = specialize TMatrix; > > > function TMatrix.RetainValue (value: T): T; > begin > if typeKind = tkClass then > TObject(value).Retain; > > result := value; > end; > You could try to do it with a pointer: PObject(@value)^.Retain; Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delphi RTTI vs Free Pascal RTTI
Am 24.03.2017 19:55 schrieb "Michael Van Canneyt" : > > > > On Fri, 24 Mar 2017, African Wild Dog wrote: > >> Hello, >> >> I need to write a code compatilble with both free pascal and delphi using >> the old style RTTI. >> What are the diferences between delphi's and free pascal's approach/types? >> >> I took a look at delphi's and fpc's TypInfo unit and it looks like the >> types/functions are compatible. > > > They are. There is one dereference on Delphi which is not present in fpc, > although in fpc trunk, this additional dereference is there. If you use the > standard functions you should not notice this. The binary data of RTTI added before 3.1.1 now has the double indirection, but the Delphi-compatible "field" names have only a single indirection for backwards compatibility (they are properties to the double indirection fields). RTTI data added in 3.1.1 only has the double indirection. So this difference needs to be kept in mind and will always result in ifdefs for RTTI code that handles both Delphi and FPC. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Questions About Constructors
Am 31.03.2017 19:27 schrieb "African Wild Dog" : > > 2017-03-30 4:25 GMT-03:00 Michael Van Canneyt : >> >> >> >> On Thu, 30 Mar 2017, African Wild Dog wrote: >> >>> Hello, >>> >>> 1 - What happens if my constructor raise an exception? Is my destructor >>> automatically called? >> >> >> Yes. >> >>> >>> 2 - Are the class fields automatically initialized to Default(T) just like >>> in Delphi? >> >> >> Yes. The're zeroed out when the memory for the class is allocated. >> > > Thanks for the clarification. > I've issued #0031619 to add these details in the documentation. Keep in mind however that the second behavior can be changed by overriding TObject.NewInstance (the default implementation allocates the memory of the class and zeroes it). Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Array clearing
Am 01.04.2017 05:42 schrieb "Ryan Joseph" : > > As far as the compiler is concerned what’s the difference between clearing an array using a for-loop vs. FillChar? It seems like iterating the array would be slower but what does FillChar do exactly and is it faster? The primary concern here is that the memory originally allocated (using SetLength right?) remains in the same location. > > var > list: array of integer; > > SetLength(list, 10); > > for i := 0 to high(list) do > list[i] := 0; > > FillChar(list[0], Length(list) * sizeof(integer), 0); It totally depends on the type. In case of primitive types like integers there is indeed only the performance difference (though if you know that the element size is four FillDWord could be even faster, depending on the implementation in the RTL). If you have managed types however or class instances the result of the FillChar (or equivalent) would be memory leaks. Plase also note that after a SetLength the new elements are already 0 (or equivalent). Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Setting record values
Am 01.04.2017 05:59 schrieb "Ryan Joseph" : > > I’ve been using a design pattern in my code which I think is probably pretty stupid so I’d like to make sure. Assume I have a type like TPoint below and I want to set the value I’ll doing something like point := PointMake(x, y). How does the compiler handle this? It probably has to allocate some memory on the heap so shouldn’t I always be setting values using the alternative TPoint.SetPoint? It’s maybe not a big deal but it’s something I’d like to clear up if it’s inefficient. Records are only located on the stack (or in case of global variables the data sections). If you want them on the heap then you'd need to explicitly do that using pointers. > function PointMake (_x, _y: integer): TPoint; > begin > result.x := _x; > result.y := _y; > end; > > procedure TPoint.SetPoint (_x, _y: integer); > begin > x := _x; > y := _y; > end; > > same outcome but which is more efficient? I haven't looked at it in detail, but it could be that both have similar efficiency. You could also add "inline" to the MakePoint function which should get rid of a potential temporary variable if the compiler doesn't do that already anyway. Alternatively you could also declare a constructor "TPoint.Make" or so (that despite its name doesn't do any dynamic memory allocation either) which you can declare as inline as well. In the end you can always check the assembler code. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Array clearing
Am 01.04.2017 10:35 schrieb "Ryan Joseph" : > > > > On Apr 1, 2017, at 2:50 PM, Ryan Joseph wrote: > > > > Yeah, I was concerned with just compiler types or weakly retained classes where I’m just keeping the reference. > > Another question. Is it more efficient/faster to reallocate a new array of the same size or call FillChar on the existing array? I think that FillChar should be faster as reallocating would need setting the array to Nil and recreating it (SetLength with the same length won't touch the existing elements) thus loosing any gain of reallocate and then there'd still be the internal FillChar of the array. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Array clearing
Am 01.04.2017 13:31 schrieb "Jürgen Hestermann" : > > I am wondering what the purpose of filling all > array elements with zero's could be. > If I want to discard all elements I would simply delete > the whole array (setlength(MyArray,0) ). > > But when should it be useful to keep all elements and > just overwrite them all with zero's (which is also very time consuming)? > If the exisiting values are no longer valid then why not > simply delete these elements? > It's the fastest way to get rid of them. > If elements were zero before overwriting them with zero's > I cannot even distinguish between original and overwritten elements. > If you wouldn't change the size of the array then merely doing FillChar (if not working with managed types) is more performant then freeing the array and allocating it again (which will also zero out the elements). Normally the performance difference isn't *that* important, but sometimes that difference can make or break something. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Setting record values
On 01.04.2017 09:59, Ryan Joseph wrote:
>
>> On Apr 1, 2017, at 2:46 PM, Sven Barth via fpc-pascal
>> wrote:
>>
>> I haven't looked at it in detail, but it could be that both have similar
>> efficiency. You could also add "inline" to the MakePoint function which
>> should get rid of a potential temporary variable if the compiler doesn't do
>> that already anyway.
>> Alternatively you could also declare a constructor "TPoint.Make" or so (that
>> despite its name doesn't do any dynamic memory allocation either) which you
>> can declare as inline as well.
>
> How is the constructor any different from the function?
In case of constructor vs. global function the encapsulation is more clear.
In case of constructor vs. class function there isn't really that much
difference except that through the name alone ("constructor blabla")
it's clear what the purpose of the function should be.
(Though I now also noticed that you can't use "inline" with constructors...)
>>
>> In the end you can always check the assembler code.
>
> Not sure how to do that or what to look for. It appears to me without knowing
> how the compiler works that there would be some allocating and copying of
> memory which is more overhead than assigning a value directly. Maybe it’s
> totally trivial but if it is it’s something I should cut out of my design
> going forward.
The compiler keeps the assembler code with line information around if
you pass "-al".
If you are so concerned about the differences in performance regarding
using a setter and a construction function you should really learn at
least in principle how typical assembler code generated by the compiler
looks like (same for your query about dynamic arrays by the way, though
there you should also take a look at the implementation of the RTL).
Here is an example compiled without optimizations aside from inline:
=== code begin ===
# [47] p.&Set(42, 21);
movq$U_$P$TRECFUNCS_$$_P,%rax
movl$21,%edx
movl$42,%esi
movq%rax,%rdi
callP$TRECFUNCS$_$TPOINT_$__$$_SET$LONGINT$LONGINT
# [48] p := TPoint.Make(42, 21);
leaq-8(%rbp),%rdi
movl$21,%edx
movl$42,%esi
callP$TRECFUNCS$_$TPOINT_$__$$_MAKE$LONGINT$LONGINT$$TPOINT
movq-8(%rbp),%rax
movq%rax,U_$P$TRECFUNCS_$$_P
# [49] p := TPoint.Make2(42, 21);
movl$42,U_$P$TRECFUNCS_$$_P
movl$21,U_$P$TRECFUNCS_$$_P+4
# [50] p := MakePoint(42, 21);
movl$21,%esi
movl$42,%edi
callP$TRECFUNCS_$$_MAKEPOINT$LONGINT$LONGINT$$TPOINT
movq%rax,U_$P$TRECFUNCS_$$_P
# [51] p := MakePoint2(42, 21);
movl$42,U_$P$TRECFUNCS_$$_P
movl$21,U_$P$TRECFUNCS_$$_P+4
=== code end ===
"&Set" is essentially your "SetPoint" method. "Make" is a constructor.
"Make2" is a static class function with "inline". "MakePoint" is your
creation function and "MakePoint2" is the same with an inline modifier.
As you can see the two inline variants ("Make2" and "MakePoint2") are
the most effective as there's no call and only the two loads of the values.
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Array clearing
On 02.04.2017 11:22, Ryan Joseph wrote: > >> On Apr 1, 2017, at 9:25 PM, Jürgen Hestermann >> wrote: >> >> If you just need to reuse the same array and only need to zero its elements >> then of course fillchar would be the fastest approach (it saves the memory >> reallocation step). > > Why is this “of course”? What’s the implementation of FillChar exactly? For > all I know it has to iterate over a range of bytes and this could be slower > than allocation of memory. Maybe some of the compiler people know these > details. The question is not about the implementation of FillChar. It's about reallocating a dynamic array as to reallocate it you'd need to do === code begin === SetLength(arr, 0); SetLength(arr, newlen); === code end === And that this is more complex than === code begin === FillChar(arr, SizeOf(arr[0]) * Length(arr), 0); === code end === can be easily seen by looking at the implementation of SetLength() in $fpcdir/rtl/inc/dynarr.inc, fpc_dynarray_setlength(). Especially since line 220 (at least in the current revision) contains a call to FillChar(), the whole ordeal can only be *more* complex than FillChar(). Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Array clearing
Am 04.04.2017 06:55 schrieb "Ryan Joseph" : > > > > On Apr 2, 2017, at 11:02 PM, Sven Barth via fpc-pascal < fpc-pascal@lists.freepascal.org> wrote: > > > > can be easily seen by looking at the implementation of SetLength() in > > $fpcdir/rtl/inc/dynarr.inc, fpc_dynarray_setlength(). > > Especially since line 220 (at least in the current revision) contains a > > call to FillChar(), the whole ordeal can only be *more* complex than > > FillChar(). > > That’s good to know about SetLength. > > Is it possible use FillChar on a multidimensional arrays? > > arr: array of array of array of integer. > SetLength(arr, 3, 3, 3); > FillChar(arr[0], (3*3*3)*sizeof(integer), false); > > I’m just getting crashes. That does only work with static arrays as dynamic arrays are in reality managed pointers, thus you override the pointers themselves with your FillChar. Not to mention that you're overwriting the memory behind the outermost array as that only has a size of Length(arr) * SizeOf(Pointer). Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Setting record values
Am 04.04.2017 05:25 schrieb "Ryan Joseph" : > > Thanks for the tips, I appreciate it. > > This is all pretty trivial but it’s kind of annoying that using an inline class function is more efficient than a constructor despite having identical functionality. It's tempting to remove the constructors now and replace them with inline functions but it seems like the compiler should be smarter and make this optimization for me. At least for classes and objects the constructor is a bit more complicated (especially the former ones), so that may be the reason that nothing is done there for record constructors either. I'll check whether I can at least get them to paricipate in auto inlining so that they would at least be automatically inlined at higher optimization levels. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Array clearing
Am 04.04.2017 12:52 schrieb "Mark Morgan Lloyd" < markmll.fpc-pas...@telemetry.co.uk>: > > On 02/04/17 10:00, Jonas Maebe wrote: > >> Allocating new memory via setlength also clears the memory (+ the >> overhead of allocating the memory). > > > Jonas, is it still the case that if SetLength() results in existing data being moved that the original- which might be e.g. an unencrypted password- isn't cleared? The reallocation is delegated to the memory manager, thus SetLength() can not know what is really done with the data area. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Array clearing
Am 04.04.2017 13:55 schrieb "Ryan Joseph" : > > > > On Apr 4, 2017, at 4:58 PM, Howard Page-Clark via fpc-pascal < fpc-pascal@lists.freepascal.org> wrote: > > > > You can always use FillChar and its kin on specific 'nested' arrays like this > > > > type > > TIntArray = array of Integer; > > TIntIntArray = array of TIntArray; > > TIntIntIntArray = array of TIntIntArray; > > > > procedure FillArray(const anArray: TIntIntIntArray; aValue: DWord); > > var > >x, y: integer; > > begin > >for x:=0 to High(anArray) do > > for y:=0 to High(anArray[x]) do > >FillDWord(anArray[x][y][0], Length(anArray[x][y]), aValue); > > end; > > Doesn’t iterating the array default the purpose of FillChar? The goal was the most efficient way clear the array with zero’s. Even if the array if nested 3 levels deep (anArray[x][y][z]) it should (I hope) be a contiguous block of memory that was allocated (correct me if I wrong please). > As I wrote that isn't the case. Each dynamic array is allocated independently (and thus you could also resize each subelement independently). If you want continuous memory areas you need to use static arrays or develop your own dynamic data structure that uses array properties. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Array clearing
On 04.04.2017 15:40, Ryan Joseph wrote: > >> On Apr 4, 2017, at 7:17 PM, Sven Barth via fpc-pascal >> wrote: >> >> If you want continuous memory areas you need to use static arrays or develop >> your own dynamic data structure that uses array properties. >> >> > > I’m glad I asked because of arrays of pointers is bad news for performance. > Does SetLength on a single level dynamic array not even allocate a continuous > block of memory? I could use GetMem and array[0..0] but it seems like dynamic > arrays should do basically that anyways if they’re not nested. SetLength() allocates a single block of memory, cause array access is ordinary pointer arithmetic. However if you have an array of array then the first array stores a pointer to each sub array. E.g. the following would be valid, too: === code begin === var arr: array of array of Integer; begin SetLength(arr, 10, 10); SetLength(arr[3], 5); arr[6] := Nil; SetLength(arr[8], 15); end. === code end === Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Array clearing
On 04.04.2017 15:40, Ryan Joseph wrote:
>
>> On Apr 4, 2017, at 7:17 PM, Sven Barth via fpc-pascal
>> wrote:
>>
>> If you want continuous memory areas you need to use static arrays or develop
>> your own dynamic data structure that uses array properties.
>>
>>
>
> I’m glad I asked because of arrays of pointers is bad news for performance.
> Does SetLength on a single level dynamic array not even allocate a continuous
> block of memory? I could use GetMem and array[0..0] but it seems like dynamic
> arrays should do basically that anyways if they’re not nested.
You could use something along these lines instead:
=== code begin ===
program tarrtest;
{$mode objfpc}
{$modeswitch advancedrecords}
type
generic TTwoDimArray = record
private
fData: array of T;
{ Note: Length1 and Length2 are not initialized by default, but you
could use trunk's management operators for that }
fLength1,
fLength2: LongInt;
function GetElement(Index1, Index2: LongInt): T; inline;
procedure SetElement(Index1, Index2: LongInt; aValue: T); inline;
public
{ using SetLength() would lead to us needing to use
"System.SetLength()" for the array which in turn would complain
about usage of the static symtable; that's a problem that yet
needs to be solved inside generics, for non-generics that would
work however }
procedure AdjustLength(aLength1, aLength2: LongInt);
property Length1: LongInt read fLength1;
property Length2: LongInt read fLength2;
property Element[Index1, Index2: LongInt]: T read GetElement write
SetElement; default;
end;
{ TTwoDimArray }
function TTwoDimArray.GetElement(Index1, Index2: LongInt): T;
begin
{ ToDo: Length check }
Result := fData[Index1 * fLength1 + Index2];
end;
procedure TTwoDimArray.SetElement(Index1, Index2: LongInt; aValue: T);
begin
{ ToDo: Length check }
fData[Index1 * fLength1 + Index2] := aValue;
end;
procedure TTwoDimArray.AdjustLength(aLength1, aLength2: LongInt);
begin
SetLength(fData, aLength1 * aLength2);
fLength1 := aLength1;
fLength2 := aLength2;
end;
var
arr: specialize TTwoDimArray;
i: LongInt;
begin
arr.AdjustLength(10, 5);
i := arr[3, 2];
arr[7, 1] := i;
end.
=== code end ===
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Array clearing
On 04.04.2017 16:54, Ryan Joseph wrote: > >> On Apr 4, 2017, at 9:46 PM, Sven Barth via fpc-pascal >> wrote: >> >> SetLength() allocates a single block of memory, cause array access is >> ordinary pointer arithmetic. However if you have an array of array then >> the first array stores a pointer to each sub array. >> >> E.g. the following would be valid, too: >> >> === code begin === >> >> var >> arr: array of array of Integer; >> begin >> SetLength(arr, 10, 10); > > “then the first array stores a pointer to each sub array.” > > Could you illustrate this is code? I don’t think I’m understanding this > exactly like it’s represented in memory. There’s only one “sub array” in this > 2x2 array so how does that look in memory? Let's look at a smaller array, let's say 3 x 4, then it would look like this: arr = @arr[0], @arr[1], @arr[2] arr[0] = 0, 0, 0, 0 arr[1] = 0, 0, 0, 0 arr[2] = 0, 0, 0, 0 Essentially you'd have four arrays, namely the outer array arr which basically contains pointers to the other arrays, and the inner arrays which are each three separate four element arrays. So all four of these arrays could reside at completely different locations of the heap. Is this clearer? Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Array clearing
On 04.04.2017 16:27, Ryan Joseph wrote: >>> Does SetLength on a single level dynamic array not even allocate a >>> continuous block of memory? >> >> Yes, it does (as explained in all the other mails). >> A (dynamic) array of integer will be allocated as a single block by >> SetLength. >> So if you only have one level of a dynamic array as in >> >> var MyArray : array of integer; >> >> then SetLength(MyArray,1000) will allocate a single block of 1000 integers. >> But with >> >> var MyArray : array of array of integer; >> >> SetLength(MyArray,1000); >> >> will allocate a single block of 1000 pointers (to an array of integer each). >> Then, SetLength(MyArray[0],1000) will allocate one (!) block of 1000 >> integers. >> SetLength(MyArray[1],1000) will allocate another block of 1000 integers and >> so on…. > > I was allocating using SetLength(MyArray, 3, 3, 3) for a 3x3x3 matrix for > example. Maybe it depends on the memory manager and the state of heap but if > you called early in the programs execution it should be allocate all that > memory in one block I would think. While your statement regarding allocation might be true you must not forget that a dynamic array consists of a meta data block (length, reference count) that is located directly in front of the data block. So even if the memory blocks would be allocated consecutively then there'd still be the meta data blocks inbetween. If you already know that your dynamic arrays only have a specific size (for matrices used in games that should usually be the case) then you're better off with using a static array: === code begin === type TMatrix = array[0..2, 0..2, 0..2] of LongInt; === code end === There you can use FillChar() as much as you want as that is indeed a single memory block containing 9 LongInt elements. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Array clearing
On 04.04.2017 16:27, Ryan Joseph wrote: >>> Does SetLength on a single level dynamic array not even allocate a >>> continuous block of memory? >> >> Yes, it does (as explained in all the other mails). >> A (dynamic) array of integer will be allocated as a single block by >> SetLength. >> So if you only have one level of a dynamic array as in >> >> var MyArray : array of integer; >> >> then SetLength(MyArray,1000) will allocate a single block of 1000 integers. >> But with >> >> var MyArray : array of array of integer; >> >> SetLength(MyArray,1000); >> >> will allocate a single block of 1000 pointers (to an array of integer each). >> Then, SetLength(MyArray[0],1000) will allocate one (!) block of 1000 >> integers. >> SetLength(MyArray[1],1000) will allocate another block of 1000 integers and >> so on…. > > I was allocating using SetLength(MyArray, 3, 3, 3) for a 3x3x3 matrix for > example. Maybe it depends on the memory manager and the state of heap but if > you called early in the programs execution it should be allocate all that > memory in one block I would think. Addendum: If you look at fpc_dynarray_setlength() again then you'll see at line 289 that it's calling itself recursively for nested arrays. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Out of scope method?
Am 06.04.2017 10:32 schrieb "Ryan Joseph" : > > Does it exist now or has it ever been discussed that a method in TObject could be called when an instance of an object goes out of scope? It’s common to clean up objects in a function body after the function exits and calling a method would be a nice way to handle this. I think c++ has such a feature but I never heard of it in Pascal. It's a difficult topic, cause in Object Pascal class instances are always on the heap while in C++ they might be on the stack as well. Thus a C++ compiler will insert calls to the destructor of such an object if it goes out of scope. In Object Pascal currently only reference counted interfaces and (new in trunk) records with management operators provide this feature. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Out of scope method?
Am 06.04.2017 11:58 schrieb "Ryan Joseph" : > > > > On Apr 6, 2017, at 4:26 PM, Sven Barth via fpc-pascal < fpc-pascal@lists.freepascal.org> wrote: > > > > It's a difficult topic, cause in Object Pascal class instances are always on the heap while in C++ they might be on the stack as well. Thus a C++ compiler will insert calls to the destructor of such an object if it goes out of scope. > > > > In Object Pascal currently only reference counted interfaces and (new in trunk) records with management operators provide this feature. > > I see, but since there is a reference to an instance on the stack wouldn’t it be trivial for the compiler to invoke a method on TObject descendants when they go out of scope? If it does it for compiler types like dynamic arrays I imagine it could do the same for classes. Arrays are reference counted, class instances are not. So if the compiler would blindly free the instance after it goes out of scope if might free something that another code part still uses. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Constants in generics
Am 09.04.2017 14:03 schrieb "Ryan Joseph" : > > > > On Apr 9, 2017, at 6:13 PM, Maciej Izak wrote: > > > > sure, but not directly. Try this: > > Thanks, that’s a seriously funky hack but it works. :) The only downside is you need to define types every time you need a different size. > > Is this a known feature request or anything on the to-do list for the compiler team? There’s no way to extend the functionality of static arrays in Pascal and this would accomplish that well. Constant parameters are definitely not planned for generics. Generics are already providing enough headaches as they are without adding that as well -.- Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] sqldb create/free lifetime of object
Am 12.04.2017 14:32 schrieb : > In a way, this is a form of garbage collection or RAII sort of. And reduces the obnoxious free's required in non garbage collected programming languages... So it's a nice feature/trick to have ownership. But at the same time you can think there is a memory leak since there is no create/free pair easily visible... > > So you train your eyes to look for ownership. > > And similarly, delphi gui widgets you throw onto a form, don't need to be freed yourself, even though the program created them - so in a way delphi TForm's gui widgets are also garbage collected, sort of. Again a nice feature/trick to avoid all the obnoxious free calls that bloat up the source code with line noise. Both are in fact using the same mechanism as you can put e.g. a TSQLTransaction on a form as well. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] WebAssembly Target
Am 12.04.2017 16:10 schrieb : > Why run webgl through javascript if you could just make something like a flash plugin object (like youtube videos) that plays opengl scenes using some native format similar to how flash uses SWF files, or whatever? Because the point is not to need some strange, obscure plugin that works only on a subset of the platforms the browser supports when the script engine of the browser is powerful enough to do it itself. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Array clearing
Am 12.04.2017 16:51 schrieb "Ryan Joseph" : > > > > On Apr 12, 2017, at 9:25 PM, Michael Van Canneyt wrote: > > > > Adding a pop/push requires compiler magic, and could be implemented; but the question is whether it is worth it, given the plethora of other > > options at your disposal. > > Why magic? It seems silly the operator += doesn’t exist or even a basic operation set like “add”, “remove”, “insert” that every array implementation in every language has. Aren’t those just function around the existing dynamic array implementation in the compiler? Delete() is already supported in trunk, Insert() and the +-operator (or Concat()) are on the near term ToDo list (mainly out of Delphi compatibility, though I definitely agree with their existence). Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Constants in generics
Am 12.04.2017 17:06 schrieb : > > On 2017-04-09 06:32, Ryan Joseph wrote: >>> >>> On Apr 9, 2017, at 6:13 PM, Maciej Izak wrote: >>> >>> sure, but not directly. Try this: >> >> >> Thanks, that’s a seriously funky hack but it works. :) The only >> downside is you need to define types every time you need a different >> size. >> >> Is this a known feature request or anything on the to-do list for the >> compiler team? There’s no way to extend the functionality of static >> arrays in Pascal and this would accomplish that well. >> > > The only way I can think of extending the functionality of a array is to put it into an old borland object (on the stack) but that may not be what you are looking for. Then you can give the array methods, effectively, possibly reinventing TStringList ;-) and that array can be fixed, dynamic, whatever. But as for generics, no, old borland style objects are not going to be generic - so this email of mine is likely completely and utterly irrelavent to your problem domain :-) > Generic TP-style objects are supported in FPC, but you can use advanced records (which allow methods as well as management operators) as well. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Array clearing
Am 13.04.2017 13:25 schrieb "MARCOU Gilles" : > > Regarding this code: > >> SetLength(Array,Length(Array)+1); >> Array[High(Array)] := … > > > as I understood from (http://wiki.freepascal.org/Dynamic_array), SetLength will create a copy of the array and free the memory of the shorter array. In this case, a lot of memory operations and copy operations are performed thus degrading the performances of the code. Then it would be unwise to use such strategy: better allocate the size of the array correctly at the beginning of the run, or resize the array by block, to decrease the frequency of such operation: > >> SetLength(Array,Length(Array)+N); > > > Can somebody confirm (or invalidate) this? SetLength() uses reallocation for the memory. So it *might* work without copying though that is not guaranteed. But in general it's recommended anyway not to do "SetLength(..., ... + 1)" loops as that will lead to fragmentation of the heap. Regards Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Array clearing
Am 13.04.2017 14:47 schrieb "Ryan Joseph" : > > > > On Apr 13, 2017, at 7:08 PM, Mattias Gaertner wrote: > > > >> as I understood from (http://wiki.freepascal.org/Dynamic_array< http://wiki.freepascal.org/Dynamic_array>), SetLength will create a copy of the array and free the memory of the shorter array. In this case, a lot of memory operations and copy operations are performed thus degrading the performances of the code. > > > > Correct. > > Why is it copying the array and freeing instead of resizing the existing block (realloc)? That sounds crazy but I don’t know how memory managers work. SetLength *does* use a reallocate for this, but since it doesn't give you any guarantee for its success as its the task of the memory manager to deal with this, it's easier to assume that the array is indeed copied. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Array clearing
Am 13.04.2017 18:06 schrieb "Ryan Joseph" : > > > > On Apr 13, 2017, at 10:29 PM, Sven Barth via fpc-pascal < fpc-pascal@lists.freepascal.org> wrote: > > > > SetLength *does* use a reallocate for this, but since it doesn't give you any guarantee for its success as its the task of the memory manager to deal with this, it's easier to assume that the array is indeed copied. > > > > So the real point here is that ReAllocMem will copy and allocate a new block if the old one can’t be resized, therefore this really isn’t about SetLength as much as the memory manager itself. Correct. And since the memory manager is changeable and might implement whatever behavior it wants nothing fixed can be done for this. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Threading vs Parallelism ?
Am 14.04.2017 09:23 schrieb "Michael Schnell" : > > On 12.04.2017 14:09, Lars wrote: >> >> If unix could just make processes even lighter weight or >> faster loading, I might avoid threads and just use processes... > > in Unix/Linux processes are not less "light" then threads. You can create a process by "fork". no "Loading" involved. it just creates the process. If you want to have the new process execute any code that is not shared with the you need to do another system call to replace the code with the new one. Moreover even if "loading" new code - in case another process already runs this file, no actual loading takes place, either, as the memory management just uses the code page already in RAM. > > This definitively is as light as it gets. A process definitely is less "light" than threads even on Unix systems: a process has its own address space (even if it shares all pages with its parent process) and also structures keeping track of the used resources (e.g. open file descriptors). A thread does not need all this as it always shares the same address space and the same resources. Why do you think the concept of threads was introduced in Unix? Early Unix systems only had processes. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Get value of PPChar ?
On 16.04.2017 16:58, fredvs wrote: > Hello. > > A C method is defined like this: > > MPG123_EXPORT int mpg123_icy(mpg123_handle *mh, char **icy_meta); > > and translated in Pascal with this: > > function mpg123_icy(mh: Tmpg123_handle; var icy_meta: PPChar): integer; > cdecl; This is wrong. "var" essentially results in a "char***". What you want is either function mpg123_icy(mh: Tmpg123_handle; icy_meta: PPChar): integer; cdecl; or function mpg123_icy(mh: Tmpg123_handle; var icy_meta: PChar): Integer; cdecl; And how you'll need to use it will depend upon the function's documentation: if the function will allocate the buffer then you simply need to pass in a PChar variable (second case) or a pointer to one (first case). If you need to allocate the buffer yourself then you first need to do a GetMem with an appropriate size before you do the same. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Get value of PPChar ?
On 16.04.2017 18:52, fredvs wrote:
> Free Pascal - General mailing list wrote
>> function mpg123_icy(mh: Tmpg123_handle; var icy_meta: PChar): Integer;
>> cdecl;
>
> Thanks for your answer.
>
> I did try with this but :
>
> res := mpg123_icy(mph,theicytag);
>
> if (res = 0) then writeln('resu = ' + inttostr(res)); // OK = 0
>
> if Assigned(theicytag) then writeln('theicytag = assigned')
> else writeln('theicytag NOT assigned') ; /// always theicytag NOT assigned
According to the code it also returns 0 with icy_meta being Nil if there
is no corresponding data:
https://github.com/georgi/mpg123/blob/master/src/libmpg123/libmpg123.c#L1384
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Get value of PPChar ?
Am 17.04.2017 00:47 schrieb "fredvs" : > > Free Pascal - General mailing list wrote > > According to the code it also returns 0 with icy_meta being Nil if there > > is no corresponding data: > > https://github.com/georgi/mpg123/blob/master/src/libmpg123/libmpg123.c#L1384 > > Ha, nice, you did find the only doc available : the source code (that > contains no comment, of course ;-) ) > > Yep, this would solve everything. > In fact solve nothing because the code was ok then ;-) No, your "var PPChar" was still wrong. It's either "var PChar" or "PPChar" and nothing else. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Coroutines and VirtualAlloc
Am 19.04.2017 06:35 schrieb "Ryan Joseph" : > > > > On Apr 19, 2017, at 2:34 AM, Daniel Gaspary wrote: > > > > Using SetJmp and LongJmp? > > > > I believe some months ago it was a discussion on the list on why this > > was not really the way to implement coroutines. > > > > Searching for longjmp/setjmp you can find the thread, I guess. > > I never heard of those functions and I did find a thread about them but it seemed inconslusive. Those functions simply store (setjmp) and restore (longjmp) register values (and setjmp also returns the value passed to longjmp if it had been reached by a longjmp). Nothing more, nothing less. So while the stack register while be changed, the contents on the stack will not. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Coroutines and VirtualAlloc
Am 19.04.2017 11:26 schrieb "Ryan Joseph" : > > > > On Apr 19, 2017, at 4:14 PM, Sven Barth via fpc-pascal < fpc-pascal@lists.freepascal.org> wrote: > > > > Those functions simply store (setjmp) and restore (longjmp) register values (and setjmp also returns the value passed to longjmp if it had been reached by a longjmp). Nothing more, nothing less. So while the stack register while be changed, the contents on the stack will not. > > Why doesn’t “i” in my example increment? The value keeps going back to 1 even after I used += 1 so its like the old copy of the stack before the jump got pushed back on top and it started over. I don’t understand how assembly works but I thought it would just start over and the state of the stack in that function would still be the same as before so I could keep adding 1 every pass. Ah, I didn't catch that earlier. Probably "i" is kept in a register due to optimization. You should check the generated assembler code to be sure. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Use a procedural type for declare a procedure\function
Am 20.04.2017 08:44 schrieb "Andrey M, Zubarev" : > > Hi All, > > Why can't use procedural type for declare a procedure\function? > Why ever allow the exact same signature? It's uncomfortable > Maybe it makes sense to introduce into the language such a possibility? No, that makes no sense. Function/procedures/methods are independent of of function/procedure/message types, maybe even declared indifferent units not related to each other and used together only in a third unit. Also it would be harder to see easily which parameters a routine takes as you'd need to check the corresponding type first. (And if you now say that an IDE can help with that, well 1) not everyone uses one and 2) the same could be said about your original problem) Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Can class function used in specialized class use intristic functions Low, High with generic type ?
Am 20.04.2017 13:02 schrieb "LacaK" : > > Hi *, > > I have some generic class: > > generic T2DNumericArray = object(specialize T2DArray) > public > class function Truncate(Value: double): T; inline; > ... > > In class function Truncate I want check if supplied Value is in range of T. > T will be always ordinal type (byte, integer) ... (I know this, but compiler does not of course) > > Can I use in : > > class function T2DNumericArray.Truncate(Value: double): T; > begin > if Value > High(T) then > Result := High(T) > else if Value < Low(T) then > Result := Low(T) > else > Result := Value; > end; > > I understand, that from compiler POV T can be any type, so High() and Low() can be invalid, but I wonder if there is any way how to solve this. The compiler will use dummy values while parsing the generic, but during specialization it will use the correct ones. Though it might be that you'd need 3.1.1 for it (dont know right now when I had fixed that). Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Can class function used in specialized class use intristic functions Low, High with generic type ?
Am 22.04.2017 08:18 schrieb "Cyrax" : > I think that this was the bug report and which you did fix back then : http://bugs.freepascal.org/view.php?id=28832> Indeed it is :) Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Record operator for assignment
Am 28.04.2017 06:06 schrieb "Ryan Joseph" : > > Instead of making constructors and doing busy work It would be nice if Free Pascal could let you assign records outside of type blocks like: > > rec := (x: 0; y: 0; z: 0); > > Why isn’t this possible btw? I saw some C++ code do this and it seems like an obvious solution that should have existed 20 years ago. The feature exists for type blocks so why not just enable it for other parts of code? It would introduce an ambiguity as "(x" could also complete to other expressions (e.g. "(x + y) * 2" or even merely "(x)"). Especially older Pascal compilers were geared towards the simplicity of the language and thus they didn't add it. For FPC it simply never came up. > I had another idea to make this a little simpler by using open arrays and operator overloading. The compiler doesn’t permit this however. Is it a bug, my code or just a limitation? > > > > > type > TMyRec = record > x, y, z: integer; > class operator Explicit(v: array of integer): TMyRec; > end; > > class operator TMyRec.Explicit(v: array of integer): TMyRec; > begin > result.x := v[0]; > result.y := v[1]; > result.z := v[2]; > end; > > > var > rec: TMyRec; > > rec := TMyRec([1, 2, 3]); // Illegal type conversion: "Set Of Byte" to "TMyRec" The compiler currently prefers to cast array constructors towards sets, especially if they contain values that could be expressed as a set. That will change once proper support for array constructors is added. Though I don't know whether this would work then ;) Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Record operator for assignment
On 28.04.2017 08:01, Ryan Joseph wrote: > >> On Apr 28, 2017, at 12:43 PM, Sven Barth via fpc-pascal >> wrote: >> >> It would introduce an ambiguity as "(x" could also complete to other >> expressions (e.g. "(x + y) * 2" or even merely "(x)"). Especially older >> Pascal compilers were geared towards the simplicity of the language and thus >> they didn't add it. For FPC it simply never came up. > > I never thought about it either until I saw some c++ code doing it. Despite > having overlooked it, it’s basically a built in record constructor that’s > been in the language since forever. First it was making functions that paired > with records and now it’s constructors and "advanced record syntax" when the > more obvious and simpler solution was there all along. Maybe I’m crazy > though. ;) > > You mean like: > > rec := (x: (x + y) * 2; y: 0; z: 0); No, I mean rec := (x + y) * 2; The compiler has to differentiate these two. > Why can’t everything between : and ; just be treated like a normal > assignment? “x” is already defined but it’s just a label and not part of the > assignment. And that's another point. The compiler does not know what "x", "y" and "z" are, cause it doesn't care about the left hand side of the assignment until *after* the right hand side is parsed (in a var/const section it knows the type; that's a different situation). So a different syntax would be needed that would allow the compiler to know that it's parsing a specific record type. >> >> The compiler currently prefers to cast array constructors towards sets, >> especially if they contain values that could be expressed as a set. That >> will change once proper support for array constructors is added. Though I >> don't know whether this would work then ;) > > Huh, that syntax works in constructors, just not in the operator overloading. > Anyways I guess I’ll just assume that’s not implemented behavior. Because in that case it knows that it's a parameter and handles that differently. A type conversion is a different case. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Record operator for assignment
Am 28.04.2017 09:23 schrieb "Ryan Joseph" :
>
>
> > On Apr 28, 2017, at 1:06 PM, Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> >
> > No, I mean
> >
> > rec := (x + y) * 2;
> >
> > The compiler has to differentiate these two.
>
> I see. It’s the parenthesis that are problematic. I guess the solution
would be curly brackets:
>
> rec := {x: 1; y: 2; z: 1}
Curly brackets are comments!
> or some magic function like writeln:
>
> rec := TMyRec(x: 1; y: 2; z: 1)
That could be a possibility as the compiler could then correctly handle the
field names, however it would have an ambiguity with typecasts until the
colon.
Though that would be solvable...
> rec := @(x: 1; y: 2; z: 1)
@ would be nonsense as that would denote a pointer.
> etc…
>
> Anyway it could be achieved that would be nice to have a built in
constructor for records on the language level.
>
Well, feel free to develop a patch, maybe it'll be accepted. I have other
fish to fry in the meantime.
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Record operator for assignment
Am 28.04.2017 14:09 schrieb "Mark Morgan Lloyd" < markmll.fpc-pas...@telemetry.co.uk>: > Is there any way that the length of an array being used for that sort of job can be defined by what's put into it, rather than having to be predefined? No, there is not. Though I already had the idea that such preinitialized dynamic arrays (because that's what they'd need to be for consistency) could be implemented. Alas that's another small point on my huge ToDo list... :/ Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Is there some disadvantages using mode Delphi?
Am 29.04.2017 22:19 schrieb "Marcos Douglas B. Santos" :
>
>
> On Sat, Apr 29, 2017 at 2:10 PM, Michael Van Canneyt <
mich...@freepascal.org> wrote:
>>
>>
>>> Hi,
>>>
>>> I would like to write some packages that should work in FPC and Delphi.
>>> I know that I will need to use {mode delphi} to do that.
>>>
>>> My ask is: Is there some disadvantages using this mode?
>>>
>>> I mean, is there something that we only can do in mode objfpc but not in
>>> mode delphi, or is it just about syntax?
>>
>>
>> It is not just about syntax. In ObjFPC mode, the compiler is more strict.
>> (for examlpe: no method parameter names that concide with properties of
the object)
>
> Hmm, right (in fact I like this feature).
> So, it is about syntax and strict.
>
> But is there something that I can't do with mode delphi but I can using
mode objfpc?
> Let me rephrase: Is there some (new cool) feature that only works in mode
objfpc?
The only thing comes to mind would be complex expressions containing inline
specializations of generics. Due to the Delphi modes not using the
"generic" and "specialize" keywords there is some disambigity that the
compiler is not yet able to handle (most of these cases can however be
worked around either by explicitly declaring the specializations as types
or breaking the expressions up into simpler ones).
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Is there some disadvantages using mode Delphi?
Am 29.04.2017 23:56 schrieb "Marcos Douglas B. Santos" :
>
> On Sat, Apr 29, 2017 at 5:23 PM, Marco van de Voort
wrote:
> >
> > In our previous episode, Marcos Douglas B. Santos said:
> > > I would like to write some packages that should work in FPC and
Delphi.
> > > I know that I will need to use {mode delphi} to do that.
> > >
> > > My ask is: Is there some disadvantages using this mode?
> > >
> > > I mean, is there something that we only can do in mode objfpc but not
in
> > > mode delphi, or is it just about syntax?
> >
> > Mostly syntax. Mode objfpc disambiguates a corner case for procedural
types
> > with an extra @ for assignment of procedural types, and a few other
> > tightenings.
> >
> > The proponents of mode objfpc make a big deal out of the differences,
but
> > IMHO it is mostly nitpicking. And worse unnecesarily incompatible
> > nitpicking.
>
> Good to know.
> I remembered something right now: Is there some problem when units
> mode objfpc have "communication" with units using mode delphi about
> Unicode?
>
> If I remember well, PChar and even String is different between these
> modes, right? The compiler will convert strings between them or this
> is not a problem? Even using LCL?
The default string type depends on two different things, namely the mode
and the H switch which is by default only set in the Delphi modes. H- means
that "String" is "ShortString". H+ means that "String" is "AnsiString" as
long as modeswitch UnicodeString is not set (which is for example the case
if the mode is DelphiUnicode). However since the latter isn't really
recommended yet anyway (since the RTL and especially its classes would
still mainly use String=AnsiString) you shouldn't really run into problems
there.
The same is true for (P)Char: only if modeswitch UnicodeString is set, then
it's an alias for (P)WideChar, otherwise it's an alias for (P)AnsiChar.
At least the conversions between the string types are handled by the
compiler, only PAnsiChar <=> PWideChar conversions you'd need to do
yourself, but the compiler would complain there anyway.
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Record operator for assignment
Am 04.05.2017 10:37 schrieb "Ryan Joseph" : > > > > On Apr 28, 2017, at 3:51 PM, Ryan Joseph wrote: > > > > I almost struck out there. ;) There’s at least a possibility for anyone interested. A few years ago I looked at the compiler source and decided it was beyond me to even understand the code base well enough to do anything. How do people get into this any ways? The learning curve is so steep it’s a miracle anyone is able to contribute. One starts with something simple and works one's way up. My first real compiler contribution were if I remember correctly class helpers. And at that time I knew next to nothing about the compiler and thus had to learn by doing and debugging. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Call for testing: array constructors
Hello together! Since revision 36105 FPC now supports the use of array constructors using the "[...]" syntax inside ordinary code blocks like Delphi does since - I think - XE8. And yes, even nested ones are supported (take a look at $fpcdir/tests/test/tarrconstr5.pp for a bit of inspiration). Considering that this changed how "[...]" is handled I'd like you all to test whether your existing code still works (especially if it's dealing with sets!) and to try this new feature to see if there are any problems that our testsuite doesn't cover yet. If you report bugs, then please attach the tag "array constructors". Have fun! :D Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Call for testing: array constructors
Am 05.05.2017 21:19 schrieb "Mark Morgan Lloyd" < markmll.fpc-pas...@telemetry.co.uk>: > > On 04/05/17 22:30, Sven Barth via fpc-pascal wrote: >> >> Hello together! >> Since revision 36105 FPC now supports the use of array constructorsusing the "[...]" syntax inside ordinary code blocks like Delphi doessince - I think - XE8. And yes, even nested ones are supported (take alook at $fpcdir/tests/test/tarrconstr5.pp for a bit of inspiration). >> Considering that this changed how "[...]" is handled I'd like you all totest whether your existing code still works (especially if it's dealingwith sets!) and to try this new feature to see if there are any problemsthat our testsuite doesn't cover yet. >> >> If you report bugs, then please attach the tag "array constructors". > > > Ah yes, /very/ nice :-) > > I append a chunk of fun code, which as it stands needs separate functions per rank (i.e. for 1 dimension, 2 dimensions and so on). Can these be rationalised using generics? Generics are only useful as long as you can use the same code for different types. E.g. if you replace the Writeln inside the loop for t1's print with Print(a[i]) then you could at least generalize the print functions. Operators however would need you to stuff them into a record as only then you could define generic operators that would work on that record type. Alse the code of your addition operators differs with the types so that would not help, at least not as is. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Call for testing: array constructors
Am 08.05.2017 16:34 schrieb "Mark Morgan Lloyd" < markmll.fpc-pas...@telemetry.co.uk>: > > On 04/05/17 22:30, Sven Barth via fpc-pascal wrote: >> >> Hello together! >> Since revision 36105 FPC now supports the use of array constructorsusing the "[...]" syntax inside ordinary code blocks like Delphi doessince - I think - XE8. And yes, even nested ones are supported (take alook at $fpcdir/tests/test/tarrconstr5.pp for a bit of inspiration). >> Considering that this changed how "[...]" is handled I'd like you all totest whether your existing code still works (especially if it's dealingwith sets!) and to try this new feature to see if there are any problemsthat our testsuite doesn't cover yet. >> >> If you report bugs, then please attach the tag "array constructors". > > > > Operators however would need you to stuff them into a record as only > > then you could define generic operators that would work on that > > record type. Alse the code of your addition operators differs with > > the types so that would not help, at least not as is. > > Thanks Sven. Am I correct in believing that operators are basically not handled by generics? They are handled in so far that operator overloads in records are respected as well if the operator was available at the time the generic was *declared* (cause that scope will be used at specialization time). I have plans to test a change in this, but I don't know yet whether it should make it into trunk... > Apart from that, the operations of getting stuff into arrays etc. appear to work well. Good to know. Any regressions with ordinary sets? Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Call for testing: array constructors
Am 08.05.2017 18:25 schrieb "Mattias Gaertner" : > > On Fri, 5 May 2017 00:06:25 +0200 > Sven Barth via fpc-pascal wrote: > > >[...] > > Since revision 36105 FPC now supports the use of array constructors > > using the "[...]" syntax inside ordinary code blocks like Delphi does > > since - I think - XE8. And yes, even nested ones are supported (take a > > look at $fpcdir/tests/test/tarrconstr5.pp for a bit of inspiration). > > Do they work the same in mode objfpc? Yes, there isn't any mode checking in place for them. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Call for testing: array constructors
Am 08.05.2017 22:14 schrieb "Jonas Maebe" : > > On 08/05/17 17:34, Sven Barth via fpc-pascal wrote: >> >> Good to know. Any regressions with ordinary sets? > > > There seems to be a problem with overload selection between dynamic and open arrays for empty array parameters: https://bugs.freepascal.org/view.php?id=31756 > Why am I not surprised? -.- Thanks. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Vehicle management
Am 11.05.2017 18:14 schrieb "Jon Foster" : > I should also throw out here that it would be *REALLY* nice, and even somewhat needful on the Android front, if FPC could interface directly with C++ libs and use their classes and objects. Besides Java, Google prefers to use C++ (for obvious reasons) and their supplied native code libraries are C++. If you look at Google's software architecture diagram they say they use FreeType2. But, even rooted, if you search the Android file system you won't find a FT2 lib anywhere. Digging through the AOSP source base it turns out that FT2 is statically linked into Skia. Skia is a C++ library used by Dalvik (and other places) to do the usual 2D text/graphics rendering. This acts much like AggPas, used by Graeme's AggCanvas. I did find it exports a limited set FT2 functions in standard C style. But it looks like, for full functionality, I'm going to have to bridge the C++ divide. > > Anyhow tips on the FPC->C++ front would be appreciated. I will probably search the list archives as I know this topic comes up repeatedly. I don't understand how ginormous an undertaking this might be but maybe I can contribute something on this front. I can't speak for other approaches to interface with C++ code, but patches to the compiler's cppclass support are definitely welcome :D It will never support everything there is in C++, but if we'd manage to interface with most library code that would be something... Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Vehicle management
On 11.05.2017 19:58, Jon Foster wrote: > > On 05/11/2017 09:37 AM, Sven Barth via fpc-pascal wrote: >> >> Am 11.05.2017 18:14 schrieb "Jon Foster" >> mailto:jon-li...@jfpossibilities.com>>: >> > Anyhow tips on the FPC->C++ front would be appreciated. I will >> probably search the list archives as I know this topic comes up >> repeatedly. I don't understand how ginormous an undertaking this might >> be but maybe I can contribute something on this front. >> >> I can't speak for other approaches to interface with C++ code, but >> patches to the compiler's cppclass support are definitely welcome :D >> It will never support everything there is in C++, but if we'd manage >> to interface with most library code that would be something... >> > @@ <- me being bug eyed > > cppclass?!?! Where? When? How? What? > > I still can't find any mention of C++ support in the FPC 3.0 doc PDFs. > I've just grepped the source and I see something... Still trying to > figure out what it means. But to put it more specifically: > > What support is there? > How is it used? > Where are the docs, if any? > When did it sneak in? (not really important, just curious) > It's rather old in fact though still in its infancy. Improving it a little bit was one of the first patches I had done for FPC (back in 2009 or so), though not much has happened since then. The only code of note is the tests that exist in $fpcdir/tests/test/cg/tcppcl*.pp Essentially only static methods of GCC C++ code are currently supported. The next step would be instantiation and the vtables. (Should you want to continue this topic I'd suggest a new thread in fpc-devel) Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC Graphics options?
On 11.05.2017 20:43, James Richters wrote: > I have a few console graphics applications that I originally wrote in > Turbo Pascal that I have been able to convert over to Free Pascal and > now have windows versions of these programs. I notice that unless I run > my program on a 3.5GHz machine or faster, the graphics are fairly > slow.By slow, I mean noticeably slower than they were on a Pentium > 233 DOS machine with Turbo Pascal. The intended computers for these > programs are simple inexpensive PCs with motherboard video, no dedicated > video cards, I think it should be possible for any modern computer to > severely out perform a Pentium 233 with a VGA card in it, so I’m not > sure what the issue is. I am just using the graph unit for windows, > and I wonder if there is a more efficient method of creating a full > screen graphics only application than to use the graph unit?I am > only looking for it to work under windows and the main issue I would > like to solve is the speed of drawing things on the screen like lines > and arcs. It would be nice if I am also able to get away from BGI fonts > and use True Type fonts instead. I don’t need 3D rendering or anything > so complicated, just to draw lines and arcs and maybe ellipses as well > as various text, and flood fill closed shapes with some solid color. > > > > Any Suggestions? You could try the units ptcgraph or sdlgraph as alternatives (both are part of FPC). Other than that you could try to investigate why the graphic unit is so slow on Windows... Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Vehicle management
Am 12.05.2017 11:10 schrieb "Mark Morgan Lloyd" < markmll.fpc-pas...@telemetry.co.uk>: > > On 05/11/2017 09:37 AM, Sven Barth via fpc-pascal wrote:>> Am 11.05.2017 > >> 18:14 schrieb "Jon Foster" >> <mailto:jon-li...@jfpossibilities.com>>:> > Anyhow tips on the FPC->C++ >> front would be appreciated. I will probably > search the list archives >> as I know this topic comes up repeatedly. I > don't understand how >> ginormous an undertaking this might be but maybe I > can contribute >> something on this front.>> I can't speak for other approaches to >> interface with C++ code, but > patches to the compiler's cppclass >> support are definitely welcome :D It > will never support everything >> there is in C++, but if we'd manage to > interface with most library >> code that would be something... > > > Apologies for bad threading here. Sven, can I just go off on a slight tangent before that part of the discussion adjourns to fpc-devel, since this is a user rather than a developer question. > > What's the current situation with FPC interface to the Subversion support libraries which I think is something you were looking at at one point? Nope, I never looked at the Subversion libraries. > In extremis, I suppose that it should be possible for a program written in FPC to use Lua as a shim when calling C++. Before that I'd say the Delphi support for the binding generator SWIG should be checked (at least I thought it already had some). Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC Graphics options?
Am 14.05.2017 23:18 schrieb : > > On 2017-05-11 18:57, Jon Foster wrote: >> >> On 05/11/2017 02:48 PM, Graeme Geldenhuys wrote: >>> >>> On 2017-05-11 19:43, James Richters wrote: Any Suggestions? >>> >>> >>> Speed: >>> In recent graphics work I've done, I've noticed that FPC is fantastic >>> at created cross-platform applications. But the generated binaries >>> are NOT fast at all - no matter how many compiler parameters and >>> artificial speed optimisations we tried to implement. Sloppy Java >>> code ended up 3x faster than the best I could get out of FPC >>> generated binaries. >>> >>> I'm not saying this is your performance problem (especially comparing >>> a 3Ghs PC vs a 233Mhz PC) - there certainly seems to be another >>> problem contributing to your speed issue. >> >> Wow, Graeme! That's harsh. One of the last set of benchmarks I did >> that focused on integer math and procedure call speed came out as >> follows: > > > I think he specifically meant graphics apps, not general apps While a raytracer is indeed a graphics app it's mainly about CPU computation in this case and not interfacing with the GPU like OpenGL does (of course one can write a raytracer to take advantage of the parallel architecture of a GPU, but that's bot the case in this specific example). Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC Graphics options?
Am 16.05.2017 02:46 schrieb "Nikolay Nikolov" : >> I also no longer have the 'graphwindow' handle variable so I had to comment out anything that was using it like >> >> SetWindowTextA(graphicwindow,graphwindowtext); >> And >> ShowWindow(graphwindow, SW_SHOW); >> So I just commented them out for now.I'm hoping there is a way to get around the graphwindow variable because I was using the above 2 functions and I don't know how else to determine the graphic window handle... but the performance gain and ease of implementation will make working out any other issues worth the effort. Any advice on how I can capture the graph window handle would be appreciated > > Unfortunately, you can't do that and it's actually the main reason why ptcgraph is fast. Even if you modify the ptcgraph source, so that you get the window handle, it would do you no good, because the window is created in a different thread and this means that you cannot draw to the window from your program's thread. In fact, all the ptcgraph drawing routines actually render to an internal software buffer and issue no winapi drawing calls at all. That's the reason ptcgraph is fast and the regular graph unit is slow - the winapi drawing routines are really the bottleneck in this case and not the speed of the code, generated by FPC. Hmm? But he only wants to change the tttle of the window. Even on Windows that should work from a different thread. However a platform independent SetWindowTitle() for ptcgraph would be rather useful I guess. Though I'd like to know why he needs ShowWindow()... Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC Graphics options?
Am 16.05.2017 16:10 schrieb "Jon Foster" : > There are only two software projects in the world that continue to impress me with each new release: the Linux Kernel and FPC, which amuses me since I remember the first version of FPC I saw. '99 I think it was. I laughed and moved on. I wish I had the time provide some concrete info on where Graeme's problem is because I'd really like to see FPC shine here too. But it will probably be a while before I can give it proper treatment. Now if only there'd be a publicly visible "like" functionality in e-mails :D Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Best way to check SimpleIPC for messages
Am 17.05.2017 07:08 schrieb : > > On 2017-05-15 04:36, Michael Schnell wrote: >> >> On 12.05.2017 16:37, Michael Van Canneyt wrote: >>> >>> >>> Check manually. What else is left ? There is no message queue, so no loop in which to check at regular basis. >>> >> For event processing in a not threaded project or in the main thread >> of a threaded project you at best use the Event Queue provided by some >> Infrastructure library (e.g. LCL or mse). IMHO, SimpleIPC might makes >> sense, if you don't want to use one of those. (mse and an enhanced >> NoGui LCL "Widget Type", I have done a working draft for, can provide >> a message queue even with no binding to a GUI Widget Set). >> > > Isn't that what the application onidle is for, a way to check messages using the application code in the LCL > > But a question is (sorry I am not familiar with "onidle"), what happens when the application is not idle, but sort of idle? What classifies an idle state? i.e. what if the cpu is at 3 percent consumption, or 55 percent, or 2 percent? What classifies an onidle? this documented somewhere? > Is onidle reliable or hit and miss where the app is not idle enough, in some cases? OnIdle() is called when there is no more event waiting in the widgetset's event queue, basically meaning that the application has nothing better to do anyway. It has nothing to do with CPU usage. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC Graphics options?
Am 17.05.2017 07:12 schrieb : > > On 2017-05-15 17:27, Graeme Geldenhuys wrote: >> >> On 2017-05-15 22:50, nore...@z505.com wrote: >>> >>> Graeme will need to clarify whether he was trying to be harsh on FPC >>> entirely, or just specifically in some areas.. :-) >> >> >> I'll try and clarify... I believe FPC generates slow (or slower than >> Delphi, GCC and Java) code no matter what. The saving grace is that >> you don't really notice it on normal event-based desktop applications. >> Writing a game is a whole different story. Games are way more >> sensitive to performance. >> >> Now the game I wrote, was a desktop GUI application. It was slow under >> Linux, FreeBSD and Windows. So the results were consistent, no matter >> what GUI API was used Be that fpGUI (via GDI), fpGUI (via X11) or >> LCL-GTK2. In all cases, game rendering was to a memory image, then >> once done, that memory image was bitblit to the Window Canvas. >> >> The Java and GCC versions did the same, but were faster. >> >> That's all I can say about. Make your own assumptions - read into it >> any conspiracy theories or what-not. ;-) At this point I don't really >> care, as I already moved on with that project, using OpenGL instead >> (both for Java and Object Pascal). >> > > But any game ends up using opengl anyway, doesnt' it? Sorry I'm not a big game programmer. Want to be, some day. No, OpenGL is not a given. E.g. on Windows you can use DirectX and depending on the demands of your game a TCanvas might be completely sufficient. Also Graeme was talking about a raytracer which is a completely different beast compared to OpenGL/DirectX/Vulkan. While a raytracer *might* use one of those APIs for output of the final image the main task is the calculation of said image and *that* is where Graeme said that FPC had problems. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC Graphics options?
Am 17.05.2017 07:15 schrieb : > > On 2017-05-16 09:10, Jon Foster wrote: > >> I think the key word in Graeme's complaint is "game". And I'm willing >> to bet that most of his envisioned gaming scenarios deal with a lot of >> floating point math and the more advanced math functions. A quick >> glance over his example code and I'm willing to bet that the "math" >> unit providing the sqrt(), cos(), sin() and others is the bottle neck. >> But that's just a knee-jerk reaction. Seems to me I read a while back >> that a ton of effort had not gone into them. >> > > Could those math routines just be written in assembly with a FastXXX unit? i.e. FastMM is a fast memory manager, so you could have a FastCRT, fastWhatever, FastMath... > > At one time the fpc system units or sysutils was written in a lot of assembly, then they changed it to more pascal so it was more readable for people like me who stay away from assembly :-) Not because assembly is bad or anything, I just like living in high level procedural land, instead of low level assembly machine land. It has nothing to do with readability. It's about portability instead as FPC supports many different CPUs all with their own assembly language and quirks. Though that stops no one from implementing platform specific routines which was done for some platforms (e.g. the x86 ones). Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC Graphics options?
Am 17.05.2017 07:18 schrieb : > > On 2017-05-15 17:37, James Richters wrote: >> >> I have managed to get ptcgraph and ptccrt to work with my program and >> I can report that there is an AMAZING increase in graphics >> performance! It is pretty much a drop in replacement and I did not >> change any compiler settings. I did have to make a few minor changes >> to get it to work, not enough to change the speed of anything. >> > > So it can't be an fpc problem, but a unit module problem that someone didn't spend time optimizing which has little to do with fpc but more to do with the way the units were written? > > Or is the ptcgraph/ptccrt in assembly code to avoid FPC mode objcfpc compilation and use assembly instead? Sorry I have not looked at it.. don't know. You don't need to look at the code you merely need to look at the mails that Nikolay has written in this thread. There he writes that the stock graph unit and the PTC graph unit both use different approaches to interact with the Windows API this allowing the latter not to have the same bottleneck as the former. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] List pre-defined defines
Am 18.05.2017 17:47 schrieb "Jon Foster" : > > On 05/18/2017 08:46 AM, Jon Foster wrote: >> >> >> On 05/17/2017 05:40 AM, Ewald wrote: >>> >>> On 16/05/17 23:53, Mattias Gaertner wrote: touch mytest fpc -vc mytest >>> >>> Perhaps a one-liner: >>> fpc -vc /dev/null >>> >>> ? >>> >>> Saves one the need to create a dummy file and remove it afterward ;-) >> >> I like it! >> > Although that won't work on windoze! ;-) > fpc -vc NUL ;) Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] List pre-defined defines
Am 18.05.2017 22:01 schrieb "Marco van de Voort" : > > In our previous episode, Sven Barth via fpc-pascal said: > > > > fpc -vc NUL > > > > But I assume that requires executing a shell? If I remember correctly it should not (though I could be wrong of course). Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC 64bit for windows
Am 19.05.2017 02:22 schrieb "James Richters" : > > Thank you for the explanation. I didn't really understand how to use the cross compiler. > > I have installed the cross compiler and tried to compile my program with > > ppcrossx64 program.pas > > but I get > PaStep.pas(3,98) Fatal: Can't find unit smtpsend used by PAStep > > Smtpsend is part of synapse... I was going to try to copy the library to the x86_64-win64 folder but then I thought, wait a minute, I will need the 64bit library to get this to work... but it looks to me like Synapse has only support for Win32. So maybe I'm out of luck with a 64bit version if I'm going to use Synapse, unless the cross compiler will take care of this for me? Anyone know about this? You'll need to compile synapse from source then using the cross compiler (I doubt that they don't support Win64). Btw: instead of calling "ppcross64.exe ..." you can also use "fpc -Px86_64 ..." Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC Graphics options?
Am 19.05.2017 03:30 schrieb "Ryan Joseph" : > > > > On May 19, 2017, at 3:48 AM, Florian Klämpfl wrote: > > > > Well, the reason are the linux calling conventions: there are no callee saved xmm registers. This > > means FPC does not use any single/double register variables. I have some prototype fixes in my local > > git mirror, but they are neither finished nor tested. > > Can you please explain how do calling conventions affect this? I failed to run this at all on my Mac but I’m not sure why and even more confused how this would decimate speeds like this. Even though FPC might use SSE for maths it will still use the x87 to transfer floating values to/from function, especially if they take Extended as parameter/result. I did a test by disabling Extended on Linux x64 trunk compiler and RTL and it tripled the framerate from ~3 to ~10. Additionally some internal functions are not yet available with sole SSE support (frac() indeed comes to mind). Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC 64bit for windows
Am 19.05.2017 13:54 schrieb "Lukasz Sokol" : > > On 19/05/17 11:15, Graeme Geldenhuys wrote: > > On 2017-05-19 00:38, Nikolay Nikolov wrote: > >> windows OS - there are simply no known issues with that under any > >> 64-bit windows version that I know of. snip... It won't work > >> from the IDE, though, but compiling your program from the command > >> line, when you want to build a 64-bit .exe shouldn't be hard. > > > > So you are contradicting your self a bit. No known problems, and then > > two paragraphs later... but there is this known problem with the IDE. > > ;-) > > > > > >> Because it is inferior, since it cannot build a 32-bit FPC. > > > > You don't have to build a 32-bit FPC because an official released > > installer exists. So this is no problem at all. But seeing as pretty > > much everything is moving (or already has moved) to 64-bit, why > > bother with 32-bit these days. [referring to desktop and server > > applications - not embedded devices] > > > > Is there a way for native 64bit application to load a 32bit library, > that then can talk to a 32bit USB driver ? > (on Windows) Drivers (at least kernel mode drivers) must be 64-bit on 64-bit Windows (and also basically every other system I'm aware of). However it's perfectly possible to talk with a 64-bit driver from a 32-bit application. And no, you can't load a 32-library from a 64-bit process. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC Graphics options?
Am 19.05.2017 13:32 schrieb "Graeme Geldenhuys" < mailingli...@geldenhuys.co.uk>: > > On 2017-05-19 12:11, Nikolay Nikolov wrote: >> >> In FPC, if you want to use SSE and >> avoid the x87 FPU, you have to compile with a specific compiler options >> and forfeit the option for your executable to run on non-SSE capable >> CPUs, because FPC generates native code. If you want to keep > > > All good and well... Yes, we tried compiling the demo with SSE3 explicitly enabled. No performance increase! What did happen though is that we got random crashes after a few seconds of the application running. You only compiled the program with SSE, but not the RTL. And to completely avoid the x87 FPU you additionally need to fiddle around with some defines/code inside the compiler as well. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC Graphics options?
Am 19.05.2017 12:51 schrieb "Mattias Gaertner" : > > On Fri, 19 May 2017 10:54:25 +0200 > Sven Barth via fpc-pascal wrote: > > >[...] > > Even though FPC might use SSE for maths it will still use the x87 to > > transfer floating values to/from function, especially if they take Extended > > as parameter/result. > > Can you elaborate on this? > I thought on x64 does not have extended, so extended is double. Only on Win64 cause Microsoft declared the x87 as deprecated there. All other x86_64 OSes can happily make use of it and thus Extended is 80bit there, thus resulting in the usage of the x87 instead of solely SSE. (Note: you can also enable the x87 for Win64 per define when building the compiler, but your mileage may vary...) > > > I did a test by disabling Extended on Linux x64 trunk compiler and RTL and > > it tripled the framerate from ~3 to ~10. > > And it works? Yes, why shouldn't it? :) Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC 64bit for windows
Am 19.05.2017 14:53 schrieb "Lukasz Sokol" : > > On 19/05/17 13:33, Sven Barth via fpc-pascal wrote: > > >>> You don't have to build a 32-bit FPC because an official > >>> released installer exists. So this is no problem at all. But > >>> seeing as pretty much everything is moving (or already has moved) > >>> to 64-bit, why bother with 32-bit these days. [referring to > >>> desktop and server applications - not embedded devices] > >>> > >> > >> Is there a way for native 64bit application to load a 32bit > >> library, that then can talk to a 32bit USB driver ? (on Windows) > > > > Drivers (at least kernel mode drivers) must be 64-bit on 64-bit > > Windows (and also basically every other system I'm aware of). However > > it's perfectly possible to talk with a 64-bit driver from a 32-bit > > application. And no, you can't load a 32-library from a 64-bit > > process. > > This one is not a kernel-mode (at least so I think because the same > installation succeeds both on 32bit XPSP3, and in recent Win10 64bit)... > > (it's the old old Microchip MCHPFUSB driver used e.g. with PIC18F4550, driver version 1.3; > it's probably not as much a 'driver' as a way to register the PID and VID with the system, > more or less; but the library interfacing it, is 32bit only) >From what I can see from their site version 1.3 is the first that supports 64-bit and it indeed includes a 64-bit driver (and a 32-bit one as well). Also if I understand that correctly the source and API information to access the driver is provided as well, so you could either compile the library for 64-bit or port it to FPC to solve this. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC Graphics options?
Am 19.05.2017 15:29 schrieb "Marco van de Voort" : > > In our previous episode, Sven Barth via fpc-pascal said: > > > > You only compiled the program with SSE, but not the RTL. And to completely > > avoid the x87 FPU you additionally need to fiddle around with some > > defines/code inside the compiler as well. > > Hmm. in addition to my earlier benchmarks, the RTL is compiled with full > optimization opts. (-Opcoreavx2 -Cfavx2 -Cpcoreavx2 -O4) > > I also tried -Oofastmath, but to no avail. (floor is still external, and > still double) Floor is not declared as inline and even the Trunc()/Frac() intrinsics it uses wouldn't be inlined as they're assembler routines and FPC as of now doesn't inline assembler routines. Also if it's Double then all is well. Extended (the 80-bit one) is the problematic case. What system are you testing on? Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC Graphics options?
Am 19.05.2017 16:39 schrieb "Karoly Balogh (Charlie/SGR)" < char...@scenergy.dfmk.hu>: > > Hi, > > On Fri, 19 May 2017, Reimar Grabowski wrote: > > > Final: The render function takes about 90%, the cast-to-int about 5%. No > > other interesting functions shown. So the missing time must be spent > > doing floating point math and branching (ifs), as that's all the render > > function does. > > Well, if I comment out the three additions where the ray is actually > traced and the tex := line, it's actually 60fps on my macbook. But > actually the real difference is made with the additions. If i comment out > everything, but those 3 (4 in fact) additions are in still there, it's > still slow. > > Which made me thinking. I think you can vectorize that quite easily, and > use some packed SIMD instruction, maybe that will make a difference. C/C++ > has some compiler intrinsics for that. I can't remember from the top of my > head if it's doable with FPC. Someone who feels like fiddling with this, > might want to try some assembly magic there, if it's possible somehow... I think Jeppe wanted to add vector support. Though the question here is whether one wants to optimize/detect this at the AST level and convert that to implicit vectors or at the CSE level. By the way: I think my commit today of a SSE Frac() implementation sped up the framerate by a third on Win64 compared to the one without it :D Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC Graphics options?
On 19.05.2017 19:22, Karoly Balogh (Charlie/SGR) wrote: > Hi, > > On Fri, 19 May 2017, Sven Barth via fpc-pascal wrote: > >> I think Jeppe wanted to add vector support. Though the question here is >> whether one wants to optimize/detect this at the AST level and convert >> that to implicit vectors or at the CSE level. > > I think the higher level you can do an optimization/simplification, the > higher you should do it. Otherwise the lower layers get really messy, as > they already are in some cases. Well, in general, we should up our > floating point game. For example if Nikolay's recent load-modify-store > optimization would work on floats, that would already a nice step forward > in this case. ;) (Sorry for my ignorance, if it already works, missed that > then.) I agree that we should improve that. Maybe we should also allow for more FPU type specific helper routines. Currently on i386 and x86_64 the x87 FPU will be used even if -CfsseX is given and only Single/Double are used, cause the compiler defaults to Extended. If SSE isn't used that might make sense, but for SSE we should fall back to Double if we're only dealing with double, IMHO (and analogous for Single). >> By the way: I think my commit today of a SSE Frac() implementation sped >> up the framerate by a third on Win64 compared to the one without it :D > > Cool, but shouldn't this be an inline node instead for real speed++...? ;) > I mean if Trunc() and Round() are... Ah, right, hadn't seen that we do indeed have an inline node implementation for x86. I should probably put that on the list then :D Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC Graphics options?
Am 19.05.2017 22:24 schrieb "Sven Barth" : > > On 19.05.2017 19:22, Karoly Balogh (Charlie/SGR) wrote: > > Hi, > > > > On Fri, 19 May 2017, Sven Barth via fpc-pascal wrote: > > > >> I think Jeppe wanted to add vector support. Though the question here is > >> whether one wants to optimize/detect this at the AST level and convert > >> that to implicit vectors or at the CSE level. > > > > I think the higher level you can do an optimization/simplification, the > > higher you should do it. Otherwise the lower layers get really messy, as > > they already are in some cases. Well, in general, we should up our > > floating point game. For example if Nikolay's recent load-modify-store > > optimization would work on floats, that would already a nice step forward > > in this case. ;) (Sorry for my ignorance, if it already works, missed that > > then.) > > I agree that we should improve that. Maybe we should also allow for more > FPU type specific helper routines. Currently on i386 and x86_64 the x87 > FPU will be used even if -CfsseX is given and only Single/Double are > used, cause the compiler defaults to Extended. If SSE isn't used that > might make sense, but for SSE we should fall back to Double if we're > only dealing with double, IMHO (and analogous for Single). And you might notice that I had written this before I had discovered the existence of the professorspecific inline nodes which I commented on below that, so forgot what I wrote here aside from the fact that we should indeed improve things regarding floating point ^^' Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC Graphics options?
On 20.05.2017 21:34, Jonas Maebe wrote: > There's at least one minor twist of the classic "C compiler evaluates > constant stuff at compile time": > 1) oy and oz are constant. The "floor" function is a standard C library > function, and hence C compilers know what it does and can evaluate it at > compile time. Therefore, the oy-floor(oy) and oz-floor(oz) expressions > are (equal) constants for C compilers. Would it help here if we'd declare suitable overloads for Floor() for the various floating point types instead of only the "Float" one, declare them as inline and have the inline nodes for Frac() and Trunc() handle constant values? At least if the compiler also recognizes that oy and oz are constant... Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] download mirror is missing
Am 25.05.2017 11:16 schrieb "Michael Van Canneyt" : > > > > On Thu, 25 May 2017, Mattias Gaertner wrote: > >> On Wed, 24 May 2017 22:24:51 +0200 (CEST) >> mar...@stack.nl (Marco van de Voort) wrote: >> >>> In our previous episode, Mattias Gaertner said: >>> > > https://www.freepascal.org/down/x86_64/linux-netherlands.var >>> > > 550 /pub/fpc/dist/3.0.2/x86_64-linux >>> Not missing, but wrong url. The dutch ftp mirror is of the form: >>> >>> ftp://freepascal.stack.nl/pub/mirrors/fpc/ >>> >>> The dutch mirror shows the right paths: >>> >>> http://freepascal.stack.nl/down/x86_64/linux-netherlands.html >>> >>> so it must be something in how the main site is updated. >> >> >> Who can update the download page? > > > I have regenerated it (I think). > > The website is created using Black Magic, it defies analysis. > It's an ill-advised attempt to create a multilingual site. > > The person who made it is no longer on the team, and his scripts are in tcl. > We'll need to clean it up once and for all. Create something like hugo > https://gohugo.io/overview/introduction/ Since you're currently the one of the team the most invested in web technologies, maybe you'd be the best choice to do this? :) Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Browser and exe
2017-05-25 15:14 GMT+02:00 Marcos Douglas B. Santos : > On Wed, May 24, 2017 at 4:23 PM, Graeme Geldenhuys > wrote: >>> 2. How did you garantee that others applications aren't being using >>> the same port as your application to avoind conflicts? >> >> >> I looked at the official IANA list of registered port numbers and chose a >> port number that hasn't been taken yet. >> >>http://www.iana.org/assignments/port-numbers >> >> Under FreeBSD you can review the /etc/services file. I believe Linux has >> something similar. Or simply use the URL above. > > Thanks for that link, I didn't know. > But I meant, how do you know if another app is already using a port > that you want to use? You'll get an error by the OS if someone is already listening on the port that you want to listen on yourself. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] download mirror is missing
2017-05-25 16:44 GMT+02:00 Marco van de Voort : >> The current system is confusing and completely un-understandable, it needs >> to go. >> >> The multi-language support has not been used in 15 years, so it is time to >> put it out of its misery... > > Please avoid non general skills (in FPC core, not the world) to > operate/maintain the system. > > In particular, avoid these languages: > https://www.destroyallsoftware.com/talks/wat I'd say if he decides to use JS he'd use it through pas2js :P Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] download mirror is missing
2017-05-25 17:05 GMT+02:00 Michael Van Canneyt : > > > On Thu, 25 May 2017, Marco van de Voort wrote: > >> In our previous episode, Michael Van Canneyt said: >>> >>> > Simply replacing the tcl bits would be enough. It seems a simple >>> > makefile >>> > generator app. >>> >>> No way. I'm going to get rid of everything. >> >> >> If you have the time, perfect. >> >>> The current system is confusing and completely un-understandable, it >>> needs to go. >>> >>> The multi-language support has not been used in 15 years, so it is time >>> to >>> put it out of its misery... >> >> >> Please avoid non general skills (in FPC core, not the world) to >> operate/maintain the system. > > > Nice link. > > But I'll simply revert it back to what it was before all the tcl. > A simple pascal program that uses a template to create the menu structure > and generate the download pages from the mirror list... I think "simple pascal program" definitely sounds like a general skill anyone on Core has :P Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] download mirror is missing
2017-05-25 17:22 GMT+02:00 Marco van de Voort : > In our previous episode, Sven Barth via fpc-pascal said: >> > >> > In particular, avoid these languages: >> > https://www.destroyallsoftware.com/talks/wat >> >> I'd say if he decides to use JS he'd use it through pas2js :P > > Javascript is dead: > > https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript > > Personally I like the delivery of this. It is just like a regular talk, with > all the absurdness and hyperbole, but he remains completely in character. Interesting talk. It got me to think about running a asm.js (or nowadays WebAssembly) on our company's OS... and here I wanted to do other things during my free day and the weekend :P But yeah, considering that the amount of transpilers to JS is increasing (I consider WebAssembly one as well) and Pas2JS is one after all as well I essentially do agree with the talk... (though avoiding the kernel kall overhead would probably mean to have the asm.js running in ring 0 as well and due to my work I've definitely come to like the advantages of a microkernel :/ ) Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why casting interface as Tobject will result in a different reference?
2017-05-26 11:08 GMT+02:00 Michael Van Canneyt : > > > On Fri, 26 May 2017, Dennis wrote: > >> I defined a generic TList //CORBA style interface >> >> var >>aInt : IMyInterface; >> aObj : TObject; >> begin >>aInt := MyList.Items[0]; >>aObj := aInt as TObject; >> >> writeln( IntToHex(LongWord(aInt),4)); >> >> writeln( IntToHex(LongWord(aObj),4)); //this will output a different >> Hex value from previous writeln >> >> >> //This is causing a problem to me because I later >> >> MyList.Remove(aObj as IMyInterface);//will fail because it is not the >> same as aInt and thus fail to locate the item to remove >> >> >> Am I missing some fundamental understanding of interface reference? > > > Why do you think the interface and the object are the same ? They are not. > An interface is just a bunch of method pointers, and an object has instance > data associated with it. Hardly the same thing, I would think ? The idea itself is valid, cause "(IMyInterfaceVar as TObject) as IMyInterface = IMyInterfaceVar" is true if and only if IMyInterface is a COM interface. If IMyInterface really is a CORBA interface as Dennis wrote then the compiler should already have complained at the "aObj := aInt as TObject" line as this type of conversion is *not* supported by CORBA interfaces (cause they don't provide QueryInterface() which is needed for this). At least for me the compiler *did* complain (both 3.0.2 and 3.1.1) when I tested this. So the question is: is IMyInterface indeed a CORBA interface? If so then why does the compiler not complain? If not then why doesn't it work? For both cases a full example would be needed to investigate this. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
