Re: [Lazarus] Possible Codetools issue for embedded targets in main branch
While investigating further I suddenly saw that the unit was detected. So I did a complete fresh install via fpcupdeluxe, opened a project for rp2040, saw the error. Then I selected 'rescan fpc source directory' and the issue was gone. So not sure if this is an issue or not, it definitely does not fully work as expected. Michael Am 06.10.22 um 21:59 schrieb Michael Ring via lazarus: I today looked at an issue posted in the lazarus forum: https://forum.lazarus.freepascal.org/index.php/topic,60790.0.html the user is unable to use ctrl-space for help because codetools cannot find the required unit rp2040. I could not reproduce the issue with my older installation of lazarus-trunk but when I upgraded to latest trunk from today I saw the same issue. Possible reason is that lazarus cannot extract the info about the unit source file from the output of the -ix format of fpc I commented out a few log entries and got this result: TFindDeclarationTool.FindUnitSource Self="/Users/ring/devel/pico-fpcexamples/blinky/blinky.lpr" AnUnitName="RP2040" AnUnitInFilename="" TCTDirectoryCache.FindUnitSourceInCompletePath AUnitName="RP2040" InFilename="" Directory="/Users/ring/devel/pico-fpcexamples/blinky/" TCTDirectoryCache.FindUnitSourceInCompletePath unit RP2040 not found in SrcPath="/Users/ring/devel/pico-fpcexamples/blinky;/Users/ring/devel/pico-fpcexamples/units" Directory="/Users/ring/devel/pico-fpcexamples/blinky/" searchin in unitset ... TCTDirectoryCache.FindUnitInUnitSet Directory="/Users/ring/devel/pico-fpcexamples/blinky/" UnitSet="CompilerFilename=/Users/ring/fpcupdeluxe/fpc/bin/x86_64-darwin/fpc.sh TargetOS=embedded TargetCPU=arm Options= FPCSrcDir=/Users/ring/fpcupdeluxe/fpcsrc/ Stamp=1" AUnitName="RP2040" TFPCUnitSetCache.GetUnitSrcFile Unit="RP2040" SrcSearchRequiresPPU=False SkipPPUCheckIfTargetIsSourceOnly=True TFPCUnitSetCache.GetUnitSrcFile Unit="RP2040" Result= TCTDirectoryCache.FindUnitInUnitSet Directory="/Users/ring/devel/pico-fpcexamples/blinky/" UnitSet="CompilerFilename=/Users/ring/fpcupdeluxe/fpc/bin/x86_64-darwin/fpc.sh#10TargetOS=embedded#10TargetCPU=arm#10Options=#10FPCSrcDir=/Users/ring/fpcupdeluxe/fpcsrc/#10Stamp=1" AUnitName="RP2040" Result="" TCTDirectoryCache.FindUnitSourceInCompletePath unit RP2040 not found in unitlinks. Directory="/Users/ring/devel/pico-fpcexamples/blinky/" TCTDirectoryCache.FindCompiledUnitInUnitSet Directory="/Users/ring/devel/pico-fpcexamples/blinky/" UnitSet="CompilerFilename=/Users/ring/fpcupdeluxe/fpc/bin/x86_64-darwin/fpc.sh TargetOS=embedded TargetCPU=arm Options= FPCSrcDir=/Users/ring/fpcupdeluxe/fpcsrc/ Stamp=1" AUnitName="RP2040.ppu" TCTDirectoryCache.FindCompiledUnitInUnitSet Directory="/Users/ring/devel/pico-fpcexamples/blinky/" UnitSet="CompilerFilename=/Users/ring/fpcupdeluxe/fpc/bin/x86_64-darwin/fpc.sh#10TargetOS=embedded#10TargetCPU=arm#10Options=#10FPCSrcDir=/Users/ring/fpcupdeluxe/fpcsrc/#10Stamp=1" AUnitName="RP2040.ppu" Result="" ### TCodeToolManager.HandleException: [20170421200056] "unit not found: RP2040" in "/Users/ring/devel/pico-fpcexamples/blinky/blinky.lpr" when I manually run the -ix command with my fpc I receive the hits I would expect: ~/fpcupdeluxe/fpc/bin/x86_64-darwin/fpc -Tembedded -Parm -ix | grep -i rp2040 and I also find the unit in my fpcsrc directory: find /Users/ring/fpcupdeluxe/fpcsrc -name "rp2040*" /Users/ring/fpcupdeluxe/fpcsrc/rtl/embedded/arm/rp2040.pp I am stuck because I cannot find the correct implementation for TCTGetCompiledUnitFromSet althoug I searched through all sources for (const UnitSet, AnUnitName: string) Michael Please note that you will not find unit rp2040 in official trunk, only in my version but the same issue should be there for any other existing embedded comtrollerunit -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Possible Codetools issue for embedded targets in main branch
I today looked at an issue posted in the lazarus forum: https://forum.lazarus.freepascal.org/index.php/topic,60790.0.html the user is unable to use ctrl-space for help because codetools cannot find the required unit rp2040. I could not reproduce the issue with my older installation of lazarus-trunk but when I upgraded to latest trunk from today I saw the same issue. Possible reason is that lazarus cannot extract the info about the unit source file from the output of the -ix format of fpc I commented out a few log entries and got this result: TFindDeclarationTool.FindUnitSource Self="/Users/ring/devel/pico-fpcexamples/blinky/blinky.lpr" AnUnitName="RP2040" AnUnitInFilename="" TCTDirectoryCache.FindUnitSourceInCompletePath AUnitName="RP2040" InFilename="" Directory="/Users/ring/devel/pico-fpcexamples/blinky/" TCTDirectoryCache.FindUnitSourceInCompletePath unit RP2040 not found in SrcPath="/Users/ring/devel/pico-fpcexamples/blinky;/Users/ring/devel/pico-fpcexamples/units" Directory="/Users/ring/devel/pico-fpcexamples/blinky/" searchin in unitset ... TCTDirectoryCache.FindUnitInUnitSet Directory="/Users/ring/devel/pico-fpcexamples/blinky/" UnitSet="CompilerFilename=/Users/ring/fpcupdeluxe/fpc/bin/x86_64-darwin/fpc.sh TargetOS=embedded TargetCPU=arm Options= FPCSrcDir=/Users/ring/fpcupdeluxe/fpcsrc/ Stamp=1" AUnitName="RP2040" TFPCUnitSetCache.GetUnitSrcFile Unit="RP2040" SrcSearchRequiresPPU=False SkipPPUCheckIfTargetIsSourceOnly=True TFPCUnitSetCache.GetUnitSrcFile Unit="RP2040" Result= TCTDirectoryCache.FindUnitInUnitSet Directory="/Users/ring/devel/pico-fpcexamples/blinky/" UnitSet="CompilerFilename=/Users/ring/fpcupdeluxe/fpc/bin/x86_64-darwin/fpc.sh#10TargetOS=embedded#10TargetCPU=arm#10Options=#10FPCSrcDir=/Users/ring/fpcupdeluxe/fpcsrc/#10Stamp=1" AUnitName="RP2040" Result="" TCTDirectoryCache.FindUnitSourceInCompletePath unit RP2040 not found in unitlinks. Directory="/Users/ring/devel/pico-fpcexamples/blinky/" TCTDirectoryCache.FindCompiledUnitInUnitSet Directory="/Users/ring/devel/pico-fpcexamples/blinky/" UnitSet="CompilerFilename=/Users/ring/fpcupdeluxe/fpc/bin/x86_64-darwin/fpc.sh TargetOS=embedded TargetCPU=arm Options= FPCSrcDir=/Users/ring/fpcupdeluxe/fpcsrc/ Stamp=1" AUnitName="RP2040.ppu" TCTDirectoryCache.FindCompiledUnitInUnitSet Directory="/Users/ring/devel/pico-fpcexamples/blinky/" UnitSet="CompilerFilename=/Users/ring/fpcupdeluxe/fpc/bin/x86_64-darwin/fpc.sh#10TargetOS=embedded#10TargetCPU=arm#10Options=#10FPCSrcDir=/Users/ring/fpcupdeluxe/fpcsrc/#10Stamp=1" AUnitName="RP2040.ppu" Result="" ### TCodeToolManager.HandleException: [20170421200056] "unit not found: RP2040" in "/Users/ring/devel/pico-fpcexamples/blinky/blinky.lpr" when I manually run the -ix command with my fpc I receive the hits I would expect: ~/fpcupdeluxe/fpc/bin/x86_64-darwin/fpc -Tembedded -Parm -ix | grep -i rp2040 and I also find the unit in my fpcsrc directory: find /Users/ring/fpcupdeluxe/fpcsrc -name "rp2040*" /Users/ring/fpcupdeluxe/fpcsrc/rtl/embedded/arm/rp2040.pp I am stuck because I cannot find the correct implementation for TCTGetCompiledUnitFromSet althoug I searched through all sources for (const UnitSet, AnUnitName: string) Michael Please note that you will not find unit rp2040 in official trunk, only in my version but the same issue should be there for any other existing embedded comtrollerunit -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Codetools and casing of unit files on Darwin
I am having an issue with casing of included units and codetools, I searched through Mantis but did not find anything matching although I think this issue is too obvious for nobody besides me seeing it: I am on Lazarus Trunk (from yesterday or the day before), on a x86_64 Mac with Big Sur installed. I have a unit in uses: uses UThisHasCamelCaseEverywhere; and the unit filename matches the written unit name. Codetools works fine... Then I change to: uses uthishascamelcaseeverywhere; now codetools complains that unit cannot be found when I try to get context help via ctrl-Space. However, the code still compiles fine because default Darwin Filesystem (and/or) fpc does not care for upper/lower case in filenames on Darwin The main reason why this behaviour is quite annoying is that traditionally(??) filenames for embedded Units are lowercase and their definition in cpuinfo.pas is uppercase: from cpuinfo.pas: (controllertypestr:'STM32F100X4'; controllerunitstr:'STM32F10X_LD'; ls ~/devel/fpc/rtl/embedded/arm allwinner_a20.pp cortexm3.pp cortexm7.pp lpc11xx.pp lpc21x4.pp mk22f51212.pp raspi2.pp stm32f10x_cl.pp stm32f10x_md.pp stm32f411xe.pp stm32f745.pp at91sam7x256.pp cortexm3_start.inc lm3fury.pp lpc122x.pp lpc8xx.pp mk64f12.pp sam3x8e.pp stm32f10x_conn.pp stm32f10x_xl.pp stm32f429.pp stm32f746.pp cortexm0.pp cortexm4.pp lm3tempest.pp lpc13xx.pp mk20d5.pp nrf51.pp sc32442b.pp stm32f10x_hd.pp stm32f401xx.pp stm32f429xx.pp stm32f756.pp cortexm0_start.inc cortexm4f_start.inc lm4f120.pp lpc1768.pp mk20d7.pp nrf52.pp stm32f0xx.pp stm32f10x_ld.pp stm32f407xx.pp stm32f446xx.pp xmc4500.pp Did I overlook some FAQ or should I open an issue on Mantis? Michael -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Cocoa Widet Set Status
Same here, I am also using anchordocking and the ide is quite stable for day to day work. Michael Am 03.06.19 um 22:05 schrieb Mattias Gaertner via lazarus: On Mon, 3 Jun 2019 15:31:31 -0400 Anthony Walter via lazarus wrote: Can anyone tell me in brief what is the current status of Lazarus on the Cocoa widget set on Mac? Does the IDE work at all? What is working and what fundamental stuff is significantly broken? I work with the Cocoa IDE and anchordocking. Works stable. Source editor popup menu does not work here. But I hardly need that. Mattias -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus not starting anymore since -r59627 on MacOSX Mojava x86_64 cocoa
Yes, I am using docking and in the crashlog there is also a reference to AnchorDocking. Good to know that there is already an issue for the problem. Michael Am 27.11.18 um 14:42 schrieb Dmitry Boyarintsev via lazarus: On Tue, Nov 27, 2018 at 5:25 AM Michael Ring via lazarus mailto:lazarus@lists.lazarus-ide.org>> wrote: The last working version is -r59626 Are you using docking? https://bugs.freepascal.org/view.php?id=34593 -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Lazarus not starting anymore since -r59627 on MacOSX Mojava x86_64 cocoa
The last working version is -r59626 after this I either received a crash, on latest trunk it take a little while until the crash is reported. removing the ~/.lazarus directory before starting does not help. (It sometimes helped in the past with similar issues) I have attached two crashlogs, 2nd one is from latest lazarus r59675 Michael Process: lazarus [23273] Path: /usr/local/share/lazarus/lazarus.app/Contents/MacOS/lazarus Identifier: lazarus.freepascal.ide Version: 2.1.0 (1) Code Type: X86-64 (Native) Parent Process: ??? [1] Responsible: lazarus [23273] User ID: 501 Date/Time: 2018-11-27 10:00:47.021 +0100 OS Version: Mac OS X 10.14.1 (18B75) Report Version: 12 Anonymous UUID: 6A731EE5-807E-5B80-F092-BF0389E45B2F Sleep/Wake UUID: F8736D66-860C-444E-B4F2-D44621004FE6 Time Awake Since Boot: 84000 seconds Time Since Wake: 1200 seconds System Integrity Protection: enabled Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x, 0x Exception Note: EXC_CORPSE_NOTIFY Application Specific Information: *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[TCocoaGroupBox setAllowsTruncatedLabels:]: unrecognized selector sent to instance 0x102a33900' terminating with uncaught exception of type NSException abort() called Application Specific Backtrace 1: 0 CoreFoundation 0x7fff4387ffa5 __exceptionPreprocess + 256 1 libobjc.A.dylib 0x7fff6f976efb objc_exception_throw + 48 2 CoreFoundation 0x7fff438fdc8d -[NSObject(NSObject) __retain_OA] + 0 3 CoreFoundation 0x7fff438215de ___forwarding___ + 1468 4 CoreFoundation 0x7fff43820f98 _CF_forwarding_prep_0 + 120 5 lazarus 0x00010030f8b7 COCOAWSCOMCTRLS$_$TCOCOAWSCUSTOMPAGE_$__$$_CREATEHANDLE$TWINCONTROL$TCREATEPARAMS$$TLCLINTFHANDLE + 143 6 lazarus 0x000100236c62 CONTROLS$_$TWINCONTROL_$__$$_CREATEWND + 2194 7 lazarus 0x0001002363ce CONTROLS$_$TWINCONTROL_$__$$_CREATEHANDLE + 46 8 lazarus 0x000100237ac7 CONTROLS$_$TWINCONTROL_$__$$_HANDLENEEDED + 119 9 lazarus 0x000100237aa9 CONTROLS$_$TWINCONTROL_$__$$_HANDLENEEDED + 89 10 lazarus 0x000100237aa9 CONTROLS$_$TWINCONTROL_$__$$_HANDLENEEDED + 89 11 lazarus 0x000100237aa9 CONTROLS$_$TWINCONTROL_$__$$_HANDLENEEDED + 89 12 lazarus 0x000100236a59 CONTROLS$_$TWINCONTROL_$__$$_CREATEWND + 1673 13 lazarus 0x000100655ac9 ETMESSAGEFRAME$_$TMESSAGESCTRL_$__$$_CREATEWND + 25 14 lazarus 0x0001002363ce CONTROLS$_$TWINCONTROL_$__$$_CREATEHANDLE + 46 15 lazarus 0x00010022ff44 CONTROLS$_$TWINCONTROL_$__$$_UPDATESHOWING + 84 16 lazarus 0x00010022e65c CONTROLS$_$TWINCONTROL_$_DOALLAUTOSIZE_$$_UPDATESHOWINGRECURSIVE$TWINCONTROL$BOOLEAN + 212 17 lazarus 0x00010022e61e CONTROLS$_$TWINCONTROL_$_DOALLAUTOSIZE_$$_UPDATESHOWINGRECURSIVE$TWINCONTROL$BOOLEAN + 150 18 lazarus 0x00010022e61e CONTROLS$_$TWINCONTROL_$_DOALLAUTOSIZE_$$_UPDATESHOWINGRECURSIVE$TWINCONTROL$BOOLEAN + 150 19 lazarus 0x00010022e61e CONTROLS$_$TWINCONTROL_$_DOALLAUTOSIZE_$$_UPDATESHOWINGRECURSIVE$TWINCONTROL$BOOLEAN + 150 20 lazarus 0x00010022e61e CONTROLS$_$TWINCONTROL_$_DOALLAUTOSIZE_$$_UPDATESHOWINGRECURSIVE$TWINCONTROL$BOOLEAN + 150 21 lazarus 0x00010022e61e CONTROLS$_$TWINCONTROL_$_DOALLAUTOSIZE_$$_UPDATESHOWINGRECURSIVE$TWINCONTROL$BOOLEAN + 150 22 lazarus 0x00010022e61e CONTROLS$_$TWINCONTROL_$_DOALLAUTOSIZE_$$_UPDATESHOWINGRECURSIVE$TWINCONTROL$BOOLEAN + 150 23 lazarus 0x00010022e61e CONTROLS$_$TWINCONTROL_$_DOALLAUTOSIZE_$$_UPDATESHOWINGRECURSIVE$TWINCONTROL$BOOLEAN + 150 24 lazarus 0x00010022e61e CONTROLS$_$TWINCONTROL_$_DOALLAUTOSIZE_$$_UPDATESHOWINGRECURSIVE$TWINCONTROL$BOOLEAN + 150 25 lazarus 0x00010022e454 CONTROLS$_$TWINCONTROL_$__$$_DOALLAUTOSIZE + 380 26 lazarus 0x000100247db9 CONTROLS$_$TCONTROL_$__$$_ENABLEAUTOSIZING + 233 27 lazarus 0x000100c6e2c7 ANCHORDOCKING$_$TANCHORDOCKMASTER_$__$$_ENABLEALLAUTOSIZING + 87 28 lazarus
Re: [Lazarus] Switching debugger based on Project settings for embedded targets
Hi Martin, thank you for the detailled answer. I like your idea of creating Id's for debugger configurations and as I want to go step by step (and I have great respect of 130kBytes of code in TEnvironmentOptions) I wanted to start small and grow as I go. I am tempted to give the full refactoring a pass 8-) and prefer your option 2) So I thought about how to create a usefull Id and came up with the following: first part could be CRC16 of the Caption (to define the pricipal debugger Module that is used): GNU debugger (gdb) --> 0x167E GNU debugger through SSH (gdb) --> 0xB2AE GNU remote debugger (gdbserver) --> 0x5579 GNU remote debugger via jlink (jlinkgdbserver) --> 0x463C then add CRC16 of lowercase basename of gdb used: gdb --> 0x84FD mips-sde-elf-gdb -->0x7B4E arm-none-eabi-gdb -->0xB5E7 and then we could add a CRC32 of all options changed from default (or CRC32 of all options) so an id could look like this: 167E-84FD- for native debugger using gdb 5579-7B4E- for gdbserver using mips version of gdb This would allow us to always select the right debugger module by looking at the first 4 chars, and for people working together there is a high chance that also the debugger part matches. We can of course fill this up to look like a propper UUID. That's already a reasonable starting point for a good configuration. We can tell the user (if we want to) that the debugger component used in the project cannot be found, we can also preconfigur the right debugger component when we find it and hint that the proper gdb is not jet configured. Not perfect, but this hopefully already covers a number of usecases. The real fun starts with also Checksumming the changes/all options, this allows us to pinpoint the exact configuration needed meaning that a developer will always get the perfect configuration for his own debug task. I first thought to explicity checksum even more fields (like Debugger_Remote_Port) but as there is no way back from a checksum to an actual setting I think it does not add much more benefit. What do you guys think? Michael Am 21.11.18 um 10:58 schrieb Dimitrios Chr. Ioannidis via lazarus: Hi, On 2018-11-20 23:44, Michael Ring via lazarus wrote: What is the best way to implement this project based override, I guess I can do the coding myself as I have also created my own debugger for JLink, but I do not know how to do this debugger switching in the proper 'Lazarus' way. I would like to be involved / help as I am thinking implementing the mEDBG protocol and intergrate it to Lazarus to debug AVR MCU's using this debugger https://hackaday.io/project/162372-xplained-yourself . I already tried to use the avr-gdb --> avarice --> dragon --> atmegaxxx combination ( which worked in Linux but not in Windows ) and the result is that I have 3 bricked mcu's ( most probably by flashes has been worn out by software breakpoints) . Not even the HVPP procedure restore them. Anyway if I can help ( and learn at the same time the Lazarus / Debug internals ) that would be awesome. regards, -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] mEDBG Debugger [[was: Re: Switching debugger based on Project settings for embedded targets]]
I can also provide you my implementation for JLink-Debugger if it helps, thanks to some great improovements Martin did in the past the code I needed to add was reduced to a minimum, and I am now checking if I need my own implementation at all Michael Am 21.11.18 um 14:28 schrieb Martin Frb via lazarus: On 21/11/2018 14:09, Dimitrios Chr. Ioannidis via lazarus wrote: Hi, thx for the info ! On 2018-11-21 14:25, Martin Frb via lazarus wrote: Depending on how your external exe works, you need some sort of control when to send which message, and how to parse the answers... Actually I'll communicate with the HW Debugger using mEDBG Protocol via Serial ( USB CDC ). So no external exe. Again thx for the info ! Well then you probably will need to look at the various FpDebug based debuggers too. FpDebug can read the dwarf info. You will need to implement run/pause/breakpoint (there is something in fpdebug, but I do not know if that works for you). And then provide memory access, so fpdebug can read data, to evaluate watches. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Switching debugger based on Project settings for embedded targets
Hi! Since a while I am using lazarus not only to edit/compile projects for embededded controllers, but also debugging now works very nicely. There is only one issue I see at the moment, the debugger is a global setting, afaik I cannot change the debugger configuration based on a project. The problem is that for debugging arm I will have to use arm-none-eabi-gdb, for pic32 I will have to use mips-sde-elf-gdb for debugging and both will have to use a special debugger class for interfacing with Segger JLink Debug Probe and possibly openocd in the future. Other people, that use Lazaeus for Windows/Linux/Mac Development would also need to change the global setting when switching from embedded development to native development to the default gdb debugger. What is the best way to implement this project based override, I guess I can do the coding myself as I have also created my own debugger for JLink, but I do not know how to do this debugger switching in the proper 'Lazarus' way. Thanks in advance, Michael -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Character spacing doubled in R58529 on MacOSX/Cocoa
Problem fixed, thank you very much! Michael Am 15.07.18 um 16:24 schrieb Dmitry Boyarintsev: You need to use 58531 On Sunday, July 15, 2018, Michael Ring via Lazarus mailto:lazarus@lists.lazarus-ide.org>> wrote: I today build Lazarus MacOSX/Cocoa**from svn and realized that all characters in the editor seem to have an extra space between each character. I did a little compiling of older SVN's and found out that the problem appeared first in revision 58529. This change in 58529 seems to kill the cat: Index: lcl/interfaces/cocoa/cocoagdiobjects.pas === --- lcl/interfaces/cocoa/cocoagdiobjects.pas (revision 58528) +++ lcl/interfaces/cocoa/cocoagdiobjects.pas (working copy) @@ -559,6 +559,7 @@ Win32Weight, LoopCount: Integer; CocoaWeight: NSInteger; FTmpFont: NSFont; + IsDefault: Boolean; begin inherited Create(AGlobal); @@ -570,7 +571,18 @@ // because otherwise the result is wrong in Mac OS X 10.11, see bug 30300 // Code used for 10.10 or inferior: // FName := NSStringToString(NSFont.systemFontOfSize(0).familyName); - if IsFontNameDefault(FName) then + // + // There's a differnet issue with not using systemFont. + // NSComboBox, if assigned a manually created font have an odd ascending-offset + // (easily seen in Xcode interface builder as well). systemFonts() + // don't have such issue at all. see bug 33626 + // the fix below (detecting "default" font and use systemFont()) is a potential + // regression for bug 30300. + // + // There might font properties (i.e. Transform Matrix) to adjust the position of + // the font. But at this time, it's safer to use systemFont() method + IsDefault := IsFontNameDefault(FName); + if not IsDefault then begin FTmpFont := NSFont.fontWithName_size(NSFont.systemFontOfSize(0).fontDescriptor.postscriptName, 0); FName := NSStringToString(FTmpFont.familyName); @@ -594,14 +606,14 @@ include(FStyle, cfs_StrikeOut); // If this is not a "systemFont" Create the font ourselves - FontName := NSStringUTF8(FName); - Attributes := NSDictionary.dictionaryWithObjectsAndKeys( - FontName, NSFontFamilyAttribute, - NSNumber.numberWithFloat(FSize), NSFontSizeAttribute, - nil); - FontName.release; - Descriptor := NSFontDescriptor.fontDescriptorWithFontAttributes(Attributes); - FFont := NSFont.fontWithDescriptor_textTransform(Descriptor, nil); + if IsDefault then + begin + FFont := NSFont.systemFontOfSize( FSize ); + end else begin + FontName := NSStringUTF8(FName); + FFont := NSFont.fontWithName_size(FontName, FSize); + FontName.release; + end; if FFont = nil then begin @@ -620,7 +632,6 @@ exit; end; end; - // we could use NSFontTraitsAttribute to request the desired font style (Bold/Italic) // but in this case we may get NIL as result. This way is safer. if cfs_Italic in Style then -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Character spacing doubled in R58529 on MacOSX/Cocoa
I today build Lazarus MacOSX/Cocoa**from svn and realized that all characters in the editor seem to have an extra space between each character. I did a little compiling of older SVN's and found out that the problem appeared first in revision 58529. This change in 58529 seems to kill the cat: Index: lcl/interfaces/cocoa/cocoagdiobjects.pas === --- lcl/interfaces/cocoa/cocoagdiobjects.pas (revision 58528) +++ lcl/interfaces/cocoa/cocoagdiobjects.pas (working copy) @@ -559,6 +559,7 @@ Win32Weight, LoopCount: Integer; CocoaWeight: NSInteger; FTmpFont: NSFont; + IsDefault: Boolean; begin inherited Create(AGlobal); @@ -570,7 +571,18 @@ // because otherwise the result is wrong in Mac OS X 10.11, see bug 30300 // Code used for 10.10 or inferior: // FName := NSStringToString(NSFont.systemFontOfSize(0).familyName); - if IsFontNameDefault(FName) then + // + // There's a differnet issue with not using systemFont. + // NSComboBox, if assigned a manually created font have an odd ascending-offset + // (easily seen in Xcode interface builder as well). systemFonts() + // don't have such issue at all. see bug 33626 + // the fix below (detecting "default" font and use systemFont()) is a potential + // regression for bug 30300. + // + // There might font properties (i.e. Transform Matrix) to adjust the position of + // the font. But at this time, it's safer to use systemFont() method + IsDefault := IsFontNameDefault(FName); + if not IsDefault then begin FTmpFont := NSFont.fontWithName_size(NSFont.systemFontOfSize(0).fontDescriptor.postscriptName, 0); FName := NSStringToString(FTmpFont.familyName); @@ -594,14 +606,14 @@ include(FStyle, cfs_StrikeOut); // If this is not a "systemFont" Create the font ourselves - FontName := NSStringUTF8(FName); - Attributes := NSDictionary.dictionaryWithObjectsAndKeys( - FontName, NSFontFamilyAttribute, - NSNumber.numberWithFloat(FSize), NSFontSizeAttribute, - nil); - FontName.release; - Descriptor := NSFontDescriptor.fontDescriptorWithFontAttributes(Attributes); - FFont := NSFont.fontWithDescriptor_textTransform(Descriptor, nil); + if IsDefault then + begin + FFont := NSFont.systemFontOfSize( FSize ); + end else begin + FontName := NSStringUTF8(FName); + FFont := NSFont.fontWithName_size(FontName, FSize); + FontName.release; + end; if FFont = nil then begin @@ -620,7 +632,6 @@ exit; end; end; - // we could use NSFontTraitsAttribute to request the desired font style (Bold/Italic) // but in this case we may get NIL as result. This way is safer. if cfs_Italic in Style then -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Problem compiling trunk LazUtils Error: (11006) Illegal parameter: -vm6058
Thank you! Things are back to normal now, Lazarus builds and installs & rebuilds just fine. Michael Am 25.06.18 um 09:20 schrieb Mattias Gaertner via Lazarus: On Sun, 24 Jun 2018 23:45:54 +0200 Bart via Lazarus wrote: On Sun, Jun 24, 2018 at 11:04 PM, Mattias Gaertner via Lazarus wrote: My fpc 3.0.4 simply ignores the parameter. What compiler flavor shows this error? 3.0.4rc1 does (never got to updating that to the actual 3.0.4 release). C:\Users\Bart\LazarusProjecten\ConsoleProjecten>fpc -vm6058 test.pas Error: Illegal parameter: -vm6058 Error: C:\devel\fpc\3.0.4\bin\i386-Win32\ppc386.exe returned an error exitcode I removed the option. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Problem compiling trunk LazUtils Error: (11006) Illegal parameter: -vm6058
Are you 100% sure that this message is 3.1.1+ only? Please look at the output below, the error is reported for /usr/local/bin/ppcx64, and when I do a version check on that file it returns 3.0.4 Error: (11006) Illegal parameter: -vm6058 Hint: (11007) -? writes help pages Error: /usr/local/bin/ppcx64 returned an error exitcode Error: (lazarus) Compile package LazUtils 1.0: stopped with exit code 256 /usr/local/bin/ppcx64 -iW 3.0.4 Am 24.06.18 um 13:00 schrieb Florian Klämpfl via Lazarus: Am 24.06.2018 um 12:07 schrieb Michael Ring via Lazarus: I cannot build current lazarus trunk on MacOSX, 64bits, not sure if the problem is because of my build environment or not. I have successfully build lazarus for a very long time with the steps I do. When I rebuild lazarus I get this error message: Error: (11006) Illegal parameter: -vm6058 when compiling LazUtils. I can workarround the problem by removing the following lines from lazutils.lpk: I do not see an obvious problem in my buildsystem: lrwxr-xr-x 1 root staff 23 4 Dez 2017 /usr/local/bin/ppc386 -> ../lib/fpc/3.0.4/ppc386 lrwxr-xr-x 1 root staff 23 4 Dez 2017 /usr/local/bin/ppcx64 -> ../lib/fpc/3.0.4/ppcx64 lrwxr-xr-x 1 ring staff 25 24 Jun 11:49 /usr/local/bin/lazbuild -> ../share/lazarus/lazbuild ppcx64 points to fpc 3.0.4 which is last official version so I guess all is fine. Any ideas? This error message is 3.1.1+ only. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Problem compiling trunk LazUtils Error: (11006) Illegal parameter: -vm6058
I cannot build current lazarus trunk on MacOSX, 64bits, not sure if the problem is because of my build environment or not. I have successfully build lazarus for a very long time with the steps I do. When I rebuild lazarus I get this error message: Error: (11006) Illegal parameter: -vm6058 when compiling LazUtils. I can workarround the problem by removing the following lines from lazutils.lpk: I do not see an obvious problem in my buildsystem: lrwxr-xr-x 1 root staff 23 4 Dez 2017 /usr/local/bin/ppc386 -> ../lib/fpc/3.0.4/ppc386 lrwxr-xr-x 1 root staff 23 4 Dez 2017 /usr/local/bin/ppcx64 -> ../lib/fpc/3.0.4/ppcx64 lrwxr-xr-x 1 ring staff 25 24 Jun 11:49 /usr/local/bin/lazbuild -> ../share/lazarus/lazbuild ppcx64 points to fpc 3.0.4 which is last official version so I guess all is fine. Any ideas? Michael Here's more detail on what I am doing: I first build lazarus with the following command: LCL_PLATFORM=cocoa CPU_TARGET=x86_64 COMPILERSWITCH="--compiler=ppcx64" make clean all CPU_TARGET=$CPU_TARGET LCL_PLATFORM=$LCL_PLATFORM OPT="-dLCLScaleForms -k'-framework' -k'ApplicationServices'" || exit 1 then I install lazarus to destination directory: sudo rm -rf /usr/local/share/lazarus sudo make install CPU_TARGET=$CPU_TARGET LCL_PLATFORM=$LCL_PLATFORM and then rebuild lazarus with lazbuild: sudo chown -R ring:staff /usr/local/share/lazarus lazbuild --build-ide= --ws=$LCL_PLATFORM --cpu=$CPU_TARGET $COMPILERSWITCH When rebuild starts I get this error message: Info: (lazarus) Execute Title="Compile package LazUtils 1.0" Info: (lazarus) Working Directory="/usr/local/share/lazarus/components/lazutils/" Info: (lazarus) Executable="/usr/local/bin/fpc" Info: (lazarus) Param[0]="-B" Info: (lazarus) Param[1]="-MObjFPC" Info: (lazarus) Param[2]="-Scghi" Info: (lazarus) Param[3]="-O1" Info: (lazarus) Param[4]="-gw" Info: (lazarus) Param[5]="-gl" Info: (lazarus) Param[6]="-l" Info: (lazarus) Param[7]="-vewnhibq" Info: (lazarus) Param[8]="-vm6058" Info: (lazarus) Param[9]="-Fu/usr/local/share/lazarus/packager/units/x86_64-darwin" Info: (lazarus) Param[10]="-Fu/usr/local/share/lazarus/components/lazutils/" Info: (lazarus) Param[11]="-FU/usr/local/share/lazarus/components/lazutils/lib/x86_64-darwin/" Info: (lazarus) Param[12]="-O2" Info: (lazarus) Param[13]="-g-" Info: (lazarus) Param[14]="-Xs" Info: (lazarus) Param[15]="lazutils.pas" Error: (11006) Illegal parameter: -vm6058 Hint: (11007) -? writes help pages Error: /usr/local/bin/ppcx64 returned an error exitcode -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] How to use two different versions of FPC
Do you have plans to make it possible to switch debuggers in the same plugin, too? This would be very helpful for embedded targets, it is always a pain to reconfigure gdb when switching between an embedded and a native target. Could it also be possible to make this plugin project based? Looks very promising, Michael Am 11.05.18 um 15:40 schrieb patspiper via Lazarus: On 11/05/18 16:17, Joost van der Sluis via Lazarus wrote: On 05/10/2018 04:35 PM, patspiper via Lazarus wrote: Attached snapshot is work in progress Sorry, but I don't think this is an improvement. For new users this looks like a nightmare. It should be hidden, at least, imho. Or better: make it a plugin. As Mattias has pointed out, it is a plugin (IDE package), and definitely not for the faint of heart. Once one creates a standardized folder hierarchy for the different fpc versions, it becomes a matter of a few clicks to switch versions. Stephano -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Cannot enter '^' in Lazarus trunk build macos/cocoa/x86_64
) NS_setFlushesWithDisplayRefresh]_block_invoke + 283 38 com.apple.CoreFoundation 0x7fff2e4cb787 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23 39 com.apple.CoreFoundation 0x7fff2e4cb6af __CFRunLoopDoObservers + 511 40 com.apple.CoreFoundation 0x7fff2e4ae178 __CFRunLoopRun + 1240 41 com.apple.CoreFoundation 0x7fff2e4ada07 CFRunLoopRunSpecific + 487 42 com.apple.HIToolbox 0x7fff2d78bd96 RunCurrentEventLoopInMode + 286 43 com.apple.HIToolbox 0x7fff2d78bb06 ReceiveNextEventCommon + 613 44 com.apple.HIToolbox 0x7fff2d78b884 _BlockUntilNextEventMatchingListInModeWithFilter + 64 45 com.apple.AppKit 0x7fff2ba3ea73 _DPSNextEvent + 2085 46 com.apple.AppKit 0x7fff2c1d4e34 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 3044 47 lazarus.freepascal.ide 0x0001001dc941 COCOAINT$_$TCOCOAWIDGETSET_$__$$_APPWAITMESSAGE + 113 Thread 1: 0 libsystem_kernel.dylib 0x7fff569b6292 __workq_kernreturn + 10 1 libsystem_pthread.dylib 0x7fff56b7d20e _pthread_wqthread + 1552 2 libsystem_pthread.dylib 0x7fff56b7cbe9 start_wqthread + 13 Thread 2: 0 libsystem_kernel.dylib 0x7fff569b6292 __workq_kernreturn + 10 1 libsystem_pthread.dylib 0x7fff56b7d009 _pthread_wqthread + 1035 2 libsystem_pthread.dylib 0x7fff56b7cbe9 start_wqthread + 13 Thread 3: 0 libsystem_pthread.dylib 0x7fff56b7cbdc start_wqthread + 0 1 ??? 0x0001 0 + 1 Thread 4: 0 libsystem_pthread.dylib 0x7fff56b7cbdc start_wqthread + 0 1 ??? 0x00030003 0 + 12884901891 Thread 5:: com.apple.NSEventThread 0 libsystem_kernel.dylib 0x7fff569ac20a mach_msg_trap + 10 1 libsystem_kernel.dylib 0x7fff569ab724 mach_msg + 60 2 com.apple.CoreFoundation 0x7fff2e4af045 __CFRunLoopServiceMachPort + 341 3 com.apple.CoreFoundation 0x7fff2e4ae397 __CFRunLoopRun + 1783 4 com.apple.CoreFoundation 0x7fff2e4ada07 CFRunLoopRunSpecific + 487 5 com.apple.AppKit 0x7fff2bb7bfc4 _NSEventThread + 184 6 libsystem_pthread.dylib 0x7fff56b7d661 _pthread_body + 340 7 libsystem_pthread.dylib 0x7fff56b7d50d _pthread_start + 377 8 libsystem_pthread.dylib 0x7fff56b7cbf9 thread_start + 13 Thread 0 crashed with X86 Thread State (64-bit): rax: 0x rbx: 0x7fff8eb64380 rcx: 0x7ffeefbf9788 rdx: 0x rdi: 0x0307 rsi: 0x0006 rbp: 0x7ffeefbf97c0 rsp: 0x7ffeefbf9788 r8: 0x7ffeefbf9650 r9: 0x7ffeefbf9820 r10: 0x r11: 0x0206 r12: 0x0307 r13: 0x0030 r14: 0x0006 r15: 0x002d rip: 0x7fff569b5b6e rfl: 0x0206 cr2: 0x7fff8eb41168 Logical CPU: 0 Error Code: 0x02000148 Trap Number: 133 Am 02.05.18 um 16:06 schrieb Michael Ring via Lazarus: I guess you will have to install the german layout as this deadkey stuff is layout specific. Fun fact is that you also cannot enter ^ with the Keyboard overview of MacOS, when I switch to US keyboard all is fine for me. fyi, the '^' key is left of the '1' key on a german keyboard on Macbook Pro Michael Am 02.05.18 um 15:24 schrieb Dmitry Boyarintsev via Lazarus: On Wed, May 2, 2018 at 9:09 AM, Michael Ring via Lazarus <lazarus@lists.lazarus-ide.org <mailto:lazarus@lists.lazarus-ide.org>> wrote: As it is a dead key you first press '^' on the keyboard and then space. other example: á is created by first pressing '´' and then 'a' Do you know, if it's required to have German layout to be installed in the system. IIRC (away from mac right now), "^" is entered by pressing Shift+6 on Mac (ansi keyboard with US keys layout) ...and it works. What I'm thinking is that you're trying to enter the character in SynEdit. and it might be that Cocoa doesn't report a certain key combinations properly. I presume you didn't have this issue in Carbon, thus it's neither SynEdit bug nor macOS specific behavior, but rather LCLCocoa issue. That's why I need to know keys combination in order to track the problem on my end. thanks, Dmitry -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Cannot enter '^' in Lazarus trunk build macos/cocoa/x86_64
I guess you will have to install the german layout as this deadkey stuff is layout specific. Fun fact is that you also cannot enter ^ with the Keyboard overview of MacOS, when I switch to US keyboard all is fine for me. fyi, the '^' key is left of the '1' key on a german keyboard on Macbook Pro Michael Am 02.05.18 um 15:24 schrieb Dmitry Boyarintsev via Lazarus: On Wed, May 2, 2018 at 9:09 AM, Michael Ring via Lazarus <lazarus@lists.lazarus-ide.org <mailto:lazarus@lists.lazarus-ide.org>> wrote: As it is a dead key you first press '^' on the keyboard and then space. other example: á is created by first pressing '´' and then 'a' Do you know, if it's required to have German layout to be installed in the system. IIRC (away from mac right now), "^" is entered by pressing Shift+6 on Mac (ansi keyboard with US keys layout) ...and it works. What I'm thinking is that you're trying to enter the character in SynEdit. and it might be that Cocoa doesn't report a certain key combinations properly. I presume you didn't have this issue in Carbon, thus it's neither SynEdit bug nor macOS specific behavior, but rather LCLCocoa issue. That's why I need to know keys combination in order to track the problem on my end. thanks, Dmitry -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Cannot enter '^' in Lazarus trunk build macos/cocoa/x86_64
As it is a dead key you first press '^' on the keyboard and then space. other example: á is created by first pressing '´' and then 'a' Michael Am 02.05.18 um 12:12 schrieb Dmitry Boyarintsev via Lazarus: What’s the keys combination to enter ‘^’? Thanks, Dmitry On Wednesday, May 2, 2018, Michael Ring via Lazarus <lazarus@lists.lazarus-ide.org <mailto:lazarus@lists.lazarus-ide.org>> wrote: I yesterday tried again after a long time to build Lazarus with Cocoa on my Mac, Lazarus is now perfectly useable for my needs and as a bonus it seems a little faster than the Carbon version. Great work! The only issue I ran in is that I cannot enter '^' from my german keyboard and, as a fact, also other charaters composed with deadkeys (accented keys) like á also do not work. Any ideas on how to fix that? Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org <mailto:Lazarus@lists.lazarus-ide.org> https://lists.lazarus-ide.org/listinfo/lazarus <https://lists.lazarus-ide.org/listinfo/lazarus> -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Cannot enter '^' in Lazarus trunk build macos/cocoa/x86_64
I yesterday tried again after a long time to build Lazarus with Cocoa on my Mac, Lazarus is now perfectly useable for my needs and as a bonus it seems a little faster than the Carbon version. Great work! The only issue I ran in is that I cannot enter '^' from my german keyboard and, as a fact, also other charaters composed with deadkeys (accented keys) like á also do not work. Any ideas on how to fix that? Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Mac users: High-DPI
I have a Retina Display, for me the Lazarus IDE looks just fine. There are some very minor issues with Buttons not beeing big enough similar, but there are only very view. I cannot judge how Apps built with the option look like, I use Lazarus for development on Embedded Controllers only. I will send you three screenshots I've made via PM, my Lazarus was built with Carbon, running a Cocoa Build now... Thank you very much for your great work, Michael Am 09.03.17 um 16:18 schrieb Ondrej Pokorny via Lazarus: On 09.03.2017 16:10, Michael Ring via Lazarus wrote: I build Lazarus about every other week from trunk and use it on my Mac. I have no idea on how to solve the issue but when you want me to test something on trunk let me know... Yes :) If you use Carbon or Cocoa: how does the latest Lazarus IDE look like (check that it is built with Application.Scaled (Project Options -> Application -> "Use LCL scaling (Hi-DPI)). Is everything fine - text size, button size etc? Did anything change from 1.6? Do you have a retina display? If yes, could you upload a screenshot somewhere? Thanks! Ondrej -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
