Re: [fpc-pascal] Re: Get all caller adresses of a given function/procedure before executing
Am Tuesday 14 August 2012 03:28:26 schrieb waldo kitty:
> On 8/13/2012 05:09, Rainer Stratmann wrote:
> > Am Monday 13 August 2012 10:35:55 schrieb Lukasz Sokol:
>
> [TRIM]
>
> >> You were saying, that you want to know, which string has not been
> >> used / which string has been used and how many times ?
> >
> > I want to knof if the string was called the first time.
> > But since I also get the pchar information of the textsnippets from the
> > programmemory I can translate (make a list or whatever in the future) all
> > snippets before they were called.
>
> i've been following this whole thread with interest... one thing that i'm
> still not clear about, though, is why is this important? is it to see what
> areas of the program are actually used or something else?
Yes. It has to do with that.
> in my mind, a
> multi-language tool will have all strings translated into the supported
> languages...
The translation is a different thing to that.
> if there are some that are ambiguous or used in a different
> way, then they would get broken down further for proper language
> constructs...
I do not understand this...
> while i have numerous tools and utils out in the wild being
> used on a daily bases, none of them are multi-language but i do look
> forward to the day when i can produce such with minimal effort in coding...
> i have to leave it to others to do the actual translations, though...
I put only ls('snippet1'), ls('snippet2'), ls('snippet3')... around the text
everywhere I want a translation.
This is also better if you are searching for text in the program. You find
then exactly the position you want.
The program then is - now before all ls() are executed - making a list of all
caller adresses (handles) and of all snipets.
Caller adresses Table:
1 $0885BE80
2 $0886CE55
3 $088FF717
4 $0892B385
ID Table
1 snippet1
2 snippet2
3 snippet3
4 ID313
Snippet Table (original language)
1 snippet1
2 snippet2
3 snippet3
4 very long text snippet
Snippet Table (language 2)
1 schnipsel1
2 schnipsel2
3 schnipsel3
4 sehr langer text schnipsel
The ls procedure can get its (unique) caller adress and quickly search in the
caller adress table and then knows the array nr of the translation.
You can make other tables (or fields in an array) for each translation for
example. The translation is done somewhere else (for example online
http://109.91.95.104/sprache).
There is a file with all snippets and translations (handles _not_ included,
because they may change with each execution of the program).
In this file you can store all information you want (date of creation, date of
change, and so on).
If you have a very long snippet then for example you can give the snippet
another identifyer by marking the identifyer with two '~' at the beginning of
the text snippet, for example: ls ('~ID313~very long text snippet' ). With
the shorter text snippets the snippet itself is the identifyer. If you work
with aliases as identifyer then an additional field is required as shown
above.
Again: all you have to do in the program is putting a ls() everywhere around
you want a translation.
No need for tons od additional identyfiers and additional lines like:
var
p_snippet1 : pchar;
p_snippet2 : pchar;
p_snippet3 : pchar;
const
id_snippet1 = 'ids_snippet1';
id_snippet2 = 'ids_snippet2';
id_snippet3 = 'ids_snippet3';
p_snippet1 := trlt( id_snippet1 );
p_snippet2 := trlt( id_snippet2 );
p_snippet3 := trlt( id_snippet3 );
writeln( p_snippet1 );
writeln( p_snippet2 );
writeln( p_snippet3 );
My solution:
writeln( ls( 'snippet1' ) );
writeln( ls( 'snippet2' ) );
writeln( ls( 'snippet3' ) );
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
On 12-8-2012 10:35, Reinier Olislagers wrote: > In my (Windows) SVN fpc installs, I can find the fpdoc executable both > under the bin directory as well as utils\fpdoc > > However, I've only found fpdoc.css in utils\fpdoc (and a different one > in packages\fcl-res\xml) but not in the bin directory. > > IIRC, fpdoc picks up fpdoc.css when generating HTML/CHM output. > Shouldn't fpdoc.css be also present under the bin directory then? > > Thanks, > Reinier > Bump. Any reactions? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
On Tue, 14 Aug 2012, Reinier Olislagers wrote: On 12-8-2012 10:35, Reinier Olislagers wrote: In my (Windows) SVN fpc installs, I can find the fpdoc executable both under the bin directory as well as utils\fpdoc However, I've only found fpdoc.css in utils\fpdoc (and a different one in packages\fcl-res\xml) but not in the bin directory. IIRC, fpdoc picks up fpdoc.css when generating HTML/CHM output. Shouldn't fpdoc.css be also present under the bin directory then? No. You're responsible for putting this file wherever it needs to be put. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Makeskel generation question
On 18-11-2011 13:14, Michael Van Canneyt wrote: > On Fri, 18 Nov 2011, Reinier Olislagers wrote: >> I've run makeskel on ibconnection.pp. >> >> This declaration: >> protected >> ... >>function GetHandle : pointer; override; >> >> gets output as: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Shouldn't the TIBConnection.GetHandle.Result function result visibility >> be protected as well? > > No, why ? A function result has no visibility. > The comment is just a hint for the documenter, after all. > > If you want to make a patch to specify the parent function's visibility, > go ahead, but I think there are more useful things that can be done... > > Michael. Filed a patch: 22639 This also improves error reporting for missing source files. Thanks, Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
On 14-8-2012 9:46, michael.vancann...@wisa.be wrote: > > > On Tue, 14 Aug 2012, Reinier Olislagers wrote: > >> On 12-8-2012 10:35, Reinier Olislagers wrote: >>> In my (Windows) SVN fpc installs, I can find the fpdoc executable both >>> under the bin directory as well as utils\fpdoc >>> >>> However, I've only found fpdoc.css in utils\fpdoc (and a different one >>> in packages\fcl-res\xml) but not in the bin directory. >>> >>> IIRC, fpdoc picks up fpdoc.css when generating HTML/CHM output. >>> Shouldn't fpdoc.css be also present under the bin directory then? > > No. You're responsible for putting this file wherever it needs to be put. > Fine, I understand that, but what is fpdoc then doing in the bin directory? Is it used in some other program? This program presumably either: - uses its own copy or version of the css file - references the fpdoc.css in the utils\fpdoc directory (in which case: why not use the fpdoc executable there) - is not interested in the css file I must still be missing something... Thanks, Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Get all caller adresses of a given function/procedure before executing
Am 14.08.2012 09:11, schrieb Rainer Stratmann: No need for tons od additional identyfiers and additional lines like: var p_snippet1 : pchar; p_snippet2 : pchar; p_snippet3 : pchar; const id_snippet1 = 'ids_snippet1'; id_snippet2 = 'ids_snippet2'; id_snippet3 = 'ids_snippet3'; p_snippet1 := trlt( id_snippet1 ); p_snippet2 := trlt( id_snippet2 ); p_snippet3 := trlt( id_snippet3 ); writeln( p_snippet1 ); writeln( p_snippet2 ); writeln( p_snippet3 ); My solution: writeln( ls( 'snippet1' ) ); writeln( ls( 'snippet2' ) ); writeln( ls( 'snippet3' ) ); You are exaggerating the standard solution a bit... which would be: resourcestring snippet1 = 'snippet1'; snippet2 = 'snippet2'; snippet3 = 'snippet3'; Writeln(snippet1); Writeln(snippet2); Writeln(snippet3); Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
On Tue, 14 Aug 2012, Reinier Olislagers wrote: On 14-8-2012 9:46, michael.vancann...@wisa.be wrote: On Tue, 14 Aug 2012, Reinier Olislagers wrote: On 12-8-2012 10:35, Reinier Olislagers wrote: In my (Windows) SVN fpc installs, I can find the fpdoc executable both under the bin directory as well as utils\fpdoc However, I've only found fpdoc.css in utils\fpdoc (and a different one in packages\fcl-res\xml) but not in the bin directory. IIRC, fpdoc picks up fpdoc.css when generating HTML/CHM output. Shouldn't fpdoc.css be also present under the bin directory then? No. You're responsible for putting this file wherever it needs to be put. Fine, I understand that, but what is fpdoc then doing in the bin directory? The binary ? Where would you put it if not in bin ? Is it used in some other program? This program presumably either: - uses its own copy or version of the css file - references the fpdoc.css in the utils\fpdoc directory (in which case: why not use the fpdoc executable there) - is not interested in the css file The fpdoc system uses a fpdoc.css file for style. We provide one which can be used, but you are under no obligation to use that file. You can perfectly create one from scratch, or adapt the existing one. Since we do not know what you want to do, we do not 'automagically' copy it to the output. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
On 14-8-2012 10:31, michael.vancann...@wisa.be wrote: > On Tue, 14 Aug 2012, Reinier Olislagers wrote: >> On 14-8-2012 9:46, michael.vancann...@wisa.be wrote: >>> On Tue, 14 Aug 2012, Reinier Olislagers wrote: On 12-8-2012 10:35, Reinier Olislagers wrote: > In my (Windows) SVN fpc installs, I can find the fpdoc executable both > under the bin directory as well as utils\fpdoc > > However, I've only found fpdoc.css in utils\fpdoc (and a different one > in packages\fcl-res\xml) but not in the bin directory. > > IIRC, fpdoc picks up fpdoc.css when generating HTML/CHM output. > Shouldn't fpdoc.css be also present under the bin directory then? >>> >>> No. You're responsible for putting this file wherever it needs to be >>> put. >>> >> Fine, I understand that, but what is fpdoc then doing in the bin >> directory? > > The binary ? Where would you put it if not in bin ? Sure, sure, but my point was the connection between fpdoc.css and fpdoc.exe... Not that important, please see below. > The fpdoc system uses a fpdoc.css file for style. We provide one which > can be used, but you are under no obligation to use that file. You can > perfectly create one from scratch, or adapt the existing one. > Since we do not know what you want to do, we do not 'automagically' copy > it to the output. The following is meant as constructive advice, not criticism: Very well, how many people do you think use fpdoc *and* customize fpdoc.css? Even then, copying fpdoc.css to the bin directory would give a sensible default, no? If people want to customize it, replace it etc they can then always do so. If you want your fpdoc.exe usable from the bin directory, I'd just copy over fpdoc.css during install. Now we've got 2 different behaviours: - fpdoc in the source directory has fpdoc.css and will generate chm/html files with it - fpdoc in the bin directory doesn't have it. In my view this difference in behaviour is unnecessary and only server to needlessly further increase the complexity of the fpdoc system... Thanks, Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
On Tue, 14 Aug 2012, Reinier Olislagers wrote: On 14-8-2012 10:31, michael.vancann...@wisa.be wrote: On Tue, 14 Aug 2012, Reinier Olislagers wrote: On 14-8-2012 9:46, michael.vancann...@wisa.be wrote: On Tue, 14 Aug 2012, Reinier Olislagers wrote: On 12-8-2012 10:35, Reinier Olislagers wrote: In my (Windows) SVN fpc installs, I can find the fpdoc executable both under the bin directory as well as utils\fpdoc However, I've only found fpdoc.css in utils\fpdoc (and a different one in packages\fcl-res\xml) but not in the bin directory. IIRC, fpdoc picks up fpdoc.css when generating HTML/CHM output. Shouldn't fpdoc.css be also present under the bin directory then? No. You're responsible for putting this file wherever it needs to be put. Fine, I understand that, but what is fpdoc then doing in the bin directory? The binary ? Where would you put it if not in bin ? Sure, sure, but my point was the connection between fpdoc.css and fpdoc.exe... Not that important, please see below. The fpdoc system uses a fpdoc.css file for style. We provide one which can be used, but you are under no obligation to use that file. You can perfectly create one from scratch, or adapt the existing one. Since we do not know what you want to do, we do not 'automagically' copy it to the output. The following is meant as constructive advice, not criticism: Very well, how many people do you think use fpdoc *and* customize fpdoc.css? Even then, copying fpdoc.css to the bin directory would give a sensible default, no? If people want to customize it, replace it etc they can then always do so. If you want your fpdoc.exe usable from the bin directory, I'd just copy over fpdoc.css during install. Now we've got 2 different behaviours: - fpdoc in the source directory has fpdoc.css and will generate chm/html files with it - fpdoc in the bin directory doesn't have it. In my view this difference in behaviour is unnecessary and only server to needlessly further increase the complexity of the fpdoc system... There is no difference in behaviour. If you do not specify the location with --css-file, then fpdoc does not look in the bin directory, only in the current working directory. That we should distribute the file somewhere is something I agree on, but I do not think it should be in the bin directory; it's not a binary, after all. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
On 14 August 2012 09:37, Reinier Olislagers wrote: > Very well, how many people do you think use fpdoc *and* customize > fpdoc.css? Even then, copying fpdoc.css to the bin directory would give > a sensible default, no? I fully agree. I know you are allowed to customise the CSS file, but i don't know of a single project or person that actually done that. The fpdoc program should at least copy in the default fpdoc.css file - because it looks a damn lot better with the default fpdoc.css than without. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
On 14 August 2012 09:43, wrote: > > That we should distribute the file somewhere is something I agree on, but I > do not think it should be in the bin directory; it's not a binary, after > all. +1 Isn't the fpdoc.css auto generated by the fpdoc executable? For some reason I though it was. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
On Tue, 14 Aug 2012 10:37:46 +0200 Reinier Olislagers wrote: >[...] > The following is meant as constructive advice, not criticism: > Very well, how many people do you think use fpdoc *and* customize > fpdoc.css? I thought almost everyone does that. > Even then, copying fpdoc.css to the bin directory would give > a sensible default, no? If people want to customize it, replace it etc > they can then always do so. Please put only binaries into the bin. It might be in PATH. > If you want your fpdoc.exe usable from the bin directory, I'd just copy > over fpdoc.css during install. > > Now we've got 2 different behaviours: > - fpdoc in the source directory has fpdoc.css and will generate chm/html > files with it > - fpdoc in the bin directory doesn't have it. > In my view this difference in behaviour is unnecessary and only server > to needlessly further increase the complexity of the fpdoc system... Having two binaries with the same name is somewhat confusing. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
On 14-8-2012 10:43, michael.vancann...@wisa.be wrote: > On Tue, 14 Aug 2012, Reinier Olislagers wrote: >> On 14-8-2012 10:31, michael.vancann...@wisa.be wrote: >>> On Tue, 14 Aug 2012, Reinier Olislagers wrote: On 14-8-2012 9:46, michael.vancann...@wisa.be wrote: > On Tue, 14 Aug 2012, Reinier Olislagers wrote: Fine, I understand that, but what is fpdoc then doing in the bin directory? >>> >>> The binary ? Where would you put it if not in bin ? >> Sure, sure, but my point was the connection between fpdoc.css and >> fpdoc.exe... >> Not that important, please see below. >> >>> The fpdoc system uses a fpdoc.css file for style. We provide one which >>> can be used, but you are under no obligation to use that file. You can >>> perfectly create one from scratch, or adapt the existing one. >>> Since we do not know what you want to do, we do not 'automagically' copy >>> it to the output. >> The following is meant as constructive advice, not criticism: >> Very well, how many people do you think use fpdoc *and* customize >> fpdoc.css? Even then, copying fpdoc.css to the bin directory would give >> a sensible default, no? If people want to customize it, replace it etc >> they can then always do so. >> >> If you want your fpdoc.exe usable from the bin directory, I'd just copy >> over fpdoc.css during install. >> >> Now we've got 2 different behaviours: >> - fpdoc in the source directory has fpdoc.css and will generate chm/html >> files with it >> - fpdoc in the bin directory doesn't have it. >> In my view this difference in behaviour is unnecessary and only server >> to needlessly further increase the complexity of the fpdoc system... > > There is no difference in behaviour. > > If you do not specify the location with --css-file, then fpdoc does not > look in the bin directory, only in the current working directory. Right. But there still is a difference between: cd c:\development\fpc\bin\i386-win32 fpdoc ...etc... and cd c:\development\fpc\utils\fpdoc fpdoc ...etc... > That we should distribute the file somewhere is something I agree on, > but I do not think it should be in the bin directory; it's not a binary, > after all. Neither are fp.ans fpc.cfg yylex.cod program.pt cvsup.tdf ... but they still live in my fpc bin directory... Probably supporting files of some sort? Still, I'm glad you think the file should be distributed somewhere... Thanks, Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
Hi On 14 August 2012 09:54, Reinier Olislagers wrote: > Neither are > fp.ans > fpc.cfg > yylex.cod > program.pt > cvsup.tdf > ... but they still live in my fpc bin directory... :-) Good point. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
On Tue, 14 Aug 2012, Reinier Olislagers wrote: On 14-8-2012 10:43, michael.vancann...@wisa.be wrote: On Tue, 14 Aug 2012, Reinier Olislagers wrote: On 14-8-2012 10:31, michael.vancann...@wisa.be wrote: On Tue, 14 Aug 2012, Reinier Olislagers wrote: On 14-8-2012 9:46, michael.vancann...@wisa.be wrote: On Tue, 14 Aug 2012, Reinier Olislagers wrote: Fine, I understand that, but what is fpdoc then doing in the bin directory? The binary ? Where would you put it if not in bin ? Sure, sure, but my point was the connection between fpdoc.css and fpdoc.exe... Not that important, please see below. The fpdoc system uses a fpdoc.css file for style. We provide one which can be used, but you are under no obligation to use that file. You can perfectly create one from scratch, or adapt the existing one. Since we do not know what you want to do, we do not 'automagically' copy it to the output. The following is meant as constructive advice, not criticism: Very well, how many people do you think use fpdoc *and* customize fpdoc.css? Even then, copying fpdoc.css to the bin directory would give a sensible default, no? If people want to customize it, replace it etc they can then always do so. If you want your fpdoc.exe usable from the bin directory, I'd just copy over fpdoc.css during install. Now we've got 2 different behaviours: - fpdoc in the source directory has fpdoc.css and will generate chm/html files with it - fpdoc in the bin directory doesn't have it. In my view this difference in behaviour is unnecessary and only server to needlessly further increase the complexity of the fpdoc system... There is no difference in behaviour. If you do not specify the location with --css-file, then fpdoc does not look in the bin directory, only in the current working directory. Right. But there still is a difference between: cd c:\development\fpc\bin\i386-win32 fpdoc ...etc... and cd c:\development\fpc\utils\fpdoc fpdoc ...etc... I do not understand what you try to say. Please explain ? As far as I know, only 1 copy of fpdoc is distributed. So where you get the second path from, I do not know. That we should distribute the file somewhere is something I agree on, but I do not think it should be in the bin directory; it's not a binary, after all. Neither are fp.ans fpc.cfg yylex.cod program.pt cvsup.tdf ... but they still live in my fpc bin directory... Probably supporting files of some sort? I suspect the programs that use those files are coded to look in the program directory. They stem from the Dos age, and it was common practice in those days. Meanwhile I think the world has evolved to other practices :-) Still, I'm glad you think the file should be distributed somewhere... Well, we're trying hard not to be totally unreasonably pig-headed. It takes a lot of effort, but we try nonetheless :-) Jokes aside: I leave it up to the Windows setup builders to decide where it should go. If they decide on the bin dir anyway, then so be it... Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
On 14-8-2012 11:06, michael.vancann...@wisa.be wrote: > On Tue, 14 Aug 2012, Reinier Olislagers wrote: >> On 14-8-2012 10:43, michael.vancann...@wisa.be wrote: >>> On Tue, 14 Aug 2012, Reinier Olislagers wrote: On 14-8-2012 10:31, michael.vancann...@wisa.be wrote: > On Tue, 14 Aug 2012, Reinier Olislagers wrote: >> On 14-8-2012 9:46, michael.vancann...@wisa.be wrote: >>> On Tue, 14 Aug 2012, Reinier Olislagers wrote: Now we've got 2 different behaviours: - fpdoc in the source directory has fpdoc.css and will generate chm/html files with it - fpdoc in the bin directory doesn't have it. In my view this difference in behaviour is unnecessary and only server to needlessly further increase the complexity of the fpdoc system... >>> >>> There is no difference in behaviour. >>> >>> If you do not specify the location with --css-file, then fpdoc does not >>> look in the bin directory, only in the current working directory. >> Right. >> But there still is a difference between: >> cd c:\development\fpc\bin\i386-win32 >> fpdoc ...etc... >> and >> cd c:\development\fpc\utils\fpdoc >> fpdoc ...etc... > > I do not understand what you try to say. Please explain ? My point is there *is* a difference in behaviour between fpdoc in the bin directory and fpdoc in the utils\fpdoc directory (because fpdoc.css is only present in the latter) Yes, this difference may only appear if you first change the current directory to that directory. But no, this difference is not necessary IMO. Sorry, I can't explain it any way else. > As far as I know, only 1 copy of fpdoc is distributed. So where you get > the second path from, I do not know. Running make all or (very much less likely) make install from an SVN copy. >>> That we should distribute the file somewhere is something I agree on, >>> but I do not think it should be in the bin directory; it's not a binary, >>> after all. >> Neither are >> fp.ans >> fpc.cfg > Meanwhile I think the world has evolved to other practices :-) Tell that to the people who use fpc.cfg ;) > Well, we're trying hard not to be totally unreasonably pig-headed. > It takes a lot of effort, but we try nonetheless :-) Same here - reasonably pig-headed is a totally different story though ;) > Jokes aside: > I leave it up to the Windows setup builders to decide where it should go. > If they decide on the bin dir anyway, then so be it... What about the make files/fpmake etc? Anyway, while I can continue arguing this point (given pig-headedness already mentioned), I think I got across what I wanted to say... even though not everybody agrees ;) Thanks, Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
In our previous episode, Reinier Olislagers said: > > in packages\fcl-res\xml) but not in the bin directory. > > > > IIRC, fpdoc picks up fpdoc.css when generating HTML/CHM output. > > Shouldn't fpdoc.css be also present under the bin directory then? > > > > Thanks, > > Reinier > > > Bump. > > Any reactions? The scripts that generate have their own locations set to the fpdoc.css Since generating docs requires additional repositories (like fpcdoc), it is not a standard feature of installs anyway. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
In our previous episode, Reinier Olislagers said: > > Now we've got 2 different behaviours: > - fpdoc in the source directory has fpdoc.css and will generate chm/html > files with it > - fpdoc in the bin directory doesn't have it. > In my view this difference in behaviour is unnecessary and only server > to needlessly further increase the complexity of the fpdoc system... FPC is supported to be used in installed form only, not directly from build directories. That is limited to what is needed for bootstrap. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
On 14-8-2012 11:34, Marco van de Voort wrote: > In our previous episode, Reinier Olislagers said: >>> in packages\fcl-res\xml) but not in the bin directory. >>> >>> IIRC, fpdoc picks up fpdoc.css when generating HTML/CHM output. >>> Shouldn't fpdoc.css be also present under the bin directory then? >>> >>> Thanks, >>> Reinier >>> >> Bump. >> >> Any reactions? > > The scripts that generate have their own locations set to the fpdoc.css > > Since generating docs requires additional repositories (like fpcdoc), it is > not a standard feature of installs anyway. True for fpc source docs... So you're saying FPC users who don't have the source installed (e.g. on Debian) should get the source, download fpdoc.css separately or create their own if they want to generate HTML documentation of their own code. Doesn't seem user friendly. It just doesn't make sense to me to distribute part of a tool. Granted, that part is optional, can be customized etc. but still, if it's there, people are more likely to use it than if it's not there. I'm trying to be constructive here, but I get a lot of answers in the sense that "this is how it is, don't worry, it's the best solution" or "this is what you're doing wrong, you should be doing it my way". Given Michael's suggestion, and in an effort to have some benefit out of this discussion: 1. Would anybody mind if FPC's fpdoc.css is distributed in fpc installs (not only in source?) 2. If the bin directory is unsuitable, where should it be placed? I'd be happy to use my awful make/fpmake-fu to try and figure out a patch. If not, well, at least this file has gotten a thorough discussion. Thanks, Reinier PS: For some reason, my Lazarus install (from the Windows installer) has an fpdoc.css that states /* $Id: fpdoc.css 32727 2011-10-07 07:47:29Z vincents $ Default style sheet for FPDoc reference documentation by Sebastian Guenther, s...@freepascal.org Feel free to use this file as a template for your own style sheets. */ The only diff with the fpc one is the $Id: fpdoc.css 32727 2011-10-07 07:47:29Z vincents $ line If fpc distributed fpdoc.css, presumably distributing this with Lazarus won't be necessary either... ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
On Tue, 14 Aug 2012, Reinier Olislagers wrote: On 14-8-2012 11:34, Marco van de Voort wrote: In our previous episode, Reinier Olislagers said: in packages\fcl-res\xml) but not in the bin directory. IIRC, fpdoc picks up fpdoc.css when generating HTML/CHM output. Shouldn't fpdoc.css be also present under the bin directory then? Thanks, Reinier Bump. Any reactions? The scripts that generate have their own locations set to the fpdoc.css Since generating docs requires additional repositories (like fpcdoc), it is not a standard feature of installs anyway. True for fpc source docs... So you're saying FPC users who don't have the source installed (e.g. on Debian) should get the source, download fpdoc.css separately or create their own if they want to generate HTML documentation of their own code. Doesn't seem user friendly. There is no discussion that fpdoc.css should be distributed. The only question is: where should we put it ? Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
On 14-8-2012 13:50, michael.vancanneyt-0is9kj9s...@public.gmane.org wrote: > > > On Tue, 14 Aug 2012, Reinier Olislagers wrote: > >> On 14-8-2012 11:34, Marco van de Voort wrote: >>> In our previous episode, Reinier Olislagers said: > in packages\fcl-res\xml) but not in the bin directory. > > IIRC, fpdoc picks up fpdoc.css when generating HTML/CHM output. > Shouldn't fpdoc.css be also present under the bin directory then? > > Thanks, > Reinier > Bump. Any reactions? >>> >>> The scripts that generate have their own locations set to the fpdoc.css >>> >>> Since generating docs requires additional repositories (like fpcdoc), >>> it is >>> not a standard feature of installs anyway. >> True for fpc source docs... >> >> So you're saying FPC users who don't have the source installed (e.g. on >> Debian) should get the source, download fpdoc.css separately or create >> their own if they want to generate HTML documentation of their own code. >> Doesn't seem user friendly. > > There is no discussion that fpdoc.css should be distributed. Yes, you told me. I'm asking because I'm not sure what Marco wanted (and anybody else). > The only question is: where should we put it ? Apparently the bin directory is not satisfactory (though I don't see why)? On my Laz install (installed by Win installer) I only have bin,msg,units under the fpc directory. Perhaps there are others in other versions... What about the fpc root directory then? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
michael.vancanneyt wrote on Tue, 14 Aug 2012: There is no discussion that fpdoc.css should be distributed. The only question is: where should we put it ? On Unix, $PREFIX/share/doc/fpc-$fpcversion/ would seem appropriate to me. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Get all caller adresses of a given function/procedure before executing
Am Tuesday 14 August 2012 10:17:52 schrieb Sven Barth: > Am 14.08.2012 09:11, schrieb Rainer Stratmann: > > No need for tons od additional identyfiers and additional lines like: > > > > var > > p_snippet1 : pchar; > > p_snippet2 : pchar; > > p_snippet3 : pchar; > > > > const > > id_snippet1 = 'ids_snippet1'; > > id_snippet2 = 'ids_snippet2'; > > id_snippet3 = 'ids_snippet3'; > > > > p_snippet1 := trlt( id_snippet1 ); > > p_snippet2 := trlt( id_snippet2 ); > > p_snippet3 := trlt( id_snippet3 ); > > > > writeln( p_snippet1 ); > > writeln( p_snippet2 ); > > writeln( p_snippet3 ); > > > > My solution: > > > > writeln( ls( 'snippet1' ) ); > > writeln( ls( 'snippet2' ) ); > > writeln( ls( 'snippet3' ) ); > > You are exaggerating the standard solution a bit... which would be: It was more or less exactly the way I did it before with little exaggerating as you notice :-) Even now I save 50% codesize in comparison to resourcestring. > resourcestring >snippet1 = 'snippet1'; >snippet2 = 'snippet2'; >snippet3 = 'snippet3'; > > Writeln(snippet1); > Writeln(snippet2); > Writeln(snippet3); ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Get all caller adresses of a given function/procedure before executing
On 14/08/2012 13:19, Rainer Stratmann wrote:
It was more or less exactly the way I did it before with little exaggerating
as you notice :-)
Even now I save 50% codesize in comparison to resourcestring.
If you don't like resource string, inho there are 2 alternatives that
are (IMHO) better:
1)
plain array with all text constants. You can break it into one array per
unit, and have a register a search-handler via the unit's initialization.
const MySnippets: Array [1..xxx] of string = ('text', '...', ... ];
For more readability (but it adds source code (should not add more to exe)
const
snip1: 'text';
MySnippets: Array [1..xxx] of string = (snip1, '...', ... ];
(actually, I havent testet if the compiler takes the 2nd
2)
Since you seem to want something that is easier to type.
Keep using
writeln(ls('text'));
Instead of analysing the exe, write your own pre-precessor.
The pre-processor can scan the source, create a temporary copy in which
it replaces the text in ls() with a reference to the "MySnippets[]" array.
It also creates and includes a unit with that array.
It then calls the compiler on the temporary created sources
At least it will keep working even if fpc internals change. And it is
cross platform (includes cross-CPU)
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
On Tue, 14 Aug 2012, Reinier Olislagers wrote: On 14-8-2012 13:50, michael.vancanneyt-0is9kj9s...@public.gmane.org wrote: On Tue, 14 Aug 2012, Reinier Olislagers wrote: On 14-8-2012 11:34, Marco van de Voort wrote: In our previous episode, Reinier Olislagers said: in packages\fcl-res\xml) but not in the bin directory. IIRC, fpdoc picks up fpdoc.css when generating HTML/CHM output. Shouldn't fpdoc.css be also present under the bin directory then? Thanks, Reinier Bump. Any reactions? The scripts that generate have their own locations set to the fpdoc.css Since generating docs requires additional repositories (like fpcdoc), it is not a standard feature of installs anyway. True for fpc source docs... So you're saying FPC users who don't have the source installed (e.g. on Debian) should get the source, download fpdoc.css separately or create their own if they want to generate HTML documentation of their own code. Doesn't seem user friendly. There is no discussion that fpdoc.css should be distributed. Yes, you told me. I'm asking because I'm not sure what Marco wanted (and anybody else). The only question is: where should we put it ? Apparently the bin directory is not satisfactory (though I don't see why)? 2 reasons: 1. I do not think you should put such files there. I know that there are some historic reasons for putting some 'extra' things there, but I think we should change that DOS habit. 2. fpdoc.exe will not search it there. By putting it there you will create the expectation that it will search for it there (as some of the other utils do), but it will not. On my Laz install (installed by Win installer) I only have bin,msg,units under the fpc directory. Perhaps there are others in other versions... What about the fpc root directory then? I think it is better to have it in fpc/docs. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
On 14-8-2012 14:40, michael.vancanneyt-0is9kj9s...@public.gmane.org wrote: > On Tue, 14 Aug 2012, Reinier Olislagers wrote: >> On 14-8-2012 13:50, >> michael.vancanneyt-0is9kj9sb0a-xmd5yjdbdmrexy1tmh2...@public.gmane.org >> wrote: >>> On Tue, 14 Aug 2012, Reinier Olislagers wrote: On 14-8-2012 11:34, Marco van de Voort wrote: > In our previous episode, Reinier Olislagers said: >>> in packages\fcl-res\xml) but not in the bin directory. >>> >>> IIRC, fpdoc picks up fpdoc.css when generating HTML/CHM output. >>> Shouldn't fpdoc.css be also present under the bin directory then? >>> The only question is: where should we put it ? >> On my Laz install (installed by Win installer) I only have bin,msg,units >> under the fpc directory. >> Perhaps there are others in other versions... >> >> What about the fpc root directory then? > > I think it is better to have it in fpc/docs. Ok. So: \docs for Windows and on Linux/Unix/(OSX??) Jonas' suggestion $PREFIX/share/doc/fpc-$fpcversion/ Thanks, Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Get all caller adresses of a given function/procedure before executing
Am Tuesday 14 August 2012 14:36:44 schrieb Martin:
> On 14/08/2012 13:19, Rainer Stratmann wrote:
> > It was more or less exactly the way I did it before with little
> > exaggerating as you notice :-)
> > Even now I save 50% codesize in comparison to resourcestring.
>
> If you don't like resource string, inho there are 2 alternatives that
> are (IMHO) better:
>
> 1)
> plain array with all text constants. You can break it into one array per
> unit, and have a register a search-handler via the unit's initialization.
>
> const MySnippets: Array [1..xxx] of string = ('text', '...', ... ];
>
> For more readability (but it adds source code (should not add more to exe)
>
> const
> snip1: 'text';
>MySnippets: Array [1..xxx] of string = (snip1, '...', ... ];
>
> (actually, I havent testet if the compiler takes the 2nd
Then you have to put _all_ text snippets at once there (!)
I didn't count my text snippets in this project, but they are spread over
about more than 10 units.
> 2)
> Since you seem to want something that is easier to type.
>
> Keep using
>writeln(ls('text'));
>
> Instead of analysing the exe, write your own pre-precessor.
I considered this, but the solution now is - in my view - unbeatably easy.
And that is what counts for me.
> The pre-processor can scan the source, create a temporary copy in which
> it replaces the text in ls() with a reference to the "MySnippets[]" array.
> It also creates and includes a unit with that array.
> It then calls the compiler on the temporary created sources
>
> At least it will keep working even if fpc internals change.
I do not worry about this. The search procedure can easily adapted then.
> And it is cross platform (includes cross-CPU)
Yes, that's true. But I am confident to find here also a solution once it will
be necessary.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
On Tue, 14 Aug 2012, Reinier Olislagers wrote: On 14-8-2012 14:40, michael.vancanneyt-0is9kj9s...@public.gmane.org wrote: On Tue, 14 Aug 2012, Reinier Olislagers wrote: On 14-8-2012 13:50, michael.vancanneyt-0is9kj9sb0a-xmd5yjdbdmrexy1tmh2...@public.gmane.org wrote: On Tue, 14 Aug 2012, Reinier Olislagers wrote: On 14-8-2012 11:34, Marco van de Voort wrote: In our previous episode, Reinier Olislagers said: in packages\fcl-res\xml) but not in the bin directory. IIRC, fpdoc picks up fpdoc.css when generating HTML/CHM output. Shouldn't fpdoc.css be also present under the bin directory then? The only question is: where should we put it ? On my Laz install (installed by Win installer) I only have bin,msg,units under the fpc directory. Perhaps there are others in other versions... What about the fpc root directory then? I think it is better to have it in fpc/docs. Ok. So: \docs for Windows and on Linux/Unix/(OSX??) Jonas' suggestion $PREFIX/share/doc/fpc-$fpcversion/ Seems like the reasonable thing, yes. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
On Tue, August 14, 2012 15:15, michael.vancann...@wisa.be wrote: > On Tue, 14 Aug 2012, Reinier Olislagers wrote: >> On 14-8-2012 14:40, michael.vancanneyt-0is9kj9s...@public.gmane.org >> wrote: >>> On Tue, 14 Aug 2012, Reinier Olislagers wrote: On 14-8-2012 13:50, michael.vancanneyt-0is9kj9sb0a-xmd5yjdbdmrexy1tmh2...@public.gmane.org wrote: > On Tue, 14 Aug 2012, Reinier Olislagers wrote: >> On 14-8-2012 11:34, Marco van de Voort wrote: >>> In our previous episode, Reinier Olislagers said: > in packages\fcl-res\xml) but not in the bin directory. > > IIRC, fpdoc picks up fpdoc.css when generating HTML/CHM output. > Shouldn't fpdoc.css be also present under the bin directory then? > The only question is: where should we put it ? >> On my Laz install (installed by Win installer) I only have bin,msg,units under the fpc directory. Perhaps there are others in other versions... What about the fpc root directory then? >>> >>> I think it is better to have it in fpc/docs. >> Ok. >> So: >> \docs for Windows and >> on Linux/Unix/(OSX??) Jonas' suggestion >> $PREFIX/share/doc/fpc-$fpcversion/ > > Seems like the reasonable thing, yes. Actually, the file is more a configuration file for fpdoc than its documentation, isn't it? From this point of view, shouldn't SysUtils.GetAppConfigDir serve as the most reasonable location? Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
On Tue, 14 Aug 2012, Tomas Hajny wrote: On Tue, August 14, 2012 15:15, michael.vancann...@wisa.be wrote: On Tue, 14 Aug 2012, Reinier Olislagers wrote: On 14-8-2012 14:40, michael.vancanneyt-0is9kj9s...@public.gmane.org wrote: On Tue, 14 Aug 2012, Reinier Olislagers wrote: On 14-8-2012 13:50, michael.vancanneyt-0is9kj9sb0a-xmd5yjdbdmrexy1tmh2...@public.gmane.org wrote: On Tue, 14 Aug 2012, Reinier Olislagers wrote: On 14-8-2012 11:34, Marco van de Voort wrote: In our previous episode, Reinier Olislagers said: in packages\fcl-res\xml) but not in the bin directory. IIRC, fpdoc picks up fpdoc.css when generating HTML/CHM output. Shouldn't fpdoc.css be also present under the bin directory then? The only question is: where should we put it ? On my Laz install (installed by Win installer) I only have bin,msg,units under the fpc directory. Perhaps there are others in other versions... What about the fpc root directory then? I think it is better to have it in fpc/docs. Ok. So: \docs for Windows and on Linux/Unix/(OSX??) Jonas' suggestion $PREFIX/share/doc/fpc-$fpcversion/ Seems like the reasonable thing, yes. Actually, the file is more a configuration file for fpdoc than its documentation, isn't it? From this point of view, shouldn't SysUtils.GetAppConfigDir serve as the most reasonable location? It is definitely not a config file. It is a file that must be copied to every project you want to document with fpdoc. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
In our previous episode, Jonas Maebe said: [ Charset UTF-8 unsupported, converting... ] > > michael.vancanneyt wrote on Tue, 14 Aug 2012: > > > There is no discussion that fpdoc.css should be distributed. > > The only question is: where should we put it ? > > On Unix, $PREFIX/share/doc/fpc-$fpcversion/ would seem appropriate to me. Is that correct? While used in doc building, it is not a documentation file. If you consider it an example or template share/examples/fpc-x would be better. (install.sh allows to specify a separate directory for examples) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
On Tue, 14 Aug 2012, Marco van de Voort wrote: In our previous episode, Jonas Maebe said: [ Charset UTF-8 unsupported, converting... ] michael.vancanneyt wrote on Tue, 14 Aug 2012: There is no discussion that fpdoc.css should be distributed. The only question is: where should we put it ? On Unix, $PREFIX/share/doc/fpc-$fpcversion/ would seem appropriate to me. Is that correct? While used in doc building, it is not a documentation file. If you consider it an example or template share/examples/fpc-x would be better. (install.sh allows to specify a separate directory for examples) Thinking about it, I will change fpdoc so it does not need the file installed, but generates it if not present, as Graeme suggested. That will be far easier, and causes less headaches and discussion. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
On Tue, August 14, 2012 15:47, michael.vancann...@wisa.be wrote: > On Tue, 14 Aug 2012, Tomas Hajny wrote: >> On Tue, August 14, 2012 15:15, michael.vancann...@wisa.be wrote: >>> On Tue, 14 Aug 2012, Reinier Olislagers wrote: On 14-8-2012 14:40, michael.vancanneyt-0is9kj9s...@public.gmane.org wrote: > On Tue, 14 Aug 2012, Reinier Olislagers wrote: >> On 14-8-2012 13:50, >> michael.vancanneyt-0is9kj9sb0a-xmd5yjdbdmrexy1tmh2...@public.gmane.org >> wrote: >>> On Tue, 14 Aug 2012, Reinier Olislagers wrote: On 14-8-2012 11:34, Marco van de Voort wrote: > In our previous episode, Reinier Olislagers said: >>> in packages\fcl-res\xml) but not in the bin directory. >>> >>> IIRC, fpdoc picks up fpdoc.css when generating HTML/CHM output. >>> Shouldn't fpdoc.css be also present under the bin directory >>> then? >>> The only question is: where should we put it ? >> On my Laz install (installed by Win installer) I only have >> bin,msg,units >> under the fpc directory. >> Perhaps there are others in other versions... >> >> What about the fpc root directory then? > > I think it is better to have it in fpc/docs. Ok. So: \docs for Windows and on Linux/Unix/(OSX??) Jonas' suggestion $PREFIX/share/doc/fpc-$fpcversion/ >>> >>> Seems like the reasonable thing, yes. >> >> Actually, the file is more a configuration file for fpdoc than its >> documentation, isn't it? From this point of view, shouldn't >> SysUtils.GetAppConfigDir serve as the most reasonable location? > > It is definitely not a config file. It is a file that must be copied to > every project you want to document with fpdoc. If I understand it correctly, this is only the case for plain HTML whereas CHM includes it internally (and from this point of view it is much more a configuration file influencing the output than part of fpdoc documentation - see also the comment from Marco). >From certain point of view it is unfortunate that the same file (equally named and potentially even equally placed) is used as the default template for generation of new documents with fpdoc and also for viewing of the (distributed) FPC documentation because fpdoc users may want to change the style of their generated documents but they may not be interested in changing the design of our FPC documentation. Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
On 14-8-2012 16:03, michael.vancanneyt-0is9kj9s...@public.gmane.org wrote: > > > On Tue, 14 Aug 2012, Marco van de Voort wrote: > >> In our previous episode, Jonas Maebe said: >> [ Charset UTF-8 unsupported, converting... ] >>> >>> michael.vancanneyt wrote on Tue, 14 Aug 2012: >>> There is no discussion that fpdoc.css should be distributed. The only question is: where should we put it ? >>> >>> On Unix, $PREFIX/share/doc/fpc-$fpcversion/ would seem appropriate to >>> me. >> >> Is that correct? While used in doc building, it is not a documentation >> file. >> >> If you consider it an example or template share/examples/fpc-x would be >> better. (install.sh allows to specify a separate directory for examples) > > Thinking about it, I will change fpdoc so it does not need the file > installed, but generates it if not present, as Graeme suggested. > > That will be far easier, and causes less headaches and discussion. Sounds good! ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
On Tue, 14 Aug 2012, Tomas Hajny wrote: $PREFIX/share/doc/fpc-$fpcversion/ Seems like the reasonable thing, yes. Actually, the file is more a configuration file for fpdoc than its documentation, isn't it? From this point of view, shouldn't SysUtils.GetAppConfigDir serve as the most reasonable location? It is definitely not a config file. It is a file that must be copied to every project you want to document with fpdoc. If I understand it correctly, this is only the case for plain HTML whereas CHM includes it internally (and from this point of view it is much more a configuration file influencing the output than part of fpdoc documentation - see also the comment from Marco). As far as I know, CHM does not include it internally. It expects it to be there, just as the other HTML files should be there. From certain point of view it is unfortunate that the same file (equally named and potentially even equally placed) is used as the default template for generation of new documents with fpdoc and also for viewing of the (distributed) FPC documentation because fpdoc users may want to change the style of their generated documents but they may not be interested in changing the design of our FPC documentation. The file in the docs dir is there so they can copy it. It will never be used directly. Anyway, it's all moot now, I will let fpdoc generate the file. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
In our previous episode, michael.vancann...@wisa.be said: > > If I understand it correctly, this is only the case for plain HTML whereas > > CHM includes it internally (and from this point of view it is much more a > > configuration file influencing the output than part of fpdoc documentation > > - see also the comment from Marco). > As far as I know, CHM does not include it internally. It expects it to be > there, just as the other HTML files should be there. The CHM files contain a copy of the fpdoc.css file. It expects it to be there or specified with CSSFILE on the make cmdline during generation. Since FPC installs an chm extaction tool by default, one can simply extract it from the CHM as if it were a ZIP file: chmls extract rtl.chm fpdoc.css will generate fpdoc.css specified during compilation of the CHM. > The file in the docs dir is there so they can copy it. > It will never be used directly. > > Anyway, it's all moot now, I will let fpdoc generate the file. I assume you mean you will embed fpdoc.css and use it by default, but cmdline params will override it? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
On 14-8-2012 16:03, michael.vancanneyt-0is9kj9s...@public.gmane.org wrote: > Thinking about it, I will change fpdoc so it does not need the file > installed, but generates it if not present, as Graeme suggested. > > That will be far easier, and causes less headaches and discussion. If/when you are looking at fpdoc, perhaps you first might want to have a look at patch http://bugs.freepascal.org/view.php?id=22639 first. It touches some copyright strings for fpdoc (as well as changing some makeskel functionality). Of course, I'd be very willing to split apart these changes as well. Thanks, Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
On Tue, 14 Aug 2012, Reinier Olislagers wrote: On 14-8-2012 16:03, michael.vancanneyt-0is9kj9s...@public.gmane.org wrote: Thinking about it, I will change fpdoc so it does not need the file installed, but generates it if not present, as Graeme suggested. That will be far easier, and causes less headaches and discussion. If/when you are looking at fpdoc, perhaps you first might want to have a look at patch http://bugs.freepascal.org/view.php?id=22639 first. It touches some copyright strings for fpdoc (as well as changing some makeskel functionality). Of course, I'd be very willing to split apart these changes as well. No need. I applied it as-is, but it would be nice in the future to split the patch... Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
On Tue, 14 Aug 2012, Reinier Olislagers wrote: On 14-8-2012 16:03, michael.vancanneyt-0is9kj9s...@public.gmane.org wrote: Thinking about it, I will change fpdoc so it does not need the file installed, but generates it if not present, as Graeme suggested. That will be far easier, and causes less headaches and discussion. Implemented it. Revision 22079. The --css-file option is still honored. If it is not specified, a built-in copy is written to the appropriate place. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
On 14.08.2012 11:29, Reinier Olislagers wrote: Meanwhile I think the world has evolved to other practices :-) Tell that to the people who use fpc.cfg ;) On Unix based systems it is standard that the fpc.cfg is either located in /etc or is in your home directory as .fpc.cfg. On Windows based systems the fpc.cfg is located in the bin directory, because this was done for a long time already, but the compiler is also capable to read the fpc.cfg from the directory given by the environment variables USERPROFILE and ALLUSERSPROFILE. (also PPC_CONFIG_PATH will always be checked for a config file) Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Get all caller adresses of a given function/procedure before executing
Why not scan the code with passrc, find the strings, build a table and
then replace the strings with calls to a function that does the
translation ?
your hack sounds like a maintenance nightmare... Thats what a C
programmer would do and then boast about his programming skills, just
to later discovar that his solution is nor portable nor safe...
2012/8/14 Rainer Stratmann :
> Am Tuesday 14 August 2012 14:36:44 schrieb Martin:
>> On 14/08/2012 13:19, Rainer Stratmann wrote:
>> > It was more or less exactly the way I did it before with little
>> > exaggerating as you notice :-)
>> > Even now I save 50% codesize in comparison to resourcestring.
>>
>> If you don't like resource string, inho there are 2 alternatives that
>> are (IMHO) better:
>>
>> 1)
>> plain array with all text constants. You can break it into one array per
>> unit, and have a register a search-handler via the unit's initialization.
>>
>> const MySnippets: Array [1..xxx] of string = ('text', '...', ... ];
>>
>> For more readability (but it adds source code (should not add more to exe)
>>
>> const
>> snip1: 'text';
>>MySnippets: Array [1..xxx] of string = (snip1, '...', ... ];
>>
>> (actually, I havent testet if the compiler takes the 2nd
>
> Then you have to put _all_ text snippets at once there (!)
> I didn't count my text snippets in this project, but they are spread over
> about more than 10 units.
>
>> 2)
>> Since you seem to want something that is easier to type.
>>
>> Keep using
>>writeln(ls('text'));
>>
>> Instead of analysing the exe, write your own pre-precessor.
>
> I considered this, but the solution now is - in my view - unbeatably easy.
> And that is what counts for me.
>
>> The pre-processor can scan the source, create a temporary copy in which
>> it replaces the text in ls() with a reference to the "MySnippets[]" array.
>> It also creates and includes a unit with that array.
>> It then calls the compiler on the temporary created sources
>>
>> At least it will keep working even if fpc internals change.
>
> I do not worry about this. The search procedure can easily adapted then.
>
>> And it is cross platform (includes cross-CPU)
>
> Yes, that's true. But I am confident to find here also a solution once it will
> be necessary.
> ___
> 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] Re: Get all caller adresses of a given function/procedure before executing
Two informations:
1. All caller adresses of a function (lets say rs( s : pchar ) : shortstring )
2. All pchar pointers to the test snippets
That was all I need.
Your solution sounds not practical to me.
(scan the code with another tool, modify the source code or what do you mean?
I don't want to have boast of tools for a simple solution).
I never talked about that my solution should be portable.
That was interjected here in this thread.
If you followed the discussion then I first asked for a (portable) solution. I
asked if the compiler can provide the 2 informations above.
But that was not possible.
So I looked for an own solution.
Of course I am proud to find a solution and make some kind of marketing here.
You call it "boast about programming skills".
You try now to make a bad atmosphere out of it.
Am Tuesday 14 August 2012 23:43:23 schrieb Jorge Aldo G. de F. Junior:
> Why not scan the code with passrc, find the strings, build a table and
> then replace the strings with calls to a function that does the
> translation ?
>
> your hack sounds like a maintenance nightmare... Thats what a C
> programmer would do and then boast about his programming skills, just
> to later discovar that his solution is nor portable nor safe...
>
> 2012/8/14 Rainer Stratmann :
> > Am Tuesday 14 August 2012 14:36:44 schrieb Martin:
> >> On 14/08/2012 13:19, Rainer Stratmann wrote:
> >> > It was more or less exactly the way I did it before with little
> >> > exaggerating as you notice :-)
> >> > Even now I save 50% codesize in comparison to resourcestring.
> >>
> >> If you don't like resource string, inho there are 2 alternatives that
> >> are (IMHO) better:
> >>
> >> 1)
> >> plain array with all text constants. You can break it into one array per
> >> unit, and have a register a search-handler via the unit's
> >> initialization.
> >>
> >> const MySnippets: Array [1..xxx] of string = ('text', '...', ... ];
> >>
> >> For more readability (but it adds source code (should not add more to
> >> exe)
> >>
> >> const
> >> snip1: 'text';
> >>MySnippets: Array [1..xxx] of string = (snip1, '...', ... ];
> >>
> >> (actually, I havent testet if the compiler takes the 2nd
> >
> > Then you have to put _all_ text snippets at once there (!)
> > I didn't count my text snippets in this project, but they are spread over
> > about more than 10 units.
> >
> >> 2)
> >> Since you seem to want something that is easier to type.
> >>
> >> Keep using
> >>writeln(ls('text'));
> >>
> >> Instead of analysing the exe, write your own pre-precessor.
> >
> > I considered this, but the solution now is - in my view - unbeatably
> > easy. And that is what counts for me.
> >
> >> The pre-processor can scan the source, create a temporary copy in which
> >> it replaces the text in ls() with a reference to the "MySnippets[]"
> >> array. It also creates and includes a unit with that array.
> >> It then calls the compiler on the temporary created sources
> >>
> >> At least it will keep working even if fpc internals change.
> >
> > I do not worry about this. The search procedure can easily adapted then.
> >
> >> And it is cross platform (includes cross-CPU)
> >
> > Yes, that's true. But I am confident to find here also a solution once it
> > will be necessary.
> > ___
> > 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
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Get all caller adresses of a given function/procedure before executing
On 8/14/2012 03:11, Rainer Stratmann wrote:
Am Tuesday 14 August 2012 03:28:26 schrieb waldo kitty:
i've been following this whole thread with interest... one thing that i'm
still not clear about, though, is why is this important? is it to see what
areas of the program are actually used or something else?
Yes. It has to do with that.
ok... that's one part that is understandable from a statistics POV...
in my mind, a multi-language tool will have all strings translated
into the supported languages...
The translation is a different thing to that.
i don't understand... you have a list of the original strings and other lists of
those strings translated into other languages... on startup, the program
determines which language is chosen and it loads that translated language
file... there is then no more translation needed... the program then simply uses
those strings using the very same routines and no additional coding is needed... ???
if there are some that are ambiguous or used in a different
way, then they would get broken down further for proper language
constructs...
I do not understand this...
consider in english we might say "she opened the door" but in another language
they might use the format of "door opened she"... basically what i'm trying to
say is that the constructs of the sentences may be different... my comment above
was looking that one might have to break down that sentence "she opened the
door" into multiple parts so that the translation would be performed and
assembled in the output of the program easier...
while i have numerous tools and utils out in the wild being
used on a daily bases, none of them are multi-language but i do look
forward to the day when i can produce such with minimal effort in coding...
i have to leave it to others to do the actual translations, though...
I put only ls('snippet1'), ls('snippet2'), ls('snippet3')... around the text
everywhere I want a translation.
this would be no different than the program doing
writeln(snippet1);
when all strings are translated and stored in some translated language file...
snippet1 in english would be the same snippet1 in german, dutch, japanese,
etc... it is my understanding that this is also the way the existing *.po files
work... the code simply loads english.po or german.po or klingon.po at the start
of the program and after that, everything is the same...
This is also better if you are searching for text in the program. You find
then exactly the position you want.
i understand what you are saying but i don't understand why... since you
mentioned an online translation service, are you looking at using live
translations instead of static ones stored in a language file??
[trim]
You can make other tables (or fields in an array) for each translation for
example. The translation is done somewhere else (for example online
http://109.91.95.104/sprache).
so you are looking to perform live translations, then? what if that translation
service disappears tomorrow? what about your users then?
There is a file with all snippets and translations (handles _not_ included,
because they may change with each execution of the program).
i don't see how a language can change from one day to the next or even one
execution to the next...
[trim]
Again: all you have to do in the program is putting a ls() everywhere around
you want a translation.
No need for tons od additional identyfiers and additional lines like:
but there's nothing like that with the existing po files if i'm understanding
their purpose and method of use... the loading code simply chooses the proper po
file and then loads the strings into an array or whatever using the same
variables which are used everywhere no matter what language their contents are
written in...
i must still be missing something :?
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Get all caller adresses of a given function/procedure before executing
On 15/08/2012 02:52, waldo kitty wrote:
this would be no different than the program doing
writeln(snippet1);
.i must still be missing something :?
If I understood him correct:
It is not
writeln(snippet1);
it is
writeln('snippet1');
With quotes.
He does want (or already has) the text snippets as in-lined constants.
He does not want to do the work of maintain them in another place (which
an array, or resource string would require.)
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
On 8/14/2012 09:47, michael.vancann...@wisa.be wrote: On Tue, 14 Aug 2012, Tomas Hajny wrote: Actually, the file is more a configuration file for fpdoc than its documentation, isn't it? From this point of view, shouldn't SysUtils.GetAppConfigDir serve as the most reasonable location? It is definitely not a config file. It is a file that must be copied to every project you want to document with fpdoc. does that include FPC itself? it seems to me that folks questioning this install problem are talking specifically about fpc documenting itself and where this file needs to be for the fpc documentation to work and look proper in an out of the box installation whether that is from some sort of installation program thing or whether it is via downloading the sources from SVN and building them with the make system... the task of placing it correctly for one's own projects is another matter completely... ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Get all caller adresses of a given function/procedure before executing
On 8/14/2012 22:05, Martin wrote:
On 15/08/2012 02:52, waldo kitty wrote:
this would be no different than the program doing
writeln(snippet1);
.i must still be missing something :?
If I understood him correct:
It is not
writeln(snippet1);
it is
writeln('snippet1');
With quotes.
yes, i caught that but thought that those were to be short examples of the
strings...
He does want (or already has) the text snippets as in-lined constants.
ok...
He does not want to do the work of maintain them in another place (which an
array, or resource string would require.)
what work? someone has to do it, somehow... it just seems better and even easier
to have them in string variables and then just use them... i mean, ok...
constants are one thing but they have their limits... if they are not intended
to be constant then they should be in vars...
FWIW: i have, around here somewhere, code that does alter constants during
execution... but it is TP6 based hackery code... in the same vein, i also have
code that saves constants to the executable and then changes them based on
settings... this instead of a configuration file... then there is also code to
alter the parent environment's variables... all of these things are TP6 stuff
but they won't work in FPC or many of today's setups... i'm really dreading to
have to figure out some other way of handling these types of things... single
file distributions are very nice even if they are actually multiple files all
stored in the executable ;)
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
