Recent

Recent Posts

Pages: [1] 2 3 ... 10
1
Free Pascal / Re: FPC 3.2.x series branched, trunk update to 3.3.1
« Last post by wp on Today at 11:56:17 pm »
Something must be badly wrong with this list. I quickly tested some of the packages that I know, CalLite,  Industrial, ColorPalette, LazBarCode, mbColorLib - and they all compile fine. Which IDE and which FPC are used? I used Laz trunk / fpc 3.0.4 / 32 bit on Win10 / 64 bit.
2
Other OS / Sample Simple HOST/DYLIB for OSX
« Last post by kevin.black on Today at 11:45:05 pm »
Hi,

Apart from just starting with Lazarus after a many year hiatus, I am necessarily in the OSX world. This is because of issues with Delphi which, even at 10.2.3, there are problems and no 64bit version for the foreseeable future (which is bad if you are doing OSX).

Now (I think) I had my code working the 32 bit version (carbon). It's a simple statically loaded DYLIB (so it gets loaded first) with one call (_say_Hello). I have converted to 64bit. This in and of itself has been plagued with issues. My settings now are (so we are all on the same page):

Tools>Settings>Environment>Files
Compiler Executable:  /usr/local/bin/ppcx64

Project Options>Compiler Options>Config and Target
Target OS:             (Default)
Target CPU Family: x86_x64
Target Processor:   (Default)

For clarity I've included the code below, but when I look at the DYLIB with nm -gU there is definitely an entry for _say_Hello(). Please take the time to have a look, this is a blocker.

Regardless, I cannot seem to get past this error (no matter what combination of '_' I use or whether or not I put in the full path of the DYLIB. There error messages are:
Code: Pascal  [Select]
  1. Hint: (11030) Start of reading config file /etc/fpc.cfg
  2. Hint: (11031) End of reading config file /etc/fpc.cfg
  3. Free Pascal Compiler version 3.0.4 [2017/11/26] for x86_64
  4. Copyright (c) 1993-2017 by Florian Klaempfl and others
  5. (1002) Target OS: Darwin for x86_64
  6. (3104) Compiling pDYLIBTestAPP.lpr
  7. (3104) Compiling udylibtestapp.pas
  8. /Users/kevin/Dropbox/Lazarus/DYLIBTest/udylibtestapp.pas(28,28) Hint: (5024) Parameter "Sender" not used
  9. /Users/kevin/Dropbox/Lazarus/DYLIBTest/udylibtestapp.pas(27,28) Hint: (5024) Parameter "Sender" not used
  10. /Users/kevin/Dropbox/Lazarus/DYLIBTest/udylibtestapp.pas(26,28) Hint: (5024) Parameter "Sender" not used
  11. (9001) Assembling (pipe) /Users/kevin/Dropbox/Lazarus/DYLIBTest/lib/x86_64-darwin/udylibtestapp.s
  12. (9001) Assembling (pipe) /Users/kevin/Dropbox/Lazarus/DYLIBTest/lib/x86_64-darwin/pDYLIBTestAPP.s
  13. (9022) Compiling resource /Users/kevin/Dropbox/Lazarus/DYLIBTest/lib/x86_64-darwin/pDYLIBTestAPP.or
  14. (9015) Linking /Users/kevin/Dropbox/Lazarus/DYLIBTest/darwin/pDYLIBTestAPP
  15. Undefined symbols for architecture x86_64:
  16.   "__say_Hello", referenced from:                                         [MY COMMENT] NOTE THE Double '_' as in '__'
  17.       _UDYLIBTESTAPP$_$TFDYLIBTESTAPP_$__$$_BITBTN1CLICK$TOBJECT in udylibtestapp.o
  18. ld: symbol(s) not found for architecture x86_64
  19. An error occurred while linking
  20. pDYLIBTestAPP.lpr(25) Error: (9013) Error while linking
  21. pDYLIBTestAPP.lpr(25) Fatal: (10026) There were 1 errors compiling module, stopping
  22. Fatal: (1018) Compilation aborted
  23.  
If I take the '_' out of the function name in the coed this shows the same error, but with a single '_'. I have used the application bundle  option and that is an issue because it don't build the Host. If I take out the call to the DYLIB, it works fine.

Host Code:
Code: Pascal  [Select]
  1. unit uDYLIBTestAPP;
  2.  
  3. {$mode objfpc}{$H+}
  4.  
  5. interface
  6.  
  7. uses
  8.   Classes,
  9.   SysUtils,
  10.   Forms,
  11.   Controls,
  12.   Graphics,
  13.   Dialogs,
  14.   Buttons,
  15.   StdCtrls;
  16.  
  17. type
  18.  
  19.   { TfDylibTestApp }
  20.  
  21.   TfDylibTestApp = class(TForm)
  22.     BitBtn1: TBitBtn;
  23.     BitBtn2: TBitBtn;
  24.     BitBtn3: TBitBtn;
  25.     Memo1: TMemo;
  26.     procedure BitBtn1Click(Sender: TObject);
  27.     procedure BitBtn2Click(Sender: TObject);
  28.     procedure BitBtn3Click(Sender: TObject);
  29.   private
  30.  
  31.   public
  32.  
  33.   end;
  34.  
  35. const
  36.   // Windows DLL Names
  37.   {$IFDEF MSWINDOWS}
  38.   TestDLL = 'pdylibtest.dll';
  39.   {$ENDIF MSWINDOWS}
  40.  
  41.   // macOS DYLIB Names
  42.   {$IFDEF DARWIN}
  43.   TestDLL = '/users/kevin/dropbox/lazarus/dylibtest/darwin/libpdylibtest.dylib';
  44.   {$ENDIF DARWIN}
  45.  
  46.   {$IFDEF MSWINDOWS}
  47.     function say_Hello(Hello: string): boolean; stdcall; external TestDLL Delayed;
  48.   {$ENDIF MSWINDOWS}
  49.  
  50.   {$IFDEF DARWIN}
  51.    function _say_Hello(Hello: string): boolean; cdecl; external TestDLL;
  52.   {$ENDIF DARWIN}
  53.  
  54.   function localFunction(localIn: string; out localOut: string): boolean;
  55.  
  56. var
  57.   fDylibTestApp: TfDylibTestApp;
  58.  
  59. implementation
  60.  
  61. function localFunction(localIn: string; out localOut: string): boolean;
  62. begin
  63.   LocalOut := 'This was passed to the function: ' + LocalIn;
  64.   Result := True;
  65. end;
  66.  
  67. {$R *.lfm}
  68.  
  69. { TfDylibTestApp }
  70.  
  71. procedure TfDylibTestApp.BitBtn3Click(Sender: TObject);
  72. begin
  73.   // Quit the test application
  74.   close;
  75. end;
  76.  
  77. procedure TfDylibTestApp.BitBtn2Click(Sender: TObject);
  78. var
  79.   sOut: string;
  80.  
  81. begin
  82.   // This is a local function
  83.   ShowMessage('Local Function Call');
  84.   if localFunction('Local in', sOut) then
  85.     showmessage('Local Function: TRUE (' + sOut + ')')
  86.   else
  87.     showmessage('Local Function: FALSE');
  88. end;
  89.  
  90. procedure TfDylibTestApp.BitBtn1Click(Sender: TObject);
  91.  
  92. var
  93.    b:boolean;
  94.    sType: string;
  95.    sDLLString: string;
  96.  
  97. begin
  98.  
  99.     b := False;
  100.  
  101.     // Call the DLL Function
  102.     {$IFDEF MSWINDOWS}
  103.     sType := 'Windows DLL';
  104.     sDLLString := 'The string passed to the Windows DLL';
  105.     b := say_Hello(sDLLString);
  106.     {$ENDIF MSWINDOWS}
  107.     {$IFDEF DARWIN}
  108.     sType := 'macOS DYLIB';
  109.     sDLLString := 'The string passed to the macOS DYLIB';
  110.     b := _say_Hello(sDLLString);
  111.     {$ENDIF DARWIN}
  112.  
  113.     if b then
  114.       showmessage('Returned From: ' + sType + ': TRUE')
  115.     else
  116.       showmessage('Returned From: ' + sType + ': FALSE');
  117.  
  118. end;
  119.  
  120. end.
  121.  

DYLIB CODE (the dylib builds OK without error):
Code: Pascal  [Select]
  1. library pDYLIBTest;
  2.  
  3. {$mode objfpc}{$H+}
  4.  
  5. {$R *.res}
  6.  
  7. uses
  8.   Classes,
  9.   SysUtils,
  10.   Forms,
  11.   Controls,
  12.   Graphics,
  13.   StdCtrls,
  14.   Dialogs,
  15.   Buttons,
  16.   Interfaces;
  17.  
  18. var
  19.   sType: string;
  20.  
  21. //function say_Hello(Hello: string): boolean; cdecl;{$IFDEF DARWIN} alias : '_say_Hello'; {$ENDIF DARWIN}
  22. function say_Hello(Hello: string): boolean; cdecl;
  23. begin
  24.  
  25.   ShowMessage('[DYLIB] This is the new direct call: DYLIB / DLL using FMX.Forms and FMX.Dialogs');
  26.  
  27.   {$IFDEF WINDOWS}
  28.   sType := 'Windows DLL';
  29.   {$ENDIF WINDOWS}
  30.   {$IFDEF DARWIN}
  31.   sType := 'macOS DYLIB';
  32.   {$ENDIF DARWIN}
  33.   Result := True;
  34. end;
  35.  
  36.  
  37. end.
  38.  
  39. exports
  40.   say_Hello;{$IFDEF DARWIN} name '_say_Hello'; {$ENDIF DARWIN}
  41.  
  42. initialization
  43.   ShowMessage('[DYLIB] initialization');
  44.  
  45. finalization
  46.   ShowMessage('[DYLIB] finalization');
  47.  
  48.  
  49. end.
  50. ``

So apart from the obvious question, why can the Host application NOT see the function in the DYLIB?

Does anyone have simple test code that is working that has a 64bit Host and a 64bit DYLIB that they might share with me (or point me to an example) so that I can see where I am going wrong?

Many thanks
3
Third party / Re: Online Package Manager
« Last post by wp on Today at 11:35:40 pm »
4
Free Pascal / Re: FPC 3.2.x series branched, trunk update to 3.3.1
« Last post by lainz on Today at 11:26:15 pm »
I think I confused these fpcupdeluxe modules with OPM, sorry.

Where do these modules come from? How are they updated? Why does fpcupdeluxe distribute its own packages when there is now OPM which is even integrated in the IDE?

I think this is older than OPM. AFAIK it downloads the repository from the official source then installs it.

Code: Pascal  [Select]
  1. * bgragames (the modules bgrabitmap, bgracontrols and bgracontrolsfx were previously properly installed)

About BGRAGames not compiling, is an outdated package, I should check if I can fix it, but for making a game better use Castle Game Engine that is cross platform and works for mobile devices.

Edit: I see LazPaint in the list, is not a package that can be installed, is a regular lazarus project. In the past that repo included bgrabitmap, but now they are in 2 separate repos.
5
Beginners / Re: Pascal Books
« Last post by Pluto on Today at 11:14:21 pm »
Thank you for the links.  These are pure gold... Actually better than what I could have bought at Amazon.
6
Free Pascal / Re: FPC 3.2.x series branched, trunk update to 3.3.1
« Last post by wp on Today at 11:04:19 pm »
I think I confused these fpcupdeluxe modules with OPM, sorry.

Where do these modules come from? How are they updated? Why does fpcupdeluxe distribute its own packages when there is now OPM which is even integrated in the IDE?
7
Other / is the Freepascal Community growing?
« Last post by coradi on Today at 11:04:02 pm »
It was a little time ago, since I was here lst time:-)
But it seems that now are much more users active?
Is it true? Will Pascal get an Revival?  :-)
8
General / ARM STM32 defination Files fro Mikroe or other
« Last post by coradi on Today at 10:58:27 pm »
Is there any Idea or way, that I can use the defination files from Mikroe compiler or other for Freepascal?

So that I can write/use
PortB.1:=0; //To enable Port B Pin 1 as example
9
Free Pascal / Re: FPC 3.2.x series branched, trunk update to 3.3.1
« Last post by valdir.marcos on Today at 10:29:03 pm »
I have just tried to install all available modules in "FPCUPdeluxe V1.6.2h for i386-win32-win32".

Before I open so many supporting tickets, I'd like to hear your opinion about modules that do not deserve a bug report because the fault is mine.

Maybe some packages didn't install because I didn't know the correct order of dependencies.

I have attached a log file with information for all broken modules.

Here is the complete list of modules that I could not install:
* bgragames (the modules bgrabitmap, bgracontrols and bgracontrolsfx were previously properly installed)
callite
castle_game_engine
cef3
codebot
colorpalette
dcpcrypt
ECControls
editormacroscript
epiktimer
evssimplegraph
fblib
fpcusblib
fpgui
fpowm
fpvectorialpkg
glscene
graphics32
graphics32-rbc
industrial
indy
indy9
internettools
james
lamw
lazbarcodes
lazgoogleapis
lazmer
lazopenglcontext
lazpackager
lazpaint
lazprofiler
* ljgridutils (freezes)
lnet
macosext
mbColorLib
metal
mtprocs
* opm (solved)
pascal-futures
pascalio
pascalscada
pascalscript
pasettimino
python4laz
rest-dw
* rutils (freezes)
rx
simplegraph
spktoolbar
suggestedpackages
suggestedpackagesadd
synapse
tiopf
tlazserial
treelistview
turbobird
* tvplaneit (solved)
uecontrols
usercontrol
vampyre
* virtualtreeview       (skipped)
* virtualtreeviewonline (skipped)
wst
zeos
zmsql
10
Normally, one should have a reason for identifier to be in global public scope. And if you have a lot of identifiers that became "unused", you should reconsider your code structure. Not just "clean unused".

I do not understand why the need to find unused "identifiers" is considered by you as a sign of poor code quality. I have been developing this game for many months (about 10) and by adding new functionalities and modifying existing (and also fixing bugs) some identifiers were no longer needed and I could forget to remove them from the code.

First of all, we talk about constants. All constants are declared in the Platformer.Constants.pp unit, which is used by many other units (thats why are global, in the interface section). They are grouped and declared in the right order, about 300 pieces. This is not a library project, so all unused constants should be removed from this unit (other "elements" from other units too).

Is the existence of such a unit a bad idea? I don't think so.

But with the things we have now, the only workaround I can think of is to move all constants, types and vars to the implementation section.

Yes, but it is a different way of manual search.

It is faster to check the identifiers with the Find in Files tool, which can be easily operated from the keyboard. If the list in the Search Results window contains only one item (declaration line), it means that the constant is not used anywhere else.

I intentionally write about the Find in Files tool, because the Find or Rename Identifier tool often does not find all instances. I often use the second mentioned tool and I also often have compilation errors after changing the identifier of the property or the method (because it didn't change all instances in all project units). Therefore, I prefer to use Find in Files for the search itself. However, if the identifiers to be checked is very much, then such a search is tiring.

I'm not going to push the creation of such a search tool, I'm just asking to sue your opinions on this subject.
Pages: [1] 2 3 ... 10