A non-text attachment was scrubbed...
Name: not available
Type: text/plain
i do like the idea of a preprocessor - it could be quite useful. Size: 57 bytes
Desc: not available
Url : http://localhost/pipermail/lazarus/attachments/20020307/ca6fb145/attachment.bin

There is no reason why this could not be developed parallel to the development of 'traditional' DB controls in lazarus. There are several approaches possible to this problem. Yours can be one of them.

But you should explain your ideas in more detail so the impact of the changes can be estimated.

I think everyone has an open mind :-)

I don't think we will add a preprocessor to the compiler; macroitis is a serious disease of C and should be kept as far from the language as possible, however I see no reason why an editor could not pipe each file through a preprocessor before feeding it to the compiler. What is more, in an IDE, the preprocessor could be specified - making it a more powerful tool than integrating the preprocessor in the compiler. On top, it should not be hard to add.

Michael.

Kevin Berry wrote:
">
Agree with you 100%.
� wrote:

[...snip...]
I don't think we will add a preprocessor to the compiler; macroitis is a serious disease of C and should be kept as far from the language as possible, however I see no reason why an editor could not pipe each file through a preprocessor before feeding it to the compiler. What is more, in an IDE, the preprocessor could be specified - making it a more powerful tool than integrating the preprocessor in the compiler. On top, it should not be hard to add.

Michael.

Do You Yahoo!?
Try FREE Yahoo! Mail -
the world's greatest free email!
Agree with that too. Option to specify preprocesor from IDE is usefull enough, but I'm sorry you sounded like it already is possible? Is it???

matjaz

I want Delphi compatibility to easily upgrade Delphi code to FPC not to create hybrids. Can u give a more detailed example of your aproach?

I totally agree, that Preprocessing is a serious disease of C and should be kept as far as possible. There are far more drawbacks than goodies. But preprocessing in the normal sense is also pain for an IDE with code completion features. Delphis code insight is neither able to work with include files, nor compiler directives. The codetools already support include files and there is slight support for "dead" code, left out by compiler directives. But they have to do a lot of bookkeeping. FPC Macros will eventually be supported, you can think of them as small include files. Now think about automatically adding code, deleting code, replacing code and moving code. Code completion features works on the preprocessed code but it alters the sources itself. So it has to consider both sides of the will add a layer between it. And do not just think about the code insight features. The codetools will become much better. ;) But I'm sure, we can add functions to the IDE to get some "preprocessing" features without the big drawbacks. Best of both worlds.

Mattias

I'm developing a new approach that I need for software I'm developing (a bit more usefull than Borland has developed) and I'm interested how important is direct Delphi compatibility to lazarus project, since I would like to discuss possibility of change in CVS (extending some things).

REASON:
Here is the reason why: I need few different approaches to data with same form in my app and I wouldn't like to develop new edit control for every one. I've always hated to have twenty edit controls just for accesing different data) So I'm developing a kind of data wrappers that use standard component set that's already in lazarus.

EXPLANATION:
I would like to contribute them to main branch, but only if you'd be comfortable with breaking delphi and kylix component compatibility (not by losing but gaining).

Idea means avoiding developing dbcontrols and make editing wrappers, which can be connected to any source not only db. So far there are only lightly changed lcl components that don't make control incomaptible with the one in CVS. Light change means few lines of code for one control and a bit more for TControl but still not much. Same control can be standalone or wrapped one. Question is not which control would we use, question is which wrapper or listwrapper (DB, XML, whateveryounameit...). Same function that would allow app to combine several complitely different approaches in same app, with no form difference, except data wrappers. (P.S. It would not disable possibility to make delphi compatibility layer based on wrappers, with a little clean code, this controls could easily be developed, but I personally am the last person that would be interested in that)

It's not quite developed yet (first results are showing already), but in a month or so, there should be some first final results already.

I know this is a bit selfish since I've got no Delphi and Kylix appz to maintain (used C, FPC, XML...), but I wonder how others think about that kind of approach.

The second question one is more lazarus IDE connected: Does anybody except me misses some kind of preprocessor in pascal. If borland hasn't included one that should not be the rule for pascal not allowing that option.

Some comments???

matjaz

A non-text attachment was scrubbed...
Name: not available
Type: text/plain
agree with you 100%.
Size: 540 bytes
Desc: not available
Url : http://localhost/pipermail/lazarus/attachments/20020307/d38355c5/attachment.bin

Mattias Gaertner wrote:
">
On Thu, 7 Mar 2002 22:16:38 +0100 (CET) wrote:

On Fri, 8 Mar 2002, Matjaz Mihelic wrote:

I know this is a bit selfish since I've got no Delphi and Kylix appz tomaintain (used C, FPC, XML...), but I wonder how others think about thatkind of approach.

I want Delphi compatibility to easily upgrade Delphi code to FPC not to create hybrids.Can u give a more detailed example of your aproach?

The second question one is more lazarus IDE connected: Does anybodyexcept me misses some kind of preprocessor in pascal. If borland hasn'tincluded one that should not be the rule for pascal not allowing thatoption.

I don't think we will add a preprocessor to the compiler; macroitis is aserious disease of C and should be kept as far from the language aspossible, however I see no reason why an editor could not pipe each filethrough a preprocessor before feeding it to the compiler. What is more, inan IDE, the preprocessor could be specified - making it a more powerful toolthan integrating the preprocessor in the compiler. On top, it should notbe hard to add.

I totally agree, that Preprocessing is a serious disease of C and should be kept as far as possible. There are far more drawbacks than goodies.But preprocessing in the normal sense is also pain for an IDE with code completion features. Delphis code insight is neither able to work with include files, nor compiler directives. The codetools already support include files and there is slight support for "dead" code, left out by compiler directives. But they have to do a lot of bookkeeping. FPC Macros will eventually be supported, you can think of them as small include files. Now think about automatically adding code, deleting code, replacing code and moving code. Code completion features works on the preprocessed code but it alters the sources itself. So it has to consider both sides of the will add a layer between it.And do not just think about the code insight features. The codetools will become much better. ;)< br>But I'm sure, we can add functions to the IDE to get some "preprocessing" features without the big drawbacks. Best of both worlds.Mattias_________________________________________________________________ To unsubscribe: mail with "unsubscribe" as the Subject archives at http://www.miraclec.com/list_archives/lazarus

Basic idea is not to take away anything but to add a EditWrapper component, in some points of class function there would need some

� if Wrapper nil then
� �
�
� else
� � DoClassicStuff;

Where it would be needed
� Wherever state and editing comes in question, by starting and stoping editing

Basically, idea goes like this
instead of TDataLink for TDBEdit
Add a wrapper to TControl, TEdit has inherited that and our new TEdit can be controled from anywhere or any data structure same as TLabel, TListbox....

>>> Our wrapper would mean same control over value and state

of any kind of control.

Use this wrapper as is, and simulate TDataLink to get compatibility >> TDBEdit

This way using my suggestion there would be a wrapped control over editing, but easy gaining compatibility with Borland.

Again, nothing, no any function would be taken out. There would be only addition over state and value from outside for all components accesing the standard wrappers.

TWrapper = class(TObject)
� Control: TControl;
� OwnerList: TWrapperList;
� State: TState;
� Value: TVariant; // or anything
end;
TWraperList = class(TList)
// I think it's obvious where I'm pointing
end;

This way would allow us to reverse control over data controls. Have one derived special wrapper list for every job for any component, and not a complete control set for every kind of data. You change wrapper, you changed data source for complete form.

Hasn't nobody else but me being bored using one control set for accesing normal input, one control set for DB, one control set to control for accesing Btrieve....???? I already tried to do something like that on Delphi, but the damn f...up was closed for any kind of internal lower editing of components. I would just end up deriving another set of components??? Bugger... Every time I set up Delphi for me I end up with hundred of components, but there's only 20 or 30 basic ones by using my solution. And there's always simple way to make compatibility set that would allow to set propertys other way (Since component is already working with wrapper and propertys are compatible, maybe I'm confuzed but doesn't that mean we'd gain compatibility???).

In case of preprocessor, I was asking about. Wouldn't be nicer to write a preprocessor that knows how to <#include somelibrary.h>, than waiting some of us to translate C headers in pascal (that's first idea that comes to my mind, and this one would put project much further than it really is, there would be no need to develop or translate things already done, but case of preprocessing I'm thinking one is simply as suggested >> IDE specified preprocessor tool, started in another CVS project completely out of, or with lazarus but different branch (This way lazarus wouldn't suffer any consequences, but gain a lot))?

matjaz

It is not that easy. The problem with a preprocessor is that it destroys all constants and macros.

e.g.

#define GTK_COLOR_BLACK 0
#define GTK_COLOR_WHITE 1

is lost when you preprocess it. The preprocessor replaces all occurrentces of these constants with the actual values.

so you need 2 passes:

1 pass which takes care of constants and macros only. (unpreprocessed) 1 pass which takes care of the actual function/procedure definitions. This can/should be preprocessed.

Then the two passes must be reconciled...

This is not easy to solve. What is more,
- it depends on some C defines being available or not (e.g. various POSIX defines) etc etc etc.
- Sometimes, headers are included which are not available, and which are strictly speaking not needed for translation - but they do stop the preprocessor...

Like I said, preprocessing and macroitis is a serious problem... There is no easy way out.

Adding an (external) preprocessor is not the hard part;
it is maybe 10 lines of code; but the output may/may not be usable.

Michael.

I like the idea.

Since it is impossible to translate any c header file to good pascal code, the current h2pas is the better solution. I would like to add a h2pas frontend to the IDE, so that using c libraries will become much easier. But before that, h2pas must be improved.

Mattias

Michael Van Canneyt wrote:
">
On Sat, 9 Mar 2002, Matjaz Mihelic wrote:

Mattias Gaertner wrote:

On Fri, 8 Mar 2002 09:43:14 +0100 (W. Europe Standard Time)Michael Van Canneyt wrote:

Since it is impossible to translate any c header file to good pascal code, the current h2pas is the better solution.I would like to add a h2pas frontend to the IDE, so that using c libraries will become much easier. But before that, h2pas must be improved.

What is missing in h2pas ? (except a preprocessor :) )

:)If someone does that, I will write a frontend for it.

What is missing?? Let's look at the thing from the right angle. I've gotsomelibrary.1.1.2. Somebody else is having somelibrary.1.1.1. This twoversions are not necesarilly compatible. But the case is the guy thatmade header translatoion had 0.3.1. Then he somehow stopedd postingupdates. We lose nobody gains.My suggestion is to go dig deep further. Combine preprocessor with gccor make this bastard, does something like that, so unit headers would beobsolete. Every got dam'n lib comes with devel. We'd gain instantlyaccess to whole api.Let's see now there will be gtk2, how long will it take to translateheaders, half of the time to gtk3, we always lose. We could do some goodthing.

See my other mail for some serious obstacles to this approach.If you can solve these without changing the compiler/language,fine. If not: There is a problem :-)Personally, I think that h2pas can be extended so it tries to do abetter job, and that it should be used to create 'temporary' unitswhich are produced on the fly.The most I can agree with is to add a new keyword 'usesheader' to pascal:uses unitA; UnitB;usesheader libC1,libC2;the compiler could then try to spawn h2pas to create a temporary unitfrom the headers, which it then proceeds to compile to a real pascalunit, which is then used in further compilation.This does not compromise the pascal language, and should give allflexibility to use C libraries.As a side remark, and don't take this personal, but: please try not to useoffensive language. The use of offensive language diminishes thecredibili ty of a message. Not just yours, but anyones message.(Unless you're posting a joke of course ;))Michael._________________________________________________________________ To unsubscribe: mail with "unsubscribe" as the Subject archives at http://www.miraclec.com/list_archives/lazarus

Sorry about b..., it slipped me somehow and I hope nobody's feelings weren't compromised. 'll keep my fingers on the right place by using "hammer" spell checker not to write like that anymore.

I'll not write words like that anymore
I'll not write words like that anymore
I'll not write words like that anymore
I'll not write words like that anymore
I'll not write words like that anymore
'll do few hundred more but on my own computer, without using clipboard, but this time act it was semi-joke

By the way I like the idea {$usesheader some.h} and using h2pas.

What is missing in h2pas ? (except a preprocessor :) )

Michael.

Also the {$useheader xx} is something that will never make it into the compiler. We are a pascal compiler not a C compiler.

Thx god.

IMHO an option for h2pas in the IDE is not that usefull, it can only be used for very simple .h files not for complex things like gtk/gnome.

Just to avoid misunderstandings:
The frontend I have in mind, will be something of a dialog to easily manage the h2pas options and add some functions to the IDE, to make the boring search&replace easier, which is often needed before/after applying h2pas. These options and editing steps can be saved to a file, so that the next time a newer version of the header files can be converted faster. I think, this could help to accelerate the conversion process. Of course I'm not a c to pascal conversion crack, and I don't know any such frontend, so I need some help to gather good ideas, what functions are needed for c to pascal conversion.

Mattias

I don't think that automatic conversion is feasable. Even if it would work reasonably for some sources, simple rearrangements (introductions of macro's in newer minor versions) could break the Pascal interface, while C would keep running.
It would require awful lot of work, and still would be fragile.

I think the best thing available is try to speed up conversion time by enhancing h2pas with some tweaked codetools edit component, so interactively.

Please no additions! {$useheader xx} then.

I think this might be interesting, if the level of abstraction is done right (input and output to a control). If then extended to sort of some internal transaction system, this could even replace TAction stuff (maybe). For a start, could you make a sample implementation on a copy of TEdit into a separate tree so that we make try it out and evaluate? I'd like to see how it works out implemented, as theory always looks bright :-)

There is always a place for better approaches !

(And Delphi compatibility can be resolved later just by means of some kind of preprocessor, or one time import processor. There just have to be a good reason).

Note that this is only my opinion, and speaking for myself only.

Michal

-------------- next part --------------
A non-text attachment was scrubbed...
Name: bin00006.bin
Type: application/octet-stream
Size: 3253 bytes
Desc: "S/MIME Cryptographic Signature"
Url : http://localhost/pipermail/lazarus/attachments/20020308/c4445046/bin00006.bin

See my other mail for some serious obstacles to this approach. If you can solve these without changing the compiler/language, fine. If not: There is a problem :-)

Personally, I think that h2pas can be extended so it tries to do a better job, and that it should be used to create 'temporary' units which are produced on the fly.

The most I can agree with is to add a new keyword 'usesheader' to pascal:

uses unitA; UnitB;
usesheader libC1,libC2;

the compiler could then try to spawn h2pas to create a temporary unit from the headers, which it then proceeds to compile to a real pascal unit, which is then used in further compilation.

This does not compromise the pascal language, and should give all flexibility to use C libraries.

As a side remark, and don't take this personal, but: please try not to use offensive language. The use of offensive language diminishes the credibility of a message. Not just yours, but anyones message.

(Unless you're posting a joke of course ;))

Michael.

Sorry about b..., it slipped me somehow and I hope nobody's feelings weren't compromised. 'll keep my fingers on the right place by using "hammer" spell checker not to write like that anymore.

It's ok. It's in your own interest anyway :-)

We'll see what we can do. Cooking up such an idea is not so difficult; it is the implementation which makes it hard. H2pas currently doesn't 'like' lots of C headers - mostly thanks to preprocessor/macro tricks :/

Some macros simply cannot be translated without user intervention because you don't know the type of the operands on which it operates. GTK for example is full of it...

Anyway, this should be discussed in the compiler core team. AFTER the release of 1.0.6...

Michael.

Also the {$useheader xx} is something that will never make it into the compiler. We are a pascal compiler not a C compiler. You always need to do some manual adaption after translating C header files. Especially the macro's need to be translated into usefull function. Simply skipping macro's is not an option.

There is a preprocessor for h2pas called h2paspp. It preprocesses the files simply using #ifdef etc. I've tried in the past using cpp but that didn't work because it removed to much information that is required for translating the header.

IMHO an option for h2pas in the IDE is not that usefull, it can only be used for very simple .h files not for complex things like gtk/gnome.

Peter

Mattias Gaertner wrote:
">
On Fri, 8 Mar 2002 09:43:14 +0100 (W. Europe Standard Time)Michael Van Canneyt wrote:

Since it is impossible to translate any c header file to good pascal code, the current h2pas is the better solution.I would like to add a h2pas frontend to the IDE, so that using c libraries will become much easier. But before that, h2pas must be improved.

What is missing in h2pas ? (except a preprocessor :) )

:)If someone does that, I will write a frontend for it.

What is missing?? Let's look at the thing from the right angle. I've got somelibrary.1.1.2. Somebody else is having somelibrary.1.1.1. This two versions are not necesarilly compatible. But the case is the guy that made header translatoion had 0.3.1. Then he somehow stopedd posting updates. We lose nobody gains.

My suggestion is to go dig deep further. Combine preprocessor with gcc or make this bastard, does something like that, so unit headers would be obsolete. Every got dam'n lib comes with devel. We'd gain instantly access to whole api.

Let's see now there will be gtk2, how long will it take to translate headers, half of the time to gtk3, we always lose. We could do some good thing.

Get API in time with other developers, combine our resources with theirs, and be able to do something more than we do now is what I'm thinking.

Other example. File formats... would you say that your own implementation of png will be better than png. Accessing OpenOffice documents and other OO shared libs

h2pas is not bad, but extension to h2pas that digs further????? Extension and inclusion would not seem like a bad idea to me.

I've taken my self two months to test kylix, tested delphi my whole bussines life. But there are details that make freepascal and lazarus go beyond limitations of proprietary software.

As for one of your previous comments. Yes, wine functions are part of every software you produce, only the smallest software would allow to avoid wine. As for delphi, the god damn m...f... is not portable CLX is not enough to make a sandwich, about serious coding you always end up with platform dependent functions (no way to avoid).

Preprocessor of that kind would need.
Parser of gcc configuration
Being able to go dig in subunit.
Eventually even avoid macro's, they're not vital as you see where I'm pointing. Being able to make abstraction unit that calls lib functions. <#include somelibrary.h> changes to somelibrary.pas in some way that we'd agree on, and job's done, interface is correct and source had to change the smallest way.

But as it concerns wrappers, I guess everyone has agreed that is a good idea. I'll make my API freeze, and start making changes. Lower objects I'll just update with changes and comment changes a lot, upper I'll make some class extension to be clearly what's added. Then after, if you'd approve change you'd have easyer implementing in CVS.
">
Mattias_________________________________________________________________ To unsubscribe: mail with "unsubscribe" as the Subject archives at http://www.miraclec.com/list_archives/lazarus

matjaz

This message is ment for all, that were involved in "About compatibility???" thread

Mattias Gaertner wrote:
">
On Sat, 09 Mar 2002 15:19:35 +0100Peter Vreman wrote:

Also the {$useheader xx} is something that will never make it into the compiler. We are a pascal compiler not a C compiler.

Thx god.

You're not the only one that thanks god. :-D

Even though I suggested that option, you've made a bit too much fuzz. One of the parts of project I'm working on, is fairly connected to that option. This includes parsing other language sources to some limit. Something like .h files were only one of the options >>> Other one would be easy translate of strings in some const unit in some other language by using some good external command (language translator) line solution. Please don't make fuzz of this again, but there could also be a fairly nice pascal const file to preprocess. Or a text file, or XML, or name it. There is no limits. ;-)

Main example of idea really was <#include somelibrary.h>. That would call h2pas or any other translator and if it goes, it goes, otherwise I thought it would produce compiling error, but the idea with some learning converter as suggested bellow is fantastic. :-)

You've stuck with this idea of parsing C headers, like a <bee on a honey "*ouch, hammer spell checker in progress">. Why, when there is no limits, the only need is to carefully design external model that IDE would support. :-P

Specifiying in some dialog <#includeheader %1> = h2pas to activate that preprocessor function or anything is nice. Generates something like "BHhbdfhjydsgts.pas" and replaces <#includeheader> with normal uses this new file.
Having set language parameter in outer converter and specifiying <#includelanguage> and have this resource strings compiled in some other language. All except this IDE internal preprocessing is something what's already possible to solve with Tools menu. I reffered either to piped preprocessor, or direct to some file or anything. This option is something what concerns IDE, and not compiler. C seemed to me like a good example, but now I see it was the worst possible because of never ending "pas & c battle" or "limitations" or "....". :-(

Originally I was reffering to option, to have user defined preprocess function in IDE. "It was said that it would be possible". Ok. :-P

Idea was to have some Codetools option that would parse use external software to preprocess. That part wasn't agreed. Ok.
:-)

I admit I'm guilty by choosing some bad example, and bad description. Just like the Compatibility question. Read that term as:> Why bothering to make a copycat Delphi? We can make 100%compatible and better without question. :-[

EWrappers and other Component extensions I was suggesting, will be posted somewhere next week probably (Depends on free time I'll have in next week). I'll post them as elf executable, as program source - well comented and well comented changes I'm suggesting. I'm not trying to <be a mosquito "*ouch, hammer spell checker in progress">, I'd like to make some mistakes that Borland made go away, to give the lazarus users much cleaner code. :-\

Parser tools I'm doing my work on would be posted same way. I wasn't asking for solution I was asking for option. :-(

I felt preety dissapointed of fuzz, that suggestion made. Dissapointment goes to me, for a stupid example :-(
">

IMHO an option for h2pas in the IDE is not that usefull, it can only be used for very simple .h files not for complex things like gtk/gnome.

Just to avoid misunderstandings:The frontend I have in mind, will be something of a dialog to easily manage the h2pas options and add some functions to the IDE, to make the boring search&replace easier, which is often needed before/after applying h2pas.These options and editing steps can be saved to a file, so that the next time a newer version of the header files can be converted faster.

Please say that you mean external, not internal part, see your first comment. I don't wanna be blamed by the society for giving a bad example, that made pascal get <bad name "*ouch, hammer spell checker in progress">. :-(
">
I think, this could help to accelerate the conversion process.Of course I'm not a c to pascal conversion crack, and I don't know any such frontend, so I need some help to gather good ideas, what functions are needed for c to pascal conversion.

Yes, I've got the ideas to the solution (your learning kind of solution would boost them indefenitelly :-P ),
somehow it would be 2nd step of my project, but with codetools easy included (and they will be *external (command line without question) and CVS, maybe if approved even part of lazarus since I'm writing them directly for lazarus), so it's far from polished state. A month or two maybe as for my case. :-\
">
Mattias_________________________________________________________________ To unsubscribe: mail with "unsubscribe" as the Subject archives at http://www.miraclec.com/list_archives/lazarus

Carefull explanaton:
1. Again >>>>>>>> my question was made for IDE and not compiler, if it would be ment to compiler www.freepascal.org would be the right place. Question is about Codetools supporting some external model of user defined preprocessing, which on the other hand could make to be included with IDE if approwed. <<<<<<<<
:-(
2. I wasn't asking for specific solution, I was asking for possibility to the solutions like this :-\
3. Correct me if I'm wrong, but LCL units are not part or freepascal, so anyway changes I suggested go to LCL ;-)
4. Reason why parsers will be external. I don't wan't to slow down project lazarus, it's simply too good and as external they'll have much more options and easyer updating. :-\

matjaz

> Since it is impossible to translate any c header file to good pascal code, the current h2pas is the better solution. > I would like to add a h2pas frontend to the IDE, so that using c libraries will become much easier. But before that, h2pas must be improved. What is missing in h2pas ? (except a preprocessor :) )

:)

If someone does that, I will write a frontend for it.

Mattias

On Sat, 09 Mar 2002 12:23:10 +0100
Matjaz Mihelic wrote:

Maybe the h2pas dicussion is somewhat off topic for the lazarus list. I think, the fpc-pascal or fpc-devel list is more appropriate, since more fpc users are reading them.

ok

Mattias