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
>>> -d
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.or
Felipe Monteiro de Carvalho schrieb:
> 2010/2/17 Flávio Etrusco :
>> 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 65001 and
you can ou
Graeme Geldenhuys schrieb:
> 2010/1/26 Florian Klaempfl :
>> (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 avai
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
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.
>
&g
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 abo
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
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 s
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 mul
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
>>>
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
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 r
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, differe
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 wante
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
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 ot
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
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 predefi
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
abstr
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 pr
Graeme Geldenhuys schrieb:
> 2010/1/6 Vincent Snijders :
>> 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 projects like tiOP
Graeme Geldenhuys schrieb:
> On 05/01/2010, Martin Sucha 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 problem is t
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 (ju
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
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
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 q
Juha Manninen schrieb:
>
> If I create a feature request issue for this, does it have any chance of
> being
> implemented?
No.
> I think it would be EASY to implement.
Then propose a patch.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Mimu Bunnylin schrieb:
> So, basically, make a GUI-mode application, let FPC release the console
> during its normal startup initialisations, then detect that the parent
> process was a console, and recapture the console... This could work,
> thanks. It would still seem far simpler to alter the FPC
Flávio Etrusco schrieb:
> But what's your
> opinion on extending it to standard procedures?
I see no sense in doing so.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
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
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. -d
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:
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 - fpc-de
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 ;)
___
Vinzent Höfler schrieb:
> Florian Klaempfl :
>
>> 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
Vinzent Höfler schrieb:
> Florian Klaempfl :
>
>> Vinzent Höfler schrieb:
>>> Florian Klaempfl :
>>>
>>>> A VAROUT parameter could have the same semantics as VAR except that the
>>>> compiler does not expect that it is needed that it is initi
Vinzent Höfler schrieb:
> Florian Klaempfl :
>
>> 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 :
>
>> Without COM, FPC wouldn't have out parameters.
>
> And because there would be no difference between "var" and "out" then,
There would be difference: no out keyword at all :)
>
Felipe Monteiro de Carvalho schrieb:
> On Thu, Nov 19, 2009 at 8:36 AM, Michael Schnell 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 both architect
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 ty
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 d
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 va
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 mea
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 b
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
dmitry boyarintsev schrieb:
> On Fri, Nov 13, 2009 at 12:44 AM, Florian Klaempfl
> 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.
>
> T
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/test
dmitry boyarintsev schrieb:
> On Thu, Nov 12, 2009 at 9:26 PM, Florian Klaempfl
> 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
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?
Run
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&
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
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 doe
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 cpst
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
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, th
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 co
Graeme Geldenhuys schrieb:
> Florian Klaempfl wrote:
>>> and therefore the RTL and compiler procedures are identical with exception
>>> of
>>> the initialization of 4 bytes with a constant?
>> Well, two times two byte ;)
>
> I have not looked at the cps
Marco van de Voort schrieb:
> In our previous episode, thaddy said:
>> Marco van de Voort wrote:
>>> While I think it would be best to use native encoding on all platforms as
>>> much as possible, that is an opinion. However not using native encoding for
>>> general processing is nuts. So we need t
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 lik
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
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 F
>
> - 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 Unicode
Ivo Steinmann schrieb:
> Delphi have got also a solution:
>
> http://docwiki.embarcadero.com/RADStudio/en/Libraries_and_Packages#Delayed_Loading
Soon or later people will request this anyways I fear ...
___
fpc-devel maillist - fpc-devel@lists.freepas
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
http://lists.freepascal.o
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
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
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 impl
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 cro
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 - fpc-devel@lists.fre
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;
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 - fpc-devel@lists.freepasca
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.
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.
Vinzent Höfler schrieb:
> Florian Klaempfl :
>
>> 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
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 need to stay flexible to change!
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
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.
>&g
Alexander Klenin schrieb:
> On Mon, Oct 19, 2009 at 18:44, Florian Klaempfl
> 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?
>> Beca
Alexander Klenin schrieb:
> On Mon, Oct 19, 2009 at 18:35, Florian Klaempfl
> 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 comp
Alexander Klenin schrieb:
> On Mon, Oct 19, 2009 at 17:55, Florian Klaempfl
> 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
Graeme Geldenhuys schrieb:
> On 19/10/2009, Florian Klaempfl 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 impl
Graeme Geldenhuys schrieb:
> 2009/10/19 Paul Ishenin :
>> ...
>> 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, dimen
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 pe
Jonas Maebe schrieb:
> Florian Klaempfl wrote on Sat, 17 Oct 2009:
>
>> Graeme Geldenhuys schrieb:
>>> 2009/10/16 Paul Ishenin :
>>>> Sealed class is a class which can't be derived by another class.
>>>> This one is
>>>> fully support
Vinzent Höfler schrieb:
> Florian Klaempfl :
>
>> 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 co
Graeme Geldenhuys schrieb:
> 2009/10/16 Paul Ishenin :
>> 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 view, it mak
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
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 acce
Florian Klaempfl schrieb:
> Sergei Gorelkin schrieb:
>> dmitry boyarintsev пишет:
>>> Hello FPC-Developers
>>>
>>> Is there anyone maintaining compiler messages translations? I have
>>> some fixes for them and utf-8 format.
>>> I know i s
Sergei Gorelkin schrieb:
> dmitry boyarintsev пишет:
>> 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?
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 deve
Graeme Geldenhuys schrieb:
> 2009/10/2 :
>> 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 correc
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)} >f
c\Pas\Test\Led_test>\Fpc\ArmBin\ppcrossarm-251 -al -XX -Tembedded -Parm
> -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
> T
Applied, thanks.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 func
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
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
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
301 - 400 of 1314 matches
Mail list logo
