Re: [fpc-pascal] Pascal Language Server

2020-04-25 Thread Ryan Joseph via fpc-pascal
I'm still stuck on this problem. I can get the full proc head using 
CodeTool.ExtractProcHead but I can't get the name/type parameter pairs in a 
list (unless I do something stupid like parse the string from ExtractProcHead). 
I need to return the parameters in discrete pairs in text that matches the 
format of the header. I know ExtractProcHead finds this information but it's 
lost in the function before it returns.


function ExtractContext(CurContext: TCodeContextInfoItem; var ParamPairs: 
TStringList): String;
  var
Code: String;
CurExprType: TExpressionType;
CodeNode, ChildNode: TCodeTreeNode;
CodeTool: TFindDeclarationTool;
ParamList: TCodeTreeNode;
  begin
CurExprType:=CurContext.Expr;
Code:=ExpressionTypeDescNames[CurExprType.Desc];
if CurExprType.Context.Node<>nil then
  begin
CodeNode:=CurExprType.Context.Node;
CodeTool:=CurExprType.Context.Tool;
case CodeNode.Desc of
  ctnProcedure:
begin
  Code:=CodeTool.ExtractProcHead(CodeNode,
  
[phpWithVarModifiers,phpWithParameterNames,phpWithDefaultValues,
   phpWithResultType]);

  // TODO: get param name/type pairs
  ParamList:=CodeTool.GetProcParamList(CodeNode);
  if ParamList <> nil then
begin
  ChildNode:=ParamList.FirstChild;
  while ChildNode<>nil do
begin
  Code += ChildNode.DescAsString+' ';
  ChildNode:=ChildNode.NextBrother;
end;
end;
end;
end;
  end;
Result := Code;
  end;


Regards,
Ryan Joseph

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


[fpc-pascal] New feature announcement: constant parameters for generics

2020-04-25 Thread Sven Barth via fpc-pascal
The Free Pascal team is happy to announce the addition of a new language 
feature: constant parameters for generics.


This allows to declare generic types or routines that aside from type 
parameters can also take constant parameters that can be used inside the 
generic as if one would use untyped constants. Together with inlining 
and optimizations this allows to generate optimal code that is yet flexible.


This feature was developed by Ryan Joseph. Thank you very much Ryan for 
your contribution and your patience until this feature was included.


A generic constant parameter is declared like this:

CONSTPARAM::=const : 
IDLIST::=[, ]
TYPE::=

The following types are supported for constant parameters:
- integer types (including range types)
- floating point types
- string types
- set types
- enum types
- Boolean types
- Pointer types

While the type declaration might look like a typed constant it is in 
fact an untyped constant. The type is used to allow the author of a 
generic to restrict the range of the type. This has some implications:


- the constant parameter can be used inside the generic whereever an 
untyped constant can be used (e.g. variable initializers, constant 
initializers, default parameters, array indices, compile time intrinsics 
and operations)
- types that can't be used for untyped constants can't be used for 
generic constant parameters either


Example:

=== code begin ===

{$mode objfpc}

type
  generic TStaticArray = array[0..N-1] of T;

generic function TimesX(aArg: Integer): Integer;
begin
  Result := aArg * N;
end;

var
  myArray: specialize TStaticArray;
  i: LongInt;
begin
  i := specialize TimesX<2>(21);
end.

=== code end ===

Important: Unlike C++ FPC does not support default specializations, thus 
doing recursive specializations together with operations on constants 
will result in out of stack exceptions or infinite loops:


=== code begin ===

{$mode objfpc}

type
  generic TTest = class
  const
    N1 = N - 1;
  type
    TSubTest = specialize TTest;
    // the following does not work currently for a different reason:
    // TSubTest = specialize TTest;
  end;

begin
end.

=== code end ===

Delphi compatibility: this feature is NOT Delphi compatible. However to 
not inconvience users that prefer mode Delphi this feature is also 
available in that mode as our stance usually is that Delphi code should 
compile with FPC while the inverse is not necessarily true.


Also this feature will NOT be part of 3.2.

Please give the generic constant parameters a try and report bugs in the 
bugtracker.


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


Re: [fpc-pascal] Pascal Language Server

2020-04-25 Thread Mattias Gaertner via fpc-pascal
On Sat, 25 Apr 2020 21:08:52 +0700
Ryan Joseph via fpc-pascal  wrote:

> > On Apr 25, 2020, at 8:49 PM, Michael Van Canneyt
> >  wrote:
> > 
> > It will run on a server that never installed lazarus.  
> 
> Excellent. Where are the caches kept btw? 

Memory.

Mattias


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


Re: [fpc-pascal] Pascal Language Server

2020-04-25 Thread Michael Van Canneyt



On Sat, 25 Apr 2020, Ryan Joseph via fpc-pascal wrote:





On Apr 25, 2020, at 8:49 PM, Michael Van Canneyt  wrote:

It will run on a server that never installed lazarus.


Excellent. Where are the caches kept btw? I thought they were in the Lazarus 
directory but I guess not.


I suspect in a file in ~/.lazarus or ~/.yourprojectname, probably the latter.

Michael.


Regards,
Ryan Joseph

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

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


Re: [fpc-pascal] Debug-Adapter-Protocol support for fpDebug

2020-04-25 Thread Martin Frb

On 25/04/2020 16:07, Ryan Joseph via fpc-pascal wrote:



On Apr 24, 2020, at 3:10 AM, Joost van der Sluis  wrote:

I'm working on the support of the debug-adapter-protocol for fpDebug. It's 
quite easy to implement, as there already is a json-based tcp/ip interface. 
(https://microsoft.github.io/debug-adapter-protocol)

I use the debugger in VSCode and while LLDB works pretty well, short strings 
are always a problem. I've never used fpDebug though so I can't say if it's 
better than LLDB (I thought it was no very mature).


FpDebug has the advantage that it knows "fpc".

That is on top of what is specified by the dwarf info, fpdebug does look 
for other info.

Of course only, if it the dwarf info contains the producer = fpc.

ShortString (depending on dwarf version) is IIRC encoded as record. So 
any debugger will show this. But fpdebug looks for some details in how 
fpc writes various dwarf entries. And then detects it as shortstring. 
Though this works for known fpc versions only.

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


Re: [fpc-pascal] Pascal Language Server

2020-04-25 Thread Ryan Joseph via fpc-pascal


> On Apr 25, 2020, at 8:49 PM, Michael Van Canneyt  
> wrote:
> 
> It will run on a server that never installed lazarus.

Excellent. Where are the caches kept btw? I thought they were in the Lazarus 
directory but I guess not.

Regards,
Ryan Joseph

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


Re: [fpc-pascal] Debug-Adapter-Protocol support for fpDebug

2020-04-25 Thread Ryan Joseph via fpc-pascal


> On Apr 24, 2020, at 3:10 AM, Joost van der Sluis  wrote:
> 
> I'm working on the support of the debug-adapter-protocol for fpDebug. It's 
> quite easy to implement, as there already is a json-based tcp/ip interface. 
> (https://microsoft.github.io/debug-adapter-protocol)

I use the debugger in VSCode and while LLDB works pretty well, short strings 
are always a problem. I've never used fpDebug though so I can't say if it's 
better than LLDB (I thought it was no very mature).

Regards,
Ryan Joseph

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


Re: [fpc-pascal] Debug-Adapter-Protocol support for fpDebug

2020-04-25 Thread Martin Frb

On 23/04/2020 22:10, Joost van der Sluis wrote:
But maybe it should become a separate package now. Lazarus can use is 
as a dependency. We'll see.


That would then reverse the burden

As it is part of bigide, it must be shipped with the installer.
And also having it in the Lazarus repro means that there is no issue 
with version incompatibilities.

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


Re: [fpc-pascal] Pascal Language Server

2020-04-25 Thread Michael Van Canneyt



On Sat, 25 Apr 2020, Ryan Joseph via fpc-pascal wrote:





On Apr 25, 2020, at 7:48 PM, Mattias Gaertner via fpc-pascal 
 wrote:

It's gpl/lgpl. Feel free to use parts.


sure, but does it does it depend on other systems which are installed from 
Lazarus or will a stand-alone binary run on a system that never installed 
Lazarus?


It will run on a server that never installed lazarus.

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


Re: [fpc-pascal] Pascal Language Server

2020-04-25 Thread Ryan Joseph via fpc-pascal


> On Apr 25, 2020, at 7:48 PM, Mattias Gaertner via fpc-pascal 
>  wrote:
> 
> It's gpl/lgpl. Feel free to use parts.

sure, but does it does it depend on other systems which are installed from 
Lazarus or will a stand-alone binary run on a system that never installed 
Lazarus?

Regards,
Ryan Joseph

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


Re: [fpc-pascal] Pascal Language Server

2020-04-25 Thread Mattias Gaertner via fpc-pascal
On Sat, 25 Apr 2020 19:43:32 +0700
Ryan Joseph via fpc-pascal  wrote:

> Is the following line something which can be cached? Currently this
> is going to be called very often but is it an expensive operation?
> Not sure what it does exactly
> 
> Code := CodeToolBoss.FindFile(URI.Path + URI.Document);

It does a binary search on the cached files. Should be barely
measurable.

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


Re: [fpc-pascal] Pascal Language Server

2020-04-25 Thread Mattias Gaertner via fpc-pascal
On Sat, 25 Apr 2020 19:29:41 +0700
Ryan Joseph via fpc-pascal  wrote:

>[...]
> Since we're so invested in code tools now what is actually required
> for users in terms of Lazarus? Can we just package a single binary
> which links to code tools or do users need to install an entire
> Lazarus setup? 

It's gpl/lgpl. Feel free to use parts.

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


Re: [fpc-pascal] Pascal Language Server

2020-04-25 Thread Ryan Joseph via fpc-pascal
Is the following line something which can be cached? Currently this is going to 
be called very often but is it an expensive operation? Not sure what it does 
exactly

Code := CodeToolBoss.FindFile(URI.Path + URI.Document);

Regards,
Ryan Joseph

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


Re: [fpc-pascal] Pascal Language Server

2020-04-25 Thread Ryan Joseph via fpc-pascal


> On Apr 25, 2020, at 6:51 PM, Mattias Gaertner via fpc-pascal 
>  wrote:
> 
> Hmm. Maybe "make distclean" does not remove all files. I wish, you had
> kept a copy.

It'll probably happen again. ;)

Since we're so invested in code tools now what is actually required for users 
in terms of Lazarus? Can we just package a single binary which links to code 
tools or do users need to install an entire Lazarus setup? 


Regards,
Ryan Joseph

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


Re: [fpc-pascal] Pascal Language Server

2020-04-25 Thread Mattias Gaertner via fpc-pascal
On Fri, 24 Apr 2020 15:55:44 +0700
Ryan Joseph via fpc-pascal  wrote:

> > On Apr 24, 2020, at 3:32 PM, Mattias Gaertner via fpc-pascal
> >  wrote:
> > 
> > Are there any ppu files left after "make distclean"?  
> 
> I just trashed the entire thing and started over. It was easier that
> way, much easier. It's working now so I'm happy. :)

Hmm. Maybe "make distclean" does not remove all files. I wish, you had
kept a copy.

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


Re: [fpc-pascal] Pascal Language Server

2020-04-25 Thread Joost van der Sluis

Op 25-04-2020 om 05:53 schreef Ryan Joseph via fpc-pascal

In the FPC streaming system with published properties, what type do I use for 
an array of strings? I've tried TStringList and TCollection but they give me 
errors like:

:: <~~ pascal-language-server 1: {'message': ' : Unsupported JSON type for object 
property: "jtArray"', 'code': -32603}


"initializationOptions" is a JSON array of strings, i.e. 
'initializationOptions': ['-Fu/path/to']


As I said before, the Cerialization-library is written with this kind of 
use-cases in mind. (https://gitlab.freepascal.org/Joost/cerialization)


Although that what you want should be possible with the default 
libraries using TStringList and some events...


Regards.

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


Re: [fpc-pascal] Pascal Language Server

2020-04-25 Thread Mattias Gaertner via fpc-pascal
On Sat, 25 Apr 2020 09:02:50 +0200
Mattias Gaertner via fpc-pascal  wrote:

> On Sat, 25 Apr 2020 12:03:55 +0700
> Ryan Joseph via fpc-pascal  wrote:
> 
> > I have FindCodeContext working correctly I believe because ProcName
> > from TCodeContextInfo returns the correct name of the function. In
> > TCodeContextInfoItem the params string list is nil though. Shouldn't
> > that contain the list of parameters? Not sure how this intended to
> > be used if that list of empty.  
> 
> Is X,Y inside the brackets?

The TCodeContextInfoItem.ProcName is set only for compiler built-in
functions.
Normal functions have an Expr<>nil.

See procedure TCodeContextFrm.CreateHints in
lazarus/ide/codecontextform.pas

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


Re: [fpc-pascal] Pascal Language Server

2020-04-25 Thread Ryan Joseph via fpc-pascal


> On Apr 25, 2020, at 2:02 PM, Mattias Gaertner via fpc-pascal 
>  wrote:
> 
>> I have FindCodeContext working correctly I believe because ProcName
>> from TCodeContextInfo returns the correct name of the function. In
>> TCodeContextInfoItem the params string list is nil though. Shouldn't
>> that contain the list of parameters? Not sure how this intended to be
>> used if that list of empty.
> 
> Is X,Y inside the brackets?

You mean ()? Yes it is. ParameterIndex also increments so for example

DoThis(a,b,c,^) 

will give ParameterIndex 4 if the cursor is at ^.

Is Params supposed to be a list of the parameters in the format "name: type"? 
If so that's what I need to return along with the parameter index. See

https://microsoft.github.io/language-server-protocol/specifications/specification-current/#textDocument_signatureHelp

Regards,
Ryan Joseph

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


Re: [fpc-pascal] Pascal Language Server

2020-04-25 Thread Mattias Gaertner via fpc-pascal
On Sat, 25 Apr 2020 12:03:55 +0700
Ryan Joseph via fpc-pascal  wrote:

> I have FindCodeContext working correctly I believe because ProcName
> from TCodeContextInfo returns the correct name of the function. In
> TCodeContextInfoItem the params string list is nil though. Shouldn't
> that contain the list of parameters? Not sure how this intended to be
> used if that list of empty.

Is X,Y inside the brackets?

Mattias

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