Michael Schnell schrieb:
I feel that Lazarus as an IDE and component library is more desirable
than Visual Studio. AFAIK there is no version of the Prism compiler that
runs on Linux or Mac.
A platform independent solution would implement the IDE, compiler etc.
in .NET/Mono, so that it can
Michael Van Canneyt schrieb:
The cure is far worse than the problem, because it is still trying to
combine 2 systems that are basically incompatible.
Bottom line is: don't use 'in' for the uses clause; use the command-line
option to specify the location of the sources.
Then we could start
Michael Schnell schrieb:
If you want paralel, take vector pascal, and implement it in e.g. the
FPC or
objfpc dialect.
I suppose this is a good idea, even tough I suppose that the .Net
parallel paradigm is a lot more broadly known than that of Vector
Pascal. so Hans-Peter might want to add VP
Florian Klaempfl schrieb:
Hans-Peter Diettrich schrieb:
But since some abstract links already exist (class type
variables for machine specific descendants), these links could be
exchanged at runtime,
One problem are all the used constants describing the target
architecture. We discussed
Michael Van Canneyt schrieb:
A platform independent solution would implement the IDE, compiler etc.
in .NET/Mono, so that it can be used immediately on every platform,
that supports .NET. AFAIK Java development systems went the same way...
Huh ? That would be the day ? AFAIK Java doesn't
Jonas Maebe schrieb:
Furthermore, at least two of the users have already posted in this
thread saying that they use this functionality (both in FPC and in
Delphi). Therefore I don't think it is a good idea to remove or change it.
ACK. My concern is about new users with (possibly) new uses of
I'm just curious, does there exist descriptions for the various SVN
branches (purpose, maintainer, state)?
Florian has offered me an new branch, for my parser etc. projects, but
he seems to be very busy right now. So I'll present a roadmap of my
activities, all around the parser and compiler:
I know that the in filespec is part of the Delphi syntax, but what
is it really good for?
AFAIK it's not allowed to rename units this way, and since (currently)
only absolute filenames are implemented, I really wonder why FPC allows
to use it everywhere?
IMO the filespec should allow for
Jonas Maebe schrieb:
AFAIK it's not allowed to rename units this way, and since
(currently) only absolute filenames are implemented,
That is incorrect. Relative file names do work. They are resolved
relative to the current working directory of the compiler.
So what's the current working
Jonas Maebe schrieb:
The stand-alone preprocessor code ($PreprocWrite, commandline
option -m) does not compile since a long time. I could it make work
again, and already supplied the according patch in Mantis.
And as I replied in mantis two days ago, a) that option is not
documented in the
Jonas Maebe schrieb:
That is incorrect. Relative file names do work. They are resolved
relative to the current working directory of the compiler.
So what's the current working directory?
The current directory when the compiler was started. E.g.:
c:\pp\src ppc386 project\test.pas
-
Michael Schnell schrieb:
In fact I did a (quite low priority) research on how to port FPC to a
new CPU such as NIOS and Blackfin and found that it of course is doable
somehow. While NIOS seems to look more doable, as it's quite similar to
MIPS (and ARM), Blackfin has a much more complex
Martin schrieb:
You can have an editor that displays and edits the content in any format
you like and validates it at the same time. But it saves it in the
current format after all.
so you edit:[b]key[/b] 1
and the editor saves: bkey/b 1
should read
and the editor saves: bkey/b
Jeppe Johansen schrieb:
I would be interested in knowing whether it would be feasible to create
DSP backends for FPC. I recently had the experience of using a TMS320C26
which probably has to be programmed in assembler due to the limits of
the instruction set. But I hear newer DSPs use
Mattias Gärtner schrieb:
Replacing units can be done with the search path.
But only when the search for used units exactly follows the search path,
and does not look into the directory of the using unit first. Is this
guaranteed?
DoDi
___
Mattias Gaertner schrieb:
Lazarus sets the working directory to the project directory when
calling the compiler.
Fine :-)
The 'in' modifier works here.
It didn't work for me with relative pathes, like
uses myUnit in '..\myUnit.pas';
(Windows, obviously ;-)
While Lazarus could find that
Mattias Gärtner schrieb:
The 'in' modifier works here.
It didn't work for me with relative pathes, like
uses myUnit in '..\myUnit.pas';
(Windows, obviously ;-)
Hint: Both compiler and lazarus automatically changes the path delimiter
and searches exact/lower/upper case for the file name
Michael Van Canneyt schrieb:
Sad but we found a new (really very old) bug with spaces:
http://bugs.freepascal.org/view.php?id=9964
If you pass -osome file with spaces.exe or -osome file with
spaces.exe fpc generates only a file with only some part.
[...]
Are you sure the bug is in FPC ? I
Marco van de Voort schrieb:
Does Lazarus set the working directory for the compiler as you expect it to
be? Keep in mind that a relative path is always dependant on the working
directory, not relative to the project.
I'd expect that the working directory is set to the directory of the
Graeme Geldenhuys schrieb:
Looking at the rtl/unix/cthread.pp unit, I noticed two $Warning lines sayin
that setting or getting thread priority is not implemented for any unix
system. WHAT???
I then thought I would go ahead and do the implementation. Seeing that
cthreads using libc and POSIX
Daniël Mantione schrieb:
Yes, but in a multi-cpu system giving up the timeslice is a very bad
idea, because the lock might be released a few clock cycles later by the
other cpu; you would waste the rest of time slice while you could be
crunching.
IMO the default implementation should work
Paul van Helden schrieb:
Threads are evil?
http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf
Interesting view point. Perhaps that is why FPC doesn't bother too much
about thread priorities? :-)
IMO the author neglects the existence of realtime systems, which have to
deal
Marco van de Voort schrieb:
The problem is not the programming (since a dedicated person could probably
start with a translated glibc in a good month), but the continuous
maintenance (for every distribution separately, since they could use
different kernels, options etc) , and interoperability
Marco van de Voort schrieb:
The Kylix-like addition of an C compiler would help to solve such
issues, that arise from the use of *any* C code with FPC.
Well, since this is about a maintenance problem, it would only solve
it if the maintenance of the C compiler would be lower than the
Michael Schnell schrieb:
From some ARM manual:
The ARM7500FE does not use the lock feature available in the ARM701
macrocell
You must take care to ensure that control of the memory is not
removed from the ARM
processor while it is performing this instruction.
This seems to apply
Graeme Geldenhuys schrieb:
FPC finally has a working TMultiReadExclusiveWriteSynchronizer
implementation (tiOPF implemented it's own), but I don't know if that
implementation is available for FPC 2.4.x yet, or if it is still only in
Trunk. Either way, TXXXConfig classes could use the same
Graeme Geldenhuys schrieb:
Bounds is used a lot in Delphi and LCL applications.
So for delphi compatibility we now need to duplicate Delphi bugs in FPC
too? FPC DELPHI.
It's not a bug, it's a commonly accepted graphics model.
The only thing I'm missing is a distinction between rectangles
L505 wrote:
| With regards to gnu linux:
| How about the Elf format?
| Is it possible to export code from an elf? (i.e. export functions)
|
Okay, I researched the topic. Of course, yes, you can export functions from
an executable
on linux. But freepascal doesn't seem to like it just
Marcel Martin wrote:
Unexpected overflows? The overflows occur or not according to
simple rules, perfectly defined, which ones depend on the types
of the operands.
Unexpected as depending on the values, not on the types. When the ranges
of the possible operands are known, it's also
Marcel Martin wrote:
Why not? I expect that the compiler evaluates constant expressions, and
creates the best code for the resulting values.
The best code is, before all, the correct code.
So we have to find out what is *correct*.
In the case of Inc(x, SomeConstant) the value of the
Marcel Martin wrote:
I think Marco is right. Basically, when the compiler has to
code Inc(x,SomeConstant), the only sensible behaviour it is
expected to have is to regard the constant as being of the
type of x. So, if x is a Longword and if SomeConstant equals
-1, either it adds $
Yury Sidorov wrote:
I found that try...except and try...finally do not work if SysUtils unit is
not used (exception handling code is not called).
This behaviour is compatible with Delphi. It allows to exclude some
procedures from being linked to the executable, when no exception
handling is
Yury Sidorov wrote:
So what way should we go?
1. Leave RTL string types as is (PChar/AnsiString) and perform conversion
from Unicode if needed.
No problem.
2. Define new types PSysChar/SysString to correspond either PChar/AnsiString
or PWideChar/WideString depending from OS type.
It's
Bram Kuijvenhoven wrote:
function MyOverloadedFunc:boolean; alias MyOverLoadedFuncNoParams;
function MyOverloadedFunc(i:integer):boolean; alias MyOverLoadedFuncInt;
Another note is that the 'alias' keyword might already be in use for some
other purpose (I don't exactly remember which), so
Michael Van Canneyt wrote:
What is the performance difference between a hash() and a binary search on
an ordered list ?
IMO perfomance heavily depends on the use of the lists. An ordered list
requires some efforts when entering or removing items, and typically
requires more comparisons than a
Ivàn Caballero Cano wrote:
I want to konow if there is a units like Turbo Vision For Borland Turbo
Pascal for Free Pascal.
There are a Units o something else that help to build windows, check
box, list box, like Turbo Vision but for Free Pascal??
Do you mean a library for GUI or Console
alphax wrote:
It seems a bug in FPC 2.0.0.(Delphi 7.1 also has this bug)
Assumes there is an object(not class) declaration, the object has a
IInterface field. If we declare another object derive from it, in the cleanup
procedure of that decendant leak to clear the IInterface references.
Peter J. Haas wrote:
I write in German language because I'm not able to translate my
statement comprehensibly. Maybe anybody can translate it for people,
which don't can read German.
Sorry for OT, please ignore the following if you don't understand
German(s) ;-)
...
Ich hatte bei den Mails
L505 wrote:
...
But compiled with delphi compiler, or freepascal? I wonder if they have a
specific restriction where you can only compile the code on their compilers...
Not that I know of but.. I thought maybe you guys had come across something
like
that
The System.pas unit is special. In
Gerhard Scholz wrote:
...
I'm not sure, at least
.L9:
movw %dx,-12(%ebp)
.Ll3:
suggests that the target is not an integer, but instead is a (possibly
unsigned) word type. Please check again!
...
This is the result of the compilation: ppc386 tord -al (shortened of
Jamie McCracken wrote:
Hans-Peter Diettrich wrote:
You obviously missed that a compiler does not only consist of scanner
and parser, but that optimizers and code generators also have to be
implemented. For multiple target platforms and CPU's...
The new dialect simply makes the syntax
Michael Van Canneyt wrote:
It's a simple fact:
90% if not more of all pascal code out there is Delphi code. Being able to
compile and
re-use that is FAR more important than changing the fact that begin/end is
required in
pascal.
ACK.
You want to make some 'Auto-Maintained' variable
Angelo Bertolli wrote:
Begin..End is redundant - you have to indent them to make em readable
anyways.
Not at all; I certainly don't indent them, and I'm a fanatical
indenter.
Agreed. I really can't understand why some people indent like this:
if ...
then
begin
...
Jamie McCracken wrote:
Those lazarus tools are great but they require advance knowledge of
those tools that new users wont have (at least somebody using lazarus
for the first time is not going to know all the keyboard shortcuts). Not
having to rely on hacks around the coding inefficiency of a
Jamie McCracken wrote:
Garbage collection is largely no issue when using the Owner concept in
TComponent, using TObjectList, etc.
True and thats why I suggested ref counting Tobjects only so that no
manual memory management is required. I tend to make heavy use of TList,
Tstringlist and
listmember wrote:
Inline variable initializers, such as:
...
function Something(...): Boolean = False;
var
Integer1: Integer = 15;
Boolean1: Boolean = False;
String1: String = 'SOME TEXT';
begin
end;
Such constructs are subject to frequent misinterpretation :-(
I assume that
Jamie McCracken wrote:
For me I prefere clarity above less typing (besides if you want to write
realy short code, you sould use APL)
I totally agree with you in this case - we dont want or need cryptic c
stlye syntax in any version of Pascal.
ACK.
However, in general Pascal has poor
Jamie McCracken wrote:
I don't understand, why are these forward declarations so evil ?
More code bloat, more typing and they get in the way. They dont give me
anything useful in return.
Please show me a piece of code where they are in the way. Code bloat?
They don't cost anything
A friend has found some obvious errors in the FPC syntax description,
and I found some more errors. Here is our current list:
==
page Expected Error Description
Jamie McCracken wrote:
Yes, but the poster was asking whether the compiler never decided by
itself to inline something (even if no inline directive was
specified). That's not the case currently.
well thats soemthing you should add to your to do list. Automatic
inlining can deliver a
Konstantin Münning wrote:
I would hapily contribute the code for a better MemAvail/MaxAvail
function if that's the problem. I would like to be able to use the
latest compiler which now I definitely can't as I must have the BP7
compatibility which is very good in 1.0.10.
IMO we have two
901 - 951 of 951 matches
Mail list logo
