[fpc-other] Git & SVN
On 2017-05-22 23:11, nore...@z505.com wrote: What happens if you use the SVN bridge that allows you to run svn commands to a git server? Maybe your wording is confusing, or SVN has abilities I didn't know of. I know Git can manage SVN repositories, but I didn't know it was possible other way round (I doubt it is possible). I often use Git to manage SubVersion repositories I don’t have control over. For everything else I’ve moved over to Git years ago. Local working copy issues Florian described would be an issue with this bridge, or not an issue? As with any new applications or technologies, there is always some learning curve (big or small). There are tons of bad habits ingrained in SVN users. Those do not translate well to Git (thank goodness). Git works fundamentally different to SVN (for the better). So you need a change in mindset - some refuse, hence they struggle with Git. And then wrongly blame Git for it. I fear this is most likely what happened with Florian. There are also 100’s of different work-flows for when you work with Git repositories. I’ve introduced Git into many companies. In every case I look at how they work, suggest an already existing work-flow as a starting point (*), and then tweak it to their needs. In they end they get exactly what they want, and without fail all of my customers said they should have made the switch years ago. * - My all time favourite git work-flow is: http://nvie.com/posts/a-successful-git-branching-model/ It works very will for small and large teams. Supports big or small features. Allows for long-term support releases as well as quick bug-fix releases. 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 ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] [fpc-pascal] FPC Graphics options?
On 2017-05-23 01:03, Nikolay Nikolov wrote: Isn't java just a wrapper around C? No. Java compilers generate code for a virtual machine, called JVM (Java Virtual Machine). They do not generate code for x86 CPUs or any other > ...snip... Very nice explanation and detailed information. x87 FPU instructions. Sounds so great, you're going to ask if there are any disadvantages to this approach? And, of course, there are - since the program is essentially recompiled every time the user runs it, starting Java programs take a long time. Technically correct, but you make it sound much worse than it really is. Here Eclipse IDE starts up just as fast as Lazarus IDE. And Eclipse is easily 10x or more bigger than Lazarus (when it comes to features). So JIT does a pretty damn good job if you ask me. Also JIT has improved tremendously over the last few years. In speed, performance and optimisations. I have read somewhere that now it does a [quick] compile to get your application up and running faster, then after your app is running it can recompile some classes with even more optimisations, and runtime reload those classes used by your application. All done auto-magically in the background. ;-) be a lot slower than a FPC program. I know comparing different IDEs is a little apples-to-oranges comparison (because they may have different features and vastly different implementation details), but compare the speed of e.g. Lazarus to any IDE, written in Java, even the fastest one. :) Lets just look at the two most popular Java IDEs - Eclipse and Intellij IDEA. When they are running I don't experience any speed difference comparing them to some native non-Java application of similar size. It is also worth noting that both Eclipse and Intellij IDEA does a ton more than Lazarus IDE. They both do deep code-analysis while you are coding, making suggestions on how you can improve your code, can apply those improvements with a single click or keyboard shortcut, have extremely impressive refactoring functionality that makes Lazarus look like Notepad. And the list goes on and on. Lazarus is good, but it doesn't hold a candle against what Eclipse or Entellij IDEA can [and does] do. Yes, yes, I know they have 100's or 1000's more developers too, and corporate backing. So making a comparison between those IDE's and Lazarus is rather insane. Always measure and try to understand why something is slow. In 99% of the cases it's not what people initially think. Indeed. I've learned a lot in the recent discussions, and I'm glad to see the FPC team seem to be making some effort in improving the compiler optimisation, instead of simply dismissing my work and comments. 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 ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
On Tue, May 23, 2017 11:23, Graeme Geldenhuys wrote: > On 2017-05-22 23:11, nore...@z505.com wrote: Hi Graeme, . . > As with any new applications or technologies, there is always some > learning curve (big or small). There are tons of bad habits ingrained in > SVN users. Those do not translate well to Git (thank goodness). Git > works fundamentally different to SVN (for the better). So you need a > change in mindset - some refuse, hence they struggle with Git. And then > wrongly blame Git for it. I fear this is most likely what happened with > Florian. . . > There are also 100’s of different work-flows for when you work with Git > repositories. I’ve introduced Git into many companies. In every case I . . I won't comment your generic statements praising one tool and condemning 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 (possibly a proposal altering the current practice, but still allowing to achieve the original goals). This was how we performed the CVS to SVN transition in the past. People interested in changing the tools should be those coming with a particular workable proposal on how to use the tool. You should not expect that those happily using another tool _and_ performing many more interactions with the current tool than you (without major issues) would be keen to invest their time in analyzing all possible workflows, etc., of a new tool just to find out, if they could achieve the same outcomes with another tool as well as with the current one. Also, note that while many things may work well in theory, solutions requiring users to be perfect (e.g. having high level of discipline to perform certain things in certain way resulting in the wanted outcomes) will rarely work so well in reality... Tomas ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
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. I also don't expect somebody with no or very little Git experience to give any good advice on such a matter either. I believe most of the FPC team don't have any or very little Git experience. I can add that I have been working closely with Michael van Canneyt for the past two years. In the last few months I have introduced Git in his workplace too, and his knowledge of Git has improved a lot. So maybe in the next round of proposals, Michael will be able to offer some more advice too. So again, if the FPC team ever wants to consider Git, feel free to contact me so we can bounce around some ideas. 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 ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
In our previous episode, Graeme Geldenhuys said: > As with any new applications or technologies, there is always some > learning curve (big or small). There are tons of bad habits ingrained in > SVN users. Those do not translate well to Git (thank goodness). Git > works fundamentally different to SVN (for the better). So you need a > change in mindset - some refuse, hence they struggle with Git. And then > wrongly blame Git for it. I fear this is most likely what happened with > Florian. That is your very colored view about it, that automatically declares non-gits stupid. However in the last discussion we showed you various faqs (like from LLVM and FreeBSD) that mirrored the FPC core teams. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
emacs! vi! Let's call the whole thing off and use EDLIN. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
On 23/05/17 14:00, Marco van de Voort wrote: In our previous episode, Graeme Geldenhuys said:> As with any new applications or technologies, there is always some > learning curve (big or small). There are tons of bad habits ingrained in > SVN users. Those do not translate well to Git (thank goodness). Git > works fundamentally different to SVN (for the better). So you need a > change in mindset - some refuse, hence they struggle with Git. And then > wrongly blame Git for it. I fear this is most likely what happened with > Florian. That is your very colored view about it, that automatically declaresnon-gits stupid. However in the last discussion we showed you various faqs (like from LLVMand FreeBSD) that mirrored the FPC core teams. One question if I may. Subversion has revision numbers like 12345, and it's comparatively easy to query that and build it into a piece of software's version information. It's also trivial for a developer to look at the revision that he's currently working with, to say whether it's older or newer than revision 12345, and to get a log of what the relative changes were by /only/ knowing the revision number. Now I don't deny for a moment that Git has its advantages for distributed working. But am I correct in my understanding that it has nothing that maps directly onto the monotonic revision list of traditional VCSs including Subversion? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
In our previous episode, Mark Morgan Lloyd said: > Now I don't deny for a moment that Git has its advantages for > distributed working. But am I correct in my understanding that it has > nothing that maps directly onto the monotonic revision list of > traditional VCSs including Subversion? Nope. There is only some hash, and various hacks to emulate with post commit hooks, which is not at all the same in behaviour. some info is at http://llvm.org/docs/Proposals/GitHubMove.html#on-managing-revision-numbers-with-git merging, external repos were some of the other issues. (Potentially) solved issues since the previous discussion were repo dictated configuration (for linefeeds), and the ability to avoid certain branches to have multiple ends (thus leaving the next committer with the unenviable choice to wait or potentially make the situation even more complex). All from memory of ourse. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
On 2017-05-23 15:09, Mark Morgan Lloyd wrote: One question if I may. Subversion has revision numbers like 12345, and it's comparatively easy to query that and build it into a piece of software's version information. And the same is true for Git. By design, distributed version control systems (any of them, not just Git), can't rely on a sequential number. The word "distributed" should say it all. True parallel development; no single "server" instance etc. Saying that, git includes a command 'git describe' which does what you need. I find its result also way more useful and informative that a single sequential revision number - which only has a mean to a developer. Lets use an example: [reportdesigner (reportdesigner)]$ git describe v1.4.1-787-g45f932c1 What does that output tell me: * Whatever code I'm working on is follow on from the "v1.4.1" release. * This line of [development] history has seen "787" commits since the v1.4.1 release. * The "g" prefix indications that the Git revision control system was used. * The "45f932c1" is the SHA1 value of the last commit, that uniquely identifies where we are in the whole history of the project. Irrespective of having 1 or a 1000 branches. Now as with anything Git, everything is configurable. So the git-describe commands has many optional parameters too. So you can change the output to suite your project's needs. Things like should Tag names be used in the git-describe output, or only Annotated Tags, or only Branch names. Do we want the commit count, do we want the "g" prefix, how long SHA1 value do we want etc etc. Many applications incorporate such output in there version information. See attached screenshot of one such example. I've seen plenty of others too. What does a SubVersion revision r20453 tell you? * Which branch are you on? * Which release is this work based on? * Is it a "hotfix" or new feature. * Is it maybe a tag? Though Subversion doesn't really have a concept of tags, as they are just branches in a bad disguise. No, it only tells you that you are using commit number 20453. So now the next thing you are probably going to tell me is that yeah but I can use the revision number in Windows's version numbering as a Revision or Build value. Yes and No. Only if your repository has less than 65535 commits - the maximum a WORD type supports. So what happens if you have more commits that that? Many large projects do. > It's also trivial for a developer to > look at the revision that he's currently working with, to say whether > it's older or newer than revision 12345, As I just explained. The git-describe output tells you that and more. > and to get a log of what the > relative changes were by /only/ knowing the revision number. Nothing new, Git does that too. Git (no surprise) even goes further and also tells you the Parent(s) commit that got you there, the Child/Children commits following on, what branch it is on and what Tags this commit follows. 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 ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
On 2017-05-23 15:23, Marco van de Voort wrote: some info is at http://llvm.org/docs/Proposals/GitHubMove.html#on-managing-revision-numbers-with-git merging, external repos were some of the other issues. Good Lord, who wrote that, and when? Clearly someone with a serious lack of Git knowlegde - just the thing I described 2 replies ago. " However, we propose to mandate making merge commits illegal in our canonical Git repository. " WTF? Branching and Merging are two key feature of Git. So if the don't want merging (or only allow fast-forward merges), I guess they want to Rebase everything everybody contributes - yeah the lovely linear history of SubVersion because they don't know better. 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 ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
On 23/05/2017 16:04, Graeme Geldenhuys wrote: WTF? Branching and Merging are two key feature of Git. So if the don't want merging (or only allow fast-forward merges), I guess they want to Rebase everything everybody contributes - yeah the lovely linear history of SubVersion because they don't know better. Or maybe they haven't forgotten how nice and simple svn is. Git just doesn't do KISS. --- (I use both git and svn, and both have things that I personally miss on the other) But at least this thread is highly amusing, so thanks for that ;) ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
On 2017-05-23 16:17, Martin Frb wrote: Git just doesn't do KISS. Git is as complicated as you want it to be. If you want to use it like SVN, then go right ahead. You will miss out a lot though. I always recommend newcomers to start out with the basic 4-5 commands (same as SVN). Then as your confidence grows, introduce new Git functionality. And contrary to what many may think, it is pretty near impossible to f*ck your repository up so that things are unrecoverable. As long as something was committed, that something can be recovered, or commands can be undone (yes, even deleted branches). Try that with SubVersion! 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 ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
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. With Git, you go to a directory, do "git init" and start committing. Everything is local. Not sure how that's not KISS. (You can add a remote later, and then push to it, with the full history intact. This remote can even be an SVN repo.) Also, you retain the full commit history locally, so you don't need access to the server to get logs, get diffs, etc. Ever tried to work on a project hosted in a centralized VCS, while on a 10 hour plane flight with no internet? Or travelling in another country, where your roaming doesn't work? Also, ever tried to do partial commits in SVN? (Not committing all the changes in a single file.) (git add --patch) Also, ever tried to just make clean build of trunk quickly in SVN then reapply your local, not committed changes? Or try your local changes on another branch without committing them? (git stash) Agreed, Git adds some complexity due to it's distributed nature, and because you don't have nice monotonously increasing revision numbers. But seriously, it makes a billion things much simpler and easier in exchange, especially if one learns to exploit its features for the everyday workflow. It's a tool to manage your source code, even *before* you commit your changes. While SVN is still seen and used by many people as some kind of "incremental source backup". And indeed, it's barely useable for anything more, if we're honest. But as I said, I'm fine with $whatever VCS, I'm not forcing anyone. Heck I still see great software developed in CVS or even without any VCS (that's quite extreme tho', admitted), because no tool can replace a great developer. But great developers know how to make their own life easier. ;) My 2 cents, -- Charlie ___ 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
On 23.05.2017 18:00, Karoly Balogh (Charlie/SGR) wrote: > Also, ever tried to do partial commits in SVN? (Not committing all the > changes in a single file.) (git add --patch) To be fair: at least on Windows that is very easy with the help of TortoiseSVN :) Regards, Sven ___ 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
In our previous episode, Karoly Balogh (Charlie/SGR) said: > > Git just doesn't do KISS. > > You need an SVN server to start working with SVN. With Git, you go to a > directory, do "git init" and start committing. Everything is local. Not > sure how that's not KISS. (You can add a remote later, and then push to > it, with the full history intact. This remote can even be an SVN repo.) The previous discussions were about team use of GIT, to be specific, FPC core repo. The problem is that if problems get practical the advocatists suddenly step back and aren't really able to do more than regurgitate either the standard beginner "wisdoms" or "you shouldn't want this" or "this is the new improved ways" or similar platitudes. To get get back on track, I'll restate the question I posed in the last message unambigously: how to avoid that a push of member X doesn't leave a branch in an undesirable state that leaves member Y three choices: 1. push anyway and make the mess worse 2. hold the commit/push 3. clean the mess himself. In your own repository that is no problem, and even in companies this only takes only a few LART/cluebat applications to fix. However in distributed teams this is a pain. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
Hi, On Tue, 23 May 2017, Florian Kl?mpfl wrote: > Every tried: > > C:\temp>svnadmin create repos > > C:\temp>svn checkout file:///c:/temp/repos wc > Checked out revision 0. > > ? No, nice to know this works, thanks. However, then if you try to publish this repo outside of your computer, it gets a bit hairy. (Nothing unsolvable, but nothing which I would describe as KISS anyway.) > > 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). Yes, TortoiseSVN makes this bearable, this was more or less the only reason I used a Windows 7 box + Linux VirtualBox combo for development at the last company which used SVN. :) But it's not the feature of SVN as such. Charlie ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
Hi, On Tue, 23 May 2017, Marco van de Voort wrote: > The problem is that if problems get practical the advocatists suddenly step > back and aren't really able to do more than regurgitate either the standard > beginner "wisdoms" or "you shouldn't want this" or "this is the new improved > ways" or similar platitudes. > > To get get back on track, I'll restate the question I posed in the last > message unambigously: > > how to avoid that a push of member X doesn't leave a branch in an > undesirable state that leaves member Y three choices: How to avoid that member X with commit write access doesn't leave a branch in SVN in an undesirable state? :) You have to trust people, and choose who you give write access to a given branch/repository, really. This didn't really change and not an argument against git. And well, in Git you don't push, but people who want to contribute, have a pull request. Then you can review that, and either apply to your tree or reject it. It's important to understand that in git all repositories are equal, and that I have a "make-amiga-great-again" branch, doesn't mean that you should have it, I could still send a pull request against your master branch, or whatever branch. All pull requests are just a set of changes, really. > 1. push anyway and make the mess worse > 2. hold the commit/push > 3. clean the mess himself. Well, ideally in distributed teams, people don't push, but have a pull request. Basically as crazy as it sounds, everyone forks the project all the time, but then you have a set of tools to reintegrate all those forks easily. It's the responsibility of the maintainer of a given branch to accept that pull request or not, or request further changes before its accepted. > In your own repository that is no problem, and even in companies this only > takes only a few LART/cluebat applications to fix. However in distributed > teams this is a pain. No, it isn't. This is the primary problem git solves, actually, by making it possible for everyone having their own sandbox to play with, and you have a review filter before accepting changes. You can even sign off changes by a maintainer, who reviews the code. All those messy branches remain local if they're not approved, on the person's computer who messed it up, they don't have to go global/upstream... And talking about myself - as much as I enjoy just committing my crap to trunk, I sometimes would really prefer review. Not because I'm not a senior engineer, but especially because of that... Now if I don't want to do a branch in SVN which are huge and expensive (Git branches are cheap and small), I either have to commit it first anyway to trunk, then ask for a review, or send a patch for review first in e-mail, which is quite cumbersome. Plus there's absolutely no warranty, that I later commit the same patch which was reviewed. At work, I don't even push against master, but I do a pull request against my own repository, and ask one of my senior colleagues to review... I don't know about you, but to me this sounds a lot more like teamwork, than going around beating up people "for wrongdoing" with a cluestick. Of course in the end it's just like crypto - you need to have a chain of trust from the top, a group of trustees who will do the actual merging of the pull requests, reviews and then push it upstream/mainline/trunk. If one of these maintainers do a bad job, then you need to sort out that problem, but that doesn't mean the whole system is broken. It's similar to giving commit access to a developer who doesn't deserve it in SVN, really. 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. Was this a proper answer, or I was beating around the bush in your views? :) Grmbhl, -- Charlie ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
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. Or even how Git's development itself is managed. True distributed workflow models. 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 ___ 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
Hi, On Tue, 23 May 2017, Karoly Balogh (Charlie/SGR) wrote: > > To get get back on track, I'll restate the question I posed in the last > > message unambigously: > > > > how to avoid that a push of member X doesn't leave a branch in an > > undesirable state that leaves member Y three choices: > > How to avoid that member X with commit write access doesn't leave a branch > in SVN in an undesirable state? :) You have to trust people, and choose > who you give write access to a given branch/repository, really. This > didn't really change and not an argument against git. > > And well, in Git you don't push, but people who want to contribute, have a > pull request. Then you can review that, and either apply to your tree or > reject it. It's important to understand that in git all repositories are > equal, and that I have a "make-amiga-great-again" branch, doesn't mean > that you should have it, I could still send a pull request against your > master branch, or whatever branch. All pull requests are just a set of > changes, really. Ok, to put this into practical example: lets say some idiot decides to do a Webassembly codegenerator for FPC. This idiot starts working on his working copy, but quickly loses track... So he wants to start committing his changes. But in SVN, this idiot has to either: A., create a Webassembly branch and start committing there, polluting the global SVN repository forever, even if he's demotivated after 5 commits, and never touches that branch again. (...) B., keep his changes in his working copy forever, getting in the way of other changes, and causing endless conflicts with changes coming in from trunk. C., keep two working copies, in case he want to work on something else meanwhile, and want to avoid accidental commits (D., use git-svn, and create a local only branch - sic!) Now, in Git, this idiot can do: 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. 2., If he wants to involve others, he can publish his whole repository as FPC-Webassembly project, independently from the main repository he forked, and get others working on it. At this point his repository acts like an independent fork of the compiler. 3., If his project succeeds (independent from the number of people worked on his fork), then he can issue a pull request, while asking a review from seniors on the FPC project. He can still do the changes requested from him on his own repo, and commit them easily. 4., He can still sync his own repository with ease with the main FPC project. So he can be sure when he sends his pull request, it will merge seamlessly against the FPC master. (And this is in fact should be expected from him.) From the two above, I would go for the Git option. Because we're already stuck with the first one in SVN, and it's not good. ;) The bigger picture is, that I can do the SVN branch, because I had write access to the SVN. But people without commit access, can't. So this also makes difficult from people independent from the project work on larger scale changes on their own... Or if they still do (hello NewPascal!), because git-svn allows them, it's difficult for us to integrate their changes back... Charlie ___ 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
In our previous episode, Karoly Balogh (Charlie/SGR) said: > > how to avoid that a push of member X doesn't leave a branch in an > > undesirable state that leaves member Y three choices: > > How to avoid that member X with commit write access doesn't leave a branch > in SVN in an undesirable state? :) You have to trust people, and choose > who you give write access to a given branch/repository, really. This > didn't really change and not an argument against git. Trust is that people are not deliberately doing things. For accidental things there are tools (except GIT, apparently) > And well, in Git you don't push, but people who want to contribute, have a > pull request. Then you can review that, and either apply to your tree or > reject it. It's important to understand that in git all repositories are > equal, and that I have a "make-amiga-great-again" branch, doesn't mean > that you should have it, I could still send a pull request against your > master branch, or whatever branch. All pull requests are just a set of > changes, really. Yeah, blabla, distributed, anarchy, world domination. I though I did mention I wanted practical info? > > 1. push anyway and make the mess worse > > 2. hold the commit/push > > 3. clean the mess himself. > > Well, ideally I was not asking for ideally. I was asking very specifically how a GIT in a FPC team group would work. And no, sending 40+ pull requests to all members of core does not count. So there is one golden repo and that is what I'm talking about. > easily. It's the responsibility of the maintainer of a given branch to > accept that pull request or not, or request further changes before its > accepted. So tool failure is fixed by throwing manpower at it? We don't have an approval person now, so a requirement to that would IMHO be a dealbreaker for GIT. > And talking about myself - as much as I enjoy just committing my crap to > trunk, I sometimes would really prefer review. Not because I'm not a > senior engineer, but especially because of that... Now if I don't want to > do a branch in SVN which are huge and expensive (Git branches are cheap > and small), I either have to commit it first anyway to trunk, then ask for > a review, or send a patch for review first in e-mail, which is quite > cumbersome. Plus there's absolutely no warranty, that I later commit the > same patch which was reviewed. I would like to have lots of extra manpower too, but I rather not spend it on what in practice would be rubberstamping commits (and delays in distribution till something is approved if the reviewers are AFK). This is exactly what I wanted to avoid with the primary case posed in this subthread: how to avoid blocking the central repo for commits (from a practical viewpoint) > At work, I don't even push against master, but I do a pull request against > my own repository, and ask one of my senior colleagues to review... I > don't know about you, but to me this sounds a lot more like teamwork, than > going around beating up people "for wrongdoing" with a cluestick. Then you don't understand what I mean. In the job you go see the person, work something out, and problem sorted in a few minutes. The odd impossible person is usually swiftly dealt with. In distributed, volunteer driven, projects, people are away/nonresponsive for extended periods of time, working hours (and days) don't match. Also working this out via mail is much less productive. > Of course in the end it's just like crypto - you need to have a chain of > trust from the top, a group of trustees who will do the actual merging of > the pull requests, reviews and then push it upstream/mainline/trunk. If > one of these maintainers do a bad job, then you need to sort out that > problem, but that doesn't mean the whole system is broken. It's similar to > giving commit access to a developer who doesn't deserve it in SVN, really. I know what an honor-system is. It doesn't protect against mistakes the day before holiday. Remember the old locking VCSes ? > 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. > > Was this a proper answer, or I was beating around the bush in your views? > :) Sorry to say, but I didn't find anything new or usable in this post. It is the standard "think different" nonsense from a very idealist viewpoint, little practical details. So I now give up this thread (and GIT). ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
Hi, On Tue, 23 May 2017, Florian Kl?mpfl wrote: > > 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 I see your point Florian, but at least LLVM seems to have a Git gateway these days, and they documented how to contribute using Git, while they can keep their upstream SVN. http://llvm.org/docs/GettingStarted.html#sending-patches-with-git And the same with GCC: https://gcc.gnu.org/wiki/GitMirror The important fact to see is Git allows people do their own branches (local branches, of course) and forks much easier/cheaper in a way, which also makes easier to contribute their changes back to the main project they originally forked. This part is at least is independent from the nature of the software developed, and the poIitics involved, I think. Charlie ___ 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:24 schrieb Karoly Balogh (Charlie/SGR): > Hi, > > On Tue, 23 May 2017, Florian Kl?mpfl wrote: > >>> 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 > > I see your point Florian, but at least LLVM seems to have a Git gateway > these days, and they documented how to contribute using Git, while they > can keep their upstream SVN. > > http://llvm.org/docs/GettingStarted.html#sending-patches-with-git > > And the same with GCC: > > https://gcc.gnu.org/wiki/GitMirror So first problem identified: no git mirror of the full 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
Hi, On Tue, 23 May 2017, Marco van de Voort wrote: > Trust is that people are not deliberately doing things. For accidental > things there are tools (except GIT, apparently) Err...? :) The only way to can fuck up a remote Git repository is by force pushing, if you have write access already. But you can disable force pushing even for people with write access. (Which is advisable.) > I was not asking for ideally. I was asking very specifically how a GIT in a > FPC team group would work. See my other mail. > > At work, I don't even push against master, but I do a pull request > > against my own repository, and ask one of my senior colleagues to > > review... I don't know about you, but to me this sounds a lot more > > like teamwork, than going around beating up people "for wrongdoing" > > with a cluestick. > > Then you don't understand what I mean. In the job you go see the person, > work something out, and problem sorted in a few minutes. The odd > impossible person is usually swiftly dealt with. Honestly, I can't even... You sound like the Expert Beginner Twitter account. No personal offense intended, but you just do. > In distributed, volunteer driven, projects, people are away/nonresponsive for > extended periods of time, working hours (and days) don't match. Also working > this out via mail is much less productive. So it's much more productive to just give everyone commit access to the main repo, and let it being polluted with random branches? Or anyone who wants to contribute but not with FPC for years, should keep working on his working copy (with no ways to commit) and then submit a .diff via Mantis? (Well, people are smarter than that, fortunately, so they just use git-svn. Whatever.) > Sorry to say, but I didn't find anything new or usable in this post. It is > the standard "think different" nonsense from a very idealist viewpoint, > little practical details. Err, see my other mail about a practical example. > So I now give up this thread (and GIT). You should try to use it. For once. With an open mind. I know it's hard. Charlie ___ 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
Hi, On Tue, 23 May 2017, Florian Kl?mpfl wrote: > > 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. *shrug* As I said, I'm fine with it anyway, whatever. But I can see the practical reasons for Git, and see the reason why people would want it. And I came a *lng* way to admit that. In late-2009 early-2010 I sounded more anti-Git than Marco. :) Charlie ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
On 2017-05-23 21:05, Florian Klämpfl wrote: FPC is a compiler and not an OS kernel, so would like to see such blog posts from big compilers: e.g. gcc, clang OS Kernel, Compiler, any other project - what's the difference. Git development itself is managed in a very "distributed" way with multiple branches, maintenance releases etc. And more impressively, all branch merging is done by a single person. Their processes are quite well documented, and if you see how active the Git development is, it goes a long way proving that even a very active project can be managed by very few (one in this case). My point is, you can learn from them to see how a project can be managed without adding extra work-load to one person or a small team (like FPC). 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 ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
On 2017-05-23 21:10, Karoly Balogh (Charlie/SGR) wrote: Now, in Git, this idiot can do: Plus that idiot could start the fork and his branch without needing to bother the FPC team. With SVN he has to ask them to add him to the SubVersion repo user list, create a branch, and manage his user permissions for that branch. Git = KISS is this case. ;-) 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 ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
On 2017-05-23 21:16, Florian Klämpfl wrote: ... and the code is lost :) Not at all, I have about 20+ local branches in my fpGUI repository. Some branches date back to 2009, 2010. Ideas I had, but lost motivation, or they were simply an experiment (that could be useful at some point). Just 2 days ago I revived a 5 year old branch and finally completed the work. I didn't pollute the public fpGUI repos because it was personal ideas or features I toyed with. They are in various incomplete stages, or simply experiments. I don't want others to see such work until my ideas have matured. On the flip side, in the past I have seen newsgroup posts where somebody has similar ideas to one or two of my incomplete branches. In such cases I speak to that person and if interested, I publish such a branch to begin collaboration. 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 ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
On 2017-05-23 04:23, Graeme Geldenhuys wrote: On 2017-05-22 23:11, nore...@z505.com wrote: What happens if you use the SVN bridge that allows you to run svn commands to a git server? Maybe your wording is confusing, or SVN has abilities I didn't know of. I know Git can manage SVN repositories, but I didn't know it was possible other way round (I doubt it is possible). I use it every day. When I hired someone for a bounty, he introduced me to it, and I have been using it ever since :-) p.s. Thanks Dmitry! ;) It's my stubborn old practice of not wanting to learn a new tool, Git, when SVN was working quite fine for my needs, but I do admit I don't have experience working with thousands/hundreds of developers all on the same repo, I more use it for my own need. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
On 2017-05-23 04:23, Graeme Geldenhuys wrote: On 2017-05-22 23:11, nore...@z505.com wrote: What happens if you use the SVN bridge that allows you to run svn commands to a git server? Maybe your wording is confusing, or SVN has abilities I didn't know of. it may just be a github thing, I'm not sure. Not git, possibly, but github has an SVN bridge that allows you to treat a github repo just like an SVN repo, and run svn commands. I use total commander for most of my SVN work with tortoise svn, which sounds like I am some kind of newbie/beginner since I don't use command line much, but it serves my need very well visually committing which files I need, which IMO is faster and more productive than running 5 different commands on files I have to manually type in or keep pressing the up arrow to repeat old commands (seems like 1970's way of doing things on unix, which I avoid) But I guess that is another issue. The point is that github does in fact allow you to treat a github repo like an SVN one, so I wondered if Florian had tried this - but I guess you might as well use SVN if you are going to make github "like svn" instead of actually being svn. Key advantage: use github awesome web interface gui, plus have svn like revision... IMO the big success of git is not git, but the github website which is visually stunning, beautiful, and productive - along with being a great social tool (although, I'm not so social). Only gripe I have about github is the fact that you cannot search forks! Searching forks on their website is essential for finding other people's code, and you cannot do that. you can't search any forks??? wtf.. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
On 2017-05-23 09:01, DaWorm wrote: emacs! vi! Let's call the whole thing off and use EDLIN. Don't forget mg https://www.google.ca/search?q=mg+micro+gnu+emacs From what I remember, this one had some nice simple C source code instead of bloated projects.. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
On 2017-05-23 17:33, Graeme Geldenhuys wrote: On 2017-05-23 21:10, Karoly Balogh (Charlie/SGR) wrote: Now, in Git, this idiot can do: Plus that idiot could start the fork and his branch without needing to bother the FPC team. With SVN he has to ask them to add him to the SubVersion repo user list, create a branch, and manage his user permissions for that branch. Yes but forking is a double edged fork (sword)... You can fork so easily that no one actually works together and then you have 218982 versons of emacs floating about that no one actually uses, because so many forks splits up the userbase and then everyone just ends up using a central version of emacs, the main copy Git = KISS is this case. ;-) Everyone making thousands of forks and not working together is not simpler, it's just a different way I like the ability to fork, as I am sick of developers not allowing me to make some change, and I go off and work myself on some fork but.. it's also anti-social and leaves projects in so many forks that no one works together. Everyone forks github repos and then you cannot search the damn code on github, as forks are not searchable - so no one can find good updated code, you just see the main git repo, which, is kind of like having a central svn repo! but with thousands of stale forks??? ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
You need an SVN server to start working with SVN. With Git, you go to a directory, do "git init" and start committing. Everything is local. Not sure how that's not KISS. (You can add a remote later, and then push to it, with the full history intact. This remote can even be an SVN repo.) I'd rather upload/commit files to a server to insure it is backed up properly... What happens if your hard drive becomes corrupted and fails, with a local git? This has happened to me so many times, hard drives have failed on me (no knock on wood) But I'm not so familiar with git so wonder what happens. Don't you eventually have to start uploading to a server anyway, at some point? As you cannot trust a hard drive. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
On 2017-05-23 15:36, Karoly Balogh (Charlie/SGR) wrote: > At work, I don't even push against master, but I do a pull request > against my own repository, and ask one of my senior colleagues to > review... I don't know about you, but to me this sounds a lot more > like teamwork, than going around beating up people "for wrongdoing" > with a cluestick. Then you don't understand what I mean. In the job you go see the person, work something out, and problem sorted in a few minutes. The odd impossible person is usually swiftly dealt with. Honestly, I can't even... You sound like the Expert Beginner Twitter account. No personal offense intended, but you just do. He's talking about Army of Programmers in a Building, an article I wrote years ago ;-) Sometimes it's better to just walk over and talk to a real programmer in a real building than it is to send some email over the christmas holidays and wait 2 weeks for a reply for him to commit his changes.. since he's in Barbados or Cuba on vacation. With Army of Programmers in a Building you can just go and knock on his door, or his cubicle, instead of this pathetic thing called Email. The disadvantage of working in the same town/building as someone, though, is that they may always be bothering you non stop and tapping on your shoulder, but not really since programmers aren't that obnoxious, AFAIK This development on the internet across multiple countries has some massive disadvantages to something like the Microsoft Campus where you can go over and knock on the guys door, or at Borland (although, they are hiring people offshore AFAIK now) And sometimes typing out a long email takes time, instead of just being able to speak in real time to a real person - an email is like a fixed essay, whereas a conversation is in real time, instant. They have IRC for this, I guess, but that becomes addictive and wastes lots of time, IMO, and you don't get as much work done if you are chit chatting nonstop on irc/icq/message systems ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
On 2017-05-23 17:41, Graeme Geldenhuys wrote: On 2017-05-23 21:16, Florian Klämpfl wrote: ... and the code is lost :) Not at all, I have about 20+ local branches in my fpGUI repository. Some branches date back to 2009, 2010. Ideas I had, but lost motivation, or they were simply an experiment (that could be useful at some point). Just 2 days ago I revived a 5 year old branch and finally completed the work. But what happens with corrupted or failed hard drive on your personal computer? Do you have any backups or is this local git work only on one personal hard drive that could fail at any time? Sorry, I've just had too many hard drives fail on me... so many fail that it's almost as if someone was doing it on purpose to me. Do you make some backups on a usb stick or some server elsewhere no one can see? ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] [fpc-pascal] FPC Graphics options?
On 2017-05-22 18:53, Graeme Geldenhuys wrote: On 2017-05-22 23:39, nore...@z505.com wrote: What about Rust or plain C? Or Digital Mars D? I hate C with a passion. I'll never code in that ever again. Pascal and C are actually twin brothers with slightly different syntax... But my biggest hate for C is not C itself but just the one fact that it lacks strings. Without strings, a language is headed for the graveyard, IMO. Counting pchars in your head is just a waste of brain power.. The C struct is literally the pascal record, and is all based on the same Structured Programming work by Dijkstra ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] [fpc-pascal] FPC Graphics options?
On 2017-05-23 01:03, Nikolay Nikolov wrote: Isn't java just a wrapper around C? No. Java compilers generate code for a virtual machine, called JVM (Java Virtual Machine). They do not generate code for x86 CPUs or any other ...snip... But the virtual machine is just C code, so it's a wrapper around C, IMO I could be wrong, but, all it does is end up calling C written VM, right? ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
[fpc-other] How do you keep up with FPC discussions?
I can't find enough time in the day to read even one single email list (fpc-pascal), let alone two, or more.. How in the world do people (you) keep up with reading email lists and not waste the entire day? It seems some of you have super human powers that I don't have, to be able to both program, and email, and read email, and cook/work. I can barely keep up with one email list, and fpc is not even that popular of a list compared to others... Maybe I'm a retard and my brain is slow, but how the f**k do you keep up with all these emails and have any time for programming, cooking, working, hiking, possibly a relationship with opposite sex? There is just no time. I'm positive that some of you are just clever A.I. bots posing as humans.. that's where your super powers come from. You're not actually humans.. Reason for posting this to fpc-other: obvious. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] [fpc-pascal] FPC Graphics options?
On 2017-05-22 18:39, Graeme Geldenhuys wrote:
On 2017-05-22 22:45, nore...@z505.com wrote:
The amount of nesting and indented procedures inside classes in Java
is
horrible, IMO.
It's not a Java language issue, but the indent preference of the
developer. Many Java IDE's support multiple coding styles and does
auto-formatting as you type or save. Some coding styles are better
than others, and all of them are configurable.
Regards,
Graeme
I'm not just talking about 8 space indentation vs 4 space or 2, I mean
having to put code
{
{
{
here
Instead of fpc/oberon/golang:
func {
code here
or
procedure TSomeObj.Example
begin
code here
instead of
...
...
...code here
Just to do basic bloody damn things, Java and C# require ridiculous
obnoxious nests/indentations.
No talking about 2 vs 8 space indentation choices, although that's
another issue
___
fpc-other maillist - fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] [fpc-pascal] FPC Graphics options?
On 05/23/2017 09:56 PM, nore...@z505.com wrote: The C struct is literally the pascal record, and is all based on the same Structured Programming work by Dijkstra except that the C struct does not have the array length at position zero and you have to process until you hit the first null character... that's the plus for pascal strings... you know how long the string is from the start... unless it is a unicode string ;) -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] [fpc-pascal] FPC Graphics options?
On 05/23/2017 09:52 PM, nore...@z505.com wrote: Just to do basic bloody damn things, Java and C# require ridiculous obnoxious nests/indentations. > No talking about 2 vs 8 space indentation choices, although that's another issue i'm guessing that you haven't played with python where indention is a major aspect of the language ;) -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] [fpc-pascal] FPC Graphics options?
On 5/23/2017 7:19 PM, wkitt...@windstream.net wrote: > On 05/23/2017 09:56 PM, nore...@z505.com wrote: >> The C struct is literally the pascal record, and is all based on the >> same Structured Programming work by Dijkstra > > except that the C struct does not have the array length at position > zero and you have to process until you hit the first null character... > that's the plus for pascal strings... you know how long the string is > from the start... unless it is a unicode string ;) > Well, the problem is that you can't use those handy Pascal strings that much anymore these days. Ever since you need to use UTF8 to properly represent textual context, this all has become one hell of a mess, pretty leveling the playing field when it comes to handling such strings with (Free)Pascalor C... Ralf --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
On 2017-05-23 21:19, Marco van de Voort wrote: I was not asking for ideally. I was asking very specifically how a GIT in a FPC team group would work. And no, sending 40+ pull requests to all members of core does not count. So there is one golden repo and that is what I'm talking about. And like I explicitly said, read the well documented processes followed by the Linux Kernel or on a much smaller scale, the Git development itself. I would like to have lots of extra manpower too, but I rather not spend it on what in practice would be rubberstamping commits (and delays in distribution till something is approved if the reviewers are AFK). Once again, read how the Git project deals with it. That workflow could suite FPC quite well. 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. If you don't know, a octopus merge is a single merge command but merges 2+ branches all in one go. eg: git checkout master git merge feature1 feature2 feature3 feature4 feature5 ...where "featureX" is a branch name. Unlike SubVersion, you don't waste a whole day "rubber stamping" commits. Such micro-management doesn't exist in Git. Git was designed to work better that SubVersion, and specificall at branch management and merging. Hence my earlier WTF comment when I read the LLVM team want- to ban merge commits! That person clearly has no f**ken idea how Git works. In distributed, volunteer driven, projects, people are away/nonresponsive for extended periods of time, working hours (and days) don't match. Also working this out via mail is much less productive. Then simply don't pull or merge their work. Simple as that. Once again, you are thinking in terms of SubVersion. Don't! You don't see the Linux Kernel project come to halt when somebody fucks up a commit - they just don't merge that commit or branch until the idiot fixed his work. And neither do they have communications problems via emails or the mailing list - they have tens of thousands of contributors spanning the globe. So I don't understand why you think such a small project like FPC will have communication issues. That's just laughable. Sorry to say, but I didn't find anything new or usable in this post. Actually, it's only your stubbornness showing. I thought Karoly's reply was very informative. 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 ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
