In our previous episode, Felipe Monteiro de Carvalho said:
>
> Is it still in time to request mergers? I'd like to request a merge of
> all changes from fpvectorial since the branching.
>
> http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/packages/fpvectorial/?view=log
There are only two, 1897
In our previous episode, Felipe Monteiro de Carvalho said:
> On Wed, Sep 7, 2011 at 2:39 PM, Marco van de Voort wrote:
> > There are only two, 18977, and the one you just committed.
( http://www.stack.nl/~marcov/mergelogs26/ and then "fpvectorial" )
> Yes, but the las
In our previous episode, Anton Kavalenka said:
> This being translated always and is Delphi compatible
It is if you use Delphi based resources for translating. It is not if you
use thirdparty translation packages udner Delphi like e.g. dxgettext
___
fpc
In our previous episode, John Lee said:
> >
> > Maybe we could/should put a fpc compilable version of this into the fpc
> docs, and into the fpc distribution? Can't imagine that one could do
> anything smaller or more portable?
P4 is not FPC compilable. It uses ISO style filehandling iirc.
___
In our previous episode, Michael Van Canneyt said:
> > When heritage is meant, I'd suggest something like "Ancestor ... of ... not
> > found". At least I like messages starting with a fixed part, indicating the
> > message type, not with an identifier.
> >
> > What do the "new alias ..." messages
Hello,
Could sb with a recent trunk based system and mysql please try to duplicate
Mantis #15324?
Thanks in advance.
]
Marco
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
In our previous episode, Ludo Brands said:
>
> <
> C:\Documents and Settings\Ludo\Mes documents\Lazarus
> Projects\test\leak0015324>leak.exe
>
> Heap dump by heaptrc unit
> 189 memory blocks allocated : 11362/12624
> 189 memory blocks freed : 11362/12624
> 0 unfreed memory blocks : 0
> Tr
In our previous episode, Graeme Geldenhuys said:
> >> No Latex support here (Win7)
> > Virtual Box is your friend :-) .
> Even easier, you get LaTeX for Windows too... I think it is called
> something like MiKTex.
Even better, TeXLive has easy installers nowaday, and that is the TeX distro
mostly
In our previous episode, Felipe Monteiro de Carvalho said:
>
> Following from a discussion on mac-pascal, I'd like to propose a
> solution for Unicode support.
First and for all. Backwards compat dropping is not going to happen. If we
were planning that, we had changed everything to something uni
In our previous episode, Felipe Monteiro de Carvalho said:
>
> * Make file-handling routines which take filenames as parameters from
> the RTL modular so that the LCL can implement them with UTF-8 support.
> This plus a UTF-8 widestring manager and the Ansi RTL can be fully
> UTF-8.
I'm not as op
In our previous episode, Felipe Monteiro de Carvalho said:
> wrote:
> > One with unicode string, one with ansistring. They will have the same code,
> > but will be compiled twice, each time with a different compiler define to
> > decide which version it must be.
>
> Is this possible in UNIX? I ca
In our previous episode, Felipe Monteiro de Carvalho said:
> And why would the interfaces change in the other proposal?
> It is only
> 1 more overloaded option for the routines,
Which is just 1 more interface change. And for something that is a temporary
workaround.
That is what I like on Mattia
In our previous episode, Martin Schreiber said:
> > Is this possible in UNIX? I can see that in Windows you can use the
> > trick to use W versions which are identical except for the string type
> > and drop Windows 9x support, but is this really possible for the UNIX
> > syscalls? They expect UTF-
In our previous episode, Hans-Peter Diettrich said:
> > Lazarus was forced to make out of the identity of ANSIString and
> > UTF8String seemingly forced by FPC. e.g.:
> >
> > Old programs assuming local ANSI 8 bit code retrieved from LCL GUI
> > components, compiled with the new version don't wo
In our previous episode, Felipe Monteiro de Carvalho said:
> And I say more, two RTLs will immediately cause problems in all kinds
> of libraries.
Why?
> Will the FCL work with the Ansi RTL, with the Unicode
> RTL, with both?
Generally both, and problematic packages are not coded in "string" bu
In our previous episode, Hans-Peter Diettrich said:
> >> Unicode users have no use for an char type, instead they have to use
> >> substrings for every logical character. A Unicode BMP user could be happy
> >> with a 2-byte char, of course, at his own (low) risk.
> >
> > Probably. But while a goo
In our previous episode, Felipe Monteiro de Carvalho said:
Note that this is all my, not necessarily core's opinion.
> On Thu, Sep 15, 2011 at 9:14 PM, Marco van de Voort wrote:
> > The assignfile() etc routines are actually not the problem. The classes in
> > the classes
In our previous episode, Jonas Maebe said:
> > disaster. I don't want to create and maintain UTF8 versions of
> > nearly every
> > class, even when the class doesn't actually do anything UTF8 specific.
>
> If we support an UTF-8 version of the RTL, then either the code must
> work both for UTF
In our previous episode, Tomas Hajny said:
> .
> > In the UTF8 RTL, all "string"s _ARE_ utf8, unless specified otherwise (by
> > naming them unicodestring or ansistring(..encoding) or shortstrings).
> >
> > So the same virtual method with a STRING parameter will be TUnicodestring
> > in the UTF16
In our previous episode, Luiz Americo Pereira Camara said:
>
> Take the example of FileExists:
>
> The current LCL implementation - the UTF8 -> UTF16 conversion is done
> with the need of auxiliary code:
All the routines you name (fileexists, filegetattr etc) will become
rawbytestring and accep
In our previous episode, Martin Schreiber said:
> TField.SetData() in fixes_2_6 calls TField.Validate().
> 2.4.4 does not, trunk neither.
> What are the plans for the upcoming release? Will FPC 2.6.0 call
> TField.Validate() in TField.SetData()?
It's on the list to be merged:
http://www.stack.nl
In our previous episode, Fl?vio Etrusco said:
>
> That's somewhat what I was thinking. Actually something like
>
> UnicodeString = object
> strict private
> FEncoding: Integer;
> FBuffer: AnsiString;
> function GetCodePointAt(AIndex: SizeInt): Integer;
> procedure SetCodePoint
In our previous episode, cobines said:
>
> Can the commit nr 18230 be merged into FPC 2.6 ?
>
> Thanks in advance, simple yes or no will suffice.
I do most of the merging, but I don't merge compiler revs unless I get a
green light from the compiler devs.
_
In our previous episode, DaWorm said:
> >
> > So instead of O(n) this loop suddenly becomes O(n^2)
>
> Sure it does. So what?
So much!
> The point is, it will do what the user expects.
No it doesn't. The user has no clue, and will just stumble on the next
detail (like codepoints not being
In our previous episode, DaWorm said:
> But isn't it O(n^2) only when actually using unicode strings?
> Wouldn't you also be able to do something like String.Encoding := Ansi
> and then all String[i] accesses would then be o(n) + x (where x is the
> overhead of run time checking that it is safe to
In our previous episode, Fl?vio Etrusco said:
> compatibility feature, and as such should care more about correctness
> and ease-of-use rather than performance. I thought the endless bugs
> WRT to char vs codepoint indexes, even in Java-developed software,
> would buy my argument...
IMHO you are s
In our previous episode, Fl?vio Etrusco said:
> > IMHO you are seeking the problems in the tools, while the problem is PEBKAC
>
> I partly agree it's PEBKAC, but why make it easy to get wrong when you
> can avoid it?
The point is you can't. You only keep the illusion you can marginally longer
at
In our previous episode, Felipe Monteiro de Carvalho said:
> I would like to add a new package to Free Pascal into the directory
> packages/fputf8 which will provide classes and routines for UTF-8
> applications. It might grow to include things like:
>
> * full unicode tables and conversion routin
In our previous episode, Felipe Monteiro de Carvalho said:
>
> Not really. One can write a non-visual library which uses utf8string
> as its main string type, why not? But the RTL is not adequate for
> utf8string projects
True, because we never planned to have support for such utf8 only libraries
In our previous episode, Pierre Free Pascal said:
> I tried to get i386-openbsd port up to date,
I had a openbsd 4.8 VM lying around, so I tried my usual cross bootstrap
routine (I'm lazy, you don't need crossbinutils on BSD systems since they
can run the linux bootstrap compiler)
What I did (pre
In our previous episode, Graeme Geldenhuys said:
> I'm not sure where to ask for this, but Michael mentioned that all
> backports are handled by Marco.
>
> So Marco, can the following minor fpdoc fix be backported to FPC 2.6.0
> please.
Was already done 2011-09-25, r19231
In our previous episode, Graeme Geldenhuys said:
> I got an email from a Delphi XE2 user busy working on a 64-bit patch for
> tiOPF3. A few things he noted, which I see is different to how FPC done it.
>
> Under 64-bit FPC we have the following:
>
> PtrInt = Int64;
>
> NativeInt = PtrInt;
>
In our previous episode, Marco van de Voort said:
Some status update after some play yesterday evening:
1. The commit from Pierre for the exit syscall seems to work. Exe's don't
crash anymore.
2. Some other minor fixes for stat record (as of yet uncommitted, as I still
have to chec
In our previous episode, Tomas Hajny said:
> > Some status update after some play yesterday evening:
> .
> .
> > 4. The next big crash is, as usual for a new port, in
> > fexpand/expandfilename/readdir.
> .
>
> I assume you probably meant FindFirst rather than FExpand/ExpandFileName,
> right? F
In our previous episode, Pierre Free Pascal said:
> The ones with compat are probably OK,
No, they are old syscalls only kept for compatibility. That means you also
have to use the corresponding old syscalls.
I also think the getdents=getdirentries "alias" is not entirely correct.
It is possible
In our previous episode, Leonardo M. Ram? said:
> Pierre, glad to hear that. What compiler did you use to bootstrap?.
> I've downloaded one from FreePascal's ftp, but it gives me "Bad system call"
> when I run it.
As said, easiest is to use a linux binary. All three BSDs can run linux
binaries
In our previous episode, Leonardo M. Ram? said:
> Problem confirmed:
> ? I use Sys call number 312 for getdirentries
> but for 4.4, the last system call is 310.
>
> ? I tested if getdirentries35 works OK,
> I was able to do a gmake cycle on a 4.4 openbsd.
>
> Committed in 19423.
For me the one b
In our previous episode, Pierre Free Pascal said:
> > (*) FreeBSD's pipe command contains an optimization. The array is not
> passed
> > to the syscall, and the results are stored in regs, not in the array. The
> > wrapper code stores the regs in the array.
> The current FreeBSD code is i386/x86_
In our previous episode, Martin said:
> Now my question.
> Is there (or going to be) an encoding, that is "unknown" and will never
> be converted. but can be assigned to any of the types?
Afaik, there is no such thing in Delphi.
___
fpc-devel maillist
In our previous episode, Jonas Maebe said:
> That would not change the meaning of the "string" type. The code in
> rtl/classes would then use a custom string type (RTLString or whatever)
> that is defined as either an utf8string or a unicodestring based on some
> define.
I did plan to make the st
In our previous episode, Martin said:
> What encoding does a pchar have?
pchar and char match string.
> what happens (or is intended to happen), if I cast a string to pchar,
> before handing it over as param?
Nothing. If you try to cast another type, it probably does a conversion and
create a
In our previous episode, Hans-Peter Diettrich said:
> > And what happens if an app did read data from some external source
> > (serial port) and then wants to declare what encoding it is?
>
> That's not different from the current situation. Network communication
> must agree about the encoding t
In our previous episode, Pierre Free Pascal said:
> You were right, it didn't help much:
> http://www.freepascal.org/testsuite/cgi-bin/testsuite.cgi?os=7&cpu=8&version
> =0&date=&submitter=&machine=&comment=&cond=
>
> > 2) Did you test with elf binwriter ?
> It took me a long time to understand
In our previous episode, Michael Schnell said:
> I suppose there is a way to just set the encoding of a new string. This
> should not affect the stored bytes (or words or DWords).
Afaik it does, but only for ansistring. IIRC there is also a codepage that
just means "system default" and assumes th
In our previous episode, Hans-Peter Diettrich said:
> > components under Lazarus/LCL ecosystem that would need such change. Also
> > porting Delphi VCL components would be a lot harder.
>
> IMO Lazarus (and FPC) should follow the Delphi way, with strictly
> separate Unicode and pre-Unicode versi
In our previous episode, Sven Barth said:
> is that a new mode DelphiUnicode and a new modeswitch Unicodestrings
> will be introduced which do exactly what Delphi 2009 has done: change
> the default string to UnicodeString. But unlike Delphi this will be
> possible on a per unit base. (That the
Building a snapshot now works fine, shared linking and IDE inclusive. The IDE
isn't
built standardly yet though, so not in the snapshot
I uploaded an initial snapshot to
ftp://ftp.freepascal.org/pub/fpc/snapshot/v27/i386-openbsd/
___
fpc-devel maill
In our previous episode, Hans-Peter Diettrich said:
> > Please explain what you mean by "unicode" and what by "ansi" in your
> > statement. Without nuancing that, your statement is pretty much meaning
> > less.
>
> AFAIR Delphi changed the string type to Unicode (UTF-16) in D2009, i.e.
> D2007 wa
In our previous episode, Jonas Maebe said:
> > I know that Florian and you wanted to see the default string as something
> > of a
> > dialect mode, but I never saw a way to do that practically.
>
> How about this: a new language feature is added to the compiler that
> enables defining a type alia
In our previous episode, Michael Schnell said:
> > deal seems to be an attempt to avoid an own development, what already
> > failed with both Kylix and Delphi.NET.
> instead of Kylix they now with XE2 provide FPC and instead of Delphi.NET
> they sell Prism. Both are 3rd party products, too.
No, t
In our previous episode, Felipe Monteiro de Carvalho said:
> RTLString = string;
>
> It would not need to be used anywhere in the RTL, but files which use
> the utf8string directive can use this string type to reffer to the RTL
> string type.
How do you override classes that are declared in RTLSt
In our previous episode, Felipe Monteiro de Carvalho said:
> I dont fully understand your question, but lets suppose this RTL file:
>
> unit system;
> {$mode string = banana}
> type RTLString = string;
>
> unit classes;
> {$mode string = banana}
> type
> TWhaeverClass = class
> procedure Do(P
In our previous episode, Felipe Monteiro de Carvalho said:
[ Charset ISO-8859-1 unsupported, converting... ]
> On Thu, Oct 13, 2011 at 10:47 AM, Marco van de Voort wrote:
> > But I don't consider this as solution. You have to put each string type in
> > the entire libraries o
In our previous episode, Sven Barth said:
> I think he ment that if such a feature is introduced it would be a
> natural conclusion to define "string = unicodestring" on Windows and
> "string = utf8string" for Unix in the RTL and the FCL (and maybe "string
> = ansistring" for DOS and OS/2). Thus
In our previous episode, Martin said:
> > it. Anything else will break as soon as the default is changed from
> > one compiler version to another.
> >
> But maybe a switch could be added, where an fpc exe gives feedback, what
> it currently defaults to?
in the case of the multiple RTL situation,
In our previous episode, Sven Barth said:
> > the utf* designates the type of the default string type. And the same for
> > unix. Maybe win32-ansi too.
>
> Ok... that you want multiple distributions per platform is clear now.
> But you would not oppose (in the case of having multiple distributio
In our previous episode, michael.vancann...@wisa.be said:
> > 2. Try a blanket {$H} to make the default stringtype what you want, and fix
> > problems (e.g. overrides of methods, passing to var params).
>
> The blanket {$H} seems like the way to go for most packages.
> If we insert {$H ANSISTRIN
In our previous episode, Sven Barth said:
> > The difference is more that I don't think it will solve as much as people
> > think, and using this to stitch together code from different origins will
> > fail miserably or be unworkable.
>
> For non-inheritance-related code that is encoding-agnostic
In our previous episode, Felipe Monteiro de Carvalho said:
> > Out of curiosity: how did you come to that conclusion? According to what I
> > read in rtl/inc/systemh.inc "PChar" is still defined as an "^Char" and
> > further down is also an alias "AnsiChar = Char", so "PChar" should still be
> > an
In our previous episode, michael.vancann...@wisa.be said:
> > The more procedural packages yes. The OOP ones not, since their stringtype
> > must match classes for overrides.
>
> Yes, but
> 1. this is the smallest group, so I don't consider that a problem.
Only in number of packages.
> 2. I dou
In our previous episode, Martin Schreiber said:
> Suggestion: Let it be as it is in fixes_2_6, add support for Unicode
> resource strings and invest power into development of Delphi like packages
> for example.
That is already not an option anymore, with the newstr branch merged in.
And while th
In our previous episode, Martin Schreiber said:
> > And while that is an option for you, it doesn't satisfy anybody else. Not
> > even the ones that want as close to D2009 compatibility as possible, since
> > they also need the new ansistring type here and there.
> >
> Hm, even Embarcadero can liv
In our previous episode, Michael Schnell said:
> >
> > No, they have something else like TUnicodeRec or so.
> >
> Which does not provide a CodePage element ???
Afaik tansirec (d2009 style)=tunicoderec (d2009) style.
The rawbytestring type afaik depends on that, that any string can be passed
to it
In our previous episode, Craig Peterson said:
> >> Plus, isn't Embarcadero pushing FireMonkey anyway?
> >
> > I don't see it that way. I see FM as a Delphi PHP/3rd Rail/Prism like
> > product, not as serious VCL contender. If I understood it correctly, it is
> > mostly a sideproduct of internal eff
In our previous episode, Jeppe Gr?sdal Johansen said:
> > And from that point to the present (19505 or so) using instructions
> > from the target embedded wiki page:
> >
> > make clean buildbase installbase CROSSINSTALL=1 OS_TARGET=embedded
> > CPU_TARGET=arm SUBARCH=armv4
> >
> > the build fails
In our previous episode, Jonas Maebe said:
> > How to define this ifdef?
> >
> > Maybe it could be fixed either by dynamic loading or weakexternal directive?
>
> Or we require libiconv also under Linux (and link against it; currently we
> only link against libc under Linux and use its -apparently
In our previous episode, Jonas Maebe said:
> > Does weaksymbol works on all platforms where cwstrings is used (I know
> > that it is not implemented on windows at least but there we don't need
> > cwstrings too)?
>
> Good question, and I'm afraid the answer is "no"... At least
> http://wiki.freepa
In our previous episode, Michael Van Canneyt said:
>
> Correct (I had checked as well), but the only purpose that serves
> is to check whether the system timezone info has changed.
>
> This is something that normally doesn't happen unless you move your
> system from one timezone to another or d
In our previous episode, Henry Vermaak said:
> Also, how cheap is this on Windows? Presumably they will also have to
> deal with potential system services running while updates fix daylight
> saving time changes? If they don't use shared memory for this, I'd
> wager that it's just as slow as l
In our previous episode, Henry Vermaak said:
> >> saving time changes? ?If they don't use shared memory for this, I'd
> >> wager that it's just as slow as libc localtime.
> >
> > I doubt Windows has a _file_ based concept of timezone.
>
> Explain?
It has an in memory concept of timezone, and does
In our previous episode, Jonas Maebe said:
>
> > That is an symmetrical argument. I could argue exactly the same about
> > correctness. I don't need it, so please don't force it on all users.
>
> I suppose you meant that what is correct and what not depends on the
> specification, rather than tha
In our previous episode, Tomas Hajny said:
> I don't get the relation of plugins to the original problem. You don't
> need any libc (c*) to solve that problem,
It does if the solution to monitor filesystem change does, or if you need or
want to use a thread for that. So it is not for the time fun
In our previous episode, Jonas Maebe said:
> Anyway: a function that reports the local time is simply
> the wrong tool for the job if you need a "mostly" monotonic timer that
> you can query at a high frequency. It may work (and apparently it does
> for you), but instating a plugin architect
In our previous episode, zeljko said:
> > So, according to POSIX clock_gettime(CLOCK_MONOTONIC) is supported on
> > linux, bsd and others, and in that case we can have exact GetTickCount.
> > If there's no support for monotonic clock on some platform , now() can be
> > returned anytime.
> Forget
Hello,
We have placed the first release-candidate of the Free Pascal Compiler
version 2.6.0 on our ftp-servers.
You can help improve the upcoming 2.6.0 release by downloading and
testing this release. If you want you can report what you have done here:
http://wiki.freepascal.org/Testers_2.6.0
Ch
In our previous episode, Felipe Monteiro de Carvalho said:
> > Having a separate Android target that reuses files from the Linux directory
> > and adding defines for that is fine (all Unix rtls share files that way).
>
> This does not make the slightest sense. So the files in the linux
> director
In our previous episode, Sven Barth said:
> > Android isn't a different architecture (if you consider native
> > applications), but a different OS. It uses a Linux kernel (although even
> > that one is heavily patched, afaik), and user land is obviously quite
> > different (including the C libra
In our previous episode, Sven Barth said:
> On 15.11.2011 12:41, Michael Schnell wrote:
> > While neither A nor B is Delphi XE compatible in any way, C seems a bit
> > similar to what Emb does. But AFAIK, Delphi does not provide an
> > unambiguous, well defined and understandable paradigm (such as
In our previous episode, Sven Barth said:
> >> But FPC also supports different C libraries (at least glibc and uclibc).
> >
> > Do we? Formally I mean? A few patches that allow interested people to play
> > with it, is something else from a supported target.
>
> I don't know whether it's formall
In our previous episode, Michael Schnell said:
[ Charset ISO-8859-1 unsupported, converting... ]
> On 11/16/2011 10:44 AM, Marco van de Voort wrote:
> >
> > It's a mix of all three actually. It is typed(A), there are two (B)
> > implementations, and the memory layout of
In our previous episode, Michael Schnell said:
> > Then there were fully dynamic encoding schemes proposed too (e..g by
> > Florian).
> I do know this. There seems pros and cons have been discussed, but no
> real decision has been done (i.e. a strict independent understandable
> definition of wha
In our previous episode, Sven Barth said:
> > Is there a general type dedicated for being able to hold any encoding ?
> > (be it ANSIxyz, UTF-8 or UTF-16) ?
>
> In theory the AnsiString type (which is now the code page aware string
> type) should be capable of holding UTF-8 and UTF-16 data, but e
In our previous episode, Graeme Geldenhuys said:
> > like this: I still can't remember which of SmallInt and Short is the 1
> > Byte and the 2 Byte variant. Some type names like "Signed8" and
> > "Unsigned16" would simplyfy this... but I won't go more into that
> > direction now ^^
>
> For exactly
In our previous episode, Sven Barth said:
> >
> > This was my first guess as well, but deactivating online-scanning didn't
> > help. So I uninstalled BitDefender completely, and now it worked :-)
>
> It's fascinating how much can be broken by an anti virus program -.-
If you want the full experie
In our previous episode, michael.vancann...@wisa.be said:
> > INF or HTML), and replaced them with simple command line programs that
> > can be compiled from: fpc somecoolutitility.pas
> >
> > You then have TProcess, the whole RTL and FCL at your disposal. MUCH
> > more powerful than scripts or ma
In our previous episode, Thaddy said:
> There's a documented delphi version: almost complete D7 support *by the
> compiler* and by now d2006 now almost feature complete.
That goes for the release branch that is already in freeze. New features
will go into trunk, which will have, among others, the
In our previous episode, Hans-Peter Diettrich said:
> In my review of the fpdoc project option some questions popped up. The
> most important question: should fpdoc be usable for creating online help
> only, or should it also allow users to create offline documentation on
> their local machine?
In our previous episode, michael.vancann...@wisa.be said:
> > will reside in an unrelated directory branch, so that all references to the
> > FPC documentation depend on the directory structure of the user machines.
>
> Explain why you think this requires a fixed directory structure ?
In plain h
In our previous episode, michael.vancann...@wisa.be said:
> > (so rtl/xxx/yy.html referencing fcl/zzz/ooo.html is done by generating a
> > link to ../../fcl/zzz/ooo.html )
> >
> > But this is an html format problem, not a fpdoc problem.
>
> I thought the cross-references are done based on the loc
In our previous episode, Hans-Peter Diettrich said:
> commandline, which are not handled properly by the Windows shell. I
> fixed this manually, by editing the Makefile.
>
> Next I get the following error messages:
Afaik the docs are hardwired for Linux. Even if you are on host windows, you
shou
In our previous episode, Graeme Geldenhuys said:
> My main problem at the moment is again the Latex format.
Manipulate the generated HTML?
> It is very hard to convert LaTex to any other format (and still look
> good). This was the main reason I wanted to implement ePub support. But
> maybe a b
In our previous episode, Tomas Hajny said:
>
> Is this the right fix? Shouldn't it be possible to generate docs based on
> other targets as an option?
What do you expect from that, other then that a few symbols disappear ? (that
are hopefully already annotated as platform specific?)
In our previous episode, Graeme Geldenhuys said:
> I've always wonder about the very verbose command line parameters used
> with fpdoc. Why couldn't the XML simply mention which unit(s) it
> documents. You could also include macros [eg: $(somemacro) ] which
> fpdoc could substitute when the xml fil
In our previous episode, Graeme Geldenhuys said:
> > First, it keeps the actual documentation XML more "clean" in the sense that
> > it contains only documentation, and not 'organizational instructions'.
>
> The documentation is useless unless you have the associated *.pas
> unit. As you even ment
In our previous episode, Graeme Geldenhuys said:
> > And the contents in the XML is _NOT_ dependent where exactly those files
> > are, as long as fpdoc can find them.
>
> Exactly my point. fpdoc cannot generate documentation without knowing
> where the the *.xml _and_ *.pas files are.
True.
> So
In our previous episode, Michael Van Canneyt said:
> > nobody else's ideas count any more from that point on. Core developer
> > has spoken! :-( One has to love the way the FPC team works.
>
> Unfortunately, Graeme, you are mistaken in your facts.
>
> The fpdoc project file support already exist
In our previous episode, Graeme Geldenhuys said:
> > When we want to distribute fpdoc project files instead of scripts, a user
> > should not have to edit these files - after every SVN update :-(
>
> They wouldn't have do it every time after a SVN update. SVN (the last
> time I checked) does not o
In our previous episode, Marco van de Voort said:
> Some things in the latex parts were fixed (but there is still a bit of
> shellscript somewhere).
(for the people wondering, it is the for loop in Makefile.4ht)
___
fpc-devel maillist - fpc
In our previous episode, Hans-Peter Diettrich said:
> I could build RTL and FCL docs from 2.4.2 without major problems (the
> trunk Makefile was not fully compatible with the old directory structure).
>
> But when I tried to build the LCL, fpdoc crashes badly in
> THTMLWriter.AppendProcType (SIG
In our previous episode, Sven Barth said:
> > The -v option should become more verbose, just for hunting such bugs.
> > And the messages should go to stdout instead of stderr, at least on
> > Windows (with poor redirection capabilities).
>
> StdErr redirection works in Windows the same as on Unix
1 - 100 of 2314 matches
Mail list logo
