Re: [fpc-other] Git & SVN
On 05/25/2017 01:44 AM, Graeme Geldenhuys wrote: On 2017-05-24 21:21, Marco van de Voort wrote: Even a limited change is already a massive operation, let's keep it managable. So how large is the FPC team really? I'm talking about active developers on a day-to-day basis who have commit access to Trunk. Oh wait, I can answer that very accurately myself... using git. $ cd /data/devel/fpc-3.1.1/src [src (master)]$ git shortlog -s -n --since=4.months 191 Michael Van Canneyt 147 Mattias Gaertner 140 nickysn 83 svenbarth 73 Florian Klaempfl 62 pierre 52 Joost van der Sluis 39 maciej 30 karoly 26 Marco van de Voort 23 Jonas Maebe 22 yury 7 lacak 5 marcus 3 Sergei Gorelkin 2 hajny So that's 16 developers - a nice size, but also not a large team (say compared to the KDE project that moved from SubVersion to Git, or LLVM seeing as that was mentioned earlier). The amount of commits are also not huge - so they most likely have a day job. ;-) And the two developers with the most commits (by a large margin) work primarily in the RTL and FCL. That's development work like any other project I have worked on. Nothing special or "rocket science" about that (sorry Florian). As for the 3rd person "nickysn"... I see he/she actually worked on the compiler/* tree. How do I know this? $ git log --name-only --oneline --since=2.months --author=nickysn Actually, that's me and I'm surprised I'm topping the list. Maybe that's because I'm still using plain old subversion, instead of git-svn, which forces me to commit my changes, instead of keeping them in a half-baked state, in a local branch of a local repository. :) Maybe it's also worth mentioning that I actually dislike git. Previously, I didn't care, but now I contribute to some other projects, which use git and I'm constantly annoyed by the extra complexity and having the source control system stand in my way and preventing me from doing actual work. Randomly picking some other authors, it seems most work is primarily in the RTL and FCL. A few small exceptions like Sven and Florian who mostly work in the compiler tree. So this definitely doesn't convince me that compiler development is so different to other projects. And definitely doesn't rule out that Git couldn't work, or that an improved workflow couldn't be applied (freeing up time in the long run). The problem is: the current FPC development model is working fine. There's nothing wrong with it. You're pushing git as a solution to a problem that doesn't exist and promising we'll see the light, as soon as we apply your solution. 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. Of course, we are. There's nothing wrong with that. We have a solution that works and that's fine. Why do you want to persuade people to use git so much? Does it bother you so much that people are using a tool that you aren't using? Here's an analogy of how the git bible-thumping looks to a subversion user: Are you driving a car? I don't know whether you do or not, but let's suppose you are, for the sake of argument. Why don't you switch to a truck? It has many advantages over the car - everything you need to carry with a car, you can carry with the truck. Sure, it takes more time to learn how to drive it and to acquire license for it, but it's a worthy skill, since it'll make you a better driver. And as soon as you need to move a lot of stuff, you'll love the fact that you learned how to drive it and bought it. And sooner or later, it happens to everyone to have to move a lot of stuff. So, I don't understand why people are still using cars. They make no sense - they are too small and therefore, useless. I simply can't see why anyone would want something more lightweight. But you're living in a big, crowded city, with lots of small streets and you're not really carrying all that much with your car, you're only using it to go to work, so you think you don't need a truck? But these advantages only exist in the minds of the car owners - you can drive a truck in the city as well in more than 99% of the streets, where you can drive your car. And in traffic jams, it's only going to be 1-2% slower. And, if you're driving in an area, where it's not appropriate to drive a truck, but you can drive a car, this is a sure signal that you're doing driving wrong. If you have to drive small city streets it's better to leave your truck at home and walk instead. Cities are for walking, not for driving. But you like the option of driving 3 or 4 people? That's yet another misconception car drivers often have, which is a sure symptom they've never owned a truck and their mind works in an car-focused, truck-unaware, unenlightened way. In fact, you can easily fit a lot more people in the truck. You just put benches in the cargo area. I hope
Re: [fpc-other] Git & SVN
In our previous episode, Graeme Geldenhuys said: > On 2017-05-24 21:21, Marco van de Voort wrote: > > Even a limited change is already a massive operation, let's keep it > > managable. > > So how large is the FPC team really? I'm talking about active developers > on a day-to-day basis who have commit access to Trunk. ... > So this definitely doesn't convince me that compiler development is so > different to other projects. And definitely doesn't rule out that Git > couldn't work, or that an improved workflow couldn't be applied (freeing > up time in the long run). You are mixing up your replies. I only excluded the Linux kernel as model (since it was written to their workflow). BSD afaik still uses GIT, and like LLVM experiments but haven't moved to GIT. Actually infrequent committers make the change harder, since they spend a higher percentage of their freetime on the move :-) ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] How do you keep up with FPC discussions?
On 2017-05-24 21:28, Marco van de Voort wrote: - preferably anything with "huys" and 'git" :-) Awesome, I made the list. :) Seriously, just be selective, and use a threaded reader that allows you to skip/ignore threads. Agreed. And if you are using Mozilla Thunderbird, learn to use the “R” key. If the thread is not already marked Ignored, the “R” key will mark the whole thread as Read. I only read threads with a subject line that catches my attention. I also have a filter that tags all messages that mention my name - seeing as I don't read every message in the mailing list. 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-24 21:21, Marco van de Voort wrote: Even a limited change is already a massive operation, let's keep it managable. So how large is the FPC team really? I'm talking about active developers on a day-to-day basis who have commit access to Trunk. Oh wait, I can answer that very accurately myself... using git. $ cd /data/devel/fpc-3.1.1/src [src (master)]$ git shortlog -s -n --since=4.months 191 Michael Van Canneyt 147 Mattias Gaertner 140 nickysn 83 svenbarth 73 Florian Klaempfl 62 pierre 52 Joost van der Sluis 39 maciej 30 karoly 26 Marco van de Voort 23 Jonas Maebe 22 yury 7 lacak 5 marcus 3 Sergei Gorelkin 2 hajny So that's 16 developers - a nice size, but also not a large team (say compared to the KDE project that moved from SubVersion to Git, or LLVM seeing as that was mentioned earlier). The amount of commits are also not huge - so they most likely have a day job. ;-) And the two developers with the most commits (by a large margin) work primarily in the RTL and FCL. That's development work like any other project I have worked on. Nothing special or "rocket science" about that (sorry Florian). As for the 3rd person "nickysn"... I see he/she actually worked on the compiler/* tree. How do I know this? $ git log --name-only --oneline --since=2.months --author=nickysn Randomly picking some other authors, it seems most work is primarily in the RTL and FCL. A few small exceptions like Sven and Florian who mostly work in the compiler tree. So this definitely doesn't convince me that compiler development is so different to other projects. And definitely doesn't rule out that Git couldn't work, or that an improved workflow couldn't be applied (freeing up time in the long run). 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. Regards, Graeme ___ 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-24 21:07, Florian Klämpfl wrote: I'm sorry to bust your bubble, but how different can compiler development be. Apparently it is: Then why are you still talking to me. I have my doubts that it can be _that_ different. To quote Marco "I see to proof to make me think otherwise". The workflow will not change. If the tool does not fit the workflow, it is the wrong tool. Period. Yes, habits (good or bad) are a hard thing to break. In that case, please enjoy your project further with SubVersion. Until you actually use a project with Git (not git-svn), we might talk again. But like you, I'm not holding my breath. ;-) Regards, Graeme ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
On 05/24/2017 02:12 PM, Graeme Geldenhuys wrote: On 2017-05-24 02:11, nore...@z505.com wrote: I'd rather upload/commit files to a server to insure it is backed up properly... There is absolutely no guarantee that your file are any safer. So you have your Army of Developers in a single building. You store all your files on a Server which is in the server room in the basement of the building behind steel doors. Oh wait, a Boeing 747 fully fuelled just flew into your building. Everything is now a pile of rubble. Oh the backups where on another server next to the one you pushed changes to. What if you have backups, distributed all over the globe? Oh wait, a meteorite hits Earth and wipes out all life. Everything is now a pile of rubble. Oh the backups where all stored on the same planet and now they are gone. :) Nikolay ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] How do you keep up with FPC discussions?
In our previous episode, nore...@z505.com said: > > How in the world do people (you) keep up with reading email lists and > not waste the entire day? Avoid the following - long discussions about new features -> design by committee was never successful anyway. - anything with "Schnell" and "unicode" - preferably anything with "huys" and 'git" :-) Seriously, just be selective, and use a threaded reader that allows you to skip/ignore threads. Speed read and if not interesting, immediately skip the lot. p.s. though I use ELM which isn't threaded, with "l" you can get a view of all msgs with one subject, which I use. For Lazarus for which I read much fewer threads I do use MUTT though. ___ 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, Florian Kl?mpfl said: > > 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. Even if we will change workflow more GIT like in time, the required leap of faith and transition is too large. I think the Git advocatists should focus more on a workable model for a transition and not some ideal in the far future. Even a limited change is already a massive operation, let's keep it managable. ___ 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] Git & SVN
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. I'm sorry to bust your bubble, but how different can compiler development be. I'm not talking about the recursive build process, I'm talking about bug fixes and implementing new features. 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 Like the Git project, you can merge all new work into a testing branch. That could be what "trunk" is now. Once features have been tested by FPC core members or community - using that trunk branch, those signed off features can be merged into a more stable development branch... lets call it "develop" (or in terms of the Git project, call in "next"). The "next" branch will always be more stable that "trunk". The "next" branch is also the one the next release (hence the name) will be based forked from. If you haven't found the Git project documentation on this workflow, I'll find it for you and post the URL. I think actually the 'git help workflows' command lists that same information. 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 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] [fpc-pascal] FPC Graphics options?
In our previous episode, nore...@z505.com said:
> 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.
That, and the fact that while (a=b){} goes through undetected. In general
it relies too much on symbols !^%&===?{}, etc etc. While that might be my
Pascal bias, I program C very regularly for over 10 years now, and I haven't
gotten used to it.
C also shares some of (IMHO) Pascal's failings, like not distinguishing
procedural end from other blocks "end" and complex blockstructure.
(different syntax for 1 and multi line blocks).
___
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-24 16:18, Jürgen Hestermann wrote:
I can type "begin" and "end" much faster than the cryptic { and } (on my
german keyboard).
I use all 10 fingers for typing and each special character is an
interruption in my coding flow..
I use a custom Dvorak keyboard layout. I used to use Programmer Dvorak,
where the symbols are where the number row normally is - but don't
require a SHIFT. So { would be a single keypress.
http://www.kaufmann.no/roland/dvorak/
These days I use a custom Dvorak on a Ergodox keyboard. All my most used
symbols are on the 2nd layer. I use my left thumb to temporarily switch
layers, and then the rest of my left hand fingers to type the symbol. No
typing slowdown at all.
https://github.com/graemeg/qmk_firmware/tree/gg_dvorak/keyboards/ergodox/keymaps/gg_dvorak
But I get what you are saying. Most people can’t type symbols or numbers
as fast as the normal alphabet.
I always indent the begin (and end) of a block together with the block:
if true then
begin
DoSomething;
end;
This way the indentation always looks similar
independent from whether you have begin/end or not:
I’ve been working with Michael van Canneyt for the last two years, and
he indents like that too. It drove me nuts in the beginning, but kinda
got used to it - though I never indent like that. Your last sentence at
least explains why one would want to do that.
You cannot solve all these cases just by TABs.
These days I don’t care about code formatting at all - while I code. I
just type. Then on occasion I press Alt+S which triggers Jedi Code
Formatter which formats my current unit as it should be. I have
different formatting styles for different clients. It’s a huge time
saver! If only Lazarus IDE had a faster way of switch between formatting
styles (would be nice if it was integrated with Project Groups). At the
moment I have bash scripts that flip between them.
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?
Am 2017-05-24 um 15:28 schrieb Karoly Balogh (Charlie/SGR): > 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... Then why hasn't it been added to the C language definition yet? At Turbo Pascal times I also added routines for variable length arrays but because of getmem etc. I lost range checking etc. It was an ugly hack (nevertheless the only way to handle such arrays at that time). Now with dynamic arrays I am so much happier. Why weren't such things added to C decades ago? Strange. ___ 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?
Am 2017-05-24 um 15:44 schrieb Karoly Balogh (Charlie/SGR): > 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. > :) Yes, and there is still a lot of very old C code used in programs and libraries that was written with strcpy and I doubt that someone will change all theses occurences at any time. Why should it be changed? It works! ;-) ___ 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?
Am 2017-05-24 um 14:02 schrieb wkitt...@windstream.net: > On 05/24/2017 12:54 AM, Ralf Quint wrote: >> 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... > > quite true, my friend... quite true :) I disagree! You still know the byte(!) length of UTF-8 strings and in many cases you don't need anything more. If I search for the existence of an ASCII character I can still iterate my string in a for loop: for i := low(MyString) to high(MyString) do begin case MyString[i] of '!' : do_something; 'a','A' : do_something_else; end; // of case end; Works perfectly on UTF-8 strings. And if it's coming to the number of glyphs in a string you will have a hard time anyway because of diacrytics etc. But I very seldom need the exact number of displayed glyphs. And for these cases there are powerfull functions available in Free Pascal to handle them. ___ 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?
Am 2017-05-24 um 13:59 schrieb Graeme Geldenhuys:
> But in Object Pascal you have...
>
> begin
> ...
> if then
> begin
> ...
> if then
> begin
> ...
> Object Pascal blocks are longer to type - “begin” vs ”{” and “end” vs
”}”.
I don't know why this argument pops up over and over again.
To me it's just the opposite:
I can type "begin" and "end" much faster than the cryptic { and } (on my
german keyboard).
I use all 10 fingers for typing and each special character is an
interruption in my coding flow..
Also, as I already often said:
Program code is *written* only once but maybe *read* very often.
I prefer readable code even if it takes a millisecond longer to type
(which is not the case for me!)
> Also IF statements require the extra “then” keyword etc.
Same argumentation here.
I don't bother to type just another (ASCII) word.
Before I can think about a delay it is typed already...
> As for indentation. At least with real TAB character indentation, you
can configure the width of a TAB as a user configurable parameter
without affecting the source code. With space indentation you are stuck
with whatever the original author did.
That does not help me as I use an indentation scheme that not only relys
on TABs.
I always indent the begin (and end) of a block together with the block:
if true then
begin
DoSomething;
end;
This way the indentation always looks similar
independent from whether you have begin/end or not:
if true then
DoSomething;
Some people indent the code lines only:
if true then
begin
DoSomething;
end;
And some write the begin on the same line:
if true then begin
...
end;
You cannot solve all these cases just by TABs.
___
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/24/2017 04:44 PM, Karoly Balogh (Charlie/SGR) wrote: Hi, On Wed, 24 May 2017, Nikolay Nikolov wrote: 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. :) ROTFL, didn't know that :) 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. :) Of course, it's still not standard, because, according to their logic, string truncation is unsafe, while buffer overflows are somehow safer, for some strange reason. I've seen discussion like that, unfortunately I didn't keep the link, so that you can laugh. :) And, of course, strncat is entirely inconsistent with strncpy: - strncat always ensures there's a null terminator in the destination, while strncpy doesn't guarantee it. - strncat doesn't fill the rest of the buffer with nulls, when there's leftover space, while strncpy does. - strncat's size parameter must be the maximum number of character to add to the destination buffer, minus the null character (so dest must have space for strlen(dest)+size+1 bytes), while strncpy's size parameter is the size of destination buffer. Thanks to things like that it's mindblowingly difficult to learn how to write correct code, that isn't vulnerable to buffer overflows, using C "strings", and most people don't do it. They think they do, but they always get caught in some of these traps, without even realizing it and that's where almost all of the buffer overrun security exploits come from. Nikolay ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
On Wed, May 24, 2017 16:51, Graeme Geldenhuys wrote: > On 2017-05-24 15:30, Tomas Hajny wrote: >> I have my doubts about availability of the GUI component for OS/2, but >> you're welcome to prove me wrong. ;-) > > I haven't personally tried Git under OS/2, but I have two OS/2 VMs > available, so I'll test. > > Does OS/2 have a port of TCL/TK? That's what those GUI's are written in. I could find a port of Tcl/Tk version 8.3.5 on Hobbes. No idea if there are newer ports somewhere else. Tomas ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
El 24/05/17 a les 16:03, Graeme Geldenhuys ha escrit: On 2017-05-24 14:38, Luca Olivetti wrote: $ LC_ALL=C git gui git: 'gui' is not a git command. See 'git --help'. I guess you can blame your Linux distro's rubbish package management requirement policies for that. They probably split Git into two or more packages. F**ken annoying if you ask me - hence I don't use Linux any more. Right, unsurprisingly it's in the git-gui package. bye -- LUca ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
On 24/05/17 13:30, Graeme Geldenhuys wrote: On 2017-05-24 12:46, Mark Morgan Lloyd wrote:> > could usefully be described as v1.4.1-787, and you can use that in> conversation without having to be online to a repository. Yes, you can use "v1.4.1-787" to describe a specific point in history, but the far more common and useful one is the "45f932c1" SHA1 reference, because the latter can be used directly in all Git commands. If multiple people were committing directly to the same repository (I> presume Git supports that) Yes. presumably they'd see a consistent sequence> of version identifiers, i.e. very much like Subversion. Yes. A SHA1 reference like "45f932c1" only only points to a specific commit, it also describes the history that lead to that point. What happens in the case where there's multiple repositories? No difference. A git repo contains the full history. If you clone that repository 100 times between developers, you effectively have a 100 backups. If the original repo had 5 branches, all 100 clones with have references (and full history) to those 5 branches too. Such remote branch can be listed using the following command: git branch -r Thanks very much for that, very interesting. -- 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
On 2017-05-24 15:30, Tomas Hajny wrote: I have my doubts about availability of the GUI component for OS/2, but you're welcome to prove me wrong. ;-) I haven't personally tried Git under OS/2, but I have two OS/2 VMs available, so I'll test. Does OS/2 have a port of TCL/TK? That's what those GUI's are written in. Regards, Graeme ___ 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-24 15:32, Santiago A. wrote: But IMHO it clearly shows how poorly git defaults and parameters have been chosen. And I am afraid that has been one of the hinders of git adoption. The problem goes much deeper than that. I once brought up the issue of inconsistent command line parameters in the Git mailing list and gave ideas I thought were improvements. They immediately confirmed the problem, and the problem in finding a solution. Some issues raised: * Because git has so many options (way more than normal apps), one change can (and does) have affects on others. * Backwards compatibility. Changing the commands will break just about every Git GUI front-end there is. Many of them simply parse the output of a forked 'git' command. But they would actually consider doing this for the greater good - I was impressed. * Conflicting command line parameter "modes". If interested, the discussion can be found here: https://www.mail-archive.com/git@vger.kernel.org/msg76433.html 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
El 24/05/2017 a las 13:41, Graeme Geldenhuys escribió: > > Git has built-in support for alias. So you could simply define a > couple of aliases in your $HOME/.gitconfig file that mimic the above > commands, or even the SVN commands. I have over 20 aliases that I > created over the years to simply long command line parameters. > > Now suddenly I can do this: > > $ git switch develop > Maybe with Alias I don't need eg to redefine git CLI. But IMHO it clearly shows how poorly git defaults and parameters have been chosen. And I am afraid that has been one of the hinders of git adoption. Here is an overview Easy Git (eg) parameters https://people.gnome.org/~newren/eg/documentation/ I think it shows how git parameters should had been. -- Saludos Santiago A. ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] Git & SVN
On Wed, May 24, 2017 16:03, Graeme Geldenhuys wrote: > On 2017-05-24 14:38, Luca Olivetti wrote: >> $ LC_ALL=C git gui >> git: 'gui' is not a git command. See 'git --help'. > > I guess you can blame your Linux distro's rubbish package management > requirement policies for that. They probably split Git into two or more > packages. F**ken annoying if you ask me - hence I don't use Linux any > more. > > I compile Git from the original source code, and it includes > everything... Console, GUI and SubVersion support. I have my doubts about availability of the GUI component for OS/2, but you're welcome to prove me wrong. ;-) Tomas ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] How do you keep up with FPC discussions?
On Wed, May 24, 2017 15:54, Karoly Balogh (Charlie/SGR) wrote: > 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. :) ...proving just that you're another A.I. bot. ;-) However, I'm afraid that I belong into the same category, because there are people who could claim meeting both the two of you and me. ;-) 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-24 15:03, Graeme Geldenhuys wrote: I compile Git from the original source code, and it includes everything... Console, GUI and SubVersion support. On this web page the first two screenshots are of gitk and git-gui - the standard GUI tools of Git. https://git-scm.com/book/uz/v2/Git-in-Other-Environments-Graphical-Interfaces They might not look as visually pleasing (eye-candy) as many other gui tools, but trust me, these built-in apps pack a punch (tons of features), and always supports git very well - obviously. Regards, Graeme ___ 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-24 14:38, Luca Olivetti wrote: $ LC_ALL=C git gui git: 'gui' is not a git command. See 'git --help'. I guess you can blame your Linux distro's rubbish package management requirement policies for that. They probably split Git into two or more packages. F**ken annoying if you ask me - hence I don't use Linux any more. I compile Git from the original source code, and it includes everything... Console, GUI and SubVersion support. 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] 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] Git & SVN
El 24/05/17 a les 13:02, Graeme Geldenhuys ha escrit: On 2017-05-24 01:26, nore...@z505.com wrote: 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 Git includes as standard all the GUI tools you would ever need. Plus those GUI tools are available on all platforms that Git supports. So there is no retraining in different tools for each platform. eg: Tortoise Git is only available on Windows. So if you jump to OSX or Linux or FreeBSD, you need to learn a different tool. Or use mercurial with tortoisehg (note:when I switched from cvs to mercurial, git was not available for windows, while mercurial was already stable and multi-platform. I cannot claim I understand mercurial fully, but at least I can use it for basic tasks with no surprises, while my experience with git is like https://xkcd.com/1597/) Anyway, the standard git GUI tools... * git gui: visually make commits, do branch management, selective line-by-line commits, pull, push, merge etc. $ LC_ALL=C git gui git: 'gui' is not a git command. See 'git --help'. Did you mean one of these? gc grep init pull push Bye -- Luca ___ 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] How do you keep up with FPC discussions?
On 2017-05-24 03:07, nore...@z505.com 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.. Or we have a couple of clones - human trials started ages ago in some countries. ;-) Regards, Graeme ___ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
Re: [fpc-other] How do you keep up with FPC discussions?
On 05/24/2017 05:07 AM, nore...@z505.com 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! :) Nikolay ___ 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/24/2017 04:28 PM, Karoly Balogh (Charlie/SGR) wrote: 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. It's even worse than that - see my other mail. Even the size in bytes is lost, as soon as you try to pass that array as a parameter to function, since it gets implicitly converted to a pointer, and the size is lost, because... who cares about array sizes, this is C! :) Nikolay ___ 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
On 2017-05-24 12:46, Mark Morgan Lloyd wrote: > [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. says explicitly that the modification with the hash g45f932c1 takes the project on the Git repository under consideration to something that could usefully be described as v1.4.1-787, and you can use that in conversation without having to be online to a repository. Yes, you can use "v1.4.1-787" to describe a specific point in history, but the far more common and useful one is the "45f932c1" SHA1 reference, because the latter can be used directly in all Git commands. If multiple people were committing directly to the same repository (I presume Git supports that) Yes. presumably they'd see a consistent sequence of version identifiers, i.e. very much like Subversion. Yes. A SHA1 reference like "45f932c1" only only points to a specific commit, it also describes the history that lead to that point. Let me explain: Say you have two branches with the same file, and the file hasn't actually changed between those two branches. Now say I give you a patch file to apply to that file in both branches. The commits that gets generated in each branch - even though the diff is identical - will not have the same SHA1 reference. Because the history to get to that point has diverged because of the branching. So if I mention a problem in the "45f932c1" commit of a Git repository. No matter how many clones [by multiple developers] there are of that repository, that SHA1 reference will point to the exact commit and code change - in all the Git repositories out there in the wild. This is also one of the huge arguments about NOT using the git-rebase command on a branch that has been published, because a rebase command rewrites the history. So every commit (SHA1 reference) in that affected branch changes. Rebasing local branches (not made public yet) is obviously not a problem. The Git project repo has a "short lived" branch where they do all kinds of testing. They explicitly note that nobody should base any new development on that branch, because it will frequently be destroyed and recreated (merging in new feature to be tested for the next cycle). What happens in the case where there's multiple repositories? No difference. A git repo contains the full history. If you clone that repository 100 times between developers, you effectively have a 100 backups. If the original repo had 5 branches, all 100 clones with have references (and full history) to those 5 branches too. Such remote branch can be listed using the following command: git branch -r eg: [tiopf (tiopf2)]$ git branch -r carlo_marona/Add_tiLogToDebugString carlo_marona/Additional_Mediators carlo_marona/Fix_BOOLEAN_Defines carlo_marona/Fix_TtiDatabaseZeosAbs_SetConnected_Except carlo_marona/Fix_tiCriteria_AssignClassProps carlo_marona/Fix_tiMediatorView carlo_marona/Fix_tiModelMediator carlo_marona/Fix_tiQueryZeosIBFB_Unit carlo_marona/tiOIDManager_Update carlo_marona/tiopf3 github/master github/tiopf1 github/tiopf2 github/tiopf3 sourceforge/HEAD -> sourceforge/master sourceforge/fea_Fix_Event_Execution_Of_TtiPropertyLinkDef sourceforge/fea_Missed_Changes_On_tiOPF3 sourceforge/master sourceforge/tiopf1 sourceforge/tiopf2 sourceforge/tiopf3 Here you can see my local tiOPF repository has 3 remote repositories defined. "carlo_marona", "github" and "sourceforge". I frequently pull fixes from Carlo, so that is why I have a permanent remote repository link to his published work. For contributions from one-off developers I don't bother setting up a remote repository link - I use their repository URL directly in the git-fetch command. The official public tiOPF repository lives on SourceForge.net, so that is the "sourceforge" remote repo link. The "github" link was just a backup public repo I used while SourceForge.net had a major global outage a little while ago. So development continued as usage without skipping a beat (thanks Git). You can also see from Carlo's repository that he nicely names each branch, and every branch that is a bug fix has the prefix name "Fix_" to it. In the end you can name branches whatever you want though, and you can even groups things with a "/" in the name of the branch. 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 05/24/2017 04:56 AM, nore...@z505.com wrote:
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.
Yes, this is one of the horrible things I have beef with. I have several.
1) the null terminated "strings"
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.
3) the fact that you can get easily burned by typing '=' instead of '=='
(or vice versa).
Both
if (i=5)
do_something();
and
i==5;
Will happily compile and _not_ do the expected thing. Modern C compilers
give you warnings in these cases, but that doesn't change the fact that
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 :)
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.
Nikolay
___
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/24/2017 04:59 AM, nore...@z505.com wrote: 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 The virtual machine is a JIT compiler, so it recompiles the bytecode to machine code for the current CPU, *not* to C code, so your understanding is not very accurate. I could be wrong, but, all it does is end up calling C written VM, right? What does "calling" a VM even mean? The VM is like a compiler, it translates java bytecode to machine code. It can also be implemented as an interpreter (and probably ancient versions of the JVM were interpreted), but that makes the program run much slower, and it can never compete with compiled code in this case. Nikolay ___ 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-24 12:49, Mark Morgan Lloyd wrote: s the licensing problem (Sun's license being incompatible with GPL) which resulted in a lot of FUD. It's only a problem if you want it to be. Yes, they can't include ZFS as standard with a Linux Distro (though some now apparently do), it is is pretty much a two command step to get it installed. 1) // Add the add-on apt repository to your list 2) apt-get install zfs Something like that - its been a while since I did that in my dual-boot Linux environment. Also ZFS doesn't run via FUSE on Linux any more - it is a "native" file system now. https://launchpad.net/~zfs-native/+archive/ubuntu/stable http://zfsonlinux.org/ The really good news is that for some time now, all ZFS development is merged into a single organization. So OSX, Linux, FreeBSD all have the same ZFS features and functionality. No more fragmented development. 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 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] [fpc-pascal] FPC Graphics options?
On 05/24/2017 12:54 AM, Ralf Quint wrote: 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... quite true, my friend... quite true :) -- 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] How do you keep up with FPC discussions?
On 2017-05-24 03:07, nore...@z505.com wrote: How in the world do people (you) keep up with reading email lists and not waste the entire day? I'm between jobs! And all my gardening chores are already done. :-P Regards, Graeme ___ 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-24 02:52, nore...@z505.com wrote:
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:
But in Object Pascal you have...
begin
...
if then
begin
...
if then
begin
...
Object Pascal blocks are longer to type - “begin” vs ”{” and “end” vs
”}”. Also IF statements require the extra “then” keyword etc.
As for indentation. At least with real TAB character indentation, you
can configure the width of a TAB as a user configurable parameter
without affecting the source code. With space indentation you are stuck
with whatever the original author did.
But lets not get into Space vs TAB vs Elastic Tabstops
indentation/alignemnt arguments - that’s a whole new war I don’t want to
tackle. :)
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-24 02:56, nore...@z505.com wrote: But my biggest hate for C is not C itself but just the one fact that it lacks strings. I also hate the cryptic syntax, the fact that there is *.c and *.h files etc. Apparently Java took a lot of ideas from C, but at least they had the common sense to get rid of the *.h file mess, and the Object Pascal "interface" vs "implementation" section mess! Kudos to them for that. Navigating Java code is so much easier now. 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/17 14:10, 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. 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? Apologies for the poor threading, but not all ML messages get through our gateway. Thanks for the explanation Graeme, I hope that I'm not the only person here to find that instructive. So in the context of what I asked > [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. says explicitly that the modification with the hash g45f932c1 takes the project on the Git repository under consideration to something that could usefully be described as v1.4.1-787, and you can use that in conversation without having to be online to a repository. If multiple people were committing directly to the same repository (I presume Git supports that) presumably they'd see a consistent sequence of version identifiers, i.e. very much like Subversion. What happens in the case where there's multiple repositories? How brutally would each one have to be whacked before it was guaranteed that every one had the same correspondence of release-commit tuples and hashes? Could this be /forced/ at the project level and what implications would that have on the amount of data transferred to synchronise them? -- 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
On 24/05/17 08:30, Graeme Geldenhuys wrote: 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. Sounds like you are in serious need of ZFS. If you work on a laptop (so can't install 3+ hard drives), then I recommend you get one of those USB3 or Thunderbolt port external NAT-style storage devices. I know some of them support ZFS. But those storage devices are a bit costly. But then, how much is your data worth? I agree, it's really very good indeed and I think the only reason that it's not more widely used is the licensing problem (Sun's license being incompatible with GPL) which resulted in a lot of FUD. -- 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
On 2017-05-24 12:32, Karoly Balogh (Charlie/SGR) wrote: 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 The bottom line is, the end result should be identical to what you see when you do a 'svn co' on any branch, compared to the Git migrated version. At least this was my case in all the conversions I have done. Some of the git-svn output is weird though. They sounds more alarming than they really are. eg: If you had a commit that only changes svn properties, I believe sometimes git can skip over such commits because there is no direct translation to Git. But those are generally rare, and often not an issue, because it was more SVN repo maintenance that actually tracking changes to files. The latter being way more important. If the Free Pascal team is ever serious about migrating to Git, I'll happily help out with the migration process. 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-24 08:21, Santiago A. wrote: i.e. instead of git checkout master git checkout develop eg switch master eg switch develop Git has built-in support for alias. So you could simply define a couple of aliases in your $HOME/.gitconfig file that mimic the above commands, or even the SVN commands. I have over 20 aliases that I created over the years to simply long command line parameters. For example: $ git config --global alias.switch checkout will result in the following -[ ~/.gitconfig ]- [alias] st = status -uno svnlog = log --stat=70 --pretty=medium --name-status --reverse ...snip... switch = checkout -- Now suddenly I can do this: $ git switch develop No need for Perl add-ons. ;-) ps: Above I listed two of my most used aliases as well. I have plenty of others too. git checkout master git merge feature1 feature2 feature3 feature4 feature5 ...where "featureX" is a branch name. Yes, that's very handy... and scaring. The merge is done magically in the repository, not in a working machine, Everything is done locally first. So if you are not happy with the result, it can be undone with a simple git-reset command. 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 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
On 2017-05-23 19:37, Florian Klämpfl wrote: First problem: quote from core: The git-to-svn bridge is slow, but pretty good - not perfect, sometimes it falls over and needs a restart. But I can honestly say, I have converted full SubVersion repositories (from small to very large) to Git, and always managed to have everything in Git at the end. Nobody ever stated that any type of migration is going to be without problems. It's the nature of migration. I've stated numerous times that SubVersion is often abused because they have very bad concepts, which have been clearly designed and developed in Git. "Tags" are the first thing that comes to mind. 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. The only reason I then changed it to only track the "trunk" branches is because I personally think a migration should be a one-shot deal, not a continuous process. It was a pain to manually update and work around the weird SubVersion behaviours (commits after a Tag was created - God Damn, use a branch instead!). Over the years I've personally migrated over 200 SubVersion repositories to Git. My final step has always been to checkout each SVN repository and branch, and then do a checksum comparison to the Git version. Ensuring everything is like it is supposed to be. Any discrepancies can then be resolved with a single commit, but to be honest, I can't recall ever having the need to do that. 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
El 24/05/2017 a las 8:57, Graeme Geldenhuys escribió: My company uses svn and I use git for my local work since Mr Geldenhuys praised it a year or two ago ;-). For me, branching is the really the big thing. I have several branches running, and I only commit to svn repository after testing everything. Git is complicated, I don't mean it is overcomplicated, just it's more complicated than svn because it tries to accomplish more and more complicated tasks than svn. In fact, the discuss shouldn't be svn vs git, but centralized version control vs distributed version control. Nevertheless, git has a complicated and anti-intuitive command line syntax. Git is the winner over others, like Mercurial, because of Linus Torvald's popularity, not that Git is better or worse than Mercurial, just that their technical virtues had little to do with the success of git. I use Easy Git, It is a perl script that In the background it calls git, but syntax is more sensible. i.e. instead of git checkout master git checkout develop eg switch master eg switch develop > > git checkout master > git merge feature1 feature2 feature3 feature4 feature5 > > ...where "featureX" is a branch name. Yes, that's very handy... and scaring. The merge is done magically in the repository, not in a working machine, It is a little black box. But it's looks that it manages to do its job. Nevertheless I have had some unexpected issues... it is scaring. :-P Should I recommend git for central repository in my company? Not sure. What's the difference between pulling from several repositories and pushing to a central repository? In the end, I prefer the central repository with a more lineal history. I think that distributed development works better when there is a big project with independent parts. For me, in Git is much important de advantage of easy local branches that distributed development. On the other hand, probably I'm getting old ;-) :-( -- Saludos Santiago A. ___ 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-24 02:11, nore...@z505.com wrote: I'd rather upload/commit files to a server to insure it is backed up properly... There is absolutely no guarantee that your file are any safer. So you have your Army of Developers in a single building. You store all your files on a Server which is in the server room in the basement of the building behind steel doors. Oh wait, a Boeing 747 fully fuelled just flew into your building. Everything is now a pile of rubble. Oh the backups where on another server next to the one you pushed changes to. ;-) 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-24 01:26, nore...@z505.com wrote: 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 Git includes as standard all the GUI tools you would ever need. Plus those GUI tools are available on all platforms that Git supports. So there is no retraining in different tools for each platform. eg: Tortoise Git is only available on Windows. So if you jump to OSX or Linux or FreeBSD, you need to learn a different tool. Anyway, the standard git GUI tools... * git gui: visually make commits, do branch management, selective line-by-line commits, pull, push, merge etc. * gitk: visually see your commit history. For a specific branch, or all branches in the repo. You can also cherry-pick commits from one branch into another. * gitk -- See the full history for a specific file only, or for a directory only. * git gui blame: visually see line-by-line who made which changes. All these gui tools also have built-in navigation, where if you click on a SHA1 it navigates to it. The point is that github does in fact allow you to treat a github repo like an SVN one, Ah, I see that now. I never knew that existed. It is definitely a Github only thing. 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, nore...@z505.com said: > >> 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. The scenario was based on older commercial VCS systems (VSS, that Team thing from Borland etc etc) that required explicit locking, and people would lock files, change some formatting and then go on holiday before their real work started. During that time nobody could make changes to those files, and even back then we already had some form of CI to a testserver that worked from the VCS, so that also hampered testing your own mods. Locks were notorious hard to break, and persons with the required rights were often also rare during those periods. And yes, if you did that, specially if the file was something central (like a file that listed all commands accepted by the command processor), people could get somewhat aggressive ;-) The DVCS scenario is not as bad, but some simple prevention of this would prevent some mistakes, and make the minefield for new devels a bit smaller, thus save a lot of annoyance on all sides. ___ 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-24 02:59, nore...@z505.com wrote: But the virtual machine is just C code, so it's a wrapper around C, IMO That is way over-simplifying it I would think. I could be wrong, but, all it does is end up calling C written VM, right? Technically, you can write a VM in many other languages too. I honest don't know what language they use for the various VMs out there - but I guess C is a safe guess. Regards, Graeme ___ 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-24 02:46, nore...@z505.com wrote: 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 I used to live in a country with constant blackouts or brownouts. So harddrives took a real punishment. UPS's were a requirement, not a luxury. So I take data protection very seriously, even though where I live now the power is much more reliable and clean. Yes, I have off-site private backups, and on occasion I push those to a USB stick too. Everybody should at least be doing this. I also know how valuable my work and data is - I run my own business. All my data, code and VMs lives on 4 server quality harddisks using ZFS RAID-Z2 as the file system, and FreeBSD as my OS of choice. I will not trust my data on anything other than ZFS. Even my USB sticks use ZFS. My hard drives were bought from different suppliers so they aren't all from the same batch. I also replace them every 3-4 years (ZFS makes this a no brainer). I highly recommend you read up on ZFS if you don't know it. It comes natively with Solaris and FreeBSD, and is easily installed on Linux. I believe OSX might also have unofficial support now. ZFS is a copy-on-write files system. Every read and write is checksummed. I can have two hard drives fail (very very unlikely) and still be able to rebuild my data. Very sensitive data I store in a partition that keeps two copies of the data scattered around the ZFS pool. ZFS partitions can be created and destroyed on the fly - they are more like directories than partitions. So you can create and destroy partitions as the need arises, and set encryption, compression, de-duplication etc on each partition as you see fit. 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. Sounds like you are in serious need of ZFS. If you work on a laptop (so can't install 3+ hard drives), then I recommend you get one of those USB3 or Thunderbolt port external NAT-style storage devices. I know some of them support ZFS. But those storage devices are a bit costly. But then, how much is your data worth? 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:41, Florian Klämpfl wrote: This is what I do as well for several things, but I still think, subversion is the better solution as the canonical FPC repository. The ‘git-svn’ functionality is great - I use it for several SubVersion projects too. It also unfortunately stops you from using many of the nicer features of Git. So you definitely don’t get the full experience - it’s more like the “cheap seats” at a concert. You can say you were there and heard the band sing, but you couldn’t actually see them. Regards, Graeme ___ 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-24 02:01, nore...@z505.com wrote: 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 "fork" is probably the wrong word. I prefer the word "clone" instead. It is only anti-social if YOU (the developer) don't share your changes. You do that by sending a pull request to the original project. See... git help request-pull ...for more details. And no, you don't require GitHub for pull requests, it's built right into Git. 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
