On Fri, 2 Jul 2010 09:21:37 +0300 (EEST)
Rigel Rig wrote:
> Windows has DLL-s. DLL, written in C, C ++... can be used in Delphi, and I
> guess in Lazarus. Why not use them? It is much easier. And you can write them
> in whatever language you want.
I'm curious, can Java be used to write a dll?
On Thu, 01 Jul 2010 22:11:25 -0300
"Leonardo M." Ramé wrote:
> El vie, 02-07-2010 a las 00:25 +0200, Mattias Gaertner escribió:
> > On Thu, 01 Jul 2010 17:09:29 -0300
> > "Leonardo M." Ramé wrote:
> >
> > What gtk version do you use?
> > Can you try to find the svn revision that broke it?
> >
On Fri, 02 Jul 2010 07:49:25 +0300
Adem wrote:
>[...]
> Well.. the whole point is to *not* maintain any more than *one* parser
> --and, that includes current n parsers (I am not sure what the value of
> 'n' is).
>
> That is the target.
Means?
I still don't understand what do you really want t
Windows has DLL-s. DLL, written in C, C ++... can be used in Delphi, and I
guess in Lazarus. Why not use them? It is much easier. And you can write them
in whatever language you want.
In Linux do you have something similar? Why not use it instead to mix Pascal
with C, C++, Java... philosophy?
On Thu, Jul 01, 2010 at 06:56:26PM +0200, Hans-Peter Diettrich wrote:
>
> FPC overcomes this problem with the .ppu files (I assume)
No. That is an optimalization. The core feature is defining the unit
concept, and clearing (reinitializing from cmdline params) preprocessor
state
> C++ with
> man
On Thu, Jul 01, 2010 at 01:55:43PM +0200, Hans-Peter Diettrich wrote:
> >> the .Net thing mostly on the premise of 'write in the language you're
> >> most comfortable yet share with others you/they find useful';
> >
> > Exactly, "sold". It's marketing speech. You could use any language but
> > onl
On 2010-07-02 07:33, Marco van de Voort wrote:
Besides that, many people (including several that worked on the FPC parser)
have warned you that such a beast, while more elegant on paper, might actually
be harder to maintain than two parsers.
You chose to ignore that.
No.
I did not ignore th
On Thu, Jul 01, 2010 at 02:27:22PM +0200, Hans-Peter Diettrich wrote:
> > Aren't you against a e.g. .Net backend because it requires a completely
> > different runtime :)? I think the same applies to M2 etc. as well?
>
> IMO we could separate the language itself (syntax) from the RTL (semantics).
On Thu, Jul 01, 2010 at 08:12:52PM +0300, Adem wrote:
> >> You could have asked the fpc team or put it into one of the many free
> >> repositories. If you put something into lazarus examples then lazarus
> >> users expect a reason for downloading 650KB extra. If the above is the
> >> only reason
El vie, 02-07-2010 a las 00:25 +0200, Mattias Gaertner escribió:
> On Thu, 01 Jul 2010 17:09:29 -0300
> "Leonardo M." Ramé wrote:
>
> What gtk version do you use?
> Can you try to find the svn revision that broke it?
>
>
> Mattias
My libgtk2.0-0 is 2.20.1-0ubuntu2. Is that what do you need?.
On Fri, 02 Jul 2010 03:22:34 +0300
Adem wrote:
> As far as I can tell, they both think it will be a tough one (due to
> complex and intertwined code) to pull off --especially from POV of speed.
Exactly and it sounds like they think the time and manpower is better spent on
other things.
much wo
On 2010-07-02 02:10, Reimar Grabowski wrote:
On Fri, 02 Jul 2010 00:55:27 +0300
Adem wrote:
First of all I apologize for hurting your feelings.
No problem. Except for mild disappointment, no harm done.
Second, please calm down. This is only a technical mailing list and in my
opinion the wro
On Thu, 1 Jul 2010 23:27:43 +0200
Graeme Geldenhuys wrote:
> PS: Real men (or any men for that matter) shouldn't send me emails
> like the above. My wife doesn't like competition. :-)
Africa is so far away, I have no fear.
Regarding the thread: No bad feelings, just different opinions.
Have a
On Fri, 02 Jul 2010 00:55:27 +0300
Adem wrote:
First of all I apologize for hurting your feelings.
Second, please calm down. This is only a technical mailing list and in my
opinion the wrong one for this discussion.
> Further: While doing that, refactor it so that ordinary mortals too
> could
On 2010-07-01 20:14, Michael Van Canneyt wrote:
Well, if you need things to do:
- Make fcl-passrc complete. (*NOT* extract parser from compiler).
I just cannot understand this: What is so holy about the 'parser from
compiler'?
- use it to create a pascal to javascript translator.
- Create a .n
On Thu, 01 Jul 2010 17:09:29 -0300
"Leonardo M." Ramé wrote:
> Hi, I can't log-in to Mantis to report this. Please, if anyone can
> access create a report for this.
>
> The bug is this:
>
> When you press CTRL+SPACE after typing an object name in the editor, it
> shows its methods and propertie
On 2010-07-01 20:26, Reimar Grabowski wrote:
On Thu, 01 Jul 2010 20:12:52 +0300
Adem wrote:
Even though these can come across as nothing to do with Lazarus, they
actually are --if you consider the fact that here in Lazarus list people
are focused on writing applications, i.e. not compiler deve
On 1 July 2010 22:06, Reimar Grabowski wrote:
> I love you Graeme. Ever have, ever will. Life would be so empty without you.
>
> Kisses
> R.
>
> p.s.: Real men don't use Thunderbird
PS: Real men (or any men for that matter) shouldn't send me emails
like the above. My wife doesn't like competitio
On 2010-07-01 23:22, Florian Klämpfl wrote:
Hans-Peter Diettrich schrieb:
The compiler can create the required (ppu?) files, when compiling a C module. That file
then perfectly reflects all the settings, that affected the code generation of that
module. Only this "header" version is important
On 1 July 2010 18:58, Adem wrote:
>
> I will, however, ask whether you thought they were *fair*.
Those suggesting it, did not understand our companies needs. I think I
have explained myself already to a few of the core LCL developers (and
a few others too) so they might have a better understanding
Hans-Peter Diettrich schrieb:
>
> This is correct, and also is the most important reason for a tighter
> integration of C source code into FPC projects.
I cannot see how a tighter integration would solve this.
>
> The compiler can create the required (ppu?) files, when compiling a C
> module. T
Hi, I can't log-in to Mantis to report this. Please, if anyone can
access create a report for this.
The bug is this:
When you press CTRL+SPACE after typing an object name in the editor, it
shows its methods and properties (autocompletion, code insight,
you_name_it), that's ok, but, when the user
I love you Graeme. Ever have, ever will. Life would be so empty without you.
Kisses
R.
p.s.: Real men don't use Thunderbird
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mai
On 1 July 2010 18:18, Reimar Grabowski wrote:
> Yes, some Lazarus users might be interested in this topic, but that does
> not change the fact that this is the wrong list to discuss this, as the
> thread clearly shows. Nearly no mention of Lazarus at all.
Lazarus users use FPC! Lazarus doesn't sup
Michael Schnell schrieb:
Ask yourself why GCC doesn't have preprocessed headers,
I supposed you mean "precompiled headers" and not "headers that are
passed through the preprocessor.
This is according to what I called the "C philosophy" in the other mail.
Even if this philosophy is simplistic
Florian Klaempfl schrieb:
A FP-propriety interface part would be added to the C units to make them
create an FP compatible compiled unit, usable in the normal way by
Pascal units and by the linker.
... and not fully automatable, so not better than current solutions.
Even worse, it does not co
On 7/1/2010 1:14 PM, Michael Van Canneyt wrote:
- Make fcl-passrc complete. (*NOT* extract parser from compiler).
+1
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
On Thu, 1 Jul 2010 19:14:40 +0200 (CEST)
Michael Van Canneyt wrote:
> Well, if you need things to do:
> - Make fcl-passrc complete. (*NOT* extract parser from compiler).
+1
R.
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top
On 2010-07-01 19:51, Alexsander Rosa wrote:
"It's a trap!" - Admiral Ackbar
What MS really wants is that you write code in
whatever-language-you-please as long as you run it at THEIR operating
system. Forget Mono and other silly attempts to clone .NET Framework
-- they are doomed to always l
On Thu, 01 Jul 2010 20:12:52 +0300
Adem wrote:
> Even though these can come across as nothing to do with Lazarus, they
> actually are --if you consider the fact that here in Lazarus list people
> are focused on writing applications, i.e. not compiler develeopment,
> anything that can expand/he
On 2010-07-01 20:10, theo wrote:
> Your fpGUI as well as Michael's (Schnell) MSEide+MSEgui and other
Cui honorem, honorem ;-)
His name is Martin Schreiber (MSEide+MSEgui)
Thank you for the correction.
I apologize for the typo.
Cheers,
Adem
--
__
On Thu, 1 Jul 2010, Hans-Peter Diettrich wrote:
Do you seriously expect that things will change, without any feedback? :-(
Perhaps you missed the ToPas documentation, available in a separate download?
I know that this project is very hard to use, due to the dependency on
external resources
On 2010-07-01 12:10, Reimar Grabowski wrote:
On Thu, 1 Jul 2010 00:19:34 +0200
Mattias Gaertner wrote
You could have asked the fpc team or put it into one of the many free
repositories. If you put something into lazarus examples then lazarus users
expect a reason for downloading 650KB extra.
> Your fpGUI as well as Michael's (Schnell) MSEide+MSEgui and other
Cui honorem, honorem ;-)
His name is Martin Schreiber (MSEide+MSEgui)
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/lis
On 2010-07-01 11:19, Graeme Geldenhuys wrote:
fpGUI and LCL have very different goals, even though, from a distance, they
look like the same thing.
And, I am sure people get to appreciate their differences once they
spend a little time to understand what they are.
Your fpGUI as well as Micha
"It's a trap!" - Admiral Ackbar
What MS really wants is that you write code in
whatever-language-you-please as long as you run it at THEIR operating
system. Forget Mono and other silly attempts to clone .NET Framework --
they are doomed to always lag behind MS implementation. That's the
oppos
>> Since accessing header files is repeated as possible advantage files
>> again
>> and again, how much progress have you made in the opposite direction?
>>
>> Automated header translation
>
> Sorry, I don't understand your point :-(
The point is: if an additional C front end for fpc could do f
On Thu, 01 Jul 2010 00:54:21 +0200
Hans-Peter Diettrich wrote:
> For now it's sufficient to discuss the possibilities from the user VP,
> that's why I started this thread in the Lazarus list.
Epic fail.
This is the Lazarus users list and not the FPC users list. Why not discuss it
in the correc
Michael Schnell schrieb:
On 06/30/2010 10:23 PM, Adem wrote:
If you could compile, say, Modula (or C/C++) with FPC, you would have
direct access to a huge & time-tested resource of libraries
In fact being able to tightly integrate C code (I can't speak for C++,
as I can't speak it) would be
Florian Klaempfl schrieb:
In fact I already missed sadly a fully working preprocessor (to be
activated optionally).
Even if FPC supported such a mess, this won't solve the fundamental
problem with C headers: they work only properly if every used header is
compiled for each source file again s
Michael Van Canneyt schrieb:
You are missing the point. The point is not DOING it. the point is the
support afterwards. After 15 years of FPC support, I have some experience.
Even now, bugs creep up that are seemingly SO basic:
W : word;
begin
w:=0;
for i:=0 to pred(w) do // What to do ?
end
Michael Schnell schrieb:
In fact I already missed sadly a fully working preprocessor (to be
activated optionally). This does help with Pascal sources from time to
time (in fact I do like macros better than generics :) ).
You could use the scanner/preprocessor part of ToPas, if you want an
fu
Florian Klaempfl schrieb:
I'm still dreaming of a FreeWirth (though admitted, M2 is so close (both
parsing, modulesystem and language type) that one could regard it as a
dialect.
Aren't you against a e.g. .Net backend because it requires a completely
different runtime :)? I think the same appl
Florian Klaempfl schrieb:
I am not sure about the 'slightest advantage' aspect: I thought MS sold
the .Net thing mostly on the premise of 'write in the language you're
most comfortable yet share with others you/they find useful';
Exactly, "sold". It's marketing speech. You could use any langua
Marco van de Voort schrieb:
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 t
Marco van de Voort schrieb:
I am curious: Since compilers are your domain, allow me to ask: Do you
think Borland did that (peppering code with '$externalsym xx ' stuff)
because there was not other/better way? And, if you had a truly
compatible C/C++ compiler, would you end up doing that too?
Michael Schnell schrieb:
> On 07/01/2010 11:15 AM, Florian Klaempfl wrote:
>> ... which does not mean that it fits into the Pascal philosophy.
> Of course it does not. That exactly was my point.
So it's pretty clear that a C front end does not change much.
--
On 07/01/2010 11:15 AM, Florian Klaempfl wrote:
... which does not mean that it fits into the Pascal philosophy.
Of course it does not. That exactly was my point.
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists
On 07/01/2010 11:22 AM, Marco van de Voort wrote:
I don't hate C. I use it daily. But I still think it shows that it was never
meant for applications programming(*). For that I think "workable" doesn't
apply. Survivable maybe, but IMHO not something one would choose if you
could avoid it.
Yep. T
Michael Schnell schrieb:
> On 07/01/2010 10:00 AM, Florian Klaempfl wrote:
>> Even if FPC supported such a mess, this won't solve the fundamental
>> problem with C headers: they work only properly if every used header is
>> compiled for each source file again
>
> Yep. Thats a fundamental philosop
On Thu, Jul 01, 2010 at 11:08:49AM +0200, Michael Schnell wrote:
> > Ask yourself why GCC doesn't have preprocessed headers,
> I supposed you mean "precompiled headers" and not "headers that are
> passed through the preprocessor.
>
> This is according to what I called the "C philosophy" in the ot
On 01/07/10 10:14, Florian Klaempfl wrote:
Henry Vermaak schrieb:
On 01/07/10 09:57, Marco van de Voort wrote:
Yes, and this is why gcc and most other C compilers have a totally manual
build systems, where you have to manually specify depedancies, so the
compiler can figure out what to recompi
Michael Schnell schrieb:
> On 07/01/2010 10:51 AM, Marco van de Voort wrote:
>> Ask yourself why GCC doesn't have preprocessed headers,
> I supposed you mean "precompiled headers" and not "headers that are
> passed through the preprocessor.
>
> This is according to what I called the "C philosophy
Henry Vermaak schrieb:
> On 01/07/10 09:57, Marco van de Voort wrote:
>>
>> Yes, and this is why gcc and most other C compilers have a totally manual
>> build systems, where you have to manually specify depedancies, so the
>> compiler can figure out what to recompile.
>
> I just use gcc -MMD in my
On Thu, 1 Jul 2010 00:19:34 +0200
Mattias Gaertner wrote:
> You could have asked the fpc team or put it into one of the many free
> repositories. If you put something into lazarus examples then lazarus
> users expect a reason for downloading 650KB extra.
> If the above is the only reason, then yo
On 07/01/2010 10:51 AM, Marco van de Voort wrote:
Ask yourself why GCC doesn't have preprocessed headers,
I supposed you mean "precompiled headers" and not "headers that are
passed through the preprocessor.
This is according to what I called the "C philosophy" in the other mail.
Even if this
On 01/07/10 09:57, Marco van de Voort wrote:
Yes, and this is why gcc and most other C compilers have a totally manual
build systems, where you have to manually specify depedancies, so the
compiler can figure out what to recompile.
I just use gcc -MMD in my Makefiles, which generates the depen
On 07/01/2010 10:57 AM, Marco van de Voort wrote:
And no other C compiler would be compatible with it, voiding the only
positive aspect of C.
As this is a pure addition to make the code integrate with FP, only
necessary if other FP units are supposed to use this interface (the
linker can do wi
On Thu, Jul 01, 2010 at 10:21:30AM +0200, Michael Schnell wrote:
> On 07/01/2010 10:00 AM, Florian Klaempfl wrote:
> > Even if FPC supported such a mess, this won't solve the fundamental
> > problem with C headers: they work only properly if every used header is
> > compiled for each source file
On Thu, Jul 01, 2010 at 09:34:12AM +0200, Michael Schnell wrote:
> On 07/01/2010 08:26 AM, Marco van de Voort wrote:
> > Since accessing header files is repeated as possible advantage files again
> > and again,
> In fact I already missed sadly a fully working preprocessor (to be
> activated opti
On 07/01/2010 10:00 AM, Florian Klaempfl wrote:
Even if FPC supported such a mess, this won't solve the fundamental
problem with C headers: they work only properly if every used header is
compiled for each source file again
Yep. Thats a fundamental philosophy of C. In fact there is a compiler
On 1 July 2010 09:37, Adem wrote:
> of owen-fresh code; we're simply talking about some possible/probable future
> direction and whether it would be a good idea to make provision for that
Fair enough. Civilised discussions would be nice to see for a change. :-)
> But, I can't quite recall whe
Michael Schnell schrieb:
> On 07/01/2010 08:26 AM, Marco van de Voort wrote:
>> Since accessing header files is repeated as possible advantage files
>> again
>> and again,
> In fact I already missed sadly a fully working preprocessor (to be
> activated optionally).
Even if FPC supported such a m
On Thu, Jul 01, 2010 at 09:18:06AM +0200, Michael Schnell wrote:
> On 06/30/2010 10:23 PM, Adem wrote:
> > If you could compile, say, Modula (or C/C++) with FPC, you would have
> > direct access to a huge & time-tested resource of libraries
>
> In fact being able to tightly integrate C code (I
On 2010-07-01 10:17, Graeme Geldenhuys wrote:
2010/6/30 Adem:
IOW, this sort of thing should be a precondition to such contributions. Keeping
the door ajar (or, at least, not closed) for this sort of thing would be
--IMHO-- a good thing as it is likely to bring on (more) commercial (and,
hen
On Thu, Jul 01, 2010 at 09:26:35AM +0200, Florian Klaempfl wrote:
> > FP-Pascal and GNU-C++. I don't know it it's possible at all to share
> > classes between Pascal and C++, even if FP would be enhanced to compile
> > C++ code.
>
> Only as a cppclass because the Object Pascal class modell is very
On 07/01/2010 08:26 AM, Marco van de Voort wrote:
Since accessing header files is repeated as possible advantage files again
and again,
In fact I already missed sadly a fully working preprocessor (to be
activated optionally). This does help with Pascal sources from time to
time (in fact I do l
Hello,
perhaps I'm missing the point but I think it would be a good idea to
enhance "swig" to create fpc-bindings to C++-Classes. Personally I
think there is no problem with having another C-Compiler.
Regards,
Stephan
--
___
Lazarus mailing list
Lazar
On Thu, Jul 01, 2010 at 08:48:00AM +0200, Florian Klaempfl wrote:
> >> And, frankly, the project is called "Free Pascal" for a simple reason:
> >> it is a *Pascal* compiler and a *Pascal* project.
> >
> > I'm sorry. Can't agree with that.
> >
> > I'm still dreaming of a FreeWirth (though admitt
Michael Schnell schrieb:
> On 06/30/2010 10:31 PM, Florian Klämpfl wrote:
>> This can be done already using compilers supporting these languages
> As discussed multiple times it's not possible to share classes between
> FP-Pascal and GNU-C++. I don't know it it's possible at all to share
> classes
On Thu, 1 Jul 2010, Hans-Peter Diettrich wrote:
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 peo
On 06/30/2010 10:31 PM, Florian Klämpfl wrote:
This can be done already using compilers supporting these languages
As discussed multiple times it's not possible to share classes between
FP-Pascal and GNU-C++. I don't know it it's possible at all to share
classes between Pascal and C++, even if
On 2010-07-01 09:23, Marco van de Voort wrote:
There is a difference between hope and dreaming. Be careful that you don't get hung up in
some scenario where you "wait" for people to come, or wait till the hordes come
and help out in the purest open source spirit.
Somehow that never happens.
We
On 06/30/2010 10:23 PM, Adem wrote:
If you could compile, say, Modula (or C/C++) with FPC, you would have
direct access to a huge & time-tested resource of libraries
In fact being able to tightly integrate C code (I can't speak for C++,
as I can't speak it) would be really nice to have. To be
2010/6/30 Adem :
> IOW, this sort of thing should be a precondition to such contributions.
> Keeping the door ajar (or, at least, not closed) for this sort of thing
> would be --IMHO-- a good thing as it is likely to bring on (more) commercial
> (and, hence/hopefully more stable) interest to the FP
75 matches
Mail list logo
