Re: [fpc-devel] Submitting patches using git
Am 20.07.2019 um 23:18 schrieb Martin Frb: On 20/07/2019 23:13, Sven Barth via fpc-devel wrote: For example I myself don't commit my .gitignore, but simply have it lying around as untracked file. Try .git/info/exclude https://git-scm.com/docs/gitignore Nice! :D Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Submitting patches using git
On 20/07/2019 23:13, Sven Barth via fpc-devel wrote: For example I myself don't commit my .gitignore, but simply have it lying around as untracked file. Try .git/info/exclude https://git-scm.com/docs/gitignore ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Submitting patches using git
Am 20.07.2019 um 22:29 schrieb Ryan Joseph: On Jul 20, 2019, at 4:19 PM, Sven Barth via fpc-devel wrote: Why is your .gitignore so big? Mine looks like this: I’m sorry, what I wrote didn’t make any sense. I mean that after I delete .gitignore then all the .o etc.. files that it was ignoring now come flooding back into the project and so they need to be deleted. My git client handles it well enough but the 20k+ files stall out the UI a little. ;) You can delete the .gitignore from the repository, but keep it around as an uncommitted file in the branch you're preparing. For example I myself don't commit my .gitignore, but simply have it lying around as untracked file. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Submitting patches using git
On 20/07/2019 22:14, Ryan Joseph wrote: On Jul 20, 2019, at 4:02 PM, Martin Frb wrote: "origin/master" is the not modified trunk? No, what I did was fork https://github.com/graemeg/freepascal and then a create new feature branches based on master. “origin” I believe refers to my forked repo on GitHub and “upstream” is the original, i.e. https://github.com/graemeg/freepascal. So what I do when I want to keep up to date is "git pull upstream master” which updates my local “master” branch with changes from graemeg/freepascal. The problem I face now is how to get changes from master into my feature branch. Merging worked fine but then I face the problem of not being able to squash all commits before submitting patches. I’ve just learned now that rebase works BUT I need to squash commits first. Catch 22. The real root of the problem is that I need to squash my feature branches commit history or my patches will get rejected. If that weren’t the case I would just do a merge and release the patch with full commit history. Ok there are 2 questions 1) if you pull, and want to avoid merges. git pull --rebase will rebase instead of merge. BUT: if you push your resulting branch to your own repro then you may need force-with-lease. That is if you had already pushed before, because then you need the same history rewrite on your server, as you did locally with the rebase. forced push should only ever be to your own repro/server. And ideally always force-with-lease 2) You current branch. You can rewrite your current branch Again find the first commit you made, that is of interest. Get the hash of the commit ONE BEFORE "0abcedef" Whilst checked out to your branch: git rebase -i 0abcedef Should open an editor with all the commits in it. Re-order them, so ALL your commits are on top. The editor text has some doc in it. You can squash your commits now. But you can do that later, and keep the unsquashed ones too. Save and exit the editor. git will rewrite the current branch, to have commits in the order that you specified. -- If you want to play: Before you start, create a new branch at the top (HEAD) of your current branch. That will keep the old commits in the old order under that new branches name. (reflog does the same, but this may be easier) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Submitting patches using git
> On Jul 20, 2019, at 4:19 PM, Sven Barth via fpc-devel > wrote: > > Why is your .gitignore so big? Mine looks like this: I’m sorry, what I wrote didn’t make any sense. I mean that after I delete .gitignore then all the .o etc.. files that it was ignoring now come flooding back into the project and so they need to be deleted. My git client handles it well enough but the 20k+ files stall out the UI a little. ;) Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Submitting patches using git
> On Jul 20, 2019, at 4:12 PM, denisgolovan wrote: > > Have you renamed your branch? > Last time you mentioned it was "gen-const-new”. The branch is called “generic_constants” but I’m making temporary copies for testing so I don’t mess up the safe one. > And you didn't include enough log to see origin/master (see in brackets like > in your first commit). > > Again your commits should be at the top of origin/master if "git rebase" did > its job correctly without any conflicts. > If you have conflicts, you need to resolve them one by one and do "git rebase > --continue" each time. Here’s a full log until my initial commit. You can see I haven’t merged updates from the main repo since 2018. If you scroll down you’ll see I made a new branch from generic_constants called “generic_constants_rebase” and then did "git rebase master”. At this point it’s giving me a conflict which is from an old commit (I think from the line "Patch failed at 0005”). It like the old commit is conflicting with something from master but why is it looking at old commits? Ryans-MacBook-Pro-2:fpc-git ryanjoseph$ git log --graph * commit c5a6c2c0822d6c869a788a98a144e739a97d517a (HEAD -> generic_constants, origin/generic_constants) | Author: Ryan Joseph | Date: Sat Jul 20 09:40:58 2019 -0400 | | fixed bugs with range checking and constants + added 2 tests | * commit 49de8113a1eb29b368d89d9e2fb7fa7c932d937e | Author: Ryan Joseph | Date: Mon Mar 25 10:35:47 2019 -0400 | | reverted back bad line endings in htypechk.pas | * commit 128d695bf83fb19de342d8e23101ec0223e08e1b | Author: Ryan Joseph | Date: Fri Mar 22 13:10:12 2019 -0400 | | added 2 more tests | * commit 4dcdd8932d5bc50b5d87bc8e1f1a7ea4e6d5b29f | Author: Ryan Joseph | Date: Tue Mar 19 09:18:39 2019 -0400 | | Fixed more operator bugs and added test | * commit f2039f13c74e74cb523076b27ff6559ae69ad7d1 | Author: Ryan Joseph | Date: Sun Mar 17 16:26:40 2019 -0400 | | Fixed binary op bugs and constant assignment bugs, added tests | * commit 053be315080c47dea68aa52c020fcbe23225d1d3 | Author: Ryan Joseph | Date: Sat Feb 23 15:01:58 2019 -0500 | | better const compare in compare_defs_ext, added tests | * commit 7f234fad6b503c0374320a81eb45d9c4e4327734 | Author: Ryan Joseph | Date: Sat Feb 16 16:27:28 2019 -0500 | | fixed tests | * commit d9cb1e6d09df6389e6f4b234ed4a13d5b2b111be | Author: Ryan Joseph | Date: Sat Feb 16 16:00:07 2019 -0500 | | fixed "class procedure" bug, cleaned up some type cast errors | * commit 2efec219041f23036508f9a35b8a7492404f29a8 | Author: Ryan Joseph | Date: Fri Feb 15 11:00:20 2019 -0500 | | fixed .gitignore so tests are included | * commit 902c7151151ccb96f2825a6eede493e9bc88af72 | Author: Ryan Joseph | Date: Mon Feb 11 11:27:37 2019 -0500 | | def compare for specialized refs with constants | * commit 3dcffa470383e81d0b287ed2c27e9b6f66362014 | Author: Ryan Joseph | Date: Sat Feb 9 17:06:54 2019 -0500 | | adding constant type/range checking | * commit 02e9456d351fb6bdeac15cf14c4e50920a718a83 | Author: Ryan Joseph | Date: Mon Jan 7 11:18:17 2019 -0700 | | minor bug fixes | * commit bd76667453914106a51d31672d841b1344066e6a | Author: Ryan Joseph | Date: Sun Jan 6 17:49:15 2019 -0700 | | Removed tgenericparamdef and defs from tspecializationcontext, changed separator syntax | * commit 3ad83ffed75b20b8f52a823452824b9eaae31ee8 | Author: Ryan Joseph | Date: Tue Nov 27 19:53:24 2018 +0700 | | bug fix | * commit 3a6b595ade54ff8b7b052221d28d1fb551a9fc7e | Author: Ryan Joseph | Date: Tue Nov 27 12:45:52 2018 +0700 | | changed const generic params to tconstsym | * commit d71e8383ebe679926598e690956b97055fada833 | Author: Ryan Joseph | Date: Tue Nov 27 08:59:05 2018 +0700 | | Removed tgenericparamsym* types | * commit 21181027340e5ab6f25f9350217ed1d4942f1e1e | Author: Ryan Joseph | Date: Wed Nov 14 09:19:57 2018 +0700 | | Bug in string const constraints | * commit 9b2190a54dff16630ea1788ab408095bd7535547 | Author: Ryan Joseph | Date: Tue Nov 13 19:11:21 2018 +0700 | | Updated ppu version | * commit b9ff43058fe98c4e3ad176953dad5413091b1676 | Author: Ryan Joseph | Date: Tue Nov 13 16:10:00 2018 +0700 | | Removed type | * commit d84930722cd94fff57638c55e1c84d48c321f104 | Author: Ryan Joseph | Date: Tue Nov 13 16:08:54 2018 +0700 | | Const type restrictions | * commit b1483f95a0636b9f29fbdc875d17b09143bbd9ea | Author: Ryan Joseph | Date: Tue Nov 13 10:45:16 2018 +0700 | | removed .gitignore | * commit 4e43439973af1413fbedb5c0b78cc60f668393e9 | Author: Ryan Joseph | Date: Tue Nov 13 10:44:29 2018 +0700 | | Generic const params can be assigned to struct consts, PPU loading, all const types accepted | * commit e2f86ae6e5c3c52d123e3e8b32103f5136b75cf2 | Author: Ryan Joseph | Date: Sat Nov 10 10:20:52 2018 +0700 | | Fixed bug in type constraints, added
Re: [fpc-devel] Submitting patches using git
Am 20.07.2019 um 18:58 schrieb Ryan Joseph: 3) remove .gitignore (which now includes thousands of .o/.ppu files which need to be deleted) and any other unrelated personal files. Why is your .gitignore so big? Mine looks like this: === file begin === # ignore binary files *.o *.ppu *.exe *.pcp *.a *.dll *.ppl *.rsj *.bak *.lst *.diff *.patch *.wpo *.lps # ignore fpmake files *.fpm # ignore other build files *-stamp.* fpcmade.* backup/ bin/ units/ * - Kopie* fpmake lazbuild/ fpctests/ testoutput/ *.mod ppc* === file end === (The "* - Kopie*" one is due to me sometimes doing copies with Windows Explorer when I want to split changes that "git add -p" can't handle, same for "*.mod" for manual copies on the command line ;) ) This keeps my status output relatively clean (and I'm sure that I could improve it further): === output begin === On branch master Changes not staged for commit: (use "git add ..." to update what will be committed) (use "git checkout -- ..." to discard changes in working directory) modified: compiler/aasmcnst.pas modified: compiler/ppcx64.lpi modified: tests/test/units/fpcunit/testcomps.pp Untracked files: (use "git add ..." to include in what will be committed) .gitconfig .gitignore compile-rtl-objpas-testrunner.bat compiler/cextflt.pas compiler/utils/fpc compiler/utils/mka64ins compiler/utils/mkarmins compiler/utils/mkx86ins compiler/utils/ppudump compiler/utils/ppufiles compiler/utils/ppumove output.wp-pp.txt packages/dyncall/ packages/rtl-objpas/tests/testrunner.rtlobjpas ppudump.txt q rtl-objpas-tests/ rtl/embedded/arm/samd21g18a.pp tests/createlst tests/gparmake tests/output/ tests/tbs/tb0658.pp tests/tstunits/i386-win32/ tests/tstunits/tmp/ tests/tstunits/x86_64-linux/ tests/tstunits/x86_64-win64/ tests/utils/concat tests/utils/digest tests/utils/dotest tests/utils/fail tests/utils/fptime tests/utils/testfail tests/webtbs/tw35019.pp tests/webtbs/tw35248.pp utils/importwinmd/ windows-ppu.txt no changes added to commit (use "git add" and/or "git commit -a") === output end === Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Submitting patches using git
> On Jul 20, 2019, at 4:02 PM, Martin Frb wrote: > > "origin/master" is the not modified trunk? No, what I did was fork https://github.com/graemeg/freepascal and then a create new feature branches based on master. “origin” I believe refers to my forked repo on GitHub and “upstream” is the original, i.e. https://github.com/graemeg/freepascal. So what I do when I want to keep up to date is "git pull upstream master” which updates my local “master” branch with changes from graemeg/freepascal. The problem I face now is how to get changes from master into my feature branch. Merging worked fine but then I face the problem of not being able to squash all commits before submitting patches. I’ve just learned now that rebase works BUT I need to squash commits first. Catch 22. The real root of the problem is that I need to squash my feature branches commit history or my patches will get rejected. If that weren’t the case I would just do a merge and release the patch with full commit history. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Submitting patches using git
On 20/07/2019 22:02, Martin Frb wrote: IF this does not show all of your commits (because the branches where merged), find the revision ONE BEFORE your first commit. (say it is 0abcde): git rebase -i 0abcde origin/master That may have to be git rebase -i --onto origin/master 0abcde your-branch-name ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Submitting patches using git
> Here’s the results of "git log —graph” on the feature branch. Does that first > part look right? I feel like I messed up something from the very start but > I’m not sure what. > > Ryans-MacBook-Pro-2:fpc-git ryanjoseph$ git log --graph > * commit c5a6c2c0822d6c869a788a98a144e739a97d517a (HEAD -> generic_constants, > origin/generic_constants) > | Author: Ryan Joseph > | Date: Sat Jul 20 09:40:58 2019 -0400 > | > | fixed bugs with range checking and constants + added 2 tests > | > * commit 49de8113a1eb29b368d89d9e2fb7fa7c932d937e > | Author: Ryan Joseph > | Date: Mon Mar 25 10:35:47 2019 -0400 > | > | reverted back bad line endings in htypechk.pas > | > * commit 128d695bf83fb19de342d8e23101ec0223e08e1b > | Author: Ryan Joseph > | Date: Fri Mar 22 13:10:12 2019 -0400 > | > | added 2 more tests > | > * commit 4dcdd8932d5bc50b5d87bc8e1f1a7ea4e6d5b29f > | Author: Ryan Joseph > | Date: Tue Mar 19 09:18:39 2019 -0400 > | > | Fixed more operator bugs and added test > | > * commit f2039f13c74e74cb523076b27ff6559ae69ad7d1 > : Have you renamed your branch? Last time you mentioned it was "gen-const-new". And you didn't include enough log to see origin/master (see in brackets like in your first commit). Again your commits should be at the top of origin/master if "git rebase" did its job correctly without any conflicts. If you have conflicts, you need to resolve them one by one and do "git rebase --continue" each time. -- Regards, Denis Golovan ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Property attributes support
Am 20.07.2019 um 18:38 schrieb Ondrej Pokorny: The old Wiki page should propably be updated to reflect the current state of affairs... I deleted the old information (nearly everything) and put a link to the new Wiki page there. Probably for the best ;) You can also take a look at Delphi tutorials. The only difference is that we provide access through the TypInfo unit as well while Delphi officially only supports the Rtti unit. I am familiar with Delphi attributes - I didn't expect the FPC attributes to be Delphi-compatible. Thanks again! As if we'd implement a big feature like that in a incompatible way... The proposal in the Wiki was before Delphi added attributes and Joost implemented them in a Delphi-compatible way from the get go. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Submitting patches using git
> On Jul 20, 2019, at 3:01 PM, denisgolovan wrote: > > Generally it means all your feature branch commits are on top of > origin/master. > > It's a bit difficult to explain via text. > Try doing "git log --graph" before and after doing rebase and you will see it > changes in feature branch to be moved (or rebased) after origin/master last > commit in your feature branch. I’m doing lots of trials right now but I can’t seem to get rebase to work unless I squash all the commits in the feature branch first but then I lose my commit history. I don’t know what it did but I see it merged changes from previous commits and didn’t even include all the changes from master. Very confusing. Here’s the results of "git log —graph” on the feature branch. Does that first part look right? I feel like I messed up something from the very start but I’m not sure what. Ryans-MacBook-Pro-2:fpc-git ryanjoseph$ git log --graph * commit c5a6c2c0822d6c869a788a98a144e739a97d517a (HEAD -> generic_constants, origin/generic_constants) | Author: Ryan Joseph | Date: Sat Jul 20 09:40:58 2019 -0400 | | fixed bugs with range checking and constants + added 2 tests | * commit 49de8113a1eb29b368d89d9e2fb7fa7c932d937e | Author: Ryan Joseph | Date: Mon Mar 25 10:35:47 2019 -0400 | | reverted back bad line endings in htypechk.pas | * commit 128d695bf83fb19de342d8e23101ec0223e08e1b | Author: Ryan Joseph | Date: Fri Mar 22 13:10:12 2019 -0400 | | added 2 more tests | * commit 4dcdd8932d5bc50b5d87bc8e1f1a7ea4e6d5b29f | Author: Ryan Joseph | Date: Tue Mar 19 09:18:39 2019 -0400 | | Fixed more operator bugs and added test | * commit f2039f13c74e74cb523076b27ff6559ae69ad7d1 : Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Submitting patches using git
On 20/07/2019 19:57, Ryan Joseph wrote: On Jul 20, 2019, at 1:04 PM, Jonas Maebe wrote: You can rebase your feature branch on latest trunk/master instead of merging. I think that may even work after you have previously merged it (and it should get rid of all merge commits). I tried doing "git rebase origin/master” on the feature branch BEFORE I merged the master but it says "Current branch gen-const-new is up to date.”. What is rebase doing that it thinks the feature branch is up to date? "origin/master" is the not modified trunk? Checkout to your branch, and try git rebase -i origin/master This should open an editor with all the git commits since you forked your branch. Remove all the revisions that belong to trunk, only keep the ones you changed. That will move all your commits to the top. IF this does not show all of your commits (because the branches where merged), find the revision ONE BEFORE your first commit. (say it is 0abcde): git rebase -i 0abcde origin/master ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Submitting patches using git
> I tried doing "git rebase origin/master” on the feature branch BEFORE I > merged the master but it says "Current branch gen-const-new is up to date.”. > What is rebase doing that it thinks the feature branch is up to date? Generally it means all your feature branch commits are on top of origin/master. It's a bit difficult to explain via text. Try doing "git log --graph" before and after doing rebase and you will see it changes in feature branch to be moved (or rebased) after origin/master last commit in your feature branch. -- Regards, Denis Golovan ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Internal error 200510032 on SynEdit package
Hello, I updated trunk now and wanted to test the attributes support - and now I get Internal error 200510032 when compiling the SynEdit package. (See attached screenshot.) synedithighlighterxmlbase.pas(236,31) Error: Internal error 200510032 Rebuild clean doesn't help. I can go over the error when I change this line: Result := TSynXmlRangeInfo((ItemPointer[Index] + FItemOffset)^); to var P: Pointer; // P := ItemPointer[Index] + FItemOffset; Result := TSynXmlRangeInfo(P^); Anybody knows whats going on and why it stopped working? (I am on Windows and use the 32bit compiler. Today's FPC trunk, today's Lazarus trunk.) Best Ondrej ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Submitting patches using git
> On Jul 20, 2019, at 1:04 PM, Jonas Maebe wrote: > > You can rebase your feature branch on latest trunk/master instead of > merging. I think that may even work after you have previously merged it > (and it should get rid of all merge commits). I tried doing "git rebase origin/master” on the feature branch BEFORE I merged the master but it says "Current branch gen-const-new is up to date.”. What is rebase doing that it thinks the feature branch is up to date? Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Submitting patches using git
On 20/07/2019 18:58, Ryan Joseph wrote: > I’m getting better with git but I’m still having problems with basic > workflows. My newest dilemma is trying to submit a patch which is actually up > to date with the current master branch > (https://bugs.freepascal.org/view.php?id=35140). Here’s what I do: > > 1) pull changes from the master remote upstream into my master branch (this > is: https://github.com/graemeg/freepascal). > 2) merge the updated local master branch into the feature branch and resolve > any conflicts if need be. > 3) remove .gitignore (which now includes thousands of .o/.ppu files which > need to be deleted) and any other unrelated personal files. > 4) squash all commits into a single so the patch doesn’t include the entire > commit history. > 5) finally make a nice clean patch using: git format-patch master --stdout > > patch.diff > > The problem is that since I merged the updated master branch I can’t squash > commits because git complains "only commits reachable from HEAD can be > modified”. Is this not how I’m supposed to keep my local feature branch > up-to-date with the server? Any advice would be great. You can rebase your feature branch on latest trunk/master instead of merging. I think that may even work after you have previously merged it (and it should get rid of all merge commits). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Submitting patches using git
I’m getting better with git but I’m still having problems with basic workflows. My newest dilemma is trying to submit a patch which is actually up to date with the current master branch (https://bugs.freepascal.org/view.php?id=35140). Here’s what I do: 1) pull changes from the master remote upstream into my master branch (this is: https://github.com/graemeg/freepascal). 2) merge the updated local master branch into the feature branch and resolve any conflicts if need be. 3) remove .gitignore (which now includes thousands of .o/.ppu files which need to be deleted) and any other unrelated personal files. 4) squash all commits into a single so the patch doesn’t include the entire commit history. 5) finally make a nice clean patch using: git format-patch master --stdout > patch.diff The problem is that since I merged the updated master branch I can’t squash commits because git complains "only commits reachable from HEAD can be modified”. Is this not how I’m supposed to keep my local feature branch up-to-date with the server? Any advice would be great. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Property attributes support
On 20.07.2019 13:56, Sven Barth via fpc-devel wrote: Here: https://wiki.freepascal.org/Custom_Attributes Thank you! The old Wiki page should propably be updated to reflect the current state of affairs... I deleted the old information (nearly everything) and put a link to the new Wiki page there. You can also take a look at Delphi tutorials. The only difference is that we provide access through the TypInfo unit as well while Delphi officially only supports the Rtti unit. I am familiar with Delphi attributes - I didn't expect the FPC attributes to be Delphi-compatible. Thanks again! Ondrej ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Deeper problem with Internal Error 200309201
Note that there is possible room for improvement with this concept (like maybe only running the semantic check on nodes that exist before the first pass, not executing it on any transformed nodes), but I wanted to get something clean working first, and fix the bugs that have been on the system for a while. Gareth aka. Kit On 18/07/2019 05:43, J. Gareth Moreton wrote: I've completed my work, although I had to adapt the original plan slightly, and I feel like my design spec could use some rewriting in places. Think of it as code smell for writing! https://bugs.freepascal.org/view.php?id=35857 - the PDF design spec is here. Gareth aka. Kit --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TFIeld.lookup problem
On Sat, 20 Jul 2019, Marco van de Voort wrote: Op 2019-07-20 om 16:04 schreef Michael Van Canneyt: Why is this field deprecated and not published? It really complicates dual maintenance of apps with database fields. Because it is redundant. The fieldkind property is what you need. Set fieldKind=fkLookup As said, it causes annoying problems with dual maintenance of forms for no particular reason (since the property is still there, public). Is it so hard to make it published (stored false if need be?). (that came out a bit more whiny then I meant it :-) No, it is not. But dual maintenance was never a target. Deliberately frustrating it can't be the object either. That was not the intent. Easy porting, yes. It makes it unnecessary hard for e.g. example code for shared component packages. So can we please change it? Just say the word, and I'll do it. Sure, go ahead. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TFIeld.lookup problem
Op 2019-07-20 om 16:04 schreef Michael Van Canneyt: Why is this field deprecated and not published? It really complicates dual maintenance of apps with database fields. Because it is redundant. The fieldkind property is what you need. Set fieldKind=fkLookup As said, it causes annoying problems with dual maintenance of forms for no particular reason (since the property is still there, public). Is it so hard to make it published (stored false if need be?). (that came out a bit more whiny then I meant it :-) No, it is not. But dual maintenance was never a target. Deliberately frustrating it can't be the object either. Easy porting, yes. It makes it unnecessary hard for e.g. example code for shared component packages. So can we please change it? Just say the word, and I'll do it. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TFIeld.lookup problem
On Sat, 20 Jul 2019, Marco van de Voort wrote: Op 2019-07-20 om 14:40 schreef Michael Van Canneyt: Why is this field deprecated and not published? It really complicates dual maintenance of apps with database fields. Because it is redundant. The fieldkind property is what you need. Set fieldKind=fkLookup As said, it causes annoying problems with dual maintenance of forms for no particular reason (since the property is still there, public). Is it so hard to make it published (stored false if need be?). No, it is not. But dual maintenance was never a target. Easy porting, yes. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TFIeld.lookup problem
Op 2019-07-20 om 14:40 schreef Michael Van Canneyt: Why is this field deprecated and not published? It really complicates dual maintenance of apps with database fields. Because it is redundant. The fieldkind property is what you need. Set fieldKind=fkLookup As said, it causes annoying problems with dual maintenance of forms for no particular reason (since the property is still there, public). Is it so hard to make it published (stored false if need be?). ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TFIeld.lookup problem
On Sat, 20 Jul 2019, Marco van de Voort wrote: Why is this field deprecated and not published? It really complicates dual maintenance of apps with database fields. Because it is redundant. The fieldkind property is what you need. Set fieldKind=fkLookup Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] TFIeld.lookup problem
Why is this field deprecated and not published? It really complicates dual maintenance of apps with database fields. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Property attributes support
Ondrej Pokorny schrieb am Sa., 20. Juli 2019, 12:04: > Hello! > > I saw that Sven committed property attributes support in trunk. Thank > you for this! > > Is there any documentation how to use them? (Syntax, reading information > during runtime etc?) I only found very old information: > https://wiki.freepascal.org/Property_attributes > > http://free-pascal-general.1045716.n5.nabble.com/Property-attributes-td5718442.html Here: https://wiki.freepascal.org/Custom_Attributes The old Wiki page should propably be updated to reflect the current state of affairs... You can also take a look at Delphi tutorials. The only difference is that we provide access through the TypInfo unit as well while Delphi officially only supports the Rtti unit. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Property attributes support
Hello! I saw that Sven committed property attributes support in trunk. Thank you for this! Is there any documentation how to use them? (Syntax, reading information during runtime etc?) I only found very old information: https://wiki.freepascal.org/Property_attributes http://free-pascal-general.1045716.n5.nabble.com/Property-attributes-td5718442.html Best Ondrej ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
