[fpc-pascal] Ical/.ics library?
Hi list, (Had posted this earlier on the forum) I'm looking at some day replacing some of my own utilities written using .net code with FPC code. One tool extracts birthdays from a database, slaps a reminder time on it and exports it as ical/.ics Some searching turned up http://sourceforge.net/projects/delphiical/ which I haven't looked at yet. Does anybody have experience with this? Any alternatives? Thanks, Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Result: string
El 06/03/2013 13:47, Jonas Maebe escribió:
2.6.0, 2.6.2 and 2.7.1 trunk produces a warning with that code, but
with this one 2.6.0, and 2.7.1 trunk does not generate it (I do not
have 2.6.2 to test):
That's because you are passing an uninitialized value to a
var-parameter. That only generates a hint, because a lot of code uses
var-parameters also for parameters that do not yet have to be
initialized (because the code predates the existence of the "out"
keyword, or simply out of habit).
This is unrelated to string results specifically.
Hello,
I had found why I was unable to see the hint, because it is not shown
due the special contruction of the function.
This code produces a hint for the "Result: String" not initialized, but
not for the "Result: integer" one:
--
program test;
{$mode objfpc}
{$h+}
procedure TheB(var aTheA: string);
begin
aTheA:=aTheA+'A';
end;
function TheA(): string;
begin
TheB(Result);
end;
procedure TheNumberB(var aTheB: integer);
begin
aTheB:=aTheB*2;
end;
function TheNumberA: integer;
procedure HideTheHint;
begin
//As it is a procedure the "Result" var is taken
//from the function scope.
TheNumberB(Result);
end;
begin
HideTheHint;
end;
Var
C : String;
N : integer;
begin
C:='B';
C:=TheA;
C:=TheA;
Writeln('= "',C,'"');
N:=1;
N:=TheNumberA;
N:=TheNumberA;
Writeln('= "',N,'"');
end.
---
Yes, it is a bit obfuscated. I do not known if this is a bug in the hint.
--
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Get error information
If you execute with TProcess, it's in... err... StdErr property. Otherwise, I have no idea. It would be dependant on how you execute... -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Get-error-information-tp5713366p5713399.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Text IDE, the displayed cursor position
Graeme Geldenhuys wrote: On 2013-03-01 14:03, Ebeling wrote: When I start a new program by clicking the button "new", the cursor stands in the upper left corner, but its position is displayed as "1:976". Just to confirm, I see the exact same thing under 64-bit FreeBSD using FPC 2.6.0 no problem with FPC 2.6.2 under (32-bit) Windows 98 ;-) Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Get variable name at runtime
In our previous episode, Darius Blaszyk said: > What > preprocessor do you use then, M4? Nearly always custom. With "general" I mean anything not part or integrated with the compiler, not necessarily a known product. The usage is now deceased and replaced by generics for the most. > I'm curious to find out how you use an external preprocessor. Basically I defined an own source type (template), and the generator created Pascal from that. The resulting code was compiled. > In principle it's not a bad idea to use an external one. I suggest we > could also make it a bit more user friendly by providing some hooks in > fpmake. This way one should not nescesarily create additional scripts to > copy files to other locations. What do you think? I think while not bad, this is premature. First usage of it (and reallife experiences), and only then adapt the infrastructure to it. But fpmake is easier customizable than the compiler of course. First we need sb willing to massively work on it though :-) > Please demonstrate how you use macro's in your perticular case. > How do you adjust your build system. Not. I simply manually ran a batchfile that generated the makefiles. I was too lazy to figure out msbuild for that (this was Delphi) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Get variable name at runtime
In our previous episode, Mark Morgan Lloyd said:
> I meant that in the context of FPC, which works out dependencies etc. on
> the fly, one can't arbitrarily hook in an external preprocessor. I meant
> that it wasn't another stage in a makefile because FPC doesn't (can't)
> use makefiles- for reasons that you explained yesterday.
That's technically impossible, since how the preprocessor influences
dependencies is not know to the compiler.
It is the same discussion as the make -j bit. If you want a C compiling
model, don't use units and use {$i} and manually link it together, like in C.
I prefer the unit model though.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Text IDE, the displayed cursor position
On 2013-03-01 14:03, Ebeling wrote: > When I start a new program by clicking the button "new", the cursor > stands in the upper left corner, but its position is displayed as > "1:976". Just to confirm, I see the exact same thing under 64-bit FreeBSD using FPC 2.6.0 > > When the cursor stays in the first column and only steps down, the > indicated column number is: > "976" in the lines 1 to 9 > "808" in line 10 > "825" in line 11 > "842" in line 12. I see this too. If I keep pressing ENTER, after line 10, I get all strange numbers. Some in the 800's and then again in the 900's, then back to the 800's etc. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Get variable name at runtime
Marco van de Voort wrote: In our previous episode, Mark Morgan Lloyd said: Unfortunately pascal macro's are rather limited compared to C. I know I know, you could potentially open up a can of worms, but sometimes more control is required. There is nothing restraining anybody using an external macro processor. It is just that we don't want to support it :-) Actually, I'd suggest that there is: the difficulty of integrating an external macro processor with the standard build process (i.e. it's not just another stage in a makefile). It is. Export all known sources to a new dir for the compiler through the preprocessor. I meant that in the context of FPC, which works out dependencies etc. on the fly, one can't arbitrarily hook in an external preprocessor. I meant that it wasn't another stage in a makefile because FPC doesn't (can't) use makefiles- for reasons that you explained yesterday. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Get variable name at runtime
On Wed, 6 Mar 2013, Marco van de Voort wrote: In our previous episode, Mark Morgan Lloyd said: Unfortunately pascal macro's are rather limited compared to C. I know I know, you could potentially open up a can of worms, but sometimes more control is required. There is nothing restraining anybody using an external macro processor. It is just that we don't want to support it :-) Actually, I'd suggest that there is: the difficulty of integrating an external macro processor with the standard build process (i.e. it's not just another stage in a makefile). It is. Export all known sources to a new dir for the compiler through the preprocessor. I've had to deal with colleagues in the past who thought it was entirely acceptable to make manual edits to compiler output (typically on Intel blue boxes) before running it through the assembler, and it's very high on my list of Thou Shalt Nots. General preprocessor usage is on mine. I use preprocessors and codegenerators all the time, and have no problem whatsoever with it. What I have a problem is, is to give that formal statement, so that future development on the compiler will be limited by it in all its gory glory. IMHO we should simply have a directive that is either cdecl or stdcall depending on the platform +1 I proposed libcall about 10 years ago - if not longer. OSCall or NativeCall. Whatever. Just not a macro. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Get variable name at runtime
Just found this project. Seems to be abandoned but might be interesting in the light of Marco's reply; http://code.google.com/p/metapascal/ [1] Links: -- [1] http://code.google.com/p/metapascal/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Get variable name at runtime
mar...@stack.nl schreef op 6 mrt '13: > In our previous episode, Mark Morgan Lloyd said: > Unfortunately pascal macro's are rather limited compared to C. I know I know, you could potentially open up a can of worms, but sometimes more control is required. >>> There is nothing restraining anybody using an external macro processor. It is just that we don't want to support it :-) >> Actually, I'd suggest that there is: the difficulty of integrating an external macro processor with the standard build process (i.e. it's not just another stage in a makefile). > > It is. Export all known sources to a new dir for the compiler through the > preprocessor. > >> I've had to deal with colleagues in the past who thought it was entirely acceptable to make manual edits to compiler output (typically on Intel blue boxes) before running it through the assembler, and it's very high on my list of Thou Shalt Nots. > > General preprocessor usage is on mine. I use preprocessors and > codegenerators all the time, and have no problem whatsoever with it. > > What I have a problem is, is to give that formal statement, so that future > development on the compiler will be limited by it in all its gory glory. > > IMHO we should simply have a directive that is either cdecl or stdcall > depending on the platform, and kill even the current macro support. > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal [1] What preprocessor do you use then, M4? I'm curious to find out how you use an external preprocessor. In principle it's not a bad idea to use an external one. I suggest we could also make it a bit more user friendly by providing some hooks in fpmake. This way one should not nescesarily create additional scripts to copy files to other locations. What do you think? Please demonstrate how you use macro's in your perticular case. How do you adjust your build system. Links: -- [1] 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] Get variable name at runtime
In our previous episode, Mark Morgan Lloyd said: > >> Unfortunately pascal macro's are rather limited compared to C. I know I > >> know, you could potentially open up a can of worms, but sometimes more > >> control is required. > > > > There is nothing restraining anybody using an external macro processor. It > > is just that we don't want to support it :-) > > Actually, I'd suggest that there is: the difficulty of integrating an > external macro processor with the standard build process (i.e. it's not > just another stage in a makefile). It is. Export all known sources to a new dir for the compiler through the preprocessor. > I've had to deal with colleagues in the past who thought it was entirely > acceptable to make manual edits to compiler output (typically on Intel > blue boxes) before running it through the assembler, and it's very high > on my list of Thou Shalt Nots. General preprocessor usage is on mine. I use preprocessors and codegenerators all the time, and have no problem whatsoever with it. What I have a problem is, is to give that formal statement, so that future development on the compiler will be limited by it in all its gory glory. IMHO we should simply have a directive that is either cdecl or stdcall depending on the platform, and kill even the current macro support. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Get variable name at runtime
In our previous episode, John Lee said: > So, why can't we have a get_name() type routine, so everyone can use it, > not just those who can write pascal macros? J The proposed Get_name only makes sense for logging purposes. Since if you can't resolve the gotten string back to an address, it is pretty useless for other things. So basically all it is good for is log(get_name(x)+' : '+inttostr(x)); like constructs. since this 1)s:=get_name(x); 2) pass s to a different procedure 3) use s to get access to x in the different procedure won't work. >From what I quickly saw while quickreading this discussion, is that the different proponents have different objectives, and don't seem to realize it. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Get variable name at runtime
So, why can't we have a get_name() type routine, so everyone can use it, not just those who can write pascal macros? J > Unfortunately pascal macro's are rather limited compared to C. I know I > know, you could potentially open up a can of worms, but sometimes more > control is required. > > There is nothing restraining anybody using an external macro processor. It > is just that we don't want to support it :-) > > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Result: string
El 06/03/2013 13:47, Jonas Maebe escribió: 2.6.0, 2.6.2 and 2.7.1 trunk produces a warning with that code, but with this one 2.6.0, and 2.7.1 trunk does not generate it (I do not have 2.6.2 to test): That's because you are passing an uninitialized value to a var-parameter. That only generates a hint, because a lot of code uses var-parameters also for parameters that do not yet have to be initialized (because the code predates the existence of the "out" keyword, or simply out of habit). This is unrelated to string results specifically. OK, I see now. I had changed the code to perform the same with integers and yes, it also does not report a warning only a hint which is enought to me. I'm quite sure that the library that starts this thread does not show a hint, so maybe in some situations it could fail. I'll try to reproduce it in a small code (if there is a problem, of course), meanwhile everything seems to work as expected. Thank you for your help. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Result: string
On 06 Mar 2013, at 13:37, José Mejuto wrote: 2.6.0, 2.6.2 and 2.7.1 trunk produces a warning with that code, but with this one 2.6.0, and 2.7.1 trunk does not generate it (I do not have 2.6.2 to test): That's because you are passing an uninitialized value to a var- parameter. That only generates a hint, because a lot of code uses var- parameters also for parameters that do not yet have to be initialized (because the code predates the existence of the "out" keyword, or simply out of habit). This is unrelated to string results specifically. Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Get variable name at runtime
Marco van de Voort wrote: In our previous episode, Darius Blaszyk said: Here's why :) Unfortunately pascal macro's are rather limited compared to C. I know I know, you could potentially open up a can of worms, but sometimes more control is required. There is nothing restraining anybody using an external macro processor. It is just that we don't want to support it :-) Actually, I'd suggest that there is: the difficulty of integrating an external macro processor with the standard build process (i.e. it's not just another stage in a makefile). I've had to deal with colleagues in the past who thought it was entirely acceptable to make manual edits to compiler output (typically on Intel blue boxes) before running it through the assembler, and it's very high on my list of Thou Shalt Nots. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Result: string
El 06/03/2013 10:40, Jonas Maebe escribió:
FPC 2.6.2 does give a warning (code is from
http://bugs.freepascal.org/view.php?id=20907#c55064 ):
[...]
It could also fail in 2.6.x, just less often.
Hello,
2.6.0, 2.6.2 and 2.7.1 trunk produces a warning with that code, but with
this one 2.6.0, and 2.7.1 trunk does not generate it (I do not have
2.6.2 to test):
>\fpc\svn\bin\i386-win32\fpc test.pp
Free Pascal Compiler version 2.7.1 [2013/03/03] for i386
Copyright (c) 1993-2013 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling test.pp
Linking test.exe
26 lines compiled, 0.1 sec, 29680 bytes code, 1236 bytes data
>\fpc\fpc\2.6.0\bin\i386-win32\fpc.exe test.pp
Free Pascal Compiler version 2.6.0 [2011/12/25] for i386
Copyright (c) 1993-2011 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling test.pp
Linking test.exe
26 lines compiled, 0.0 sec , 27264 bytes code, 1692 bytes data
--
program test;
{$mode objfpc}
{$h+}
procedure TheB(var aTheA: string);
begin
aTheA:=aTheA+'A';
end;
function TheA(): string;
begin
TheB(Result);
end;
Var
C : String;
begin
C:='B';
C:=TheA;
C:=TheA;
Writeln('= "',C,'"');
end.
---
And the effect is the same as using a non initialized variable, so it
must generate a warning AFAIK. So passing Result as var does not
generate a warning.
--
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Get variable name at runtime
In our previous episode, Darius Blaszyk said: > Here's why :) > > Unfortunately pascal macro's are rather limited compared to C. I know I know, > you could potentially open up a can of worms, but sometimes more control is > required. There is nothing restraining anybody using an external macro processor. It is just that we don't want to support it :-) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Object pascal language compatiblity - was: Does FPC 2.8.0 can actually still be called Pascal ?
Am 05.03.2013 22:36, schrieb Dimitri Smits: - Oorspronkelijk e-mail - Van: "Florian Klämpfl" Aan: "FPC-Pascal users discussions" Verzonden: Maandag 4 maart 2013 21:00:10 And how does this change the fact that it is an external cg not written in pascal? the front-end would still be written in pascal. But the back end not, right ;)? as a matter of fact, when you use the binutils and ld etc, you aren't exactly using a full pascal toolchain either, no? Of course I do. My desktops run all windows and fpc for win32/win64 has no need of as or ld (guess why ;)). fpc contains an assembler and linker for win32/win64. Actually, fpc even supported win64 before binutils for it were available due to this. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Result: string
On 05 Mar 2013, at 12:34, José Mejuto wrote: El 05/03/2013 11:23, Howard Page-Clark escribió: The code that makes me wonder something is wrong is this one: [...] For me (win32, FPC 2.6.2) the output is identical (= "A") whether or not Result in TheA() is initialised manually or not. Perhaps 2.7.1 has a regression here if it differs for you? The problem is not the different behavior as it is or will be noted in documentation, the problem is the lack of warning of using a not initialized variable, FPC 2.6.2 does give a warning (code is from http://bugs.freepascal.org/view.php?id=20907#c55064 ): $ fpc -vw tt7.pp Free Pascal Compiler version 2.6.2 [2013/02/03] for powerpc Copyright (c) 1993-2012 by Florian Klaempfl and others Target OS: Darwin for PowerPC Compiling tt7.pp tt7.pp(8,13) Warning: Function result variable does not seem to initialized Assembling (pipe) tt7.s Linking tt7 26 lines compiled, 2.6 sec 1 warning(s) issued so it is hard to fix code that works fine in 2.6.x and that could fail with Trunk. It could also fail in 2.6.x, just less often. Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiler define MAC or MACOS ?
On 25 Feb 2013, at 11:10, LacaK wrote: on documentation http://www.freepascal.org/docs-html/prog/progap7.html#x316-331000G there is : Classic Macintosh MAC but in sources is used: MACOS So may be, that documentation should be updated ? Fixed in svn, thanks. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
