Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2019-02

Multi helpers

16 messages · 4 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Ryan Joseph

Update on multi-scope helpers. I’ve added tests (tmshlp*.pp), fixed a bug and renamed the mode switch to “multihelpers” which I think is more concise than “multiscopehelpers” and fits the format with “typehelpers”. Any better ideas are welcome of course.

I’ve made all the tests I could think of (included now) but I wonder if I messed up any subtle order of precedence. If anyone wants to test or has any ideas for more tests to include please let me know.

https://github.com/genericptr/freepascal/tree/helperscope

Regards,
Ryan Joseph

Ryan Joseph
to Ryan Joseph

Question, is this mode switch allowed in Delphi mode? I disabled it because I had a comment that said it was ObjFPC mode only but that doesn’t make sense it couldn’t be enabled manually even in Delphi mode.

Regards,
Ryan Joseph

Mattias Gaertner
to Ryan Joseph: Update on multi-scope helpers. I’ve added tests (tmshlp*.pp), fixed a bug and renamed…
Update on multi-scope helpers. I’ve added tests (tmshlp*.pp), fixed a bug and renamed the mode switch to “multihelpers” which I think is more concise than “multiscopehelpers” and fits the format with “typehelpers”.

Thanks!

Good that the final pas2js 1.4 release is not yet out there, so I can rename the modeswitch.

Any better ideas are welcome of course. I’ve made all the tests I could think of (included now) but I wonder if I messed up any subtle order of precedence.

At least FPC helpers are more consistent than Delphi. inherited crap

Mattias

Ryan Joseph
to Mattias Gaertner
On Feb 25, 2019, at 12:41 PM, Mattias Gaertner via fpc-pascal wrote: At least FPC helpers are more consistent than Delphi. inherited crap

I’m pretty confident I didn’t add anything extra in terms of logic. All my changes did are instead of checking the last helper declared, it now checks from the last helper to the first.

Regards,
Ryan Joseph

Mattias Gaertner
to Ryan Joseph
Show quoted text 9 lines
> On Feb 25, 2019, at 12:41 PM, Mattias Gaertner via fpc-pascal > wrote: > > At least FPC helpers are more consistent than Delphi. > inherited crap I’m pretty confident I didn’t add anything extra in terms of logic. All my changes did are instead of checking the last helper declared, it now checks from the last helper to the first.

In pas2js it is a very small change as well - a single "if".

Whoever implemented helpers in Delphi must have noticed the inconsistencies and still continued. I wonder why. I'm glad FPC did not blindly follow Delphi. e.g. inherited; vs inherited name;

Mattias

Ryan Joseph
to Mattias Gaertner
On Feb 25, 2019, at 1:12 PM, Mattias Gaertner via fpc-pascal wrote: Since $modeswitch typehelpers is allowed in mode delphi, it would be inconsistent to forbid it.

Good point, I didn’t know that. I’ve correct this on GitHub.

Regards,
Ryan Joseph

Sven Barth
to Ryan Joseph: Question, is this mode switch allowed in Delphi mode? I disabled it because I had a…

Ryan Joseph schrieb am Mo., 25. Feb. 2019,
19:00:

Question, is this mode switch allowed in Delphi mode? I disabled it because I had a comment that said it was ObjFPC mode only but that doesn’t make sense it couldn’t be enabled manually even in Delphi mode.

Mattias already answered, but nevertheless: we don't forbid modeswitches in other modes. After all if one wants to enable a feature (or disable one that's enabled by default) then the user should be free to do so.

Regards,
Sven

Sven Barth
to Mattias Gaertner: On Mon, 25 Feb 2019 12:49:16 -0500 In pas2js it is a very small change as well - a single…

Mattias Gaertner via fpc-pascal schrieb
am Mo., 25. Feb. 2019, 19:09:

Show quoted text 19 lines
On Mon, 25 Feb 2019 12:49:16 -0500 Ryan Joseph wrote: > > On Feb 25, 2019, at 12:41 PM, Mattias Gaertner via fpc-pascal > > wrote: > > > > At least FPC helpers are more consistent than Delphi. > > inherited crap > > I’m pretty confident I didn’t add anything extra in terms of logic. > All my changes did are instead of checking the last helper declared, > it now checks from the last helper to the first. In pas2js it is a very small change as well - a single "if". Whoever implemented helpers in Delphi must have noticed the inconsistencies and still continued. I wonder why. I'm glad FPC did not blindly follow Delphi. e.g. inherited; vs inherited name;

Do you have examples for these differences? Not that I want to change them, but I'm curious...

Regards,
Sven

Ryan Joseph
to Sven Barth

Slightly unrelated question but one that will come up again soon. When I submitted my last patch I was told it would be best to put the tests in a different patch (so I submitted two). Does anyone know how to do that? This is the command I used:

git format-patch master --stdout > patch.diff

which works well but there doesn’t seem to be a way to choose the directory it starts from.

Regards,
Ryan Joseph

Sven Barth
to Sven Barth: Mattias Gaertner via fpc-pascal schrieb am Mo., 25. Feb. 2019, 19:09: Do you have…
Sven Barth wrote 29 lines
Mattias Gaertner via fpc-pascal < > schrieb am Mo., 25. Feb. 2019, 19:09: On Mon, 25 Feb 2019 12:49:16 -0500 Ryan Joseph < > wrote: > > On Feb 25, 2019, at 12:41 PM, Mattias Gaertner via fpc-pascal > > < > wrote: > > > > At least FPC helpers are more consistent than Delphi. > > inherited crap > > I’m pretty confident I didn’t add anything extra in terms of logic. > All my changes did are instead of checking the last helper declared, > it now checks from the last helper to the first. In pas2js it is a very small change as well - a single "if". Whoever implemented helpers in Delphi must have noticed the inconsistencies and still continued. I wonder why. I'm glad FPC did not blindly follow Delphi. e.g. inherited; vs inherited name; Do you have examples for these differences? Not that I want to change them, but I'm curious...

Nevermind. I found what you meant in the Wiki. :)

Regards,
Sven

Graeme Geldenhuys
to Ryan Joseph: Slightly unrelated question but one that will come up again soon. When I submitted my…
Ryan Joseph wrote
git format-patch master --stdout > patch.diff

Yuck!

Rather do as always recommended... develop in a "feature" branch. Branches are brilliant in Git and most Git commands work better when branches are used. Also split your changes into multiple smaller commits. ie: your tests into one commit and your other changes into another commit. Use commits - they don't cost anything, so no need to go sparingly on them. ;-)

Lastly, use the format-patch command but with branches instead.

git format-patch -o output_directory --cover-letter <feature_branch>...<master_branch>

In will generate sequentially numbered set of .patch files in the <output_directory> and a 0000-cover-letter.patch file. ie: a summary of what you changed, which is useful for pasting into an email or mantis report.

NOTE:
1. Note the 3 dots between branch names
2. <feature_branch> is the branch in which you did your work.
3. <master_branch> is the branch you create your feature branch from.

Hope this helps.

Regards,
Graeme

fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp
Ryan Joseph

posts getting blocked again, just sending this to see if it gets through.

Show quoted text 40 lines
On Feb 26, 2019, at 9:10 AM, Ryan Joseph wrote: > On Feb 26, 2019, at 7:05 AM, Graeme Geldenhuys wrote: > > Rather do as always recommended... develop in a "feature" branch. > Branches are brilliant in Git and most Git commands work better when > branches are used. Also split your changes into multiple smaller > commits. ie: your tests into one commit and your other changes into > another commit. Use commits - they don't cost anything, so no need to go > sparingly on them. ;-) I was actually in a feature branch already. I don’t know how it works but only changes made in the active branch (my feature branch) were added to the patch. What do you mean split changes into smaller commits? I’ve been working on this over months so there were dozens of commits. The final patch that was made had a history of all the commits but they were just packed into one file (which I thought was easier to distribute than a directory full of them). Still not sure how to keep the tests separate though. I added them in over time in a number of commits so it seems not possible to extract them now. > > Lastly, use the format-patch command but with branches instead. > > git format-patch -o output_directory --cover-letter > <feature_branch>...<master_branch> > > In will generate sequentially numbered set of .patch files in the > <output_directory> and a 0000-cover-letter.patch file. ie: a summary of > what you changed, which is useful for pasting into an email or mantis > report. Does this mean a .patch for each commit? Why is that better than merging into one patch? > > NOTE: > 1. Note the 3 dots between branch names > 2. <feature_branch> is the branch in which you did your work. > 3. <master_branch> is the branch you create your feature branch from. > > > Hope this helps.

Regards,
Ryan Joseph

Sven Barth
to Ryan Joseph

Ryan Joseph schrieb am Do., 28. Feb. 2019,
03:50:

Show quoted text 27 lines
posts getting blocked again, just sending this to see if it gets through. > On Feb 26, 2019, at 9:10 AM, Ryan Joseph wrote: > > > >> On Feb 26, 2019, at 7:05 AM, Graeme Geldenhuys < > wrote: >> >> Rather do as always recommended... develop in a "feature" branch. >> Branches are brilliant in Git and most Git commands work better when >> branches are used. Also split your changes into multiple smaller >> commits. ie: your tests into one commit and your other changes into >> another commit. Use commits - they don't cost anything, so no need to go >> sparingly on them. ;-) > > I was actually in a feature branch already. I don’t know how it works but only changes made in the active branch (my feature branch) were added to the patch. > > What do you mean split changes into smaller commits? I’ve been working on this over months so there were dozens of commits. The final patch that was made had a history of all the commits but they were just packed into one file (which I thought was easier to distribute than a directory full of them).

See below.

Show quoted text 20 lines
> Still not sure how to keep the tests separate though. I added them in over time in a number of commits so it seems not possible to extract them now. > >> >> Lastly, use the format-patch command but with branches instead. >> >> git format-patch -o output_directory --cover-letter >> <feature_branch>...<master_branch> >> >> In will generate sequentially numbered set of .patch files in the >> <output_directory> and a 0000-cover-letter.patch file. ie: a summary of >> what you changed, which is useful for pasting into an email or mantis >> report. > > Does this mean a .patch for each commit? Why is that better than merging into one patch? >

Yes, though the first step should probably be to rework your commits. It's a bit of work, but that way you can nicely restructure your commit history,get rid of unintended changes(1) and maybe group the changes by functional topic or so...

(1) I don't remember whether it was this branch or another, but one had unintended and unrelated changes in indentation that you should get rid of.

Regards,
Sven

Ryan Joseph
to Sven Barth
Show quoted text 6 lines
On Feb 28, 2019, at 1:51 AM, Sven Barth via fpc-pascal wrote: Yes, though the first step should probably be to rework your commits. It's a bit of work, but that way you can nicely restructure your commit history,get rid of unintended changes(1) and maybe group the changes by functional topic or so... (1) I don't remember whether it was this branch or another, but one had unintended and unrelated changes in indentation that you should get rid of.

What do you mean rework the commits? I tried using "git rebase -i” but I have no idea what the terminal wants me to do. I can’t even cancel or anything, just for the intention, again I couldn’t figure out what git was seeing. Maybe if I squish the commits into one they’ll go away.

Regards,
Ryan Joseph

Sven Barth
to Ryan Joseph

Ryan Joseph schrieb am Do., 28. Feb. 2019,
15:37:

Show quoted text 18 lines
> On Feb 28, 2019, at 1:51 AM, Sven Barth via fpc-pascal < > wrote: > > Yes, though the first step should probably be to rework your commits. It's a bit of work, but that way you can nicely restructure your commit history,get rid of unintended changes(1) and maybe group the changes by functional topic or so... > > (1) I don't remember whether it was this branch or another, but one had unintended and unrelated changes in indentation that you should get rid of. > What do you mean rework the commits? I tried using "git rebase -i” but I have no idea what the terminal wants me to do. I can’t even cancel or anything, just beeping at me.

It should show an editor (vi, Nano, etc) showing the commits of your branch. If it doesn't your git isn't configured correctly.

As for the intention, again I couldn’t figure out what git was seeing.

Maybe if I squish the commits into one they’ll go away.

You should be able to see them using "git diff" when you rework the commits. You could simply stage the required changes and then simply drop the rest.

Alternatively you could add your changes simply to a new branch in the correct order and without unrelated changes...

Regards,
Sven