[fpc-pascal] [PATCH] Re: Imagemagick: magickwand doesn't convert to TIFF 1 bit
On 15/09/2014 09:43, Reinier Olislagers wrote: > Mantis issue > http://mantis.freepascal.org/view.php?id=26723 Test case and patch attached to bugtracker issue. Thanks, Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] with statement using mulltiple objects
On 13 September 2014 20:29, vfclists . wrote: > > > On 13 September 2014 20:02, Sven Barth > wrote: > >> On 13.09.2014 20:13, vfclists . wrote: >> >>> According to the docs the with statement when used with mulltiple >>> objects only works with the last parameter. >>> >>> >>> The statement >>> >>> With A,B,C,D do Statement; >>> >>> is equivalent to >>> >>> With A do >>> With B do >>>With C do >>> With D do Statement; >>> >>> -- >>> >>> I thought that if all the objects have the property the statement would >>> apply to them eg. >>> >>> >>> with Label1, Label2, Label3 do >>>Caption = 'Text'. >>> >>> I thought all the 3 labels would have the caption set, but only Label3's >>> caption is set. Is this a difference between Delphi's Object Pascal and >>> FreePascal, or has Delphi's Object Pascal always worked in the same >>> manner? >>> >> >> It has always worked in this manner. It's just for abbreviating typing, >> not for combining properties. (and then the with-variant with multiple >> elements is even more seldomly used than the single-element one...) >> >> Regards, >> Sven >> ___ >> fpc-pascal maillist - fpc-pascal@lists.freepascal.org >> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal >> > > What then is the nesting for if the command will only apply to the last > item with the property? Is each nested element supposed to be a property of > the enclosing element? > > What is the rationale for such a statement, ie using multliple elements? > > -- > Frank Church > > === > http://devblog.brahmancreations.com > This is a fragment I was using with multiple elements. So it means that all this time it was only working because all of them had been set at design time and the command was only applied to the last one. I wonder where I got the impression that because they all shared the property the command applied to all of them. with qrySCParameters, qrySavedCommands, qryTemplateParameters, qryLiveCommands, qryLCParameters do begin Connection := dmCentral.localCommandsConnection; end; dmCentral.localCommandsConnection.Connected := True; I am happy with the use of 'with' on a single element, but using it with multiple elements is plainly evil. -- Frank Church === http://devblog.brahmancreations.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] console gdb in mac
On 08/09/14 17:34, Joost van der Sluis wrote: > On 09/07/2014 05:19 PM, Felipe Monteiro de Carvalho wrote: >> How can I read the value of field FParent which is located in object >> "Self" ? > > That's not that difficult: > > p this > p this.fparent You can also use "self". You don't even have to add self/this explicitly, and just use "p fparent". Additionally, to print all fields of a class instance, you have to use "p self^", as class instances are pointers. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] with statement using mulltiple objects
On Sun, Sep 14, 2014 at 02:30:01PM +0200, Marco van de Voort wrote:
In our previous episode, J?rgen Hestermann said:
> -
> d:=TreeRoot.SubDirs[Low(TreeRoot.SubDirs)]; // local var d
> d^.DirLogged := true;
> d^.DirHatFocus := false;
> d^.SubDirsExpanded := true;
> [...] -
Long-winded and still not the same clarity as in the with statement.
But the important part is that it forces each property/field to be a member
of T, or get a compiler error.
WITH doesn't, and you risk that if your class or one of its ancestor has
such property, and your error goes unnoticed.
I have to believe the WITH statement is more efficient
than the C language equivalent where an extra
convenience pointer is declared as a variable and
allocated. The WITH statement allows the compiler to
generate the same code as a fully qualified variable name
without extra overhead in the form of a dummy pointer.
Just as the GOTO statement needs to be used with careful,
close locality of scope, the WITH statement should be used
when the fields will all come from the same record
definition and ideally have distinct names. The safe
approach would be to qualify all field references that are
potentially ambiguous even while using a WITH statement.
The danger of surprises in scope evaluation for a simple
and short variable name within a WITH statement scope are
not that different from the danger of unit global
variables. Each unit creates its own local name space,
which usually does the programmer a favor, but not always.
Now the order units are referenced in the USES statement
of each individual unit matters. What do you think
happens when the programmer is casual about the USES order
for helper utility units with duplicate global variable
names?
Unit FooUtil1;
var ErrorString : string;
Unit BarUtil2
var ErrorString : string;
Unit CodeSection;
uses FooUtil1, BarUtil1;
procedure Main
begin
ErrorString := ''; {Clears error string in last unit}
.
.
end;
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] with statement using mulltiple objects
Am 15.09.2014 09:08 schrieb "Graeme Geldenhuys" < mailingli...@geldenhuys.co.uk>: > > On 2014-09-14 13:30, Marco van de Voort wrote: > > WITH doesn't, and you risk that if your class or one of its ancestor has > > such property, and your error goes unnoticed. > > +1 > > Not to mention that you can't use tooltip debugging when it comes to the > WITH statement - at least this was the case last time I tried (I don't > use WITH, so it could have been a long time ago). With Lazarus this works, which is what I meant in my other mail ;) In Delphi this AFAIK still does not work... (at least it did not in Delphi 2007) Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] with statement using mulltiple objects
Bernd Oppolzer wrote: PL/1 was designed in the mid 60s, and Wirth of course knew about PL/1, because he was at IBM at the time, and of course he was aware of the problems and pitfalls of PL/1. I didn't know that Wirth had been directly associated with IBM. I did know that while at Stanford he'd supervised Larry Breed who was writing the first fairly-complete computerised APL implementation, but my recollection is that they used FORTRAN since it was the only language that ran on the various computers that the involved parties had available. http://infolab.stanford.edu/TR/CS-TR-66-47.html -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Optimal number of threads for SMP
In our previous episode, Xiangrong Fang said: > If my application needs SPEED, i.e. take full advantage of CPU > capabilities, and the application has no I/O operation at all (neither disk > nor network), it seems no need to create threads more than the number of > CPU cores ?hyper-threads)? > > Am I right? My rule of thumb is physical cores + a percentage. (like 10-20%). The idea is to saturate the CPU, but only just so, since saturating by way too many threads increasing switching time and thus decreases performance. The percentage is a rule of thumb approach to account for some minor I/O (if only OS background), scheduler/locks switch time, and, possibly hyperthreading. But in my apps I always make it configurable, and use this sum only to seed the default of the configuration setting. This because you don't always want to fully utilize the computer (e.g. to give some air to background services, or because you are working on it), and because automatic detection regularly goes wrong with new CPUs etc. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Optimal number of threads for SMP
Hi All, If my application needs SPEED, i.e. take full advantage of CPU capabilities, and the application has no I/O operation at all (neither disk nor network), it seems no need to create threads more than the number of CPU cores （hyper-threads)? Am I right? Xiangrong ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] return 8 byte of return as function result via register
On 09/13/2014 12:59 AM, Dennis Poon wrote: I am trying to use an external C++ dll Usually you can't use (pure) C++ DLLs. DLLS need to have a "flat" (ANSI C) interface using standard data types and calling conventions. I suppose with x86/64 the return value in fact is 8 bytes in a single register. AFAIK, with X86/32 there is no single register with 8 bytes. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] with statement using mulltiple objects
Graeme Geldenhuys wrote: As already mentioned, human refactoring of WITH statements can, and has, caused lots of debugging issues afterwards. If Dijkstra had written a letter to the CACM cautioning against the With statement, I wonder whether Wirth would have headlined it "With Statement Considered Harmful"? [Ref: EWD-1308] -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Imagemagick: magickwand doesn't convert to TIFF 1 bit
On 15/09/2014 00:54, José Mejuto wrote: > El 13/09/2014 17:34, Reinier Olislagers escribió: > For some reason the bindings in Pascal, and/or the wand bindings (maybe > internally to imagemagick) are broken. Mmmm, if the wand bindings were broken that would surely have lead to many more people complaining and it getting fixed? > Use this enumeration to get the expected result in the TIFF module: Great, thanks a LOT - that does solve the problem! Mantis issue http://mantis.freepascal.org/view.php?id=26723 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] with statement using mulltiple objects
On 2014-09-14 13:30, Marco van de Voort wrote: > WITH doesn't, and you risk that if your class or one of its ancestor has > such property, and your error goes unnoticed. +1 Not to mention that you can't use tooltip debugging when it comes to the WITH statement - at least this was the case last time I tried (I don't use WITH, so it could have been a long time ago). Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] with statement using mulltiple objects
On 2014-09-14 15:41, Vojtěch Čihák wrote: > because Editor is also public property of TStringGrid. Here would be > solution to rename parameter to "AEditor". Yes, that is a classic issue I have often come across. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] with statement using mulltiple objects
On 2014-09-14 11:49, Sven Barth wrote: > Though to be honest Lazarus handles with-statements in context of debugging > much more gracefully than Delphi... We all know Lazarus is way better that Delphi - so that's always good to know. :) As already mentioned, human refactoring of WITH statements can, and has, caused lots of debugging issues afterwards. Two or more classes used in a with statement, both classes have the same property name - how the hell must the developer know (and the compiler for that matter) which one is meant where. Bottom line (for me), WITH gives more trouble than its worth, so I avoid it at all costs. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] with statement using mulltiple objects
On Mon, September 15, 2014 07:55, Sven Barth wrote: > On 14.09.2014 18:05, Philippe wrote: >> someone wrote about a better performance using "with". is that true? >> even with a simple pointer as in: . . > This is the relevant code generated for TestWith: > > === asm begin === > > # [28] with p^ do begin > movl-4(%ebp),%ebx > # [29] Prop1 := 42; > movl%ebx,%eax > movw$42,%dx > callP$TWITHTEST_TTEST_$__SETPROP1$SMALLINT > # [30] Prop2 := 21; > movl%ebx,%eax > movw$21,%dx > callP$TWITHTEST_TTEST_$__SETPROP2$SMALLINT > > === asm end === > > and this for TestWithout: > > === asm begin === > > # [42] p^.Prop1 := 42; > movl-4(%ebp),%eax > movw$42,%dx > callP$TWITHTEST_TTEST_$__SETPROP1$SMALLINT > # [43] p^.Prop2 := 21; > movl-4(%ebp),%eax > movw$21,%dx > callP$TWITHTEST_TTEST_$__SETPROP2$SMALLINT > > === asm end === > > As you can see the expression p^ is only evaluated once in the TestWith > case while it's evaluated twice in the TestWithout one. So it's only > minimally faster in this example (one less memory access), but if you > use enough members of TTest it a more or less tight loop it might even > be noticeable. Have you tried to enable optimizations? Diff of the two code fragments generated with 2.6.4 and -O3: --- t_with_o3.s Mon Sep 15 08:59:07 2014 +++ t_without_o3.s Mon Sep 15 08:59:32 2014 @@ -1,18 +1,14 @@ -# [26] New(p); +# [40] New(p); movl$0,%eax callfpc_getmem movl%eax,%ebx -# [28] with p^ do begin - movl%ebx,%esi -# [29] Prop1 := 42; - movl%esi,%eax +# [42] p^.Prop1 := 42; movw$42,%dx callP$TWITHTEST_TTEST_$__SETPROP1$SMALLINT - movl%esi,%eax -# [t.pas] -# [30] Prop2 := 21; +# [43] p^.Prop2 := 21; + movl%ebx,%eax movw$21,%dx callP$TWITHTEST_TTEST_$__SETPROP2$SMALLINT -# [33] Dispose(p); +# [45] Dispose(p); movl%ebx,%eax callfpc_freemem Note that there are actually more instructions generated for version using 'with' in this case (obviously depending on the context). In other words, the remark about micro-optimizations (which may not necessarily lead to expected results) applies here... Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
