Recent

Author Topic: Features for money ?  (Read 10968 times)

kupferstecher

  • Hero Member
  • *****
  • Posts: 583
Re: Features for money ?
« Reply #30 on: June 29, 2019, 11:20:07 pm »
The imagnation that one can force the implementation of non-pascalish features into FPC just with money is really frightening me.
You seem to have a vivid imagination. I haven't seen anyone in this thread suggest the addition of "non-pascalish" features to the compiler, for money or otherwise.
Perhaps not in this thread, but they are there. Inline type declaration, untyped variables...

The title "Features for money", in a way could be understood as "Syntax for money". You still think this would be a good idea?

Quote
"jack of all trades, master of none."...
In my narrow view angle, Freepascal is of really high quality and there is much more potential for improvements in Lazarus, especially for the mobile targets. For Freepascal I see in the embedded targets a good chance for growth. People are really looking for alternatives of C.
Didn't you ask before in the Forum for a change of the in/out/var naming? I would (mentally) support such cleanups, but I don't think its a good idea to push them with money.

440bx

  • Hero Member
  • *****
  • Posts: 3944
Re: Features for money ?
« Reply #31 on: June 30, 2019, 02:44:10 am »
Perhaps not in this thread, but they are there. Inline type declaration, untyped variables...
There will always be "questionable" ideas/requests but, even if they offer money to have them implemented, their chances won't be very good. 

The title "Features for money", in a way could be understood as "Syntax for money". You still think this would be a good idea?
I'm not sure what "syntax for money" really means but, while I do appreciate good syntax, good/nice syntax that does not implement something genuinely useful is of little interest (at least to me) and, very unlikely something I would financially support.


In my narrow view angle, Freepascal is of really high quality and there is much more potential for improvements in Lazarus, especially for the mobile targets. For Freepascal I see in the embedded targets a good chance for growth. People are really looking for alternatives of C.
There is plenty of room to improve Freepascal.  There are still fairly basic features missing, among them, the ability of having multiple variants in a record definition.  The absence of that feature makes porting C code to FPC more work than it should be.

I do agree there is room for improvement in Lazarus.  So far, I am under the impression the Lazarus developers are much more open to listen and consider suggestions than FPC's.


Didn't you ask before in the Forum for a change of the in/out/var naming? I would (mentally) support such cleanups, but I don't think its a good idea to push them with money.
No. I didn't ask for a change in the in/out/var naming.  What I asked for is the implementation of "in" and "inout" and remove the erroneous assumption FPC is currently making that a "var" should be initialized (chicks for free and useless compiler messages for nothing!.)

The purpose of "in", "out", "inout" is to enable the compiler to do more checking on behalf of the programmer to catch errors at compile time instead of runtime.  That is part of the soul of Pascal and one of the most significant advantages it has over other languages such as C (C++ has exceeded Pascal in that area but, in the syntax area, it's just a deformed C atrocity, radioactivity is really bad... even for computer languages.)

Implementing reliable mechanisms a programmer can use to enable the compiler to flag variable usage errors is worth money.  (lots of C programmers at one time bought "lint" specifically for that purpose.)


(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

Akira1364

  • Hero Member
  • *****
  • Posts: 561
Re: Features for money ?
« Reply #32 on: June 30, 2019, 06:27:32 am »
I sincerely doubt that there is anyone at all claiming features such as generics or inline variables are "confusing" who is under the age of 45, also.

I do feel like the general tone of your comment is perhaps a bit... aggressive, however: as an "older" developer myself, I am indeed annoyed when people around my age complain about stuff like this.

I certainly would not hire anyone who thought inline variables made Pascal "hard", as that just comes off like a sign of general incompetence to me.

julkas

  • Guest
Re: Features for money ?
« Reply #33 on: June 30, 2019, 10:35:12 am »
Classic Pascal is like the ancient Greek language - beautiful and precise. But modern people speak other languages.

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: Features for money ?
« Reply #34 on: June 30, 2019, 10:45:47 am »
The imagnation that one can force the implementation of non-pascalish features into FPC just with money is really frightening me.
You seem to have a vivid imagination. I haven't seen anyone in this thread suggest the addition of "non-pascalish" features to the compiler, for money or otherwise.
Perhaps not in this thread, but they are there. Inline type declaration, untyped variables...

The title "Features for money", in a way could be understood as "Syntax for money". You still think this would be a good idea?
The core developers would always have the final say anyway. That's why marcov said that such ideas should first be discussed on the forum or better on fpc-devel, because if it turns out that the core devs would say no anyway, then why waste money?

People are really looking for alternatives of C.

Yes, they absolutely are.

But they're also looking for languages that support extremely basic things like inline variable declarations, which all of the aging FPC die-hards like to pretend are the devil despite the fact that literally every language uses them and it is not a problem at all, because why the hell would it be.

The crybaby FUD "oh my god, Delphi is ruining Pascal because it introduced inline variable!" bullshit is unbelievably annoying. No, Delphi added a feature that should have been added long ago. Anyone who thinks that inline variables complicate anything is literally an idiot, who cannot possibly be anything resembling a professional programmer in 2019.
Those languages were designed around the ideas of inline variables. The idea of Pascal was an easy to read, declare first language. Inline variables are anything but. And "every other language out there has it" is not a valid reason to include something in a language.

Nobody cares that your language / compiler can make cool Android apps via Lazarus, if they are also aware that it has core developers who actually believe utterly moronic things like "generics are slower than using untyped pointers for everything" or whatever.
Well, it is a fact that a variant of TStringList based on generics was slower than the non-generic one. And especially if managed types (strings for example) are involved untyped pointers are indeed faster, but I personally favor the increased type safety I get with generics.



JernejL

  • Jr. Member
  • **
  • Posts: 92
Re: Features for money ?
« Reply #35 on: June 30, 2019, 11:57:31 am »
I think a bounty for features is a good approach.
 
I also would not think of a problem if there was a good unofficial FPC branch with more experimental and bleeding edge features, as long as it's synced to main fpc branch regularly.
 
The features needed the most are usually already presented in delphi, and can be simply handled as feature request bounties, if financial reward would help them get thru.
 
I would however also recomment a bounty for more up to date bindings for popular libraries, jedi was a good approach.. a long time ago, but lately, there's not much projects working on delphi interoperatibility bindings.
 

Thaddy

  • Hero Member
  • *****
  • Posts: 14204
  • Probably until I exterminate Putin.
Re: Features for money ?
« Reply #36 on: June 30, 2019, 01:24:32 pm »
Well, you forget that the standard distribution of FreePascal and Lazarus already contain *way* more features and bindings than Delphi ever had to this day.
And Jedi is too Windows centric to be a serious proposal. I would ask the Delphi community to get up to scratch with what FreePascal offers...... :D :D :D
Specialize a type, not a var.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: Features for money ?
« Reply #37 on: June 30, 2019, 01:30:28 pm »
There is plenty of room to improve Freepascal.  There are still fairly basic features missing, among them, the ability of having multiple variants in a record definition.  The absence of that feature makes porting C code to FPC more work than it should be.

(This is not true. There is a mechanical way to transform those, and if it happens enough you could write software for it or improve header converters:

Code: [Select]

type
    tsomeunion = record
                   case boolean of   
                      false : ( x : Integer);
                      true  : ( y : word;
                                case boolean of
                                             true : (z:word);
                                             false: (a:integer);
                                          );
                     end;

begin
end.
                         

See http://rvelthuis.de/articles/articles-convert.html

Which brings me back to the point, people that don't know what there is, shouldn't be designing language. That only leads to more syntax, and often duplicate just because some other language does it in a different way (and every newbie comes up with it each time again, queue inline variables)

Most new syntax is micro. Optimizations for very local problems, even the old  guideline "must make things possible not otherwise" is regularly trampled.
« Last Edit: June 30, 2019, 01:33:48 pm by marcov »

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: Features for money ?
« Reply #38 on: June 30, 2019, 01:39:39 pm »
So, the bottom line is, it is quite simply impossible to increase the popularity of FPC while simultaneously clinging to these woefully outdated and often wrong opinions on things.

Which is absolutely nonsense. People don't chose languages because of micro syntax, but because what they can do with it.

We heard this tired old line for every language change since 1997, and other than delphi compatibility features, I still have to see the first user coming because of such changes.

440bx

  • Hero Member
  • *****
  • Posts: 3944
Re: Features for money ?
« Reply #39 on: June 30, 2019, 03:20:11 pm »
(This is not true. There is a mechanical way to transform those, and if it happens enough you could write software for it or improve header converters:
really !?... if it is as simple as you are so conveniently pretending it is, I can't help but wonder why you haven't done it.  After all, I am under the impression that you are one of the main API header maintainers for FPC.

Code: [Select]
type
    tsomeunion = record
                   case boolean of   
                      false : ( x : Integer);
                      true  : ( y : word;
                                case boolean of
                                             true : (z:word);
                                             false: (a:integer);
                                          );
                     end;

begin
end.
                         
yes, most programmers know how to write a "hello world" program and translate a trivial union. 


See http://rvelthuis.de/articles/articles-convert.html
It seems to me that you should have read the article a bit more carefully.  One of the things required to apply the multiple "union collapsing" is determining the largest union in the group, something which in many cases is far from trivial since the type definition being used are very likely to be in other .h files and not in the .h file the program is processing.

Which brings me back to the point, people that don't know what there is, shouldn't be designing language.
I completely agree with that.  One thing I've noticed is that people who actually know how to design a programming language don't leave much, if any, "undefined territory" in it.   


That only leads to more syntax,
The point you are very conveniently missing is, even using the techniques Rudy shows in his article is less than desirable and the reason is obvious: when you look at the documented structure in MSDN it will no longer look like the translated structure.  Parallelism went out the window and, if there is a mistake somewhere, due to alignment or wrong size, it will be difficult to find.

Those are the things a well designed language avoids.  It doesn't create situations which demand a significant amount of attention from the programmer to solve them.

It's not about syntax, it's about code and definitions that are clear, succinct, accurate and easily understood. Yes, syntax most definitely has an influence in those areas.

It's no wonder Pascal has lost so much ground and isn't going anywhere.  Even trivial things that should have been implemented long ago, meet resistance supported by rather deficient reasoning.    Good thing the auto industry doesn't share your methods, we'd still be driving Model Ts which you could get any color you wanted as long as it was black.

« Last Edit: June 30, 2019, 03:23:17 pm by 440bx »
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: Features for money ?
« Reply #40 on: June 30, 2019, 03:43:21 pm »
(This is not true. There is a mechanical way to transform those, and if it happens enough you could write software for it or improve header converters:
really !?... if it is as simple as you are so conveniently pretending it is, I can't help but wonder why you haven't done it.  After all, I am under the impression that you are one of the main API header maintainers for FPC.

Because the problem is not big enough? The one or two that occasionally happen in a header are easier fixed by hand?

(Automated conversion is overrated in practice anyway, and that is mainly because of preprocessor/conditional code, and the fact that macros are substitution based, so you can't see the intention from the use only)

It seems to me that you should have read the article a bit more carefully.  One of the things required to apply the multiple "union collapsing" is determining the largest union in the group, something which in many cases is far from trivial since the type definition being used are very likely to be in other .h files and not in the .h file the program is processing.

Trying to find the next best remote detail to justify a solution to what is a non-problem?

Quote
The point you are very conveniently missing is, even using the techniques Rudy shows in his article is less than desirable and the reason is obvious: when you look at the documented structure in MSDN it will no longer look like the translated structure. 

Neither does any header. The 1:1 relation simply doesn't exist. For one thing, declarations are sorted.

Quote
Parallelism went out the window and, if there is a mistake somewhere, due to alignment or wrong size, it will be difficult to find.

Not really. If you want to check that you need unittests rather than source inspection anyway. See e.g. Wine.

Quote
Those are the things a well designed language avoids.  It doesn't create situations which demand a significant amount of attention from the programmer to solve them.

....For the duration of translating one union out of a mega headerset.

As said, syntax microoptimization for a non-problem. More syntax is worse than the problem it solves.

Quote
It's no wonder Pascal has lost so much ground and isn't going anywhere.  Even trivial things that should have been implemented long ago, meet resistance supported by rather deficient reasoning.    Good thing the auto industry doesn't share your methods, we'd still be driving Model Ts which you could get any color you wanted as long as it was black.

Your reasoning is that people would select a model T over a new car simply because it had a shade of colour that is not available for the new car. Totally disregard for proportion.

Actually, strike that. Color is an important feature. Make it some detail somewhere in the engine's suspension, and then you get the point.

And of course the elephant in the room is that users select languages more for framework than language details to begin with.

"What can I achieve in a short time with it?" is the central user tenet, and that is governed MORE by libraries than by language details. Which is why the "change this language feature and more users will come" argument is fundamentally flawed.

Micro language optimization only matters for language discussions in forums.
« Last Edit: June 30, 2019, 05:53:04 pm by marcov »

bylaardt

  • Sr. Member
  • ****
  • Posts: 309
Re: Features for money ?
« Reply #41 on: June 30, 2019, 05:39:55 pm »

"What can I achieve in a short time with it?" is the central user tenet, and that is governed MORE by libraries than by language details. Which is why the "change this language feature and more users will come" argument is fundamentally flawed.
+1
a good example here in brazil is the acbr project.

440bx

  • Hero Member
  • *****
  • Posts: 3944
Re: Features for money ?
« Reply #42 on: June 30, 2019, 06:10:28 pm »
Because the problem is not big enough? The one or two that occasionally happen in a header are easier fixed by hand?
That's an interesting comment.  If the problem is so small and trivial then how come FPC is missing so many APIs and structure definitions ? ...

You don't solve "small" problems ?

(Automated conversion is overrated in practice anyway,
Of course, a programmer's dream come true is to translate thousands of APIs and data structure definitions by hand. It is very kind of you not to want to deprive programmers of such pleasures.


Trying to find the next best remote detail to justify a solution to what is a non-problem?
It's a non-problem for people who don't program.  There is no doubt in my mind that API function and data structure definitions are likely a non-problem to the average shoe salesman but, for most programmers, they tend to make themselves needed.

Seen from that viewpoint, you're right, it really is a non-problem for a significant percentage of the population.

The 1:1 relation simply doesn't exist. For one thing, declarations are sorted.
There is a 1:1 relation in the translation of API headers.  There is _no good_ reason why there isn't a 1:1 relation when translating data structures.

Not really. If you want to check that you need unittests rather than source inspection anyway. See e.g. Wine.
Yes, really.  Parallelism does go out the window when there isn't a 1:1 between the original and the translation.  Wine is neither here nor there in the subject.

....For the duration of translating one union out of a mega headerset.
one union ?... are you inspecting a bacon-cheeseburger API ? ...  because Windows certainly has quite a few more data structure definitions that include a union and even multiple of them in the struct definition and, many of them are tedious to translate "manually" because Pascal is somewhat lacking in that area.


As said, syntax microoptimization for a non-problem.
This has nothing to do with "microoptimization" but... if I have to see how it has something to do with it, do feel free to enlighten me (I suspect you will anyway... though I refer to it as enlightenment because of my generous nature)

More syntax is worse than the problem it solves.
Nice technique.  You declare something and, because you did, it must be true.  Move over Bertrand Russell.

Your reasoning is that people would select a model T over a new car simply because it had a shade of colour that is not available for the new car. Totally disregard for proportion.
Nice try.  My "reasoning" is that if you were in charge of car designs, we'd all be driving Model Ts with triangular wheels (microoptimizing the wheels making them round would not solve any problem since the car can move with the wheels it has)

And of course the elephant in the room is that users select languages more for framework than language details to begin with.
Users hopefully (but not always, unfortunately) select the tool that makes the task easiest to accomplish correctly.  For some users, myself among them, it's rather "convenient" to have a complete set of API function and structure definitions (one of the very few things I miss about C/C++).  Having to deal with an incomplete set of APIs and, an often enough, not straightforward conversion of data structures, takes some shine away  from the tool.

"What can I achieve in a short time with it?" is the central user tenet, and that is governed MORE by libraries than by language details.
If all a programmer cares is how long it takes to achieve something with the language, they can spend their day writing "hello world" programs.  Even a beginning programmer should be able to write a few of them every day. 

You should give some thought that some programmers use a programming language for what they can accomplish with it and, if the language doesn't have the necessary capabilities to implement the target task then the time spent with that tool will be _zero_.

Which is why the "change this language feature and more users will come" argument is fundamentally flawed.
Did anyone say something to the contrary ?... I must have missed it.

Micro language optimization only matters for language discussions in forums.
You're rather fond of that meaningless term "micro language optimization". You get to pepper your deficient arguments with it to make them sound impressive.  Good stuff but, I have seen that syntax before.   


Marco,

I got to give you credit for being very consistent.   Any discussion of anything that could potentially help FPC go forward is "micro optimization" you don't want to have anything to do with.  That syntax horse is so dead by now... what a beating it got... poor thing.
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: Features for money ?
« Reply #43 on: June 30, 2019, 06:53:19 pm »
Because the problem is not big enough? The one or two that occasionally happen in a header are easier fixed by hand?
That's an interesting comment.  If the problem is so small and trivial then how come FPC is missing so many APIs and structure definitions ? ...

Maybe because unions are not the main problem?

Quote
You don't solve "small" problems ?

Depends. If the solution is adding to the language, you are making something big out of something small, due to the fact that needs to be supported ad infinitum, including all kinds of cross-talk.

Quote
(Automated conversion is overrated in practice anyway,
Of course, a programmer's dream come true is to translate thousands of APIs and data structure definitions by hand. It is very kind of you not to want to deprive programmers of such pleasures.

I'm still waiting for your maintainable auto-translation. While I'm sceptic, I'm still hoping you convince me otherwise.

Quote
Trying to find the next best remote detail to justify a solution to what is a non-problem?
It's a non-problem for people who don't program.  There is no doubt in my mind that API function and data structure definitions are likely a non-problem to the average shoe salesman but, for most programmers, they tend to make themselves needed.

Sure. But mostly on an exist or not level, not these kinds of details. The user just sees that his   .xxxx fieldreference works, no matter if it is a pascal nested union or a c nested union.

Quote
one union ?... are you inspecting a bacon-cheeseburger API ? ...  because Windows certainly has quite a few more data structure definitions that include a union and even multiple of them in the struct definition and, many of them
are tedious to translate "manually" because Pascal is somewhat lacking in that area.

I'm talking about those non trivial unions that might be hard to automatically map to current support (and then still: in theory)

Quote
As said, syntax microoptimization for a non-problem.
This has nothing to do with "microoptimization" but... if I have to see how it has something to do with it, do feel free to enlighten me (I suspect you will anyway... though I refer to it as enlightenment because of my generous nature)

Since you asked: microoptimization on language level. Not  necessarily code generator.

Quote
More syntax is worse than the problem it solves.
Nice technique.  You declare something and, because you did, it must be true.  Move over Bertrand Russell.

Who? I'm not that deep into Anglo-Saxon authors. Which period is he from? Elizabethan? Victorian?

Quote
Users hopefully (but not always, unfortunately) select the tool that makes the task easiest to accomplish correctly. 

True. But usually they avoid knowing all the details, and its the details we are discussing.

Quote
For some users, myself among them, it's rather "convenient" to have a complete set of API function and structure definitions (one of the very few things I miss about C/C++).  Having to deal with an incomplete set of APIs and, an often enough, not straightforward conversion of data structures, takes some shine away  from the tool.

Ah, that explains why you make the whole world revolve around your issue.

Anyway, enough sophism, while fun, I get tired of it quickly, so let's just cut to the chase:

  • I don't want big upsets to the current headers because they are hand maintained.
  • But I don't rule out anything if you come up with an automated tool to translate headers in sufficient quality. I'm probably even game if anything you show has  potential, even if it is not a drop in solution yet. I'm well aware of the current approach problems, just don't have the time to start the alternative from scratch
The current sets are not set in stone, and while I refrain from doing mass-restructures in them, I'm not above throwing them away for something better, and for all, consistent.

For that, I suggest you make a header conversion system that can take meta data instructions on how to translate. (e.g. lists of functions to also translate as var etc). So never edit the result, always edit the process (the converter) if a change needs to be made. Similarly the metadata can disambiguate most macros into decent structures.

I tried building something like that in 2003-2005 while translating commctrl, but alas, I already turned thirty, and my limitless free time periods were over.

In short it is a combination of "Le roi is mort, vive le roi!" and "be careful what you wish for". Show enough prowess with windows headers, and I'll gladly surrender the throne to you.  You'll be FreePascal's Windows header king!.

I got into this because in the 2000-2005 frame I did some new stuff with windows api, and the old 1998 headers were deficient and unmaintained. Many others also worked on it, but went out of steam long term, leaving me the defacto "king", though I never aspired to it. 

So, show me your metal, and there is a good chance you'll be king of the headers.
« Last Edit: June 30, 2019, 07:11:14 pm by marcov »

440bx

  • Hero Member
  • *****
  • Posts: 3944
Re: Features for money ?
« Reply #44 on: June 30, 2019, 09:59:34 pm »
Maybe because unions are not the main problem?
I see.. only the main problem deserves attention... the other problems don't.  I have to say, that's an economical way of paring the number of problems down.

Depends. If the solution is adding to the language, you are making something big out of something small, due to the fact that needs to be supported ad infinitum, including all kinds of cross-talk.
I simply mentioned that removing the limitation on variants forced to be unique and last would make translating headers easier. That is part of the solution but, it isn't only for C headers, it would also make some Pascal only record definitions simpler and easier.  No doubt, that's a terrible thing.

I'm still waiting for your maintainable auto-translation. While I'm sceptic, I'm still hoping you convince me otherwise.
I suggest you don't wait for that.  I never offered such a thing.  In this case, your self-grown skepticism is justified.  I have no intention of convincing you otherwise.

I'm talking about those non trivial unions that might be hard to automatically map to current support (and then still: in theory)
and what I'm talking about is enhancing the language to make the process simpler no matter how many nested unions and structs there are.  It's not about one particular case.

Since you asked: microoptimization on language level. Not  necessarily code generator.
is that statement supposed to answer a question ?... just a reminder, what is it you are so fond of calling "micro optimization" ?

Who? I'm not that deep into Anglo-Saxon authors. Which period is he from? Elizabethan? Victorian?
Don't worry about it.   There are some thing you shouldn't concern yourself with.  It's another one of those "non problems".

True. But usually they avoid knowing all the details, and its the details we are discussing.
Someone has to take care of the details for others to enjoy the luxury of ignoring them.


Ah, that explains why you make the whole world revolve around your issue.
No. It only explains why I used it as an example.  It's a good thing the world doesn't revolve around any of my issues, it would wreak havoc with seasons.

Anyway, enough sophism, while fun, I get tired of it quickly, so let's just cut to the chase:
That sounds like good news.  Hopefully, it means you're done typing words like "micro optimization" and "syntax <something" (I don't remember and don't really care to refresh my memory.)


  • I don't want big upsets to the current headers because they are hand maintained.
I doubt anyone is interested in big upsets to the current headers.  I'm guessing but, I doubt I'm the only one who would welcome any improvements that makes them easier and more straightforward to translate.

  • But I don't rule out anything if you come up with an automated tool to translate headers in sufficient quality. I'm probably even game if anything you show has  potential, even if it is not a drop in solution yet. I'm well aware of the current approach problems, just don't have the time to start the alternative from scratch
Sounds like you've been smoking some good stuff.  I hate to pop your high but, I never offered to create or improve an automated header translation tool. 

The current sets are not set in stone, and while I refrain from doing mass-restructures in them, I'm not above throwing them away for something better, and for all, consistent.
I'm quoting that "just in case" someone offers better and you attempt to drown them in "micro optimizations" and "syntax whatever".


For that, I suggest you make a header conversion system that can take meta data instructions on how to translate. (e.g. lists of functions to also translate as var etc). So never edit the result, always edit the process (the converter) if a change needs to be made. Similarly the metadata can disambiguate most macros into decent structures.
Very nice suggestion.  If someday I consider creating a header conversion program, I'll keep it in mind.

I tried building something like that in 2003-2005 while translating commctrl, but alas, I already turned thirty, and my limitless free time periods were over.
You couldn't solve that "non problem" before turning thirty ?... I think I'm disappointed now.

In short it is a combination of "Le roi is mort, vive le roi!" and "be careful what you wish for".
Good thing that's not a structure definition... it's "Le Roi est mort, vive le Roi!"... there is one field that got messed up in the translation.
 
Show enough prowess with windows headers, and I'll gladly surrender the throne to you.  You'll be FreePascal's Windows header king!.
I'm terrible at converting headers (everything I know about converting headers I just learned from the link you provided.)  In your case it's "Le Roi est vivant, vive le Roi!"... that reminds me, there are a couple of missing header definitions I submitted several months ago that the king has not processed yet.


So, show me your metal, and there is a good chance you'll be king of the headers.
I've just realized I'm a plastic (recyclable, of course) kind of guy.  No metal here (who wants rust anyway?)


Thank you for the warm welcome you gave to the idea that is the subject of this thread.




(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

 

TinyPortal © 2005-2018