Jonas Maebe schrieb:
I guess that FPC should simply write tkWString also for this unicode
string type, since that's effectively what it is. Florian?
No. An unicode string encoded by tkUString is an utf-16 string.
___
fpc-devel maillist -
Graeme Geldenhuys schrieb:
Hi,
I reviewing the various errors that I am experiencing with tiOPF and FPC
2.3.1. The last count was 130+ errors! Considering that there was under
10 errors with FPC 2.2.5 and tiOPF, it seems a lot in FPC has changed.
You should have tested with the unicode
Graeme Geldenhuys schrieb:
Florian Klaempfl het geskryf:
You should have tested with the unicode string branch one year ago ;)
I gave up a long time ago testing unstable FPC branches with
production code. Things change to often. I only test with the new FPC
when it is announced that a new
Graeme Geldenhuys schrieb:
Graeme Geldenhuys het geskryf:
Who says that? What is not supported?
Let me know how far you get with this example as well.
http://compaspascal.blogspot.com/2008/10/delphi-2009-strings-explained-by.html
Didn't we talk about *unicode* ?
Graeme Geldenhuys schrieb:
Marco van de Voort het geskryf:
MSE has no D2009 tested code afaik.
MSE has no unit tests, period!
As far as I know unicodestring support is not at D2009 level, since the
1-byte stuff and the format of internals are still missing/different?
Exactly.
The
Graeme Geldenhuys schrieb:
Micha Nelissen het geskryf:
Extracting a Char from a UnicodeString? What's that supposed to do?
Follow the URL I posted with that example.
I don't claim to know everything regarding Unicode. Florian said FPC
supports Unicode,
I said it supports the
Micha Nelissen schrieb:
Graeme Geldenhuys wrote:
MyString := '世界您好';
MyChar := MyString[1];
writeln(MyChar);
end.
Extracting a Char from a UnicodeString? What's that supposed to do?
As I said, it's UCS coding style :)
___
fpc-devel
Graeme Geldenhuys schrieb:
Florian Klaempfl het geskryf:
Then you shouldn't cry if a release candidate breaks your stuff :)
I'm not crying. I go through this process on every new FPC release. It's
part of my job. :-)
We can only fix stuff we know about.
And I only know about things
Jonas Maebe schrieb:
On 15 Sep 2009, at 13:53, Graeme Geldenhuys wrote:
ian Klaempfl het geskryf:
Do you use the cwstrings unit? Did you tell the encoding (UTF-8?) to the
compiler? Did you use the UnicodeChar instead of Char?
Yes to all, and the example still doesn't work.
Graeme Geldenhuys schrieb:
Jonas Maebe het geskryf:
That's because you did not specify the code page of the source code,
in which case it's parsed as CP 8859-1.
Even though my Linux system defaults to UTF-8? Umm
Add {$codepage utf-8} or save
Adding that with test3.pas and then it
Graeme Geldenhuys schrieb:
Hi,
Continuing with the RTTI return types for various property types. In FPC
2.2.5, WideString properties were returned as tkWString types. Now with
FPC 2.3.1, those are returned as tkUString.
Does that mean tkWString is now deprecated? In that case, why is it
Jonas Maebe schrieb:
On 16 Sep 2009, at 20:09, Sven Barth wrote:
Jonas Maebe schrieb:
As far as I know, there is not a single test for this functionality,
so I'm not sure that it actually works.
Well... then I think it's time to change this.
I'll try to test this functionality (and to
Applied, thanks.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
-XParm-
embedded- -d
led.pas
Hint: End of reading config file J:\Fpc\ArmBin\fpc.cfg
Free Pascal Compiler version 2.5.1 [2009/09/24] for arm
Copyright (c) 1993-2009 by Florian Klaempfl
Target OS: Embedded
Compiling led.pas
Assembling led
Linking led
J:\Fpc\ArmBin\arm-embedded-ld.exe
Carsten Bager schrieb:
How does the linker script look like?
MEMORY {
flash : ORIGIN = 0, LENGTH = 512K
ram : ORIGIN = 0x4000, LENGTH = 32K
}
__stack_end__ = 0x4000 + 31K;
__ram_end__ = 0x4000 + 32K-4;
SECTIONS {
. = 0;
startup : { *(.startup)} flash
prog
Graeme Geldenhuys schrieb:
2009/10/2 petr.kris...@epos.cz:
On Linux and cs_CZ.UTF-8 locale is thousand separator set to
NO-BREAK SPACE (UTF-8: 0xC2 0xA0).
But ThousandSeparator variable is defined as Char. Fpc sets
ThousandSeparator=0xA0 and kylix ThousandSeparator=0xC2.
Any ideas how to
dmitry boyarintsev schrieb:
Hello FPC-Developers
Is there anyone maintaining compiler messages translations? I have
some fixes for them and utf-8 format.
I know i should post them to bug tracker, but is there anyone to
review and accept (or reject) fixes?
One of the main compiler
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 to pollute Mantis
Bernd Mueller schrieb:
Florian Klaempfl wrote:
Just wanted to ask another question:
is there any support for interrupt procedures?
It is implemented for DOS/go32v2.
how to declare a proc as an
interrupt and associate it to its vector?
Not yet, but my processor specific units declare
Graeme Geldenhuys schrieb:
2009/10/16 Paul Ishenin webpi...@mail.ru:
Sealed class is a class which can't be derived by another class. This one is
fully supported by delphi.
Would you mind explaining this - I never saw the benefit of a sealed
class.
From a compiler developers point of
Vinzent Höfler schrieb:
Florian Klaempfl flor...@freepascal.org:
From a compiler developers point of view, it makes optimization easier
under certain cases (e.g. virtual method calls). It's the same as with
inline: inline has no advantage except that it is a hint to the compiler
how
Jonas Maebe schrieb:
Florian Klaempfl wrote on Sat, 17 Oct 2009:
Graeme Geldenhuys schrieb:
2009/10/16 Paul Ishenin webpi...@mail.ru:
Sealed class is a class which can't be derived by another class.
This one is
fully supported by delphi.
Would you mind explaining this - I never saw
Jonas Maebe schrieb:
Declaring a class as sealed for optimization purposes is a
micro-optimization that pollutes the source code. In that case, you'll
probably have to revert that change again later if you or someone else
does have to inherit from the class after all. It may also force people
Graeme Geldenhuys schrieb:
2009/10/19 Paul Ishenin i...@kmiac.ru:
...
TNokiaPhone = class(TCellularPhone)
TNokia37xxPhone = class(TNokiaPhone)
TNokia3720Phone = class sealed(TNokia37xxPhone)
TBasicPhone is ofcource an abstract class. It can have some basic fields
like color, weight,
Graeme Geldenhuys schrieb:
On 19/10/2009, Florian Klaempfl flor...@freepascal.org wrote:
Without discussing details, I think a singleton is a good example where
sealed is useful.
You had to go and pick the one design pattern that is probably the
most difficult to implement (per GoF book
Alexander Klenin schrieb:
On Mon, Oct 19, 2009 at 17:55, Florian Klaempfl flor...@freepascal.org
wrote:
Without discussing details, I think a singleton is a good example where
sealed is useful.
Why sealing a singleton is any more (or less) useful then sealing any
other class?
As I said
Alexander Klenin schrieb:
On Mon, Oct 19, 2009 at 18:35, Florian Klaempfl flor...@freepascal.org
wrote:
And taking into account the size of the patch (see below and ignore the
auto generated files msg*.inc), it's worth to add. private etc. cause
much more trouble in the compiler and has
Alexander Klenin schrieb:
On Mon, Oct 19, 2009 at 18:44, Florian Klaempfl flor...@freepascal.org
wrote:
Alexander Klenin schrieb:
BTW, I have already asked in the beginning of the thread,
but got no answer: why are those files under version control at all?
Because it's easier to handle when
Micha Nelissen schrieb:
Florian Klaempfl wrote:
I want really fast building and no external tool calling etc., that's
why I still use the text mode ide. Not to forget that msg*.inc not the
only auto generated files in the compiler sources: there are e.g.
autogenerated register tables
Jonas Maebe schrieb:
On 19 Oct 2009, at 10:44, Florian Klaempfl wrote:
I still think that none of the people mainly working on the compiler use
lazarus :)
Actually, I mostly use Lazarus for working on the compiler nowadays,
because of its code navigation.
I see :) I still navigate
Vinzent Höfler schrieb:
Florian Klaempfl flor...@freepascal.org:
Marco van de Voort schrieb:
In our previous episode, Florian Klaempfl said:
This is exactly my point about sealed classes. When you design the
product or class, you have NO way of know what will come in the
future. So you
Michael Van Canneyt schrieb:
Secondly:
You promote a certain class/interface to a language feature. The
compiler then depends on the presence of a certain class with some
'known' methods in the RTL.
The whole interface ref. counting depends on that as well as e.g. the
as operator.
My
Michael Van Canneyt schrieb:
My only worry now is to make sure that if they are implemented, that we
make the design as clean as possible: e.g. No hardcoded dependencies on
class or
interface names.
Afaik Delphi's implementation only depends on the guid: it's the same as
interface ref.
Marco van de Voort schrieb:
but keep in mind this is all GPL, and your product seems to be commercial,
which would taint it.
http://www.arm-pascal.ru/uploads/PortFPC.rar contains full sources.
___
fpc-devel maillist -
Paul Ishenin schrieb:
I have compared what d2010 TObject has and found a few differences:
1. Dispatch method is virtual
2. new method: class function UnitName: string;
3. new method: function Equals(Obj: TObject): Boolean; virtual;
4. new method: function GetHashCode: Integer; virtual;
5.
Sven Barth schrieb:
All in all I have the following goals for (my) future work on this:
* make a cppclass an implicit pointer
I don't like this idea because C++-classes aren't an implicit pointer
either.
___
fpc-devel maillist -
Dimitrios Chr. Ioannidis schrieb:
* native x86_64 compiler (assuming your fpc.exe in the path is an
x86_64 version)
* 'native' i386 compiler
* ARM/wince cross-compiler
In the above case i will end up with two dir's in fpc\bin. One
i386-win32 and one x86_64-win64.
Just use a cross x86-64
Sven Barth schrieb:
Florian Klaempfl schrieb:
Sven Barth schrieb:
All in all I have the following goals for (my) future work on this:
* make a cppclass an implicit pointer
I don't like this idea because C++-classes aren't an implicit pointer
either.
At first I wanted to disagree
Alexander Klenin schrieb:
For both FPC and Lazarus at about 8 days ago.
Should work again.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Paul Ishenin schrieb:
Alexander Klenin wrote:
Yet another bug:
---
type T = (a1, b1=5);
var
ch: T;
begin
for ch in T do Writeln(ch);
end.
This is caused by the problem in the for-to loop:
for ch := Low(T) to High(T) do
WriteLn(ch)
How should I solve the problem in the
Alexander Klenin schrieb:
The best Succ(X) algorithm I can think of that works correctly on
sparse enums is O(log enum_size).
It depends how much memory one wastes ;)
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
- There is only one encoding in MSEgui framework, it is the same on all
platforms.
Which is performance wise neither a good decision.
- In the majority of cases the fast and convenient character access by index
can be used. This is important for beginners.
- The current FPC
Martin Schreiber schrieb:
On Tuesday 10 November 2009 12:45:26 Michael Schnell wrote:
Martin Schreiber wrote:
Performance and simplicity. MSEgui does not need the overhead of
multi-encoding/multi-charsize. At the moment msestring=UnicodeString for
FPC 2.4 which is perfect. I fear FPC will
Martin Schreiber schrieb:
On Tuesday 10 November 2009 18:33:54 Florian Klaempfl wrote:
Did you look into the code in cpstrnew branch? I did.
And which changes are exactly the reason for your concerns?
More checks
Where? A pure unicodestring routine won't get additional checks.
and more
Martin Schreiber schrieb:
On Tuesday 10 November 2009 19:08:45 Florian Klaempfl wrote:
Where? A pure unicodestring routine won't get additional checks.
What is a pure unicodestring routine?
No other string types being involved especially things like RawByteString.
and more complicated
Michael Schnell schrieb:
Martin Schreiber wrote:
OK, so you say that the processing of the new and the current UnicodeString
and therefore the RTL and compiler procedures are identical with exception
of
the initialization of 4 bytes with a constant? Now that is exciting.
Of course with
Michael Schnell schrieb:
Florian Klaempfl wrote:
No other string types being involved especially things like RawByteString.
If you additionally implement the encoding Type RawWordString, Martin
should be happy.
No. RawByteString means simply: encoding unknown, the string is just a
couple
Martin Schreiber schrieb:
On Tuesday 10 November 2009 19:08:45 Florian Klaempfl wrote:
Martin Schreiber schrieb:
On Tuesday 10 November 2009 18:33:54 Florian Klaempfl wrote:
Did you look into the code in cpstrnew branch? I did.
And which changes are exactly the reason for your concerns?
More
Martin Schreiber schrieb:
On Wednesday 11 November 2009 13:47:43 Florian Klaempfl wrote:
I try to prove the exciting statement. How can I build a startup compiler
for the cpstrnew branch or
I use the 2.2.4/2.4.0 ide to build the compiler, so make in the cpstrnew
branch compiler dir should
Michael Schnell schrieb:
P.S.:
In this list, we already did discuss doing an FPC version that creates
the intermediate code that can be fed to the GCC code generator. This
would make available to FPC all relevant CPU architectures and
supposedly the low level optimization that gcc4 does on
Michael Schnell schrieb:
Florian Klaempfl wrote:
Just use GPC then?
It does not compile the many thousands of lines of the Delphi project I
want to port :(.
Yes, because it's probably very hard to make a (Object) Pascal front end
for gcc. Another backend for FPC is 4k-5k lines (pascal
Martin Schreiber schrieb:
On Tuesday 10 November 2009 10:33:07 Florian Klaempfl wrote:
So please don't destroy this ideal solution by dropping current FPC
UnicodeString in favour of the Delphi string which is complicated,
Who says that? If you don't mess with code pages, the only different
Martin Schreiber schrieb:
On Thursday 12 November 2009 19:26:06 Florian Klaempfl wrote:
What are the differences of AnsiString and RawByteString?
Ansistring: system encoding
System encoding at compile time or run time?
Runtime, as it is currently
dmitry boyarintsev schrieb:
On Thu, Nov 12, 2009 at 9:26 PM, Florian Klaempfl
flor...@freepascal.org wrote:
Ansistring: system encoding
RawByteString: variable encoding, cannot be checked at compile time,
when working with RawByteStrings, you've to take care of the newly
introduced encoding
Sven Barth schrieb:
If so, how do you
suggest to write those tests, especially as they (currently) rely on a
external library...
Libraries or object files? FPC does similiar testing for C linking: the
C sources are checked in into
http://svn.freepascal.org/svn/fpc/trunk/tests/test/cg/obj/
dmitry boyarintsev schrieb:
On Fri, Nov 13, 2009 at 12:44 AM, Florian Klaempfl
flor...@freepascal.org wrote:
Well, an ansistring has an implicit encoding: system. This won't change
and if one uses only unicodestrings and ansistrings, no change will be
noticed.
Thanks. It's always nice
Paul Ishenin schrieb:
Hello, FPC developers' list
I am trying to understand how to add an enumerator support to the fgl
containers. Seems it is imposible.
I need enumerator to return the same type as generic container. So I
declared enumerator class as generic too. But how to use it
Graeme Geldenhuys schrieb:
Jonas Maebe wrote:
Delphi compatibility. And Delphi does that because COM requires this
behaviour.
Can't that behaviour be limited to Windows platform only. Now *all*
platforms and all non-COM code has to be stuck with the useless compiler
hint simply because
Graeme Geldenhuys schrieb:
Florian Klaempfl wrote:
Without COM, FPC wouldn't have out parameters.
Why do you say that?
Because I added it for Delphi compatibility which needs it for COM?
I see many use-cases for out parameters
You mean for VAROUT parameters
Graeme Geldenhuys schrieb:
Florian Klaempfl wrote:
I see many use-cases for out parameters
You mean for VAROUT parameters :)?
I search the latest FP Language Reference document, and there is no
mention of 'varout'. I also tried to use varout in a procedure as
follows - which gave
Vincent Snijders schrieb:
Graeme Geldenhuys schreef:
Florian Klaempfl wrote:
I see many use-cases for out parameters
You mean for VAROUT parameters :)?
First one is not compilable, but the second one is. So no, I don't
understand your comment about 'varout'? Please explain more
Paul Ishenin schrieb:
Graeme Geldenhuys wrote:
As I stated in the other mailing list. It's not about a obsession to get
hint warning free code. It's about spoting REAL issues in code between
all the crap the compiler currently spits out. If your project uses a
lot of structure types, you
Felipe Monteiro de Carvalho schrieb:
On Thu, Nov 19, 2009 at 8:36 AM, Michael Schnell mschn...@lumino.de wrote:
This is great news for me, as I am considering a NIOS2 Port and NIOS2 is
very similar to MIPS32 so we might be able to work together on this and
the resulting thingy would support
Vinzent Höfler schrieb:
Florian Klaempfl flor...@freepascal.org:
A VAROUT parameter could have the same semantics as VAR except that the
compiler does not expect that it is needed that it is initialized. But
be warned: with such a parameter type you can easily create memory leaks
Vinzent Höfler schrieb:
Florian Klaempfl flor...@freepascal.org:
Vinzent Höfler schrieb:
Florian Klaempfl flor...@freepascal.org:
A VAROUT parameter could have the same semantics as VAR except that the
compiler does not expect that it is needed that it is initialized. But
be warned
Vinzent Höfler schrieb:
Florian Klaempfl flor...@freepascal.org:
Because a VAROUT parameter would be simply overwritten by the callee
even if it contains a valid automated type:
That's a semantic definition, not an explanation.
Sorry, but it seems you didn't follow up the thread, so I
Jonas Maebe schrieb:
The only thing that changed in r14137 was adding a prefetch statement
to tgnuassembler.writetree (on i386 you have to compile with
-Cppentium4 or higher for the prefetch statement to do anything
though).
Actually pentium3 ;)
Mattias Gaertner schrieb:
CompareMemRange of unit sysutils takes as Length a cardinal.
Can this be changed to PtrUInt?
Same question for CompareMem.
Should I create a bug report?
Bug report with patch ;)
___
fpc-devel maillist -
Felipe Monteiro de Carvalho schrieb:
Hello,
I am wondering about the best way to set the mips target. We are only
targetting mipsel (32-bits, little endian), but the Linux convention
for the name of this target is mipsel, while mips=mipseb, so the
command to build the target should be:
Felipe Monteiro de Carvalho schrieb:
Excelent. One thing I don't understand however is the link between the
defines and the makefile targets.
The Lazarus project for arm uses the -darm option to build a arm
compiler. For mipsel, how would that be?
-dmipsel ? That doesn't compile. -dmips
Jonas Maebe schrieb:
On 04 Dec 2009, at 17:51, Dariusz Mazur wrote:
but now another problem
linker say that system.pp need function _haltproc_eabi which is
absent in ucprt.0
That's probably because nobody has maintained the uclibc support
since adding EABI support. The ARM/Linux
Juha Manninen schrieb:
On tiistai, 5. tammikuuta 2010 18:07:38 Florian Klaempfl wrote:
Juha Manninen schrieb:
If I create a feature request issue for this, does it have any chance of
being implemented?
No.
Well thanks, that was a quick answer. According to timestamp you answered my
mail
Juha Manninen schrieb:
On tiistai, 5. tammikuuta 2010 18:39:21 Florian Klaempfl wrote:
I knew all the reasoning, but honestly, I don't see a point in it. I
used C++ for years professionally and I always avoided circular
references/implementing classes in different files than the header is
named
Juha Manninen schrieb:
On tiistai, 5. tammikuuta 2010 19:16:25 Florian Klaempfl wrote:
See e.g. the compiler, but how does a big source file hurt anyways?
Today, navigation is done by the IDE and cvs times are also gone when
big files were a problem to commit. I consider class reference
Jonas Maebe schrieb:
On 05 Jan 2010, at 17:45, Juha Manninen wrote:
On tiistai, 5. tammikuuta 2010 18:14:53 Jonas Maebe wrote:
The reason that they are conceptually not the same thing is that
in Pascal two different units can both declare a different class
with the same name (just like they
Graeme Geldenhuys schrieb:
On 05/01/2010, Martin Sucha anty...@gmail.com wrote:
You should be able to achieve that by putting some ifdefs around interface
and
implementation (and other) parts of your autogenerated programs and then for
example
True and I have done this before. BIG
Graeme Geldenhuys schrieb:
2010/1/6 Vincent Snijders vsnijd...@vodafonevast.nl:
You are getting old:
http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg13343.html
Ah, but that would explain why I don't use it. I never develop in
delphi mode, only objfpc mode - unless I work with
Nikolai ZHUBR schrieb:
Tuesday, January 05, 2010, 11:08:37 PM, Juha Manninen wrote:
On tiistai, 5. tammikuuta 2010 20:06:42 Florian Klaempfl wrote:
Then do the same as in C++ and put it in different include files.
Right, include files could solve this problem at least partly. They seem
Juha Manninen schrieb:
Still, best solution has been to put everything into one big file. And still,
I don't like that compiler forces such a thing.
The compiler forces you many other things. Still, I don't get what's the
problem with a large unit if it's really needed (and nothing like
Michael Schnell schrieb:
Stefan Kisdaroczi wrote:
to create hard realtime linux programs with freepascal and xenomai [1] in
userspace
Ooops
Userspace means Linux and Linux means no hard realtime possible (with
the official definition of hard realtime: reaching a predefined timing
Florian Klaempfl schrieb:
Juha Manninen schrieb:
Still, best solution has been to put everything into one big file. And
still,
I don't like that compiler forces such a thing.
The compiler forces you many other things. Still, I don't get what's the
problem with a large unit if it's really
Marco van de Voort schrieb:
In our previous episode, Florian Klaempfl said:
Still, best solution has been to put everything into one big file. And
still,
I don't like that compiler forces such a thing.
The compiler forces you many other things. Still, I don't get what's the
problem
Marco van de Voort schrieb:
(remember the people to complain about the huge amount of files of the
fpc rtl :)?).
The point is that they are right from a birds-eye general application
development view.
I wanted only to point out that there pros and cons for small/large
units and if a design
Florian Klaempfl schrieb:
Marco van de Voort schrieb:
(remember the people to complain about the huge amount of files of the
fpc rtl :)?).
The point is that they are right from a birds-eye general application
development view.
I wanted only to point out that there pros and cons for small
Juha Manninen schrieb:
Other programming languages have different cultures. See the comment from my
original post in this thread. It was from a professional programmer and I
understand it. Some development teams want to put every class into its own
file.
Different languages, different
Michael Schnell schrieb:
Florian Klaempfl wrote:
Did you look at the xenomai website?
Seemingly you need to do your own device drivers and not use any Linux
system calls in your realtime process, that seems to run Linux in a kind
of virtualization.
Hard real time causes a lot
Jonas Maebe schrieb:
On 06 Jan 2010, at 12:14, Florian Klaempfl wrote:
Different languages, different habits. I even consider putting every
class in its own header and implementation file as a bad habit. There is
no reason to do anymore because modern C/C++ compiler can smartlink on a
sub
Jonas Maebe schrieb:
On 06 Jan 2010, at 13:04, Florian Klaempfl wrote:
Jonas Maebe schrieb:
Another reason is probably to speed up the compilation:
* (re)compiling huge source files can be slow and/or require lots of
memory, depending on the used compiler (and debug information
Marco van de Voort schrieb:
In our previous episode, Wimpie Nortje said:
Did you have a look at AVR?
Yes, but from what I remember it was canceled because the amount of
periphery on the chip is poor. I also looked at ARM, but while there is more
choice there, it is fragmented over multiple
Nikolai ZHUBR schrieb:
Wednesday, January 06, 2010, 2:47:24 PM, Juha Manninen wrote:
On keskiviikko, 6. tammikuuta 2010 13:14:18 Michael Van Canneyt wrote:
Why ? Every class in 1 file is perfectly possible with include files, and 1
big unit file.
Ok, include files seem to solve this
dmitry boyarintsev schrieb:
Hello All
I've been trying to modify the patch:
http://bugs.freepascal.org/view.php?id=15163
so it can be accepted.
But I've ran into a strange bug.
I'm using r14593 compiler + int_asm_darwin.patch applied (from the link
above).
Go to ogbase.pas and
Nikolai Zhubr schrieb:
Hello people,
I've discovered that (at least on win32) the compiler (2.2.2 and 2.4.0)
refuse to overwrite an invalid PPU file. It just stops.
One typical case is when PPU creation had previously failed due to disk
problems (e.g. out of room) or compilation abort,
Nikolai Zhubr schrieb:
15.01.2010 0:01, Florian Klaempfl:
I don't think that people will be happy if the compiler just deletes
their ppus if it can't read it for any reason. The compiler cannot know
if it can recreate the ppu when it deletes it.
Well, when a user asks compiler to compile
Graeme Geldenhuys schrieb:
Hi,
Speaking of language syntax in another thread it got me thinking.
Being around FPC for a few years now I have read many messages and saw
patches regarding language extensions etc...
Then today by pure accident while searching for Modula-2 if..then..end
Graeme Geldenhuys schrieb:
2010/1/26 Florian Klaempfl flor...@freepascal.org:
(remember, I did the initial development of FPC on a 386-40 with 4 MB
Wow, that must be long ago.
The current FPC code base was started in June 1993. Nice task for the
git addicted to take available old sources
Felipe Monteiro de Carvalho schrieb:
2010/2/17 Flávio Etrusco flavio.etru...@gmail.com:
I've read somewhere that Windows ANSI functions support utf-8?
(despite the name)
lol!!!
You read from someone deeply missinformed =D
Switch the console to a font supporting unicode, execute chcp
Adriaan van Os schrieb:
Does current_procinfo in the compiler sources always denote a global
procedure, never a nested one ?
No, it's always contains info about the currently handled procedure.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Nataraj S Narayan schrieb:
Florian
Getting this kinda errors when using:-
No wonder. Read again what I wrote.
# gmake distclean crosszipinstall CPU_TARGET=arm OS_TARGET=linux
CROSSOPT='-dFPC-ARMEL '
#make distclean crosszipinstall CPU_TARGET=arm CROSSOPT='-CfSOFT -darm
-dFPC-ARMEL
Sergey Bochkanov schrieb:
Now about the future. As I told, I think that I should use FPC 2.5.*
for unit-testing because one important floating point bug was fixed
only in 2.5.1
Which one? If it's a bug fix, it can be probably merged to 2.4.* and you
can use the 2.4.1 fixes branch what
Ivo Steinmann schrieb:
My question: What is required to get the same results for TVector as for
TScalar?
Not yet. Planned for years, but no time so far :)
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
701 - 800 of 1078 matches
Mail list logo
