[fpc-pascal] Cmdline parser

[denisgolovan via fpc-pascal]

Hi all

Could anybody suggest some existing command line parser for FPC having 
following requirements:

1. Crossplatform with stable semantics - Linux/Windows.
2. Short and long values support.
3. Support for "generic parsing". I mean being able to parse from string any 
unknown set of args as logn as they conform to standard short/long grammar.
4. Must support "--" separator for splitting "rest" of command line for passing 
as one string further.
5. Support for quoted / escaped string values.
6. Having unit-tests :)
7. MPL/MIT license

I'd like to avoid creating another half-baked parser :)
Perhaps any existing parser willing to accept patches will do as well.

-- Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Barriers semantics

[denisgolovan via fpc-pascal]

> On 14/08/2023 18:19, denisgolovan via fpc-pascal wrote:
> 
>> Now we have "volatile" intrinsic for assignments in place, I'd like to ask 
>> for another clarification.
> 
> Just to make sure given your questions below: using volatile in the
> context of multithreaded code is completely wrong in 99.9% of the cases,
> and when it's not in the best case it's usually just highly inefficient.
> volatile in FPC/C++ is unrelated to volatile in Java or C# in that respect.

As long as volatile marks data access and but not field attribute - I am very 
much fine with it.
Let Java/C# devs suffer it :)

> 
>> Documentation states we have following barriers - ReadBarrier, WriteBarrier, 
>> ReadDependencyBarrier, ReadWriteBarrier.
>>
>> I'd like to get an idea how those related to more common / standard terms - 
>> Acquire/Release & their combinations?
> 
> Read/Write barriers are terms used in cpu architecture manuals.
> Acquire/Release are high level parallel programming terms.
> 
>> Is it safe to assume that:
>>
>> ReadBarrier - Acquire
>> WriteBarrier - Release
>> ReadWriteBarrier - Acquire+Release
>> ReadDependencyBarrier - which one is that?
> 
> You cannot express a ReadDependencyBarrier in terms of acquire/release.
> See e.g. the explanation of "data dependency barrier" at
> https://www.sobyte.net/post/2022-08/cpu-cache-and-memory-barriers/ . In
> practice, I don't think any currently used cpu architectures still
> require such barriers though.

Ok. I assume I got it right.
This field lacks common terms for some reason.

-- Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Barriers semantics

[denisgolovan via fpc-pascal]

Hi all

Now we have "volatile" intrinsic for assignments in place, I'd like to ask for 
another clarification.
Documentation states we have following barriers - ReadBarrier, WriteBarrier, 
ReadDependencyBarrier, ReadWriteBarrier.

I'd like to get an idea how those related to more common / standard terms - 
Acquire/Release & their combinations?
Is it safe to assume that:

ReadBarrier - Acquire
WriteBarrier - Release
ReadWriteBarrier - Acquire+Release 
ReadDependencyBarrier - which one is that?

-- Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Volatile store usage

[denisgolovan via fpc-pascal]

> On 11/08/2023 18:05, denisgolovan via fpc-pascal wrote:
> 
>> Are "volatile" stores supported?
> 
> They weren't, but I've added support for it now.

Aha.
Thanks.

-- Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Volatile store usage

[denisgolovan via fpc-pascal]

Hi all

I'd like to get some clarification about "volatile" intrinsic.

https://wiki.freepascal.org/FPC_New_Features_Trunk#Support_for_.22volatile.22_intrinsic
 says just following:

Support for "volatile" intrinsic
Overview: A volatile intrinsic has been added to indicate to the code 
generator that a particular load from or store to a memory location must not be 
removed.

... and states that example is here - 
https://gitlab.com/freepascal.org/fpc/source/-/blob/main/tests/test/tmt1.pp

However I cannot find "store" usage example there.
Only "load". 

Are "volatile" stores supported?
I tried following using my rather old 3.3.1 compiler, but none of them compile:

volatile(mem):=0;
mem:=volatile(0);


Any help?

-- Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Cache-line alignment for records

[denisgolovan via fpc-pascal]

> It is possible
> (https://gitlab.com/freepascal.org/fpc/source/-/blob/main/tests/test/talignrec1.pp),
> but it is subject to the same limitations when declaring variables of
> those types.
> 
> Jonas

Aha. Nice!
Does it work recursively? I mean - does it work when aligned record is itself a 
field within other record?

-- Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Cache-line alignment for records

[denisgolovan via fpc-pascal]

> However, the maximum alignment you can specify this way is limited per
> target (hardcoded in the compiler). In 3.2.x, it's 16 bytes for most
> desktop targets. On 3.3.x, it's 64 bytes for most desktop targets.
> 
> Jonas

But it's still not possible to attach alignment to type itself instead of 
variable, right?

-- Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Feature announcement: implicit generic function specializations

[denisgolovan via fpc-pascal]

> If you want to pass a pointer to ^T in a generic function is there anyway 
> safe to do this currently? Pascal doesn’t allow ^ types in function arguments 
> (why?) and generics don’t seems to support pointers either (why?).
> 
> generic TValues = array[0..0] of T;
> generic PValues = ^specialize TValues;
> 
> I guess the only thing to do is use a untyped pointer and cast it to the 
> correct type inside the function declaration?
> 
> For example here is a generic QuickSort function which operates on any array 
> of T.
> 
> type
> generic TComparator = function (left: T; right: T; context: pointer): 
> integer;
> 
> generic procedure QuickSort(_values: pointer; first, last: LongInt; 
> comparator: specialize TComparator);
> type
> TValues = array[0..0] of T;
> PValues = ^TValues;
> var
> pivot,j,i: integer;
> temp: T;
> values: PValues absolute _values;
> 
> Regards,
> Ryan Joseph
> 

Not that pretty, but I use something like:

==
generic TPtr = record
public
  type P = ^T;
public
  ptr: P;
  end;

generic function Ref(out r: specialize TPtr.P):boolean;
==

Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Feature announcement: implicit generic function specializations

[denisgolovan via fpc-pascal]

That seriously improves generic code readability. Definitely worth trying to upgrade. Thanks a lot! 20:15, 20 апреля 2022 г., "Sven Barth via fpc-pascal" :Dear FPC community,The FPC developers are pleased to announce the implementation of a new feature: implicit generic function specializations. This feature was implemented by Ryan Joseph, so thank you very much, Ryan.This feature allows you to use generic routines (functions, procedures, methods) without explicitely specializing them (“<…>” in Delphi modes and “specialize …<…>” in non-Delphi modes) as long as the compiler can determine the correct parameter types for the generic.This feature is enabled with the modeswitch ImplicitFunctionSpecialization and is for now not enabled by default as this has the potential to break existing code.Assume you have the following function:=== code begin ===generic function Add(aArg1, aArg2: T): T;begin   Result := aArg1 + aArg2;end;=== code end ===Up to now you could only use this function as follows:=== code begin ===SomeStr := specialize Add('Hello', 'World');SomeInt := specialize Add(2, 5);=== code end ===However with implicit function specializations enabled you can also use it as follows:=== code begin ===SomeStr := Add('Hello', 'World');SomeInt := Add(2, 5);=== code end ===The compiler will automatically determine the type of the generic parameters based on the parameters you pass in (this is always done left to right). Depending on the passed in parameters (especially if you're using constant values like in the example instead of variables) the compiler might however pick a different type than you expected. You can enforce a specific type by either explicitely specializing the method as before or by inserting a type cast. In the example above the compile will specialize the call with the parameters “2, 5” using an 8-bit signed type (Pascal prefers signed types) instead of a LongInt as in the explicit specialization. If you use “LongInt(2), 5” as parameters then the compiler will pick that instead, however with “2, LongInt(5)” it will still pick an 8-bit type, because the parameter types are determined left to right.If there exists a non-generic overload for which the parameters types match exactly, the compiler will pick that instead of specializing something anew. So assume you also have the following function in scope:=== code begin ===function Add(aArg1, aArg2: LongInt): LongInt;begin   Result := aArg1 + aArg2;end;=== code end ===In the case of “Add(2, 5)” the compiler will *not* pick the non-generic function, because it determines that an 8-bit type is enough, however if you use “Add(LongInt(2), 5)” the compiler will pick the non-generic function.Aside from simple parameters the compiler also supports arrays and function/method variables:=== code begin ===generic function ArrayFunc(aArg: specialize TArray): T;var   e: T;begin   Result := Default(T);   for e in aArg do Result := Result + e;end;type   generic TTest = function(aArg: T): T;generic function Apply(aFunc: specialize TTest; aArg: T): T;begin   Result := aFunc(aArg);end;function StrFunc(aArg: String): String;begin   Result := UpCase(aArg);end;function NegFunc(aArg: LongInt): LongInt;begin   Result := - aArg;end;begin   Writeln(ArrayFunc([1, 2, 3])); // will write 6   Writeln(ArrayFunc(['Hello', 'FPC', 'World'])); // will write HelloFPCWorld   Writeln(Apply(@StrFunc, 'Foobar')); // will write FOOBAR   Writeln(Apply(@NegFunc, 42)); // will write -42end.=== code end ===There are of course a few restrictions for this feature:- all generic parameters must be used in the declaration of the routine (implementation only type parameters are not allowed)- all parameters that have a generic type must not be default parameters, they need to be used in the call or their type must have been fixed by a parameter further left (as currently default values for parameters of a generic type are not supported this is not much of a restriction, but should that change (e.g. Default(T)) then this restriction will apply)- the generic routine must not have constant generic parameters (this might be extended in the future with e.g. static arrays or file types, but for now this restriction stands)- the result type is not taken into account, so if only the result type of a routine is generic then an implicit specialization does not work either- function/method pointers to implicit specializations are not yet supported (pointers to explicit specializations are not yet supported either; once this changes the former will change as well)- the compiler will silently discard generic functions that it can't specialize the *declaration* of; however if the declaration can be specialized correctly, but for whatever reason the *implementation* can not then this will trigger a compilation errorThis feature is by and in itself Delphi compatible however there might be differences in what FPC can implicitely specialize and what Delphi can. Especially if Delphi can specialize something 

Re: [fpc-pascal] Compiler internals. Changing dynamic arrays format

[denisgolovan via fpc-pascal]

> On 2022-04-13 00:34, denisgolovan via fpc-pascal wrote:

> Your comment about conditional defines goes in the right direction -
> basically:
> 
> 1) Separate your changes into parts affecting the compiler behaviour
> (e.g. the changes impacting the compiled structures and code, etc.) from
> changes needed because of the changed behaviour (i.e. use of your new
> features within the RTL and/or the compiler, modified versions of code
> working with the newly / differently compiled structures, etc.).
> 
> 2) Create a conditional define for your new changes - this new define
> would be enabled within the compiler behaviour affecting changes.
> 
> 3) Make your changes resulting from the changed behaviour (either in the
> RTL, or in the compiler) enabled only when the new conditional define is
> enabled.
> 
> If you do this, you should be able to use the standard makefiles without
> any changes (e.g. "make compiler_cycle", etc.).
> 
> Tomas

Ok. It's good then.
I'd like to know about the actual CYCLELEVEL logic implementation details.

So far I haven't found any explicit conditional define related to cycle levels.
I assume something like:

  {$IF not defined(FPC_CYCLELEVEL1) and not defined(FPC_CYCLELEVEL2) and not 
defined(FPC_CYCLELEVEL3)}   
 
// previous version compiler builds our sources 

  
def_system_macro('FPC_CYCLELEVEL1');

  
  {$ENDIF}  

  
  {$IFDEF FPC_CYCLELEVEL1}  

  
// CYCLELEVEL1 compiler builds our sources  

  
def_system_macro('FPC_CYCLELEVEL2');

  
  {$ENDIF}  

  
  {$IFDEF FPC_CYCLELEVEL2}  

  
// CYCLELEVEL2 compiler builds our sources  

  
def_system_macro('FPC_CYCLELEVEL3');

  
  {$ENDIF}  

  
  {$IFDEF FPC_CYCLELEVEL3}  

  
// CYCLELEVEL3 compiler builds our sources  

  
def_system_macro('FPC_CYCLELEVEL4');

  
  {$ENDIF}  

  

... somewhere in options.pas should be enough. 
Or maybe there is already some existing / more reliable way?


-- Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Compiler internals. Changing dynamic arrays format

[denisgolovan via fpc-pascal]

Hi all

I've been maintaining a set of private patches for some quite old FPC revision 
for some years.
The idea behind those patches to ease interoperation between FPC and LuaJIT FFI 
by pointer tagging for dynamic arrays.
For that to happen I was forced to modify "tdynarray" record (increase its size 
to 32 bytes and always align dynamic arrays to 32 bytes) & change some compiler 
internals to emit proper offset to "high" and "reference count" fields.

Bootstrapping patched compiler is quite an adventure.
And that is something I'd like to straight-line and I feel that I need some 
piece of advice.

My first trouble is initialization of dynamic arrays with constant arrays. 
It looks like simply building one version of compiler just makes a build with 
old-style array constants and my already patched code.
That leads to code/constant data format mismatches and new compiler process 
just crashes.

Looks vanilla makefile builds a several versions of compiler progressing to a 
final version.
It seems that my troubles also can be solved by enabling parts of the patchset 
progressively.
More specifically, I plan to enable array serialization code patch first in 
cyclelevel 1. 
Then build next compiler level using compiler 1 with rest code enabled to get 
cyclelevel 2.
Cyclelevel2 build should already contain both all code changes and data 
constants in new format.
And finally build cyclelevel3 build with cyclelevel2 compiler to complete build.

Is it the right way to go?
And if I get it right - could anyone suggest me how to enable my constants code 
serialization patches (via conditional defines I guess) at cyclelevel 1 and all 
patches at cyclelevels 2 and 3?

-- Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Inactive account on GitLab

[denisgolovan via fpc-pascal]

> I starred the projects of those bugs (FPC/FPC/Source and
> FPC/Lazarus/Lazarus) but my todo list is still empty.
> Not a biggie now that I know how to find my bugs, though I'd prefer to
> find them with the proper filter (the first one with author_username)
> and not with a full text search.

Same problem - my todo list is empty.
I can find my issues by those "indirect" ways though :)

-- Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Inactive account on GitLab

[denisgolovan via fpc-pascal]

> FPC's git and issue trackers are hosted on Gitlab itself, we have no 
> authority to do
> user management.

Ok. I managed to sign up and login.

Does it mean my old issues cannot be linked to my GitLab account?

-- Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Inactive account on GitLab

[denisgolovan via fpc-pascal]

Hi all

Could anybody look at GitLab MageSlayer account?
I can neither login nor change my password.

Maybe my mail has not been transferred?

-- Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Management operators memleaks

[denisgolovan via fpc-pascal]

> I have not looked at your test case yet, but it *might* be related to
> issue #37164 ( https://bugs.freepascal.org/view.php?id=37164 ).

Thanks for the point, Sven.
Is there something I can do to prioritize the issue?

-- Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Management operators memleaks

[denisgolovan via fpc-pascal]

Could anybody reply?

Am I doing something wrong?
Are management operators supported or not?

-- Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Management operators memleaks

[denisgolovan via fpc-pascal]

Hi all

I created a test case for rather unusual behaviour of management operators in 
fpc 3.3.1.
In some specific cases they produce memory leaks.
I suspect it's some compiler issue.

Could somebody take a look at https://bugs.freepascal.org/view.php?id=38990 ?

P.S.
Sorry for attaching quite large test case. 

-- Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Option type

[denisgolovan via fpc-pascal]

> Well as already discovered type like strings can not go into a "record case"
> 
> But... The above record is anyway of constant size. I.e. the memory for
> the field is always included, even if it is not used.
> 
> Since the "false" block is empty, you can do
> 
> type
> generic TOption = record
> IsSome:boolean;
> some: T;
> end;
> 
> It is not as expressive to the reader of the code. But it leads to the
> same data in memory.

Yes. 
Except that "some" is still initialized with something (some default) and 
dropped and copied and assigned despite conceptually being empty.

-- Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Option type

[denisgolovan via fpc-pascal]

> You simply can't use managed types in a variant clause and as T could be
> a managed type the compiler does not allow it.

Well. I thought it should be precisely the case for variant clause to properly 
handle.
Compiler knows IsSome field is used to determine if some contains initialized 
value.

On drop/free it would insert check:
if IsSome then finalize(some);

> Use Nullable.TNullable.

Thanks. It's something close to what I need.

-- Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Option type

[denisgolovan via fpc-pascal]

> You need to use a constraint like:
> 
> type
> generic TOption = record
> case IsSome:boolean of
> true: ( some: T );
> false: ();
> end;
> 
> Not sure why though.
> 
> Regards,
> Ryan Joseph

That would limit supported types to class instances.
I'll like to avoid that. 
Ideally TOption type should allow any type (primitives, strings, objects, class 
instances, etc).

-- Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Option type

[denisgolovan via fpc-pascal]

Hi all

I am trying to implement Option type in FPC.

type
  generic TOption = record
case IsSome:boolean of
true: ( some: T );
false: ();
  end;

However fpc just emits errors:
Error: Type parameters may require initialization/finalization - cannot be used 
in variant records

Could anybody suggest some sane workaround for the problem?

-- Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Extended type under Win64

[denisgolovan via fpc-pascal]

> In theory yes, but it's not recommended, because Microsoft does not recommend 
> it (not to mention that it isn't even remotely tested as much as the normal 
> Win64 target).
> 
> Regards,
> Sven

Got it. Thanks for the clarification.

-- Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Extended type under Win64

[denisgolovan via fpc-pascal]

> The Extended type is not available for x86_64-win64. You either need to use 
> Double or the software floating point support in unit sfpux80 (though that is 
> only available in 3.2 and newer).

So, Linux x64 having hardware Extended support is just an exception?
Or maybe it's possible to build a custom x86_64-win64 compiler with that define 
enabled?

> Please note that you'll have the same problem on any non-x86 platform as that 
> type only exists there (and m68k).
Yes. I am perfectly ok with Intel only.

-- Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Extended type under Win64

[denisgolovan via fpc-pascal]

Hi all

I'm trying to get an idea if Extended float is/can actually be 80bit?
I have FPC built under Linux x64 and it works fine (co-processor command are 
actually used).

But I haven't found any reliable information about Win64 support.
Brief FPC source grepping showed FPC_HAS_TYPE_EXTENDED define, but I haven't 
managed to find where it is defined.

-- Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] IDLE_PRIO with FPC-compiled processes

[denisgolovan via fpc-pascal]

Hi all

Have anybody experienced exceptions "Failed to create new thread" when 
FPC-compiled process priority changed with schedtool -D [pid]?

-- Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Git mirror

[denisgolovan]

> I fixed it at 08:00 this morning. It's all in sync again. There was a
> new contributor to SVN that wasn't in my name list. It happens ever now
> and again.

Thanks.

-- Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Git mirror

[denisgolovan]

> It appears that the last commit on svn was on the 27th 
> (https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/utils/?sortby=date=log)
>  which is the same date as the last commit on Graeme's mirror 
> (https://github.com/graemeg/freepascal/commit/a1fd692f4f98e4889eb9ef333075a6c0f8dd0891).
>  I thus don't think there is a sync problem.

No, it's just Graeme fixed syncing today :)

-- Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Git mirror

[denisgolovan]

Hi all

Looks like Graeme's FPC git mirror stopped syncing with svn.
I've sent a private mail, but no response.
Could somebody help?

-- Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Compiler regression

[denisgolovan]

> Several people have already looked at it, but it's a complex issue that
> is not yet understood.
> 
> Jonas

Ok, thanks.
Hope all those people didn't find anything secret forcing them to remain silent 
with regards to bug comments :)

-- Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Compiler regression

[denisgolovan]

Hi all

Could somebody look at https://bugs.freepascal.org/view.php?id=35877 ?
Latest fpc trunk is completely broken while using generics.collections.

-- Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] wiki.freepascal.org is down?

[denisgolovan]

Ok, thanks.

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] wiki.freepascal.org is down?

[denisgolovan]

Hi

I get empty pages when browsing http://wiki.freepascal.org/
Is it some bug or I am doing something wrong?

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] TOpenGLControl segfaults on re-parenting

[denisgolovan]

Bug report and patch with fix filed to 
https://bugs.freepascal.org/view.php?id=35335
Please review.

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] TOpenGLControl segfaults on re-parenting

[denisgolovan]

Some more information on the matter.

While investigating the issue I noticed that gtk_gl_area_destroy is called 
twice for single OpenGL widget when changing Parent property.
That does not look nice as it accesses freed memory second time it calls 
gdk_gl_context_unref (context : PGdkGLContextPrivate).

gtk2proc.DestroyWidget->gtk_widget_destroy calls gtk_gl_area_destroy twice via 
internal gtk/glib functions.

First time gtk_gl_area_destroy is called from g_object_run_dispose with 
following stack:

#0 GDK_GL_CONTEXT_UNREF(0x29451c0) at 
../../../../../usr/local/share/lazarus/components/opengl/glgtkglxcontext.pas:456
#1 GTK_GL_AREA_DESTROY(0x278bb10) at 
../../../../../usr/local/share/lazarus/components/opengl/glgtkglxcontext.pas:283
#2 g_closure_invoke(0x26f86b0, 0x26f86b0, 0x0, 0x0, 1, 0x7fffc4a0, 
0x7fffc4a0, 0x7fffc410, 0x7fffc410) at 
/var/tmp/paludis/dev-libs-glib-2.52.3/work/glib-2.52.3/gobject/gclosure.c:804
#3 signal_emit_unlocked_R(0x26f80a0, 0x26f80a0, 0, 0, 0x278bb10, 0x278bb10, 
0x0, 0x0, 0x7fffc4a0, 0x7fffc4a0) at 
/var/tmp/paludis/dev-libs-glib-2.52.3/work/glib-2.52.3/gobject/gsignal.c:3751
#4 g_signal_emit_valist(, , , 
0x7fffc650, 0x7fffc650) at 
/var/tmp/paludis/dev-libs-glib-2.52.3/work/glib-2.52.3/gobject/gsignal.c:3391
#5 g_signal_emit(, , ) at 
/var/tmp/paludis/dev-libs-glib-2.52.3/work/glib-2.52.3/gobject/gsignal.c:3447
#6 ?? at :0
#7 g_object_run_dispose(0x278bb10) at 
/var/tmp/paludis/dev-libs-glib-2.52.3/work/glib-2.52.3/gobject/gobject.c:1084
#8 DESTROYWIDGET(0x278bb10) at gtk2/gtk2proc.inc:4252
#9 DESTROYCONNECTEDWIDGET(0x26a1100, 0x278bb10, false) at 
gtk2/gtk2widgetset.inc:4814
#10 DESTROYLCLCOMPONENT(0x26a1100, 0x2932a60) at gtk2/gtk2widgetset.inc:4724
#11 DESTROYHANDLE(0x2234978, 0x2932a60) at gtk2/gtk2wscontrols.pp:611
#12 DESTROYHANDLE(0x278be00, 0x2932a60) at 
../../../../../usr/local/share/lazarus/components/opengl/openglcontext.pas:766
#13 DESTROYWND(0x2932a60) at include/wincontrol.inc:7869
#14 DESTROYHANDLE(0x2932a60) at include/wincontrol.inc:5321
#15 REMOVECONTROL(0x2907120, 0x2932a60) at include/wincontrol.inc:6374
#16 SETPARENT(0x2932a60, 0x2f8e840) at include/control.inc:4347

Second time - from g_object_unref with stack:

#0 GDK_GL_CONTEXT_UNREF(0x29451c0) at 
../../../../../usr/local/share/lazarus/components/opengl/glgtkglxcontext.pas:449
#1 GTK_GL_AREA_DESTROY(0x278bb10) at 
../../../../../usr/local/share/lazarus/components/opengl/glgtkglxcontext.pas:283
#2 g_closure_invoke(0x26f86b0, 0x26f86b0, 0x0, 0x0, 1, 0x7fffc480, 
0x7fffc480, 0x7fffc3f0, 0x7fffc3f0) at 
/var/tmp/paludis/dev-libs-glib-2.52.3/work/glib-2.52.3/gobject/gclosure.c:804
#3 signal_emit_unlocked_R(0x26f80a0, 0x26f80a0, 0, 0, 0x278bb10, 0x278bb10, 
0x0, 0x0, 0x7fffc480, 0x7fffc480) at 
/var/tmp/paludis/dev-libs-glib-2.52.3/work/glib-2.52.3/gobject/gsignal.c:3751
#4 g_signal_emit_valist(, , , 
0x7fffc630, 0x7fffc630) at 
/var/tmp/paludis/dev-libs-glib-2.52.3/work/glib-2.52.3/gobject/gsignal.c:3391
#5 g_signal_emit(, , ) at 
/var/tmp/paludis/dev-libs-glib-2.52.3/work/glib-2.52.3/gobject/gsignal.c:3447
#6 ?? at :0
#7 g_object_unref(0x278bb10) at 
/var/tmp/paludis/dev-libs-glib-2.52.3/work/glib-2.52.3/gobject/gobject.c:3148
#8 DESTROYWIDGET(0x278bb10) at gtk2/gtk2proc.inc:4252
#9 DESTROYCONNECTEDWIDGET(0x26a1100, 0x278bb10, false) at 
gtk2/gtk2widgetset.inc:4814
#10 DESTROYLCLCOMPONENT(0x26a1100, 0x2932a60) at gtk2/gtk2widgetset.inc:4724
#11 DESTROYHANDLE(0x2234978, 0x2932a60) at gtk2/gtk2wscontrols.pp:611
#12 DESTROYHANDLE(0x278be00, 0x2932a60) at 
../../../../../usr/local/share/lazarus/components/opengl/openglcontext.pas:766
#13 DESTROYWND(0x2932a60) at include/wincontrol.inc:7869
#14 DESTROYHANDLE(0x2932a60) at include/wincontrol.inc:5321
#15 REMOVECONTROL(0x2907120, 0x2932a60) at include/wincontrol.inc:6374
#16 SETPARENT(0x2932a60, 0x2f8e840) at include/control.inc:4347

I guess I need some help from Lazarus GTK/GLib experts.
Calling glXDestroyContext in TOpenGLControl twice is obviously an undefined 
behavior and should be fixed.

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] TOpenGLControl segfaults on re-parenting

[denisgolovan]

Hi all

I experience various random segfaults when trying to change Parent for 
TOpenGLControl.
Unfortunately it happens rather randomly. 
Sometimes it happens deep in GTK code, sometimes when GL context destroys.

I am under Linux + GTK-2.24.32 + Mesa 19.0.1 (amdgpu driver).

Does anybody experience the same?

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Undocumented optimizations???

[denisgolovan]

Anybody home? :)

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Undocumented optimizations???

[denisgolovan]

Hi all

I've just tried checking fpc optimizations and found that some implemented 
optimization are not documented in fpc -io output.
e.g. http://wiki.freepascal.org/Optimization mentions AUTOINLINE, but fpc 
states only (Linux x64, svn rev. 40743):

 $ fpc -io
REGVAR
STACKFRAME
PEEPHOLE
LOOPUNROLL
TAILREC
CSE
DFA
USERBP
ORDERFIELDS
FASTMATH
REMOVEEMPTYPROCS
CONSTPROP
USELOADMODIFYSTORE

However doing something like fpc -Ooautoinline project1.lpr works fine.
Same thing with STRENGTH, SCHEDULE and some others.
Also compiling with SCHEDULE causes immediate AV in compiler.

Is it intentional to avoid usage of unstable code or just a miss in 
documentation?

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] inlining functions

[denisgolovan]

  12.01.2019, 19:44, "Benito van der Zander" :Hi,  something that appears  to help is to put units in the interface uses rather than the implementation uses.When the unit mentioned in the interface uses, uses the first unit in its implementation uses, it can inline the functions from the first unit. Although I would have expected it to do the opposite. Unfortunately that does not help if the second unit needs to use types from the first unit in its interface   Best,Benito Yes, I got it.The problem is that circular dependencies are too often happen in practice.The discussion is about how to make compiler inline function automatically even when circular dependencies exist. -- Regards,Denis Golovan ___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] inlining functions

[denisgolovan]

  12.01.2019, 16:03, "Sven Barth via fpc-pascal" :With WPO you need to compile at least twice as well as the first pass only collects information and acts on it in the second pass. Is it possible to make Lazarus do that automatically?According to Jonas it's a bit too unpractical. -- Regards,Denis Golovan 
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] inlining functions

[denisgolovan]

12.01.2019, 15:32, "Jonas Maebe" :
> It's not yet integrated in the compiler, so you have to do it manually
> right now:
> a) compile everything with -al (including the RTL etc; add OPT="-a" to
> the make command)
> b) go in all the unit directories, and assemble the files to bitcode
> using something like this:
>
> for file in *.ll; do
>    clang -emit-llvm -O -c $file
> done
>
> c) compile your program with -a -s and do the same as in step b) for
> your program
> d) edit the generated link.res file, and replace all references to unit
> files ending in ".o" with the same files ending in ".bc"
>
> If you used a custom clang rather than the one installed by default on
> your system, you will also have to specify the path to the libLTO that
> the linker should use. You have to do this on the ld command line in
> ppas.sh. You can find the correct parameter by compiling a test
> C-program with "clang -flto -### test.c", as this will print the ld
> invocation to use. E.g. on macOS, it will be something like
>
> -lto_library
> /Volumes/imac/devel/clang+llvm-7.0.0-x86_64-apple-darwin/lib/libLTO.dylib"
>
> On Linux, it's something like
>
> -plugin
> /home/jmaebe/local/clang+llvm-7.0.0-x86_64-linux-gnu-ubuntu-16.04/bin/../lib/LLVMgold.so
> -plugin-opt=O2
>
> (or a different optimization level)

Thanks, but I expected something like rebuilding compiler and adding some 
option to Lazarus project :)
So far it looks like it's not far away from manually recompilation of each and 
every module.

-- 
Regards,
Denis Golovan

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] inlining functions

[denisgolovan]

12.01.2019, 14:53, "Jonas Maebe" :
> Not at this time (unless you use the LLVM backend). 

Could you give some hints on how to enable WPO/LTO under LLVM backend?
http://wiki.freepascal.org/LLVM does not seem to mention anything on that.

> However, what you actually can do, is manually recompile all units of your 
> program
> multiple times. While this won't help with inline functions called
> before they are parsed in those same units, it will allow inlining of
> function bodies in other units that were not available during the first
> compilation due to dependency cycles.

Eh.
It does not look too practical, right?
Unless there is some magical receipt for that :)

-- 
Regards,
Denis Golovan

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] inlining functions

[denisgolovan]

07.01.2019, 00:45, "Jonas Maebe" :
> Not besides breaking your dependency cycles.

Sorry, but for necro-posting, but shouldn't WPO is supposed to help to inline 
functions as well?

-- 
Regards,
Denis Golovan

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Interface bug or some new feature

[denisgolovan]

  06.01.2019, 15:00, "Sven Barth via fpc-pascal" : The default visibility for classes without $M+ is private. Thus TClass1.P is private. An interface implementation does not have access to private methods of a parent class. So you need to declare P as protected for this to work. Though to be fair in the specific example you gave I think that it should work as both are within the same unit. We'll need to check that...  Yes. That was another real issue in my project.However I managed to get it.Thanks for quick help. -- Regards,Denis Golovan ___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Interface bug or some new feature

[denisgolovan]

06.01.2019, 14:57, "Jonas Maebe" :
> http://wiki.freepascal.org/User_Changes_Trunk#Methods_implementing_interface_methods_and_overloads
>
> Jonas

Thanks, Jonas.
That was precisely the cause for my trouble.

-- 
Regards,
Denis Golovan

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Interface bug or some new feature

[denisgolovan]

Hi all

I've been using 3.1.1 compiler for a long time and now I am trying to upgrade 
to 3.3.1 from trunk.
However, I am stuck with some new behavior when using classes + interfaces.
I've managed to reproduce it in a small example which follows. 

Specifically 3.1.1 compiler compiles it and correctly prints "Double". 
3.3.1 compiler refuses to compile it at all.
Please comment if it's a bug or a new breaking feature.

//==
program project1;

{$mode objfpc}{$H+}

uses
  {$IFDEF UNIX}{$IFDEF UseCThreads}
  cthreads,
  {$ENDIF}{$ENDIF}
  Classes
  { you can add units after this };

type
  IIntf1 = interface
procedure P(i:Integer);
  end;

  TClass1 = class(TInterfacedObject, IIntf1)
procedure P(i:Integer);
  end;

  IIntf2 = interface(IIntf1)
procedure P(f:Double);
  end;

  TClass2 = class(TClass1, IIntf2) // Error: No matching implementation for 
interface method "P(LongInt);" found
procedure P(f:Double);
  end;

procedure TClass1.P(i:Integer);
begin
  WriteLn('Integer');
end;

procedure TClass2.P(f:Double);
begin
  WriteLn('Double');
end;

var v2:TClass2;
begin
  v2:=TClass2.Create;
  v2.P(0.0);
  v2.Free;
end.
//===


-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Constants in generics

[denisgolovan]

Well, I'll wait then.That's definitely nice to have feature.02.01.2019, 16:33, "Sven Barth via fpc-pascal" :Am Mi., 2. Jan. 2019, 11:20 hat denisgolovan <denisgolo...@yandex.ru> geschrieben:Hi, allCould someone confirm this functionality is merged into trunk? I mean constants in generics.I can confirm that it is not integrated in trunk. Regards, Sven ___fpc-pascal maillist  -  fpc-pascal@lists.freepascal.orghttp://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pas…-- Regards,Denis Golovan___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Constants in generics

[denisgolovan]

Hi, allCould someone confirm this functionality is merged into trunk? I mean constants in generics.29.11.2018, 05:24, "Ryan Joseph" : On Nov 29, 2018, at 5:15 AM, Sven Barth via fpc-pascal  wrote: Looks better. The next thing to nuke is the tgenericparamdef. The parameters stored in tdef.genericparas are the parameter symbols, so there should be no need for defs. If necessary some of the code in pgenutil (and related functions) will need to be changed from handling a list of defs to a list of syms.I added that extra type so that it would be compatible with genericdeflist. I don’t see how that can be removed. The const sym is pulled out in generate_specialization_phase2 and renamed (which I forget why already).So the tgenericparamdef is just a vessel to hold the constsym until generate_specialization_phase2? Either way removing it means breaking genericdeflist right?if typeparam.nodetype <> typen then  begin{ the typesym from paramdef will be added to the list in generate_specialization_phase2 }paramdef := tgenericparamdef.create(typeparam.resultdef,typeparam,constprettyname);genericdeflist.Add(paramdef);  endelse  beginconstprettyname := '';genericdeflist.Add(typeparam.resultdef);  end;from generate_specialization_phase2:for i:=0 to genericdef.genericparas.Count-1 do  beginsrsym:=tsym(genericdef.genericparas[i]);if not (sp_generic_para in srsym.symoptions) then  internalerror(2013092602);// note: ryan{ set the generic param name of the constsym of tgenericparamdef }typedef := tstoreddef(context.genericdeflist[i]);if typedef.typ = genericconstdef then  tgenericparamdef(typedef).typesym.realname := srsym.realname;generictypelist.add(srsym.realname,typedef.typesym);  end;Regards,Ryan Joseph___fpc-pascal maillist  -  fpc-pascal@lists.freepascal.orghttp://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pas…-- Regards,Denis Golovan___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Candidate for crowd-funding

[denisgolovan]

>> - Custom/separate allocators for dynamic arrays (to avoid manually patching 
>> compiler).
> 
> Why do you need that?

Besides ordinary arrays I allocate/use arrays backed by mmaped files. 
Existing functions taking arrays as arguments mostly remain working 
transparently.
That's a huge win in code size and allow zero-copy scenarios.

Besides that, I am able provide special alignment for arrays. 
That also would be necessary to vector/SSE/AVX work.

>> - inline assembler function support
> 
> The main problem here is to model what registers an instruction uses and 
> modifies so that the register allocator of the surrounding function can take 
> that into account accordingly... Maybe as a first step we could allow in 
> lining for funcrions that have a register clause with the touched registers...
> But yes, in the long term this would definitely be nice.

Agree. Register clause will ease a lot of pain.
 
>> - proper macro language perhaps
> 
> No. We already rejected such an idea some months ago.

Ok. Looks like m4 will be my friend forever :)

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Candidate for crowd-funding

[denisgolovan]

> I will leave the technical comments to the compiler developers.
> 
>> BTW, is it possible to state the specific project when donating?
> 
> Yes, if I recall correctly you can give a message when the paypal donate
> page appears. (just as you can state that you want to be in the hall of
> fame)

Ok. Thanks.

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Candidate for crowd-funding

[denisgolovan]

Hi all

I decided to start a separate thread for asking about potential candidate for 
crowd-funding.

My personal wish-list is:
- support for array calculations / automatic loop parallelization via SSE, AVX, 
etc.
  Both static and dynamic arrays should supported. 
  Once implemented vector operations on arrays (ala APL) might be done using 
operator overloads.
- Custom/separate allocators for dynamic arrays (to avoid manually patching 
compiler). 
- Coroutines. Portable library or in-compiler support.
- Interprocedural optimizations (something akin to LTO)
- inline assembler function support
- proper macro language perhaps

Could someone comment if those goal are attractive to somebody else?
I mean both donators and potential "implementors".

BTW, is it possible to state the specific project when donating?

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Implicit generic specializations

[denisgolovan]

Hi Sven

> Where is it messy? O.o

See https://bugs.freepascal.org/view.php?id=28824
 
> Also the idea should be that a non-generic routine takes precedence.

Seems reasonable.

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Implicit generic specializations

[denisgolovan]

Hi Ryan

That's definitely a nice feature.
Could you clarify and/or discuss with compiler devs the rules for function 
overloads?
Currently FPC seems a bit messy even without inferencing like that.


BR,
Denis
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Constants in generics

[denisgolovan]

> Here’s my test which seems to be working.
> 
> program gc_procs;
> 
> generic procedure DoThis(msg:string = U);
> begin
> writeln(msg, ' ',sizeof(T), ' ', U);
> end;
> 
> begin
> specialize DoThis('hello world’); // prints "hello world 4 foo"
> specialize DoThis; // prints “foo 4 foo"
> end.

Thanks.
That's definitely a nice feature.

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Constants in generics

[denisgolovan]

Hi

Sorry for breaking in, but I'd like to know if this functionality supports 
specializing generic functions with const parameters?

BR,
Denis
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Constants in generics

[denisgolovan]

Does this trick also work for declaring arrays using "val"?

BR,
Denis
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Proper preprocessor?

[denisgolovan]

See below the function to convert dynamic value into string value inside 
interpreter project I am working at, something similar to *ToStr family in FPC.

It's generated by the macro which expands to corresponding branches for each 
value type. "$" prefixes are for passing macro arguments. "ident!" is "calling" 
other macros, but it's quite obvious I guess.

Last syntax expression is "application" of this macro resulting in actual 
function creating and immediate compilation by Rust compiler. 

macro_rules! to_string {
($($scalar:tt),*) => {
pub fn to_string(ast: , interpreter: ) -> AST {
match base_tp(ast.tp()) {
$(
$scalar => {
let aco=aco!($scalar, ast, Some(interpreter.alloc()));
let s=ato_str!(aco, aget!(aco, ast), interpreter);
new_string(, interpreter.alloc())
},
)*
$(
to_vec!($scalar) => {
let aco=aco!($scalar, ast, Some(interpreter.alloc()));
let v=ast.array::();
v.iter().map(|x| {
let s=ato_str!(aco, *x, interpreter);
new_string(, interpreter.alloc())
}).enlist(v.len(), interpreter.alloc())
}
)*
$(
to_deq!($scalar) => {
let aco=aco!($scalar, ast, Some(interpreter.alloc()));
let v=ast.vecdeq().head::();
v.iter().map(|x| {
let s=ato_str!(aco, *x, interpreter);
new_string(, interpreter.alloc())
}).enlist(v.len(), interpreter.alloc())
}
)*
x if is_nested(x) => atomic(ast, to_string, "to_string", 
interpreter),
VEC_CHAR => (*ast).clone(),

_ => except!(eval_err!("cast: nyi.")),
}
}
}
}
to_string!(
SC_BOOL,
SC_BYTE,
SC_SHORT,
SC_INT,
SC_MONTH,
SC_DATE,
SC_MINUTE,
SC_SECOND,
SC_TIME,
SC_LONG,
SC_TIMESTAMP,
SC_DATETIME,
SC_TIMESPAN,
SC_SINGLE,
SC_DOUBLE,
SC_ENUM,
SC_SYMBOL,
SC_GUID
);

All in all my rough estimate for macro efficiency ratio is something like 12x 
currently. That's about 12 times less code to type and support. YMMV, of course.

See 
https://danielkeep.github.io/tlborm/book/mbe-min-captures-and-expansion-redux.html
 for boring details on Rust macros.

BR,
Denis
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Proper preprocessor?

[denisgolovan]

> Do you have examples here?

There are several use-cases I often see.

1. The task is to allow declaration of some container structure (vector, tree, 
etc.)
The mechanism to create it must have enough flexibility to define/parametrize 
at compile-time in one go:
- keys are integers in 0..N-1 only or any type supporting equality testing. 
  That user decision should influence container code and its manual code 
optimizations, e.g. special cases like indexing, appending/removing/etc.
- are keys always sorted? => influences insertion, search, etc.
- values are primitive types (not having destruction phase - just dealloc) or 
it should call Finalize/Free/"Assign nil" on destroying.
- if values are records - all accessors should return pointers instead to be 
able to modify fields without "read, modify, write" ceremonies.
- does structure generate events on insertion/deleting/etc? => influences event 
property declarations + actual code to trigger those
- what kind of interface user prefers for the container - class, record, 
interface with reference counting or any combination of those?
- all its generic functions like map, filter, destructive map, etc. should be 
overloaded functions existing both as structure methods and free form (globals 
with additional argument). Their argument should accept all kinds of callbacks 
- simple functions, methods ("of object" type), nested ("is nested") and 
possibly future "reference" (closure FPC does not support yet).
- grow strategy - user-defined, with given coefficient, etc.

... currently all above is generated using m4 producing entire FPC module. 
That's old times philosophy - structures amount is small, functions to work 
with them are numerous and coherently named. Something similar to C++ STL, but 
without exponential build times and more tailored to users' needs.

2. Meta declarations for global entities with names/ids/descriptions/etc. 
The mechanism to create it must have enough flexibility to define/parametrize 
at compile-time in one go:
- create Pascal native declarations as enums
- create Pascal functions to convert to/from strings/integers/etc
- create overloaded serialization functions for XML, streams, etc.
- create foreign code declaration (C, Lua, etc.)
- native Pascal foreign code marshalling (e.g. Pascal <-> Lua via Lua stack)

3. Dynamic libraries exports.
The mechanism to create it must have enough flexibility to define/parametrize 
at compile-time in one go:
- compile in Pascal "generics" / m4 templates to support other processes / 
languages
- exported functions should accessible via specific foreign import (e.g. it 
should generate corresponding header files for use in C/C++)

4. Published functions/classes/ into interpreted languages
- just declare which classes and their methods should be accessible e.g. from 
Lua and code should generated for make it happen.
- FFI import/export - declare functions / types / names - get boilerplate to 
make it happen.


That's more or less it. 
At least those I quickly gathered from real project.

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Proper preprocessor?

[denisgolovan]

> C was designed from the ground up with preprocessing. Pascal, and most newly
> designed languages, do not have preprocessing built-in. For good reason.

Well. I can't agree.
C macros are bolted on :). It's too alien for main part of language. No respect 
to captured variables, no operator priorities, parsing is hard, etc.
On the other hand, recent language Rust has macros nicely integrated in 
language itself and they plan to extend them in 2.0 version.
D language also has mixins. Let alone Lisp-dynamics derivatives.
Those macros help a lot in intensive meta programming (read writing 
interpreters/compilers/introspection heavy applications) and reduce total line 
count considerably.

Generics are rather limited in that respect. 
At least some construction should exist to instantiate those generics.
e.g. to create several public structs, interfaces, free functions (possibly 
instancing generics) in one go.

My personal way of doing stuff like that is "m4 -> pas/inc" conversion and 
triggering them in makefiles. 
Robust incremental pre-processing is quite affordable for make + m4 combination 
as well.
Again Rust macros being something in between C defines and m4 in terms of power 
are really pragmatic at times.

> Some cans are better left unopened. Or pandora's box is better left
> closed... (if you prefer mythological references ;) )

Again, different design philosophies lead to different design decisions.
Better less amount of code + more automatic consistence leading to more cryptic 
code (have a look at APL/J/... implementation) OR lots of boilerplate + less 
consistence, but much more readable for non-experts? 
What about refactoring price in both scenarios? Open source projects have a 
variety of opinions on that.

But I generally support FreePascal team in avoiding features they personally 
don't extensively use :)

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

[denisgolovan]

> Horses for courses. I think the impressive thing about APL is that the
> necessary operations were worked out (and used for Blackboard
> demonstrations) /before/ it was converted into a computer language, and
> by and large weren't added to. However the functional nature of the
> language was vastly overrused, and students who thought they were being
> smart would on occasion find themselves with mainframe runtimes of
> /months/ because they'd created an enormous array instead of using a
> simple control structure.

Yes, sure. 
But things slowly change in compiler/interpreter world.
Now we have loop/streams fusion techniques and other devectorization tricks, so 
I think smart APL interpreter would be of real help here.
 
> Nod here to Vector Pascal as well. And as a bit of history, the first
> computer implementation of Iverson's notation was done at Stanford under
> the watchful eye of Niklaus Wirth.

Hm, I didn't know that. Thanks for sharing.
Looks like computer scientist community was really small those days.

Vector Pascal is much closer to our current discussion though :)

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

[denisgolovan]

Having worked with APL for almost 6 years and continuing with Q/KDB, I would 
say APL syntax is much more readable than Perl 6. 

Though being able to modify language like that is really impressive.

BR,
Denis 
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

[denisgolovan]

Yes, if you want destructive updates you need a special syntax for that.

I believe existing syntax is not suitable for destructive update, hence the 
error I mentioned.

BR,
Denis
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

[denisgolovan]

Yes, I strongly support removing that functionality in favor of user operator 
overloads or vector-compatible way.

Moreover, SSE/AVX vector extensions also should work per-element.
I mean those vectors as in https://bugs.freepascal.org/view.php?id=27870

BR,
Denis
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

[denisgolovan]

It's technically possible.

But for vector operations to be valid/consistent both of them should work the 
same way. That is perform arithmetic per-element addition. 

BTW, you first overload is not implemented properly. You need to clone "left"  
first and return it as a result.

BR,
Denis
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

[denisgolovan]

> By all means, please reconsider this, and leave me the choice to define the
> operators. If I want "+" for concatting, it is trivial to define it myself.
> I don't need the language to force that and eseentially destroy operator
> overloading for mathematical operations on dynamic arrays.

Same here.

The semantics for vector operations on arrays was thoroughly explored in vector 
languages (APL, A+, J, K, etc).
Doing per-element dyadic function application is the basis for it. Having 
proper operators overloads is crucial.

@Sven
Please reconsider "+" operator for arrays if your changes really forbid to 
overload operators for arrays now.

Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Copy dynamic array

[denisgolovan]

> What would the expected behavior be for pointers inside records? What if
> the record is actually a linked list? Or includes classes and objects?
> Do we run the constructor or no? If the record has file handles do we
> attempt to recreate their state? (perhaps running assign again, and
> crossing our fingers the file hasn't been deleted - which at least on
> Linux is definitely possible)

Well.
The answer is simple - value types (scalars, strings, records, variants, arrays 
of mentioned) are good functional citizens.
Cloning is well defined for them as compound value is also value. 

Should someone wants for add complexity (read OOP/pointers/classes and other 
crap) - use http://wiki.freepascal.org/management_operators#Copy at your own 
risk.

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Copy dynamic array

[denisgolovan]

Doing the same conceptual thing using different syntax does not seem right as 
generics, macros and other nice stuff become clumsy and too verbose.

See

//
program project1;
{$mode objfpc}

type
   TRec= record
  A:array of integer;
  S:string;
   end;

var R1,R2:TRec;
begin
   SetLength(R1.A, 3);
   R1.A[0]:=1;
   R1.A[1]:=2;
   R1.A[2]:=3;
   R1.S:='123';

   R2:=R1; // shallow copying <> full clone
   R2.A[0]:=10;
   R2.S[1]:='S';

   // does not work as expected (no copy-on-write/cloning)
   writeln(R1.A[0]); // prints 10
   writeln(R2.A[0]); // prints 10

   // works fine
   writeln(R1.S[1]); // prints 1
   writeln(R2.S[1]); // prints S
end.
//

BR,
Denis
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Copy dynamic array

[denisgolovan]

Yes. 
That's exactly why I gave that example.
Your method with Move will trigger segfault eventually, so the compiler support 
is required to handle it properly.

BR,
Denis
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Copy dynamic array

[denisgolovan]

Well.

"Copy" works for arrays only.
Neither strings nor records work.
Tested in pretty old svn rev. 37656

//=
program project1;

{$mode objfpc}{$H+}

type
  TRec = record
s1:string;
i1:integer;
  end;

var S1,S2:string;
A1,A2:array of integer;
R1,R2:TRec;
begin
  A1:=[1,2,3];
  A2:=Copy(A1);
  A2[0]:=10;
  writeln(A1[0]);
  writeln(A2[0]);

  S1:='123';
  S2:=Copy(S1);

  R1.s1:='123';
  R1.i1:=1;
  R2:=Copy(R1);
end.
//===

BR,
Denis
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Copy dynamic array

[denisgolovan]

A side note:

I am still wondering why there is no something like "Clone" function to make an 
independent copy of string/array/... ? It's used quite often in practice (as we 
don't have copy-on-write working in all circumstances).

BR,
Denis
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Operator overload resolution with arrays

[denisgolovan]

> Take the following simple declaration:
> 
> type
> TTriangleIndex = array[0..2] of Integer;
> TFacetList = specialize TFPGList;
> 
> operator = (A, B: TTriangleIndex): boolean;
> 
> This will not work:
> fgl.pp(948,50) Error: Operator is not overloaded: "TTriangleIndex" =
> "TTriangleIndex"

Hi, I believe https://bugs.freepascal.org/view.php?id=27690 is all about it.

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Again heaptrc dump interpretation

[denisgolovan]

> IIUC, if these two do not match, you might have a memory leak... keep up also
> with your memory blocks allocated and freed...

Well. I feel something is wrong.
But how can it be? I mean all allocated blocks were freed.
I'd like to know for sure what that "Should be" means.

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Again heaptrc dump interpretation

[denisgolovan]

Hi all

I am getting following dump after my application exits.

Heap dump by heaptrc unit
342662 memory blocks allocated : 7318105636/7319146560
342662 memory blocks freed : 7318105636/7319146560
0 unfreed memory blocks : 0
True heap size : 7276691456
True free heap : 1773152
Should be : 7276691456

Could somebody explain what "Should be" (7Gb here) is?
Is it some memory leak which is not tracked by heaptrc?

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] PAPI module for FreePascal

[denisgolovan]

Hi all

Does anybody know any module/binding for PAPI?
I mean some library for reading hardware performance counters under Linux.
Something similar to https://github.com/david-grs/geiger
It's quite simple to write it myself, but worth asking before re-inventing the 
wheel :)

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Compiler debug build

[denisgolovan]

Thanks.That's exactly what I need.22.07.2017, 20:20, "Maciej Izak" <hnb.c...@gmail.com>:2017-07-22 19:05 GMT+02:00 denisgolovan <denisgolo...@yandex.ru>:So the question is why it's so difficult to build fpc compiler/rtl in debug mode?
Is it possible to fix? Or maybe I miss some official way?You don't need to edit Makefile.fpc. When I need debug info for rtl and packages I use this:make clean all LINKSMART=1  CREATESMART=1  DEBUG=1 OPTIMIZE=0  OPT="-gl -gw -godwarfsets -O-1" -- Best regards,Maciej Izak

,___fpc-pascal maillist  -  fpc-pascal@lists.freepascal.orghttp://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal-- Regards,Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Compiler debug build

[denisgolovan]

Hi all

Currently I am debugging a nasty shared memory bug.
More specifically it's related to memory allocator, though not directly.

More to the point - lack of backtraces is really tough - Lazarus debugger just 
shows one level. 
Upon some investigation I managed to get much more meaningful backtraces. 
However the only way to enable them which I found is manually editing root 
Makefile.fpc and removing all RELEASE directives (giving executing make DEBUG=1 
does not help) and compiler rebuild to avoid -O2 optimizations.

So the question is why it's so difficult to build fpc compiler/rtl in debug 
mode?
Is it possible to fix? Or maybe I miss some official way?

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[denisgolovan]

Please do.

And to that hero who is willing to take the effort - please post a call for 
donation in a separate thread :)

10.07.2017, 13:06, "Michael Van Canneyt" <mich...@freepascal.org>:
> On Mon, 10 Jul 2017, denisgolovan wrote:
>
>>  That's exactly what I mean - some (or major) part of public considers it a 
>> stopper for some reason :)
>>
>>  Sorry for hijacking the thread.
>
> I can add it to the list of sponsored projects on the foundation page.
>
> Michael.
> ___
> fpc-pascal maillist - fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[denisgolovan]

That's exactly what I mean - some (or major) part of public considers it a 
stopper for some reason :)

Sorry for hijacking the thread.


10.07.2017, 12:43, "Santiago A." <s...@ciberpiula.net>:
> El 10/07/2017 a las 11:17, denisgolovan escribió:
> It is not a matter of public image, it's a matter of usability, a "must
> have", a stopper.

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[denisgolovan]

Just my 50 cents.

Even though I avoid using debugger at all cost, 
I am willing to donate some money should someone start a crowd-funding effort 
to get "modern" debugging support in Lazarus.
That would definitely improve Lazarus/FPC public image.

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] GLM library alternative?

[denisgolovan]

28.05.2017, 09:55, "Benjamin Rosseaux" : I've put some units of my still work-in-progress UE4-style SupraEngine on my root server, after I've read this mailing list thread =>  http://rootserver.rosseaux.net/stuff/supraengineunits/   Looks nice. Thanks for sharing.How about publishing it on Github with small readme to ease contributions? -- Regards,Denis Golovan 
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] machine readable grammar of object pascal?

[denisgolovan]

> On 2017-05-03 00:53, Marc Santhoff wrote:
>>  Does such grammar exist?

Well, it depends on what you are trying to solve.
If you want to parse Pascal using FPC - that's one way. 
If you want to get some king of AST using any available [command-line] tools - 
that's another one.

Talking about latter - I would take LPEG (Lua+PEG) and create a parser myself. 
It comes quite simple and intuitive (contrary to LL,LR,LALR,...).
Most of Object Pascal is done right (minus sets/open arrays), so it can be 
parsed statically pretty easily.
See http://lua-users.org/wiki/LpegRecipes for inspiration.

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Coroutines and VirtualAlloc

[denisgolovan]

20.04.2017, 11:43, "Ryan Joseph" :
>>  On Apr 20, 2017, at 3:01 PM, Bernd Mueller  wrote:
>>
>>  it would be really nice to have coroutines for the embedded targets like 
>> AVR and ARM.
>
> What are people using this for btw? Personally I wanted them to solve some 
> problems in game programming where I lots of nested loops that need to be 
> synched with a main loop and can’t block.

It is especially favorable for game development.
All processes/objects which live across several rendering frames and have any 
state are greatly simplified by coroutines.
e.g. living entities, animations, any game triggers, any finite state machines, 
etc. 
Proper implemented coroutines support thousands of instances. 
With proper (read "mostly functional"/non-shared data) approach coroutines 
might also be calculated within real threads in parallel.

Another example is network-related code (both client and server code).
Break your huge finite state machines into pipeline stages via coroutines and 
it gets pretty modular, extensive and simple to reason about.

To say to generally, had we had coroutines in first place, no OOP crap would be 
necessary :)
At least in game development.

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Feature announcement: Management Operators

[denisgolovan]

Thanks a lot.I guess http://bugs.freepascal.org/view.php?id=30687 should be closed now :) -- Regards,Denis Golovan 
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] List of integers? Any class available in RTL or FCL to help?

[denisgolovan]

05.12.2016, 16:38, "Sven Barth" :Again: I don't see why anyone thinks of generics as complex. Your mail did not answer that in any way. Hm. I tried :)I can put it another way.No language element exists on its own.And generics are complex because they lead to more accidental complexity for reasons given earlier. I guess the analogy with bureaucratic papers is valid here.Too much hassle (new strange and verbose syntax, combination/overload rules are non-obvious) with so low added value.It comes that using any sufficiently advanced text preprocessor (like m4) gives much more power _without_ added complexity of generics. For OOP-only, it may be a step forward, but for functional language it's quite a controversy. -- Regards,Denis Golovan ___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] List of integers? Any class available in RTL or FCL to help?

[denisgolovan]

 05.12.2016, 13:35, "Sven Barth" :I really don't get why some people think of generics as complex -.- Exactly for the cited reason. See below. > Using plain old arrays, requires reinventing the wheel because you end up> writing duplicate functions for each array type (array of string) instead> of a general purpose algorithm for many types.. It's not possible to get uniform interfaces that would play nice with algorithms.Try writing a _single_ function for sorting static arrays, dynamic arrays,open arrays, generic containers(T*List * all value types).The standard recipe is re-implement everything from scratch over and over again.Even now, when we have generic functions - I am forced to specialize them by hand! Even C# got it right...Another issue is that some special functions are considered "special" - you cannot overload them (SetLength, Copy, ...).Yet another thing is that arrays are nice value-pretending types (refcouting), but most generics are classes!We desperately need http://bugs.freepascal.org/view.php?id=30687 to get record based generics value types back to the language. Basically it's all about combinatorics when combining functions.Either compiler does it for you, or you are forced to do it manually instead. To sum up, generics in current implementation add too little while exploding combinatorial variety of algorithms. -- Regards,Denis Golovan ___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Other linkers support

[denisgolovan]

I've received an answer to my reported bug
https://sourceware.org/bugzilla/show_bug.cgi?id=20870

Could anyone from FPC team comment anything there?


19.11.2016, 14:53, "Jonas Maebe" <jonas.ma...@elis.ugent.be>:
> denisgolovan wrote:
>
>>  18.11.2016, 13:00, "Jonas Maebe" <jonas.ma...@elis.ugent.be>:
>>>  denisgolovan wrote on Fri, 18 Nov 2016:
>>>
>>>>   Last time I tried, ld scripts generated by fpc caused some errors on
>>>>   gold linker.
>>>>   Are there any plans for support anything else besides standard ld?
>>>  Gold and lld are supposed to be compatible with GNU ld (bar ancient
>>>  stuff that is no longer relevant current platforms). If you get
>>>  errors, please report bugs against these other linkers.
>>
>>  Ok.
>>  See http://bugs.freepascal.org/view.php?id=30956 then.
>
> With "report a bug against these other linkers" I meant "report a bug to
> the project that develops those linkers". The reason is that they are
> supposed to be drop-in replacements for GNU/BFD ld, so any
> incompatibility is a bug/missing feature in their implementation.
>
> Jonas
> ___
> fpc-pascal maillist - fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Other linkers support

[denisgolovan]

Ok.
See http://bugs.freepascal.org/view.php?id=30956 then.


18.11.2016, 13:00, "Jonas Maebe" <jonas.ma...@elis.ugent.be>:
> denisgolovan wrote on Fri, 18 Nov 2016:
>
>>  Last time I tried, ld scripts generated by fpc caused some errors on
>>  gold linker.
>>  Are there any plans for support anything else besides standard ld?
>
> Gold and lld are supposed to be compatible with GNU ld (bar ancient
> stuff that is no longer relevant current platforms). If you get
> errors, please report bugs against these other linkers.
>
> If you are under Linux, make sure to first check with FPC trunk
> though, because the "did you forget -T" warnings from ld have been
> fixed there, and these warnings indicated that FPC was relying on
> undefined behaviour of the linker.
>
> Jonas
> ___
> fpc-pascal maillist - fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Other linkers support

[denisgolovan]

Hi all

Could anybody provide some information on support for LLD and/or gold linker?
Linker phase becomes a bottleneck for me. 

Last time I tried, ld scripts generated by fpc caused some errors on gold 
linker.
Are there any plans for support anything else besides standard ld?

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] New Feature: 'Management Operators'

[denisgolovan]

Yes. Mostly.

More general advantage is that this feature might finally bring FreePascal back 
into league of languages having nice support for value types (as opposed to OOP 
atrocities). 
To put it in other words, functional style might become both feasible and 
sufficiently fast in FreePascal.

IMHO, that is one of the most valuable additions to the language in years.

BR,
Denis


09.11.2016, 08:29, "Lars" :
> On Tue, November 8, 2016 1:47 am, Maciej Izak wrote:
>>  2016-11-07 22:24 GMT+01:00 African Wild Dog :
>>
>>>  I saw on the bug tracker a patch submission by Maciej Izak about the
>>>  feature "Management Operators".
>>>
>>>  This feature is related to Automatic Reference Counting?
>>
>>  Yes. We have a working ARC objects
>
> Can someone briefly explain what this means for code?
>
> Is this related to garbage collected heap allocated objects and similar,
> without using a garbage collector but using reference counting?
>
> Sorry if I am way off base, I just have no idea what it is...
> ___
> fpc-pascal maillist - fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] New Feature: "Management Operators"

[denisgolovan]

  08.11.2016, 11:48, "Maciej Izak" : anyway probably I have no motivation anymore to continuing my work. That's unfortunate for the community, IMHO.Personally, I appreciate your idea of management operators. -- Regards,Denis Golovan 
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Smart Link definition ?

[denisgolovan]

Sorry, for the question, but is it really working for FPC+Lazarus?
I mean FPC with smart-linking from trunk.

Last time I tried, I could not complete full FPC and Lazarus rebuild.

BR,
Denis

10.10.2016, 18:03, "Jonas Maebe" :
> On 10/10/16 16:25, fredvs wrote:
>>  Does somebody know if smart-link (-XX) is done by the compiler (fpc) or by
>>  the linker (ld) ?
>
> It's done by the linker, but it is based on how the compiler
> structures/annotates the code and data when you compile with -CX.
>
> Jonas
> ___
> fpc-pascal maillist - fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] [PATCH] Addition of OnNotify event on "TFPGObjectList" and "TFPGList" triggered on the insert, delete and extract methods.

[denisgolovan]

21.02.2016, 02:59, "Sven Barth" :
> Then you don't consider C++ as mainstream, do you?
>
> Regards,
> Sven

Hm. Looks like C++ actually does that and that's great.
Unfortunately I stopped using C++ for large projects about 12 years ago, so my 
C++ template knowledge must be too old :)  

> I had thought about this some time ago and then found a reason why I wouldn't 
> do it... Now if I'd only remember that reason -.-
Yes, it's interesting to see why. It's wildly useful and gives a lot of power.

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] [PATCH] Addition of OnNotify event on "TFPGObjectList" and "TFPGList" triggered on the insert, delete and extract methods.

[denisgolovan]

20.02.2016, 02:05, "Sven Barth" :
> There's no need for a sample. This degradation is the whole reason why the 
> non-generic classes TFPObjectList and TFPList exist compared to TObjectList 
> and TList which do have notifications.
>
> Regards,
> Sven

/ My previous mail appeared to be in html format. Sorry for that.

Hi

That always keeps me wondering - why neither FPC, no any other mainstream 
static-type language implements specialization based not only on types, but on 
compile-time constants as well?

I mean something like

  TGenericList = class
    ...
  end;

procedure TGenericList.Delete(index:integer);
begin
  if (nnNotifyDelete in options) and Assigned(FOnDelete) then
    FOnDelete(...);
  end;
end;

// usage
type
  TMyList = specialize TGenericList;

... that "if (nnNotifyDelete in options) " condition will optimized out by 
compiler if options lack corresponding enum constant.
Of course, FOnDelete property should be omitted as well in ideal case. That 
might require something like "static if" in D.

I've done that trick for ages using m4 preprocessor and it works really good, 
why it's still not supported natively by compilers themselves?

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] [PATCH] Addition of OnNotify event on "TFPGObjectList" and "TFPGList" triggered on the insert, delete and extract methods.

[denisgolovan]

Hi That always keeps me wondering - why neither FPC, no any other mainstream static-type language implements specialization based not only on types, but on compile-time constants as well? I mean something like   TGenericList = class    ...  end; procedure TGenericList.Delete(index:integer);begin  if (nnNotifyDelete in options) and Assigned(FOnDelete) then FOnDelete(...);  end;end; // usagetype  TMyList = specialize TGenericList; ... that "if (nnNotifyDelete in options) " condition will optimized out by compiler if options lack corresponding enum constant.Of course, FOnDelete property should be omitted as well in ideal case. That might require something like "static if" in D. I've done that trick for ages using m4 preprocessor and it works really good, why it's still not supported natively by compilers themselves? 20.02.2016, 02:05, "Sven Barth" :There's no need for a sample. This degradation is the whole reason why the non-generic classes TFPObjectList and TFPList exist compared to TObjectList and TList which do have notifications.Regards, Sven,___fpc-pascal maillist - fpc-pascal@lists.freepascal.orghttp://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal  -- Regards,Denis Golovan ___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Lazarus smartlinking

[denisgolovan]

Hi all

I am trying to get smartlinking working, but it seems a bit harder than I 
expected. I am interested in both Linux and Windows arches.
I was able to build fpc using RELEASE=1 CREATESMART=1 LINKSMART=1 make flags.
So far so good.

However, when I tried building Lazarus with the same make flags, it just fails 
early with:
(3104) Compiling fcllaz.pas
Fatal: (10022) Can't find unit process used by RegisterFC

I found out it's related to RELEASE=1 flag. Looks like recent Lazarus cannot be 
build with RELEASE=1 at all (-n is passed and fpc can no longer find its own 
units).

I removing RELEASE=1 and leaving CREATESMART=1 LINKSMART=1, but it looks like 
makefiles pass -g -gl flags to compiler and Linux compiler does not like dwarf 
debug info together with smartlinking. 

Can somebody give a hint on a proper build sequence for Lazarus?

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] fgl.TFPGMap / operator not overloaded for object types

[denisgolovan]

 https://github.com/dathox/generics.collections
 
  Thanks. Git makes life easier.

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] fgl.TFPGMap / operator not overloaded for object types

[denisgolovan]

 Alternatively you can use THashMap from Generics.Collections - this 
 implementation don't need any operators overloading, will work with most of 
 FreePascal types and it is much, much faster :)

Yes. I saw your library.
Looks promising, but I am a bit concerned about amount of bugs related to this 
one.
You pushed fpc generics straight to the edge :)

BTW, could you upload it to GitHub to be able to pull new changes easier?
It looks like it will be a long way to official FPC package.

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] fgl.TFPGMap / operator not overloaded for object types

[denisgolovan]

Hi all

I am wondering if somebody created a bug request for the problem described in
http://lists.freepascal.org/fpc-pascal/2011-January/028020.html ?

If not I'd like report it :)
I am asking because I stumbled across the same issue under fpc 3.1.1 (rev.30041)

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Linux x64 linking error (FPC_ABSMASK_SINGLE)

[denisgolovan]

 How can I fix it? Should I pass -fPIC argument (and how to do this)?

AFAIK, PIC code generation is turn on by default.
Are you sure you don't have an opposite problem?
Sometimes when you have asm code written with hard-coded offsets you can get a 
module which can't be PIC-compiled.

See fpc -h params for _disabling_ PIC code generation.

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Heap manager tuning

[denisgolovan]

Hi all

I am trying to debug an issue that seems to be related to FPC heap manager.
Test machine - Linux x64.

It looks like really large memory overhead compared to cmem manager.
Test load profile - 50 heavy objects with around 25 large (1Mb - 10Mb) dynamic 
arrays each.
Those arrays are created in threads.

That allocation takes 10Gb+ under FPC heap manager. Further allocation becomes 
hardly possible (I have 16Gb on-board).
Meanwhile, cmem allocates around 3Gb. So I can operate 3 times more object 
set. 

I am pretty sure I don't have any memory leaks (heaptr is enabled all the time).

Any suggestions?
I am willing to sacrifice some allocation performance to decrease total memory 
consumption if it is necessary. 

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Heap manager tuning

[denisgolovan]

 On 09/08/14 23:01, denisgolovan wrote:
 
 Try avoiding growing memory blocks small amounts at a time via
 reallocmem or setlength, and instead grow them in bigger chuncks. This
 will both increase the performance of your program and reduce the
 internal memory fragmentation.
 
 Jonas

I don't have that allocation pattern here. Just a lot of large arrays 
allocating/deallocating (including local arrays for temporary results).
Any Java-like knobs to play with? :)

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal