Recent

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

lucamar

  • Hero Member
  • *****
  • Posts: 3074
Re: Features for money ?
« Reply #15 on: June 29, 2019, 03:33:19 pm »
English is, in the main, an "usage based" tongue (witness the debacle of "virtually" now meaning also "literally; in the real world" ;)) but just for fun:
Turbo Pascal 3 CP/M - Amstrad PCW 8256 (512 KB !!!) :P
Lazarus 2.0.8/FPC 3.0.4 - 32/64 bits on:
(K|L|X)Ubuntu 12..18, Windows XP, 7, 10 and various DOSes.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 6675
  • Debugger - SynEdit - and more
    • wiki
Re: Features for money ?
« Reply #16 on: June 29, 2019, 04:49:01 pm »
witness the debacle of "virtually" now meaning also "literally; in the real world" ;)
Yeah, but a new word for the original "literally" was needed, since "literally" nowadays is often/sometimes used to mean "figurative" ;)

lucamar

  • Hero Member
  • *****
  • Posts: 3074
Re: Features for money ?
« Reply #17 on: June 29, 2019, 05:02:46 pm »
Yeah, English is (or rather English-speakers are) funny like that :D
Turbo Pascal 3 CP/M - Amstrad PCW 8256 (512 KB !!!) :P
Lazarus 2.0.8/FPC 3.0.4 - 32/64 bits on:
(K|L|X)Ubuntu 12..18, Windows XP, 7, 10 and various DOSes.

avra

  • Hero Member
  • *****
  • Posts: 2009
    • Additional info
Re: Features for money ?
« Reply #18 on: June 29, 2019, 05:06:55 pm »
referring to the "variant" thread, it was essentially ignored by the developers which led me to forget that idea.
People have an expectation that FPC core developers follow much of this forum. That is mostly not the case. If you want their attention you should better join fpc-devel mail list:
https://freepascal.org/maillist.html
ct2laz - Conversion between Lazarus and CodeTyphon
bithelpers - Bit manipulation for standard types
pasettimino - Siemens S7 PLC lib

440bx

  • Hero Member
  • *****
  • Posts: 2007
Re: Features for money ?
« Reply #19 on: June 29, 2019, 05:45:16 pm »
People have an expectation that FPC core developers follow much of this forum. That is mostly not the case. If you want their attention you should better join fpc-devel mail list:
https://freepascal.org/maillist.html
I admit to have a mild level of expectation for the FPC developers to, at least occasionally, check out what's happening here in the forums.

I concur that for an extensive discussion of implementing a new feature in the compiler, the mailing list is probably a better avenue than the forums but, to get an initial "feel" of whether or not a particular feature would be considered, the forums seem to be a reasonable avenue.  Plus, it gives other forum members the opportunity to express their opinions too (which can be, both, a pro and a con.)




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

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 6675
  • Debugger - SynEdit - and more
    • wiki
Re: Features for money ?
« Reply #20 on: June 29, 2019, 05:56:45 pm »
The forum is (by many of the team members) seen as a place for User-to-User discussions.
Some team members are regulars on the forum, others will only attend if they are notified via the mailing lists.

Also I guess, in the specific case of a "what about this feature", there are 2 kind of discussions to be had:
1) What do users want. Kind of get an idea what people want out of that feature.
2) Can the feature be accepted. Or to which extend can it be accepted.

The 2nd kind of discussion, can generate very huge discussions (even if the developers would totally welcome it, other users may bring in arguments why it should be limited).

So it is well possible, that people hold back, in order to avoid starting the 2nd kind of discussion prematurely. (But I do not know if that is/was the case (here, or for any other such topic))

Thaddy

  • Hero Member
  • *****
  • Posts: 10516
Re: Features for money ?
« Reply #21 on: June 29, 2019, 06:13:09 pm »
I think it is always correct to respond to misunderstandings. That may look off-topic but often is not.
Precise wording is important.

k1ng

  • New Member
  • *
  • Posts: 37
Re: Features for money ?
« Reply #22 on: June 29, 2019, 07:00:46 pm »
I don't think this would help very much, unfortunately. It's become clear to me while observing the bugtracker recently that even if someone can actually implement a new working feature by themselves, if the "core" developers decide that they don't like it for whatever reason, it will just sit there in limbo forever without being merged.

Absolutely right and that's very sad!
Sometime even nobody of the team responded to a patch which easily leads to the impression that help is not wanted.  :-\

Would also help to have a list with rejected features/patches and a reason WHY it was rejected.

IMHO the recent problems with rejections is because aspiring developers try to do too much to soon, without getting a feel for the project.

Start small. Ask questions a lot. Learn proper procedures. And, most importantly, don't reformat code unnecessarily, keep patches to the point and as small as possible. It doesn't matter if it is in a git branch or a submitted patch.

Having some kind of rejected patches/features would help new people to get a better feeling about FPC. Might also reduce duplicate question for feature X...


And, most importantly, don't reformat code unnecessarily, keep patches to the point and as small as possible. It doesn't matter if it is in a git branch or a submitted patch.

Many delays come due to unclean patches.
Unclean patches could be cleaned by devs if the feature is working, takes less time than asking to submit a new patch which might not fit your rules also...as there are no contribution rules, or?

k1ng

  • New Member
  • *
  • Posts: 37
Re: Features for money ?
« Reply #23 on: June 29, 2019, 07:04:55 pm »
Just one example is
I don't think this would help very much, unfortunately. It's become clear to me while observing the bugtracker recently that even if someone can actually implement a new working feature by themselves, if the "core" developers decide that they don't like it for whatever reason, it will just sit there in limbo forever without being merged.

Absolutely right and that's very sad!
Sometime even nobody of the team responded to a patch which easily leads to the impression that help is not wanted.  :-\

One example for this:
Attributes support

kupferstecher

  • Sr. Member
  • ****
  • Posts: 406
Re: Features for money ?
« Reply #24 on: June 29, 2019, 07:19:50 pm »
The imagnation that one can force the implementation of non-pascalish features into FPC just with money is really frightening me.

Imho, the compiler is already mature, new features should be considered very restrictively.
On the other hand, addressing new targets (both FPC and Lazarus), making components etc. don't threaten Freepascal, so I would support that.
FPC compiler featured should be spared out and that should be stated very clearly.

440bx

  • Hero Member
  • *****
  • Posts: 2007
Re: Features for money ?
« Reply #25 on: June 29, 2019, 07:24:13 pm »
Would also help to have a list with rejected features/patches and a reason WHY it was rejected.
That should be part of the current process.   It would provide a much better idea to FPC users what direction the compiler is going.


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

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8781
  • FPC developer.
Re: Features for money ?
« Reply #26 on: June 29, 2019, 07:29:11 pm »
Note: speaking more for FPC than for lazarus.


Absolutely right and that's very sad!
Sometime even nobody of the team responded to a patch which easily leads to the impression that help is not wanted.  :-\

That's the problem with language design. It is quite a minefield.  But a lot of it is self-inflicted. They have been warned. Nevertheless, when it happens it is a tragedy. For both sides.

Quote
Would also help to have a list with rejected features/patches and a reason WHY it was rejected.

If people wade in to disputed areas (usually: copying syntax from other languages or totally ad-hoc syntax enhancements) after being warned, I don't really think that some list somewhere in the wiki will detract them.

Quite often it is not rejected per se, but the amount of work is simply to daunting for a committer. Specially if he can't do it during normal hours, but really has to set aside holidays to review something that is big or with big consequences.

Quote
IMHO the recent problems with rejections is because aspiring developers try to do too much to soon, without getting a feel for the project.

Start small. Ask questions a lot. Learn proper procedures. And, most importantly, don't reformat code unnecessarily, keep patches to the point and as small as possible. It doesn't matter if it is in a git branch or a submitted patch.

Having some kind of rejected patches/features would help new people to get a better feeling about FPC. Might also reduce duplicate question for feature X...

If you feel that way, start a wiki page.

But I think it is more a sign of the times. For some reason all new contributors want to play with expanding language, the bigger the better.  10 years ago, new contributors were more about new targets, and often were already deeper into that field than core contributors.

That had several important consequences
1) what they didn't, mostly affected the new target, not everything, and the consequences for support etc would be
2) they usually knew what they were doing (wrt that target) better than core anyway.
3) they usually had already quite a string of patches and rearrangements, often for related targets.

It is much easier to let such contributor get commit bits than the current batch that seems to be overly focussed on language (with the dialect backwards compatibility as a Sword of Damocles haging over it).

Just look what happened to similar contributions a few years ago. Where are the case <string> of committers?

Quote
And, most importantly, don't reformat code unnecessarily, keep patches to the point and as small as possible. It doesn't matter if it is in a git branch or a submitted patch.

Many delays come due to unclean patches.
Unclean patches could be cleaned by devs if the feature is working, takes less time than asking to submit a new patch which might not fit your rules also...as there are no contribution rules, or?

Most of  these people have submitted more trivial stuff before, so they now about cleanliness rules.

Keeping changesets minimal as possible is a fairly universal rules in open source (or even: multi person projects).

Anyway, while I don't think a rejected patch list will do much good, I do think that the current policy of officially welcoming any patches is bankrupt. It worked in the past when the new developers either had or acquired the same mindset as the old bunch in time, but it doesn't seem to work like that any more.

440bx

  • Hero Member
  • *****
  • Posts: 2007
Re: Features for money ?
« Reply #27 on: June 29, 2019, 07:49:27 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.

Imho, the compiler is already mature, new features should be considered very restrictively.
Mature doesn't imply it has all the features that would make programming cleaner and easier. It doesn't.

On the other hand, addressing new targets (both FPC and Lazarus), making components etc.
"jack of all trades, master of none."...

... don't threaten Freepascal, ...
I don't see how removing the current limitation on variants being last in a record definition would "threaten Freepascal".



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

PascalDragon

  • Hero Member
  • *****
  • Posts: 2248
  • Compiler Developer
Re: Features for money ?
« Reply #28 on: June 29, 2019, 10:23:05 pm »
And, most importantly, don't reformat code unnecessarily, keep patches to the point and as small as possible. It doesn't matter if it is in a git branch or a submitted patch.

Many delays come due to unclean patches.
Unclean patches could be cleaned by devs if the feature is working, takes less time than asking to submit a new patch which might not fit your rules also...as there are no contribution rules, or?
And then they present an unclean patch for the next issue again. And again. And again. No. If they want to contribute they need to learn how to make it easier for us as well. After all we developers need to look at the bug reports from other users as well. We're willing to point out what they did wrong, but if they're not willing to learn why should I waste my time with them?
Note: I'm not talking about small patches with just a handful of lines; there it is indeed not worth the effort to request a cleaned up patch. Big feature patches... Oh boy. If they include hundreds of unrelated changes, because the IDE decided to be too clever (yes, that happens with FPC's code in Lazarus fairly often) that makes the real changes hard to spot.
But I think it is more a sign of the times. For some reason all new contributors want to play with expanding language, the bigger the better.  10 years ago, new contributors were more about new targets, and often were already deeper into that field than core contributors.

That had several important consequences
1) what they didn't, mostly affected the new target, not everything, and the consequences for support etc would be
2) they usually knew what they were doing (wrt that target) better than core anyway.
3) they usually had already quite a string of patches and rearrangements, often for related targets.

It is much easier to let such contributor get commit bits than the current batch that seems to be overly focussed on language (with the dialect backwards compatibility as a Sword of Damocles haging over it).
That's how I had started as well. With a new target. :)

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8781
  • FPC developer.
Re: Features for money ?
« Reply #29 on: June 29, 2019, 10:56:25 pm »
And more importantly, for sizeable patches created over a larger time it is painful to do it afterwards. The whole point is to encourage the policy in the work, not just afterwards.

 

TinyPortal © 2005-2018