Re: [fpc-other] Lists and wiki down?
Hi, On Mon, 1 Jun 2020, St?phane Aulery wrote: > Tonight I tried to register with user "LkpPo" and was always defeated by > the CAPTCHA. After some times I reloaded the page to try again from the > beginning. After that, lists.freepascal.org and wiki.freepascal.org are > down (connection failed). > > After I have destroyed my cookies these website stay offline for me. I > wonder if it's me or if it's general. > > I wanted to edit a few pages because I am testing the 3.2.0-rc1 release. Lists and wiki are the same machine, so you probably tried too agressively to "hack" your way in, and you're caught by our Fail2Ban installation, which blacklisted your IP for bombing the machine with requests and too many auth failures. The machine is still up and running w/o problems as far as I can tell. Sorry for the inconvenience. If you send me your IP in private. I might be able to try to un-blacklist it. Can't remember how soon the ban is lifted automatically otherwise. Charlie ___ fpc-other maillist - fpc-other@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] How do you keep up with FPC discussions?
Hi, On Wed, 24 May 2017, Nikolay Nikolov wrote: > > 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.. > Hahaha, you got that right! That's my secret! :) For the record, I met him in person already, and I can confirm this. :) Charlie ___ 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?
Hi,
On Wed, 24 May 2017, Nikolay Nikolov wrote:
> Yes, this is one of the horrible things I have beef with. I have several.
> ()
> 2) the fact that the array size is not exactly part of the type. In case
> you're wondering what this means, if you declare:
>
> int a[5];
>
> sizeof(a) gives you the correct size of the array. However, if you pass
> this array as a parameter to a function:
>
> void func(int array_param[5])
> {
> // inside the function, sizeof(array_param) gives you the size
> of a pointer, and not the array size
> }
>
> That's one of the reasons you can't add range checking to C compilers.
Ah, I love this. :) Thanks for this, I didn't know. Will put it on my
list. :)
> this is bad language design. Bonus points for the fact that writing this
> ugliness:
>
>if (5 == i)
> do_something();
>
> is considered a very good practice by some people, just because it
> prevents you from being burned if you write if (5 = i) instead :)
These are nicknamed Yoda conditions. :)
> 4) the badly designed standard library. Even though C "strings" suck by
> design, the library functions, that operate on them have extra hidden
> traps. For example, using strcpy is unsafe, because it doesn't check the
> size of the destination buffer, that's why you must use strncpy.
> However, this code:
>
> char dest[1000];
> strncpy(dest, src, sizeof(dest));
>
> is still unsafe. Why? Because if src is 1000 characters or larger, even
> though strncpy will not overwrite past the end of the dest array, it
> will _not_ put a null terminator in the dest array. On top of that, it
> is also suboptimal - if src is shorter, strncpy will fill the entire
> array past the end of the string with null characters. So, if src is a
> 10 character string, strncpy will write 990 null characters, filling the
> area between dest[10] and dest[999], wasting CPU cycles on that.
OK, this is also beautiful, thanks again. :) BSDs seem to have strlcpy()
tho', which works around both defects mentioned here, but that's non
standard obviously, because who needs standard functions which make sense.
:)
Charlie
___
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?
Hi, On Tue, 23 May 2017, nore...@z505.com wrote: > Pascal and C are actually twin brothers with slightly different > syntax... Fortunately, they really aren't. :) And this goes both ways. > But my biggest hate for C is not C itself but just the one fact that it > lacks strings. Strings are a library feature, with syntax sugar on top of it. Nothing stops you to implement Pascal-alike strings in C, minus the syntax sugar. In fact I'm willing to bet, there are some libs out there already, ready to be used. In fact, see what someone wrote about UTF-8 later in the thread, pretty sure you can just pull in an UTF-8 string library in your project and run with it... There are a bunch of things in C, which are a lot more WTF. 1., no standard way to determine the length of an array compile time. sizeof() returns the length in bytes, not the number of elements. Basically you have to do sizeof(array)/sizeof(elementtype), where the elementtype has to be the same as when you declare an array. 2., I cannot make an enum type, and make an array which matches that enum type, and has the same number of elements, other than arbitarily defining the "max" item in an enum (no low()/high()/length(), etc). Same with standard types, actually (talking about things like array[boolean] of ). Also, the compiler makes no checks that if indexing this array[type] is out of bounds when used. This single thing alone makes it super robust to write all kinds of low level Pascal code, when used properly. Which is of course also possible in C, but you don't get the safety-net of the compiler/language, so you end up writing a billion tests for all kinds of edge cases, which cannot even happen in Pascal. 3., While we're at enums, the size of enumeration type is not defined, except it's "int" which varies wildly from platform to platform. Which means if you cannot really have enumeration types in structs which are involved in I/O, otherwise you're up for surprises. There are ways around this, but it's very cumbersome, so usually people just go "whatever" and hardwire an int type of arbitary size instead. But then again, you lose all kinds of compiler checks. 4., The whole weakly typed thing. You can have all your types defined, but when you mess up, the compiler just says "well okay" (even with -Wall), especially when you pass around various pointers, and you end up scratching your head, what makes your code explode. I'm working as an embedded software engineer these days, in C/C++, these were the just the things I ran into recently. Strings are the least of the problem, when it comes to defining an architecture in C in a safe/sane way. :) Charlie (Ps: BTW, fixme on any of the above, I don't even claim I'm good at C, so at least I learn something. Also, I know C++ fixed some of these, which is among the reasons why people stick to a subset of C++. "C with classes", as they say, I say, it's "C with classes and stronger typing." ;) ) ___ 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 Wed, 24 May 2017, Graeme Geldenhuys wrote: > If the Free Pascal team is ever serious about migrating to Git, I'll > happily help out with the migration process. Well, I think the resistance is too big for the migration. The SVN people go full berserk bloodbath mode when Git is mentioned, and Git people usually go "whatever" and just use git-svn. :) But. If we could come up with a way, which allows accepting pull requests with Git somehow (thinking about Github, specifically, but in general), then have them seamlessly integrated into upstream SVN as they're accepted, that would maybe move things forward. (Remember, we even have an FPC organization on Github, which we can utilize.) With the more automated verifications regarding the integrity of the SVN the better. But Marco was right on the point, that this needs a very very carefully designed plan and process, to not screw up the upstream SVN. Maybe what LLVM and GCC has in place can serve as a starting point. And to be honest, I wouldn't even have the full SVN mirror "published" in Git, only trunk, and branches fixes_3_0 and newer, with the later being read only, as merges would happen by the maintainer, in SVN. So yeah, TL;DR: instead of trying to fix people we could use engineering to make the technology just serve us all. :) 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 Wed, 24 May 2017, Graeme Geldenhuys wrote: > Back in 2009 (I think it was) when I created Git mirrors of FPC and > Lazarus, I initially did it with all branches and tags in place. It took > long, but there was no roadblocks. I think the claim was, after the svn 2 git conversion, some commits were missing from the converted repo, at least the one the FPC Team had internally. As in, the history wasn't complete. Not sure what that means though, or which commits, commits of which nature, or why. Maybe Florian can ellaborate on this. 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, 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
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
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
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
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
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] $100, 000 for C++ implementation of FPC's -CR option
Hi, On Fri, 14 Aug 2015, Nikolay Nikolov wrote: On 08/13/2015 11:47 PM, Jonas Maebe wrote: http://it.slashdot.org/story/15/08/13/1229239 In all fairness, they also optimise it so that they emit fewer checks (if you check whether X of the correct type in one statement, you may not have to check it again in the next etc) and hence reduce the run time overhead. Still... :) Well, now all they need is a decent equivalent to Pascal's units (instead of relying on preprocessor hacks such as #include), Meet the C(++) Modules proposal: http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf I think CLang/LLVM already implemented it. http://clang.llvm.org/docs/Modules.html Almost like Pascal's units. :) Although they don't include namespaces and not intended for binary distribution. Charlie ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
