from:"Martin"

On Monday 04 March 2013 09:26:53 Vittorio Giovara wrote:

 Martin made a point that delphi7 is faster better and whatever than fpc...
 so what?
 Don't use fpc if you don't like it, or send patches to improve it ;)

You probably might know, I am the author of MSEide+MSEgui:
http://sourceforge.net/projects/mseide-msegui/

In MSEgui development I am happy if users report what they need in their daily 
work and what is inconvenient in current MSEgui implementation. I then try to 
examine the problem, find out how it can be solved and implement an universal 
solution based on what I learned from the conrete real world example. I do 
not expect that users provide patches, reproducible testcases are enough. If 
the users provide patches there is a big risk, that they fix their current 
problem only instead to find an orthogonal improvement. And the quality of 
the code maybe is not always the best. ;-)
Please read the MSEide-MSEgui mailing list archive in order to check how 
things are handled in MSEgui.
http://www.mail-archive.com/mseide-msegui-talk@lists.sourceforge.net/

With the MSEide Delphi/Kylix/FPC comparison I provide a real world testcase 
which the FPC team can use to improve their product. If the FPC team don't 
want to do so or think it is not necessary or it is no fun then I have to 
accept it and I will accept it.
But from time to time I will repeat the comparison in order the facts will not 
get forgotten.

Martin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Martin


On 04/03/2013 04:54, Boian Mitov wrote:

Here is example:

Parallel execution with selection of executor:

for i := 0 to AMaxScaleIndex - 1 do
 begin
 APerIterationLocations.Add( TRTDynamicListTVLImageRect.Create() );
 AExecutionTask.Add( AExecutor.Execute(
 procedure()
 begin
   ProcessOne( levelScale[ i ], img, hitThreshold, winStride, 
padding, APerIterationLocations[ i ] );

 end
   ));

 end;

In this case, not only you save declaration, you save the need to 
write a whole new class just for the task.

This code reduced well over 30 lines of code alone.
I have a lot of other examples as well ;-) .


Ok, I can see the closure helping, but why the anonymous procedure?

If FPC would offer something like this:

Procedure Foo;
var
  // your locals
 procedure  Bar(); closure;
   begin
 ProcessOne( levelScale[ i ], img, hitThreshold, winStride, 
padding, APerIterationLocations[ i ] );

   end
begin
  // your code from above
  for i := 0 to AMaxScaleIndex - 1 do
   begin
   APerIterationLocations.Add( TRTDynamicListTVLImageRect.Create() );
   AExecutionTask.Add( AExecutor.Execute( @Bar  ));
end;

I added:
 - the name Bar
- Used is at reference
- the keyword closure

The above code would then create the exact same closure, as your code 
does. And it does not need an anonymous method.


Of course for portability of Delphi code, in {$mode Delphi}  you need 
the anonymous method.
But the argument on this thread was, that you needed it, because 
anonymous functions allowed to do things not possible (or very hard) 
without. And that argument still does not hold up. It only applies to 
closures.


There is only one other difference between the 2. And that is the 
subjective preference where you like the code.
- You may find it more readable to see see code of a function in-lined. 
So you do not need to scroll.
- You may prefer the shorter body of the none anonymous version. After 
all, if you give it a meaningful name, it should read as easy as the 
inlined version.

But that is personal preference. It can not be argued on.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Martin


On 04/03/2013 05:00, Boian Mitov wrote:
One thing for sure, I probably will very much never need to declare 
TThread inherited classes. I can use a single anonymous method for 
that, thanks to the ability of the anonymous method to capture local 
and member variables.
This is something not doable with closure as it has fixed number of 
parameters ;-) .


Afaik, that is exactly what a closure is. To capture the 
scope/environment of the surrounding code (including the local variables 
of the procedure in which it is declared.


An anonymous method just skips the name, and allows to declare it in-line.

Delphi may not offer them individually. I do not know... But this is not 
about what Delphi offers.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Martin


On 04/03/2013 05:57, Alexander Klenin wrote:

On Mon, Mar 4, 2013 at 2:38 PM, Martin laza...@mfriebe.de wrote:


Closures, do not need to be written/declared in the middle of other code
(in-line)

Strictly speaking, they do not. However, if the closures are required
to be named,
their expressive power and readability will suffer greatly.


Nevertheless, I agree what the implementation plan can be detailed even further:
1) Anonymous procedures *without* closures -- basically, just another
syntax for nested procedures.

That might be interested for mode Delphi

2) Named closures support -- while I do think that anonymous
procedures are useful,
And this could be in mode FPC too. So purists can still enjoy 
closures. But it keeps one of the thinks that make Pascal: Declaration 
is all done before the code block starts.



3) Anonymous closures support -- a combination of the above:
// Delphi-compatible syntax. Could be made to *not* use closures in

4) As stated above, either a syntax to explicitly turn off a closure
for anonymous procedure,
   or intelligent enough optimizer to do that automatically. I have
some ideas on both fronts,
   but I suggest we first discuss previous points.



IMHO explicit Syntax.

But in the recent light of discussions to keep pascal being Pascal, 
anonymous functions could be entirely mode delphi only.


From the reasons for anonymous methods.

   in Delphi every local variable access becomes a reference to the
frame object field,
   *even in the parent procedure*. So nested anonymous procedures,
together with
   good inlining support, are crucial for the efficient implementation
of, for example,
   various ForEach methods.


That could be implemented for *named* closures too, and then there was 
no need for the anonymous.



IMHO anonymous methods are a syntactical difference only. All 
functionality can be done with named equivalents too.



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Martin


On 04/03/2013 06:06, Boian Mitov wrote:

It may be a good idea to analyze the current Delphi implementation.
In essence the anonymous method expands to a class and interface.
The interface Execute method has the parameters of the anonymous 
function. and the corresponding interface has the Execute method.
The class contains all the variables that are captured from the 
current context, and the constructor of the class does the capture.
The class is reference counted trough the interface, and is disposed 
when all references are released.
There are some interesting side effects and benefits from the 
implementation, and there are fear number of articles about that on 
the web.


All fine and good. But all that can be done with a *named* closure too
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3

On Monday 04 March 2013 12:05:37 Florian Klämpfl wrote:
 Am 04.03.2013 01:00, schrieb Graeme Geldenhuys:
  4.4 seconds (Kylix under Linux) vs 89 seconds (FPC under Linux)... That
  is just too a huge performance difference to justify. Yes, we all know
  the argument about more platforms, maintainable code etc, but that
  couldn't possible be the only reason for such a huge speed difference.
  Somewhere there is a serious bottleneck(s), or the FPC team simply
  disregard optimization completely. From why I have heard them say, the
  latter is more likely [unfortunately].

 You completely miss the point. If there are only approx 25
 features/properties which make the compiler each 10% slower than in
 total FPC is 10 (1.1^25=10.9) times slower than before.

Is this correct? It implies that every feature/property uses 100% of the total 
process. And if it is true it is absolutely necessary to stop adding features 
soon because 1.1^50 = 117.4. ;-)

Martin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Martin


On 04/03/2013 12:51, Sven Barth wrote:
If you guys would read what I wrote in one of my first answers to 
Vasiliy in this thread than you would know that I want him to 
implement this possiblity as well... but after all, who reads the 
mails of some strange computer science student who just happens to 
work on the compiler -.-

Yes, you did. 2nd message of the thread.

My reply however was to a mail, claiming (or at least to me giving the 
impression of doing so) the improvements where given by anonymous 
method rather than closure.

So I wonted to clarify this, and therefore ended up giving this example



To rephrase: implement support for anonymous functions for Delphi 
compatibility (maybe coupled to a mode switch) 

yes: {$mode Delphi}}

and allow for all other modes the assignment of nested 
functions/procedures to reference to procvars instead. Additionally 
a shortened lambda syntax can be added for really simple cases.


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3

On Monday 04 March 2013 07:08:25 Martin Schreiber wrote:

 Both Delphi 7 and Kylix 3 compiled MSEide feel more snappy than their FPC
 counterpart which is especially surprising for Delphi because Delphi
 widestrings are not reference counted.

Some more tests, starting MSEide, loading and highlighting the 277441 lines 
MacOSAll.pas from FPC 2.4.0:

FPC 2.6.2 Windows 3.2..3.5s
Delphi 7 Windows   4.0s
FPC 2.6.2 Linux5.0s
Kylix 3 Linux  4.0s.

It seems there is actually a benefit of the reference counted Free Pascal 
UnicodeStrings on Windows.

Martin


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Martin


On 04/03/2013 14:09, Alexander Klenin wrote:

On Mon, Mar 4, 2013 at 10:34 PM, Martin laza...@mfriebe.de wrote:

Nevertheless, I agree what the implementation plan can be detailed even
further:
1) Anonymous procedures *without* closures -- basically, just another
syntax for nested procedures.



That might be interested for mode Delphi

No, this would be incompatible -- in Delphi, anonymous procedures are
the only syntax for closures.
I was proposing the reverse -- do this on objfpc mode only.

My comment was about anonymous part:
- Any anonymous function, for {$mode delphi} only.
- {$mode objfpc} does not need any anonymous functions at all.

AS for extending anonymous functions in the delphi mode: I have no opinion.


2) Named closures support -- while I do think that anonymous
procedures are useful,

And this could be in mode FPC too. So purists can still enjoy closures.
But it keeps one of the thinks that make Pascal: Declaration is all done
before the code block starts.

Of course, this should only be on mode FPC, since Delphi does not have
named closures.
Yes, but doesnt hurt if it compiles. mode delphi does not need to be 
artificially restricted.


The efficiency argument was mostly to show that non-closure procedures 
are useful,

No argoment there. Both have there place



IMHO anonymous methods are a syntactical difference only. All functionality
can be done with named equivalents too.

syntactical difference is a very broad concept. The whole notion of high-level
programming language is one large pile of syntactical differences from
machine code.
I did *not* mean to diminish the importance of the correct syntax. I 
merely tried to emphasis the point, that this thread is about 2 things:
- anonymous functions: which is mainly adding new syntax. There is 
little (if any) new functionality added.  You still have the same code. 
Only now you can put it in a different location.

- closures: which add new functionality.


The important question is, whether the new syntax adds enough expressive power
to justify the complexity it adds to the language?
In the case of anonymous methods, my answer is yes, but only with
lambda or similar extension.
Let's revisit a typical example of anonymous functions -- note that
this example does NOT use closures
   to avoid another confusion:
0) Suppose we have
type
   TVisitor = function (X: Integer): Integer;
   TTree = class
  procedure VisitPreorder(AVis: TVisitor);
   end;

1) Current syntax:
function AddFive(X: Integer): Integer; Result := X + 5; end;
ATree.VisitPreorder(AddFive);

2) Delphi syntax:
ATree.VisitPreorder(function (X: Integer): Integer; Result := X + 5; end;);

3) With lambda syntax:
ATree.VisitPreorder(lambda TVisitor; Result := X + 5; end;);

3) With as syntax:
ATree.VisitPreorder(function (X: Integer): Integer as X + 5);

4) With both lambda and as syntax:
ATree.VisitPreorder(lambda TVisitor as X + 5);

Now, my argument is that (2) does indeed have only a marginal
advantage over (1),
IMHO it does not. Except for, currently AddFive can not be a nested 
procedure. If we could use a nested (none closure) procedure here, then 
I would prefer this.

However I agree, this is subjective preference.


but (4) is powerful enough to really make functional-style programming
practically



I can live with that. I find it odd so that as is used in the reverse 
order compared to current use.





___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Martin


On 04/03/2013 14:49, Sven Barth wrote:

Am 04.03.2013 15:42, schrieb Martin:



but (4) is powerful enough to really make functional-style programming
practically



I can live with that. I find it odd so that as is used in the 
reverse order compared to current use.


The use of as is based on an idea of mine. C# for example has = 
and Oxygene has - which I didn't consider much Pascal like. Also 
the compiler needs to know the type of the lambda so it can correctly 
typecheck its code (after all we have no type inference (yet :P )). So 
lambda PROCVARTYPE as EXPR/STMT came as the most natural and 
Pascal like variant.


First: Stressing out: I don't like it. But if we must have one, the 
lambda approach is the best one yet.

Reason: At least the type is declared at a pascal-like location.

I did not note at first, but the al leaves  the Result away. So X+5 
now looks like a statement.

What would happen with
  ATree.VisitPreorder(lambda TVisitor as begin X := min(10,x); X + 5; end);
Reminds me of perl: the last value is the return value.

If you look for the most natural, pascal like (ignoring the part that declaring 
a function inline, IMHO is not that)

  ATree.VisitPreorder(TVisitor(Result := X + 5);
  ATree.VisitPreorder(TVisitor(begin Result := X + 5; end);

You are type casting the code, into a procedure of the given type.





 



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Martin


On 04/03/2013 16:05, Alexander Klenin wrote:

Anonymous functions (with good syntax, of course) fall in this category.
The world recognized that fact -- rather slowly, to be sure, but
remember that whiles and fors
also took decades to be accepted as standard constructs.
 I am not going to ask for proof of this statement (as for example in 
quotation of literature on the topic).

For the arguments sake, let's assume the above.


No, my proposal (which was made in the previous thread in this topic)
is following (all-caps denotes non-terminal):
1.1) A function of the form
   function NAME(PARAMS): RETURNTYPE; begin Result := EXPRESSION; end;
can be shortened to
   function NAME(PARAMS): RETURNTYPE as EXPRESSION
IMHO that is not a good idea. It adds an additional construct, that 
every reader must know how to read. It does not add/save enough to be 
needed.



If you look for the most natural, pascal like (ignoring the part that
declaring a function inline, IMHO is not that)

   ATree.VisitPreorder(TVisitor(Result := X + 5);
   ATree.VisitPreorder(TVisitor(begin Result := X + 5; end);

You are type casting the code, into a procedure of the given type.

There is certainly a merit in that, but it violates another Pascal
basic principle -- prefer keywords to symbols.
We could also use the new, have a constructor for everything 
(TArray.Create) style. Personally, the idea appals me, but

   TVisitor.Create(Result := x + 5)

Another way to avoid the as
  lambda(TVisitor)  end

lambda acts as begin to the block, so there always must be an end.


Also, note that you can not omit Result assignment,
since ATree.VisitPreorder(TVisitor(X + 5)); is syntactically ambiguous.
So it becomes
ATree.VisitPreorder(TVisitor(Result := X + 5));
vs
ATree.VisitPreorder(lambda TVisitor as X + 5);

See above. The omission of Result := is IMHO not desirable.


Finally, I disagree with unbalanced parenthesis -- but that's probably a typo?



yes
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3

On Monday 04 March 2013 15:19:56 Tomas Hajny wrote:
 
  Any idea, why FPC Linux is slower than FPC Windows?
  Loading and highlighting does not sound like a task where many OS calls
  are involved.

 Is the starting MSEide (as mentioned above) bit included in the measured
 time? That would probably imply quite some OS calls, of course...

Yes. The time is from pressing enter with mseide respective mseidefp on 
the the commandline until the last line of MacOSAll.pas from FPC 2.4.0 in the 
source editor window is colored. MSEide first shows the file without colors 
and does the highlighting in background if main event loop is idle.

Martin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Martin


On 04/03/2013 16:05, Alexander Klenin wrote:

Both lambda and as keywords are quite debatable, of course.



IMHO the existing procedure/function keywords should be kept. But with 
the requirement of using a defined type


Foo(  function as TVisitor; Result := x+5 end; );

or
Foo(  function as TVisitor; begin Result := x+5 end; );
Foo(  function of TVisitor; begin Result := x+5 end; );

or even
Foo(  function TVisitor( Result := x+5 ));


or anything alike
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3

On Monday 04 March 2013 18:16:03 Mattias Gaertner wrote:

  Yes. The time is from pressing enter with mseide respective mseidefp
  on the the commandline until the last line of MacOSAll.pas from FPC 2.4.0
  in the source editor window is colored. MSEide first shows the file
  without colors and does the highlighting in background if main event loop
  is idle.

 And how much time is spent on the highlighting on Linux
 and Windows?

About 2/3 on booth. I need to instrument the code in order to get more precise 
numbers.

Martin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3

On Monday 04 March 2013 14:54:01 Mattias Gaertner wrote:
 On Mon, 4 Mar 2013 14:50:17 +0100

 Martin Schreiber mse00...@gmail.com wrote:
  On Monday 04 March 2013 07:08:25 Martin Schreiber wrote:
   Both Delphi 7 and Kylix 3 compiled MSEide feel more snappy than their
   FPC counterpart which is especially surprising for Delphi because
   Delphi widestrings are not reference counted.
 
  Some more tests, starting MSEide, loading and highlighting the 277441
  lines MacOSAll.pas from FPC 2.4.0:
 
  FPC 2.6.2 Windows 3.2..3.5s
  Delphi 7 Windows   4.0s
  FPC 2.6.2 Linux5.0s
  Kylix 3 Linux  4.0s.
 
  It seems there is actually a benefit of the reference counted Free Pascal
  UnicodeStrings on Windows.

 Any idea, why FPC Linux is slower than FPC Windows?

I don't know. I often find Windows 2000 faster than Linux.

Martin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Martin


On 04/03/2013 19:16, Alexander Klenin wrote:

function NAME(PARAMS): RETURNTYPE as EXPRESSION

IMHO that is not a good idea. It adds an additional construct, that every
reader must know how to read. It does not add/save enough to be needed.

I agree, it is borderline, and needs to be additionally justified.
I believe that for each feature, there is a threshold for the baroqueness of
syntax required to use it which separates obscure from simple and
understandable.
The main barrier for understanding code is not actually the number of
language constructs involved -- they are way too few compared to,
say, number of procedures in any non-trivial library.
The main barrier is the amount of effort required to see the programmers intent
while looking at a given piece of code.
For example (still using lambda syntax here to not muddle the issue,
I'll discuss your alternatives to lambda below):

// Task: Select five largest even numbers from the array:

// (0) Theoretically possible with type inference:
AIntArray.Filter(lambda X div 2 = 0).Sort(lambda X  Y).Take(5);
How is that possible? In lambda X  Y  how does the compiler know, if 
X or Y is the first param?




// (1) My proposal
AIntArray.Filter(lambda TIntFilter as X div 2 = 0).Sort(lambda TIntCmp
as X  Y).Take(5);
And that is a good example *against* anonymous functions. Even with some 
c# background (and it does remind me of it / maybe general dotNet), I 
had to read it several times.
Sure, if it was highlighted it might be easier to find the keywords 
lambda/as and to know where the expression (the truncated result := 
statement starts.




// (2) Without as
AIntArray.
   Filter(lambda TIntFilter; begin Result := X div 2 = 0 end).
   Sort(lambda TIntCmpl; begin Result := X  Y; end).Take(5);


You comparison is tainted. the begin/end are not needed. Though, I 
actually would like them required. Well at least the end. The lambda 
might serve as the opening.


AIntArray.
  Filter(lambda TIntFilter; Result := X div 2 = 0 end).
  Sort(lambda TIntCmpl; Result := X  Y; end).Take(5);

And that is of course because of your preference for keyword over typecast. 
Though you are right, even in a typecast a keyword would be good to indicate 
this code is not executed right away.

  AIntArray.
  Filter(TIntFilter(lambda Result := X div 2 = 0 end).
  Sort(TIntCmpl(lambda Result := X  Y end).Take(5);

Then a none type casted lambda could return a procedure();, no params, no 
result.


// (4) Without anonymous functions:
function IsEven(X: Integer): Boolean; begin
   Result := X div 2 = 0;
end;
function IsGreaterThan(X, Y: Integer): Boolean; begin
   Result := X  Y;
end;
// ... possibly a lot of code here
AIntArray.Filter(@IsEven).Sort(@IsGreaterThan).Take(5);
And the actual fitter/sort line is so much easier to read. Really, so 
much easier...



As you can see, there is a spectrum of expressive power vs language simplicity.
It is debatable at which position of the spectrum Pascal should be,
but my opinion is that (4) is way too weak, (0) is probably too strong,
and (1) is easier to read then (2), (3) or (4) for any reasonably
literate programmer,

actually from a point of readability
 TIntCmpl(lambda Result := X  Y end
looks easiest to me. WIthin the typecast, you have only an opening 
/closing keyword. The rest is the code. No distraction






We could also use the new, have a constructor for everything (TArray.Create)
style. Personally, the idea appals me, but
TVisitor.Create(Result := x + 5)

I actually dislike this syntax even for arrays.

As I said: the idea appals me


Another way to avoid the as
   lambda(TVisitor)  end
lambda acts as begin to the block, so there always must be an end.

Why not also omit end then? Just say that lambda must be followed
by a single statement,
No Pascal is verbose. It must be a proper block. TO easy to misread 
otherwise.
 It does not have to finish with end, there could be another keyword. 
(Like in repeat until pair).


If there is no block
  Foo(lambda TFunc x = a, lambda TFunc yb)
versus
  Foo(lambda TFunc x = a(lambda TFunc yb))

And if (another of those I personally do not like it) tuples will come, 
then

Foo(lambda TFunc x = (a, lambda TFunc yb))
where x is a tuple, and the bracket is too.

I want a none return ticket to a different planet.


then for the case of many statements, begin..end should be used like
in normal blocks.
The only problem is with local declarations, but I guess it is
possible to disambiguate
based on var, const and type keywords appearing after lambda.

Argh yes, I hadn't thougt of that yet.

Well then that just makes it an even bigger monstrosity.
I am not going to think about that now. To much work for something that 
I do not want in first





See above. The omission of Result := is IMHO not desirable.

Are you sure? Note that *any* useful single-statement function will
start exactly like this
(strictly speaking, it could be also be call to exit, but obviously
it makes no

Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Martin


On 04/03/2013 19:16, Alexander Klenin wrote:

See above. The omission of Result := is IMHO not desirable.

Are you sure? Note that *any* useful single-statement function will
start exactly like this

If a = x then Result := 4 else Result := 5;

Single statement, but starts different.  And is useful.

But that isn't why I replied again.

Reading the shortened version versus the full anonymous procedure (with 
var, const, type) and I realized, that thi's a 2 entirely different 
things.


The above is NOT an anonymous function. It is a reference to a term.
I am not voting for it, but IF it was done, then it should have its own 
keyword.


It would not allow for var, type or anything (and it will only work for 
functions, not procedures.)

   a.sort(LambdaTerm TMyCompare do x  y)
or
   a.sort(TermRef TMyCompare(x  y) )

anonymous function, then would *always* require
   a. sort( Function; prototype TMyCompare; [var ...] begin ... end )

the protopybe (modifier) could work for named procedures too. (THey 
would be required NOT to have any params)

  Function Foo; prototype TMyCompare;
  [var ...]
  begin ... end

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Delphi anonymous methods

2013-03-04 Thread Martin


On 04/03/2013 22:16, Sven Barth wrote:


 The above is NOT an anonymous function. It is a reference to a term.
 I am not voting for it, but IF it was done, then it should have its 
own keyword.


 It would not allow for var, type or anything (and it will only work 
for functions, not procedures.)

a.sort(LambdaTerm TMyCompare do x  y)
 or
a.sort(TermRef TMyCompare(x  y) )

This is basically what my idea behind the lambs syntax was: only one 
expression or statement and no variable, type or constant 
declarations. And for more complex use case there are either Delphi's 
anonymous functions or FPC's nested procedures/functions.




Ok, so then it is important, that they are distinguished. Starting with 
their own name. We MUST NOT call them anonymous functions. (despite the 
do construct a function. But they are not, because the skip the  
Result:= part and other)


Technically they are a subset:
1- like a function, they have a result
2- like a function the have zero, 1 or more params
3- not like a functions, they can not have var or out param
  Well you can construct cases were they are possible:  (* Result := *) 
1 + Foo(VarParam);

  But I think they should not be allowed
4- There body must always contain a RHS term/expression
  This also results in that the can only be passed for functions
5- begin end is not allowed (would not be an RHS

About 4) If you want procedures to, then we can not use an RHS, because 
a procedure needs a full statement in the body.
That would mean functions would have to include the Result :=. There 
is no way of smart detection, because a function can also sot the result 
by doing CallFoo(Result) (CallFoo has an out param)

It is either or, but no mixture.
Even if it goes for proceddure style, 5 should still be considered.



 anonymous function, then would *always* require
a. sort( Function; prototype TMyCompare; [var ...] begin ... end )

 the protopybe (modifier) could work for named procedures too. (THey 
would be required NOT to have any params)

   Function Foo; prototype TMyCompare;
   [var ...]
   begin ... end

Ah! Now with the named example I understand the use of the ; after 
the function...




I think using a modifier is the best way to specify the parameter template.


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7

On Sunday 03 March 2013 10:04:54 Daniël Mantione wrote:
 Op Sun, 3 Mar 2013, schreef Martin Schreiber:
  BTW, a significant percentage of the time is waiting for FPC compiling
  because FPC normally crashes without -B.

 I think you should focus your efforts on getting those bugs fixed, such as
 by submitting bug reports that allow reproduction of the problem with
 programs as simple as you can get them to show the problem.

The problem is well known since a long time AFAIK. The answer we normally get 
when we report a unit handling related FPC crash is that FPC unit handling 
should be rewritten. I can't rewrite FPC unit handling myself because I have 
many other tasks. ;-)

Martin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7

On Sunday 03 March 2013 10:42:09 Sven Barth wrote:

 Do you mean compiling the compiler? If so than for real tests you SHOULD
 NOT compile the compiler by hand, but only through make cycle in the
 compiler directory or make all in the top level directory. This will
 ensure that the compiler is compiled correctly.

 And yes, I know the problem with -B and it's likely related to unit
 loading. This normally happens only in more complex projects like the
 compiler. Though I've just managed yesterday to create a smaller example
 (by accident) that also chrashes. Maybe I'll find the problem and can
 fix it once and for all :)

No, I mean MSEide. MSEide is a more complex application than the compiler it 
seems. :-)

Martin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3

On Friday 01 March 2013 18:33:56 Martin Schreiber wrote:
[...]
On Linux, same computer, OpenSUSE 12.2, comparison FPC 2.6.2, Kylix 3,
Source (master branch a4172602c45fe5abc931dee8b8ae2f4744ee70f3):
http://gitorious.org/mseide-msegui

Command line Kylix 3:
dcc -D+ -Aclasses=Classes -Adateutils=DateUtils -Afmtbcd=FMTBcd 
-Amaskutils=MaskUtils -Astrutils=StrUtils -U${DCUS} -I../../lib/common/kernel 
-U../../lib/common/kernel -U../../lib/common/audio -U../../lib/common/opengl 
-U../../lib/common/report -U../../lib/common/db -U../../lib/common/crypto 
-U../../lib/common/graphics -U../../lib/common/i18n 
-U../../lib/common/kernel/linux -U../../lib/common/image 
-U../../lib/common/widgets -U../../lib/common/designutils 
-U../../lib/common/sysutils -U../../lib/common/editwidgets 
-U../../lib/common/dialogs -U../../lib/common/regcomponents 
-U../../lib/common/serialcomm -U../../lib/common/printer -U../../lib/common/ifi 
-U../../lib/common/math -U../../lib/common/delphicompatibility 
-U../../lib/common/fpccompatibility 
mseide.pas

Result Kylix 3:
488041 lines, 4.40 seconds, 2762044 bytes code, 1220304 bytes data.
-rwxr-xr-x 1 mse users 5092836 Mar  3 18:16 mseide

Command line FPC 2.6.2:
ppc386 -O2 -g -Xg -Xs -B -Fi../../lib/common/kernel -Fu../../lib/common/kernel 
-Fu../../lib/common/audio -Fu../../lib/common/opengl -Fu../../lib/common/report 
-Fu../../lib/common/db -Fu../../lib/common/crypto -Fu../../lib/common/graphics 
-Fu../../lib/common/i18n -Fu../../lib/common/kernel/linux 
-Fu../../lib/common/image -Fu../../lib/common/widgets 
-Fu../../lib/common/designutils -Fu../../lib/common/sysutils 
-Fu../../lib/common/editwidgets -Fu../../lib/common/dialogs 
-Fu../../lib/common/regcomponents -Fu../../lib/common/serialcomm 
-Fu../../lib/common/printer -Fu../../lib/common/ifi -Fu../../lib/common/math 
-Fu../../lib/common/delphicompatibility -Fu../../lib/common/fpccompatibility 
-omseidefp 
mseide.pas

Result FPC 2.6.2:
495971 lines compiled, 89.3 sec
-rwxr-xr-x 1 mse users 7463712 Mar  3 18:19 mseidefp

Please note that smartlinking with FPC is not possible on that system because 
it has 1GB ram only.

Martin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7


Am 02.03.2013 11:11, schrieb Martin Schreiber:

On Saturday 02 March 2013 10:52:18 Michael Van Canneyt wrote:


Anyway, what seems obvious from your numbers is that it is the linking
stage that needs speedup. This does not really come as a surprise.


On Windows FPC linking time of MSEide is about 2-3 seconds IIRC, I'll check it
later, currently I try to make MSEide+MSEgui Kylix3 compatible so we have a
benchmark on Linux too.


I checked again, time of FPC linking stage is about 2.5 seconds.

Martin

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3

On Sunday 03 March 2013 20:08:43 Michael Van Canneyt wrote:
 On Sun, 3 Mar 2013, Martin Schreiber wrote:
  On Friday 01 March 2013 18:33:56 Martin Schreiber wrote:
  [...]
  On Linux, same computer, OpenSUSE 12.2, comparison FPC 2.6.2, Kylix 3,
  Source (master branch a4172602c45fe5abc931dee8b8ae2f4744ee70f3):
  http://gitorious.org/mseide-msegui

 Impressive.

 Now that we've clearly established that FPC is slower than Delphi,
 and that you consider this a serious problem (which we, in fact,
 know since some time):

 When can we expect to see some constructive proposals on how to
 improve the situation?

I supplied the benchmark, more than 10 man years of development time. A good 
start, no? ;-)

Martin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Delphi anonymous methods

2013-03-03 Thread Martin


On 04/03/2013 01:47, Boian Mitov wrote:

Strongly disagree.
Anonymous methods are a critical feature of any mother language, and 
allow vast improvements of the code and the readability. I recently 
started rewriting our libraries with anonymous methods and that alone 
allowed for cutting over 2 lines of code, while adding vast number 
of new features. Any language that does not support anonymous methods 
is just a joke IMHO.


Really, just by dropping the names? Or did you mean, you did all that by 
using closures?



From what I can see, anonymous methods are just like the above code...

allowing a declaration of a procedure/method in-line inside a code block
where in shouldn't belong. It is very, very un-Pascal like. The end
result is unreadable code, probably hard to debug etc.


Closures, do not need to be written/declared in the middle of other code 
(in-line)

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Delphi anonymous methods

2013-03-03 Thread Martin


On 04/03/2013 03:49, Boian Mitov wrote:

Yes, really!
Then again this is over 4 mln mines of code after all. :-D
Thank you for letting me know what closure is :-D . Can you imagine, 
me being component vendor for over 16 years and not knowing what 
closure is :-D.
Did I? Wow, I didn't know I did. Didn't mean to neither. I was just 
checking, if you accidentally used the wrong word. (Happens to everyone, 
even the very best / so no judgement implied)


Anonymous methods lead to a different way of thinking altogether and 
allow you to do things that you can't even imagine with closures ;-) .
And they make the code infinitely easier to read, especially if like 
me this is a huge codebase ;-) . After all we sell well over 400 
components not to mention some of our other Delphi based products ;-) .
Sure, if you have small code you can do just fine with closures, as I 
have for many years, then again I did just fine without having 
classes, and objects in the old days, and also did fine in the older 
days in Assembler :-D .
So according to this logic, we really should be doing everything in 
machine code (as I actually did briefly 24 years ago :-D ), who needs 
new features such as those whatmacallit... ohhh yeahh... compilers 
:-D .
Well I give you the benefit of the doubt, and believe you. But that does 
not help me, because I still do not know which case you are talking 
about So for my benefit, please enlighten me with an example.


From your above statement, I take, that you already used closures, and 
that the big improvements really happened of a result of anonymous methods.
Just to be save, let me state the obvious: We are talking of dropping 
the function name; and introducing the ability, to declare the function 
anywhere within the code (probably the latter being the important). That 
are the 2 only things, that anonymous methods do offer? (OR am I missing 
anything?)


If so then I do not see how they save 2 lines?
- The name is part of the declaration line, SO it should not affect the 
line count at all). Unless you always write the name on a separate line 
(which I would consider a very special case)

- the place of declaration also does not change the line count.



-Original Message- From: Martin
Sent: Sunday, March 03, 2013 7:38 PM
To: FPC developers' list
Subject: Re: [fpc-devel] Delphi anonymous methods

On 04/03/2013 01:47, Boian Mitov wrote:
Really, just by dropping the names? Or did you mean, you did all that by
using closures?

Closures, do not need to be written/declared in the middle of other code
(in-line)


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3

On Monday 04 March 2013 00:29:51 Vittorio Giovara wrote:

  IMHO Martin Schreiber is doing a great job using these comparisons and
  some improvements could be made in FPC... but he is making a mistake
  in their approach of how to present FPC's defects.

 I am not so sure about this... I know nothing of dcc switches but he
 is comparing the compiler speed with a different set of features, it
 is easy to spot how flawed the comparison is: -O2 -Xg -Xs are all
 optimization flags and it is expected that optimizing code takes time.

 Could be interesting to see the speed and size of the binary produced
 by the two compilers, slower compilation time over faster or smaller
 code is something I would pick any time!

Please note that Delphi/Kylix produce both smaller and faster code than FPC in 
the testcase, they do full optimisation by default. Quality of the produced 
code is another goal of the comparisons.

MSEide sizes


Delphi 7:   5'062'144
FPC 2.6.2 Windows with smart linking:   6'026'259
Kylix 3:5'092'836   
 
FPC 2.6.2 Linux without smart linking   7'463'712
(it can't smartlink with 1MB ram only) 

Both Delphi 7 and Kylix 3 compiled MSEide feel more snappy than their FPC 
counterpart which is especially surprising for Delphi because Delphi 
widestrings are not reference counted.

Martin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7

On Saturday 02 March 2013 10:52:18 Michael Van Canneyt wrote:

 Anyway, what seems obvious from your numbers is that it is the linking
 stage that needs speedup. This does not really come as a surprise.

On Windows FPC linking time of MSEide is about 2-3 seconds IIRC, I'll check it 
later, currently I try to make MSEide+MSEgui Kylix3 compatible so we have a 
benchmark on Linux too.

Martin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7

On Saturday 02 March 2013 10:12:51 Florian Klämpfl wrote:
 Am 01.03.2013 22:40, schrieb Martin Schreiber:
  On Friday 01 March 2013 22:30:31 Florian Klämpfl wrote:
  Am 01.03.2013 18:33, schrieb Martin Schreiber:
  Hi,
 
  In order to have a good benchmark for FPC
 
  Expect the next release to be even slower.
 
  Will it produce better code instead?

 What means better? Faster? Less buggy? Smaller?

It means faster and smaller, Delphi 7 produced code is smaller and faster than 
FPC 2.6.2 code. A compiler must be bug free anyway. ;-)

 I did a quick test on win32, it seems to be a little bit smaller than
 2.6.2:

 02.03.2013  10:09 5.774.848 mseide.exe

Compiled with which FPC version?

Martin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7

On Saturday 02 March 2013 11:12:52 Florian Klämpfl wrote:

  I did a quick test on win32, it seems to be a little bit smaller than
  2.6.2:
 
  02.03.2013  10:09 5.774.848 mseide.exe
 
  Compiled with which FPC version?

 trunk.

??? MSEgui compiles with trunk?

Martin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7

On Saturday 02 March 2013 14:01:10 Marco van de Voort wrote:
 In our previous episode, Martin Schreiber said:
Compiled with which FPC version?
  
   trunk.
 
  ??? MSEgui compiles with trunk?

 It is mostly unicodestring centric, so that shouldn't be such a surprise?

MSEgui has an own unicodestring manager on Linux which must be adapted to 
cpstrnew. Also the meaning of #nnn characters has changed and MSEgui uses 
some hacks with UnicodeStrings which must be adapted. I don't want to do the 
work before Unicode handling in FPC is finished and documented. And frankly, 
I don't believe in it anymore...

Martin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7

On Saturday 02 March 2013 11:28:25 Michael Van Canneyt wrote:
 On Sat, 2 Mar 2013, Martin Schreiber wrote:
  On Saturday 02 March 2013 10:52:18 Michael Van Canneyt wrote:
  Anyway, what seems obvious from your numbers is that it is the linking
  stage that needs speedup. This does not really come as a surprise.
 
  On Windows FPC linking time of MSEide is about 2-3 seconds IIRC, I'll
  check it later, currently I try to make MSEide+MSEgui Kylix3 compatible
  so we have a benchmark on Linux too.

 When you do, please send me the output of a strace -f

I will take a while because it is much work to make the code both FPC and 
Delphi/Kylix compatible.

 It will allow me to see what IO the Delphi/Kylix compiler does.

 We can say for sure that the fact you use .pas as filename extension
 will cause FPC to do twice the number of stat() calls, because .pp is
 searched first...Logical therefore that the IO is slower.

AFAIK *.pas is Delphi compatible? ;-)

Martin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7

On Sunday 03 March 2013 08:12:28 Martin Schreiber wrote:
 On Saturday 02 March 2013 11:28:25 Michael Van Canneyt wrote:
  On Sat, 2 Mar 2013, Martin Schreiber wrote:
   On Saturday 02 March 2013 10:52:18 Michael Van Canneyt wrote:
   Anyway, what seems obvious from your numbers is that it is the linking
   stage that needs speedup. This does not really come as a surprise.
  
   On Windows FPC linking time of MSEide is about 2-3 seconds IIRC, I'll
   check it later, currently I try to make MSEide+MSEgui Kylix3 compatible
   so we have a benchmark on Linux too.
 
  When you do, please send me the output of a strace -f

 I will take a while because it is much work to make the code both FPC and
 Delphi/Kylix compatible.

BTW, a significant percentage of the time is waiting for FPC compiling because 
FPC normally crashes without -B.

Martin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Comparison FPC 2.6.2 - Delphi 7

2013-03-01 Thread Martin Schreiber


Hi,

In order to have a good benchmark for FPC I made MSEide+MSEgui Delphi 7 
compatible again.

Source (master branch 2400be4999b254dbf335e4777baa33b13ea72649):
http://gitorious.org/mseide-msegui

As testcase I used compiling MSEide, all dcu's, ppu's and o's deleted 
before compiling.

System:
win2000, AMD Atlon XP 3000+, 1GB RAM

Command line Delphi 7:
dcc32 -B -D+ -I..\..\lib\common\kernel -U..\..\lib\common\kernel 
-U..\..\lib\common\audio -U..\..\lib\common\opengl 
-U..\..\lib\common\report -U..\..\lib\common\db 
-U..\..\lib\common\crypto -U..\..\lib\common\graphics 
-U..\..\lib\common\i18n -U..\..\lib\common\kernel\windows 
-U..\..\lib\common\image -U..\..\lib\common\widgets 
-U..\..\lib\common\designutils -U..\..\lib\common\sysutils 
-U..\..\lib\common\editwidgets -U..\..\lib\common\dialogs 
-U..\..\lib\common\regcomponents -U..\..\lib\common\serialcomm 
-U..\..\lib\common\printer -U..\..\lib\common\ifi 
-U..\..\lib\common\math -U..\..\lib\common\delphicompatibility 
-U..\..\lib\common\fpccompatibility mseide.pas


Result Delphi 7:
483086 lines, 6.72 seconds, 3396292 bytes code, 1217961 bytes data.

F:\proj\mseide-msegui\apps\idedir mseide.exe
 Datenträger in Laufwerk F: ist win2000_F
 Datenträgernummer: 5C58-C4EF

 Verzeichnis von F:\proj\mseide-msegui\apps\ide

01.03.2013  17:225'062'144 mseide.exe

Command line FPC 2.6.2:
ppc386.exe -g -Xg -O2 -CX -XX -Xs -B -Fi..\..\lib\common\kernel 
-Fu..\..\lib\common\kernel -Fu..\..\lib\common\audio 
-Fu..\..\lib\common\opengl -Fu..\..\lib\common\report 
-Fu..\..\lib\common\db -Fu..\..\lib\common\crypto 
-Fu..\..\lib\common\graphics -Fu..\..\lib\common\i18n 
-Fu..\..\lib\common\kernel\windows -Fu..\..\lib\common\image 
-Fu..\..\lib\common\widgets -Fu..\..\lib\common\designutils 
-Fu..\..\lib\common\sysutils -Fu..\..\lib\common\editwidgets 
-Fu..\..\lib\common\dialogs -Fu..\..\lib\common\regcomponents 
-Fu..\..\lib\common\serialcomm -Fu..\..\lib\common\printer 
-Fu..\..\lib\common\ifi -Fu..\..\lib\common\math 
-Fu..\..\lib\common\delphicompatibility 
-Fu..\..\lib\common\fpccompatibility -omseidefp.exe mseide.pas


Result FPC 2.6.2:
489756 lines compiled, 84.6 sec , 3309520 bytes code, 2691084 bytes data

F:\proj\mseide-msegui\apps\idedir mseidefp.exe
 Datenträger in Laufwerk F: ist win2000_F
 Datenträgernummer: 5C58-C4EF

 Verzeichnis von F:\proj\mseide-msegui\apps\ide

01.03.2013  17:246'026'259 mseidefp.exe

Martin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7

2013-03-01 Thread Martin Schreiber

On Friday 01 March 2013 22:30:31 Florian Klämpfl wrote:
 Am 01.03.2013 18:33, schrieb Martin Schreiber:
  Hi,
 
  In order to have a good benchmark for FPC

 Expect the next release to be even slower.

Will it produce better code instead?

Martin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Assert and calling frame / address

2013-02-17 Thread Martin

If the RTL is compiled with optimization then same functions may not 
have a stackframe. Of course that is intended. But...


Within the list of those is at least one (probably both of the following:

Procedure fpc_assert(Const 
Msg,FName:Shortstring;LineNo:Longint;ErrorAddr:Pointer); [Public,Alias : 
'FPC_ASSERT']; compilerproc;

begin
  if pointer(AssertErrorProc)nil then
AssertErrorProc(Msg,FName,LineNo,ErrorAddr)
...

Procedure AssertErrorHandler (Const Msg,FN : ShortString;LineNo:longint; 
TheAddr : pointer);

...
S:=Msg;
  Raise EAssertionFailed.Createfmt(SAssertError,[S,Fn,LineNo]) at 
get_caller_addr(theAddr), get_caller_frame(theAddr);



This leads to get_caller_addr/get_caller_frame getting the address and 
frame of the wrong function.
Instead of the function containing the assert, they will get the caller 
of that function.


This is unconvincing if debugging.

I was wondering what the options are? Not even sre if that really is due 
to the missing frame


the code calling ASSERT

006F30AB 55   push   %ebp  // ErrorAddr:
006F30AC b96903   mov$0x369,%ecx
006F30B1 baf8478000   mov$0x8047f8,%edx
006F30B6 b8c8498000   mov$0x8049c8,%eax
006F30BB e800acd1ff   call   0x40dcc0 fpc_assert

ErrorAddr is the frame of the function calling assert?

Then why get_caller_addr/get_caller_frame ?

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] fpc 2.7.1 segfault in writestr?

2013-02-15 Thread Martin


revision 23621
Win 32 / Vista

RTL build with OPT=-gl -gw -godwarfsets -O-1
compiler build with OPT=-gl -O3 -Or -CpPENTIUMM -OpPENTIUMM
Lazarus  -WC -gh -Criot -gw2 -godwarfsets -O-1 -gt

The following line crashes with SigSegV
writestr(BaseConf, AType,':',
 ' IMode=', dbgs(AIndentMode), ' IMax=', 
AIndentFirstLineMax, ' IExtra=', AIndentFirstLineExtra,
 ' CMode=', ACommentMode, ' CMatch=', AMatchMode, ' 
CLine=', AMatchLine,
 ' M=''', AMatch, ''' R=''', APrefix, ''' CIndent=', 
ACommentIndent

);


Stepping through the disassembler it happens in a cass to
0046E95B e8e03efaff   call   0x412840 fpc_write_end


Not much of the stack is available:
#0 CPUDECLOCKED(1718187125) at ..\i386\i386.inc:1246
#1 fpc_ansistr_decr_ref(0x66697475) at ..\i386\i386.inc:1490
#2 ?? at :0

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] I have created a openocd debugger-interface for lazarus, now some questions

2013-02-07 Thread Martin


On 07/02/2013 07:14, Michael Ring wrote:


One more thing, do you know why ExecuteCommand is defined as protected 
and not public in GDBMIDebugger? I need to send some extra commands to 
GDB to make the remote connection, using ExecuteCommand is an elegant 
way to do this. But the method is invisible in my class because it is 
protected. Can the ExecuteCommand methods be made public or is this a 
no-go?
They (the ones in GDBMIDebugger, not the ones in TGDBMIDebuggerCommand) 
should be deprecated and removed.


All commands must go via TGDBMIDebuggerCommand. This is because GDB may 
need to be set into the correct state (select thread/stack).
The ones in TGDBMIDebugger are left overs from long ago. They do work, 
because they do actually encapsulate the command in a TGDBMIDebuggerCommand


I have plans to change this and introduce a new inner queue, that will 
automatically da the necessary thread/stack selection.


Then also the TGDBMIDebuggerCommand should be changed, so they do not 
expect a result from a gdb command, but assign an event, and get called 
back. So ProcessMessages will no longer be needed.

But that is still some time to go.

---
As for you, You should be able to inherit from TGDBMIDebuggerCommand?

Also I do not understand why you do not see a protected class. You do 
inherit from TGDBMIDebugger? And if you have helper objects, then you 
can create a public wrapper in your main class.





Which GDB version is your prefered version for debugging FreePascal?
I run the testcase for gdb 6.3 to 7.5. So the IDE can communicate with 
all of those.


On Mac, apple provides a modified 6.3.5

On Windows (at least 32 bit) I recommend 7.2.  7.3 up has some 
regressions http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#Bugs_in_GDB

Win64 I am not sure

On Linux any 7.x should be fine

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] I have created a openocd debugger-interface for lazarus, now some questions

2013-02-07 Thread Martin


On 07/02/2013 23:51, Michael Ring wrote:


Index: debugger/debugger.pp
===
--- debugger/debugger.pp(revision 40204)
+++ debugger/debugger.pp(working copy)
@@ -3304,6 +3304,7 @@
 const
   OLD_GDB_DBG_NAME = 'GNU debugger (gdb)';
   OLD_SSH_DBG_NAME = 'GNU debugger through SSH (gdb)';
+  OLD_REMOTE_DBG_NAME = 'GNU debugger through OpenOCD (gdb)';


You should not need this.

Older versions of the IDE used those strings in the XML. But now the IDE 
uses the classname.


The 2 existing old names are kept so old config can be read.

There is no old config for your class.


 var
   s: String;
 begin
@@ -3314,6 +3315,7 @@
 s := ConfigStore.GetValue('Type', '');
 if s = OLD_GDB_DBG_NAME then FDebuggerClass:='TGDBMIDEBUGGER';
 if s = OLD_SSH_DBG_NAME then FDebuggerClass:='TSSHGDBMIDEBUGGER';
+if s = OLD_REMOTE_DBG_NAME then 
FDebuggerClass:='TOPENOCDGDBMIDEBUGGER';

see above


Index: debugger/gdbmidebugger.pp
===
--- debugger/gdbmidebugger.pp   (revision 40204)
+++ debugger/gdbmidebugger.pp   (working copy)
@@ -4502,8 +4502,12 @@
   s := GetPart(['Thread '], [' '], R.Values, True);
   Result := StrToIntDef(s, 0);
   if Result  0 then exit;
+
+  // returned by openocd server
+  s := GetPart(['* '], ['Remote target'], R.Values, True);
+  Result := StrToIntDef(trim(s), 0);
+  if Result  0 then exit;
 end;


I'd rather factor all of the get PID code into a virtual method. (on 
the class TGDBMIDebuggerCommandStartDebugging)

Actually that might be the entire RunToMain

Then you can override it, and add there.

That means you have to subclass TGDBMIDebuggerCommandStartDebugging. See 
the GDBMIServerDebugger haw to do that



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Why FreeBSD sem_init() works different to Linux?

2013-02-06 Thread Martin Schreiber

On Wednesday 06 February 2013 20:24:34 Graeme Geldenhuys wrote:


 It case I'm overlooking something critical, has anybody else done
 something like this. If so, anybody willing to share that code - saving
 me some time in developing, unit testing and debugging my own Object
 Pascal based semaphore.

MSEgui has a semaphore implementation. On Linux it uses the libc interface, on 
Windows an own implementation with a windows event object, 
lib/kernel/windows/msesysintf1.pas. Works so far, but with sync mechanics one 
never knows...

Martin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] I have created a openocd debugger-interface for lazarus, now some questions

2013-02-05 Thread Martin


On 05/02/2013 22:14, Michael Ring wrote:
I have integrated openocd debugger class as a child of the gdbmi 
debugger classes, basic code upload  debugging now works for me in 
lazarus, still has some rough edges, this is why I am seeking for 
support by the arm-embedded hackers here in fpc-devel.

...
single stepping works, I seem to have trouble with creating 
breakpoints, I run out of them very fast, for example lazarus shows me 
3 breakpoints, openocd complains that it is already at breakpoint #11, 
is this a well known problem or do I need to investigate deeper into 
this?

Hi.
I don't know much about openocd. But I do know the debugger stuff in 
Lazarus.


Since you say it is based on the gdbmi classes: There are a number of 
breakpoints inserted by GDBMI at startup.


First GDBMI runs the exe to the main-entry-point. It does that in order 
to then set other breakpoints and do other initialization (which on some 
platform depending on gdb and god knows what, can only succeed *after* 
the initial run).
a) up to 4 breakpoints (each by name  AND address) to stop at main entry 
point. find function:

   function RunToMain(EntryPoint: String): integer;
b) 3 breakpoints in fpc, to catch exception, run-error and some other
c) run the program.

So that gives the breakpoints you see.

This can be moved to a virtual method, if a suitable patch is supplied.




Also, visibility of variables is not that good, I can see simple 
variables in my procedures but more complex variables are usually 
invisible. Is this a known problem or is there just some magic I need 
to apply in the startup of gdb?
Complex variables are read via a great many conditions. Each GDB reports 
slightly different, and needs slightly different corrections


e.g a class may have to be deferred (Foo^.FField), or even first 
typecasted (to the type already detected by GDB via ptype). That is 
mostly done in GDBTypeInfo


I have run various commands, for various datatypes against a dozen 
different GDB (and I keep doing for new releases). Some examples are in  
debugger\test\gdb responses\



For in IDE testing define (be warned, you can screw the debug session. 
Do NOT run or step).

DBG_WITH_DEBUGGER_DEBUG   // adds commandline to debug output window
DBG_WITH_GDB_WATCHES  // Allows watches or eval-window gdb_command




Another issue is that I cannot do the loading of my binary from within 
gdb, at the moment I still need to do direct telnet communication with 
openocd.
Not sure if it helps, there also is a class that started work on 
gdbserver / it is in SVN




Which library should I use for doing the telnet session? I read on the 
freepascal wiki  that fcl-net is a little outdated, so which library 
should I use, I do not want to introduce additional dependencies to 
the lazarus build by including synapse or indy.


If your exe is remote, you need to disable the pause functionality 
(which is also called if you change breakpoints while running (not 
paused). Because it sends a signal to a local process


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] RFC: Support for new type tuple v0.1

2013-01-27 Thread Martin


On 27/01/2013 14:42, Alexander Klenin wrote:

On Mon, Jan 28, 2013 at 1:26 AM, Paul Ishenin paul.ishe...@gmail.com wrote:

27.01.13, 1:43, Sven Barth wrote:

Based on the results of the for-in-index thread I've decided to come
up with a draft for the Tuple type which is thought by many people to be
a better alternative to for-in-index.

I think it is big overkill to implement a new base type for such a small
task as returning a key in for-in loop.

Of course. But note that in this thread, many more uses of tuples
(which I do NOT want to make a type -- see my previous mail for
lengthy explanation why).
Some of the uses are: record and array constructors, adaptation of
inconvenient signatures,
better support for return code style of error handling, etc.


If I understand this correct, the ability to return more than one value 
from a function (without out parm) is identical to using a record.

Except you do not want a type declaration for a record.

Therefore in this case tuple becomes an inline (lack of better word) 
declared record (match like you can declare an array outside a type 
section)
And since it has no named type, it is (other tan records) assignment 
compatible if it has the same declaration (same as 2 array of integer, 
only array can not hold different types)


So really here you would need an assignment compatible record (I do not 
say it is a good thing, but if the multi return case is addressed, it 
may be a better way than toupe)


type
  TFoo1 = compatible record  a: integer; b: string end;
  TFoo2 = compatible record  a: integer; b: string end;

function Bar: compatible record  a: integer; b: string end;

and variables/results of any of these are assignment compatible. 
(compatible record can be restricted to none variant records)




And (for Michael) I don't see any beauty in this. Imo, initial index
extension is much more beauty than suggested here (a,b,c) := d;
constructions.

I have a compromise suggestion:
Implement for-index extension with the syntax:
for (k, v) in a do

can be solved with records too?

The typeof(a) needs to declare the key values anyway (provide an 
iterator, or something)


So together with that, a named record (normal record as exists today) 
can be defined? Or am I missing something?



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] for-in-index loop

2013-01-25 Thread Martin Schreiber

On Friday 25 January 2013 09:07:27 Michael Van Canneyt wrote:

 Once more: simple is beautiful.

 Free pascal becomes less so with each of these features.

Agreed. I even would say it becomes more by removing some of the 
existing features. ;-)

Martin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] dwarf for array [ 0..191] of

2013-01-20 Thread Martin


On 20/01/2013 18:50, Jonas Maebe wrote:
It looks like a gdb issue (from dwarfdump; readelf -g can show similar 
information):





Ah yes. objdump does that on win too.

Thanks.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] dwarf for array [ 0..191] of

2013-01-19 Thread Martin


Since I don't know the fpc cdoebase, I can not check this myself.

I suspect it is a gdb issue. But if it is not to much work, maybe 
someone who does know fpc dwarf generation can check that it is not fpc?


I got the following source:
type  TFoo = array [0..191] of integer;

and in gdb
  ptype TFoo

Using dwarf, up to gdb 7.2 (inclusive) the result is ok.

but 7.3 up reports
array [0..-65] of LONGINT

SO definitely something changed in GDB.
But I do not know if the old or new gdb is right.

-
So my guess is fpc declares the index as byte sized type.

If someone can confirm this, and that fpc declares it as unsigned in the 
dwarf info, then it is a gdb issue.



Thanks

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Inline methods

2013-01-16 Thread Martin


On 16/01/2013 13:06, Ludo Brands wrote:
 Perhaps a Hint or Warning when inline is used in the declaration 
could avoid these mistakes.


+1 for a hint in those cases.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Do bitwise operation (1 or 2) acre about the sign ? (Giving sign related hints on compilation)

2013-01-14 Thread Martin

Having recently asked about and learned that it is mainly a hint about 
performance. I have now another question about this hint:
  project1.lpr(6,9) Hint: Mixing signed expressions and longwords gives 
a 64bit result


Actually not so much about the hint, as about the fact that in the below 
example fpc extends the operands to 64 bits.


program Project1;
var
  x: cardinal;
  i, j: integer;
begin
  i:= x or j
end.

I understand the need for a 64 bit operation for +/-///*/...

But the or operator works bitwise, it does not treat the operands as 
numbers which could either be signed or unsigned? Or does it? If it does 
not, why does it need to use 64 bit?

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Do bitwise operation (1 or 2) acre about the sign ? (Giving sign related hints on compilation)

2013-01-14 Thread Martin


On 14/01/2013 13:54, ik wrote:

On Mon, Jan 14, 2013 at 3:11 PM, Martin laza...@mfriebe.de wrote:

Actually not so much about the hint, as about the fact that in the below
example fpc extends the operands to 64 bits.

program Project1;
var
   x: cardinal;
   i, j: integer;
begin
   i:= x or j
end.

i is an integer type, and you try to assign it a number that might
have 64 bit value.
It might overflow the memory itself.



That is not it.

program Project1;
var
  x: cardinal;
  j: integer;
  i: qword; // int64;
begin
  i:= x or j
end.

Happens too, if the left site is int64 or qword.

I understand, the hint is about the fact that doing 64 bit calculations 
on 32 bit are more expensive. But that was not my question.


Why does  signed_32bit or unsigned_32bit  need to be extended and 
calculated in 64 bit? or operates on a set of bits. Afaik for the or 
statement, there is no diff in signed/unsigned?


-
BTW, the thin text should really be changed. It is (from what I can see 
/ was told) not at all about the result. It is about the operation.
e.g in if signed32  unsigned32 then there is a boolean result (Which 
I do not think will be a 64 bit bool?). So saying a 64 bit result 
appears actually wrong.


   Hint: Mixing signed expressions and longwords will use 64bit operations

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Do bitwise operation (1 or 2) acre about the sign ? (Giving sign related hints on compilation)

2013-01-14 Thread Martin


On 14/01/2013 14:10, Jonas Maebe wrote:
That said, the compiler contains an optimization pass that tries to 
remove 64 bit widenings on 32 bit platforms in case it turns out they 
were not necessary. It will also catch the above example and the 
generated code will only contain a 32 bit operations. Semantically, 
the result of that expression remains 64 bit though.


So I am right about the 64 bits not needed.
And the hint is simply because the compiler (for keeping it simple) will 
first extend *all* mixed signed/unsigned to 64 bit (even if not needed 
in the end).

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Do bitwise operation (1 or 2) acre about the sign ? (Giving sign related hints on compilation)

2013-01-14 Thread Martin


On 14/01/2013 15:27, Hans-Peter Diettrich wrote:

Martin schrieb:

On 14/01/2013 13:54, ik wrote:

On Mon, Jan 14, 2013 at 3:11 PM, Martin laza...@mfriebe.de wrote:
Actually not so much about the hint, as about the fact that in the 
below

example fpc extends the operands to 64 bits.

program Project1;
var
   x: cardinal;
   i, j: integer;
begin
   i:= x or j
end.

i is an integer type, and you try to assign it a number that might
have 64 bit value.
It might overflow the memory itself.



That is not it.

program Project1;
var
  x: cardinal;
  j: integer;
  i: qword; // int64;
begin
  i:= x or j
end.

Happens too, if the left site is int64 or qword.

I understand, the hint is about the fact that doing 64 bit 
calculations on 32 bit are more expensive. But that was not my question.


Why does  signed_32bit or unsigned_32bit  need to be extended and 
calculated in 64 bit? or operates on a set of bits. Afaik for the 
or statement, there is no diff in signed/unsigned?


During above calculation (or) a sign extension is required because 
the result *must* have a definite sign. Else a following comparison of 
e.g. (x or j)0 could not determine a result.


This is casting a set of bits (neither signed, nor unsigned - a set is 
not a number at all) into a number. This only needs to have a 
definition, if it should cast to signed or unsigned type.


Extending it, and then using the 64 bit result will mean that, the sign 
will be excluded from the or operation. This is not expected at all. 
The sign is stored in one of the bits (and part of the set of bits), in 
should be affected.

Here in an example
   signed($8001)  OR unsigned($8002)
will be extended to
   signed($8001)  OR signed($8002)
the sign is now present in the to pupper dword / for the unsigned value 
this is empty. Therefore the sign is simply copied from the signed 
value, without being ever affected by the or itself.


The operation could be done with 32 bit
set_of_bits := s32 or u32;

and if you do
   set_of_bits  int
   set_of_bits + int
or anything then set_of_bits must be cast to an int type. It needs to be 
defined if that should cast in to signed or unsigned.






___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Do bitwise operation (1 or 2) acre about the sign ? (Giving sign related hints on compilation)

2013-01-14 Thread Martin


On 14/01/2013 15:52, Jonas Maebe wrote:


On 14 Jan 2013, at 16:44, Martin wrote:

This is casting a set of bits (neither signed, nor unsigned - a set 
is not a number at all) into a number. This only needs to have a 
definition, if it should cast to signed or unsigned type.


It has to be signed, because otherwise any negative number in the 
operation would trigger a range check error when it gets converted to 
a (larger) unsigned type. The nature of the operation that is used 
afterwards is irrelevant, range checking always operates in exactly 
the same way when performing a type conversion from one type to 
another. This is required to have predictable behaviour in a 
programming language.




not sure if I follow. If or performs on a set of bits (rather than a 
number), and a set (not being a number) is neither signed or unsigned, 
then before the OR both operands (independent of being signed or not) 
will be cast to a set. The result is a set. The set can be converted to 
either signed or unsigned. The set has no range checking.


  result := bit_set32(a) or bit_set32(b)

If result has also 32 (or more) bits, then no range check error can 
occur. In the set, the high-bit has no meaning. It is neither part of 
the (unsigned positive) numer, nor is it sign indicator. This meaning is 
only applied by casting it to a numeric type.


Same as
var i: set of (b0, b1, b2  b31);
signed := integer(i);
unsigned := cardinal(i);


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] String handling in trunk (was utf8 in 2.6.0)

On Saturday 05 January 2013 11:30:42 Jonas Maebe wrote:
[...]

 For example, I said that basically nothing changed in 2.7.x compared to
 2.6.x, except that certain string constants are no longer automatically
 converted to utf-16 at compile time, and then you ask Or should we not
 touch the theme strings and FPC anymore?. Since basically nothing changed
 except for a few less blind auto-conversions at compile time, why should
 you no longer be able to touch anything anymore?

 Let me repeat: your string constants will be parsed by the compiler into
 character sequences with exactly the same content in both 2.6.x and 2.7.x
 (and with content I mean that if they would be converted to the same code
 page in 2.6.x and in 2.7.x, you would end up with exactly the same binary
 data). Whether or not they contain character literals whose value is #127
 in the source code's code page, or explicit #xx, #xxx etc expressions
 has no influence, nothing changed in the compiler in that account.

 The *only* difference is that the compiler can now internally represent
 ansistrings with arbitrary code pages, and as a result the aforementioned
 character sequences may now be stored internally in the compiler in a
 different format, and also stored in the program in a different format if
 that can avoid conversions at run time. In particular, character sequences
 are no longer all converted immediately/by default/under all circumstances
 to UTF-16 in case characters #127 need to be interpreted according to a
 particular code page (i.e., if a {$codepage xxx} directive is present).

 The compiler will now only convert such character sequences to UTF-16,
 still at compile time (just like it was able to do in 2.6.x), if it is
 actually assigned to an UTF-16-encoded string, passed to an UTF-16
 parameter etc. And the compiler will also convert it to another ansistring
 code page is case the character sequence appeared in e.g. a file with
 {$codepage utf-8} and is then assigned to a variable whose type is declared
 as type ansistring(850).

Thank you very much for the detailed explanation. What I could not found in 
all the answers (probably it is my ignorance of the English language), is, 
does #n mean a utf16 code unit as in Delphi XE3 or does it denote something 
other? You write:

 Whether or not they contain character literals whose value is #127
 in the source code's code page, or explicit #xx, #xxx etc expressions
 has no influence, nothing changed in the compiler in that account.

Assume {$codepage utf-8} how should we enter Russian character constants in #n 
form? How should we enter Russian character constants in #n form if 
{$codepage 8859-5} is defined?
And again, sorry for the impertinence, how do resource strings fit in the 
string handling scenario of Free Pascal trunk?

Martin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] utf8 in 2.6.0

On Saturday 05 January 2013 11:42:29 Sven Barth wrote:
 On 05.01.2013 11:30, Jonas Maebe wrote:
  For example, I said that basically nothing changed in 2.7.x compared to
  2.6.x, except that certain string constants are no longer automatically
  converted to utf-16 at compile time, and then you ask Or should we not
  touch the theme strings and FPC anymore?. Since basically nothing
  changed except for a few less blind auto-conversions at compile time, why
  should you no longer be able to touch anything anymore?

 I think it was more meant in the context of the mailing list instead of
 a technical context. Like in we had this topic a thousand times and
 maybe it's better we shut up about it now before we get moderated.

Correct. :-)

Martin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] String handling in trunk (was utf8 in 2.6.0)

On Saturday 05 January 2013 12:28:03 Jonas Maebe wrote:

 Alternatively, in both cases you can instead define a
 unicodestring/widestring constant instead of an ansistring/shortstring
 constant by embedding widechar constants in the character sequence. Such
 widechar constants are of the form #number with number a valid Pascal
 representation of an integer constant between 255 and 65535. Then you can
 use those widechars to represent the desired characters as UTF-16 code
 points. In that case, the entire string will however be parsed as a
 sequence of UTF-16 code points (because a string is either a sequence of
 ansichars, or a sequence of widechars; it can never be a mixture of the
 two), and hence also #1 or #128 appearing in a widestring will be parsed as
 widechar(#1) and widechar(#128) as opposed to being interpreted according
 to the current codepage setting.

So compiled with -Fcutf8

unicodestringvar:= 'Best'#228'tigung';

produces a different result on fixes_2_6 and trunk? I assume in trunk there 
will be a compile error? We use this form of character constants in MSEgui to 
have the sources in pure ASCII.

Martin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] utf8 in 2.6.0

On Saturday 05 January 2013 12:39:21 Jonas Maebe wrote:

 Then maybe I should just stop completely answering any questions about
 this, because apparently not answering completely enough to your liking
 gets interpreted as telling you to shut up or getting moderated. Just like
 Sven I don't understand where this interpretation comes from, and I
 strongly resent it. I didn't answer because I thought the information was
 all in my previous answers already, and if someone else felt they could
 clarify it better than I did, they were free to do so.

 My time is also finite, and trying to get me to elaborate further by
 getting my on my high horse because I feel I'm being misrepresented, is
 something that will not work very well in the long term. It will much more
 likely result in silence than in more help.

No, no, you understand me wrong. I am merely cautious not to annoy the FPC 
team, please accept my apology, but I need to decide if FPC is still the 
right tool for my purposes.

Martin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] utf8 in 2.6.0

On Saturday 05 January 2013 13:01:44 Michael Van Canneyt wrote:

 Seeing that you have already invested lots of time in FPC, you could also
 ask yourself

 'How can I help improve fpc so it remains the right tool for my purposes' ?

 Or have you decided that cooperation with the FPC team is an impossibility
 ?

It is not easy mainly because the mission goal is so broad. And a division of 
work probably would be the better solution. I make my job to build a highly 
productive open source development environment for Free Pascal and the FPC 
team makes a compiler which allows to build such a tool.
But now we are off topic.

Martin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] String handling in trunk (was utf8 in 2.6.0)

On Saturday 05 January 2013 12:57:44 Jonas Maebe wrote:
 On 05 Jan 2013, at 12:53, Martin Schreiber wrote:
  So compiled with -Fcutf8
  
  unicodestringvar:= 'Best'#228'tigung';
  
  produces a different result on fixes_2_6 and trunk? I assume in trunk
  there will be a compile error?

 No. In both cases it results in a widestring with this content:

 .short66,101,115,116,228,116,105,103,117,110,103,0

 I guess invalid utf-8 values are just copied through by the compiler. As
 mentioned: absolutely nothing whatsoever changed in how character sequences
 are interpreted by the compiler in 2.7.x. The explanation you quoted above
 (and which I deleted) applies to both 2.6.x and 2.7.x. I really don't know
 how I can say this in another way, and repeating it clearly doesn't help.

 I think it's best if you compile trunk for yourself and test as many
 scenarios as you can, because I feel I cannot add anything further to the
 discussion, and I'm not interested in playing compile bot.

Then it was a misunderstanding again because I read

Alternatively, in both cases you can instead define a unicodestring/widestring 
constant instead of an ansistring/shortstring constant by embedding widechar 
constants in the character sequence. Such widechar constants are of the form 
#number with number a valid Pascal representation of an integer constant 
between 255 and 65535.

and

Whether or not they contain character literals whose value is #127 in the 
source code's code page, or explicit #xx, #xxx etc expressions has no 
influence, nothing changed in the compiler in that account.

and

I have no idea how anything I wrote suggests that it wouldn't. As mentioned, 
the only difference is that string constants containing characters #127 are 
no longer always converted to unicodestring constants at compile time.

-- #255  #127 and the question arose how can one define widechar 
constants for strings without a character value 255.

Martin

Martin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] utf8 in 2.6.0

2013-01-01 Thread Martin


On 01/01/2013 13:18, Jonas Maebe wrote:

On 15 Dec 2012, at 19:35, Martin wrote:


I am trying to figure out how to do that, or what I do wrong. I found a page 
about $codepage, but it did not help 
http://wiki.freepascal.org/LCL_Unicode_Support
I didnt find the fpc specific page, if exists (I suspect it does)


I am calling a function function Foo(A:string) {$mode objfpc}{$H+}
I call it with a constant, that contains an german umlaut. Checked with a hex 
editor, the constant in the source file is utf8

- If I save the source (in utf8), without a utf8 BOM, then it works fine on 
windows.
- If I had a bom, then the string received by the function appears to be ascii (checked 
memory dump in debugger oe becomes d6
- if I add {$codepage utf8} it also becomes ascii

If I do *not* add that, it seems something gos wrong with the encoding on a 
PowerPC Mac. Unfortunately this is someone else's pc, and I have no more info.
If I add it things also go wrong, only different. Again no more info.

---

I know the provided info, is very little.

There is not enough information to be able to give an answer. Source code, 
source code, source code.



Problem is, the original issue does not happen on my hardware.
It is about an issue with the test case in components/EditorMacroScript. 
But only happens on powerPC hardware.
I only have/had an extract of the results. From the looks ofwhat went 
wrong, and what was the output (calculating char positions) utf8 coding 
was/is a strong suspect (not confirmed though.


On my hardware it is normally all fine, but fails if I add the 
$codepage. I could spent a lot of work boiling that down to a sample. 
But given that I couldn't even find the docs what I really should 
expect, and therefore might be doing something wrong, I thought I go 
first looking for what should happen.


Add {$codepage utf8}
on top of
  lazarus\components\macroscript\test\testscriptprocs.pas

and the behaviour changes so that the test will fail. (there are utf8 
constants in the source, and it appears, that with the $codepage the 
called code does NOT get that utf8 string, but something else instead.








___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] utf8 in 2.6.0

2013-01-01 Thread Martin

On 01/01/2013 14:24, Jonas Maebe wrote:

On 01 Jan 2013, at 15:14, Martin wrote:

On my hardware it is normally all fine, but fails if I add the $codepage. I
could spent a lot of work boiling that down to a sample. But given that I
couldn't even find the docs what I really should expect,

Without a {$codepage xxx} directive, string constants containing characters
#127 remain exactly as they appear in the source code.

With a {$codepage xxx} directive, string constants containing characters #127 are
converted into unicodestrings during the parsing (according to the specified code page), and
converted back into ansistrings (using the ansi code page of that particular
program run) at run time if they are assigned to ansistring/shortstrings or passed to
routines expecting such parameters.

Note that the above is for 2.6.x (as the subject mentions).

ok, leaves me with my original problem.

On said ppc, using the original file (no codepage directive). file
should be identical (svn checkout) (yet on 2nd thought I can't be sure,
that it wasn't open in an editor and saved with utf8 bom...).

So on that ppc something goes wrong. From the feedback I had, it looks
exactly as if the encoding of the constant was changed. So what I was
looking for was a way to 100% prevent that. Something that tells the
compiler: Whatever encoding you find or expect or whatever encoding the
output should be, do not touch strings. just take them byte by byte.

Does that exist?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] utf8 in 2.6.0

On Tuesday 01 January 2013 15:24:05 Jonas Maebe wrote:
 On 01 Jan 2013, at 15:14, Martin wrote:
  On my hardware it is normally all fine, but fails if I add the $codepage.
  I could spent a lot of work boiling that down to a sample. But given that
  I couldn't even find the docs what I really should expect,

 Without a {$codepage xxx} directive, string constants containing characters
  #127 remain exactly as they appear in the source code.

 With a {$codepage xxx} directive, string constants containing characters 
 #127 are converted into unicodestrings during the parsing (according to the
 specified code page), and converted back into ansistrings (using the ansi
 code page of that particular program run) at run time if they are assigned
 to ansistring/shortstrings or passed to routines expecting such parameters.

 Note that the above is for 2.6.x (as the subject mentions).

How does it work in trunk?

Martin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] utf8 in 2.6.0

On Tuesday 01 January 2013 16:44:28 Jonas Maebe wrote:
 On 01 Jan 2013, at 16:31, Martin Schreiber wrote:
  On Tuesday 01 January 2013 15:24:05 Jonas Maebe wrote:
  Without a {$codepage xxx} directive, string constants containing
  characters
 
  #127 remain exactly as they appear in the source code.
 
  With a {$codepage xxx} directive, string constants containing characters
   #127 are converted into unicodestrings during the parsing (according
  to the specified code page), and converted back into ansistrings (using
  the ansi code page of that particular program run) at run time if they
  are assigned to ansistring/shortstrings or passed to routines expecting
  such parameters.
 
  Note that the above is for 2.6.x (as the subject mentions).
 
  How does it work in trunk?

 The strings are stored as ansistrings with the appropriate code page.

So 

UnicodeStringVariable:= 'abcdäüö';

always will call a conversion function?

Martin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] utf8 in 2.6.0

On Tuesday 01 January 2013 16:54:21 Martin Schreiber wrote:
 So
 
 UnicodeStringVariable:= 'abcdäüö';
 
 always will call a conversion function?

And how works

{$codepage 8859-1}
...
 UnicodeStringVar:= 'abcd'#228#246#252#1092#1080#1089#1074;


?
Martin


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] utf8 in 2.6.0

Thanks, another question, or is the behavior already documented?

  UnicodeStringVar:= 'abcd'#228#246#252#1092#1080#1089#1074;
 
  
  ?

 That string contains codepoints  #255 and hence is a unicodestring rather
 than a single byte string. No conversion at either compile or run time
 happens, and the codepage directive has no influence.

 {$codepage utf8}
 ...
UnicodeStringVar:= 'abcd'#228#252#246;

Does it store 'abcdäüö' in trunk?

Martin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] utf8 in 2.6.0