Re: [fpc-pascal] Codetools, identity nodes from includes

[Ryan Joseph via fpc-pascal]

> On Jul 7, 2020, at 4:57 AM, Mattias Gaertner via fpc-pascal 
>  wrote:
> 
> Something like this:
> 
> Node:=AItem.Node;
> if Node<>nil then
> begin
>  Scanner:=Tool.Scanner;
>  LinkIndex:=Scanner.LinkIndexAtCleanPos(Node.StartPos);
>  if LinkIndex<0 then
>// dangling node, e.g. syntax error
>  else
>InIncludeFile:=Scanner.LinkP[LinkIndex]^.Code<>Scanner.MainCode;
> end else
>  ; // artificial node, e.g. intrinsic

works well, thanks.

Regards,
Ryan Joseph

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

Re: [fpc-pascal] FPC for Win64

[Rainer Stratmann]

Am Samstag, 4. Juli 2020, 20:02:39 CEST schrieb Graeme Geldenhuys:
> On 02/07/2020 9:30 pm, Evert van Dijken via fpc-pascal wrote:
> > I see a WIN32 compiler and a WIN64 cross
> > compiler. How it works is a mystery for me.
> 
> I never understood the choice FPC made to not create a native 64-bit
> compiler, but rather stay with a cross-compiler. *shrug*
> I've always simply downloaded the latest release source code, and
> built my own native 64-bit FPC with the previous FPC release.
> 
> I've done this for 10 years - simply because 10 years ago (there
> about) I had issues with the cross-compiler generating broken
> executables. Obviously that could have been a local problem, but
> either way, I didn't trust them since. So I compile my own
> native 64-bit version (just like I did for Linux and FreeBSD).

For Linux: Does that mean apt-get install lazarus is always the 32bit version?
Regardless of the Linux Version (32bit or 64bit).
 
> 
> Regards,
>   Graeme




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

Re: [fpc-pascal] FPC for Win64

[Marco van de Voort]

Op 07/07/2020 om 09:14 schreef Rainer Stratmann:

For Linux: Does that mean apt-get install lazarus is always the 32bit version?
Regardless of the Linux Version (32bit or 64bit).
   

No. The reason for no 64-bit compiler is specific to Windows 64-bit.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] TProcess.CurrentDirectory doc

[Marco van de Voort]

Op 07/07/2020 om 07:44 schreef Michael Van Canneyt:

need more info there! a) what happens when the process, eg Bash 
file, changes its working dir (via "cd") many times and I read 
CurrentDirectory eg during OnReadData (ASyncProcess)? do I get 
changed cur-dir, or initial dir? b) do i get changed dir on all 
OSes? c) if Bash file runs child bash file which changes cur-dir, do 
i get changed dir?


No, because it is the *initial* directory only.

I changed the docs, no need to submit a report.

I quickly walked through the tprocess docs and most new things in 3.2.0 
are nicely documented, nice!  Just two emergency changes from May 
aren't, and might need rerunning makeskel for it.


See two identifiers without description in 
https://www.freepascal.org/docs-html/current/fcl/process/tprocessoptions.html


porunidle:  Run  Runidle event.  By default this is a sleep (to avoid 
busy waiting with long living processes)


podetached: Windows specific alternative to poNoConsole.   Still creates 
a console handle even if it doesn't show it. 
(https://forum.lazarus.freepascal.org/index.php/topic,49631.0)



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

Re: [fpc-pascal] Codetools, identity nodes from includes

[Mattias Gaertner via fpc-pascal]

On Tue, 7 Jul 2020 14:09:09 +0700
Ryan Joseph via fpc-pascal  wrote:

> > On Jul 7, 2020, at 4:57 AM, Mattias Gaertner via fpc-pascal
> >  wrote:
> > 
> > Something like this:
> > 
> > Node:=AItem.Node;
> > if Node<>nil then
> > begin
> >  Scanner:=Tool.Scanner;

Scanner:=AItem.Tool.Scanner;

> >  LinkIndex:=Scanner.LinkIndexAtCleanPos(Node.StartPos);
> >  if LinkIndex<0 then
> >// dangling node, e.g. syntax error
> >  else
> >InIncludeFile:=Scanner.LinkP[LinkIndex]^.Code<>Scanner.MainCode;
> > end else
> >  ; // artificial node, e.g. intrinsic  

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

Re: [fpc-pascal] FPC for Win64

[Rainer Stratmann]

Am Dienstag, 7. Juli 2020, 09:42:54 CEST schrieb Marco van de Voort:
> Op 07/07/2020 om 09:14 schreef Rainer Stratmann:
> > For Linux: Does that mean apt-get install lazarus is always the 32bit
> > version? Regardless of the Linux Version (32bit or 64bit).
> 
> No. The reason for no 64-bit compiler is specific to Windows 64-bit.

Then how to install a 32-bit Lazarus/FPC on a 64-bit Linux Debian System?



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

[fpc-pascal] fpDebug function-call proof-of-concept

[Joost van der Sluis]

Hi all,

Last weekend I started on the ability to evaluate functions within 
fpDebug. And I got quite far. It is a proof-of-concept, still needs a 
lot of work. But it works!


See it in action here:

http://amira.cnoc.nl/fpc/FpDebugCallProofOfconcept.gif

Regards,

Joost.


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

Re: [fpc-pascal] FPC for Win64

[Tomas Hajny]

On 2020-07-07 10:28, Rainer Stratmann wrote:

Am Dienstag, 7. Juli 2020, 09:42:54 CEST schrieb Marco van de Voort:

Op 07/07/2020 om 09:14 schreef Rainer Stratmann:
> For Linux: Does that mean apt-get install lazarus is always the 32bit
> version? Regardless of the Linux Version (32bit or 64bit).

No. The reason for no 64-bit compiler is specific to Windows 64-bit.


Then how to install a 32-bit Lazarus/FPC on a 64-bit Linux Debian 
System?


In general - talking about tools like apt, these provide means for 
selecting the requested architecture (32-bit or 64-bit). Whether the 
respective packages are ready for such tools is another question and 
more appropriate for people responsible for packages in the individual 
Linux distributions.


As far as FPC is concerned, there's nothing preventing you to install 
the 32-bit version on a 64-bit Linux Debian system. I believe that 
there's no ready-made package providing a 32-bit hosted 64-bit 
cross-compiler for Linux in our builds at the moment, because it's 
easier to install both 32-bit and 64-bit versions side by side in cases 
like this (i.e. the cross-compiler would be really needed only for users 
interested in building 64-bit applications on a 32-bit machine, but 
there probably aren't too many people with such a need and they can 
always build it for themselves). I can't talk about Lazarus.


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

Re: [fpc-pascal] fpDebug function-call proof-of-concept

[Christo Crause via fpc-pascal]

On Tue, 7 Jul 2020, 11:17 Joost van der Sluis,  wrote:

> Hi all,
>
> Last weekend I started on the ability to evaluate functions within
> fpDebug. And I got quite far. It is a proof-of-concept, still needs a
> lot of work. But it works!
>

Great news! I guess this is a step towards evaluating object properties via
get methods?

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

Re: [fpc-pascal] fpDebug function-call proof-of-concept

[Sven Barth via fpc-pascal]

Joost van der Sluis  schrieb am Di., 7. Juli 2020, 11:17:

> Hi all,
>
> Last weekend I started on the ability to evaluate functions within
> fpDebug. And I got quite far. It is a proof-of-concept, still needs a
> lot of work. But it works!
>
> See it in action here:
>
> http://amira.cnoc.nl/fpc/FpDebugCallProofOfconcept.gif


Very nice! Looking forward to further improvements here. :)

By the way: how do you use it from within VS Code? Is that some generic
debug interface?

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

Re: [fpc-pascal] fpc-pascal Digest, Vol 193, Issue 2

[Tomas Hajny]

On 2020-07-03 18:44, Sven Barth via fpc-pascal wrote:

Can it be that you replied to the wrong
message? ;) (see below)


I suspect that it was an automated reply (out-of-office message). :/ 
Ceterum censeo automated replies delenda sunt. ;-) Let's take it as an 
opportunity to remind everybody that if (s)he needs to set up such a 
reply for the holiday period (on mailboxes subscribed to one of FPC 
lists), the lists should be added to the exceptions for not receiving 
such replies - any decent mail server should allow such setting.


Btw, if somebody knows an e-mail header allowing to distinguish such 
replies from regular e-mails, contact me privately.


Thanks

Tomas
(one of FPC lists moderators)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] fpDebug function-call proof-of-concept

[Joost van der Sluis]

Op 07-07-2020 om 12:41 schreef Christo Crause via fpc-pascal:
On Tue, 7 Jul 2020, 11:17 Joost van der Sluis, > wrote:


Last weekend I started on the ability to evaluate functions within
fpDebug. And I got quite far. It is a proof-of-concept, still needs a
lot of work. But it works!


Great news! I guess this is a step towards evaluating object properties 
via get methods?


That is the final goal, yes.

Regards,

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

Re: [fpc-pascal] fpDebug function-call proof-of-concept

[Joost van der Sluis]

Op 07-07-2020 om 14:17 schreef Sven Barth via fpc-pascal:
Joost van der Sluis mailto:jo...@cnoc.nl>> schrieb am 
Di., 7. Juli 2020, 11:17:


Hi all,

Last weekend I started on the ability to evaluate functions within
fpDebug. And I got quite far. It is a proof-of-concept, still needs a
lot of work. But it works!

See it in action here:

http://amira.cnoc.nl/fpc/FpDebugCallProofOfconcept.gif


Very nice! Looking forward to further improvements here. :)

By the way: how do you use it from within VS Code? Is that some generic 
debug interface?


I am using this plugin: (Please install and give feedback)
https://marketplace.visualstudio.com/items?itemName=CNOC.fpdebug

Well, actually I wrote it:
https://gitlab.freepascal.org/Joost/vscode-fpdebug

It's using Microsoft's debug-adapter-protocol (DAB), a generic protocol 
that can be used to glue editors and debuggers together:

https://code.visualstudio.com/blogs/2018/08/07/debug-adapter-protocol-website/

I wrote a version of fpDebug that implements this protocol. In principle 
it should also work with other editors that implement this protocol:

https://gitlab.freepascal.org/Joost/fpdserver

Regards,

Joost.



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

[fpc-pascal] properties // Re: fpDebug function-call proof-of-concept

[Martin Frb]

On 07/07/2020 15:04, Joost van der Sluis wrote:


Op 07-07-2020 om 12:41 schreef Christo Crause via fpc-pascal:


Great news! I guess this is a step towards evaluating object 
properties via get methods?


That is the final goal, yes.


For this, we will need to start looking at improving the DWARF info.
And most probably adding some vendor specific info.

Afaik, even Dwarf 5 does not supply those

We should probably start a wiki on this

1) Encoding a property. This could be done by:
- Currently properties already point to the Field.
  That could in future be: point to either the field or the getter. => 
Thus any debugger could read the info.
  The type of the property might point to a function declaration (for 
other debuggers)


- Adding a DW_AT_fpc_type_property attribute to the type, so FpDebug 
knows it is a property
  This would be added to DW_Tag_Member  Or for global properties to 
DW_Tag_Variable.
  => FpDebug would (in case of a function) show the property as the 
result type of the function.    (that does not apply for function refs)


- Adding a sub tag    DW_TAG_fpc_setter
  This contains the description of the setter/or the field
  It could be left empty, if the outer TAG describes a field, and the 
setter is direct field access.


The absence of the DW_TAG_fpc_setter would mean a read-only property
Alternatively the outer tag can have DW_AT_fpc_type_property_readable 
DW_AT_fpc_type_property_writeable



2) Extra info for managed data (ansistring, dyn array, smart pointer)
Managed data needs to be marked with DW_AT_fpc_managed
Also maybe DW_AT_fpc_managed_copy_on_write
- This would also make ansistrings distinguishable from 
pchar/array-of-char. Though for that ansistring could also have 
DW_AT_fpc_longstring.


There would also need to be info on
- initial default value: nil
- incref / decref
- alloc mem, for initializing/changing with a value that the user 
specified in the debugger

  Foo('abc') needs to create a string 'abc'.
  Modifying the value of an existing string, also needs this.

3) calling convention?
Not sure what information already exists.



Outside the scope of function calling:

- the dwarf info for nested procedures, and the outer variables that 
they can access, could be improved.

Currently there is some scope info lacking.

- Each unit should have a list of other units, in correct search order.
So global symbols can be found according to pascal scope.

- file of text /file of record
I still haven't figured out what the dwar specs try to archive with 
their definition.

It defines a type, but there is no data to be viewed.
Some users have pointed to what "stabs" did => exposing the internal 
filehandle, so one can see if the file is open. Not exactly "correct" 
but more useful than what dwarf offers.

I have no idea/preference what should happen on this. Just throwing it in.

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

Re: [fpc-pascal] fpc-pascal Digest, Vol 193, Issue 2

[Sven Barth via fpc-pascal]

Tomas Hajny  schrieb am Di., 7. Juli 2020, 14:33:

> On 2020-07-03 18:44, Sven Barth via fpc-pascal wrote:
> > Can it be that you replied to the wrong
> > message? ;) (see below)
>
> I suspect that it was an automated reply (out-of-office message). :/
> Ceterum censeo automated replies delenda sunt. ;-) Let's take it as an
> opportunity to remind everybody that if (s)he needs to set up such a
> reply for the holiday period (on mailboxes subscribed to one of FPC
> lists), the lists should be added to the exceptions for not receiving
> such replies - any decent mail server should allow such setting.
>

Detlef already confirmed to me privately that he'd replied to the wrong
message ;)


> Btw, if somebody knows an e-mail header allowing to distinguish such
> replies from regular e-mails, contact me privately.
>

Even if there'd be a standard for that, I bet that enough such auto-reply
systems would do their own thing 🙄

Regards,
Sven

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