Marco van de Voort schrieb:
> On Wed, Jun 30, 2010 at 10:53:39PM +0200, Michael Van Canneyt wrote:
>>> ... because it increases the maintainance work on fpc. Even with one
>>> front end only we are almost unable to keep the issue count under
>>> control. I'am pretty sure that more front ends will b
Adem schrieb:
> On 2010-07-01 00:20, Florian Klämpfl wrote:
>>> Same here: What's wrong with considering, say, a new language
>>> back-end (or front-end) much like a new CPU-support?
>> As Michael said, it is called "Pascal". Supporting a new CPU does not
>> change this. Adding a C/Oberon/Modula w
On Thu, Jul 01, 2010 at 12:17:47AM +0200, Hans-Peter Diettrich wrote:
> I've already translated a couple of available C libraries into Pascal,
> using ToPas. There exist only a few constructs that do not translate
> into Pascal directly (bitfields...), but their addition to the compiler
> (code
On Thu, Jul 01, 2010 at 01:36:56AM +0300, Adem wrote:
> > I think these "pie in the sky" kind of scenarios are several years if
> > not longer beyond the initial C compiler. It will be a plant that needs
> > a lot of nurturing and care for a very long term, before it becomes an
> > alternative, a
Florian Klämpfl schrieb:
There should exist a
method/procedure in the CPU specific code, that is called to create the
binary code for a procedure, but I could not yet locate it.
psub.pas: tcgprocinfo.generate_code, it is generic.
I couldn't find out how the code generator is involved. Most met
Michael Van Canneyt schrieb:
... because it increases the maintainance work on fpc. Even with one
front end only we are almost unable to keep the issue count under
control. I'am pretty sure that more front ends will be rejected without
more people working on bug fixing in fpc.
Exactly. We can
Florian Klämpfl schrieb:
Why do you think Pascal would lose its glamor when (or if) FPC can
compile other languages?
... because it increases the maintainance work on fpc. Even with one
front end only we are almost unable to keep the issue count under
control. I'am pretty sure that more front
On 2010-07-01 00:30, Marco van de Voort wrote:
It is a devilish dillemma.
It defintely is.
But, the whole process of evolution is just that [and, no, for this
once, I am not out to start a 'creationism' vs 'evolution' war here ;) ]
Being lax, and you become dumping ground for failed experime
On Wed, 30 Jun 2010 21:53:47 +0200
Hans-Peter Diettrich wrote:
> Mattias Gaertner schrieb:
>
> > Why is this in the lazarus examples? Why not put it to the fpc sources?
>
> Because I can commit only to the Lazarus examples :-(
Sorry, but that sounds somewhat childish.
You could have asked the
On 2010-07-01 00:20, Florian Klämpfl wrote:
Same here: What's wrong with considering, say, a new language back-end (or
front-end) much like a new CPU-support?
As Michael said, it is called "Pascal". Supporting a new CPU does not change
this. Adding a C/Oberon/Modula whatever front end simply
On Wed, Jun 30, 2010 at 10:53:39PM +0200, Michael Van Canneyt wrote:
> > ... because it increases the maintainance work on fpc. Even with one
> > front end only we are almost unable to keep the issue count under
> > control. I'am pretty sure that more front ends will be rejected without
> > more pe
On Wed, Jun 30, 2010 at 11:59:15PM +0300, Adem wrote:
> >> Why do you think Pascal would lose its glamor when (or if) FPC can
> >> compile other languages?
> > ... because it increases the maintainance work on fpc. Even with one front
> > end only we are almost unable to keep the issue count und
Hi
> What LCLIntf functions do you want to use? I guess there should be
> better cross platform options in the RTL and FCL.
I don't even want to make console applications myself, the question is about
converting existing Delphi applications.
Now I implemented it like you and Michael wanted. So,
> Same here: What's wrong with considering, say, a new language back-end
> (or front-end) much like a new CPU-support?
As Michael said, it is called "Pascal". Supporting a new CPU does not
change this. Adding a C/Oberon/Modula whatever front end simply does not
fit into this scope besides the fact
Hans-Peter Diettrich schrieb:
>>> There should exist a
>>> method/procedure in the CPU specific code, that is called to create the
>>> binary code for a procedure, but I could not yet locate it.
>>
>> psub.pas: tcgprocinfo.generate_code, it is generic.
>
> I couldn't find out how the code generato
On 2010-06-30 23:53, Michael Van Canneyt wrote:
Exactly. We can barely cope as it is. If we compiled C as well, we'd
get bug reports about glibc or whatever C library fails to compile. no
thanks.
And, frankly, the project is called "Free Pascal" for a simple reason:
it is a *Pascal* compiler
Sven Barth schrieb:
Wouldn't it be better to also include the fpc-devel list in this
discussion (with CC)?
Not yet. I want to collect more information about the compiler, so that
I can make well based suggestions for the next steps.
DoDi
--
___
Mattias Gaertner schrieb:
Why is this in the lazarus examples? Why not put it to the fpc sources?
Because I can commit only to the Lazarus examples :-(
Now I have to adopt the sample to the FPC trunk version, which is
somewhat incompatible with 2.4.
DoDi
--
__
Florian Klämpfl schrieb:
3) The compiler builds an parse tree for every procedure, but I found no
way yet to make this tree accessible.
It is no parse tree but some intermediate represensation.
Yes, it's an AST, but I didn't want to put too much into the
advertisement ;-)
There should e
>>> If you could compile, say, Modula (or C/C++) with FPC, you would have
>>> direct access to a huge& time-tested resource of libraries etc which
>>> you could directly incorporate into your applications,
>> This can be done already using compilers supporting these languages
> True. But, wouln't
On 2010-06-30 23:31, Florian Klämpfl wrote:
Adem schrieb:
Why do you think Pascal would lose its glamor when (or if) FPC can
compile other languages?
... because it increases the maintainance work on fpc. Even with one front end
only we are almost unable to keep the issue count under control
On Wed, 30 Jun 2010, Florian Klämpfl wrote:
Adem schrieb:
On 2010-06-30 15:00, Marcos Douglas wrote:
On Wed, Jun 30, 2010 at 7:04 AM, Hans-Peter Diettrich
wrote:
One big advantage of the separation into syntactical and semantical
parts is the chance for adding further languages to the co
/zeljko wrote:
/> Yep, if he want to get complete X11 tree he can do that via XLib and (now
guessing from my mind) use XQueryTree() and friends.
Yes.
I had already some code but hacked a class today.
The code and an example is here: http://www.theo.ch/lazarus/winlist.zip
The example lists t
Adem schrieb:
> On 2010-06-30 15:00, Marcos Douglas wrote:
>> On Wed, Jun 30, 2010 at 7:04 AM, Hans-Peter Diettrich
>> wrote:
>>> One big advantage of the separation into syntactical and semantical
>>> parts is the chance for adding further languages to the compiler...
>> No sense for me.
>> IMH
On 2010-06-30 15:00, Marcos Douglas wrote:
On Wed, Jun 30, 2010 at 7:04 AM, Hans-Peter Diettrich
wrote:
One big advantage of the separation into syntactical and semantical parts is
the chance for adding further languages to the compiler...
No sense for me.
IMHO, we chose the FPC much more b
2010/6/30 Juha Manninen :
>> There is no reason whatsoever to drag in the nogui widgetset and whatnot in
>> a console application. That is just plain wrong. Someone using e.g. the
>> forms unit in a console application is coding wrong, and he should be
>> pointed out this fact by letting the compi
On Wed, 30 Jun 2010 15:24:23 +0300
Juha Manninen wrote:
> > There is no reason whatsoever to drag in the nogui widgetset and whatnot in
> > a console application. That is just plain wrong. Someone using e.g. the
> > forms unit in a console application is coding wrong, and he should be
> > pointe
On Wed, 30 Jun 2010, Juha Manninen wrote:
There is no reason whatsoever to drag in the nogui widgetset and whatnot in
a console application. That is just plain wrong. Someone using e.g. the
forms unit in a console application is coding wrong, and he should be
pointed out this fact by letting
> There is no reason whatsoever to drag in the nogui widgetset and whatnot in
> a console application. That is just plain wrong. Someone using e.g. the
> forms unit in a console application is coding wrong, and he should be
> pointed out this fact by letting the compile step fail.
Using the Forms
Hi Diettrich,
I see a complex work... very intelligent!
I have only one comment below:
On Wed, Jun 30, 2010 at 7:04 AM, Hans-Peter Diettrich
wrote:
> One big advantage of the separation into syntactical and semantical
> parts is the chance for adding further languages to the compiler...
No sense
On Wed, 30 Jun 2010 15:07:30 +0300
Juha Manninen wrote:
> > Yes, but you should set the widgetset to nogui.
>
> How to do it automatically by converter?
Options.LCLWidgetType
Mattias
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
h
On Wed, 30 Jun 2010, Juha Manninen wrote:
It's lack of Interfaces unit.
Right! I forgot it because normally it is added by the IDE save project
function and not by converter.
The save function adds it only if it finds Forms unit in uses section (IIRC).
Console applications are not always
> Yes, but you should set the widgetset to nogui.
How to do it automatically by converter?
Juha
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
On Wednesday 30 June 2010 13:03, theo wrote:
> zeljko wrote:
> > Screen.CustomFormsZOrdered[]
>
> But I guess that's for your own application windows only, right?
Yep, if he want to get complete X11 tree he can do that via XLib and (now
guessing from my mind) use XQueryTree() and friends.
zeljko
> It's lack of Interfaces unit.
Right! I forgot it because normally it is added by the IDE save project
function and not by converter.
The save function adds it only if it finds Forms unit in uses section (IIRC).
> Console applications are not always Windows dependant.
> So I guess adding LCL d
Hi!
Wouldn't it be better to also include the fpc-devel list in this
discussion (with CC)? Although (most of) the FPC-Devs might be reading
the Lazarus list as well, you might find a better and perhaps more
experienced audience there (it's nothing against the Lazarus developers,
but not every
>
> 3) The compiler builds an parse tree for every procedure, but I found no
> way yet to make this tree accessible.
It is no parse tree but some intermediate represensation.
> There should exist a
> method/procedure in the CPU specific code, that is called to create the
> binary code for a pro
zeljko wrote:
> Screen.CustomFormsZOrdered[]
But I guess that's for your own application windows only, right?
Given the context, I think the op wanted the order of X toplevel-windows.
I have written some code which does this using Xlib.
If this is what you need SteveG, I can prepare the code for
On Wed, Jun 30, 2010 at 2:44 PM, Mattias Gaertner
wrote:
> Why is this in the lazarus examples? Why not put it to the fpc sources?
+1, as FPC sources branch or even trunk.
thanks,
dmitry
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
On Wed, 30 Jun 2010 12:04:38 +0200
Hans-Peter Diettrich wrote:
> In examples/parser/no_cpu you find a new project, that can be used as a
> Pascal parser, or as a compiler template for a new CPU.
Nice work.
Why is this in the lazarus examples? Why not put it to the fpc sources?
Mattias
--
On Wed, Jun 30, 2010 at 2:52 PM, Juha Manninen wrote:
> Why does it happen? The obvious solution is not to add LCL dependency to
> console apps. Is it always the correct way?
It's lack of Interfaces unit.
Console applications are not always Windows dependant.
So I guess adding LCL dependency + In
On Wed, 30 Jun 2010 13:52:26 +0300
Juha Manninen wrote:
> Hi,
>
> I am testing the Delphi converter with a console application. Related to:
> http://www.lazarus.freepascal.org/index.php/topic,9746
>
> The converter adds dependency for LCL automatically. I though console apps
> could need LCL
Hi,
I am testing the Delphi converter with a console application. Related to:
http://www.lazarus.freepascal.org/index.php/topic,9746
The converter adds dependency for LCL automatically. I though console apps
could need LCL, too, because there are Windows compat functions in units like
LCLIntf
In examples/parser/no_cpu you find a new project, that can be used as a
Pascal parser, or as a compiler template for a new CPU.
This project is kind of a plug-in for the FPC compiler, i.e. it uses the
original FPC parser (fpcsrc/compiler/p*). More projects will follow,
making the FPC parser usabl
On 2010-06-30 12:05, Paul Ishenin wrote:
30.06.2010 16:18, Žilvinas Ledas wrote:
Yes, thanks, I understand that. I just was HOPING it will do what I want
:) I have some kind of "virtual keyboard" but it is only for my own app
(it does send "keys" to 3 TEdit's), so I was hoping such PostMessag
30.06.2010 16:18, Žilvinas Ledas wrote:
Yes, thanks, I understand that. I just was HOPING it will do what I want
:) I have some kind of "virtual keyboard" but it is only for my own app
(it does send "keys" to 3 TEdit's), so I was hoping such PostMessage()
will work as I expect. As it is not - I
On 2010-06-30 10:56, Michael Schnell wrote:
On 06/28/2010 11:13 PM, Žilvinas Ledas wrote:
PostMessage(currentEdit.Handle, LM_CHAR, Ord('a'), 0); // trying to
post msg to some TEdit
AFAIK, Controls that react on messages is a windows specific way to
manage controls.
In Linux, mess
On 06/28/2010 11:13 PM, Žilvinas Ledas wrote:
>
> PostMessage(currentEdit.Handle, LM_CHAR, Ord('a'), 0); // trying to
> post msg to some TEdit
AFAIK, Controls that react on messages is a windows specific way to
manage controls.
In Linux, messages can be used to have a thread notify the main threa
48 matches
Mail list logo
