Re: [Lazarus] Log4D weirdness
On Thu, Jan 1, 2015 at 2:39 PM, Marco van de Voort mar...@stack.nl wrote: On Thu, Jan 01, 2015 at 01:04:22AM -0200, Marcos Douglas wrote: This is totally new for me. I have used interfaces a lot, and while I had trouble from time to time, I haven't really encountered these. New? What do you mean? This problem was talked in FPC list and here before. I use weak reference. Somethings are not possible to implement without this technique. For example: https://github.com/mdbs99/AWS/blob/master/src/aws_s3.pas#L166 https://github.com/mdbs99/AWS/blob/master/src/aws_s3.pas#L304 These objects have circular reference and they need weak reference to keep memory safe. Ah, you mean that. I didn't consider that an interface problem, since the ref is in an object. (whose aren't refcounted). IOW by design :-) If I understood right, you mean it only uses interfaces but not refcount? eachother. The major implementations are somewhat hardened against it, but more involved reference counting implementations (like Python) are too. I know some others approaches have problems, but Delphi/FPC is not perfect too. Certainly. It doesn't even try, and as soon as you try to overuse it, it breaks down. It is IMHO a designchoice and not a flaw though. Delphi/FPC reference counting is simple and cheap. The problem is IMHO not the implementation, but the fact that people try to abuse it for things it wasn't meant for (a holistic automatic memory management solution). I agree. Then why do you write such code ? :-) I didn't understand. What code, AWS Lib? If yes, well I wrote such code because I know the workarounds to limit such problems with interfaces, refcount and circular reference. But is not easy, memleaks could happen. Unit tests and -gh argument have helping a lot. ARC is IMHO no solution but only damage control (by explicitely naming pure references). IIRC Python has similar tricks to keep circular detections cheap (cycle checking can stop at a weak reference) Happy New year! Happy New Year. May 3.0 be all that we hope it will be. WOW! I can not wait for it! Marcos Douglas -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Alternative component palette layout
First of all: HAPPY NEW YEAR! ComponentsListView should be read only. Please apply attached patch if OK. Sandro On 31 December 2014 at 18:46, Sandro Cumerlato sandro.cumerl...@gmail.com wrote: Hello Juha, I've implemented (auto) resize of Components list columns. Please review attached patch and apply if OK. Sandro On 28 December 2014 at 21:11, Juha Manninen juha.mannine...@gmail.com wrote: On Sun, Dec 28, 2014 at 1:08 PM, zeljko zel...@holobit.net wrote: I'm against such workarounds since it can hide bug. Is it enough to comment code LCLQt to completely disable LCLQt ifdef ? I'll try to debug and see what exactly happens, since it's impossible to reproduce it with simple example project. I already thought I spotted the error and I almost opened a bug report. Unneeded pages are deleted like : Application.ReleaseComponent(Sheet); I could reproduce the error in a small test project and then fix it using : TabControl := TCustomTabControl(PageControl1); TabControl.Pages.Delete(0); But ... I tried to use it in the component palette code and it didn't work. I am puzzled and will not touch this issue for a while. TPageControl API sucks badly. TPageControl inherits from TCustomTabControl. They both have Pages but with different meaning. There is Pages[] and Page[]. I think it should be fixed even if it breaks Delphi compatibility. Anyway, the palette reordering works pretty much perfectly now! Giuliano made a workaround for the QT issue and I fixed a last remaining bug related to saving the configuration. Please everybody test and create alternative palette layouts. Juha -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus Index: ide/frames/componentpalette_options.lfm === --- ide/frames/componentpalette_options.lfm (revisione 47275) +++ ide/frames/componentpalette_options.lfm (copia locale) @@ -235,6 +235,7 @@ 54657374436F6D70080054657374506167650B00546573745061636B 616765 } + ReadOnly = True RowSelect = True ScrollBars = ssAutoBoth TabOrder = 0 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Log4D weirdness
On Thu, Jan 01, 2015 at 01:04:22AM -0200, Marcos Douglas wrote: This is totally new for me. I have used interfaces a lot, and while I had trouble from time to time, I haven't really encountered these. New? What do you mean? This problem was talked in FPC list and here before. I use weak reference. Somethings are not possible to implement without this technique. For example: https://github.com/mdbs99/AWS/blob/master/src/aws_s3.pas#L166 https://github.com/mdbs99/AWS/blob/master/src/aws_s3.pas#L304 These objects have circular reference and they need weak reference to keep memory safe. Ah, you mean that. I didn't consider that an interface problem, since the ref is in an object. (whose aren't refcounted). IOW by design :-) eachother. The major implementations are somewhat hardened against it, but more involved reference counting implementations (like Python) are too. I know some others approaches have problems, but Delphi/FPC is not perfect too. Certainly. It doesn't even try, and as soon as you try to overuse it, it breaks down. It is IMHO a designchoice and not a flaw though. Delphi/FPC reference counting is simple and cheap. The problem is IMHO not the implementation, but the fact that people try to abuse it for things it wasn't meant for (a holistic automatic memory management solution). I agree. Then why do you write such code ? :-) ARC is IMHO no solution but only damage control (by explicitely naming pure references). IIRC Python has similar tricks to keep circular detections cheap (cycle checking can stop at a weak reference) Happy New year! Happy New Year. May 3.0 be all that we hope it will be. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Alternative component palette layout
On Thu, 1 Jan 2015 10:49:56 +0100 Sandro Cumerlato sandro.cumerl...@gmail.com wrote: First of all: HAPPY NEW YEAR! ComponentsListView should be read only. Please apply attached patch if OK. Thanks. Applied. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TListView - column alignment doesn't work when OwnerData
On 12/31/2014 08:53 PM, Krzysztof wrote: Hi, I have column alignment taRightJustify. When using as normal listview then everything is ok but with OwnerData, data is always taLeftJustify (but column title is ok). Is it a bug or need I set some extra property? Open an issue about it and attach example project. zeljko -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Log4D weirdness
Am 31.12.2014 um 21:51 schrieb Marco van de Voort: Afaik the problem is that const as used in classic delphi is not very portable. In theory it is specified as immutable (can't be modified), but widely abused to mean by reference. Const parameters exist for optimization, the compiler is allowed to pass them by reference instead of a copy. This happens to be the case for x86 ABIs, but this is not portable (which why FPC introduced constref) I don't see how this is not portable - as long as the procedure is OPL. External procedures of other languages don't leave room for such an optimization, even in x86 ABIs, that's why constref was introduced for them. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
