Re: [fpc-pascal] csLoading
On Wednesday 09 July 2008 23.24:31 Vincent Snijders wrote: Hi, This is sequel to this thread of almost two years ago: http://lists.freepascal.org/lists/fpc-devel/2006-September/008737.html Some things changed (e.g. TComponent.Loading has been added), but I stil did not find an easy way to fix lazarus bug 7305. Looking at TReader.ReadComponent I have two questions: First, why is for inline components csLoading set before the constructor is called and why for other components after the constructor is called. Having csLoading set before the constructor would help me to decide to set the default values for the collection or not. You could check csLoading of the AOwner parameter. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] csLoading
Martin Schreiber schreef: On Wednesday 09 July 2008 23.24:31 Vincent Snijders wrote: Hi, This is sequel to this thread of almost two years ago: http://lists.freepascal.org/lists/fpc-devel/2006-September/008737.html Some things changed (e.g. TComponent.Loading has been added), but I stil did not find an easy way to fix lazarus bug 7305. Looking at TReader.ReadComponent I have two questions: First, why is for inline components csLoading set before the constructor is called and why for other components after the constructor is called. Having csLoading set before the constructor would help me to decide to set the default values for the collection or not. You could check csLoading of the AOwner parameter. Thanks. That is a good suggestion. I'll use it if nothing better comes up. Vincent ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] {$R file} support on non-Windows targets
On Wed, Jul 9, 2008 at 8:17 PM, Giulio Bernardi [EMAIL PROTECTED] wrote: So I assume we have a cross-platform resource compiler now, so is windres unnecessary? Was pre-processing also implemented? No. To compile .rc files to .res you still need windres. In general you can compile and run it fine on little endian machines, but it doesn't work (at least, it didn't work 6 months ago, don't know if newer versions are endian safe) on big endian machines. So is that the technical issue with cross-platform resource compilers? The endian handling? Or is there some other technical issue? I remember even Kylix didn't have a resource compiler and couldn't understand why. After all, most C/C++ compilers are cross platform and they seem to have resource compilers, so what is wrong with Object Pascal compilers... Sorry if this is dumb, but I obviously don't understand the full issue here... Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] {$R file} support on non-Windows targets
Graeme Geldenhuys ha scritto: On Wed, Jul 9, 2008 at 8:17 PM, Giulio Bernardi [EMAIL PROTECTED] wrote: So I assume we have a cross-platform resource compiler now, so is windres unnecessary? Was pre-processing also implemented? No. To compile .rc files to .res you still need windres. In general you can compile and run it fine on little endian machines, but it doesn't work (at least, it didn't work 6 months ago, don't know if newer versions are endian safe) on big endian machines. So is that the technical issue with cross-platform resource compilers? The endian handling? Or is there some other technical issue? I remember even Kylix didn't have a resource compiler and couldn't understand why. After all, most C/C++ compilers are cross platform and they seem to have resource compilers, so what is wrong with Object Pascal compilers... Sorry if this is dumb, but I obviously don't understand the full issue here... The concept of resources is a bit vague when talking about different platforms. Some systems have this concept, some no, and they are all different things, though the basic thing that they provide is a way to embed data in applications. E.g. windows has it's own definition of resources, classic Mac OS another, Mac OS X another, OS/2 another one, Unix doesn't have resources, and so on. So a cross platform resource compiler is not common because there isn't a standardized resource format. In 2.3.1 we support resources the windows way on non-windows systems: the 2.3.1 fpcres is able to convert .res files to object files which will be linked in your application. However we don't have a resource compiler yet (a compiler that is able to compile .rc files to .res files). There is gnu windres though which is able to do this work. Windres can also be compiled on Linux (and on other unixes I think). However, windres isn't endian safe so it's useless on big endian machines: maybe they never thought about the possibility of crosscompilation from, say, linux powerpc to win32. You can of course embed already made .res files, since the 2.3.1 fpcres is endian safe. And it can also compile dfm/lfm/xfm files. Regarding the fact that most C/C++ compilers have resource compilers... well in general OS vendors provide resource compilers if their system have this concept (rc.exe from microsoft, ReZ from Apple). Moreover some compiler vendor provide their own (brcc32 from borland, wrc from watcom, gorc), but they are not cross platform, even if wrc is able to compile win32, win16 and os2 resource files for those systems. Giulio ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] csLoading
Vincent Snijders schreef: Martin Schreiber schreef: You could check csLoading of the AOwner parameter. Thanks. That is a good suggestion. I'll use it if nothing better comes up. This was simple enough. I used it in r15730 of Lazarus. Thanks. Vincent ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] {$R file} support on non-Windows targets
On Thu, Jul 10, 2008 at 9:13 AM, Giulio Bernardi [EMAIL PROTECTED] wrote: vendor provide their own (brcc32 from borland, wrc from watcom, gorc), but they are not cross platform, even if wrc is able to compile win32, win16 and os2 resource files for those systems. You stole my example! :-) I was just about to mention Watcom's resource compiler. If it works for Win32, Win16 and OS/2, how can it not be cross-platform? Or do you mean not cross-platform, because a .res file compiled under OS/2 cannot be used as-is under Win32? If the latter, would that really be an issue for FPC with a slogan like write once, compile everywhere. As long as the application is compiled on the platform it needs to run on, the resource will be correct. This excludes cross-compiling, no idea how that works. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] {$R file} support on non-Windows targets
Graeme Geldenhuys ha scritto:
On Thu, Jul 10, 2008 at 9:13 AM, Giulio Bernardi [EMAIL PROTECTED] wrote:
vendor provide their own (brcc32 from borland, wrc from watcom, gorc), but
they are not cross platform, even if wrc is able to compile win32, win16
and os2 resource files for those systems.
You stole my example! :-) I was just about to mention Watcom's
resource compiler. If it works for Win32, Win16 and OS/2, how can it
not be cross-platform? Or do you mean not cross-platform, because a
.res file compiled under OS/2 cannot be used as-is under Win32?
Exactly. E.g. OS/2's .res format is like the win16 one but without
support for string IDs (that is, you can't have a os/2 resource named
'MYFORM'). Moreover they have little syntax differences here and there.
For what regards wrc, it's simple: you tell wrc you want to compile a
win32 rc file, and it will output a win32 .res file. If you tell it to
use win16 format, .rc file must use that syntax and it will be compiled
as a win16 resource.
So you can't use wrc to compile a win32 rc file to a os2 res file: it's
like to have three separate resource compilers in one.
If
the latter, would that really be an issue for FPC with a slogan like
write once, compile everywhere. As long as the application is
compiled on the platform it needs to run on, the resource will be
correct. This excludes cross-compiling, no idea how that works.
The idea is that we support win32 resources everywhere, since the {$R}
stuff comes from delphi, where it's used for win32 resources.
At the moment, winlike resources aren't supported on os/2 or classic mac
os because one might want to use their platform-specific resources. One
idea I have is to add something like {$resmode native/win32} (example
case: lazarus starts using resources, someone decides to port lazarus to
os/2, we have a problem. With the switch a program could contain both
win32 resources used by lazarus and os2 resources like the program icon
and so on).
Giulio
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Performance issue with dynamic arrays
Volker Zipfel schrieb: Hi all! While analyzing my project with valgrind, I discovered that almost a quarter of the cpu cycle where eaten up by the function fpc_finalize_array. It seams that fpc_finalize_array calls for every element of the array fpc_finalize. To illustrate the problem i have written to small test programs: Thanks, applied a slightly modified patch which might not break if new tk* constants are added. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] assigning a local function to a var
Thanks Lourival, Joao, Chris, for your responses.
It looks like what I'm attempting is not possible. FWIW, I've included a
more illustrative example at the end of this message.
Thus, I would ask of the devs, has this functionality been considered?
Is there some particular reason that anyone is opposed to implementing
it? Or is it just difficult to implement, and/or not considered useful?
There is a part of me that wants to jump in and try to implement this in
the compiler, although I suspect I would be in well over my head.
Before I consider making such an attempt (or looking for someone to do
it) it'd be nice to get a feeling for whether such an extension would
be welcome.
I am hard-pressed to detect any drawback or conflict, although of course
that's largely because I have no idea how this stuff is actually
implemented.
Lourival wrote some code which included:
var
my_func : TProcedure;
begin
my_func:= TProcedure(@func_a);
my_func('hello, ');
end
Lourival: while your suggestion to typecast the local function to
TProcedure did compile and run, the procedure is no longer local!
Thus the parent function's variables are no longer in scope, which was
the principal reason to use a local function. I neglected to include
that in my original example, so I rewrote the example below.
Chris: It seems like you're saying what I want to do is impossible.
Thanks for pointing out that citation in the reference manual. It would
be nice to hear a more definitive answer, though :) For now, I've made
the functions external, which unfortunately requires passing many
(local) parameters to them, within a loop that should go fast. :(
Chris wrote, among other things:
This is for a reason - think what would happen if you were able to
assign a local procedure to a global variable!
Perhaps my subject line should have read assigning a local function to
a LOCAL var -- that is, after all, what I'm after. ((Just because it's
possible to do something stupid with a feature, doesn't mean the
feature is a bad idea: I can think of all sorts of stupid/absurd things
to do with pointers, which compile without hint or warning.))
Joao: creating a named type isn't a solution, as it only moves the
problem of declaration into the type section, where the very same
problem persists. Thanks for responding, though.
On Wednesday 09 July 2008 9:31 am, David Emerson wrote:
I'd like to store an address of a local function in a variable, and
call that local function, but I don't know how to define a variable of
type local function.
Here's a revised version that better illustrates the need:
test.pas(20,14) Error: Incompatible types:
got address of local procedure;Register
expected procedure variable type of procedure;Register
procedure test;
var
what_to_say : ansistring;
procedure proc_a;
begin
writeln ('A says, ', what_to_say, '');
end;
procedure proc_b;
begin
writeln ('B says, ', what_to_say, '');
end;
var
my_proc : procedure; // need to specify local. impossible?
begin
what_to_say := 'hello, world!';
my_proc := @proc_a; // won't compile! proc_a is local.
my_proc();
end;
Cheers,
~David.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] assigning a local function to a var
David Emerson wrote:
Joao: creating a named type isn't a solution, as it only moves the
problem of declaration into the type section, where the very same
problem persists. Thanks for responding, though.
Did you test? I did and it works.
==
function func_a(pass_str: ansistring): boolean;
begin
writeln(pass_str, ' A');
func_a := true;
end;
function func_b(pass_str: ansistring): boolean;
begin
writeln(pass_str, ' B');
func_b := false;
end;
type
tmy_fnc = function(pass_str: ansistring): boolean;
var
my_fnc: tmy_fnc;
begin
my_fnc := @func_a;
my_fnc('hello');
end.
==
Joao Morais
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] assigning a local function to a var
Hi Joao,
You're missing the point -- those functions, func_a and func_b, should
be embedded within another function. The behavior I would like to see
concerns local functions, not global functions. In your executable,
func_a and func_b are global functions (within the unit) not local
functions (embedded within another function).
As a sidenote, the type declaration is still superfluous -- when dealing
with global functions, the following will work equally well:
var my_fnc: function(pass_str: ansistring): boolean;
(Although I'm not sure if there might be compiler switches that would
enable/disable this functionality, possibly requiring the type
definition. My fpc.cfg may have something enabled that yours doesn't.)
At any rate, global functions work fine, with or without the type
definition. The reason I posted was to ask about local functions.
~David.
On Thursday 10 July 2008 12:33 pm, Joao Morais wrote:
David Emerson wrote:
Joao: creating a named type isn't a solution, as it only moves the
problem of declaration into the type section, where the very same
problem persists. Thanks for responding, though.
Did you test? I did and it works.
==
procedure parent_procedure;
var parent_var_available_to_local_functions; // ;)
function func_a(pass_str: ansistring): boolean;
begin
writeln(pass_str, ' A');
func_a := true;
end;
function func_b(pass_str: ansistring): boolean;
begin
writeln(pass_str, ' B');
func_b := false;
end;
type
tmy_fnc = function(pass_str: ansistring): boolean;
var
my_fnc: tmy_fnc;
// my_fnc : function(str:ansistring):boolean; // works equally well
begin
my_fnc := @func_a;
my_fnc('hello');
end.
// this is a procedure, so 'end' should be followed by a semicolon,
// not a period.
==
Joao Morais
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] assigning a local function to a var
David Emerson wrote: You're missing the point -- those functions, func_a and func_b, should be embedded within another function. The behavior I would like to see concerns local functions, not global functions. In your executable, func_a and func_b are global functions (within the unit) not local functions (embedded within another function). Aff... indeed. Sorry. Local procedures and functions are really unsupported because of stack and local variable issues afaik. Delphi has this same limitation. Joao Morais ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] assigning a local function to a var
Dear David,
Sorry for my question, probably I didn't get the real idea of what
you need, but I didn't see why the revised version didn't work.
Actually, I would write it like:
procedure test;
var
what_to_say : ansistring;
procedure proc_a;
begin
writeln ('A says, ', what_to_say, '');
end;
procedure proc_b;
begin
writeln ('B says, ', what_to_say, '');
end;
var
// my_proc : procedure; // need to specify local. impossible?
my_proc : TProcedure; // Lourival
begin
what_to_say := 'hello, world!';
// Lourival Begin
my_proc:= nil;
if not Assigned(my_proc) then begin
my_proc:= TProcedure(@proc_a);
my_proc ();
end
else .
// Lourival End
end;
Again I didn't test it, but I think that should work, shouldn't??
Lourival
2008/7/10, David Emerson [EMAIL PROTECTED]:
Thanks Lourival, Joao, Chris, for your responses.
It looks like what I'm attempting is not possible. FWIW, I've included a
more illustrative example at the end of this message.
Thus, I would ask of the devs, has this functionality been considered?
Is there some particular reason that anyone is opposed to implementing
it? Or is it just difficult to implement, and/or not considered useful?
There is a part of me that wants to jump in and try to implement this in
the compiler, although I suspect I would be in well over my head.
Before I consider making such an attempt (or looking for someone to do
it) it'd be nice to get a feeling for whether such an extension would
be welcome.
I am hard-pressed to detect any drawback or conflict, although of course
that's largely because I have no idea how this stuff is actually
implemented.
Lourival wrote some code which included:
var
my_func : TProcedure;
begin
my_func:= TProcedure(@func_a);
my_func('hello, ');
end
Lourival: while your suggestion to typecast the local function to
TProcedure did compile and run, the procedure is no longer local!
Thus the parent function's variables are no longer in scope, which was
the principal reason to use a local function. I neglected to include
that in my original example, so I rewrote the example below.
Chris: It seems like you're saying what I want to do is impossible.
Thanks for pointing out that citation in the reference manual. It would
be nice to hear a more definitive answer, though :) For now, I've made
the functions external, which unfortunately requires passing many
(local) parameters to them, within a loop that should go fast. :(
Chris wrote, among other things:
This is for a reason - think what would happen if you were able to
assign a local procedure to a global variable!
Perhaps my subject line should have read assigning a local function to
a LOCAL var -- that is, after all, what I'm after. ((Just because it's
possible to do something stupid with a feature, doesn't mean the
feature is a bad idea: I can think of all sorts of stupid/absurd things
to do with pointers, which compile without hint or warning.))
Joao: creating a named type isn't a solution, as it only moves the
problem of declaration into the type section, where the very same
problem persists. Thanks for responding, though.
On Wednesday 09 July 2008 9:31 am, David Emerson wrote:
I'd like to store an address of a local function in a variable, and
call that local function, but I don't know how to define a variable of
type local function.
Here's a revised version that better illustrates the need:
test.pas(20,14) Error: Incompatible types:
got address of local procedure;Register
expected procedure variable type of procedure;Register
procedure test;
var
what_to_say : ansistring;
procedure proc_a;
begin
writeln ('A says, ', what_to_say, '');
end;
procedure proc_b;
begin
writeln ('B says, ', what_to_say, '');
end;
var
my_proc : procedure; // need to specify local. impossible?
begin
what_to_say := 'hello, world!';
my_proc := @proc_a; // won't compile! proc_a is local.
my_proc();
end;
Cheers,
~David.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
--
Lourival J. Mendes Neto
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Webservice from .Net
Hi, 2008/7/9 [EMAIL PROTECTED] [EMAIL PROTECTED]: I build webservice app with .Net and connect to client app with fpc. I used wst unit. But i have problem with WSDL translate result using the Lazarus IDE. There is no parameter/function like wst samples. Can anyone help me? or give the tutorial step by step? Tq There is a Google group for WST at http://groups.google.com/group/wst-list Please post your question there. PS : Please be more specific. Best regards. -- Inoussa O. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] assigning a local function to a var
Thus, I would ask of the devs, has this functionality been considered? Yes. A solution for this problem is needed for Mac Pascal compatability. Is there some particular reason that anyone is opposed to implementing it? Not really I guess. Or is it just difficult to implement, and/or not considered useful? Useful, but a lot of work. There is a part of me that wants to jump in and try to implement this in the compiler, although I suspect I would be in well over my head. Well, my ideas about it were: - there must be a local directive that enables a procvar type declaration t to become a full procvar. (to switch between compatible and full). Maybe mac mode should turn this on by default. - The new full procvar type consists out of a framepointer and a procedure address. A two pointer record, like tmethod. - In case of a global procedure being assigned to the full procvar, the framepointer=nil. - In case of a local procedure being assigned to the full procvar, the framepointer is the parents framepointer. (the implict first argument) - Calling such localproc is of course only allowed from within the immediate parent of the local procedure, so that the frame exists. - When a procedure calls such a procedure, on asm level the code is roughly like this: if assigned(procvar.frameptr) then procvar.procaddress(procvar.frameptr,arg1,arg2,arg3..) else procvar.procaddress(arg1,arg2,arg3..) Of course this is just brainstorming. IIRC Jonas punched a few holes in it when I talked to him about it, but I can't remember what they were. Except a warning that the callnode code was complicated, due to the many ways a procedure/method can be called. (think directives, special rules for parameter order, hidden params, float params, small complex types etc) Before I consider making such an attempt (or looking for someone to do it) it'd be nice to get a feeling for whether such an extension would be welcome. It's on the roadmap for the mac dialect: http://wiki.freepascal.org/Mode_MacPas (Search for planned, it is the nested procedure parameters) item) I am hard-pressed to detect any drawback or conflict, although of course that's largely because I have no idea how this stuff is actually implemented. See above. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
