Re: [fpc-pascal] Can class function used in specialized class use intristic functions Low, High with generic type ?

2017-04-22 Thread Cyrax

On 20.04.2017 14:37, Sven Barth via fpc-pascal wrote:

Am 20.04.2017 13:02 schrieb "LacaK" :


Hi *,

I have some generic class:

generic T2DNumericArray = object(specialize T2DArray)
 public
   class function Truncate(Value: double): T; inline;
   ...

In class function Truncate I want check if supplied Value is in range of

T.

T will be always ordinal type (byte, integer) ... (I know this, but

compiler does not of course)


Can I use in :

class function T2DNumericArray.Truncate(Value: double): T;
begin
   if Value > High(T) then
 Result := High(T)
   else if Value < Low(T) then
 Result := Low(T)
   else
 Result := Value;
end;

I understand, that from compiler POV T can be any type, so High() and

Low() can be invalid, but I wonder if there is any way how to solve this.

The compiler will use dummy values while parsing the generic, but during
specialization it will use the correct ones. Though it might be that you'd
need 3.1.1 for it (dont know right now when I had fixed that).

Regards,
Sven



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



I think that this was the bug report and which you did fix back then : 



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

Re: [fpc-pascal] Windows API SendMessage()

2017-08-09 Thread Cyrax

On 10/08/17 04:27, James Richters wrote:

I'm trying to use SenMessage() to turn the display on or off under program
control of a console application.I got the function to work, and it
turns off the display, but then the program just hangs.

Does anyone know what I am doing wrong?

  


Here's my sample program

Program Displaycontrol;

Uses Windows;

Begin

   Writeln('Turning Off Display');

   SendMessage(HWND_BROADCAST, WM_SYSCOMMAND, SC_MONITORPOWER, 2);
//This seems to work, turning off my display

   Writeln('Display is Off');  // This Writeln never
happens.I need to force terminate the program.

   sleep(1);

   Writeln('Turning On Display');

   SendMessage(HWND_BROADCAST, WM_SYSCOMMAND, SC_MONITORPOWER, -1);

   Writeln('Display is On');

End.

  


James




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



You need to use PostMessage if you want to your program to work 
correctly. SendMessage waits reply and you don't have a message pump in 
your console application, thus a hang happens.


SendMessage : 
https://msdn.microsoft.com/en-us/library/windows/desktop/ms644950(v=vs.85).aspx


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

Re: [fpc-pascal] Best way to insert bytes into a TBytes variable?

2017-07-28 Thread Cyrax

On 27/07/17 18:17, nore...@z505.com wrote:

On 2017-07-25 11:00, Martok wrote:

Ideally the function should be portable between FPC and Delphi XE5...
You'd only need your own functions for Delphi, FPC's intrinsics such 
as Insert()

can already work with arrays:

var
  b, c: TBytes;
begin
  b:= TBytes.Create(1,2,3);
  c:= TBytes.Create(10,11);
  Insert(c,b,2);

-> b is now [1,2,10,11,3]




The fpc wiki should probably be updated?

I cannot find "insert" on this page:
http://wiki.freepascal.org/Array

I cannot find it here either:
https://www.freepascal.org/docs-html/ref/refsu14.html

For the last 10 years or so I've been criticizing occasionally the fact 
that everyone reinvents their own array algorithms for each array! So it 
seems that may solve it. In fact this problem goes back to the 1970's 
and 1980's when arrays were being used.


Please list other functions other than insert that are available? Maybe 
someone add it to the wiki/docs

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


AFAIK, that is avaible only in the trunk version of FPC. You need to 
build the trunk version of the documents by yourself.


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

Re: [fpc-pascal] Building trunk

2018-11-29 Thread Cyrax

On 30/11/2018 00:53, C Western wrote:

On 26/11/2018 22:46, - - wrote:
An additional note - it may well be a ld version issue. On Ubuntu the 
ld version is 2.30, but on Fedora ld reports 2.31.1-13.fc29. (Maybe I 
should have held off upgrading to Fedora 29...)


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


Looking at this a little more I think the headers are simply not 
available to the program. Simply commenting out the INITTLS call allows 
the compiler to be built successfully. I note that multi-threaded 
programs don't call it (at least those using cthreads) and if the 
program isn't multi-threaded the call to INITTLS is most likely not 
needed so I suspect this would fix most use cases. My main non-gui 
program (multi-threaded) runs fine. However on Fedora 29 32 bit builds 
on 64 bit systems are broken for lazarus because the 32 bit -devel 
packages are broken:


https://bugzilla.redhat.com/show_bug.cgi?id=1651231

https://bugzilla.redhat.com/show_bug.cgi?id=1645328

so maybe I should just conclude that 32 bit apps are broken on Fedora.

Colin

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


Can you test if patch from my bug report 
https://bugs.freepascal.org/view.php?id=34475> fixes your problem? 
You can omit changes for x86_64 target from that patch.



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

Re: [fpc-pascal] Building trunk

2018-11-30 Thread Cyrax

On 30/11/2018 11:12, C Western wrote:

On 30/11/2018 04:23, Cyrax wrote:

On 30/11/2018 00:53, C Western wrote:

On 26/11/2018 22:46, - - wrote:
An additional note - it may well be a ld version issue. On Ubuntu 
the ld version is 2.30, but on Fedora ld reports 2.31.1-13.fc29. 
(Maybe I should have held off upgrading to Fedora 29...)


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


Looking at this a little more I think the headers are simply not 
available to the program. Simply commenting out the INITTLS call 
allows the compiler to be built successfully. I note that 
multi-threaded programs don't call it (at least those using cthreads) 
and if the program isn't multi-threaded the call to INITTLS is most 
likely not needed so I suspect this would fix most use cases. My main 
non-gui program (multi-threaded) runs fine. However on Fedora 29 32 
bit builds on 64 bit systems are broken for lazarus because the 32 
bit -devel packages are broken:


https://bugzilla.redhat.com/show_bug.cgi?id=1651231

https://bugzilla.redhat.com/show_bug.cgi?id=1645328

so maybe I should just conclude that 32 bit apps are broken on Fedora.

Colin

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


Can you test if patch from my bug report 
https://bugs.freepascal.org/view.php?id=34475> fixes your 
problem? You can omit changes for x86_64 target from that patch.



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


This is loader-abitag.diff? With that applied, both 64 and 32 bit fpc 
trunk build, and basic testing indicates that they are working fine. I 
note however that compiling a basic "Hello World" program now produces a 
dynamically linked, rather than a statically linked executable, and 
INITTLS is not called.


Colin

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


Strange. All my (32/64 bits) binaries are static ones.

What I can see at seeing the source code is that INITTLS is only defined 
for i386 target.


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

Re: [fpc-pascal] Building trunk

2018-11-30 Thread Cyrax

On 30/11/2018 12:23, Cyrax wrote:

On 30/11/2018 11:12, C Western wrote:

On 30/11/2018 04:23, Cyrax wrote:

On 30/11/2018 00:53, C Western wrote:

On 26/11/2018 22:46, - - wrote:
An additional note - it may well be a ld version issue. On Ubuntu 
the ld version is 2.30, but on Fedora ld reports 2.31.1-13.fc29. 
(Maybe I should have held off upgrading to Fedora 29...)


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


Looking at this a little more I think the headers are simply not 
available to the program. Simply commenting out the INITTLS call 
allows the compiler to be built successfully. I note that 
multi-threaded programs don't call it (at least those using 
cthreads) and if the program isn't multi-threaded the call to 
INITTLS is most likely not needed so I suspect this would fix most 
use cases. My main non-gui program (multi-threaded) runs fine. 
However on Fedora 29 32 bit builds on 64 bit systems are broken for 
lazarus because the 32 bit -devel packages are broken:


https://bugzilla.redhat.com/show_bug.cgi?id=1651231

https://bugzilla.redhat.com/show_bug.cgi?id=1645328

so maybe I should just conclude that 32 bit apps are broken on Fedora.

Colin

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


Can you test if patch from my bug report 
https://bugs.freepascal.org/view.php?id=34475> fixes your 
problem? You can omit changes for x86_64 target from that patch.



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


This is loader-abitag.diff? With that applied, both 64 and 32 bit fpc 
trunk build, and basic testing indicates that they are working fine. I 
note however that compiling a basic "Hello World" program now produces 
a dynamically linked, rather than a statically linked executable, and 
INITTLS is not called.


Colin

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


Strange. All my (32/64 bits) binaries are static ones.

What I can see at seeing the source code is that INITTLS is only defined 
for i386 target.


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


Oh, I forgot to mention that I use Arch Linux. I run the i686 and x86_64 
versions of Arch as an LXC containers.


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

Re: [fpc-pascal] Building trunk

2018-11-25 Thread Cyrax

On 25/11/2018 14:58, Jonas Maebe wrote:

On 25/11/18 13:51, Florian Klämpfl wrote:
I am not aware that somewhere a fixed offset is applied. All info is 
read from the auxiliary data and the header.


You can have a load address offset in case there is a PT_PHDR. From 
http://www.gabriel.urdhr.fr/2015/01/22/elf-linking/ :


// Simplified code from the GNU dynamic linker source code:
for (ph = phdr; ph < [phnum]; ++ph)
   if (ph->p_type == PT_PHDR)
     main_map->l_addr = (ElfW(Addr)) phdr - ph->p_vaddr;

There doesn't seem to be one in Colin's program though.


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


Somehow this thread reminds my one open bug : 
https://bugs.freepascal.org/view.php?id=34475


I have found out that you need to have either linked against libc or 
have small binary stub generated from assembler source (like 64-bit 
pascal programs/libraries have that doesn't link against libc) linked 
against your 32-bit program so it can access PHDR structure without 
crashing on access violation exception.


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

Re: [fpc-pascal] bug in make install ?

2019-03-26 Thread Cyrax

On 24.3.2019 19.36, Bart wrote:

On Sun, Mar 24, 2019 at 6:10 PM Joost van der Sluis  wrote:


Note: I see several times a window (console?) flash when starting up
Lazarus now.
Maybe add poNoConsole to ProcessOptions ?
It's a bit annoying now.


Can you test if this actually works on Windows (on Linux this is not an
issue)


I added poNoConsole to the 2 occasions of TProcessUtf8 I could fine in
InitialSetupDlg, but I still see 2 console windows flashing by.

Adding [poNoconsole] may also prevent the program in question to write
output to StdOut?
But since we're using pipes, that should not matter?

Sorry, I just never use that stuff in my programs.

Bart



Does adding clauses for TProcess.StartupOptions := [suoUseShowWindow] 
and TProcess.ShowWindow := swoHIDE help?


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

Re: [fpc-pascal] Compile for WinCE 7, target ARM, CPU Cortex-A9

2019-04-09 Thread Cyrax

On 9.4.2019 12.45, LacaK wrote:









    Note that you probably don't need two different cross
    compilers if your cpu-OS target is the same


    Target CPU family is same: "arm", but Target processor is not
    the same: "ARMv4" versus "ARMv7" ...

    So I do not know if this requires two pre-compiled
    cross-compilers or not?

    You only need different compilers if you have different ABIs
    (e.g. Soft Float vs. Hard Float). For WinCE that isn't applicable
    however.


    So it does not matter how I build cross-compiler using
    FpcUpDeluxe: wheter I use "-Cparmv5" or "-Cparmv7A" ?


Correct.

    Then there is still problem with precompiled RTL/packages?

    Because when I only change "Target processor" (in Lazarus build
    using FpcUpDeluxe) I can compile application, but I can not run it
    on target system (so I guess, that resulting EXE is not compiled
    for target processor).

    When I add to Custom options: -CfVFPV2 then I get error while
    compiling: Fatal: Can't find unit system used by Test1

    When I download and install default Lazarus and cross-compiler
    then when I change "Target processor" to "ARMv5" or "ARMv7A" I
    get: "project1.lpr(22,0) Error: Error while assembling exitcode 1"


As said by Christo you need to select the correct set of compiled 
units. Also you need to select the correct processor type when 
building your application.



I did this test:

1. I have precompiled units for "-Cparmv5" and "-Cparmv7A"and I have 
saved these precompiled units
2. Then I copy "v5" units to expected directory (of FpcUpDeluxe 
structure) fpc\units\arm-wince
3. Then I run Lazarus and try build for Target processor ARMv5 and run 
on target system ... works


4. Then I have copied "v7" units over prior "v5" units
5. I repeated step 3 ... works on target system with ARMv7 processor

Until now only question is :
Can I set somewhere (in Project Options), in inteligent way, where 
compiler will look for precompiled units ... to be able in one project 
switch between Build modes, where each build mode will look in other 
directory ?


But when I try set also "-CfFPV2" (in Project Options / Custom Options ) 
then I get:


Fatal: Cannot find system used by fcllaz. Make sure all ppu files of a 
package are in its output directory. ppu in wrong 
directory=D:\TEMP\fpcupdeluxe\fpc\units\arm-wince\rtl\system.ppu..


I can resolve this error (beside using precompiled units with same flag 
set) by adding "-CfFPV2" also in fpc.cfg after:

#IFDEF FPC_CROSSCOMPILING
#IFDEF WINCE
#IFDEF CPUARM

So in this use case it is not sufficient only have two (or third) 
distinct sets of precompiled units ...


So can these problems be solved somehow using only Project Options 
without need to modify fpc.cfg ?


Btw. in fpc.cfg I have:
# searchpath for units and other system dependent things
-FuD:\TEMP\fpcupdeluxe\fpc/units/$fpctarget
-FuD:\TEMP\fpcupdeluxe\fpc/units/$fpctarget/*
-FuD:\TEMP\fpcupdeluxe\fpc/units/$fpctarget/rtl

Can this be avoided in fpc.cfg and transfered to Project Options ? (is 
/* supported in Lazarus, becuase Lazarus complains about non-existent 
directory)


TIA

-Laco.



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



You can use IDE macros in path names at Project Options.

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

Re: [fpc-pascal] Getting multiple files from GetOpenFileNameA

2019-05-21 Thread Cyrax

On 21.5.2019 22.12, James Richters wrote:

This is the function I came up with to use GetOpenFileNameA() to get multiple 
files, and put the file names all into a StringList.

I think I am doing something fundamentally wrong here because I can run this in 
a loop sometimes 2 or 4 times, or sometimes 30 times, and it seems to work but 
eventually my program crashes with an access violation at various different 
points.. it's not always the same point in the program that crashes, but if I 
rig this to only build the stringlist once, I can run the rest of the process 
over and over including the GetOpenFileNameA() without issues.   I wonder if my 
method of putting the files names into the stringlist is flawed, I made it up 
myself based on what I could gather from the documentation of 
GetOpenFileNameA(),  maybe I am missing something.. or maybe the way I'm 
setting the string list to nil and then re-creating it is causing an issue?   
The Writeln's I put in seem to be what I expect, but still it crashes at some 
point when I run this in a loop.   Below is my procedure, can anyone see 
anything I am doing in a bad way that would cause the instability I am 
experiencing?

I am freeing the stringlist first thing, and I only create a new one if 
GetOpenFileNameA()is successful.  Then later on I check for the existence of 
the stringlist and if it's there, I process my files, the loop back and run 
this again, if not, I just exit, because if the string list does not exist then 
GetOpenFileNameA() was closed without selecting any files, so the process is 
complete.

Another issue with this  I am only able to select 6 or 7 files with this 
and then GetOpenFileNameA() returns with False... I suspect I need to make a 
memory buffer for more files but don't know how to do that, anyone have any 
advice on how to fix that?


Procedure GetFilesIntoStringlist;
Begin
IF (File_Stringlist<>Nil) Then
   FreeAndNil(File_Stringlist);
fillchar(TFileName, sizeof(TFileName), 0);
TFileName.lStructSize:=sizeof(TFileName);
TFileName.hwndOwner:=0;
TFileName.lpstrFile:=ret;
TFileName.lpstrFile[0]:=#0;
TFileName.nMaxFile:=100;
TFileName.Flags := OFN_EXPLORER or OFN_FILEMUSTEXIST or 
OFN_ALLOWMULTISELECT;
TFileName.lpstrDefExt:='';
TFileName.lpstrTitle:='Production Automation Open Dpax File:';
TFileName.lpstrFilter:='Draw.Pax Files (*.DPax)'+#0+'*.DPax'+#0;
If Drawpaxfilename<>'' then
   Begin
  TFileName.lpstrFile:=Pchar(Drawpaxfilename+'DPax'+#0);
  TFileName.lpstrInitialDir:=Pchar(ExtractFilePath(Drawpaxfilename)+#0);
   End;
OpenFileResult:=GetOpenFileNameA(@TFilename);
If OpenFileResult then
   Begin
  Textcolor(10);
  IF File_Stringlist=Nil Then
 File_Stringlist:=TStringlist.Create;
  Loopx:=-1;
  filenum:=0;
  Repeat
 Filenamestr:='';
 Repeat
Inc(Loopx);
if TFileName.lpstrFile[loopx]<>#0 Then
   begin
  Write(TFileName.lpstrFile[loopx]);
  Filenamestr:=Filenamestr+TFileName.lpstrFile[loopx];
   end;
 Until TFileName.lpstrFile[loopx]=#0;
 Writeln;
 File_Stringlist.add(Filenamestr);
  Until TFileName.lpstrFile[loopx+1]=#0;
  Textcolor(14);
  If File_Stringlist.Count=1 then
 Writeln(File_Stringlist.Count,' File Selected')
  Else
 Writeln(File_Stringlist.Count-1,' Files Selected');
   End;
End;

James


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



It looks like that you are using the type name directly (TFileName). 
Where is TFileName defined?



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

Re: [fpc-pascal] Challenge accepted

2019-08-15 Thread Cyrax

On 15/08/2019 00:14, Joost van der Sluis wrote:

Op 11-08-19 om 12:28 schreef Michael Van Canneyt:

[snip]


Another thing, can you help me setting up some kind of git-repository on 
the FPC-infrastructure? Or don't you have any plans in that direction?


Regards,

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


You could do that by yourself by using local svn mirror of FPC (so you 
don't stress orginal source if the git mirror creation goes awry) 
repository and subgit (https://subgit.com/> needs java (!!!) [use 
64-bit one] and decent amount memory, 16GB+ is suffcient and some swap 
space, too).


subgit saves whole SVN history beatifully and have some speed 
improvements and other optimizations over standard git-svn command.


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


Re: [fpc-pascal] Generic type conflicts

2019-11-02 Thread Cyrax via fpc-pascal

On 02/11/2019 16:55, Ryan Joseph via fpc-pascal wrote:

I've wanted to make a generic version of a vector for a while but I always give 
up because it seems not very possible. It's probably not even a great idea 
because many methods don't translate between float and integer but I wanted to 
prevent other code duplication if possible.

Here's an example of how things break down. Are there any solutions for this 
currently? I feel like generics need to support some compiler directives so 
different blocks of code can specialize different depending on the type.

{$mode objfpc}
{$modeswitch advancedrecords}

program generic_vector_2;
uses
   Math;

type
   generic TVec2 = record
 x, y: TScalar;
 function Normalize: TVec2;
   end;
   TVec2f = specialize TVec2;
   TVec2i = specialize TVec2;

function TVec2.Normalize: TVec2;
var
   fac: TScalar;
begin
   // Can't determine which overloaded function to call
   // Incompatible types: got "Extended" expected "LongInt"
   fac:=Sqrt(Sqr(x) + Sqr(y));
   if fac<>0.0 then begin
 // Incompatible types: got "Single" expected "LongInt"
 fac:=1.0/fac;
 result.x:=x*fac;
 result.y:=y*fac;
   end else begin
 result.x:=0;
 result.y:=0;
   end;
end;

begin
end.

Regards,
Ryan Joseph

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



You need to do a explicit typecasting.

...
fac:=Sqrt(Sqr(TScalar(x)) + Sqr(TScalar(y)));
...
fac:=1.0/TScalar(fac);

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