Hi,
31.01.2012 0:08, Pierre Free Pascal:
Anyhow, I just discovered that
the /home directory is 99% full on that GCC compile farm machine,
meaning that only remote tests will be possible ☹
It seems that lots of developers have the same issue about finding
MIPS machines for testing ….
Would you
Just a note to confirm that FPC 2.6.0 builds and installs from source on
SPARC Solaris 10 and 8. I had to revert from 2.5.1 to 2.4.4 on one
machine before it would compile, the other was still on 2.4.2.
I am definitely not complaining, but purely for information I note that
the fp IDE isn't bu
On Thu, February 2, 2012 18:27, Mark Morgan Lloyd wrote:
> steve smithers wrote:
>>> If you try to achieve a port by modifying all code that deals with
>>> characters you will fail. The amount of work becomes then far too big
>>> for
>>> a single person, and the modifications become too huge and wi
steve smithers wrote:
If you try to achieve a port by modifying all code that deals with
characters you will fail. The amount of work becomes then far too big for
a single person, and the modifications become too huge and wide-spread
that you will raise objections for merging it with the SVN trun
On Thu, Feb 2, 2012 at 5:26 PM, Sven Barth wrote:
> You don't have a backup of that project file so that one could look what the
> differences in the options were?
Not really, but I think I have seen strange assembler errors more
often in 2.7, so I will make a copy of the files in question next t
steve smithers wrote the following on 02/02/12 14:38:08:
>
> You can do a build on a PC up to a point. Certainly the assembler output
> could be generated, in whatever format. It may be possible to lob this
> through the assembler and generate object files, I don't know what
> format(s) gas wi
Am 02.02.2012 17:17, schrieb Felipe Monteiro de Carvalho:
The errors disappeared after deleting the lpi and getting a fresh version of it.
You don't have a backup of that project file so that one could look what
the differences in the options were?
Regards,
Sven
The errors disappeared after deleting the lpi and getting a fresh version of it.
--
Felipe Monteiro de Carvalho
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
> If you try to achieve a port by modifying all code that deals with
> characters you will fail. The amount of work becomes then far too big for
> a single person, and the modifications become too huge and wide-spread
> that you will raise objections for merging it with the SVN trunk.
That's a goo
Hello,
I get very strange errors when trying to cross-compiler the LCL to
arm-wince which never happened in FPC up to 2.6
F:\Programas\lazarussvn\lcl\units\arm-wince\customdrawn\customdrawnproc.s:
Assembler messages:
F:\Programas\lazarussvn\lcl\units\arm-wince\customdrawn\customdrawnproc.s:896:
E
02.02.12 19:51, Hans-Peter Diettrich пишет:
What's the codepage/encoding of AnsiString? Depending on the platform?
DefaultSystemCodePage - this const depends on platform
UnicodeString convertions are required when string in one codepage is
converted to another or when ansistring is assigned
In our previous episode, Hans-Peter Diettrich said:
> >> AnsiString, in which situations are UnicodeString conversions really
> >> required, in contrast to pre-UnicodeString versions?
> >
> > The default string type is ShortString/AnsiString and this depends on
> > {$h+/-} option.
>
> What's the
On Thu, 2 Feb 2012, Hans-Peter Diettrich wrote:
michael.vancann...@wisa.be schrieb:
One reason may be the different assumptions about the content of the
FProcessedUnits list, where either the input file part or the entire input
specification is stored. But this seems not to be the only bug
Paul Ishenin schrieb:
02.02.2012 17:00, Hans-Peter Diettrich пишет:
Dumb question: what's the default "string" type in FPC trunk? When it's
AnsiString, in which situations are UnicodeString conversions really
required, in contrast to pre-UnicodeString versions?
The default string type is Sho
michael.vancann...@wisa.be schrieb:
One reason may be the different assumptions about the content of the
FProcessedUnits list, where either the input file part or the entire
input specification is stored. But this seems not to be the only bug :-(
The entire input spec is stored.
Only in Han
On Thu, 2 Feb 2012, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
Well, It took me about 15 lines to implement it in dglobals.pas of fpdoc.
I moved one function out of fpdocoptsxml to mkfpdoc to split the input
line.
First tests work fine. See revision 20213.
A fine solution
On 02 Feb 2012, at 09:06, Blaise Thorn wrote:
On 02.02.2012 1:46, Blaise Thorn wrote:
For know, I am here for a different request: I reckon that small
fixes, especially those not directly related to closures, ought to
be submitted separately.
Or I could create something like http://svn.f
02.02.2012 17:00, Hans-Peter Diettrich пишет:
I wonder how these many messages occur, even in building the libraries.
Is it only lazyness why according fixes are missing, or are there
reasons why such conversions are inevitable?
Compiler informs that there are places which has suspicious code.
I wonder how these many messages occur, even in building the libraries.
Is it only lazyness why according fixes are missing, or are there
reasons why such conversions are inevitable?
Dumb question: what's the default "string" type in FPC trunk? When it's
AnsiString, in which situations are Uni
Michael Van Canneyt schrieb:
Well, It took me about 15 lines to implement it in dglobals.pas of fpdoc.
I moved one function out of fpdocoptsxml to mkfpdoc to split the input
line.
First tests work fine. See revision 20213.
A fine solution :-)
I happen to get an AV during the Engine destruc
On 02.02.2012 1:46, Blaise Thorn wrote:
For know, I am here for a different request: I reckon that small fixes,
especially those not directly related to closures, ought to be submitted
separately.
Or I could create something like http://svn.freepascal.org/svn/fpc/branches/blaise/misc
and as
21 matches
Mail list logo