> Marco van de Voort wrote on Mon, 12 Jul 2010:
>
>> In our previous episode, Hans-Peter Diettrich said:
>>>
>>> Then we could start by immediately flagging all uses of "in" as
>>> deprecated, unless e.g. TP7 or Delphi mode is selected. When the users
>>> can demonstrate that they still need such
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 o
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 nee
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 multi
Alexsander Rosa wrote on Mon, 12 Jul 2010:
Java tries to be "write once, run everywhere", while .NET is more like
"write in any language, as long as you run it at our operating system".
Forget Mono, it's doomed to always play catch with Microsoft's
implementation due to technical and legal issue
Marco van de Voort wrote on Mon, 12 Jul 2010:
In our previous episode, Hans-Peter Diettrich said:
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
Marco van de Voort escreveu:
In our previous episode, Hans-Peter Diettrich said:
Honestly, a .NET back-end is less useful than e.g. a Java back-end, and
requires much work in the front-end for assembly compatibility ("uses").
Next a new debugger-interface is needed, and a VCL.NET. All in all
In our previous episode, Hans-Peter Diettrich said:
>
> Honestly, a .NET back-end is less useful than e.g. a Java back-end, and
> requires much work in the front-end for assembly compatibility ("uses").
> Next a new debugger-interface is needed, and a VCL.NET. All in all a
> very new project, t
In our previous episode, Hans-Peter Diettrich said:
> 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
>
On Mon, 12 Jul 2010, Hans-Peter Diettrich wrote:
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 th
On Mon, 12 Jul 2010, Hans-Peter Diettrich wrote:
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
Add the missing instructions to the bottom of armins.dat, run mkarmins
in the same directory. (and then submit patch) :-)
Geoffrey Barton skrev:
I wrote a procedure to turn on interrupts:-
procedure intenable;nostackframe;
begin
asm
cpsie i
end;
end;
The compilation fails with 'Error
Java tries to be "write once, run everywhere", while .NET is more like
"write in any language, as long as you run it at our operating system".
Forget Mono, it's doomed to always play catch with Microsoft's
implementation due to technical and legal issues.
2010/7/12 Sven Barth
> Hi!
>
> On 12.07.
Hi!
On 12.07.2010 11:59, Hans-Peter Diettrich wrote:
Honestly, a .NET back-end is less useful than e.g. a Java back-end, and
requires much work in the front-end for assembly compatibility ("uses").
Next a new debugger-interface is needed, and a VCL.NET. All in all a
very new project, that can in
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 multiple back-ends in one com
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 V
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 by
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 be
Michael Schnell schrieb:
I just stripped down the machine files for a no_cpu machine (all
fakes), with some documentation about the required units etc.
Is this based on what we already have for X86, ARM, etc, or does it
"fork" to another set of ARC implementations ? If "fork", is it intended
I wrote a procedure to turn on interrupts:-
procedure intenable;nostackframe;
begin
asm
cpsie i
end;
end;
The compilation fails with 'Error: Unrecognized opcode cpsie'
The compiler also does not recognise 'cpsid' and also 'primask' as in
'mrs r0,primask'
any ideas/workarounds?
Geo
Snapshots were broken. Think this is now fixed.
The v2.5.1 and v2.4.3 snapshots for go32v2 and win32 should now be
updated more or less daily again in /v25 and /v24 respectively, on the
fpc ftp sites /pub/fpc/snapshot/.
Regards John
Please help Logica to respect the environment by not printing
Michael Schnell schrieb:
IMHO a lot more interesting than ISO-Pascal, Modula, Oberon:
What about Delphi-Prism on that behalf. ?
(This supposedly would be easier to make working using a .NET/MONO-code
generating backend compiler than by attempting to reproduce the
appropriate functionality
On 07/12/2010 02:15 PM, Marco van de Voort wrote:
But why? What does it make possible? What would you use it for in
practice,
that you can't use Prism+mono for?
In fact the Prism Compiler is free - but not open source -, but to use
the IDE and a component library you even not only need to use
In our previous episode, Michael Schnell said:
> On 07/12/2010 11:51 AM, Marco van de Voort wrote:
> > But more importantly, what would be the use of supporting Prism?
> Before bashing me: I don _not_ vote for starting this really huge
> project, but nonetheless I think it would be great to have
On 07/12/2010 01:32 PM, Michael Van Canneyt wrote:
The cure is far worse than the problem, because it is still trying to
combine 2 systems that are basically incompatible.
Right you are. I was just trying to help ;).
-Michael
___
fpc-devel maillist
On Mon, 12 Jul 2010, Michael Schnell wrote:
On 07/12/2010 08:12 AM, Michael Van Canneyt wrote:
So for historical reasons, FPC is stuck with the 'in' clause, when in fact
it should
not exist in the first place.
It could be made useful when
- it takes precedence above the search path
- can be
Op Mon, 12 Jul 2010, schreef Michael Schnell:
On 07/12/2010 08:12 AM, Michael Van Canneyt wrote:
So for historical reasons, FPC is stuck with the 'in' clause, when in fact
it should
not exist in the first place.
It could be made useful when
You may be able to make it more usefull, but th
On 07/12/2010 08:12 AM, Michael Van Canneyt wrote:
So for historical reasons, FPC is stuck with the 'in' clause, when in
fact it should
not exist in the first place.
It could be made useful when
- it takes precedence above the search path
- can bed used relative with "current" = the file it
On 07/11/2010 11:31 PM, Michael Müller wrote:
We use relative paths like '..\foo\foo.pas' or '..\..\foo\foo.pas' under
Windows and it works with FPC 2.4.0 (but it already worked with 2.2.4).
Portability nightmare .
-Michael
___
fpc-devel ma
On 07/12/2010 11:51 AM, Marco van de Voort wrote:
But more importantly, what would be the use of supporting Prism?
Before bashing me: I don _not_ vote for starting this really huge
project, but nonetheless I think it would be great to have.
(1) Delphi Prism adds a lot of interesting language
In our previous episode, Michael Schnell said:
> What about Delphi-Prism on that behalf. ?
If it relies on GC (and afaik Oberon has the same problem), an RTL based on
GC first has to be explored first, and the extend of the changes.
But more importantly, what would be the use of supporting Prism
On 07/11/2010 03:29 PM, Hans-Peter Diettrich wrote:
Further projects could implement additional front-ends for FPC, for
other Wirthian languages (ISO-Pascal, Modula, Oberon...).
IMHO a lot more interesting than ISO-Pascal, Modula, Oberon:
What about Delphi-Prism on that behalf. ?
(This supp
On 07/10/2010 12:40 PM, Hans-Peter Diettrich wrote:
Let me know if you (or somebody else) has more concrete plans on the
integration of a new CPU.
I remember some discussions about doing a MIPS / PIC32 port recently
I just stripped down the machine files for a no_cpu machine (all
fakes), wi
Jonas Maebe schrieb:
I know that the "in " 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,
That is incorrect. Relative file names do work. They are resolved
relative
Op 2010-07-12 09:01, Marco van de Voort het geskryf:
>
> The IN syntax was iirc mainly to fix certain Kylix naming issues, and to
> assist the designer (hence its main use in .dpr).
As far as I know the "in" syntax was used in Delphi .dpr files, long before
Kylix arrived. It was initially used b
In our previous episode, Hans-Peter Diettrich said:
> That's why I would restrict the usage of "in", with a (relative) path,
> to a program or library module, as AFAIR Delphi does, and make the
> directory of that file the root for relative filenames.
AFAIK it does not. Delphi projects with rel
36 matches
Mail list logo
