On 09/09/2011 14:34, Mark Morgan Lloyd wrote:
> Is there a "correct" way of telling the build process to skip the fp
> IDE?
Delete the 'ide' folder? :)
A 'svn revert' can always restore it later.
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://
On 11/09/2011, Jonas Maebe wrote:
>
> Neither DWARF 3 nor DWARF 4 supports properties. I'm not aware of anyone
> submitting a proposal to add them to the DWARF standard either. See e.g.
I was under the impression that you could now define (at least with
DWARF3 upwards) your own types or language
On 11/09/2011 23:40, Jonas Maebe wrote:
> extensions. I don't see the advantage of allocating one of those and
> communicating it to other compiler writers (to avoid them using that
> same extension for something else) instead of submitting it for
> inclusion in the official DWARF standard though.
Hi,
Speaking of the subject in another thread, and to show the desire I have
to finding a solution to this [what I consider a very serious] problem
FPC needs its own debugger! GDB is just rubbish when it comes to the
Object Pascal language. Also if FPC had it's own debugger, the time it
would
On 12/09/2011 09:13, Jonas Maebe wrote:
>
> You don't have to wait until it is published. Both gcc and gdb
> supported provisional DWARF4 features before the standard was out.
And then standing the chance of it being reject - thus doing the
implementation in GCC and GDB all for nothing. But may
On 11/09/2011 13:51, Skybuck Flying wrote:
>
> The P5 code is not properly indented.
Now you are on the border line of ridiculous! Simply run the code
through JCF (Jedi Code Formatter), and the code will look exactly as you
specified in all of 2 seconds!
Regards,
- Graeme -
--
fpGUI Toolki
On 12/09/2011 10:21, Michael Schnell wrote:
> On 09/11/2011 07:33 PM, Hans-Peter Diettrich wrote:
>> 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.
Regards,
- Graeme -
--
fpGUI Toolki
On 12/09/2011 11:43, Martin wrote:
>
> The debugger itself (in my understanding) can either have a library-like
> interface or command-line driven or both.
Duby already has both (in rudimentary form). At this point I will be
fine with a command-line debugger only, that can actually debug my code
On 12/09/2011 13:00, Martin Schreiber wrote:
>
> True. And maintaining all platforms is a fulltime job too.
Maintenance should be MUCH less work than the initial implementation. So
I don't consider this too a big problem. FPC doesn't change that
radically that often.
> And a FPC only debugger ca
On 12/09/2011 12:45, Nikolai Zhubr wrote:
>
> I'd also happily contribute $300 or so (in case there is a reasonable
> chance to actually get it working at least on windows/linux/bsd)
>
> However, the effort needed is probably much much more expensive
Well, considering the about of people that
On 12/09/2011 13:32, Martin Schreiber wrote:
>
> I think it is better to invest time into gdb support instead into a FPC
> debugger which probably never will reach a usable state.
[sarcasm on]
With that attitude the same could be applied to MSEide, MSEgui and fpGUI
too. Why did we bother investin
On 12/09/2011 13:30, Martin Schreiber wrote:
> ???
> EUR 100'000..200'000? Really?
Yes, we all know your rates a much higher than others - so we will not
ask you to do the work.
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.ne
On 12/09/2011 13:49, Martin Schreiber wrote:
> True. And because we know what it means to develop something new from scratch
> and because I know that I don't want to invest several years into development
> of a FPC debugger and because we know that there are not so many people who
Please have a
On 12/09/2011 14:07, Paul Ishenin wrote:
> I also want to know. Imo, you are loosing your time :)
[off-topic: so this will be my last public response to this]
No, fpGUI has now reached a point where I can knock out apps in a
fraction of the time it took me 5 years ago. Also those apps are
conside
On 12/09/2011 14:57, Dimitri Smits wrote:
>
> I don't disagree with the need for a prime debugger, nor with the
> amounts of bounty everyone is offering, just with the statements
> above.
I still stand with my statement that it will NOT cost 100,000 - 200,000
euros to get a basic working debugger
Hi,
Below is a quote from the documentation of the ApplicationName() function:
"Standard this is equal to the result of ParamStr(0), but it can be
customized by setting the OnGetApplicationName callback."
This seems incorrect, as the following test program shows.
--[ test1.pas
On 13/09/2011 11:02, michael.vancan... wrote:
>>
>> I have adapted the docs.
Thanks.
> By the way, the second paragraph in the help already contained this info.
Yes I saw that, but the original two paragraphs seem to contradict
themselves. So a clarification seemed in order. ;-)
Regards,
-
On 12/09/2011 22:37, Hans-Peter Diettrich wrote:
>
> I expect that RTTI is used by an FPC debugger, but I don't expect that
Not at all! The debugger I am working on ONLY reads the debug
information embedded in the executable - in my case DWARF info supplied
by FPC.
Regards,
- Graeme -
--
f
On 13/09/2011 01:43, DaWorm wrote:
> I don't understand why a property with a getter could ever be ran by a
> debugger. If I have a property called NextValue, implanted by a method
Yes, yes, but I am a big boy and know what I am doing, so I do NOT want
the debugger to limit what I am allowed to d
On 13/09/2011 00:37, Jonas Maebe wrote:
>
>> Maybe this will help?
>>
>> make.exe all OPT="-gl -gw -godwarfsets -O1 "
>
> You should use -O-1 instead of -O1. The default for "make all" is
> "-O2", and "-O2 -O1" is the same as "-O2" (it says "enable -O2
> optimizations and also -O1 optimization
On 13/09/2011 14:33, Jonas Maebe wrote:
>
> No, he's saying that it should not be easy to do this accidentally. I
> can imagine that in IDEs that evaluate everything your mouse cursor
> happens to hoover over, automatic evaluation of getters with side
> effects can be quite an annoyance.
Ag
On 13/09/2011 14:53, Jonas Maebe wrote:
>
> -O-1 is the same as -O- -O1 (just like -vwn is the same as -vw -vn --
> all single-character FPC options behave that way).
OK, thanks.
> -O- and -O1 are both listed in the overview of the command line
> options of the Programmers Guide (Appendix A
Hi,
I noticed I still have the 2.4.2 PDF docs, so went to the freepascal.org
website and downloaded the online versions just to notice that they
are 2.4.2 as well.
The updated docs are on SourceForge though.
Can anybody update the PDF docs in the following URL please?
http://www.freepas
On 13/09/2011 14:48, Michael Schnell wrote:
> If we could really hope for this, I would vote for a gdb extension
> instead of creating a completely new debugger from scratch .
I disagree. In the long term, I think a object pascal based debugger for
FPC is the way to go - potential for much easier
On 13 September 2011 16:52, Hans-Peter Diettrich wrote:
> That's why Delphi normally checks for changed values only when a breakpoint
> is hit, not on every instruction.
That makes no sense at all! A watchpoint should trigger as soon as
that data referenced by some memory address changes. Then y
On 13 September 2011 17:10, Juha Manninen wrote:
>
> Graeme, are you working on Duby or some new debugger?
I'm working on Duby, but all changes are local to my system. I don't
have commit rights to Duby on SourceForge - though I never asked.
I'm also not sure if the original author of duby would
On 13 September 2011 21:25, Marcos Douglas wrote:
>
> Graeme Geldenhuys, sometime, written that string type shoud be
> depended of plataform. I agree with him, but I don't know if this is
+1 ;-)
> the easiest way... but this is be best way to codify our programs,
On 14/09/2011 03:56, Luiz Americo Pereira Camara wrote:
>
> I propose that the above behavior be implemented as a type named RTLString
The Object Pascal language already has enough damn string types. I
really don't think we should be adding fuel to the fire, by adding yet
more string types!
> S
Reported it in Mantis so that is does not get forgotten.
http://bugs.freepascal.org/view.php?id=20238
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/
___
fpc-devel maillist -
On 13/09/2011 21:23, Michael Van Canneyt wrote:
> Current strategy on fpc core seems to be to have 2 RTLs:
>
> One with unicode string, one with ansistring.
Can you clarify a bit. When you say "unicode string" to you mean UTF-16
(Delphi's definition of a unicode string), or do you mean a Unicode
On 14/09/2011 11:19, Luiz Americo Pereira Camara wrote:
> This is not desirable simply because at each platform (windows / unix)
> the user code of the same program will have a different encoding
> increasing the possibility of subtle errors.
Why? Not every program is a text manipulation program
On 14/09/2011 11:04, Felipe Monteiro de Carvalho wrote:
>
> IMHO a platform-dependent string would be the worse solution of all
> ... far worse then migrating to UTF-16.
I don't see why? Use the RTL functions to manipulate your text strings.
Both the string and RTL functions will use the same e
On 14/09/2011 17:02, Hans-Peter Diettrich wrote:
> Many users still want simple string handling, with direct mapping
> between logical and physical chars (SBCS). This is not possible at all
> with UTF-8, while UTF-16 works fine with the BMP, at least.
What rubbish! The only "utf-8 limit" is
On 15/09/2011 06:19, Martin Schreiber wrote:
>
> Agreed. And so it is made in MSEgui:
Yeah, and everything you said applies to fpGUI, except I use TfpgString,
TfpgChar and the UTF-8 encoding. Though I would prefer having the
native encoding on each platform - thus less conversions and i
On 15/09/2011 09:43, Michael Schnell wrote:
> there are lots of file systems in Linux. They can work differently. i.e.
> FAT works case insensitive while ext* works cases sensitive. IMHO ext
> completely ignores character coding and just works on byte arrays.
You also forgot to mention that most
On 14/09/2011 19:17, Hans-Peter Diettrich wrote:
>
> How many users will have to deal with chars outside the Unicode BMP?
You are very narrow minded! It depends on the application you are
developing. Lets take a Science application as an example. Many
scientific symbols fall ou
On 15/09/2011 10:16, Michael Schnell wrote:
> In fact users want to deal with "decently coded characters" and not
> with "cryptic bytes some of which together are representing a
> character". (e.g. when doing MyChar := MyString[1]; )
None of our company's users using our products woul
On 14/09/2011 20:47, dmitry boyarintsev wrote:
> really a standard in GDB (i can be wrong). But I've seen a lot of
> issues in Lazarus gdb-support, because of the different builds of GDB
> used.
Exactly the reason we need a FPC based debugger. Currently each Linux
distro includes a different versi
On 15/09/2011 09:53, Michael Schnell wrote:
> If not strings, Chars do:
>
> MyString := 'Öse';
> MyChar := MyString[1];
and to show you AGAIN how flawed your "direct index access to a
character" example is. How is that 'Öse' entered into the system.
Is the Ö a
U+00D6 LATIN CAPITAL LETTER O W
On 15/09/2011 11:06, Felipe Monteiro de Carvalho wrote:
>
> It would solve for those writing buggy software which ignores part of
> the Unicode characters.
>
> On the other hand 100% of them would be solved correctly, for all
> Unicode characters by using LCLProc.UTF8CharacterLength
+1 on both
On 15/09/2011 10:59, Martin Schreiber wrote:
>
> There are plenty of user problems with utf-8
Then they are not well versed in Unicode are they...
> character access
in fpGUI:
UTF8Copy(...)
UTF8CharAtByte(...)
> and string length.
in fpGUI:
Length(...) result is in bytes
UTF8Len
On 15/09/2011 11:38, Michael Schnell wrote:
> is bound to create problems. But it is what generations of pascal
> programmers are trained to do. They all need to be re-trained.
Just like all Delphi developers had to since Delphi 2009+. Obviously,
the RTL could cater for it, or implement more obv
On 15/09/2011 13:52, Marcos Douglas wrote:
>
> And you will provide these patches, from SVN/Git, right? =)
Yes of course. Now that I know Dmitry's goals for Duby is quite
different to mine [based on his recent posts], I'll publish it to GitHub
in due time - with a different project name to preve
On 15 September 2011 18:43, Hans-Peter Diettrich wrote:
>
> UTF-8 is much more complicated to handle by the user, than e.g. UTF-16.
I don't see this. Please give an example?
--
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI to
On 15 September 2011 17:21, Felipe Monteiro de Carvalho wrote:
>
> // file operations
> function FileExistsUTF8(const Filename: string): boolean;
> function FileAgeUTF8(const FileName: string): Longint;
fpGUI has similar, for file handling functions.
> With the currently planned Unicode RTL
On 15 September 2011 19:09, Hans-Peter Diettrich wrote:
>
> What data type would you use, to store an UTF-8 character?
> And how to access the n-th character in an UTF-8 string?
I already showed how in a previous post. For more details on how fpGUI
does this, have a look at the fpg_base.pas and f
On 15 September 2011 20:52, Hans-Peter Diettrich wrote:
> When I want a program for German or French users, I'll hire an coder with
> experience in those *languages*, not with experience only in Unicode.
Why? We simply hired average people (not programmers) to translate
your English resource strin
On 16/09/2011 03:49, Hans-Peter Diettrich wrote:
> How many users will have to deal with chars outside the Unicode BMP?
>> Any app that loads a text from disk.
>
> Again: please answer my question first: How many *users*?
Just counted
2,345,237,925
;-)
Regards,
- Graeme -
On 16/09/2011 00:01, Dimitri Smits wrote:
>
> errrm, utf-8 can have 6 octets representing one character,
Last time I checked, that was only in the very early stages of
developing the utf-8 specification. Since then, the maximums size of a
utf-8 code point is 4 bytes.
If you know otherwise, pleas
On 16/09/2011 11:48, Felipe Monteiro de Carvalho wrote:
>
> What about stuff like this in classes:
>
> TReader = class(TFiler)
> function ReadString: string;
> function ReadWideString: WideString;
> function ReadUnicodeString: UnicodeString;
I'm clearly not understanding your (and
I can understand the confusion. There are lots of old and outdated
information regarding UTF-8 on the net.
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/
___
fpc-devel maillist -
On 18/09/2011, Sven Barth wrote:
>
> Currently the POSIX-based systems seem to be broken (the Windows ones
> work). That is already known. The other devs are working on that.
And it boggles the mind why something so broken / incomplete was
merged into Trunk in the first place? Isn't that the whol
On 01/10/2011 12:56, Mattias Gaertner wrote:
>>
>> Is that correct? Does the old Makefile driven compilation use both/all
>> cores, while packages done via fpmake, are using one core only?
>
> AFAIK the makefile does not use parallel compilation.
Yes it does, at least for compiling FPC itself (o
Hi,
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.
http://bugs.freepascal.org/view.php?id=20318
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI
Hi,
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;
But apparently under 64-bit Delphi XE2
PtrInt = Integer
On 07/10/2011 15:27, Marco van de Voort wrote:
>
> Was already done 2011-09-25, r19231
Thank you.
Regards,
- Graeme -
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 12/10/2011 11:47, Martin Schreiber wrote:
> idea. Have a look at Firemonkey and you know what I mean. ;-)
For those unfamiliar with Firemonkey, would you mind explaining further.
...but over all, I do agree with your statement, that FPC shouldn't
follow Delphi blindly. Delphi and VCL is Windo
On 12/10/2011 14:38, Martin Schreiber wrote:
>
> Read here for example:
Thanks for the link.
> Is this desirable? What is the benefit of non ASCII Pascal identifiers at the
> expense of performance and simplicity?
No idea if it is desirable - probably not, when it is a global open
source proj
Hi,
I was reading this article about Delphi XE2 floating point performance.
http://delphitools.info/2011/09/02/first-look-at-xe2-floating-point-performance/
Not that I understand much of the assembler generated, but what I did
notice is that Delphi XE2 64-bit uses the MOVAPD function (introduce
On 2011-10-19 16:04, Jonas Maebe wrote:
> The movsd that FPC uses is an SSE2 instruction.
Ah, thanks for the info.
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/
___
fpc-devel m
On 2 November 2011 10:31, Mark Morgan Lloyd wrote:
> But even in this case, what should happen if the user (or NTP) explicitly
> changes the system clock?
NTP client service doesn't explicitly change the system time in one
shot. This could cause all kinds of problems. Instead they slow down
or sp
If you want to do timing, you can also take a look at EpikTimer. I
believe it doesn't work on all platforms that FPC supports, but it
works on the big three (Windows, Linux, Mac).
--
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI
On 3 November 2011 15:55, wrote:
>
> PLEASE NEVER MENTION EPIKTIMER AGAIN.
>
> it returns Now() on all platforms except i386.
Not sure if my version of EpikTimer is the same as yours. Last time we
had this (similar) conversation, your EpikTimer code was out of date
(you still had code which requi
Please stop spreading FUD!
> - dependency on LCL
I have fixed this well over a year or two ago. The only LCL dependency
was the registration of the EpikTimer component on the Lazarus
component palette. I simply split the original lazarus package into
two packages (runtime and design-time) - that
On 4 November 2011 12:39, Sven Barth wrote:
> "fpgettimeofday" itself simply calls the syscall "gettimeofday" of the
> kernel.
I have another "experimental" version of epiktimer that uses the posix
clock_gettime() (instead of fpgettimeofday), which I had to implement
myself, because FPC doesn't i
Hi,
This is the implementation of FileAge() under FPC 2.6.0 (the upcoming release)
---
Function FileAge (Const FileName : String): Longint;
Var Info : Stat;
begin
If (fpstat (pointer(FileName),Info)<0) or fpS_ISDIR(info.st_mode) then
exit(-1)
else
On 17 November 2011 21:51, Seth Grover wrote:
> For what it's worth, in C (compiled with gcc) both
> 64-bit and 32-bit give the same (correct) answer, 733682.6250.
>
For what it's worth, a Java test (compiled under 64-bit Linux) also
gives the answer of 733682.6250.
--
Regards,
- Graeme -
On 2011-11-18 12:11, Michael Schnell wrote:
> Why should a type that is capable of holding multiple different UTF
> encodings be called "ANSIString". IMHO this is very contra-intuitive.
Every time I see this used in Delphi too, I start to laugh as well. It
makes no sense. Call the damn thing Unico
On 2011-11-18 13:04, Jonas Maebe wrote:
>
> http://wiki.freepascal.org/User_Changes_2.2.0#Floating_point_constants
The description of the "new behaviour" should change then. The part that
says "...which doesn't cause data loss" is now false, given Seth's
example. He lost precision compared to pre
On 2011-11-18 13:37, Jonas Maebe wrote:
>
> It says that the floating point *constant* (in Seth's example: 24.0) is
> converted to the lowest precision that does not cause data loss.
My mistake, I read it wrong.
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free
On 2011-11-18 14:41, Sven Barth wrote:
> 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 the same reason I hav
On 29/11/2011, Hans-Peter Diettrich wrote:
>
> A "make -n rtl.chk > test.txt" succeeded, at least. Now I suspect some
> Windows or RTL commandline limitations, which seem to truncate the long
> command lines created by the scripts (4890 chars for rtl.chk).
Does this limitation apply when using T
On 29/11/2011, Sven Barth wrote:
>
> You could try the Jedi Code Formatter included with Lazarus. I've never
> tested it myself, because it is the first thing I disable when
That copy of JCF is bugy. Rather use the original version available
for download on SourceForge, from the JCF project. Also
On 30 November 2011 01:33, Hans-Peter Diettrich wrote:
> 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?
On 30 November 2011 10:11, Marco van de Voort wrote:
> I don't see plain html as a valid target for offline help. I reserve that
> for CHM. With the textmode IDE, the plain html was nothing but pain.
Indeed. HTML lacks a TOC, Index, searching etc. Plus it is verbose and
HUGE in terms of disk spac
On 30 November 2011 22:14, Hans-Peter Diettrich wrote:
> Now you hear some, most probably from the first user of fpdoc on Windows ;-)
I use fpdoc under Windows without problems. Though mostly for
generating documentation for my own projects, not FPC ones. I also use
a console utility program with
On 1 December 2011 13:45, Michael Schnell wrote:
>
> Never heard of same. Is this supposed to replace *.inf ?
No, ePub is a specialised HTML/XHTML archive format. A single file
used for electronic books. It is most often used on tablet pc's, smart
phones and e-Book readers like Amazon Kindle.
On 1 December 2011 15:37, Marco van de Voort wrote:
> In our previous episode, Graeme Geldenhuys said:
>> My main problem at the moment is again the Latex format.
>
> Manipulate the generated HTML?
Yes, I was thinking in that same direction.
>> maybe a better idea is to imp
Hi,
I was playing around this morning with my console app that can
generate a script/batch file to generate documentation for fpGUI.
The content of the script file is every verbose because of the large
set of search path options inside each --input="..." parameter.
I'm not sure how the Makefiles
On 2 December 2011 03:17, Hans-Peter Diettrich wrote:
> exist. It doesn't look good when the docs do not include the most basic
> types, like Boolean, Byte, Char, Pointer etc. :-(
Those are all basic built-in types. Built into the compiler, not
defined in the RTL (as far as I know), but rather the
On 2 December 2011 12:43, Michael Van Canneyt wrote:
>
> You will be pleased to hear then, that we've developed - in FPC - a search
> engine for the HTML docs :-)
Excellent. How fast does it do searching across the RTL and FCL HTML
docs? Does it need to first build a search/keyword database?
I re
On 2 December 2011 09:05, Graeme Geldenhuys wrote:
> Excellent documentation means nothing if you can search and
> find something.
Typo alert!
The above should read: "Excellent documentation means nothing if you
_can't_ search it and find something."
--
On 1 December 2011 13:44, Michael Schnell wrote:
> I (tried to) use DocView (*.inf files) for local help. Seems very
> promising.
I've just released fpGUI v0.8. With that release comes pre-built
binaries for DocView, and pre-built documentation in INF format. You
can download them from the follo
On 3 December 2011 01:59, Michael Van Canneyt wrote:
>> Already included: all XML files are discarded, when they don't contribute
>> to the current package :-)
>
>
> Because of the loose coupling between XML files and source files, there is
> no way to know if a XML file is contributing or not, un
On 3 December 2011 16:03, wrote:
> 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 mentioned earlier. fpdoc doe
On 3 December 2011 17:26, Marco van de Voort wrote:
>
> 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. So currently we
On 3 December 2011 18:42, Michael Van Canneyt wrote:
>
> The former (the documenters) will normally work in Lazdoc or whatever tool
> that supplements the IDE, and the IDE knows where all relevant source files
> are.
Not everybody uses lazdoc! I know I don't. And last time I heard, you
told me yo
On 4 December 2011 20:09, Hans-Peter Diettrich wrote:
> Currently fpdoc stores many options in the project files, but this can cause
> problems. Once a boolean option is stored as True, e.g.
>
> it cannot be turned off by a different commandline option :-(
I know this might sound silly, but sim
On 4 December 2011 16:17, Hans-Peter Diettrich wrote:
>
> I thought about such a simplification, too, but you'll get some objections:
I believe I already have. ;-)
> How then do you want to document files for different platforms?
> (needs to supply different source and include directories)
Macr
On 4 December 2011 18:11, Marco van de Voort wrote:
>
> Because then you can't have multiple projects using the same content and
> sources in different paths.
I'm afraid I don't understand your point? fpdoc is about documenting
API's. Those are rather specific to a single project. Could you suppl
On 4 December 2011 21:41, Hans-Peter Diettrich wrote:
> Where are they defined, what's the syntax for their definition and use, how
> are nested macros expanded, why is my macro not found...
You are over exaggerating a bit. Macros are used all over the place
with great success. FPC, Lazarus IDE,
On 4 December 2011 21:55, Michael Van Canneyt wrote:
>> doubt it will make it into fpdoc. Core developers always trump mere
>> contributors like us. ;-)
>
> We simply have a vision and try to remain true to it.
> Ideas corresponding to this vision will make it. Others not.
Hardly any time was gi
On 4 December 2011 20:40, Hans-Peter Diettrich wrote:
>
> 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 ove
On 7 December 2011 23:09, Hans-Peter Diettrich wrote:
>
> Does there exist a chance (trick) to use the input files of a different
> installation, without copying the description files?
If you use the make command to generate the docs, simply pass the
FPCSRCDIR command line parameter.
eg: m
On 14 December 2011 21:10, Dimitrios Chr. Ioannidis wrote:
>
> i remember some time ago i read here in the list that someone had
> managed to create tool chain to cross compile wince arm from linux.
Try these links from Paul Breneman... Simply unzip, and you are ready
to cross-compile. It can't
On 16 December 2011 14:25, Michael Schnell wrote:
> On 12/16/2011 12:42 PM, Marco van de Voort wrote:
>>
>> It's fine, but like most built-in engines it is not google.
>
> Can it do "and" and "or" and search for multi word strings ?
>
> (In fact I don't know wheter DocView can do these...)
Yes, D
On 16 December 2011 14:51, Marco van de Voort wrote:
>
> They are roughly from the same period, and nearly equivalent in any way.
Not even close, but that is a debate best left for another time.
> And because the format isn't dead.
Didn't Microsoft drop CHM format too? ;-) Anyway, INF is far f
On 16 December 2011 15:10, Michael Schnell wrote:
> I might be inclined to follow in case that there is a script that creates an
> combined CHM file for fpc language, rtl, lazarus IDE, LCL, (and ...) from
> the svn sources.
Which DocView can already do today with the INF files. ;-)
$ docview
On 15 December 2011 17:48, Marco van de Voort wrote:
> Afaik docview does not work within the IDE at all, only via the external
> tools option?
There is no reason it can't work within the Lazarus IDE. I simply find
it easier using the External Tools option of Lazarus IDE, MSEide,
Delphi IDE, etc.
On 16 December 2011 13:33, Marco van de Voort wrote:
> Graeme started working on it when CHM was already mostly
> operational.
"mostly operational" doesn't entrust a lot of confidence.
> Most of his original arguments were based on disk sizes and
> little implementation gotchas, not on functio
1 - 100 of 1762 matches
Mail list logo
