Recent

Author Topic: All aspects of Lazarus are generally incapable of parsing Generics...  (Read 4860 times)

Akira1364

  • Hero Member
  • *****
  • Posts: 561
Is this a "known" issue that someone is actively working on, or should I just starting tearing into the CodeTools (and Jedi Code Format) sources myself? It applies to both "mode Delphi" and "mode ObjFPC". (Although it's worse with CodeTools code completion, which seems to view both modes as equally invalid. Jedi Code Format can at least format Delphi-mode generics, but views the "specialize" keyword as invalid in mode ObjFPC.) If anyone who reads this has been following my work on DeleD: this is 95% of the reason I haven't uploaded anything yet. Ever since I moved the applications list classes over to use Generics exclusively, I've basically been locked in a constant battle with the IDE that makes everything take many times longer than I originally expected it to.

derek.john.evans

  • Guest
Re: All aspects of Lazarus are generally incapable of parsing Generics...
« Reply #1 on: December 04, 2016, 02:42:24 am »
So, 95% of the reason you cant release code is... because you cant auto format it, and code insight doesn't work with your changes.

This given the original DeleD code compiled with Delphi 7 which didn't have source formatting or better code insight than Lazarus.

There is a difference between porting and hacking to pieces.

IMHO, you should have:

1) Focused on the Lazarus port first with minimal changes (which adhere to Delphi 7 standards) and are portable to Linux/Mac.
2) Uploaded the code, and allowed users to bug check for 6 months. If the job was done right, it would have gained new Mac/Linux users.

Then, fork the code and apply your fancy template code changes.

Thats just my view, and it may be the view of others

Akira1364

  • Hero Member
  • *****
  • Posts: 561
Re: All aspects of Lazarus are generally incapable of parsing Generics...
« Reply #2 on: December 04, 2016, 05:08:00 am »
So, 95% of the reason you cant release code is... because you cant auto format it, and code insight doesn't work with your changes.

This given the original DeleD code compiled with Delphi 7 which didn't have source formatting or better code insight than Lazarus.

There is a difference between porting and hacking to pieces.

IMHO, you should have:

1) Focused on the Lazarus port first with minimal changes (which adhere to Delphi 7 standards) and are portable to Linux/Mac.
2) Uploaded the code, and allowed users to bug check for 6 months. If the job was done right, it would have gained new Mac/Linux users.

Then, fork the code and apply your fancy template code changes.

Thats just my view, and it may be the view of others

*Yawn*.

I'm going to be honest: I don't know who you are, or why you're so specifically worked up over this post, right now. As far as I can recall you are not even someone who has ever replied to my DeleD thread, to date? I was expecting that I might get a reply like yours, but I figured it would be from someone like, say, JuhaManninen (and I would have been perfectly ok with that, as I honestly find his posts rather entertaining most of the time!)

Yes, the original code compiled with Delphi 7. However, that is less than irrelevant in this context, and it's mind-boggling that you mention that in the same sentence as your comment about cross-platform compatibility. The original codebase was (and still is in some places, I've yet to find workarounds for everything) chock-full of good-old-fashioned late 90s/early 2000s Windows-centric Delphi tropes: as in, the sort of things that you would totally expect to find in an application written between 2004 and 2011, in Delphi 5 to 7. The sort of things, more specifically, that would make it literally impossible to ever get the application running on a non-Windows-platform.  The approach you're suggesting I should have taken to the codebase is literally the opposite of what has allowed me to make real progress in the work I've done so far.

Imagine if you will that I had uploaded my changes to Github within the first week or so I started working on the codebase, and made the same post on these forums as I did in reality: I absolutely guarantee you that we'd still be sitting around endlessly debating things like whether we should rewrite the parts of the application that used Graphics32 to use BGRABitmap. Or, to give another example, whether we should rewrite the parts of the application that used the original developers "home-grown" image loading/manipulation code to use BGRABitmap. Both of these are things that I just went ahead and did after considering the pros/cons for about an hour, and as I suspected they both ended up being the right decision. It's the difference between DeleD actually being able to properly support PNG textures (which it does now) and not doing so, which it didn't before. However, it could have, very easily, at any point in the last 12 years had the original developers simply not been so stubborn, accepted the fact that their PNG loading routines didn't work, and just used any of the number of libraries that could have done it for them. (I mean, despite the problems with Graphics32 that lead me to replace its use, they were already using it and it could have have least done THAT for them... so why keep hammering away at their own stuff? Makes zero sense.)

Furthermore: Nothing I've done should even be thought of as "porting" to begin with, and I certainly don't think I've been "hacking it to pieces". The application as JuhaManninen left it already technically compiled in Lazarus: it just didn't really work. What I've done has all been related to simply making it run as intended at first, and later improving it/adding features/etcetera.

The bottom line is: it was and still is an application in desperate need of far more than "minimal changes", and an application in desperate need of an overall development attitude that does not involve thinking Delphi 7 matters at all in 2016 (it doesn't.) Delphi 7 was never anything more than "pretty good" for what it was at the time it was released. It was certainly never "great" as so many people seem to believe, and it's definitely not something that should be aspired to as any kind of standard in this day and age.

Now, does anyone have any relevant information about the ability of Lazarus to parse Generics? Because even if I'm the worst programmer in the world, and indeed literally a demon sent from Programmer Hell to stir up controvery..... the fact remains that Lazarus has some serious problems parsing Generics.
« Last Edit: December 25, 2016, 02:05:19 am by Akira1364 »

Ondrej Pokorny

  • Full Member
  • ***
  • Posts: 220
Re: All aspects of Lazarus are generally incapable of parsing Generics...
« Reply #3 on: December 04, 2016, 09:04:19 pm »
It's a known issue that nobody is working on now, unfortunately. Any help is appreciated.

Xor-el

  • Sr. Member
  • ****
  • Posts: 404
Re: All aspects of Lazarus are generally incapable of parsing Generics...
« Reply #4 on: December 04, 2016, 09:27:39 pm »
unfortunately, Lazarus codetools "hates" Generics.
Here is what I simply do if I encounter such situation
1. modify the application to not use generics

or

2. if you have a legal copy of Delphi, write your code in Delphi and at intervals, check if it still compiles in FPC.
of course, this would require you to use the (mode Delphi) switch.

lainz

  • Hero Member
  • *****
  • Posts: 4460
    • https://lainz.github.io/
Re: All aspects of Lazarus are generally incapable of parsing Generics...
« Reply #5 on: December 04, 2016, 09:48:39 pm »
Xor-el, he is talking about an application that only runs on lazarus, for example it uses bgrabitmap that only is available on lazarus. So using Delphi is not possible.

Xor-el

  • Sr. Member
  • ****
  • Posts: 404
Re: All aspects of Lazarus are generally incapable of parsing Generics...
« Reply #6 on: December 04, 2016, 10:10:49 pm »
Xor-el, he is talking about an application that only runs on lazarus, for example it uses bgrabitmap that only is available on lazarus. So using Delphi is not possible.

Ok I See.
thanks for the info.

derek.john.evans

  • Guest
Re: All aspects of Lazarus are generally incapable of parsing Generics...
« Reply #7 on: December 05, 2016, 04:58:53 am »
*Yawn*.
I'm going to be honest: I don't know who you are, or why you're so specifically worked up over this post, right now.
...
Now, does anyone have any relevant information about the ability of Lazarus to parse Generics? Because even if I'm the worst programmer in the world, and indeed literally a demon sent from Programmer Hell to stir up controvery..... the fact remains that Lazarus has some serious problems parsing Generics.

I'm actually as calm as a cucumber, but anyway, my view stands. At the end of the day, if you dont get the job done, someone else will.

As far as "serious problems". Im running Lazarus 1.6.2 and the parsing/formatting is a lot better, so someone is doing some work.

A more productive approach might be to post some FPC 3.0 generic code which you have viewed as a "serious problem". I know there were problems with 3.1+ code, but are you saying you want Lazarus to handle generic syntax which is yet to be officially released?

Yes, I have found workarounds for parsing and formatting which I (and most likely others) would like to talk about.

Your post title is "All aspects of Lazarus are generally incapable of parsing Generics" which is totally false. As far as I can tell, any issues are being worked on.

So who am I?  Im just a coder who sees your posts filled with criticisms of other peoples efforts, while saying stuff like "or should I just starting tearing into the CodeTools (and Jedi Code Format) sources myself?"

Yep, go for it. Tear/rip/hack/complain/whinge all you want, and then convince yourself that 95% of the reason you haven't released anything is because of other people.


Akira1364

  • Hero Member
  • *****
  • Posts: 561
Re: All aspects of Lazarus are generally incapable of parsing Generics...
« Reply #8 on: December 07, 2016, 05:53:49 am »
I'm actually as calm as a cucumber, but anyway, my view stands. At the end of the day, if you dont get the job done, someone else will.

That seems highly unlikely. If anyone else was interested enough in the project or willing to spend the time, I think they would have started a long time ago considering that JuhaManninen's branch has been available for download since 2013. Also, I would hardly call it a "job"...

As far as "serious problems". Im running Lazarus 1.6.2 and the parsing/formatting is a lot better, so someone is doing some work.

Isn't Ondrej (who stated above that no one is working on it) some kind of significant member of the Lazarus dev team? Wouldn't he know best?

So who am I?  Im just a coder who sees your posts filled with criticisms of other peoples efforts, while saying stuff like "or should I just starting tearing into the CodeTools (and Jedi Code Format) sources myself?"

Yep, go for it. Tear/rip/hack/complain/whinge all you want, and then convince yourself that 95% of the reason you haven't released anything is because of other people.

I'm pretty sure I've never implied that any specific person was bad at what they did. Saying a team or group of developers made a collective decision that wasn't necessarily a good one doesn't reflect on them individually (as there's a good chance none of them would have made that decision on their own.)  I'm also not "blaming" anyone for anything, but simply stating the nature of a problem I've consistently encountered as clearly/concisely as I can. I'll be the first to admit that I've probably gotten far too used to the "comforts" of IDEs over the years. Someone who was more used to a traditional text editor/command line sort of environment would probably be slowed down much less, but I have not worked like that for a very long time.
« Last Edit: December 07, 2016, 05:58:26 am by Akira1364 »

derek.john.evans

  • Guest
Re: All aspects of Lazarus are generally incapable of parsing Generics...
« Reply #9 on: December 07, 2016, 06:38:01 am »
Well, lets jump to the actual post title/question.

A snippet of 3.0 generic code which is not working, would be a great start.

 

TinyPortal © 2005-2018