[Lazarus] fatal error while make lazarus
My system is osx yosemite fpc svn lazarus svn and this is my command line: make PREFIX=/opt/lazarus clean all bigide CPU_TARGET=x86_64 LCL_PLATFORM=qt OPT=-k'-framework' -k'ApplicationServices' -dUSE_QT_45 -g -gl _q_DrawWinPanel, referenced from: _QTOBJECTS$_$TQTDEVICECONTEXT_$__$$_QDRAWWINPANEL$crc3564D156 in qtobjects.o ld: symbol(s) not found for architecture x86_64 An error occurred while linking lazarus.pp(144) Error: Error while linking lazarus.pp(144) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted make[2]: *** [lazarus] Error 1 make[1]: *** [ide] Error 2 make: *** [ide] Error 2 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Alternative component palette layout
On Fri, Dec 26, 2014 at 2:04 PM, Giuliano Colla giuliano.co...@fastwebnet.it wrote: The patch has no effect, but I suspect that the problem is elsewhere, because in my tests the TabControl.Pages.Move() is never called. That is not true. It is called from TComponentPage.InsertVisiblePage for any existing page that gets a new position index. Just debug it if you don't believe. You also wrote that you recreated the whole modern layout for your palette setup. It should not be needed. Non-existent components are skipped and you should be able to import any configuration. If you get an error during the import, then there is another bug. I start to suspect you have local changes in your code which cause the errors. Juha -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Alternative component palette layout
Il 27/12/2014 11:04, Juha Manninen ha scritto: On Fri, Dec 26, 2014 at 2:04 PM, Giuliano Colla giuliano.co...@fastwebnet.it wrote: The patch has no effect, but I suspect that the problem is elsewhere, because in my tests the TabControl.Pages.Move() is never called. That is not true. It is called from TComponentPage.InsertVisiblePage for any existing page that gets a new position index. Just debug it if you don't believe. You are right. I found out that it depends on the difference between the old and the new layout. It's not called with my layout, it's called with yours. With my layout, it happens that the move performed in CreatePagesFromUserOrder is already the good one. Just a coincidence. You also wrote that you recreated the whole modern layout for your palette setup. It should not be needed. Non-existent components are skipped and you should be able to import any configuration. If you get an error during the import, then there is another bug. It was just for testing purpose. I didn't get errors during the import of the Modern layout, I only had misplaced tabs with Qt. With my layout I didn't have misplaced tabs with the import, but I had when restoring the default. Just because of a slightly different order of tabs. I start to suspect you have local changes in your code which cause the errors. svn diff doesn't show anything strange, and the only problem is with Qt ws, and in a very specific condition: 1) a number of tabs are added in the first positions (0,1,2 in one of my tests) 2) some are skipped because they are already in place (3,4,5,6 ) 3) a new tab should be inserted just after those skipped (index = 7) and goes instead before them ( at position 3). Everything tells that it goes to index 7, up to TQtTabWidgetset.insertTab(), but it shows at index 3! Then of course everything goes astray, because the tab index are out of sync. I suspect that the problem arises from tab components being possibly shared by two widgets: I can see that at start, there are two InsertTab sequences: one with the number of visible tabs of the selected layout, and another one with all the tabs. It's possible that different widgetsets behave differently in this condition. My question is: is it necessary? However I've found a simple workaround: with Qt ws, to remove the old tab before calling InsertVisiblePage. That way PageComponent is always nil, and everything works just fine. If you agree, I can commit my change (it's really minimal) and you may check it. Giuliano -- Giuliano Colla Project planning question: when it's 90% done, are we halfway or not yet? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Alternative component palette layout
Il 27/12/2014 15:56, Giuliano Colla ha scritto: I suspect that the problem arises from tab components being possibly shared by two widgets: I can see that at start, there are two InsertTab sequences: one with the number of visible tabs of the selected layout, and another one with all the tabs. It's possible that different widgetsets behave differently in this condition. My question is: is it necessary? Please ignore this paragraph! The second InsertTab sequence is for the source editor tabs! I had not realized it! Giuliano -- Giuliano Colla Project planning question: when it's 90% done, are we halfway or not yet? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] fatal error while make lazarus
On 12/27/2014 09:58 AM, FreeMan wrote: My system is osx yosemite fpc svn lazarus svn and this is my command line: make PREFIX=/opt/lazarus clean all bigide CPU_TARGET=x86_64 LCL_PLATFORM=qt OPT=-k'-framework' -k'ApplicationServices' -dUSE_QT_45 -g -gl _q_DrawWinPanel, referenced from: _QTOBJECTS$_$TQTDEVICECONTEXT_$__$$_QDRAWWINPANEL$crc3564D156 in qtobjects.o ld: symbol(s) not found for architecture x86_64 1.You must have 64bit Qt. 2.You must build your own libQt4Pas for 64bit. zeljko -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Alternative component palette layout
On Sat, Dec 27, 2014 at 4:56 PM, Giuliano Colla giuliano.co...@fastwebnet.it wrote: However I've found a simple workaround: with Qt ws, to remove the old tab before calling InsertVisiblePage. That way PageComponent is always nil, and everything works just fine. If you agree, I can commit my change (it's really minimal) and you may check it. Yes, that workaround would prevent moving tabs and it could be added with IFDEF LCLQt. The bug is most likely a regression in recent QT versions. I applied the change from Zeljko. It uses QTabBar_moveTab and is an improvement but still does not solve the problem. I see if I can reproduce it in a small test application. Juha -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Alternative component palette layout
On Sat, Dec 27, 2014 at 6:35 PM, Juha Manninen juha.mannine...@gmail.com wrote: I see if I can reproduce it in a small test application. I cannot reproduce it. I give up. Juha -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Alternative component palette layout
Il 27/12/2014 17:35, Juha Manninen ha scritto: On Sat, Dec 27, 2014 at 4:56 PM, Giuliano Colla giuliano.co...@fastwebnet.it wrote: However I've found a simple workaround: with Qt ws, to remove the old tab before calling InsertVisiblePage. That way PageComponent is always nil, and everything works just fine. If you agree, I can commit my change (it's really minimal) and you may check it. Yes, that workaround would prevent moving tabs and it could be added with IFDEF LCLQt. Committed with rev 47255. You'll find the workaround (surrounded by the IFDEF LCLQt) + some added Debugln + a minor fix (a ShowHint := true was missing) + an attempt to use a different code for moving tabs (surrounded by an IFDEF USE_PageIndex). It doesn't make any difference but it saves a number of tests, because they're done in LCL. You may keep it or throw it away following your taste. The bug is most likely a regression in recent QT versions. I applied the change from Zeljko. It uses QTabBar_moveTab and is an improvement but still does not solve the problem. I see if I can reproduce it in a small test application. I hope you'll have better chance than me. I tried with a small test application, but no way to reproduce the bug. Tabs were always inserted/moved properly. True, I did use just standard components i.e. a standard NoteBook with standart TabSheet, and my tabs didn't come from a StringList, but I don't see how this should make a difference. The Qt code involved was exactly the same, as far as I can tell, and my debugln's tell. Giuliano -- Giuliano Colla Project planning question: when it's 90% done, are we halfway or not yet? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Getting the last modified date of a directory
On Sat, Oct 25, 2014 at 06:19:07PM +0100, Richard Mace wrote:
I can see that we have a FileAge function and also a FileGetDate
however, I was wondering what the best way of getting the last modified
date of a folder? Effectively, the last time that a file was
created/changed within a folder?
On Windows you can access finddata, I did this to get the creation time, but
the record has multiple fields:
{$mode delphi}
uses sysutils,windows;
function GetFileInformation(const FileName: string; out FileInfo:
TSearchRec): Boolean;
begin
Result := FindFirst(FileName, faAnyFile, FileInfo) = 0;
if Result then
SysUtils.FindClose(FileInfo);
end;
function GetFileInformation2(const FileName: string): TSearchRec;
begin
if not GetFileInformation(FileName, Result) then
RaiseLastOSError;
end;
function GetFileCreation(const FileName: string): TFileTime;
begin
Result := GetFileInformation2(FileName).FindData.ftCreationTime;
end;
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Log4D weirdness
On Fri, Dec 19, 2014 at 06:49:07PM -0300, Mario R. Carro wrote: There's a LogLog variable that is destroyed in the finalization section (and fails). The problem is that the TLogODSAppender created in the ctor ends up destroyed inside the AddAppender call. This is the AddAppender code: procedure TLogLogger.AddAppender(const Appender: ILogAppender); begin LockLogger; try if FAppenders.IndexOf(Appender) = -1 then begin FAppenders.Add(Appender); if FHierarchy nil then FHierarchy.FireAppenderEvent(True, Self, Appender); end; finally UnlockLogger; end; end; Yes, this is a known kind of buggy code. (buildin assumptions of Delphi code that only happens to work on Delphi). Delphi /usually/ destroys automatically created temps at the end of a function, while FPC can also do it after a block. Best is to explicitely keep a local variable reference, local variable references are kept to the end at the moment, as you already found out. Who is at fault here? Log4D? The compiler? Me? Hard to say, there is some opinion involved there. Like many cases, Delphi does not specify this behaviour, and in general for Delphi not much is known what of the implementation is intended, or what is coincidence. This is aggrevated by the fact that too much Delphi code messing with interface refcounting seems to be created with trial and error. However it has come up a zillion times in the bugtracker, and FPC compiler devels have stated that they won't fix it (since it could inhibit/complicate implementing certain optimizations in the future), and the code is shoddy to start with. Best is to root out these kinds of bugs in the relevant projects (in this case Log4D) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] FPDoc Editor vs Lazarus Documentation Tool
On Sat, Dec 20, 2014 at 07:06:09PM -0300, silvioprog wrote: Yes, I want it too, and this is a very nice option (I use a similar approach in other IDEs). The documentation generated by the FPDoc is not responsive (e.g: http://goo.gl/bCJoPM), i.e., it does not open well on a mobile device. But I believe that the FPC team can accept a patch to apply the Bootstrap ( http://getbootstrap.com/) in FPDoc and all generated documentation could have a better appearance and be compatible with any device that can render HTML. =) Probably not. CHM Windows viewer operates in an older IE compat mode, and not all modern sets are supported. Moreover the Lazarus help viewer would have to implement those features. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] AWS Lib - Object Pascal library for the Amazon Web Services
Hi, I'm glad to announce the 0.2 release of AWS Lib, a minimalistic Object Pascal implementation for the Amazon Web Services. The project has been completely rewritten using OOP. It is extensible, fully object-oriented, interface-based and all objects are immutable objects. https://github.com/mdbs99/AWS Operations such authentication, create/delete buckets, upload/download objects (files and folders), work perfectly. There are Unit tests for all code. Synapse is used for HTTP protocol, but all classes work by contract (interfaces) then you can use lNet, fphttpclient or whatever you want, just implement the interfaces. The classes are sealed to encourage decorator pattern, not inheritance. Improvements will come and comments are welcome. Thank you. Regards, Marcos Douglas -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Log4D weirdness
Am 27.12.2014 um 22:49 schrieb Marco van de Voort: On Fri, Dec 19, 2014 at 06:49:07PM -0300, Mario R. Carro wrote: There's a LogLog variable that is destroyed in the finalization section (and fails). The problem is that the TLogODSAppender created in the ctor ends up destroyed inside the AddAppender call. This is the AddAppender code: procedure TLogLogger.AddAppender(const Appender: ILogAppender); [...] Yes, this is a known kind of buggy code. (buildin assumptions of Delphi code that only happens to work on Delphi). Delphi /usually/ destroys automatically created temps at the end of a function, while FPC can also do it after a block. Best is to explicitely keep a local variable reference, local variable references are kept to the end at the moment, as you already found out. Who is at fault here? Log4D? The compiler? Me? Hard to say, there is some opinion involved there. Like many cases, Delphi does not specify this behaviour, and in general for Delphi not much is known what of the implementation is intended, or what is coincidence. This is aggrevated by the fact that too much Delphi code messing with interface refcounting seems to be created with trial and error. Also strings had (have?) problems with refcounting of *const* parameters in Delphi. As a first try I remove the const, in case of unexpected trouble. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
