Recent

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

440bx

  • Hero Member
  • *****
  • Posts: 1359
Re: Features for money ?
« Reply #45 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.




using FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 64bit.

kupferstecher

  • Sr. Member
  • ****
  • Posts: 331
Re: Features for money ?
« Reply #46 on: June 30, 2019, 10:55:18 pm »
@440bx:
Why are you getting that off-topic in "your own" thread?
The discussion about a single specific feature (in a way that it is not just used as an example) gives me the impression, that my scepticism was right and your reguest for "features for money" actually has the aim to push something through, that otherwise would be rejected.

440bx

  • Hero Member
  • *****
  • Posts: 1359
Re: Features for money ?
« Reply #47 on: June 30, 2019, 11:10:42 pm »
@440bx:
Why are you getting that off-topic in "your own" thread?
There is Marco to thank for that. 

The discussion about a single specific feature (in a way that it is not just used as an example) gives me the impression, that my scepticism was right and your reguest for "features for money" actually has the aim to push something through, that otherwise would be rejected.
I used that feature as an example.  Yes, it is one that I am interested in.  Anyone is more than welcome to provide their own example of features they would be willing to support, since I don't know what those are, I can't use them as examples.

If telling yourself you were "right" makes you feel good, by all means, be my guest.


using FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 64bit.

Akira1364

  • Hero Member
  • *****
  • Posts: 539
Re: Features for money ?
« Reply #48 on: July 01, 2019, 01:08:45 am »
I've posted about it before, but this library / program: https://github.com/neslib/Chet

gives pretty much 100% correct translations of basically any header you throw at it (for which it has its use of libClang to thank, specifically).

The only caveats are that it's designed specifically for Delphi, and also that it does tend to leave in a number of "unrelated" definitions for things (which you'll of course generally want to remove from the "final version" of a given translation.)

I'm currently working on a proper FPC port of it though, as even as-is it's way, way, way better than H2Pas. (No offense meant by that, but really, I don't think anyone has ever claimed H2Pas was "good". It relies on a (port) of a (really outdated) version of, uh, Yacc after all...)

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.

Again, I'm not a fan of the general tone of the post you were responding to there, but the "generic TStringList was slower because of generics" thing is absurd.

It was slower almost entirely because the specific implementation of maps in FGL (one of which the generic TStringList used internally) is awful. (I.E. they are in no way, whatsoever, actual hashmaps, amongst various other flaws.)

Were it based around stuff from the current revision of Generics.Collections, it would almost certainly be quite a bit faster.

In general: FPC monomorphizes generics in all cases, thus, they cannot be slower, because they are literally the same thing as a directly equivalent non-generic implementation.
« Last Edit: July 01, 2019, 04:35:19 am by Akira1364 »

440bx

  • Hero Member
  • *****
  • Posts: 1359
Re: Features for money ?
« Reply #49 on: July 01, 2019, 02:39:25 am »
I'm currently working on a proper FPC port of it though,
I'm really looking forward to your port of it.

Do you have some rough idea as to when you might be done with it ?
using FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 64bit.

Akira1364

  • Hero Member
  • *****
  • Posts: 539
Re: Features for money ?
« Reply #50 on: July 01, 2019, 03:30:08 am »
Do you have some rough idea as to when you might be done with it ?

Soonish. Currently the blocker is just that the GUI "frontend" app for it went ahead and used Delphi 10's "TCardPanel", which Lazarus does not implement, making the app rather annoying to translate without destroying the LFM file.

I've gotten a skeleton of it going with the "TDI" Lazarus package, and am currently just carefully trying to make sure I don't break any of the original UI behavior.

440bx

  • Hero Member
  • *****
  • Posts: 1359
Re: Features for money ?
« Reply #51 on: July 01, 2019, 03:54:21 am »
Soonish.
Very nice!.

Currently the blocker is just that the GUI "frontend" app for it went ahead and used Delphi 10's "TCardPanel", which Lazarus does not implement, making the app rather annoying to translate without destroying the LFM file.
There is always something... <chuckle>

I've gotten a skeleton of it going with the "TDI" Lazarus package, and am currently just carefully trying to make sure I don't break any of the original UI behavior.
Nice.

Thank you for the update on your progress.
using FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 64bit.

PascalDragon

  • Hero Member
  • *****
  • Posts: 895
  • Compiler Developer
Re: Features for money ?
« Reply #52 on: July 01, 2019, 09:34:47 am »
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.

Again, I'm not a fan of the general tone of the post you were responding to there, but the "generic TStringList was slower because of generics" thing is absurd.

It was slower almost entirely because the specific implementation of maps in FGL (one of which the generic TStringList used internally) is awful. (I.E. they are in no way, whatsoever, actual hashmaps, amongst various other flaws.)
To be fair: I have never looked at the generic TStringList, thus I hadn't present that it's based on TFPGMap<>. The time when that was implemented and tested was before my time and I was only presented with the results when I asked about the generic TStringList, namely that it's slower than the non-generic one. I had enough items on my ToDo list (and still do), so I simply turned my attention to another points. *shrugs*

In general: FPC monomorphizes generics in all cases, thus, they cannot be slower, because they are literally the same thing as a directly equivalent non-generic implementation.
Now it's you who's generalizing. As always it depends on the implementation. Take a look at TFPGList<>: It's implemented as a descendant of TFPSList and the generic's type handling is done through virtual functions. Compare that to a generic list that implements all in a single class (even if both simply use a dynamic array as implementation). Here the TFPGList<> is slower than this hypothetical generic list due to the virtual call (it might be only a small difference in performance, but it will be there).

But the performance discussion aside, I also stated that I use generics simply due to the type safety they provide. That is IMHO the main reason to use them. I know that there are core developers that don't like generics, but I'm definitely not one of them (after all I developed much of the new functionality since 2.6.4  :-[ ).

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 7853
Re: Features for money ?
« Reply #53 on: July 01, 2019, 09:40:14 am »
Do you have some rough idea as to when you might be done with it ?

Soonish. Currently the blocker is just that the GUI "frontend" app for it went ahead and used Delphi 10's "TCardPanel", which Lazarus does not implement, making the app rather annoying to translate without destroying the LFM file.

I've gotten a skeleton of it going with the "TDI" Lazarus package, and am currently just carefully trying to make sure I don't break any of the original UI behavior.

Did you running windows headers through it? Can it handle calling convention macros?