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

[Graeme Geldenhuys]

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?

[Jürgen Hestermann]

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?

[Jürgen Hestermann]

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?

[Jürgen Hestermann]

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?

[Nikolay Nikolov]

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] [fpc-pascal] FPC Graphics options?

[Karoly Balogh (Charlie/SGR)]

Hi,

On Wed, 24 May 2017, Nikolay Nikolov wrote:

> Yes, this is one of the horrible things I have beef with. I have several.
> ()
> 2) the fact that the array size is not exactly part of the type. In case
> you're wondering what this means, if you declare:
>
> int a[5];
>
> sizeof(a) gives you the correct size of the array. However, if you pass
> this array as a parameter to a function:
>
> void func(int array_param[5])
> {
>  // inside the function, sizeof(array_param) gives you the size
> of a pointer, and not the array size
> }
>
> That's one of the reasons you can't add range checking to C compilers.

Ah, I love this. :) Thanks for this, I didn't know. Will put it on my
list. :)

> this is bad language design. Bonus points for the fact that writing this
> ugliness:
>
>if (5 == i)
>  do_something();
>
> is considered a very good practice by some people, just because it
> prevents you from being burned if you write if (5 = i) instead :)

These are nicknamed Yoda conditions. :)

> 4) the badly designed standard library. Even though C "strings" suck by
> design, the library functions, that operate on them have extra hidden
> traps. For example, using strcpy is unsafe, because it doesn't check the
> size of the destination buffer, that's why you must use strncpy.
> However, this code:
>
> char dest[1000];
> strncpy(dest, src, sizeof(dest));
>
> is still unsafe. Why? Because if src is 1000 characters or larger, even
> though strncpy will not overwrite past the end of the dest array, it
> will _not_ put a null terminator in the dest array. On top of that, it
> is also suboptimal - if src is shorter, strncpy will fill the entire
> array past the end of the string with null characters. So, if src is a
> 10 character string, strncpy will write 990 null characters, filling the
> area between dest[10] and dest[999], wasting CPU cycles on that.

OK, this is also beautiful, thanks again. :) BSDs seem to have strlcpy()
tho', which works around both defects mentioned here, but that's non
standard obviously, because who needs standard functions which make sense.
:)

Charlie
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

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

[Nikolay Nikolov]

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?

[Karoly Balogh (Charlie/SGR)]

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] [fpc-pascal] FPC Graphics options?

[Nikolay Nikolov]

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?

[Nikolay Nikolov]

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] [fpc-pascal] FPC Graphics options?

[wkitty42]

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] [fpc-pascal] FPC Graphics options?

[Graeme Geldenhuys]

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?

[Graeme Geldenhuys]

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] [fpc-pascal] FPC Graphics options?

[Graeme Geldenhuys]

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] [fpc-pascal] FPC Graphics options?

[Ralf Quint]

On 5/23/2017 7:19 PM, wkitt...@windstream.net wrote:
> On 05/23/2017 09:56 PM, nore...@z505.com wrote:
>> The C struct is literally the pascal record, and is all based on the
>> same Structured Programming work by Dijkstra
>
> except that the C struct does not have the array length at position
> zero and you have to process until you hit the first null character...
> that's the plus for pascal strings... you know how long the string is
> from the start... unless it is a unicode string ;)
>
Well, the problem is that you can't use those handy Pascal strings that
much anymore these days. Ever since you need to use UTF8 to properly
represent textual context, this all has become one hell of a mess,
pretty leveling the playing field when it comes to handling such strings
with (Free)Pascalor C...

Ralf


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

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

[wkitty42]

On 05/23/2017 09:52 PM, nore...@z505.com wrote:

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


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


--
 NOTE: No off-list assistance is given without prior approval.
   *Please keep mailing list traffic on the list unless*
   *a signed and pre-paid contract is in effect with us.*
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

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

[wkitty42]

On 05/23/2017 09:56 PM, nore...@z505.com wrote:
The C struct is literally the pascal record, and is all based on the same 
Structured Programming work by Dijkstra


except that the C struct does not have the array length at position zero and you 
have to process until you hit the first null character... that's the plus for 
pascal strings... you know how long the string is from the start... unless it is 
a unicode string ;)


--
 NOTE: No off-list assistance is given without prior approval.
   *Please keep mailing list traffic on the list unless*
   *a signed and pre-paid contract is in effect with us.*
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

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

[noreply]

On 2017-05-22 18:39, Graeme Geldenhuys wrote:

On 2017-05-22 22:45, nore...@z505.com wrote:
The amount of nesting and indented procedures inside classes in Java 
is

horrible, IMO.


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

Regards,
  Graeme


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

{
   {
{
   here

Instead of fpc/oberon/golang:

func {

  code here


or

procedure TSomeObj.Example
begin
  code here


instead of

...
   ...
  ...code here

Just to do basic bloody damn things, Java and C# require ridiculous 
obnoxious nests/indentations.


No talking about 2 vs 8 space indentation choices, although that's 
another issue

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

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

[noreply]

On 2017-05-23 01:03, Nikolay Nikolov wrote:

Isn't java just a wrapper around C?
No. Java compilers generate code for a virtual machine, called JVM 
(Java

Virtual Machine). They do not generate code for x86 CPUs or any other
 ...snip...



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

I could be wrong, but, all it does is end up calling C written VM, 
right?

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

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

[noreply]

On 2017-05-22 18:53, Graeme Geldenhuys wrote:

On 2017-05-22 23:39, nore...@z505.com wrote:

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


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



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


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


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

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

The C struct is literally the pascal record, and is all based on the 
same Structured Programming work by Dijkstra

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

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

[Nikolay Nikolov]

On 05/23/2017 01:35 AM, nore...@z505.com wrote:

On 2017-05-18 10:12, Graeme Geldenhuys wrote:

On 2017-05-18 16:04, Ryan Joseph wrote:

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

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

[noreply]

On 2017-05-18 10:05, Graeme Geldenhuys wrote:

On 2017-05-18 15:58, Reimar Grabowski wrote:

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

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

[noreply]

On 2017-05-21 07:58, Felipe Monteiro de Carvalho wrote:

On Thu, May 18, 2017 at 5:05 PM, Graeme Geldenhuys
 wrote:
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-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

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

[Graeme Geldenhuys]

On 2017-05-14 13:58, Graeme Geldenhuys wrote:

Yes, and based on OpenJDK with their own additions - just like Oracle is
doing.


I forgot to say... But to be fair, most of the information regarding 
Oracle's Java releases, OpenJDK, IBM J9 etc is pretty murky.


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?

[Jonas Maebe]

Graeme Geldenhuys wrote:
> Doesn't IBM, Linux, FreeBSD etc use OpenJDK? I was also under the
> impression that Oracle now also uses OpenJDK as the base for their
> releases - with some of their own additions. If this is all correct, it
> means they all pretty much use the same Java VM and Compiler
> implementations.

IBM has their own JVM, J9:
https://www.ibm.com/support/knowledgecenter/en/SSYKE2_7.0.0/com.ibm.java.win.70.doc/user/java_jvm.html


Jonas
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other