[fpc-other] [fpc-pascal] FPC Graphics options?

[n***@z505.com]

On Thu, May 18, 2017 at 5:05 PM, Graeme Geldenhuys

Use Java instead. ;-) Check. Oh wait, that's what I did for that
project.

Well, Java also has its issues.

...

import java.util.*;
class FelipeTestThread
{
volatile boolean running = true;
public void test()
{
new Thread(new Runnable()
{
public void run()
{
int counter = 0;
while (running) {
counter++;
}

Yes indeed, one issue is:

your code is
{
{
{
way
{
over here


Compare that to oberon or even Plain C where your code:

someproc {
is here
}


Not here:

{
{

{
system.print()

Same issue with C#

Not an issue with: golang, fpc, delphi, oberon, C, or even in some cases
ruby

The amount of nesting and indented procedures inside classes in Java is
horrible, IMO.
Just to get a program started you are

way over here
by morning
and worse
by night
_______________________________________________
fpc-other maillist - fpc-***@lists.freepascal.org
http://lists.f

[n***@z505.com]

A real game would be done differently and then FPC is fast.

Oh, so work around the FPC problem. I get it now. ;-)

Wanne do PacMan in 160x100 resolution, no problem for FPC.

Check.

Wanne do something more modern...

Use Java instead. ;-) Check. Oh wait, that's what I did for that
project.

What about Rust or plain C? Or Digital Mars D?

Biggest problem with C is all the manual memory management, like
strings, for example, that IMO morons waste hours of time on and create
buggy code, all needlessly and unnecessarily.

Or instead of using rust/c/java, simply fix FPC, which is a good
solution IMO, as not only does it speed up some boring game test case,
but fixes other things that people didn't know about which were slowing
down their app.

I don't see how ZenGL and Andorra3D have been able to succeed as game
engines with all these performance issues in the RTL/compiler? Did they
work around them and swap in their own faster code, instead of reporting
the bug/issue to the fpc bug reporting?

Indeed it is not exactly a bug but could just be correct code that is
slow.
_______________________________________________
fpc-other maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/

[Graeme Geldenhuys]

Post by n***@z505.com
What about Rust or plain C? Or Digital Mars D?

I hate C with a passion. I'll never code in that ever again.

I also have no interest in learning "the new language flavour of the
month" - which will be obsolete in a year or two. Object Pascal is
already pretty irrelevant when it comes to looking for jobs - I'm a
freelancer / contract programmer. Though it has served me very well
since TP 5.5 and then again from Delphi 4 onwards.

I now go where the work is (as well as the money - but enjoyment of work
is still a higher priority for me).

Post by n***@z505.com
Or instead of using rust/c/java, simply fix FPC, which is a good
solution IMO

I don't know compiler design or how it works internally. So contributing
in that area is out of my scope.

Post by n***@z505.com
I don't see how ZenGL and Andorra3D have been able to succeed as game
engines

I can't speak for those, but have used OpenGL with FPC for a few months.
I'm definitely no OpenGL expert, but I did manage to off-loaded a lot of
work via shaders to the GPU. So that frees up a lot of what FPC has to
do with the general game "ticks".

Post by n***@z505.com
Indeed it is not exactly a bug but could just be correct code that is
slow.

Many seem to miss the whole point of what I was trying to say. Other
compilers did a much better job than what FPC could manage - using the
exact same code (just the language syntax that differed). I didn't need
to change anything for GCC or Java, and I didn't have to implement all
kinds of work-arounds.

Either way, I've run out of energy discussing this. I profile my code
one more time and try the suggestions in Jonas. Simply because I'm
curious. But other than that, my project has already moved forward using
Java.


Regards,
Graeme

[n***@z505.com]

Post by Graeme Geldenhuys

Post by n***@z505.com
What about Rust or plain C? Or Digital Mars D?

I hate C with a passion. I'll never code in that ever again.

Pascal and C are actually twin brothers with slightly different
syntax...

But my biggest hate for C is not C itself but just the one fact that it
lacks strings.

Without strings, a language is headed for the graveyard, IMO.

Counting pchars in your head is just a waste of brain power..

The C struct is literally the pascal record, and is all based on the
same Structured Programming work by Dijkstra
_______________________________________________
fpc-other maillist - fpc-***@lists.freepascal.org
http://lists.freepas

[Karoly Balogh (Charlie/SGR)]

Hi,

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
int a[5];
sizeof(a) gives you the correct size of the array. However, if you pass
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
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.
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-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-ot

[Jürgen Hestermann]

Post by 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-***@lists.freepascal.org
http://li

[Nikolay Nikolov]

Post by Karoly Balogh (Charlie/SGR)
Hi,

this is bad language design. Bonus points for the fact that writing this
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 :)

Post by Karoly Balogh (Charlie/SGR)

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.
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-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/list

[Jürgen Hestermann]

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-***@lists.freepascal.org
http://lists.freepas

[Graeme Geldenhuys]

Post by n***@z505.com
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

[w***@windstream.net]

Post by n***@z505.com
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 :)

[Jürgen Hestermann]

Post by w***@windstream.net

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-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/list

[Nikolay Nikolov]

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-***@lists.freepascal.org
http://lists.freepa

[Graeme Geldenhuys]

Post by n***@z505.com
The amount of nesting and indented procedures inside classes in Java is
horrible, IMO.

It's not a Java language issue, but the indent preference of the
developer. Many Java IDE's support multiple coding styles and does
auto-formatting as you type or save. Some coding styles are better than
others, and all of them are configurable.

Regards,
Graeme

_______________________________________________
fpc-other maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-othe

[Graeme Geldenhuys]

I'm not just talking about 8 space indentation vs 4 space or 2, I mean
having to put code
{
{
{
here

But in Object Pascal you have...

begin
...
if <whatever> then
begin
...
if <whatever_else> 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

[Jürgen Hestermann]

Post by Graeme Geldenhuys
But in Object Pascal you have...
begin
...
if <whatever> then
begin
...
if <whatever_else> 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!)

Post by Graeme Geldenhuys
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...

Post by Graeme Geldenhuys
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-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/m

[Graeme Geldenhuys]

Post by Jürgen Hestermann
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.

Post by Jürgen Hestermann
if true then
begin
DoSomething;
end;
This way the indentation always looks similar

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.

Post by Jürgen Hestermann
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

[w***@windstream.net]

Just to do basic bloody damn things, Java and C# require ridiculous obnoxious
nests/indentations. >
No talking about 2 vs 8 space indentation choices, although that's another issue

i'm guessing that you haven't played with python where indention is a major
aspect of the language ;)

[Nikolay Nikolov]

After I looked at the code I didn't see anything strange about it

Thank you, that's what I thought too.

it just got me thinking, if that code can be that slow how slow is
all the stuff I’m writing on a daily basis? It’s just worrying that’s
all.

+1
Thank goodness normal desktop applications are not that sensitive to
inefficient generated binaries.

And this is why it is usually premature optimization.. most people are
using FPC likely for lazarus desktop apps, not game programming or
fast graphics rendering, so no one cared about this bug/slowness until
someone reported it..
Which is good that it was reported, to find a problem with FPC that
was not noted before or that no one previously had any issues with.
But with that pascal game development web forum out there, it should
have come up some time previously? As there are game programmers out
there using fpc, and there is andorra/zengl so what do they do? Work
around the bug instead of fixing it at the source in the rtl/compiler?
Swap in their own faster functions instead of replacing the rtl
functions at the source level on fpc's svn server?

It was actually a case, not typical at all for game development. It was
software rendering and game engines almost always use hardware
rendering, even for 2D games. And a huge part of the performance
difference was caused by the highly specific fact that floating point to
integer conversion is slow on the x87 FPU and SSE3 improves this a lot.
If it was regular floating point, without so many integer conversions,
SSE3 wouldn't matter, and I'm guessing that SSE2 wouldn't make a lot of
difference. Disclaimer: I have not tested this. :)

And yes, Florian, Jonas and Sven did a few small optimizations, which is
a good thing, but they are nowhere near as impactful in general use
cases as people think ( which is related to the fact that the FPC
optimization performance is not as bad as this particular test was
making it out to be :) )

Nikolay
_______________________________________________
fpc-other maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailma

[Graeme Geldenhuys]

What happens if you use the SVN bridge that allows you to run svn
commands to a git server?

Maybe your wording is confusing, or SVN has abilities I didn't know of.
I know Git can manage SVN repositories, but I didn't know it was
possible other way round (I doubt it is possible).

I often use Git to manage SubVersion repositories I don’t have control
over. For everything else I’ve moved over to Git years ago.

Local working copy issues Florian described would be an issue with this
bridge, or not an issue?

As with any new applications or technologies, there is always some
learning curve (big or small). There are tons of bad habits ingrained in
SVN users. Those do not translate well to Git (thank goodness). Git
works fundamentally different to SVN (for the better). So you need a
change in mindset - some refuse, hence they struggle with Git. And then
wrongly blame Git for it. I fear this is most likely what happened with
Florian.

There are also 100’s of different work-flows for when you work with Git
repositories. I’ve introduced Git into many companies. In every case I
look at how they work, suggest an already existing work-flow as a
starting point (*), and then tweak it to their needs. In they end they
get exactly what they want, and without fail all of my customers said
they should have made the switch years ago.


* - My all time favourite git work-flow is:
http://nvie.com/posts/a-successful-git-branching-model/

It works very will for small and large teams. Supports big or small
features. Allows for long-term support releases as well as quick
bug-fix releases.


Regards,
Graeme

[Tomas Hajny]

Hi Graeme,

.
.

Post by Graeme Geldenhuys
As with any new applications or technologies, there is always some
learning curve (big or small). There are tons of bad habits ingrained in
SVN users. Those do not translate well to Git (thank goodness). Git
works fundamentally different to SVN (for the better). So you need a
change in mindset - some refuse, hence they struggle with Git. And then
wrongly blame Git for it. I fear this is most likely what happened with
Florian.

.
.

Post by Graeme Geldenhuys
There are also 100’s of different work-flows for when you work with Git
repositories. I’ve introduced Git into many companies. In every case I

.
.

I won't comment your generic statements praising one tool and condemning
the other, but let me remind you, that it isn't just about Florian. During
the previous discussions on this evergreen topic, Florian, Marco, Jonas
(if I remember correctly) and others raised quite a few specific questions
on how to accomplish particular tasks commonly used in the FPC project. I
may have missed something, but I haven't noticed a particular proposal
from you or anyone else describing in detail how to cover those needs
(possibly a proposal altering the current practice, but still allowing to
achieve the original goals). This was how we performed the CVS to SVN
transition in the past.

People interested in changing the tools should be those coming with a
particular workable proposal on how to use the tool. You should not expect
that those happily using another tool _and_ performing many more
interactions with the current tool than you (without major issues) would
be keen to invest their time in analyzing all possible workflows, etc., of
a new tool just to find out, if they could achieve the same outcomes with
another tool as well as with the current one. Also, note that while many
things may work well in theory, solutions requiring users to be perfect
(e.g. having high level of discipline to perform certain things in certain
way resulting in the wanted outcomes) will rarely work so well in
reality...

Tomas


_______________________________________________
fpc-other maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-b

[Graeme Geldenhuys]

Post by Tomas Hajny
the other, but let me remind you, that it isn't just about Florian. During
the previous discussions on this evergreen topic, Florian, Marco, Jonas
(if I remember correctly) and others raised quite a few specific questions
on how to accomplish particular tasks commonly used in the FPC project. I
may have missed something, but I haven't noticed a particular proposal
from you or anyone else describing in detail how to cover those needs

To be honest, I can't actually remember seeing any such proposal (asking
for advice or help) in the FPC-Users mailing list. Maybe it was in a
list I'm not subscribed in? Otherwise, I would have happily given my advice.

I also don't expect somebody with no or very little Git experience to
give any good advice on such a matter either. I believe most of the FPC
team don't have any or very little Git experience.

I can add that I have been working closely with Michael van Canneyt for
the past two years. In the last few months I have introduced Git in his
workplace too, and his knowledge of Git has improved a lot. So maybe in
the next round of proposals, Michael will be able to offer some more
advice too.

So again, if the FPC team ever wants to consider Git, feel free to
contact me so we can bounce around some ideas.

Regards,
Graeme

[Karoly Balogh (Charlie/SGR)]

Hi,

nevertheless Charlie's mail was too interesting and constructive not
to respond to it :)

Awww, you, stop it... *blushes* :D

Of course the biggest obstacle is the building and running of the
testsuite.

Well. Build breakages are daily occurence with obvious "this could have
never built" mistakes, or new packages get committed which don't build for
any platform, etc. Even large patches, with little care and "worksforme"
excuse. So even in the current system we run the testsuite *AFTER* the
commits are already made. And lot of the experimental development happens
in directly trunk. So this reaction of "omg, what happens to the testsuite
runs" I feel a bit... Yes. :)

And I'm guilty as well, make no mistake. :) But actually this leads us to
another problem, that now all commits are equal, even if someone touches
an uncritical/new package or some x86 codegenerator or a critical part of
the RTL. If the later breaks, could cause problems for everyone years down
the line, while a package will almost certainly only affect some people.
Which means different developers work in the same repo with different
quality/criticality standards...

So maybe the Pull Requests for the integration system could be designed
in such a way that only a subset of the supported targets can be
requested for build and testsuite runs or maybe only a fullcycle is done
together with a full build of only one target all depending on whatever
the Pull Request specifies.

Indeed. I think we already have an informal list of "Tier 1" systems
anyway, which is more or less Windows, Linux-i386/x86_64 and Darwin. I
think (almost?) everyone uses these as development hosts, even if he works
on some other system in the end. But breakages in these affect quasi
everyone immediately. The rest is "irrelevant". (Disclaimer: I mostly work
on other systems, so I can claim this. ;))

There would of course be the possibility that this would break some
target that isn't in the test subset, but let's be honest: that
currently happens as well :P

Indeed.

To be honest, I don't see a lot of difference to a Pull request or a diff
submitted via Mantis. A core developer has to handle both, and sign it
off. From then on it's his responsibility to handle the patch during its
lifetime, and revert or fix it, if breaks the build and next days'
testsuite runs. It's actually pretty much irrelevant if the change got
into trunk via a manual diff/patch/commit, or someone integrated a pull
request. What I meant is some automatic process, which makes sure you have
a linear history suitable for an SVN upstream commit, etc.

I agree that this could be solved with some engineering if enough
willpower and time (and insight into FPC's development process) is
available.

Indeed. Some of these "rules" or process ideas sound like an improvement
even if Git is not in the picture. :)

Charlie
_______________________________________________
fpc-other maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.or

[Dimitrios Chr. Ioannidis via fpc-other]

Hi,

Στις 2017-05-25 16:53, Sven Barth via fpc-other έγραψε:

< snip >

Maybe such a hypothesized integration system would be a bit more
rigorous depending on what files were changed? E.g. full build with
fullcycle plus testsuite run on Tier 1 targets if anything in compiler
and rtl was changed and only a full build if merely something in
packages was touched.

May I ask currently for "Tier 1" how many physical systems fpc team have
available for the automated test suite ?

regards,

[Dimitrios Chr. Ioannidis via fpc-other]

Hi,
Στις 2017-05-25 17:34, Sven Barth via fpc-other έγραψε:

< snip >

a core dev). Though we'd need to implement such restrictions anyway no
matter what we choose for the repo hosted on our own server...

Ok just setup gogs for testbed / evaluation at
https://fpc-scm.nephelae.eu/ .

Anyone interested for admin credentials for evaluation just email me
privately .

regards,

[Dimitrios Chr. Ioannidis via fpc-other]

Hi,

Post by Dimitrios Chr. Ioannidis via fpc-other
Hi,
< snip >

a core dev). Though we'd need to implement such restrictions anyway no
matter what we choose for the repo hosted on our own server...

Ok just setup gogs for testbed / evaluation at
https://fpc-scm.nephelae.eu/ .

This machine is a private test VPS in a DataCenter in Germany, so feel
free to do whatever you want .

regards,

[Sven Barth via fpc-other]

2017-05-25 17:24 GMT+02:00 Dimitrios Chr. Ioannidis via fpc-other

Post by Dimitrios Chr. Ioannidis via fpc-other
Hi,
< snip >

a core dev). Though we'd need to implement such restrictions anyway no
matter what we choose for the repo hosted on our own server...

Ok just setup gogs for testbed / evaluation at https://fpc-scm.nephelae.eu/
.
Anyone interested for admin credentials for evaluation just email me
privately .

I appreciate the gesture, but if I'd want to evaluate it I'd do this
on my own system.

Regards,
Sven
_______________________________________________
fpc-other maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-b

[Dimitrios Chr. Ioannidis via fpc-other]

Hi,

Post by Sven Barth via fpc-other
2017-05-25 17:24 GMT+02:00 Dimitrios Chr. Ioannidis via fpc-other

< snip >

Post by Sven Barth via fpc-other

Post by Dimitrios Chr. Ioannidis via fpc-other
Ok just setup gogs for testbed / evaluation at
https://fpc-scm.nephelae.eu/
.
Anyone interested for admin credentials for evaluation just email me
privately .

I appreciate the gesture, but if I'd want to evaluate it I'd do this
on my own system.

I realize that yesterday I was little too spontaneous. I don't want to
look that I'm pushing in any direction .

Preferences noted ;)

regrads,

[Graeme Geldenhuys]

a core dev). Though we'd need to implement such restrictions anyway no
matter what we choose for the repo hosted on our own server...

Gitolite is brilliant at directory level, file level, branch level, site
level permissions, private branches support and more. It's very flexible
and uses git to configure itself - so config changes and new repo setups
can be done remotely, and as soon as you do the push the server is
updated and repos are created.

http://gitolite.com/gitolite/

It is also very simple to install and set up. Also a under 5 minute job.


ps:
I just thought I would point out that a web interface (Github, Gogs
and others) are not the only way to do pull requests. In fact,
pull requests via a email message is much more informative and
easier for other person to review. This is built into git.

For more information see:

$ git help request-pull

So you guys might want a daemon that scans the fpc-devel and
fpc-users mailing lists too. That's if you want to cover all
bases.


Regards,
Graeme

_______________________________________________
fpc-other maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/ma

[Dimitrios Chr. Ioannidis via fpc-other]

Hi,

Hi,

< snip >

who needs github when you have gogs ( https://gogs.io/ ) ?
It's a 5 minute setup and is very solid .

Actually, the irony is strong with this one, as Gogs hosts their own
source on Github. :) But it's actually looks like a cool interface if
one
needs self-hosted "Github", I like it, thanks for this.

GitHub is those days what sourceforge was 5 -8 years ago ;) .

For the company I work ( small team ) and for my personal projects Gogs
solved the usual "painfull" IT tasks reg. scm's .

regards,

[DaWorm]

emacs! vi!

Let's call the whole thing off and use EDLIN.

[n***@z505.com]

Post by DaWorm
emacs! vi!
Let's call the whole thing off and use EDLIN.

Don't forget mg

https://www.google.ca/search?q=mg+micro+gnu+emacs

From what I remember, this one had some nice simple C source code
instead of bloated projects..
_______________________________________________
fpc-other maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cg

[Tomas Hajny]

$ 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-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-ot

[Graeme Geldenhuys]

Post by Tomas Hajny
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-***@lists.freepascal.org
http://lists

[Tomas Hajny]

Post by Graeme Geldenhuys

Post by Tomas Hajny
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-***@lists.freepascal.org
http://lists.freepascal.or

[Luca Olivetti]

$ 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

[n***@z505.com]

Post by Graeme Geldenhuys

What happens if you use the SVN bridge that allows you to run svn
commands to a git server?

Maybe your wording is confusing, or SVN has abilities I didn't know
of. I know Git can manage SVN repositories, but I didn't know it was
possible other way round (I doubt it is possible).

I use it every day.

When I hired someone for a bounty, he introduced me to it, and I have
been using it ever since :-)
p.s. Thanks Dmitry! ;)

It's my stubborn old practice of not wanting to learn a new tool, Git,
when SVN was working quite fine for my needs, but I do admit I don't
have experience working with thousands/hundreds of developers all on the
same repo, I more use it for my own need.
_______________________________________________
fpc-other maillist - fpc-***@lists.freepascal.org
http://lists.freep

[Graeme Geldenhuys]

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-***@lists.freepascal.org
http://lists.freepas

[Graeme Geldenhuys]

Isn't java just a wrapper around C?

No. Java compilers generate code for a virtual machine, called JVM (Java
Virtual Machine). They do not generate code for x86 CPUs or any other
...snip...

Very nice explanation and detailed information.

x87 FPU instructions. Sounds so great, you're going to ask if there are
any disadvantages to this approach? And, of course, there are - since
the program is essentially recompiled every time the user runs it,
starting Java programs take a long time.

Technically correct, but you make it sound much worse than it really is.
Here Eclipse IDE starts up just as fast as Lazarus IDE. And Eclipse is
easily 10x or more bigger than Lazarus (when it comes to features). So
JIT does a pretty damn good job if you ask me.

Also JIT has improved tremendously over the last few years. In speed,
performance and optimisations. I have read somewhere that now it does a
[quick] compile to get your application up and running faster, then
after your app is running it can recompile some classes with even more
optimisations, and runtime reload those classes used by your
application. All done auto-magically in the background. ;-)

be a lot slower than a FPC program. I know comparing different IDEs is a
little apples-to-oranges comparison (because they may have different
features and vastly different implementation details), but compare the
speed of e.g. Lazarus to any IDE, written in Java, even the fastest one. :)

Lets just look at the two most popular Java IDEs - Eclipse and Intellij
IDEA. When they are running I don't experience any speed difference
comparing them to some native non-Java application of similar size.

It is also worth noting that both Eclipse and Intellij IDEA does a ton
more than Lazarus IDE. They both do deep code-analysis while you are
coding, making suggestions on how you can improve your code, can apply
those improvements with a single click or keyboard shortcut, have
extremely impressive refactoring functionality that makes Lazarus look
like Notepad. And the list goes on and on.

Lazarus is good, but it doesn't hold a candle against what Eclipse or
Entellij IDEA can [and does] do. Yes, yes, I know they have 100's or
1000's more developers too, and corporate backing. So making a
comparison between those IDE's and Lazarus is rather insane.

Always measure and try to understand why something is slow. In 99% of
the cases it's not what people initially think.

Indeed. I've learned a lot in the recent discussions, and I'm glad to
see the FPC team seem to be making some effort in improving the compiler
optimisation, instead of simply dismissing my work and comments.


Regards,
Graeme

[n***@z505.com]

Isn't java just a wrapper around C?

No. Java compilers generate code for a virtual machine, called JVM (Java
Virtual Machine). They do not generate code for x86 CPUs or any other
...snip...

But the virtual machine is just C code, so it's a wrapper around C, IMO

I could be wrong, but, all it does is end up calling C written VM,
right?
_______________________________________________
fpc-other maillist - fpc-***@lists.freepascal.org
http://

[Graeme Geldenhuys]

Post by n***@z505.com
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.

Post by n***@z505.com
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-***@lists.freepascal.org
http://lists.freepascal.org/c

[Nikolay Nikolov]

Post by n***@z505.com

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.

Post by n***@z505.com
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-***@lists.freepascal.org
http://lists.free

[Graeme Geldenhuys]

One question if I may. Subversion has revision numbers like 12345, and
it's comparatively easy to query that and build it into a piece of
software's version information.

And the same is true for Git. By design, distributed version control
systems (any of them, not just Git), can't rely on a sequential number.
The word "distributed" should say it all. True parallel development; no
single "server" instance etc.

Saying that, git includes a command 'git describe' which does what you
need. I find its result also way more useful and informative that a
single sequential revision number - which only has a mean to a
developer. Lets use an example:

[reportdesigner (reportdesigner)]$ git describe
v1.4.1-787-g45f932c1

What does that output tell me:
* Whatever code I'm working on is follow on from the "v1.4.1"
release.
* This line of [development] history has seen "787" commits
since the v1.4.1 release.
* The "g" prefix indications that the Git revision control
system was used.
* The "45f932c1" is the SHA1 value of the last commit, that
uniquely identifies where we are in the whole history of
the project. Irrespective of having 1 or a 1000 branches.

Now as with anything Git, everything is configurable. So the
git-describe commands has many optional parameters too. So you can
change the output to suite your project's needs. Things like should Tag
names be used in the git-describe output, or only Annotated Tags, or
only Branch names. Do we want the commit count, do we want the "g"
prefix, how long SHA1 value do we want etc etc.

Many applications incorporate such output in there version information.
See attached screenshot of one such example. I've seen plenty of others too.


What does a SubVersion revision r20453 tell you?

* Which branch are you on?
* Which release is this work based on?
* Is it a "hotfix" or new feature.
* Is it maybe a tag? Though Subversion doesn't really have a
concept of tags, as they are just branches in a bad disguise.

No, it only tells you that you are using commit number 20453.

So now the next thing you are probably going to tell me is that yeah but
I can use the revision number in Windows's version numbering as a
Revision or Build value. Yes and No. Only if your repository has less
than 65535 commits - the maximum a WORD type supports. So what happens
if you have more commits that that? Many large projects do.

It's also trivial for a developer to
look at the revision that he's currently working with, to say whether
it's older or newer than revision 12345,

As I just explained. The git-describe output tells you that and more.

and to get a log of what the
relative changes were by /only/ knowing the revision number.

Nothing new, Git does that too. Git (no surprise) even goes further and
also tells you the Parent(s) commit that got you there, the
Child/Children commits following on, what branch it is on and what Tags
this commit follows.


Regards,
Graeme

[Graeme Geldenhuys]

some info is at
http://llvm.org/docs/Proposals/GitHubMove.html#on-managing-revision-numbers-with-git
merging, external repos were some of the other issues.

Good Lord, who wrote that, and when? Clearly someone with a serious lack
of Git knowlegde - just the thing I described 2 replies ago.

"
However, we propose to mandate making merge commits illegal in our
canonical Git repository.
"

WTF? Branching and Merging are two key feature of Git. So if the don't
want merging (or only allow fast-forward merges), I guess they want to
Rebase everything everybody contributes - yeah the lovely linear history
of SubVersion.... because they don't know better.


Regards,
Graeme

[Martin Frb]

Post by Graeme Geldenhuys
WTF? Branching and Merging are two key feature of Git. So if the don't
want merging (or only allow fast-forward merges), I guess they want to
Rebase everything everybody contributes - yeah the lovely linear
history of SubVersion.... because they don't know better.

Or maybe they haven't forgotten how nice and simple svn is.

Git just doesn't do KISS.

---
(I use both git and svn, and both have things that I personally miss on
the other)

But at least this thread is highly amusing, so thanks for that.... ;)

_______________________________________________
fpc-other maillist - fpc-***@lists.freepascal.org
http://li

[Graeme Geldenhuys]

Post by Martin Frb
Git just doesn't do KISS.

Git is as complicated as you want it to be.



If you want to use it like SVN, then go right ahead. You will miss out a
lot though. I always recommend newcomers to start out with the basic 4-5
commands (same as SVN). Then as your confidence grows, introduce new Git
functionality.

And contrary to what many may think, it is pretty near impossible to
f*ck your repository up so that things are unrecoverable. As long as
something was committed, that something can be recovered, or commands
can be undone (yes, even deleted branches). Try that with SubVersion!

Regards,
Graeme

[Karoly Balogh (Charlie/SGR)]

Hi,

Post by Martin Frb
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.

Post by Martin Frb
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-***@lists.freepascal.org
http://lists.freepascal.or

[Florian Klämpfl]

Post by Karoly Balogh (Charlie/SGR)
Hi,

Post by Martin Frb
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.

Post by Martin Frb
Git just doesn't do KISS.

You need an SVN server to start working with SVN.

Every tried:

C:\temp>svnadmin create repos

C:\temp>svn checkout file:///c:/temp/repos wc
Checked out revision 0.

?

Post by Karoly Balogh (Charlie/SGR)
Also, ever tried to do partial commits in SVN? (Not committing all the
changes in a single file.) (git add --patch)

I do it daily with FPC (using TortoiseSVN though).

_______________________________________________
fpc-other maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-b

[Karoly Balogh (Charlie/SGR)]

Hi,

Post by Florian Klämpfl
C:\temp>svnadmin create repos
C:\temp>svn checkout file:///c:/temp/repos wc
Checked out revision 0.
?

No, nice to know this works, thanks. However, then if you try to publish
this repo outside of your computer, it gets a bit hairy. (Nothing
unsolvable, but nothing which I would describe as KISS anyway.)

Post by Florian Klämpfl

Post by Karoly Balogh (Charlie/SGR)
Also, ever tried to do partial commits in SVN? (Not committing all the
changes in a single file.) (git add --patch)

I do it daily with FPC (using TortoiseSVN though).

Yes, TortoiseSVN makes this bearable, this was more or less the only
reason I used a Windows 7 box + Linux VirtualBox combo for development at
the last company which used SVN. :) But it's not the feature of SVN as
such.

Charlie
_______________________________________________
fpc-other maillist - fpc-***@lists.freepascal.org
http://lists.fr

[Sven Barth via fpc-other]

Post by Karoly Balogh (Charlie/SGR)
Also, ever tried to do partial commits in SVN? (Not committing all the
changes in a single file.) (git add --patch)

To be fair: at least on Windows that is very easy with the help of
TortoiseSVN :)

Regards,
Sven
_______________________________________________
fpc-other maillist - fpc-***@lists.freepascal.org
http://lists.freepascal

[Graeme Geldenhuys]

Now, how the actual process would look with the FPC team, that's hard to
define at this point. But the tools are there for it.

Exactly what I was getting at.

Was this a proper answer, or I was beating around the bush in your views?
:)

Finally somebody that understands distributed version control, and how
Git could be used. You gave a very good answer indeed. Too many people
(and companies) are so stead fast in the ways of a client/server version
control system - like SubVersion. They then wrongly (or not ideal) force
those ideas onto Git usage. Hence the reason I said it takes a bit or
"rethinking the problem", and in the end everything becomes quite clear.

For those interested, read the many blobs about how the Linux Kernel
development is managed. Or even how Git's development itself is managed.
True distributed workflow models.

Regards,
Graeme

[Florian Klämpfl]

Post by Graeme Geldenhuys

Now, how the actual process would look with the FPC team, that's hard to
define at this point. But the tools are there for it.

Exactly what I was getting at.

Was this a proper answer, or I was beating around the bush in your views?
:)

Finally somebody that understands distributed version control, and how Git could be used. You gave a
very good answer indeed. Too many people (and companies) are so stead fast in the ways of a
client/server version control system - like SubVersion. They then wrongly (or not ideal) force those
ideas onto Git usage. Hence the reason I said it takes a bit or "rethinking the problem", and in the
end everything becomes quite clear.
For those interested, read the many blobs about how the Linux Kernel development is managed.

FPC is a compiler and not an OS kernel, so would like to see such blog posts from big compilers:
e.g. gcc, clang
_______________________________________________
fpc-other maillist - fpc-***@lists.freepascal.org
http://lists.fr

[Karoly Balogh (Charlie/SGR)]

Hi,

Post by Florian Klämpfl

Post by Graeme Geldenhuys
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-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/li

[Florian Klämpfl]

Post by Karoly Balogh (Charlie/SGR)
Hi,

Post by Florian Klämpfl

Post by Graeme Geldenhuys
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
https://gcc.gnu.org/wiki/GitMirror

So first problem identified: no git mirror of the full fpc repository :)

_______________________________________________
fpc-other maillist - fpc-***@lists.freepascal.org
http://lists.fre

[Graeme Geldenhuys]

Post by Florian Klämpfl
FPC is a compiler and not an OS kernel, so would like to see such
blog posts from big compilers: e.g. gcc, clang

OS Kernel, Compiler, any other project - what's the difference. Git
development itself is managed in a very "distributed" way with multiple
branches, maintenance releases etc. And more impressively, all branch
merging is done by a single person. Their processes are quite well
documented, and if you see how active the Git development is, it goes a
long way proving that even a very active project can be managed by very
few (one in this case).

My point is, you can learn from them to see how a project can be managed
without adding extra work-load to one person or a small team (like FPC).

Regards,
Graeme

[Florian Klämpfl]

1., Have his own clone of the FPC repository. Create his local webassembly
branch, and keep happily working on his local copy, then leave it rot
when he loses motivation, doesn't distract anyone.

... and the code is lost :)
_______________________________________________
fpc-other maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-

[Graeme Geldenhuys]

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

[Graeme Geldenhuys]

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

[Lukasz Sokol]

Post by Florian Klämpfl
... and the code is lost :)

Not at all, I have about 20+ local branches in my fpGUI
repository. Some branches date back to 2009, 2010. Ideas I had, but
lost motivation, or they were simply an experiment (that could be
useful at some point). Just 2 days ago I revived a 5 year old
branch and finally completed the work.

But what happens with corrupted or failed hard drive on your personal
computer? Do you have any backups or is this local git work only on
one personal hard drive that could fail at any time?
Sorry, I've just had too many hard drives fail on me... so many fail
that it's almost as if someone was doing it on purpose to me.
Do you make some backups on a usb stick or some server elsewhere no
one can see?

Nothing stops you from using a remote git server on some private remote hosting server,
that gets backed up regularly.

Or having a dedicated git server in your LAN, that you regularly backup.

Or indeed, make regular backups of your working directory, on one or more external media;
it's as easy as COPY THE ENTIRE DIRECTORY.

-L.

_______________________________________________
fpc-other maillist - fpc-***@lists.freepascal.org
http://lists.freepasca

[Florian Klämpfl]

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.
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-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/f

[Florian Klämpfl]

Post by Florian Klämpfl

I'm sorry to bust your bubble, but how different can compiler
development be.

Then why are you still talking to me.

To avoid that people get the impression we do not know what we are doing (or not doing).

Post by Florian Klämpfl
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.

To close this for now and ever: I am using hg at least since 2008 and git at least since 2011 when
it got popular on windows (both natively), hg daily for several periods. And overall the experience
collected during this is for sure a reason (besides others!) why using a dvcs for FPC development is
not a good thing.

And let me also state when we can open is discussion again:

Either
- FPC gets that much "third party" contributions that managing and merging them gets a problem of
the scm, we are light years away from this point though.
or
- Somebody pops up who has the time and motivation to push and to do(!) the migration. This does not
mean to do a half baked conversion of the fpc-svn but the whole process, e.g. starting with a wiki
page collecting all issues and working out solutions, adapting all scripts for release building
etc., fixing all snapshot and regression test machines and it ends up with helping the low traffic
contributors to get their work committed (and pushed!). This is at least one month of work I (and
probably nobody else) can and want to spent.
_______________________________________________
fpc-other maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailma

[Graeme Geldenhuys]

Post by Florian Klämpfl
This is at least one month of work I (and
probably nobody else) can and want to spent.

And some how I believe that will never happen (or be allowed) even if I
(or somebody else) decide to donate a month of our time. I fear the
resistance will outweigh the dedication to accomplish this task. This
was made abundantly clear to me now.

Regards,
Graeme

_______________________________________________
fpc-other maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-ot

[Nikolay Nikolov]

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-***@lists.freepascal.org
http:/

[Graeme Geldenhuys]

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

[Santiago A.]

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 ;-) :-(

[Graeme Geldenhuys]

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/***@vger.kernel.org/msg76433.html


Regards,
Graeme

[Nikolay Nikolov]

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 you get the idea ;-)

Nikolay
_______________________________________________
fpc-other maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.or

[Florian Klämpfl]

[...]

In fact, you can easily fit a lot
more people in the truck. You just put benches in the cargo area.

Great comparison :)

I hope you get the idea ;-)

I fear he will not.
_______________________________________________
fpc-other maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mail

[Marco van de Voort]

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-***@lists.freepascal.org
http://lists.freepascal

[Florian Klämpfl]

But I get in now. You guys are set in your ways - good or bad, and currently not willing to change.
So I'll leave it at that.

Thanks. I hope I might quote you in a few weeks/months/years :)
_______________________________________________
fpc-other maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo

[Graeme Geldenhuys]

Post by Graeme Geldenhuys
[reportdesigner (reportdesigner)]$ git describe
v1.4.1-787-g45f932c1
* 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

[Florian Klämpfl]

so they just use
git-svn.

This is what I do as well for several things, but I still think, subversion is the better solution
as the canonical FPC repository.
_______________________________________________
fpc-other maillist - fpc-***@lists.freepascal.org
http://lists.free

[Karoly Balogh (Charlie/SGR)]

Hi,

Post by Florian Klämpfl

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
*loooong* way to admit that. In late-2009 early-2010 I sounded more
anti-Git than Marco. :)

Charlie
_______________________________________________
fpc-other maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/lis

[Graeme Geldenhuys]

Post by Florian Klämpfl
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-***@lists.freepascal.org
http://lists.

[Marco van de Voort]

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.

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-***@lists.freepascal.org
http://l

[Marco van de Voort]

Workflows are designed according with the tools you had when you
designed it. Sometimes you improve your workflow as you improve your
knowledge of tools. And sometimes you create new tools to improve your
workflow.
But sometimes other people create a new tools that improves the system
but requires a dramatic change of workflow for better. I know Changing
of mindset is never easy, but the attitude of "I won't change my
workflow" closes the doors to any improvement.
Many projects are using Git, we are not talking about early adopters or
isnewisbetter guys. It has been tested in real world for several year,
and may projects are moving to it. So I would give it a second chance.
I'm doing so, in spite I'm not exactly a young boy and early adopter, I
can see some advantages in git easy branching and merging.
Evaluate git and workflows again as for the first time, as if it were
the first time you have heard about it. Forget Graeme Geldenhuys,
sometimes he says things with manners that.... well, sometimes is looks
like seducing people is not among his virtues but the other way around
;-), Take a new fresh look to Git.

I've done so every time the discussion looks up. I also have some DVCS
experience with Mercurial, and I still don't see it.
_______________________________________________
fpc-other maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/m

[Marco van de Voort]

donate a month of our time.

Indeed, it depends on the person who does it. It requires knowledge about the specific workflow
requirements of a compiler project. And that this is not easy is proven by the fact that gcc as well
as llvm still use svn as canonical repository. They probably have a lot more man power than FPC.

So does FreeBSD, (though IIRC they also use Perforce internally), so even it
is not pinacle of OS kernel development either :-)
_______________________________________________
fpc-other maillist - fpc-***@lists.freepascal.org
http://lists.

[Sven Barth via fpc-other]

Of course the biggest obstacle is the building and running of the
testsuite.

I think running the testsuite is a waste of time and cycles for anything
outside compiler/ and rtl/. And even for half of the RTL.

I essentially agree which is why I wrote in my message to Charlie a
moment ago that the integration system could differentiate here based
on what files were changed.
Though maybe partial testsuite runs would be useful as well, e.g. if
something changed in the rtti unit (which is in the rtl-objpas
package) the tests for that unit/package should at least be run. This
of course would require a few more adjustments to the testsuite, but
it wouldn't be an unsolveable problem.

Regards,
Sven
_______________________________________________
fpc-other maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi

[Marco van de Voort]

Post by n***@z505.com
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-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailm