Žilvinas Ledas wrote:
Thanks, it works with named type.
Is using not named specializations is some kind of not implemented yet
part? :)
No it's a design choice to more easily reuse separate (but equal)
specializations.
Micha
___
fpc-devel
On Wed, October 7, 2009 11:27, Micha Nelissen wrote:
Žilvinas Ledas wrote:
Thanks, it works with named type.
Is using not named specializations is some kind of not implemented yet
part? :)
No it's a design choice to more easily reuse separate (but equal)
specializations.
Well, the
Sergei Gorelkin schreef:
Vincent Snijders wrote:
Vincent Snijders schreef:
While running valgrind on fpcdoc, I got a warning in
Maybe you are interested in the valgind output. See attachment.
That check should be removed altogether, in both WideString and
UnicodeString routines.
I just
About the naughty naughts:
This is also the cause of many problems and the main cause of the ssl
certificate hack:
www.paypal.com\0filtyhacker.cr
see ASN.1 and X509. PASCAL strings (with length before string) are for
good reason part of many a specification... C strings are convienient,
but
On Mon, Oct 5, 2009 at 10:27 AM, Mark Morgan Lloyd
markmll.fpc-de...@telemetry.co.uk wrote:
Linking testgdb
/usr/local/lib/fpc/2.2.4/units/powerpc-linux/gdbint/gdbint.o: In function
`GDBINT_INITLIBGDB':
gdbint.pp:(.text+0x1a60): undefined reference to `error_init'
libgdb.a(xml-support.o): In
Felipe Monteiro de Carvalho wrote:
On Mon, Oct 5, 2009 at 10:27 AM, Mark Morgan Lloyd
markmll.fpc-de...@telemetry.co.uk wrote:
Linking testgdb
/usr/local/lib/fpc/2.2.4/units/powerpc-linux/gdbint/gdbint.o: In function
`GDBINT_INITLIBGDB':
gdbint.pp:(.text+0x1a60): undefined reference to
True in principle,
but XML library used for GDb
is expat, so you should
add {$linklib expat.a}
in gdbint.pp
It is generally easier to
first try to compile
testgdb executable
in packages/gdbint directory.
Once this executable links without errors,
with the same libraries, it should
also work
Tomas Hajny wrote:
Well, the internal error is in any case a bug, so if this appears also
with the latest (trunk) version, a bug report would be useful.
I didn't see an internal error? But a more descriptive message would be
useful ('specialization not allowed in this context' or so?).
On Wed, October 7, 2009 18:47, Micha Nelissen wrote:
Tomas Hajny wrote:
Well, the internal error is in any case a bug, so if this appears also
with the latest (trunk) version, a bug report would be useful.
I didn't see an internal error? But a more descriptive message would be
useful
Florian Klaempfl wrote:
Sergei Gorelkin schrieb:
Florian Klaempfl wrote:
So, who will be the first to creat a Mantis entry? :-)
I gave you both access to trunk/compiler/msg, so please update things as
needed ;)
Actually write access and commit as need :)
Ok, that simplifies things: no need
Yes, I had an internal error and now I know why - I used specialization
in function params. This gives internal error:
procedure asdasd(something: specialize TTwoValuesListUnicodeString);
begin
end;
I'll make a bug report tomorow or a day after.
And yes, I think a descriptive message saying to
On Wed, Oct 7, 2009 at 5:50 PM, Sergei Gorelkin sergei_gorel...@mail.ru wrote:
Updating done, revisions 13814 and 13815. Enjoy :)
And criticism is welcome, too.
Great job! Translation is much better than before.
You need to ask russian comminity about it, since they're to use these messages.
Hi,
make all OPT=-gtl in the fpc source fails.
/home/vincent/src/fpc/trunk/compiler/ppc1 -Ur -Ur -Xs -O2 -n -Fi../inc
-Fi../i386 -Fi../unix -Fii386 -FE.
-FU/home/vincent/src/fpc/trunk/rtl/units/i386-linux -gtl -di386
-dRELEASE -Us -Sg system.pp
Fatal: Compilation aborted
An unhandled
13 matches
Mail list logo
