Recent Posts

Pages: [1] 2 3 ... 10
Third party / Re: Fpcupdeluxe
« Last post by marcov on Today at 09:38:11 am »
(should be fixed, at least I read on core)
Thanks, your description is rather encouraging. For arrays, the D ones work in GDB since it supports D officially. Otherwise yes it's DWARF debugger... D tooling is a bit inconsistent with that. Under windows that's a mess i don't want to deal with.

No i also remember that last time i tried to write a correct GDBMI parser the main issue encountered was that my process didn't get full answers from GDB. I've seen that Laz uses a special process derived from TAsyncProcess, probably because of the same problem... gotta look at this as well.
General / Re: Alias for Int64
« Last post by Thaddy on Today at 09:17:28 am »
I wrote "and family"   :D but of course you are correct.
Doesn't mean they are not missing in that particular part of the docs.
General / Re: Alias for Int64
« Last post by PascalDragon on Today at 09:12:06 am »
NativeInt and NativeUInt were only added for Delphi compatibility. The types we consider as the corresponding types for the processors native integer size are PtrInt and PtrUInt respectively.
General / Re: TIniFile inside dropbox folder
« Last post by Thaddy on Today at 09:10:16 am »
File locking during sync?
Third party / Re: Fpcupdeluxe
« Last post by avra on Today at 09:09:20 am »
gives me an error when compiling a unit called dom.pp.
I confirm this with 32-bit FPC 3.2 fixes on Win10x64 using fpcupdeluxe 1.6.2h and 1.6.2.i

Start compiling package fcl-xml for target i386-win32.
       Compiling fcl-xml\BuildUnit_fcl_xml.pp
       Compiling .\fcl-xml\src\xmlutils.pp
       Compiling .\fcl-xml\src\dom.pp
       Compiling .\fcl-xml\src\dtdmodel.pp
External command "C:/Prg/Lazarus/Fixes20x32x/fpcsrc/compiler/ppc386.exe -Twin32 -FUfcl-xml\units\i386-win32\ -FuC:\Prg\Lazarus\Fixes20x32x\fpcsrc\rtl\units\i386-win32\ -FuC:\Prg\Lazarus\Fixes20x32x\fpcsrc\packages\fcl-base\units\i386-win32\ -FuC:\Prg\Lazarus\Fixes20x32x\fpcsrc\packages\fcl-res\units\i386-win32\ -FuC:\Prg\Lazarus\Fixes20x32x\fpcsrc\packages\rtl-objpas\units\i386-win32\ -Fufcl-xml\src -Fifcl-xml\src -Ur -Xs -O2 -n -vw-n-h-l-d-u-t-p-c- -di386 -dRELEASE -XX -CX -Sc -S2h -viq fcl-xml\BuildUnit_fcl_xml.pp" failed with exit code 1. Console output:
Target OS: Win32 for i386
Compiling fcl-xml\BuildUnit_fcl_xml.pp
Compiling .\fcl-xml\src\xmlutils.pp
Compiling .\fcl-xml\src\dom.pp
Compiling .\fcl-xml\src\dtdmodel.pp
dom.pp(1283,92) Error: Call by var for arg no. 3 has to match exactly: Got "UnicodeString" expected "AnsiString"
dom.pp(1304,50) Error: Call by var for arg no. 3 has to match exactly: Got "UnicodeString" expected "AnsiString"
dom.pp(3599) Fatal: There were 2 errors compiling module, stopping
Fatal: Compilation aborted

The installer encountered the following error:
Compilation of "BuildUnit_fcl_xml.pp" failed
make[2]: *** [smart] Error 1
make[2]: Leaving directory `C:/Prg/Lazarus/Fixes20x32x/fpcsrc/packages'
make[1]: *** [packages_smart] Error 2
make[1]: Leaving directory `C:/Prg/Lazarus/Fixes20x32x/fpcsrc'
make: *** [build-stamp.i386-win32] Error 2
make: Leaving directory `C:/Prg/Lazarus/Fixes20x32x/fpcsrc'

fpcupdeluxe: ERROR: FPCNativeInstaller (CleanModule: FPC): Error running make for FPC failed with exit code 2
. Details:

ERROR: Fpcupdeluxe fatal error !
General / TIniFile inside dropbox folder
« Last post by bobkos on Today at 06:36:48 am »
Hello everyone,

Just recently found that the TIniFile created inside dropbox may have strange behavior comparing to the same file created to local drive or for example onedrive folder. I suppose this is happening because of fast open, modify and close of the target file and dropbox client cannnot deal with it in a proper way. For more details I've recorded a small video, please find the link below:

The sample code is attached.

Does some one have any idea why this is happening?
OK, my guess is that the FMX code has little or no LCL, probably just uses FCL ?

Now, I'm sure someone will correct me but ....
The FPC / Lazarus can be broadly divided into, wait for it, FPC and Lazarus. FPC is closely linked to the FCL and together they are relatively static and stable. On the other hand, Lazarus is closely linked to LCL - that does change a bit more often and, in the case of the Cocoa stream, has gone from "you must be joking" to "looking pretty good mate!" in the time period you are talking about.

Now, are FMX components visible ones ?   Nice if they kept GUI stuff separate from network behavior....   Anyway, my guess is that in 2016, they would have assumed Carbon, quite possible its now just a recompile (and linking to new LCL) - one would hope so anyway.

Defines DARWIN and UNIX are used quite differently. MacOS is UNIX but its sure not LINUX for example. And executing the Darwin binary ?  All the assumed system stuff is different, even the executable format. But Lazarus is "Compile anywhere" !

Linux      F            T           F                      F
MacOS   T            T          T or F             T or F

I think we'll all be interested in how things work out - hope you'll get somewhere and tell us about it !


I am looking at the code in the

Code: Pascal  [Select]
  1. function TWin32WidgetSet.AddProcessEventHandler(AHandle: THandle;
  2.   AEventHandler: TChildExitEvent; AData: PtrInt): PProcessEventHandler;
  3. var
  4.   lProcessEvent: PProcessEvent;
  5. begin
  6.   if AEventHandler = nil then exit(nil);
  7.   New(lProcessEvent);
  8.   lProcessEvent^.Handle := AHandle;
  9.   lProcessEvent^.UserData := AData;
  10.   lProcessEvent^.OnEvent := AEventHandler;
  11.   lProcessEvent^.Handler := AddEventHandler(AHandle, 0,
  12.     @HandleProcessEvent, PtrInt(lProcessEvent)); // << Casting a pointer to a signed Int64 to be reference later
  13.   Result := lProcessEvent;
  14. end;                                    
  16. Could it be the Address is getting above the 2G  for 32 bit targets?
  17. Maybe we should be using PtrUint instead which is a QWORD under the 64bit target.

Just something I noticed.
Debugger / Re: lldb on windows?
« Last post by Martin_fr on Today at 01:55:49 am »
On Lazarus it takes up to 5 seconds.  :o

HDD or SSD? That is your project: project1.exe

I have done a few tests, with a default empty Form1 project.
Starting process in the debugger (That is the 2nd, or later run of the debugger, with "Reset after each run" disabled)
- project on HDD: 4-5 Sec
- project on SSD: 2-3 Sec

If you are on 2.0RC => Apply the changes from r60130 Debugger: remove some active logging
Logging can slow things down. It accidentally slipped in.

Also you may want to set the following option in the debugger options:
DisableLoadSymbolsForLibraries => Set to True, may save up to 0.5 secs (estimated, I did not implement measuring)

And disable everything for the "event log". Though I did not notice a difference here.

You may also want to use GDB 8.2. For big projects, it can save some time.

But even more time is saved by disabling debug info for packages (assuming you only debug code in your project)
You can force this via "additions and overrides" (search the wiki if you need more info)
target: *
with a custom option: -g-
target: #project
with a custom option: -gw -godwarfsets

The project must be after the *.

With all of that, the form1 project starts in maybe 1.5 to 2 secs (estimated from looking at my watch)
Pages: [1] 2 3 ... 10