A first test on macOS Mojave delivered excellent results. Thanks for your efforts!
Is it possible to create a 64 bit cocoa install package?
...As I routinely compile a 'kit' pulled down from my github repo, I end up with the compiler set to fpc and usually (?) have to manually set it to ppcx64 if I am using the Lazarus IDE - from memory (my Mac is out of reach) its /usr/bin/ppcx64 but, obviously, thats depends on where yours is installed. I don't know why fpc (which just redirects to an appropriate compiler) does not work but I have just. sort of, got used to doing that. My 'official' builds are done using a script from the command line and it does call ppcx64 directly.
Unfortunately, I am now getting warnings about fpc missing a config file, and not finding the x86_64 binaries. This was not a problem prior to installing RC3, and I have not made changes (that I am aware of) to fpc.
fpc, run from the command line, is 3.0.4 [2017/11/26] for x86_64.
Any thoughts on how to address the new fpc issue?
Just in general / not sure if it applies to your issues
fpc is a wrapper that will call the correct compiler depending on the target (cpu)
ppcx64 is for 64 bit
ppci386 is for 32 bit
If you want to be able to change targets in the ide, then the IDE must be configured with fpc as the compiler.
---
If you are looking for a config file, compile a simple program with -va
This will get lots of output ("copy all and original" in messages window). It will show every path that the compiler looked for any file.
Not all of them need to be present. But one fpc.cfg should be found.
There is fpcmcfg to generate one. But you need to google that.
Would it make sense to move a copy to " /Users/frederick/.fpc.cfg"?
Warning The current FPC has no config file. It will probably miss some units. Check your installation of fpc.
Error The project uses target OS=macos and CPU=x86_64. The system.ppu for this target was not found in the FPC binary directories.
Make sure fpc is installed correctly for this target and the fpc.cfg contains the right directories.
fpcupdeluxe FPC 2.0.4 + fixes2.0
ERROR: Fpcupdeluxe fatal error !
Removed lazarus directory (Development/laz_2_0) and configuration directory (Users/frederick/.laz_2_0). Ran:Ok, so that happens when you start the IDE?
cd /Developer svn co https://svn.freepascal.org/svn/lazarus/branches/fixes_2_0/ laz_2_0 cd laz_2_0 make LCL_PLATFORM=cocoa CPU_TARGET=x86_64 open startlazarus.app --args "--pcp=~/.laz_2_0"
Still get:
Warning The current FPC has no config file. It will probably miss some units. Check your installation of fpc.
Error The project uses target OS=macos and CPU=x86_64. The system.ppu for this target was not found in the FPC binary directories.
Make sure fpc is installed correctly for this target and the fpc.cfg contains the right directories.
:(
Error: Illegal parameter: -Tmacos
From the FPC output:Code: [Select]Error: Illegal parameter: -Tmacos
Target MacOS is for MacOS Classic (pre Mac OS X). For Mac OS X the target OS needs to be set to Darwin.
Also you may want to try to change your target to Darwin or Cocoa...
Target MacOS is for MacOS Classic (pre Mac OS X). For Mac OS X the target OS needs to be set to Darwin.
or just left as 'default' - thats all mine is.
And $DARWIN is defined.
Davo
I have a project which uses the VirtualStringTree(VST) 4.8.7.4, for easy and fast install I use the Online-Package-Manager(OPM).With Lazarus 2.0(RC1, RC2, ...), OPM uses VTV 5.3.3.1 internally, this is why VTV 5.3.3.1 is installed by default. By trying to install an older version of VTV, 4.8.7.4 for example, you will get the multiple ppu message, like the one in your screenshot. You have two choices:
But since rev2.0RC1-RC3 I get an error. Installing process in the OPM seems to work but when the IDE is recompile then occurs an error:
Multiple Units found: In attachments is a pic with this error(german message)
1. Stay with VTV 4.8.7.4 and uninstall OPM and VTV 5.3.3.1...Just to make sure: Does OPM really need features of VTV5? Of course it depends on the explicit requirements, but all my own usages of VTV worked with v4 and with v5.
Just to make sure: Does OPM really need features of VTV5?Yes. Many new features does not exists in VTV4:
all my own usages of VTV worked with v4 and with v5Mine too, in fact I could switch from 4.x to 5.x without any issues in a few projects of mine. However OPM is a special case, because it has to run in multiple platforms.
Would it be an option to rename all classes, units and the package of VTV4 by appending a "4" (or similar), and to adapt these identifiers in the pas and lfm files of your project? Automatic search and replace can be done by any editor and should be easy. This way VTV4 becomes completely independent of VTV5.
Unfortunately I cannot test because VTV4 is no longer available through OPM.
Or should OPM contain only VTV4 with all critical identifiers renamed to give users of the old version a chance to install it in addition to the one used by OPM?
The best will be to fix VTV5 immediately before rev2.0 is finished.The official repository for VTV is on github. You should file a bug report there: https://github.com/blikblum/VirtualTreeView-Lazarus/issues. The one in the lazarus component folder is just a copy, only needed for OPM. After it's fixed on github, the changes can be merged back to the component folder.
Any one which will use the VTV5 will have all the issues.
You should file a bug report there: https://github.com/blikblum/VirtualTreeView-Lazarus/issues.I absolutely agree with GetMem. It is no use complaining here about the bugs in VTV5, there is almost zero chance that Luiz, the maintainer of the Lazarus port VTV, will read a thread titled "Lazarus Release Candidate 3 for 2.0" and expect a VTV bug report buried among 50 posts.
Why should everybody (including you) test the release candidate?Every one should test the new RC's because "you can be the one of millions where the projects are broken".
Why should everybody (including you) test the release candidate?
Every one should test the new RC's because "you can be the one of millions where the projects are broken".I understand your frustration, sometimes I feel the same about Lazarus development, but:
Lazarus works with VTV4 and now we have VTV5 with more features but it is unstable and buggy and breaks my and maybe other projects. I don't understand the logic to replace a working component with a buggy version.
Not tested, but...
Has anyone checked if OPM would compile against vtv4?
I am not suggesting to change the distribution. But if it compiles, and someone needs vtv4, they can
- download vtv4
- open opm package, drop vtv5 dependency, replace by vtv4, and compile.
And then they should have vtv4 in their Ide.
@wpNo. It is a snap. Please see the [EDIT] of my previous post: You only must rename the unit name and the names of the registered components, for a form with a single VTV this is one change in the lfm and two changes in the pas file.
Looks like a lot of work.
Now I took the time to rename the essential classes of VTV4 (i.e. i added a "4") and packed everything into a zip. Unfortunately, the file is too large for the forum, so I uploaded it to my dropbox: https://www.dropbox.com/s/d5hmtmurcdx5eeo/VirtualTreeView4.zip?dl=0.Thanks. I assume that the modified VTV4 can co-exists with VTV5, so you can install both of them at the same time. If yes, then I will add it back to the main repository.
Has anyone checked if OPM would compile against vtv4?Yes. Unfortunately you cannot build OPM with VTV4, at least not without small modification. However it shouldn't take too long to make the necessary adjustments. Some of the procedures parameter has changed, like:
I assume that the modified VTV4 can co-exists with VTV5, so you can install both of them at the same time.Yes. Installation of both VTV versions on the same system is no problem (well... I only checked Windows, Linux gtk2 and qt).
If yes, then I will add it back to the main repository.Maybe we should wait for some feedback first. I think I'll add it to ccr in order to have some workplace if changes are required in the future. It should be clarified here, however, that this VTV4 fork will not be developed any further, I will only fix compilation issues which can creep in sometimes.
Maybe we should wait for some feedback first.OK.
I think I'll add it to ccr in order to have some workplace if changes are required in the future. It should be clarified here, however, that this VTV4 fork will not be developed any further, I will only fix compilation issues which can creep in sometimes.I agree. There are too many VTV versions already, it can be confusing.
Release candidateWhich is just about what I wrote independently. 8-)
A release candidate (RC), also known as "going silver", is a beta version with potential to be a final product, which is ready to release unless significant bugs emerge. In this stage of product stabilization, all product features have been designed, coded and tested through one or more beta cycles with no known showstopper-class bugs. A release is called code complete when the development team agrees that no entirely new source code will be added to this release. There could still be source code changes to fix defects, changes to documentation and data files, and peripheral code for test cases or utilities. Beta testers, if privately selected, will often be credited for using the release candidate as though it were a finished product. Beta testing is conducted in a client's or customer's location and to test the software from a user's perspective.
I have just downloaded 32-bit FPC 3.0 with latest fixes for Windows, and it still has "No memory left bug" which stops you from installing many components because {$setpeflags $20} fix was not back ported yet.
https://forum.lazarus.freepascal.org/index.php/topic,40351.msg279886.html#msg279886
It would really be a bummer to have official Lazarus 2.0 released without this FPC fix.
setpeflags is fixed in fpc fixes 3.2 branchWell, official Lazarus is going to come with 3.0.x, so I thought I should lit up a red light on the semaphore. I have little hope anyway, since fix never got back ported to 3.0.x.
And my fpcupdeluxe have my patch for older versions.FPC 3.0.x fixes branch comes without this fix even in fpcupdeluxe. It needs to be applied manually. I did it by hand and just let fpcupdeluxe rebuild only.
3.0.4 is already released. Fpc backports can either go to fixes 3.0 (i.e. 3.0.5) or fixes 3.2. Neither of this will affect Lazarus 2.0.Thanks for the info. That's a spoiler. Not for me since I know how to fix 'No memory left' bug, but I can already imagine reports from users...
1) The issue is still open (assigned). So no it has not yet been fixed.Actualy MY version of lazarus solves 0034763 without me doing anything.
Secondly, old problem, if you develop on a machine with a second screen, if the graphical layout form is on the second screen for development, the compiled program will open at the same coordinates, which creates a problem if it is opened on a machine without a second screen.
I am not really sure what it is you are trying to do here however, if you use the LoadfromClipboard
function it will fail if there isn't a supported format.
Indeed Jamie. I guess I have not been clear, the issue is that on RC3, there are no graphic formats available if copied from another app. I fully understand (and expect) a failure if you try and load a non existing format and discussion did wander into identifying the formats. But in RC3 (unlike 1.8.4) no graphic formats are available !I installed RC3 and 1.8.4 to a Linux VM and can confirm your observation. Please file a bug report. No developer will see this description in this monster thread.
I found what caused the bug with controls appearing on all tabs of a pagecontrol. If you create the control on the main form, and then move it to the pagecontrol tab, it will appear on all tabs.
Hint: (11030) Start of reading config file /usr/local/etc/fpc.cfg
Hint: (11031) End of reading config file /usr/local/etc/fpc.cfg
Free Pascal Compiler version 3.0.4 [2018/12/20] for x86_64
Copyright (c) 1993-2017 by Florian Klaempfl and others
(1002) Target OS: FreeBSD for x86-64
(3104) Compiling startlazarus.lpr
(3104) Compiling redirect_stderr.pas
(3104) Compiling lazarusmanager.pas
/root/lazarus/ide/lazarusmanager.pas(138,35) Hint: (5024) Parameter "Sender" not used
/root/lazarus/ide/lazarusmanager.pas(429,12) Warning: (5043) Symbol "CommandLine" is deprecated
(9022) Compiling resource ../units/x86_64-freebsd/gtk2/startlazarus.or
(9015) Linking ../startlazarus
(1008) 708 lines compiled, 4.1 sec
(1021) 1 warning(s) issued
(1022) 3 hint(s) issued
gmake[2]: Leaving directory '/root/lazarus/ide'
gmake[1]: Leaving directory '/root/lazarus/ide'
#csh# gmake install
/usr/local/bin/ginstall -m 755 -d /usr/local/share
/usr/local/bin/ginstall -m 755 -d /usr/local/share/lazarus
/usr/local/bin/ginstall -m 755 -d /usr/local/share/applications
/usr/local/bin/ginstall -m 755 -d /usr/local/share/pixmaps
/usr/local/bin/ginstall -m 755 -d /usr/local/share/mime/packages
/usr/local/bin/ginstall -m 755 -d /usr/local/share/icons/hicolor/48x48/mimetypes
/usr/local/bin/ginstall -m 755 -d /usr/local/bin
/usr/local/bin/ginstall -m 755 -d /usr/local/share/man
/usr/local/bin/ginstall -m 755 -d /usr/local/share/man/man1
/bin/cp -Rfp packager debugger designer converter ide images languages lazarus.app units /usr/local/lazarus
cp: /usr/local/lazarus is not a directory
gmake: *** [Makefile:3420: install] Error 1
#csh#startlazarus
startlazarus: Command not found.
ll /usr/local/bin/startlazarusEmpty folder with no files in it. And /usr/local/bin/startlazarus appears to be linked against non-existing file..
lrwxr-xr-x 1 root wheel 29 Jan 11 12:06 /usr/local/bin/startlazarus@ -> ../share/lazarus/startlazarus
#csh# ll /usr/local/share/lazarus/startlazarus
ls: /usr/local/share/lazarus/startlazarus: No such file or directory
ll /usr/local/share/lazarus/
total 0
In every 2.0 RC was a bug related to TDBLookUpListBox. First, it didn't work as intended: you can not select items, KeyValue is not null, but does not contain a valid value either. It is happens when linked DataSource and/or ListSource contain a read-only field.
Tested only on Linux, so far.
Attached is a small example project. Yes, I know that table structure is awkward (SQL statement, too :) ) but it is working sometimes with simpler structures.
Code: [Select]packagedefs.pas(59,17) Error: No matching implementation for interface method "GetIDAsString:AnsiString;" found
packagedefs.pas(59,17) Error: No matching implementation for interface method "GetIDAsWord:AnsiString;" found
Binaries should never be in share/ to begin with, since that is for architecture independent files.Yeah, I wondered about that. These are all 'default' folders though, chosen by Lazarus's make build system.
DrawText(Canvas.Handle,{$IFNDEF CLR}pchar{$endif}(s),length(s), temp,flags);
shows the wrong encoding. The string is utf-8, but it shows latin1 on Windows 7NowCode: [Select]DrawText(Canvas.Handle,{$IFNDEF CLR}pchar{$endif}(s),length(s), temp,flags);
shows the wrong encoding. The string is utf-8, but it shows latin1 on Windows 7
NowCode: [Select]DrawText(Canvas.Handle,{$IFNDEF CLR}pchar{$endif}(s),length(s), temp,flags);
shows the wrong encoding. The string is utf-8, but it shows latin1 on Windows 7
Where does that piece of code come from?
Is CLR defined?
IIRC when handling strings as PChars (in API's) the codepage information of the string gets lost.
Bart
I tried to compile the version from https://svn.freepascal.org/svn/lazarus/tags/lazarus_2_0_0_RC3, but it givesIt got fixed in r59921.Quoteedit: because it is private in TLazPackageID ...Code: [Select]packagedefs.pas(59,17) Error: No matching implementation for interface method "GetIDAsString:AnsiString;" found
packagedefs.pas(59,17) Error: No matching implementation for interface method "GetIDAsWord:AnsiString;" found
NowCode: [Select]DrawText(Canvas.Handle,{$IFNDEF CLR}pchar{$endif}(s),length(s), temp,flags);
shows the wrong encoding. The string is utf-8, but it shows latin1 on Windows 7
and when i call utf8ToWinCP on the string it is broken on wine, because it needs utf-8 in the string there
In latest lazarus, i have a issue with debugger not really working on any variables - i've attached a picture, this is stock install: Lazarus 2.0.0RC3 r59877 FPC 3.0.4 i386-win32-win32/win64
Do you have an example how to reproduce?I don't know about JernejL's case, but I can provide an example when GDB totally doesn't work.
I don't know about JernejL's case, but I can provide an example when GDB totally doesn't work.
You just need to declare a nested class with interface implementation and store this nested class as interface variable. Then no one private field of this class can be watched.
Just try to set a breakpoint at Result := FVal * FVal; line, and watch FVal. You will get no symbol BLABLA in current context. This is a really annoying bug.
#0 P$PROJECT1$_$TMYCLASS_$_TINTERNALCLASS_$__$$_EVAL$$LONGINT at :36
#1 DOTEST(0xfcab0) at project1.lpr:48
#2 TEST1 at project1.lpr:61
#3 main at :0
Incompatible PPU problem:
(3104) Compiling lazarus.pp
(10001) PPU Loading C:\PRG\Lazarus\FixesAll\lazarus\components\sparta\mdi\lib\i386-win32\sparta_multiplyresizer.ppu
(10011) PPU Source: sparta_multiplyresizer.pas not found
(10028) Recompiling sparta_MultiplyResizer, checksum changed for Generics.Collections
C:\PRG\Lazarus\FixesAll\lazarus\ide\sparta_multiplyresizer.pas(80,12) Fatal: (10022) Can't find unit sparta_MultiplyResizer used by sparta_MDI
Fatal: (1018) Compilation aborted
More info?
- I also do not see any resolved symbols in the backtrace dialog, only the addresses.
It does not say "incompatible". It says "Checksum changed"Sorry if provided info was not enough. Incompatible PPU is mentioned as fatal error during IDE rebuilding:
sparta_multiplyresizer.pas(80,12) Fatal: Cannot find sparta_MultiplyResizer used by sparta_MDI, incompatible ppu=C:\Prg\Lazarus\FixesAll\lazarus\components\sparta\mdi\lib\i386-win32\sparta_multiplyresizer.ppu, package sparta_MDI
Anyway the issue is with Generics.Collections (and/or the package that contains it)As for point 3 I have set manual compilation of package rebuild options in both generics.collections and sparta_DockedFormEditor, but still the same problem. Messing with points 1 and 2 is uncharted territory for me, so I will byte them only if no other option is left.
There may be many reasons for this error.
The one I know, and have seen before is a combination of using "inline" and "circular unit refs" .
Something todo, with one of the circular referencing units forces the other (or itself) unit to compile again, but not updating its checksum. Or maybe it was changing the checksum for the header, after discovering the "inline".
1)
I am not sure, it may be enough to make sure, that all "inline" are declared in the interface. Yet it may not.
2)
It should help, if you disable all inlining in the affected units (package of Generics.Collections)
3)
It may (or may not) also help, to compile this package twice (the 2nd time, without cleaning it). The 2nd compile may fix the checksums.
not having a functional docked form editor is a major bummer and I will report it as a bug in Lazarus 2.0 RC3 / FPC 3.0.5.Just reported: https://bugs.freepascal.org/view.php?id=34899
Note that Generics.Collections has been in trunk FPC for over a year now, and the Lazarus version is somewhat outdated compared to the trunk version. Anyone having problems might want to try replacing their files with the ones from trunk.I replaced all generics.*.pas files from \lazarus\components\sparta\generics\source with \fpcsrc\packages\rtl-generics\src ones from trunk downloaded at the beginning of December, and after manual successful recompiling of sparta_generics.lpk, sparta_mdi.lpk, and sparta_dockedformeditor.lpk, I added sparta_dockedformeditor package to IDE and tried IDE clean rebuild but error was the same (incompatible ppu):
Warning: Recompiling sparta_MultiplyResizer, checksum changed for Generics.Collections
sparta_multiplyresizer.pas(80,12) Fatal: Cannot find sparta_MultiplyResizer used by sparta_MDI, incompatible ppu=C:\PRG\Lazarus\FixesAll\lazarus\components\sparta\mdi\lib\i386-win32\sparta_multiplyresizer.ppu, package sparta_MDI
Personally, I've never had any problems with Sparta Docked Form Editor at all.First thing I do on fresh Lazarus is to add anchor docking package and sparta docked form editor. That goes well and embedded form editor works. But after installing more and more packages, at one moment (maybe at installing something that uses generics?) I am not able to rebuild the IDE any more because of the reported error. If I uninstall sparta docked form editor package I can rebuild IDE and continue with installation of other packages.
In 32-bit Lazarus 2.0 RC3 and FPC 3.0.5 on Win10x64, when I right click on some tab in source editor and choose 'Close Page' menu with item tab is not closed. With Ctrl+F4 or File / Close Page tab gets closed. Can someone confirm this?
In 32-bit Lazarus 2.0 RC3 and FPC 3.0.5 on Win10x64, when I right click on some tab in source editor and choose 'Close Page' menu with item tab is not closed. With Ctrl+F4 or File / Close Page tab gets closed. Can someone confirm this?
The stacktrace window is directly provided by GDB, so not much the IDE can do about.
- I also do not see any resolved symbols in the backtrace dialog, only the addresses.
In 32-bit Lazarus 2.0 RC3 and FPC 3.0.5 on Win10x64, when I right click on some tab in source editor and choose 'Close Page' menu with item tab is not closed. With Ctrl+F4 or File / Close Page tab gets closed. Can someone confirm this?
In 32-bit Lazarus 2.0 RC3 and FPC 3.0.5 on Win10x64, when I right click on some tab in source editor and choose 'Close Page' menu with item tab is not closed. With Ctrl+F4 or File / Close Page tab gets closed. Can someone confirm this?My 32-bit Lazarus 2.0 RC3 and FPC 3.0.5 on Win10x64 - and on Win7 -
There is an old unresolved issue with Unit testing. I had reported it together with a patch in 2015, but it still seems to be unimplemented in Lazarus 2.0RC3. See https://bugs.freepascal.org/view.php?id=29283 for details.
I have now added a note with a new version of the patch, which supports Cocoa, too.
'End of source not found' (util.inc(27,4) Error: Ende des Quelltexts nicht gefunden)Unless the includefile (util.inc(27,4) is included at the wrong place....... It's an include and gets parsed so there must be something wrong at your side.
Can anyone confirm this?