Re: [Lazarus] global operator overloading
Am 26.02.2013 08:59 schrieb xrfang xrf...@gmail.com: No, it's not a dilemma, but rather a requirement. Before generics specialization, all required operations for given type must be known. This is because the symbol table when the generics is parsed must be reconstructed when it gets specialized. Think about declaring usual classes with the generic parameter replaced with actual type. If at that time, the operation is not yet defined, the code won't compile anyway. It is a pity. I think if fpc supports class operators, maybe this problem could be solved by using class helpers (my purpose is that users of ttreap class does not have to modify treap.pas) ? Is that possible in future FPC? Helpers have the same problem. For now there is only one solution (as I already wrote): require that the type with which you specialize is a record. Then a class operator in that record can be defined. For the future I already have the following longterm plans: - add class operator support to class and object - allow to specify additional units after specialize that will be used when specializing (they will be added first, so that the original code is not unnecessarily modified) Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] global operator overloading
Hi Sven, Could you please give a simple example that shows what you said: require that the type with which you specialize is a record. Then a class operator in that record can be defined. Thanks 2013/2/26 Sven Barth pascaldra...@googlemail.com Am 26.02.2013 08:59 schrieb xrfang xrf...@gmail.com: No, it's not a dilemma, but rather a requirement. Before generics specialization, all required operations for given type must be known. This is because the symbol table when the generics is parsed must be reconstructed when it gets specialized. Think about declaring usual classes with the generic parameter replaced with actual type. If at that time, the operation is not yet defined, the code won't compile anyway. It is a pity. I think if fpc supports class operators, maybe this problem could be solved by using class helpers (my purpose is that users of ttreap class does not have to modify treap.pas) ? Is that possible in future FPC? Helpers have the same problem. For now there is only one solution (as I already wrote): require that the type with which you specialize is a record. Then a class operator in that record can be defined. For the future I already have the following longterm plans: - add class operator support to class and object - allow to specify additional units after specialize that will be used when specializing (they will be added first, so that the original code is not unnecessarily modified) Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] global operator overloading
On 02/26/2013 09:07 AM, Sven Barth wrote: Helpers have the same problem. For now there is only one solution (as I already wrote): require that the type with which you specialize is a record. Then a class operator in that record can be defined. For the future I already have the following longterm plans: - add class operator support to class and object - allow to specify additional units after specialize that will be used when specializing (they will be added first, so that the original code is not unnecessarily modified) Here a funny question come up: Why do we (still) have records at all ? We do have classes that allow for static and/or virtual methods (of course no methods at all are possible, too. ) So why are record that now can have more than none methods. The only difference I see is that records can reside in other places than on the heap. But (if necessary) a certain type of class seems more straight forward to me (of course with record as a synonym for compatibility) . AFAIK even old style Turbo-Pascal Objects are still in place That could be a certain type of class as well. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TOpenGLControl: multisampling not working (Linux/GLX)
On Tue, 26 Feb 2013 06:05:15 +0100 Michalis Kamburelis michalis.ka...@gmail.com wrote: Reimar Grabowski wrote: Hi, as the title says multisampling does not work for me. I was testing TOpenGLControl.MultiSampling on Linux (with Radeon GPU), it worked fine for me. Note that there is a fallback (documented in TCustomOpenGLControl interface): if the requested MultiSampling is not available, we fallback to non-multisampled context (that's because for most applications anti-aliasing can be just an optional feature). I guess you already checked that this didn't happen in your case? I checked: There is no error, so the fallback is not called. The code is pretty straightforward, in glgtkglxcontext.pas LOpenGLCreateContextCore gets called with given MultiSampling value, and then CreateOpenGLContextAttrList adds to the attributes this: Add(GLX_SAMPLE_BUFFERS_ARB); Add(1); Add(GLX_SAMPLES_ARB); Add(MultiSampling); The GLX_SAMPLES_ARB is the minimal required value (as http://www.opengl.org/registry/specs/ARB/multisample.txt says ...accepts GLX_SAMPLES_ARB in attribList, followed by the minimum number of samples that can be accepted in the multisample buffer). So it should work... Well, unless GLX is just lying to us. Can you check what list was created in your case by CreateOpenGLContextAttrList, did it contain appropriate GLX_SAMPLES_ARB and MultiSampling items? Yes, it does and the copy contains them too. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TOpenGLControl: multisampling not working (Linux/GLX)
On Mon, 25 Feb 2013 19:20:57 +0100 Reimar Grabowski reimg...@web.de wrote: [...] 3. The FBConfig then gets passed to glxCreateNewContext which returns a GLXContext. I get the ID from this context using glxQueryContext with GLX_FBCONFIG_ID. Looking up the ID in glxinfos list of FBConfigs shows that I get a non-conformant context with the specified number of red, green, blue and alpha bits, multisampling enabled and with the specified number of samples. Everything looks fine. 4. Then the GTK/GDK stuff kicks in (which I have not the slightest clue about) and when all is said and done I end up without multisampling in my GL code. Querying the GLX_FBCONFIG_ID later still shows the same config *with* sample buffers and GL_MULTISAMPLE is enabled. Maybe some drivers need an explicit activation or more parameters? Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Error: Incompatible type for arg no. 1: Got TFPPenEndCap, expected TPenEndCap
On Mon, Feb 25, 2013 at 7:19 PM, Mattias Gaertner nc-gaert...@netcologne.de wrote: On Mon, 25 Feb 2013 22:43:36 +0200 patspiper patspi...@gmail.com wrote: On 25/02/13 21:37, Marcos Douglas wrote: On Mon, Feb 25, 2013 at 11:09 AM, Marcos Douglas m...@delfire.net wrote: Hi, I updated my FPC to 2.6.3 (rev 23658) and my Lazarus trunk (rev 40403) I'm using Windows. When I try to compile Lazarus, I got: W:\md\dev\freepascal\ide\laz\1.1\ide\syncolorattribeditor.pas(167,26) Error: Incompatible type for arg no. 1: Got TFPPenEndCap, expected TPenEndCap W:\md\dev\freepascal\ide\laz\1.1\ide\syncolorattribeditor.pas(197,26) Error: Incompatible type for arg no. 1: Got TFPPenEndCap, expected TPenEndCap W:\md\dev\freepascal\ide\laz\1.1\ide\syncolorattribeditor.pas(579) Fatal: There were 2 errors compiling module, stopping Nobody has the same problem? Lazarus trunk compiles with FPC 2.7.1 and 2.6.2, but not 2.6.3. Pls submit a bug report. Lazarus rev 40410 compiles with fpc 2.6.3. Yep, thank you. Marcos Douglas -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] global operator overloading
On 26.02.2013 09:36, Xiangrong Fang wrote: Hi Sven, Could you please give a simple example that shows what you said: require that the type with which you specialize is a record. Then a class operator in that record can be defined. Let's suppose you have the following generic declaration: === example begin === type generic TTreapT1, T2 = class // let's assume T1 requires end; === example end === If you use a record to specialize TTreap's T1 parameter then you can do it the following way: === example begin === type TMyRecord = record // note: in mode objfpc the modeswitch advancedrecords is needed class operator (aLeft, aRight: TMyRecord): Boolean; end; // implementation: class operator TMyRecord.(aLeft, aRight: TMyRecord): Boolean; begin // compare aLeft and aRight end; // somewhere else TTreapTMyRecordLongInt = specialize TTreapTMyRecord, LongInt; === example end === Now the generic will specialize without problem. If you want to specialize other types that don't support class operators then you need to wrap them inside a record, e.g.: === example begin === type TRecTStringList = record MyStringList: TStringList; class operator (aLeft, aRight: TRecTStringList): Boolean; end; === example end === You can also use visibility modifiers like private or strict private to hide the MyStringList field and make it accessible only through properties. To simplyfy usage you can also define assignment operators. E.g.: === example begin === type // maybe it will also work with a TStringList if you use TStrings instead... TRecTStringList = record private fStringList: TStringList; public class operator := (aRight: TStringList): TRecTStringList; class operator := (aRight: TRecStringList): TStringList; end; class operator TRecTStringList.:=(aRight: TStringList): TRecTStringList; begin Result.fStringList := aRight; end; class operator TRecTStringList.:=(aRight: TRecStringList): TStringList; begin Result := aRight.fStringList; end; // somewhere else: var sl: TStringList; rec: TRecStringList; begin // setup sl rec := sl; // use rec in the tree sl := rec; end; === example end === It's not the nicest solution, but currently the only thing you can do. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] global operator overloading
On 26.02.2013 10:16, Michael Schnell wrote: On 02/26/2013 09:07 AM, Sven Barth wrote: Helpers have the same problem. For now there is only one solution (as I already wrote): require that the type with which you specialize is a record. Then a class operator in that record can be defined. For the future I already have the following longterm plans: - add class operator support to class and object - allow to specify additional units after specialize that will be used when specializing (they will be added first, so that the original code is not unnecessarily modified) Here a funny question come up: Why do we (still) have records at all ? We do have classes that allow for static and/or virtual methods (of course no methods at all are possible, too. ) So why are record that now can have more than none methods. The only difference I see is that records can reside in other places than on the heap. But (if necessary) a certain type of class seems more straight forward to me (of course with record as a synonym for compatibility) . The critical difference between records and classes besides the ability of records to reside on the stack is that they don't allow inheritance and they support variable parts. The don't allow inheritance is important, because otherwise you'll have a certain overhead like virtual method resolution. AFAIK even old style Turbo-Pascal Objects are still in place That could be a certain type of class as well. Yes, objects still exist as well and I still don't really understand why Borland didn't revive them instead of adding methods to records... Nevertheless objects are between records and classes: they can also be located on the stack (and be initialized as a constant) like records, yet they support (if you need it) inheritance and virtual methods. They can't implement interfaces though and there is no base object type (similar to TObject). Also they don't support RTTI (though I might change this with the extended RTTI). All three types, records, objects and classes have their purposes and uses and one can select the one that is most fitting in a given situation. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] global operator overloading
Hi Sven, My code below: === program project1; {$mode objfpc}{$H+} {$MODESWITCH advancedrecords} uses Classes; type TMyStringList = record StringList: TStringList; class operator (s1, s2: TMyStringList): Boolean; end; class operator TMyStringList.(s1, s2: TMyStringList): Boolean; begin Result := s1.StringList.Count s2.StringList.Count; end; begin end. === generated these errors: project1.lpr(9,20) Error: It is not possible to overload this operator. Related overloadable operators (if any) are: project1.lpr(9,21) Error: It is not possible to overload this operator. Related overloadable operators (if any) are: project1.lpr(9,53) Error: Impossible operator overload project1.lpr(12,31) Error: method identifier expected project1.lpr(1,1) Fatal: Compilation aborted I am using Lazarus 1.0.6/FPC2.6.0-6 on Linux Mint 14/x86_64. Sincerely, Shannon 2013/2/26 Sven Barth pascaldra...@googlemail.com On 26.02.2013 09:36, Xiangrong Fang wrote: Hi Sven, Could you please give a simple example that shows what you said: require that the type with which you specialize is a record. Then a class operator in that record can be defined. Let's suppose you have the following generic declaration: === example begin === type generic TTreapT1, T2 = class // let's assume T1 requires end; === example end === If you use a record to specialize TTreap's T1 parameter then you can do it the following way: === example begin === type TMyRecord = record // note: in mode objfpc the modeswitch advancedrecords is needed class operator (aLeft, aRight: TMyRecord): Boolean; end; // implementation: class operator TMyRecord.(aLeft, aRight: TMyRecord): Boolean; begin // compare aLeft and aRight end; // somewhere else TTreapTMyRecordLongInt = specialize TTreapTMyRecord, LongInt; === example end === Now the generic will specialize without problem. If you want to specialize other types that don't support class operators then you need to wrap them inside a record, e.g.: === example begin === type TRecTStringList = record MyStringList: TStringList; class operator (aLeft, aRight: TRecTStringList): Boolean; end; === example end === You can also use visibility modifiers like private or strict private to hide the MyStringList field and make it accessible only through properties. To simplyfy usage you can also define assignment operators. E.g.: === example begin === type // maybe it will also work with a TStringList if you use TStrings instead... TRecTStringList = record private fStringList: TStringList; public class operator := (aRight: TStringList): TRecTStringList; class operator := (aRight: TRecStringList): TStringList; end; class operator TRecTStringList.:=(aRight: TStringList): TRecTStringList; begin Result.fStringList := aRight; end; class operator TRecTStringList.:=(aRight: TRecStringList): TStringList; begin Result := aRight.fStringList; end; // somewhere else: var sl: TStringList; rec: TRecStringList; begin // setup sl rec := sl; // use rec in the tree sl := rec; end; === example end === It's not the nicest solution, but currently the only thing you can do. Regards, Sven -- __**_ Lazarus mailing list Lazarus@lists.lazarus.**freepascal.orgLazarus@lists.lazarus.freepascal.org http://lists.lazarus.**freepascal.org/mailman/**listinfo/lazarushttp://lists.lazarus.freepascal.org/mailman/listinfo/lazarus -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] global operator overloading
On 26.02.2013 15:30, Xiangrong Fang wrote: Hi Sven, My code below: === program project1; {$mode objfpc}{$H+} {$MODESWITCH advancedrecords} uses Classes; type TMyStringList = record StringList: TStringList; class operator (s1, s2: TMyStringList): Boolean; end; class operator TMyStringList.(s1, s2: TMyStringList): Boolean; begin Result := s1.StringList.Count s2.StringList.Count; end; begin end. === generated these errors: project1.lpr(9,20) Error: It is not possible to overload this operator. Related overloadable operators (if any) are: project1.lpr(9,21) Error: It is not possible to overload this operator. Related overloadable operators (if any) are: project1.lpr(9,53) Error: Impossible operator overload project1.lpr(12,31) Error: method identifier expected project1.lpr(1,1) Fatal: Compilation aborted I am using Lazarus 1.0.6/FPC2.6.0-6 on Linux Mint 14/x86_64. Hmm... 2.6.0 seems to indeed have problems there. I did not test 2.6.2 (I don't have it installed yet), but 2.7.1 works without problems. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] global operator overloading
On 26.02.2013 15:30, Xiangrong Fang wrote: Hi Sven, My code below: === program project1; {$mode objfpc}{$H+} {$MODESWITCH advancedrecords} uses Classes; type TMyStringList = record StringList: TStringList; class operator (s1, s2: TMyStringList): Boolean; end; class operator TMyStringList.(s1, s2: TMyStringList): Boolean; begin Result := s1.StringList.Count s2.StringList.Count; end; begin end. === generated these errors: project1.lpr(9,20) Error: It is not possible to overload this operator. Related overloadable operators (if any) are: project1.lpr(9,21) Error: It is not possible to overload this operator. Related overloadable operators (if any) are: project1.lpr(9,53) Error: Impossible operator overload project1.lpr(12,31) Error: method identifier expected project1.lpr(1,1) Fatal: Compilation aborted I am using Lazarus 1.0.6/FPC2.6.0-6 on Linux Mint 14/x86_64. In addition to my previous mail: It will work in 2.6.0 if you compile in mode delphi (no $H+ and $modeswitch needed there) and you need to rename the operator from to LessThan (this is the Delphi operator name). Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] global operator overloading
Then, I wish to see 2.8 released :-D thanks. 2013/2/26 Sven Barth pascaldra...@googlemail.com On 26.02.2013 15:30, Xiangrong Fang wrote: Hi Sven, My code below: ==**= program project1; {$mode objfpc}{$H+} {$MODESWITCH advancedrecords} uses Classes; type TMyStringList = record StringList: TStringList; class operator (s1, s2: TMyStringList): Boolean; end; class operator TMyStringList.(s1, s2: TMyStringList): Boolean; begin Result := s1.StringList.Count s2.StringList.Count; end; begin end. ==**= generated these errors: project1.lpr(9,20) Error: It is not possible to overload this operator. Related overloadable operators (if any) are: project1.lpr(9,21) Error: It is not possible to overload this operator. Related overloadable operators (if any) are: project1.lpr(9,53) Error: Impossible operator overload project1.lpr(12,31) Error: method identifier expected project1.lpr(1,1) Fatal: Compilation aborted I am using Lazarus 1.0.6/FPC2.6.0-6 on Linux Mint 14/x86_64. Hmm... 2.6.0 seems to indeed have problems there. I did not test 2.6.2 (I don't have it installed yet), but 2.7.1 works without problems. Regards, Sven -- __**_ Lazarus mailing list Lazarus@lists.lazarus.**freepascal.orgLazarus@lists.lazarus.freepascal.org http://lists.lazarus.**freepascal.org/mailman/**listinfo/lazarushttp://lists.lazarus.freepascal.org/mailman/listinfo/lazarus -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] global operator overloading
On 26.02.2013 15:37, Xiangrong Fang wrote: Then, I wish to see 2.8 released :-D I don't, because I still have so many things I want to implement before that :P Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TOpenGLControl: multisampling not working (Linux/GLX)
On Tue, 26 Feb 2013 06:17:04 +0100 Michalis Kamburelis michalis.ka...@gmail.com wrote: What is weirder is that I can get multi-sampling on both these systems (both Radeon and NVidia) with a very similar multi-sampling code inside my Castle Game Engine TCastleWindow class (that directly uses GTK and GTKGlExt, without Lazarus TOpenGLControl, to create window with OpenGL context) GTKGLExt may be the thing making it work. I don't have enough details but searching around the net showed that GTKGLArea does not support multisampling. AFAIR TOpenGLControls code is based on this. The lazarus forum post I linked to in another mail showed multisampling did work for the OpenGL examples that come with FPC. Multisampling does work with GTKGLExt as your engine shows. So I still think it is a problem with GDK but that is just a gut feeling. Perhaps TOpenGLControl can be rewritten to use GTKGLExt following your code if your license permits it. It's a shame that the GTK guys did not get their act together and don't offer a standard way of context creation like virtually every other widgetset does since years. R. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Forward declare (modern) records [was: Re: global operator overloading]
All three types, records, objects and classes have their purposes and uses and one can select the one that is most fitting in a given situation. Is it possible to forward declare records the way we can with classes? I mean, with classes, I can do this: TSecondClass = class; TFirstClass = Class(TObject) private FSecondClass: TSecondClass; public end; TSecondClass = Class(TObject) private FFirstClass: TFirstClass; public end; but, I don't seem to be able to do the same with records --I am referring to the new/modern records. I can see why it isn't immediately available, but it would be so much nicer if fpc handled the pointer stuff in the background. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Forward declare (modern) records [was: Re: global operator overloading]
On 26.02.2013 16:15, ListMember wrote: All three types, records, objects and classes have their purposes and uses and one can select the one that is most fitting in a given situation. Is it possible to forward declare records the way we can with classes? I mean, with classes, I can do this: TSecondClass = class; TFirstClass = Class(TObject) private FSecondClass: TSecondClass; public end; TSecondClass = Class(TObject) private FFirstClass: TFirstClass; public end; but, I don't seem to be able to do the same with records --I am referring to the new/modern records. I can see why it isn't immediately available, but it would be so much nicer if fpc handled the pointer stuff in the background. It would be no use anyway. You CAN NOT have the record used as a field inside itself, so you'd need to define a pointer type anyway. And this is something where we won't do things behind the programmers back. If you need a pointer then you declare one. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Configuration not quite right
Dňa 25.02.2013 20:40, Leslie Turriff wrote / napísal(a): Hi, I'm just starting out with Free Pascal and Lazarus, and I need a bit of help. I've installed them in my OpenSuSE 12.2 system running on x86_64 hardware, using the version in the distribution repository (which I presumed would be properly configured). Lazarus is v1.0.4 and Free Pascal is version 2.6.0 [2012/10/17] for x86_64. The first time I opened Lazarus it populated with a predefined sample program (how do I turn that off?). I made a few cosmetic changes to the source code (blank lines added or removed) to be sure Lazarus saw differences, then pressed the Run button. The messages window reported 'Project Project1 successfully built', then an error message window popped up, saying 'No program file /tmp/project1 found.' I looked through Tools=Options, looking for a mis-set path, but so far I can't see anything helpful. Any suggestions? Leslie -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus I think /tmp/project1 does need superuser rights. You do need to change path to ~/tmp/project1 or to run lazarus as a superuser. Milan -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Configuration not quite right
On Tue, 26 Feb 2013 16:21:30 +0100 Milan Baša min...@mail.t-com.sk wrote: Dňa 25.02.2013 20:40, Leslie Turriff wrote / napísal(a): Hi, I'm just starting out with Free Pascal and Lazarus, and I need a bit of help. I've installed them in my OpenSuSE 12.2 system running on x86_64 hardware, using the version in the distribution repository (which I presumed would be properly configured). Lazarus is v1.0.4 and Free Pascal is version 2.6.0 [2012/10/17] for x86_64. The first time I opened Lazarus it populated with a predefined sample program (how do I turn that off?). I made a few cosmetic changes to the source code (blank lines added or removed) to be sure Lazarus saw differences, then pressed the Run button. The messages window reported 'Project Project1 successfully built', then an error message window popped up, saying 'No program file /tmp/project1 found.' I looked through Tools=Options, looking for a mis-set path, but so far I can't see anything helpful. Any suggestions? I think /tmp/project1 does need superuser rights. Under OpenSuSE /tmp is writable for users. You do need to change path to ~/tmp/project1 Yes, that is an alternative. You have to create the directory. or to run lazarus as a superuser. Bad idea. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Forward declare (modern) records [was: Re: global operator overloading]
On 2013-02-26 17:18, Sven Barth wrote: On 26.02.2013 16:15, ListMember wrote: All three types, records, objects and classes have their purposes and uses and one can select the one that is most fitting in a given situation. Is it possible to forward declare records the way we can with classes? I mean, with classes, I can do this: TSecondClass = class; TFirstClass = Class(TObject) private FSecondClass: TSecondClass; public end; TSecondClass = Class(TObject) private FFirstClass: TFirstClass; public end; but, I don't seem to be able to do the same with records --I am referring to the new/modern records. I can see why it isn't immediately available, but it would be so much nicer if fpc handled the pointer stuff in the background. It would be no use anyway. You CAN NOT have the record used as a field inside itself, so you'd need to define a pointer type anyway. And this is something where we won't do things behind the programmers back. If you need a pointer then you declare one. Well.. yes and no. Here is my use-case: I am working (on and off) on string classes. I have basically 3 string types: TByteString, TWordString, TCardinalString string each representing a different char/codepage width/bytesize. And, I'd like to have the user-facing interface to be somethig like this: TByteString = record {...} public property AsWordString: TWordString read GetWordString write SetWordString; property AsCardinalString: TCardinalString read GetCardinalString write SetCardinalString; end; TWordString = record {...} public property AsByteString: TByteString read GetByteString write SetByteString; property AsCardinalString: TCardinalString read GetCardinalString write SetCardinalString; end; TCardinalString = record {...} public property AsByteString: TByteString read GetByteString write SetByteString; property AsWordString: TWordString read GetWordString write SetWordString; end; Having these properties would be very useful; but if I have to use pointers, then I believe it would force almost all the rest of the calling code to be based on pointers --defeating the purpose of simplicity for the user. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TOpenGLControl: multisampling not working (Linux/GLX)
On Tue, 26 Feb 2013 15:51:52 +0100 Reimar Grabowski reimg...@web.de wrote: On Tue, 26 Feb 2013 06:17:04 +0100 Michalis Kamburelis michalis.ka...@gmail.com wrote: What is weirder is that I can get multi-sampling on both these systems (both Radeon and NVidia) with a very similar multi-sampling code inside my Castle Game Engine TCastleWindow class (that directly uses GTK and GTKGlExt, without Lazarus TOpenGLControl, to create window with OpenGL context) GTKGLExt may be the thing making it work. A quick look at the gtkglext-1.2.0 sources didn't reveal anything special about multisampling. The first noticeable thing of gtkglext code is the special color map. I don't have enough details but searching around the net showed that GTKGLArea does not support multisampling. AFAIR TOpenGLControls code is based on this. Yes. The lazarus forum post I linked to in another mail showed multisampling did work for the OpenGL examples that come with FPC. Multisampling does work with GTKGLExt as your engine shows. So I still think it is a problem with GDK but that is just a gut feeling. The GLGtkGlxContext only uses the gdk function gdk_colormap_new. And it let the gtk create the XWindow. It seems gtkglext does not create the XWindow too. Perhaps TOpenGLControl can be rewritten to use GTKGLExt following your code if your license permits it. It's a shame that the GTK guys did not get their act together and don't offer a standard way of context creation like virtually every other widgetset does since years. Indeed. And the last release of gtkglext is 1.2.0 from 2006. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Forward declare (modern) records [was: Re: global operator overloading]
Am 2013-02-26 16:15, schrieb ListMember: Is it possible to forward declare records the way we can with classes? Well, I know that you can do something like this: PTreeType= ^TreeType; TreeType = record ...; ...; Dirs : PListType; end; { of record } You can see that TreeType is used in the first line although it is not (yet) defined. As long as you declare the type within the same Type section the compiler swallows it. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Forward declare (modern) records [was: Re: global operator overloading]
On 26.02.2013 18:22, Jürgen Hestermann wrote: Am 2013-02-26 16:15, schrieb ListMember: Is it possible to forward declare records the way we can with classes? Well, I know that you can do something like this: PTreeType= ^TreeType; TreeType = record ...; ...; Dirs : PListType; end; { of record } You can see that TreeType is used in the first line although it is not (yet) defined. As long as you declare the type within the same Type section the compiler swallows it. He wants to have this supported: === example begin === type SomeType1 = record; SomeType2 = record; SomeType1 = record // ... property SomeProperty: SomeType2 read ... write ... end; SomeType2 = record // ... property SomeProperty: SomeType1 read ... write ... end; === example end === Just in case you aren't up to date with FPC's supported language, Jurgen, the following works in FPC out of Delphi compatibility since 2.6.0 (though it needs {$modeswitch advancedrecords} in non-Delphi modes): === example begin === type SomeType = record // ... property SomeProperty: SomeType read ... write ... end; === example end === What still doesn't work (and will never work [and doesn't work in Delphi either :P ]) is this: === example begin === type SomeType = record SomeField: SomeType; end; === example end === Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TOpenGLControl: multisampling not working (Linux/GLX)
On Tue, 26 Feb 2013 16:53:25 +0100 Mattias Gaertner nc-gaert...@netcologne.de wrote: A quick look at the gtkglext-1.2.0 sources didn't reveal anything special about multisampling. It is very possible that no 'special' support is needed. The first noticeable thing of gtkglext code is the special color map. This could be the difference as multisampling in GLX is handled the same as for example alpha bits or color bits. And the last release of gtkglext is 1.2.0 from 2006. It is not part of GTK and OpenGL context creation never was unlike for example QT where the OpenGL widget is a first class citizen. AFAIR GLX 1.3 was released around 1998. R. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] ValueListEditor: feedback needed from Delphi users
On Tue, Feb 26, 2013 at 8:03 PM, Bart bartjun...@gmail.com wrote: Please only provide answer obtained by black box testing. Just build a Delpi app and see how it functions. Do NOT, I repeat do NOT, look at the Delphi source code. Our implementation needs to be clean. Just commenting on this black box testing: It is OK for somebody else to look at Delphi source and then answer your questions based on that code. Only copying or otherwise duplicating the Delphi source is not OK. However, these features are easy to test without looking at the source. If you don't get other answers, I can check with Delphi later. Now I have other things. I believe most list members have at least Delphi 7 which is enough for testing ValueListEditor. Regards, Juha -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Configuration not quite right
On Tuesday 26 February 2013 09:35:00 Mattias Gaertner wrote: On Tue, 26 Feb 2013 16:21:30 +0100 Milan Baša min...@mail.t-com.sk wrote: Dňa 25.02.2013 20:40, Leslie Turriff wrote / napísal(a): Hi, Any suggestions? I think /tmp/project1 does need superuser rights. Under OpenSuSE /tmp is writable for users. You do need to change path to ~/tmp/project1 Yes, that is an alternative. You have to create the directory. And then, how do I tell Lazarus to use ~/tmp instead of /tmp ? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TOpenGLControl: multisampling not working (Linux/GLX)
On Tue, 26 Feb 2013 19:10:53 +0100 Reimar Grabowski reimg...@web.de wrote: On Tue, 26 Feb 2013 16:53:25 +0100 Mattias Gaertner nc-gaert...@netcologne.de wrote: A quick look at the gtkglext-1.2.0 sources didn't reveal anything special about multisampling. It is very possible that no 'special' support is needed. The first noticeable thing of gtkglext code is the special color map. This could be the difference as multisampling in GLX is handled the same as for example alpha bits or color bits. The color map functions are in gdk/x11/gdkglconfig-x11.c. The C looks simple, but I guess it needs some time to understand all the X calls and flags. And the last release of gtkglext is 1.2.0 from 2006. It is not part of GTK and OpenGL context creation never was unlike for example QT where the OpenGL widget is a first class citizen. There is still no opengl widget for LCL QT. AFAIK it requires a QT expert. AFAIR GLX 1.3 was released around 1998. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Configuration not quite right
On Tue, 26 Feb 2013 12:33:54 -0600 Leslie Turriff jlturr...@centurytel.net wrote: On Tuesday 26 February 2013 09:35:00 Mattias Gaertner wrote: On Tue, 26 Feb 2013 16:21:30 +0100 Milan Baša min...@mail.t-com.sk wrote: Dňa 25.02.2013 20:40, Leslie Turriff wrote / napísal(a): Hi, Any suggestions? I think /tmp/project1 does need superuser rights. Under OpenSuSE /tmp is writable for users. You do need to change path to ~/tmp/project1 Yes, that is an alternative. You have to create the directory. And then, how do I tell Lazarus to use ~/tmp instead of /tmp ? Tools / Options / Environment / Files / Directory for building test projects. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TOpenGLControl: multisampling not working (Linux/GLX)
On Tuesday 26 of February 2013 19:42:32 Mattias Gaertner wrote: There is still no opengl widget for LCL QT. AFAIK it requires a QT expert. Only bindings are missing. zeljko -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] DataSource State not always current
In Delphi 3.02 this ALWAYS works, but only sometimes with Laz 1.0.6 for Win7 64bit w/ADS database: with DBNavigator1.DataSource do if State in [dsEdit, dsInsert] then This can be fixed in Laz by adding a variable to the var section like so: myState : TDataSetState; And replacing the above with the following 2 lines: myState:=DBNavigator1.DataSource.State; with DBNavigator1.DataSource do if myState in [dsEdit, dsInsert] then A. G.-- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TOpenGLControl: multisampling not working (Linux/GLX)
On Tuesday, February 26, 2013 08:07:16 PM zeljko wrote: Only bindings are missing. it is a lot of work :-) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Patch question.
Hi All! I have finished the code needed to use xml to specify templates for some of the code completion functions. I was about to create a patch till I remembered that the xml file is in ~/.lazarus. AFAICT this will not go into the patch, but should be put into .lazarus on install or build. What is the proper way of doing this? Thanks, Don Z. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Patch question.
On Tue, 26 Feb 2013 17:05:59 -0500 Donald Ziesig don...@ziesig.org wrote: Hi All! I have finished the code needed to use xml to specify templates for some of the code completion functions. I was about to create a patch till I remembered that the xml file is in ~/.lazarus. AFAICT this will not go into the patch, but should be put into .lazarus on install or build. What is the proper way of doing this? Check on start if the config file exists. If yes, load it, if not, create defaults, e.g. copy a file from the lazarus directory. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Forward declare (modern) records [was: Re: global operator overloading]
Sven Barth schrieb: He wants to have this supported: === example begin === type SomeType1 = record; SomeType2 = record; SomeType1 = record // ... property SomeProperty: SomeType2 read ... write ... end; SomeType2 = record // ... property SomeProperty: SomeType1 read ... write ... end; === example end === In the meantime I understand why such a construct *is* useful, in detail with records. The *caller* provides the memory for the result, returned by an property getter, and is responsible for releasing it. Not so with pointers, for which memory may have to be allocated, but there is no obligation to release that memory (no owner)! DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Patch question.
On 02/26/2013 05:17 PM, Mattias Gaertner wrote: On Tue, 26 Feb 2013 17:05:59 -0500 Donald Ziesig don...@ziesig.org wrote: Hi All! I have finished the code needed to use xml to specify templates for some of the code completion functions. I was about to create a patch till I remembered that the xml file is in ~/.lazarus. AFAICT this will not go into the patch, but should be put into .lazarus on install or build. What is the proper way of doing this? Check on start if the config file exists. If yes, load it, if not, create defaults, e.g. copy a file from the lazarus directory. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus Got it! -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TOpenGLControl: multisampling not working (Linux/GLX)
On Tuesday, February 26, 2013 09:29:04 PM Den Jean wrote: it is a lot of work This is very alpha and after lots of hacks to get this far. FPC Qt4 OpenGL: http://users.telenet.be/Jan.Van.hijfte/qtforfpc/V2.6RC2/splitbuild-qt4pas-V2.6RC2_Qt4.8.4.tar.gz $ grep qgl -i qt4.pas | wc -l 545 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] CRM and MVC
Hi all, i am interested on Lazarus. I want to know if there are ORMs for it? Which is the better in your opinion. Other question is if there are MVC or MVP frameworks for Lazarus. Any answer will be apreciated .. Sorry for my english. TIA Ing. Pablo Digonzelli Sofware Solutions IP Soluciones SRL 25 de Mayo 521. Entrepiso A email: pdigonze...@softsargentina.com email: pdigonze...@gmail.com twitter: @pdigonzelli Tel: 0381 4227378 Cel: 0381 155982714 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] TDD
Hi , another question . Wich are TDD frameworks for Lazarus? TIA Ing. Pablo Digonzelli Sofware Solutions IP Soluciones SRL 25 de Mayo 521. Entrepiso A email: pdigonze...@softsargentina.com email: pdigonze...@gmail.com twitter: @pdigonzelli Tel: 0381 4227378 Cel: 0381 155982714 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Recent Problem with program compile
This process is called my a linux service. Required Packages only list as LCLBase and LazUtils. When I remove LCLBase the project compiles. However, if I follow the wiki suggestions I compile just fine but the program terminates abnormally when launched as a process from the LazDaemon. Error: Compiling resource /Developer/Source/Builds/Aurawin/SCS/Linux/64/.Output/AuProcess.or Linking AuProcess /usr/bin/ld: warning: link.res contains output sections; did you forget -T? /Developer/Lazarus/lcl/units/x86_64-linux/wsimglist.o: In function `REGISTERCUSTOMIMAGELIST': Did something recently changed with Lazarus from SVN/trunk to AUTOMATICALLY include LCLBase? AFAIK the package LCLBase was added inadvertently. And a previous revision of my project shows it is not there. Just a heads up. -- Andrew Brunner Aurawin LLC 15843 Garrison Circle Austin, TX 78717 https://aurawin.com Aurawin is a great new way to store, share, and explore all your content featuring our innovative cloud social computing platform. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TDD
2013/2/27 Pablo R. Digonzelli pdigonze...@softsargentina.com: Hi , another question . Wich are TDD frameworks for Lazarus? http://wiki.lazarus.freepascal.org/fpcunit There are others too. Vincent -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] default visibility for class members
Hi All, My class looks like this: TMyClass = class FField1: Integer; private FField2: string; public FField3: string; end; Question is, is FField1 private or public or protected? For all lcl classes, I see a lot of fields above private, it looks like they are same as public, because I can access them from outside. But why allow them to be put there instead of directly under public? Thanks, Shannon -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus