Re: [fpc-other] Fork
Am 21.10.2010 22:13, schrieb Adem: I don't have the top post ( http://lists.freepascal.org/lists/FPC-other/2010-October/000468.html ) in this thread to comment on in a more conversation fashion, as a result I reverting to bulleted listing of my views on the subject. 1) In the fpc-devel I have read quite a few arguments that FPC is production quality and no significant changes can be afforded to that code. While I sympathize with what that implies, it also means that, structurally, FPC is more or less frozen This is wrong. If a big change promises significant advantages for FPC users, it will be done. Things like turning the parser upside down simply don't have an significant advantage for users. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Fork
Am 24.10.2010 19:03, schrieb Graeme Geldenhuys: On 22 October 2010 20:20, Marco van de Voort wrote: Graeme's last mail where he explains he just wants to drop quick and dirty patches AND IT IS FPC'S CORE TEAM JOB to make head or tails of it, explains the fundamental misconception better than I could do here. And here I thought that is what a detailed commit log is for. Correct me if I'm wrong, but it seems the norm of SubVersion users is to give one liner commit comments. That is just wrong. The normal in Git repositories, well at least git.git repo and our company repos, is to give a much more detailed commit message. Makes applying patches a breeze, as well as when you have no review a old commit. Oh yes, the vcs is to blame for poor commit comment. Maybe we should create a list fpc-bullshit for you? ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Embarcadero plans to base C++ and Delphi compilers on LLVM
Am 10.07.2012 09:45, schrieb Sven Barth: Hello together! Today I stumpled upon this http://www.itwriting.com/blog/5966-embarcadero-adopts-open-source-clang-for-future-c-versions.html and maybe some of you will find this interesting. Let's see who will be first with LLVM support: Embarcadero or we ;) Having LLVM as sole fpc backend would probably take 90% out of my fun of fpc development :( ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
Re: [fpc-other] Source code of Adobe Photoshop 1 published
Am 14.02.2013 20:20, schrieb Sven Barth: On 14.02.2013 20:07, Florian Klämpfl wrote: Am 14.02.2013 20:06, schrieb Sven Barth: I wonder whether the first version of FPC 0.1 or 1.0 :)? 0.1 of course :) 0.1 was never released to public. To revive it I need to get my hands on a 5 1/4 drive first. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
[fpc-other] Community site
You might have noticed that the FPC community site is already down for some time. Since we are retiring the machine running the community site we decided not to migrate the community but add some new boards to the lazarus forum to reduce the need to maintain another bulletin board site. The lazarus forum can be reached at http://forum.lazarus.freepascal.org/index.php?action=forum and it contains now an FPC section. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] [fpc-pascal] Google Code closing down
Am 15.03.2015 um 15:11 schrieb vfclists .: Somehow all this indifference to Git bothers me because it seems they are ignoring the greater realities of life. If a new generation are going to get involved with FPC and Lazarus development, and the main developers are really concerned with all the time and effort they put into this great product not going to waste when they retire then they ought to reconsider the indifference or aversion to Git. Luckily enough, this is an automatism. As soon as somebody pops up and does e.g. repository maintainance, fixes branch merging etc. and volounteers to work on switching the whole FPC infrastructure to git, this will happen. Since this is a lot of really tedious work, it will be probably take another couple of decades especially as anybody really used to git can use it already flawlessly with git-svn. Ever wondered how Jonas can commit hundreds of changesets within a few minutes ;)? Now Florian, considering your preference for GUI tools, won't the development of cross platform Git GUI surpassing Tortoise Git, Github and Atlassian's tools, SmartGit and whatever be the best advert for Lazarus and FPC? In a world with unlimited resources and time? Maybe. There would such a major flow of patches coming in that you would have to stop coding actively and review the patches going in like Linus does. For sure not my aim, actually, if I had only to review patches, I would quit to work on FPC or whatever. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] [fpc-pascal] Google Code closing down
Am 16.03.2015 um 13:53 schrieb Graeme Geldenhuys: Hello Martin, On 2015-03-16 12:35, Martin Frb wrote: better product, simply means: Compared to others it scores better on more use cases. Agreed. :-) Different people learn in different ways. There will be a fair share of people for whom taking their first steps into using a repository is better done with a simpler system. I fully understand that. I think the biggest resistance to migrating to git is the distributed system principle. For me 1) it is usability, mainly the gui, well, and other stuff like the un-memorizable hashes. 2) too much freedom :) svn forces me basically to finish patches: if I started to modify something, it is the easiest to finish it than to store it somehow away. git doesn't, just commit when being disturbed, add an unfinished in front of the commit message and I can/will continue with something else when I come back. For an idle time project like FPC this is really a problem for me: my git-svn copy contains currently around 60 unfinsished branches :( And of course in case of FPC the huge effort to switch the whole infrastructure. That scares people. That is why I introduced the developers, at my previous employment, to git by simplifying things. I let them use a client/server workflow model. That seem to have helped them a lot, and get over that fear they had. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] [fpc-pascal] Google Code closing down
Am 16.03.2015 um 10:23 schrieb Graeme Geldenhuys: As the majority of developers would tell you, Git is simply the better product at this stage. If you want facts, then do a Google search. See the exponential growth of projects migrating from SubVersion (or other systems) to Git. Qt, KDE, Linux Kernel etc - they are massive projects and must have had very good reason to move to Git. But why do you use Pascal then? All these projects use C/C++, probably also for a good reason. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
Am 23.05.2017 um 12:42 schrieb Graeme Geldenhuys: > On 2017-05-23 11:31, Tomas Hajny wrote: >> the other, but let me remind you, that it isn't just about Florian. During >> the previous discussions on this evergreen topic, Florian, Marco, Jonas >> (if I remember correctly) and others raised quite a few specific questions >> on how to accomplish particular tasks commonly used in the FPC project. I >> may have missed something, but I haven't noticed a particular proposal >> from you or anyone else describing in detail how to cover those needs > > To be honest, I can't actually remember seeing any such proposal (asking for > advice or help) in the > FPC-Users mailing list. Maybe it was in a list I'm not subscribed in? > Otherwise, I would have > happily given my advice. First problem: quote from core: Am 05.03.2017 um 20:53 schrieb Jonas Maebe: > On 05/03/17 14:33, Maciej Izak wrote: >> Mhm. It hapens also for simplified github import for svn >> (https://help.github.com/articles/about-github-importer/). My >> proposition is : >> >> git svn init -s http://svn.freepascal.org/svn/fpc >> :repeatloop >> git svn fetch >> If %ErrorLevel%==1 ( >> Goto :repeatloop >> ) >> >> (this command is for repo with all branches, instead of -s I have used >> for NewPascal --trunk=trunklink but in theory -s should work...) > > It doesn't abort with errors (except at some point because we created a > branch called "avr", deleted > it, then again created a branch with that name -- but that can be worked > around). It simply does not > imports some revisions, or does not classify them under the right branches. But actually, as long as llvm and gcc still use svn, svn should fulfill our needs as well :) ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
Am 23.05.2017 um 18:00 schrieb Karoly Balogh (Charlie/SGR): > Hi, > > On Tue, 23 May 2017, Martin Frb wrote: > >> Or maybe they haven't forgotten how nice and simple svn is. > > Erm, I really don't want to be involved in the usual religious war, > personally I use exclusively Git these days (for personal stuff), but I > don't mind SVN, CVS, or whatever a project uses I'm working on. But. > >> Git just doesn't do KISS. > > You need an SVN server to start working with SVN. Every tried: C:\temp>svnadmin create repos C:\temp>svn checkout file:///c:/temp/repos wc Checked out revision 0. ? > > Also, ever tried to do partial commits in SVN? (Not committing all the > changes in a single file.) (git add --patch) I do it daily with FPC (using TortoiseSVN though). ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
Am 23.05.2017 um 22:10 schrieb Karoly Balogh (Charlie/SGR): > > 1., Have his own clone of the FPC repository. Create his local webassembly > branch, and keep happily working on his local copy, then leave it rot > when he loses motivation, doesn't distract anyone. > ... and the code is lost :) ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
Am 23.05.2017 um 21:56 schrieb Graeme Geldenhuys: > On 2017-05-23 20:33, Karoly Balogh (Charlie/SGR) wrote: >> Now, how the actual process would look with the FPC team, that's hard to >> define at this point. But the tools are there for it. > > Exactly what I was getting at. > > >> Was this a proper answer, or I was beating around the bush in your views? >> :) > > Finally somebody that understands distributed version control, and how Git > could be used. You gave a > very good answer indeed. Too many people (and companies) are so stead fast in > the ways of a > client/server version control system - like SubVersion. They then wrongly (or > not ideal) force those > ideas onto Git usage. Hence the reason I said it takes a bit or "rethinking > the problem", and in the > end everything becomes quite clear. > > For those interested, read the many blobs about how the Linux Kernel > development is managed. FPC is a compiler and not an OS kernel, so would like to see such blog posts from big compilers: e.g. gcc, clang ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
Am 23.05.2017 um 22:36 schrieb Karoly Balogh (Charlie/SGR): > so they just use > git-svn. This is what I do as well for several things, but I still think, subversion is the better solution as the canonical FPC repository. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
Am 24.05.2017 um 08:57 schrieb Graeme Geldenhuys: > > Once again, read how the Git project deals with it. That workflow could suite > FPC quite well. You never developed a real world compiler and you have no real insight into fpc development so you cannot know about this. > In > summary, feature are in separate branch. There is a public "testing stablish > changes" and a public > "testing unstable" branches. Everything stays in branches until they are > signed off and merged into > "master" (aka Trunk). Then less than 5 minutes is spend doing a "octopus > merge" of all branches that > have been well tested and signed. Who tests and signs? Our testing facilities cannot test more than a few (1, 2 maybe 3) branches nightly as we use build farms used also by other people. Further we test also on slow system, where one run takes >1h. We have already >150 regression test runs per night with different parameters, on difference architectures etc. This cannot be extended. Everything not in trunk (or master/) fixes is not seriously tested and cannot seriously be tested, due to lacking resources. So feature branches make only sense for big changes (as we do already with svn). Or tests the "crowd" which makes OSS so powerful and everything is reviewed by dozens of people? Looking at the problems FPC 3.0.2 has, people even didn't test release candidates seriously. And some branch for a single feature? May I laugh? ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
Am 25.05.2017 um 00:44 schrieb Graeme Geldenhuys: > But I get in now. You guys are set in your ways - good or bad, and currently > not willing to change. > So I'll leave it at that. Thanks. I hope I might quote you in a few weeks/months/years :) ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
Am 25.05.2017 um 12:02 schrieb Graeme Geldenhuys: > On 2017-05-25 09:26, Florian Klämpfl wrote: >> This is at least one month of work I (and >> probably nobody else) can and want to spent. > > And some how I believe that will never happen (or be allowed) even if I (or > somebody else) decide to > donate a month of our time. Indeed, it depends on the person who does it. It requires knowledge about the specific workflow requirements of a compiler project. And that this is not easy is proven by the fact that gcc as well as llvm still use svn as canonical repository. They probably have a lot more man power than FPC. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] What makes a Compiler project (like FPC) special?
Am 25.05.2017 um 21:29 schrieb Graeme Geldenhuys: > > So what is Florian going on about regarding workflow and Git not being able > to cope in a "compiler" > based project? He made it out as if FPC will not be workable in a Git managed > environment. I don't > see his analogy. The Linux Kernel running on more platforms than FPC does, is > just as complex a > beast, It is not complex in the sense Nikolay described. > I see no proof to > convince me otherwise > - a compiler is just a complex project. > Nothing "special" as he claimed it to be. See, this is the reason why I do not believe you. You simply cannot understand the problems of a compiler project which requires small linear steps which can be easily reviewed. And it seems LLVM likes this small steps as well: http://lists.llvm.org/pipermail/llvm-dev/2011-July/041781.html ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] What makes a Compiler project (like FPC) special?
Am 25.05.2017 um 16:18 schrieb Graeme Geldenhuys: > This is directed at Florian primarily, but any other FPC core member is > welcome to chip in. > > different to any other software project... It has really bugged me... > Why is it different, and What is different? Because they are basically a mess of spaghetti code and modules :) And this is not the writers fault but simply their nature, they are a very complex piece of software were everything is inter winded. In theory, everything sounds simple: one has a front end consisting of a scanner and a parser and a back end consisting of an optimizer, a code generator and an assembler. Front end and back end are accessing the symbol tables. However, in practice things look different. We try to keep fpc layered and everything, nevertheless, the unit dependency graph looks terrible, see attachment (resized, I can send a full fledged pdf if someone is interested). Simple things often mean that one has to dig upside down and one is often bitten by several side effects or interferences of changes. I am really familiar with the code of FPC, but I do not want to know the hours I spent in e.g. r36325 (which is basically 100 lines of new code, rest is copy and moving code around) due to such effects. Code sample for the "spaghetti" nature, just look at the needtemp function in fpc/compiler/ncal.pas at line 4589: it determines if an argument of an inlined subroutine needs to be copied to a temp. The code is commented very well, it is almost literate programming, everything is split into multiple if statements, nevertheless it is very unreadable. Of course, EveryIfStatmentCouldBeMovedToAnExtraFunctionWithADescribtiveLongName, but I doubt that it makes it more readable in the sense of being understandable. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
Am 24.05.2017 um 21:34 schrieb Graeme Geldenhuys: > On 2017-05-24 19:11, Florian Klämpfl wrote: >> You never developed a real world compiler and you have no real >> insight into fpc development so you cannot know about this. > > As a technical consultant for many clients I have seen a boat load of > projects from banking to > online trading to educational etc. So no compiler? ... > I'm sorry to bust your bubble, but how different can compiler > development be. Apparently it is: Am 23.05.2017 um 01:53 schrieb Graeme Geldenhuys: > > I don't know compiler design or how it works internally. So contributing in > that area is out of my > scope. :) > If you haven't found the Git project documentation on this workflow, I'll > find it for you and post > the URL. The workflow will not change. If the tool does not fit the workflow, it is the wrong tool. Period. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] VSCode
Am 26.04.20 um 14:28 schrieb Martin Frb:
On 26/04/2020 14:21, Sven Barth via fpc-other wrote:
Am 26.04.2020 um 14:03 schrieb Martin:
Just curiosity:
I recently see a lot of great efforts to make things more widely
available (language server / debug adapter).
Often with reference to use in VSCode.
I wonder what the advantage or usecases are for using VSCode as an IDE?
- free and open source
- cross platform
- easy to setup
- support for a wide range of languages (syntax highlighting, the
language servers) and environments (e.g. there's Arduino support which
is leagues better than that of the Arduino IDE)
- if the language server is implemented well then good code completion
as well
So matter of taste?
Same as some people prefer eclipse?
I was wondering how it compares (if used with FPC) to Lazarus. (Not
saying that Lazarus has a monopoly, just interested in knowing the diffs)
I.e., maybe it offers some features that Lazarus does not have?
I can see the advantage for people often using diff languages, to use
one IDE for all of them.
It has a few advantages:
- minimap
- better scm integration
- quicker way to run external commands ("tasks"), editing the tools
in lazarus is pretty cumbersome
___
fpc-other maillist - fpc-other@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] ARM is the future of desktop
Am 04.07.20 um 23:20 schrieb Marco van de Voort: Op 2020-07-04 om 23:14 schreef Sven Barth via fpc-other: Here is an interesting article by a ex-windows boss. He thinks that in a few years even desktops will be ARM and Intel will be residual. And obviously it will be a mayor problem to Microsoft, whose software is very tied to Intel platform. https://www.zdnet.com/article/ex-windows-boss-apples-arm-based-mac-will-be-the-ultimate-developer-pc/ Windows 10 nowadays supports both ARM and ARM64, so I see no problem there. And it is from Sinofsky, who is considered to be good in the tech department, but bad in the visionary department (he was resposible for the tanked Windows 8 "vision", and Microsofts failed ventures in the phone and tablet world) I stopped taking it serious when I read "iPad", "work" and "touch" in combination. While I have a current iPad, it is still no more than a better ebook, pdf and web page reader for me. Even answering mails works that bad that I prefer typically to wait till I have a real keyboard to type it. ___ fpc-other maillist - fpc-other@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
