Am 22.09.2011 11:51, schrieb Henry Vermaak:
> On 22 September 2011 10:26, Mark Morgan Lloyd
> wrote:
>> I got from there to 2.4 via (I think) 2.5 with Jonas's help, and since then
>> have moved it between local machines as a binary. I can confirm that 2.4.4
>> will build FPC trunk (2.7.1) on ARM,
Am 17.11.2011 20:51, schrieb Seth Grover:
>
> Although I can avoid the problem by casting the longword to a double
How should the compiler know that the division should be done using
double? Using always double slows down calculations. Because the range
of longword fits into a single as well as 2
Am 22.12.2011 17:56, schrieb Jonas Maebe:
> Keeping an aligned stack requires completely different code generation
> inside the calling routine, you can't implement that on a call-by-call
> basis.
Intel defined once how procedure entry/exit code should look like for
procedures doing 16 byte align
Am 21.01.2012 14:25, schrieb Sven Barth:
> On 20.01.2012 11:18, Skybuck Flying wrote:
>> Finally if you do believe prefetching is a good alternative to a pointer
>> cache or simply want to try out the effect of prefetching class pointers
>> then I challenge you to implement it in a experimental bra
Am 03.02.2012 01:37, schrieb Nikolai Zhubr:
> 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
Am 11.03.2012 12:01, schrieb peter green:
> It appears to me (i'm not an expert on arm assembler and I can't seem
> to find any documentation on FPA) that FPC is generating FPA
> instructions even though the FPU is set to a VFP type. What i'm really
> struggling to work out is why the heck that is
Am 11.03.2012 13:22, schrieb Jonas Maebe:
> * I'm don't think that requiring yet another different ARM compiler
> binary for this is the proper way. There's already enough confusion
> as it is with ppcarm variants.
But isn't this caused by the fact that we have the same executable name
while it ge
Am 11.03.2012 15:37, schrieb Jonas Maebe:
>
> On 11 Mar 2012, at 15:14, Florian Klaempfl wrote:
>
>> Am 11.03.2012 13:22, schrieb Jonas Maebe:
>>> * I'm don't think that requiring yet another different ARM
>>> compiler binary for this is the proper way.
Am 15.04.2012 17:03, schrieb Max Nazhalov:
Anyway, I ran that diff on the same conditions as above. Full test
suite did not show any regressions.
This is already a good sign.
My test case resulted in:
"1.2345678901234568E+3999": FPC=1.92 seconds
"1.2345678901234568E-3999": FPC=1.83 seconds
Am 25.05.2012 21:04, schrieb Jeppe Græsdal Johansen:
I managed to remove the errors with the following patch, such that
everything compiled, but I haven't been able to test it:
http://j-software.dk/fpc-mipsel.patch
All fixes of the patch are committed, I solved some things differently
though.
>
> And the whole code seems totally incompatible with standard mips abi,
> it use 6 registers to pass parameters, while o32 has 4.
cpupara needs a major overhaul. This is one of the next things I planned
to do.
___
fpc-devel maillist - fpc-devel
Am 22.07.2012 13:44, schrieb Martin Schreiber:
On Sunday 22 July 2012 13:23:50 Marco van de Voort wrote:
In our previous episode, Martin Schreiber said:
I don't think it's the best. I'm also quite sure it will require more
work from you in the long run, keeping them up to date and merging bug
f
Am 22.07.2012 14:06, schrieb Martin Schreiber:
On Sunday 22 July 2012 13:53:28 Florian Klaempfl wrote:
So classes.pp except for TObject is safe?
Afaik yes. Exception is in sysutils (magic too ?), tobject is in objpas.
Ah, yes. So whole classes unit is independent from compiler. Super
Am 24.08.2012 13:48, schrieb Jonas Maebe:
Martin wrote on Fri, 24 Aug 2012:
On 24/08/2012 12:04, Jonas Maebe wrote:
Martin wrote on Fri, 24 Aug 2012:
The above takes the first of the overloaded.
All bodies are empty.
procedure DebugLn(const s: string = ''); inline; overload;
That looks
Am 30.08.2012 13:42, schrieb Marco van de Voort:
In our previous episode, Graeme Geldenhuys said:
I found this old PDF documenting the FPC compiler architecture. I
remember in recent years others attempted to do a similar thing. I don't
know how accurate this PDF still is, considering it is base
Am 31.08.2012 09:32, schrieb Michael Schnell:
On 08/30/2012 10:20 PM, Florian Klaempfl wrote:
I doubt that a good developer needs such a document to get into the
compiler...
Hmmm.
I once thought about trying to do an fpc compiler for a not yet
supported arch, and I still am interested in
Am 16.09.2012 17:53, schrieb Daniël Mantione:
Op Sun, 16 Sep 2012, schreef Luca Olivetti:
but I don't know the outcome. Is it currently possible to develop
software
for that mcu with freepascal?
As far as I know the Cortex M series cannot run generic ARM code; it
only understands the Thumb2
Am 18.10.2012 22:16, schrieb Sven Barth:
On 18.10.2012 13:13, Sven Barth wrote:
Over the past weeks I've spent some time on getting something to work in
FPC and now I'm about to commit this either this evening or at least
this weekend (depending on the time I have).
I've now commited my change
Am 25.12.2012 12:38, schrieb Michael Van Canneyt:
On Tue, 25 Dec 2012, Martin Schreiber wrote:
On Tuesday 25 December 2012 11:20:02 Michael Van Canneyt wrote:
Everybody is aware of the speed difference between Delphi and FPC.
The compiling itself (parsing/producing assembler code) is not s
Am 25.12.2012 13:39, schrieb Yury Sidorov:
It is possible to seed-up compilation by allocating memory for nodes
from some zero pre-filled memory pool to avoid costly calls to heap
manager and avoid zero filling of small memory chunks. A base class for
various FPC nodes should be modified to handl
Am 25.12.2012 11:32, schrieb Mark Morgan Lloyd:
Michael Van Canneyt wrote:
On Mon, 24 Dec 2012, Martin Schreiber wrote:
- Produce at least as good code as Delphi 7.
- Compile at least as fast as Delphi 7.
You know that sacrifices need to be made to make a compiler cross
platform and easily
Am 25.12.2012 14:53, schrieb Jy V:
Although FPC heap manager is good, but custom pool memory allocation
will be much faster, since it will be very simple:
Result:=CurPoolPtr;
Inc(CurPoolPtr, BlockSize);
if CurPoolPtr > MaxPoolPtr then AllocNewZeroFilledPool();
It
Am 25.12.2012 14:44, schrieb Jy V:
The only approach I see to speed it up is to kick the whole back end
and generate directly some close to i386 intermediate code directly
in the parser.
Is this close i386 intermediate code similar to IR LLVM generation ?
No. It must be much clos
Am 25.12.2012 15:04, schrieb Sven Barth:
On 25.12.2012 14:15, Florian Klaempfl wrote:
The only approach I see to speed it up is to kick the whole back end and
generate directly some close to i386 intermediate code directly in the
parser.
Ewww... please not...
No, we would be back in pre 1.0
Am 25.12.2012 14:59, schrieb Yury Sidorov:
From: "Yury Sidorov"
From: "Florian Klaempfl"
Am 25.12.2012 13:39, schrieb Yury Sidorov:
It is possible to seed-up compilation by allocating memory for nodes
from some zero pre-filled memory pool to avoid costly calls to he
Am 25.12.2012 15:11, schrieb Paul Ishenin:
25.12.12, 21:59, Yury Sidorov пишет:
Hmm, Seems to be a false alarm :(
I've made some tests just now with memory allocation and found that such
pooling will not speed up the compiler too much. Only minor improvement
such as 10-20% :(
10-20% is still
Am 25.12.2012 15:17, schrieb Yury Sidorov:
From: "Paul Ishenin"
25.12.12, 21:59, Yury Sidorov пишет:
Hmm, Seems to be a false alarm :(
I've made some tests just now with memory allocation and found that such
pooling will not speed up the compiler too much. Only minor improvement
such as 10-
Am 25.12.2012 15:28, schrieb Mattias Gaertner:
On Tue, 25 Dec 2012 12:55:41 +0100 (CET)
mar...@stack.nl (Marco van de Voort) wrote:
[...]
The numbers Martin names (up till 10 times slower, even without linking) are
the numbers I have in mind too. IMHO denial without tests is unfair.
Maybe the
Am 25.12.2012 19:30, schrieb Dimitri Smits:
I'm guessing that is NOT on a Windows platform? Every full build (it
has been a while) I've ever done of the compiler on windows was at
least a few minutes.
It is windows: "self compilation". No rtl building or whatever.
The only approach I see to
Am 25.12.2012 19:39, schrieb Mattias Gaertner:
On Tue, 25 Dec 2012 18:01:50 +0100
Florian Klaempfl wrote:
Am 25.12.2012 15:28, schrieb Mattias Gaertner:
On Tue, 25 Dec 2012 12:55:41 +0100 (CET)
mar...@stack.nl (Marco van de Voort) wrote:
[...]
The numbers Martin names (up till 10 times
Am 10.02.2013 11:09, schrieb Sven Barth:
Having a LLVM backend would not only benefit HedgeWar's JavaScript case,
but also all others that would like to use the LLVM backend for one
purpose or the other. And in my opinion a pure JS backend would be much
harder to implement than a LLVM backend as
Am 10.02.2013 15:23, schrieb Vittorio Giovara:
Indeed, a fpc->js code generator would have a rather limited use. A
LLVM backend instead could be use on many more levels, and for example
could improve (or replace) the compilation process on iOS.
Improve in which regard? Experience showed that th
Am 10.02.2013 15:23, schrieb Vittorio Giovara:
Indeed, a fpc->js code generator would have a rather limited use. A
LLVM backend instead could be use on many more levels, and for example
Not to mention that I estimate that full llvm support with debugging and
extending llvm to support everythin
Am 22.02.2013 15:36, schrieb Refr Bruhl:
http://wwwp2t
Please do not click the link in this mail, it is probably malware/spam.
I have set the moderation flag for Refr Bruhl. Sorry for any
inconvenience caused by this.
___
fpc-devel maillist -
Am 02.03.2013 13:24, schrieb Marco van de Voort:
In our previous episode, Florian Kl?mpfl said:
(for example renaming all files to .pp takes off +/- 1 second here)
Nevertheless, I'd be interested in seeing the strace.
Better parallize the building using some build units. Then it will be
proba
Am 02.03.2013 15:15, schrieb Craig Peterson:
On Mar 2, 2013, at 3:52 AM, Michael Van Canneyt
wrote:
If you hire 2 painters to paint the whole of your house, and one
doesn't paint the inside, "because you don't see it from the
outside", of course he will be finished faster; he didn't perform
Am 02.03.2013 16:23, schrieb Marco van de Voort:
In our previous episode, Florian Klaempfl said:
Better parallize the building using some build units. Then it will be
probably compiled in less than 10 sec on a modern CPU.
Better paralellize the compiler :-)
In theory yes but I still fear
Am 02.03.2013 17:24, schrieb Marco van de Voort:
In our previous episode, Florian Klaempfl said:
I don't see why there would be more synchronization overhead than make?
In a parallelized compiler symtables etc. might be shared and this might
require a lot of synchronization to prevent
Am 02.03.2013 16:49, schrieb Michael Van Canneyt:
All this said: You will not hear me claiming that there is no room for
improvement in FPC.
I'm sure there is. However, I do not think we'll be able to match
Delphi's speed without sacrificing the main goal of FPC: to support as
much platforms as p
Am 05.03.2013 11:10, schrieb Paul Ishenin:
05.03.13, 17:55, Sven Barth wrote:
@Paul: see? :)
I see you, Graeme, Michael and probably some more 5-6 developers.
Even if those are the only ones, from the beginning, FPC tried to
support all niches. And if someone maintaines a certain niche, th
Am 06.03.2013 11:12, schrieb Michael Schnell:
So (as with all x86 variants) no library
or system call is necessary.
Wrong. This is not true in the general case, please read the appropriate
api documents.
With Cortex, this has changed to the use of the CP15 Register (freeing
A9 to allow for
Am 06.03.2013 14:16, schrieb Martin Schreiber:
On Sunday 03 March 2013 18:35:53 Martin Schreiber wrote:
On Friday 01 March 2013 18:33:56 Martin Schreiber wrote: [...] On
Linux, same computer, OpenSUSE 12.2, comparison FPC 2.6.2, Kylix 3
A last one, simple MSEgui demo, one form, a fancy tlabel,
Am 10.03.2013 18:53, schrieb Aleksa Todorovic:
Hi, FPC developers!
I've commited patch to issue 9961 few days ago, and I'd like to ask if
someone could take a look at it? I'm currently analyzing several other
unit-loading issues (10551, 18294) with similar situations (relative
paths, different u
Am 12.06.2013 15:45, schrieb Max Nazhalov:
Wednesday, June 12, 2013, 4:00:52 AM, Florian wrote:
FK> Am 09.06.2013 18:22, schrieb Max Nazhalov:
Could this patch be reviewed and accepted/adapted/rejected?
FK> Thanks, I applied it and fixed a few more things.
Thanks a lot! Just two addition no
Can anybody help with a fix?
Do I understand it correctly, that it is sufficient so replace .long by
.4byte and .short by .2byte at all locations? Does it apply to all targets?
Please tell me if r25054 helps.
___
fpc-devel maillist - fpc-devel@list
Am 03.08.2013 23:31, schrieb Sven Barth:
On 03.08.2013 22:50, Florian Klämpfl wrote:
Am 03.08.2013 17:19, schrieb Sven Barth:
On 03.08.2013 13:12, Florian Klämpfl wrote:
First, FPC does not loop unrolling by default, you need -Ooloopunroll,
second, the loop is relatively long, so let the com
>
> - 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
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
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 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
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
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
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
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
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
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
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
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
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&
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
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
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 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
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 b
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:
> 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
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
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
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
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 :)
>
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 :
>
>> 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 :
>
>> 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
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 - fpc-de
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. -d
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
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
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
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
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:
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 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 (ju
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
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
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
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
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
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
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
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
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
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
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
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
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
>>>
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
1 - 100 of 1314 matches
Mail list logo
