Re: [fpc-pascal] Is Generics.collections stable?

[Graeme Geldenhuys]

On 2016-04-21 04:44, Dennis wrote:
> Is it stable enough for production use?

I don't see a single unit test, so that would make me weary.

Regards,
  Graeme

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

Re: [fpc-pascal] Build in a C compiler

[Ralf Quint]

On 4/20/2016 4:29 AM, Rainer Stratmann wrote:

Am Mittwoch, 20. April 2016, 07:05:10 schrieb Mark Morgan Lloyd:

No. Pascal and ALGOL are closely related, C and ALGOL are closely
related. Pascal and C are not so closely related.

As you can see here Pascal, C, and Basic are very close related.

http://www.mikroe.com/compilers


I think you are jumping to conclusion here.
It is more likely that they spend the time in the past (they are around 
for quite a while) to build their specific Basic, Pascal and C compiler 
front end and just have to replace the actual code generator for each 
architecture they support.
Just because a company offers compilers for various languages, with a 
common IDE, doesn't mean that those compilers are "closely related".
Just take Borland of old, Turbo Pascal, Turbo C, Turbo Basic, Turbo 
Prolog, they all used a very similar IDE but the actual compiler had all 
completely different origins...


Ralf

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

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

Re: [fpc-pascal] Build in a C compiler

[Rainer Stratmann]

Am Mittwoch, 20. April 2016, 12:40:19 schrieb Mark Morgan Lloyd:
> > http://www.mikroe.com/compilers
> 
> If you want to believe that BASIC- as originally implemented- and ALGOL
> are related then go ahead and do so. But the politest thing I can say is
> that it doesn't make you look particularly well-informed.

You can go to the company and say poliltely to them that they are not well 
informed. I don't know if they take you serious.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FCL maskutils incompatible with Delphi

[Bart]

On 4/19/16, silvioprog  wrote:

> Yes, he (Handlei) reported it at Brazillian group, but he didn't tell us
> that had already reported that at bugtracker.
>
> The patch was sent from another member, and he told us that it fix the
> current maskutils.pp unit, I just sent it here as they asked me.
>
> Can I send this patch to #30020 or just wait for new MaskUtils
> implementation?

Send it to the bugreport anyway.
The new implementation I wrote is ot going to be implemented soon (see
related thread for reasons why).

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

Re: [fpc-pascal] Build in a C compiler

[Mark Morgan Lloyd]

Marco van de Voort wrote:

In our previous episode, Mark Morgan Lloyd said:

Pascal and C are close related.
No. Pascal and ALGOL are closely related, C and ALGOL are closely 
related. Pascal and C are not so closely related.


Did ALGOL standarize the preprocessor? The high reliance on preprocessor is
often a hinderance in automated C conversion.


Burroughs ALGOL (-60 implied) had include and define as part of the 
language. I think they were later moved into a preprocessor to make it 
possible to implement them on smaller computers.


Sorry, having a bad day so rushed.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Build in a C compiler

[Mark Morgan Lloyd]

Rainer Stratmann wrote:

Am Mittwoch, 20. April 2016, 07:05:10 schrieb Mark Morgan Lloyd:

No. Pascal and ALGOL are closely related, C and ALGOL are closely
related. Pascal and C are not so closely related.


As you can see here Pascal, C, and Basic are very close related.

http://www.mikroe.com/compilers


If you want to believe that BASIC- as originally implemented- and ALGOL 
are related then go ahead and do so. But the politest thing I can say is 
that it doesn't make you look particularly well-informed.


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Build in a C compiler

[Sven Barth]

Am 20.04.2016 13:29 schrieb "Rainer Stratmann" :
>
> Am Mittwoch, 20. April 2016, 07:05:10 schrieb Mark Morgan Lloyd:
> > No. Pascal and ALGOL are closely related, C and ALGOL are closely
> > related. Pascal and C are not so closely related.
>
> As you can see here Pascal, C, and Basic are very close related.
>
> http://www.mikroe.com/compilers

By that logic C#, C++, VB.net and F# must be closely related as well,
because Microsoft is providing compilers for all four...

No, C and Pascal are *not* closely related. And it surely isn't done with
replacing begin and end with curly brackets!

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Build in a C compiler

[Rainer Stratmann]

Am Mittwoch, 20. April 2016, 07:05:10 schrieb Mark Morgan Lloyd:
> No. Pascal and ALGOL are closely related, C and ALGOL are closely
> related. Pascal and C are not so closely related.

As you can see here Pascal, C, and Basic are very close related.

http://www.mikroe.com/compilers
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Build in a C compiler

[Marco van de Voort]

In our previous episode, Mark Morgan Lloyd said:
> > 
> > Pascal and C are close related.
> 
> No. Pascal and ALGOL are closely related, C and ALGOL are closely 
> related. Pascal and C are not so closely related.

Did ALGOL standarize the preprocessor? The high reliance on preprocessor is
often a hinderance in automated C conversion.
 
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more?

[Jonas Maebe]

Michael Schnell wrote on Tue, 19 Apr 2016:


On 04/19/2016 08:22 AM, Jonas Maebe wrote:
When any {$codepage xxx} directive is specified, string constants  
in the source are represented in a way that makes lossless  
conversion to any other code page possible. This conversion to the  
target code page is performed at compile time where possible (when  
the target code page cannot change at run time), and otherwise at  
run time.



Of course I do understand that.

But anyway, AFAIK, UTF8 already is a way of lossless coding, so I  
don't see a forcing necessity to convert that to UTF16 at compile  
time. And as far as I understand, if the user does not take some  
means, the executable will work with 8 bit coding and very likely  
with UTF8, > so holding the constants as UTF16 increases as well  
memory as CPU resource usage.


The reasons are
a) the FPC compiler binary itself prior to 3.x did not contain any  
UTF-8 encoding support. All it could do was convert the source file  
code page to UTF-16.
b) FPC's widestring manager does not contain any interface to directly  
convert from one 8 bit encoding to another, only from 16 bit to 8 bit  
and vice versa (which also made it useless to convert to UTF-8 at  
compile time, since there was no way to convert it to another code  
page at run time except by making a round trip via UTF-16 anyway). The  
reason is that these helpers were already necessary to convert between  
widestring/unicodestring and other types when assigning such variables  
to each other
c) changing b) would require a lot of testing because not all code  
page conversion libraries/OS interfaces support converting from any  
arbitrary character set to any other arbitrary character set. While it  
is likely that they all support converting from arbitrary code pages  
to UTF-8 and back (like they do for UTF-16), this would still have to  
be tested and additionally such an interface would undoubtedly also  
starting to get used for other code pages by people unaware of this  
limitation. Adding an interface limited to converting from/to UTF-8  
would be another option to address that though.


In the end it would be a lot of work, result in a lot of extra code  
that may not work everywhere (or in specialised routines), and it  
would be for a use case you can already address yourself if you  
absolutely want to be completely UTF-8-centric: you can declare your  
string variables as UTF8Stringm since then the conversion to UTF-8 for  
constant strings will happen at compile time. If your  
DefaultSystemCodePage is CP_UTF8, no extra conversion will happen when  
assigning/converting these variables to regular ansistrings.  
Furthermore, converting from UTF-8 to other code pages is probably  
slower than from UTF-16, since UTF-8 is a more complex encoding for  
most characters.


The fact that other things are less convenient if you use UTF8String  
is the price you will have to pay for such code specialisation (which  
probably won't make any noticeable difference in 99.999% of the cases  
anyway).



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

Re: [fpc-pascal] Problem using ipc with OSX and fpc 3.0.0

[Jonas Maebe]

Tony Whyman wrote on Wed, 20 Apr 2016:

The problem is that the code makes a direct call to the semctl  
function (defined in ipc.pp) and uses the SEM_GETVAL constant as the  
command value. "Identifier not found errors" are returned for  
SEM_GETVAL (and SEM_SETVAL as well).


That's indeed a bug in FPC 3.0, where these constants were  
accidentally disabled for Darwin. They have been re-enabled in svn  
already, and this fix will be in FPC 3.0.2.


To work around this bug, you can copy the constants to your own source  
file for now.



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

Re: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more?

[Michael Schnell]

BTW.:
http://www.freepascal.org/docs-html/rtl/system/defaultsystemcodepage.html says 
that DefaultSystemcodepage can be modified in the user code at runtime.


I suppose that will change the way strings with StringCodePage() = 
CP_ACP are handled.


I'll do some tests...

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

Re: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more?

[Michael Schnell]

On 04/19/2016 08:22 AM, Jonas Maebe wrote:
When any {$codepage xxx} directive is specified, string constants in 
the source are represented in a way that makes lossless conversion to 
any other code page possible. This conversion to the target code page 
is performed at compile time where possible (when the target code page 
cannot change at run time), and otherwise at run time.



Of course I do understand that.

But anyway, AFAIK, UTF8 already is a way of lossless coding, so I don't 
see a forcing necessity to convert that to UTF16 at compile time. And as 
far as I understand, if the user does not take some means, the 
executable will work with 8 bit coding and very likely with UTF8, so 
holding the constants as UTF16 increases as well memory as CPU resource 
usage.


(I am not trying to bash anybody ! It obviously does work nicely and 
supposedly close to always as expected, and the possible resource 
overhead will be extremely rare and minimal).


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

Re: [fpc-pascal] FPC 3 regression: cannot use TStringList for UTF-8 data any more?

[Michael Schnell]

On 04/19/2016 08:22 AM, Jonas Maebe wrote:


No, it does not. Please tell me which sentence of 
http://wiki.freepascal.org/FPC_Unicode_support#String_constants 
suggests that in any way.

I just was making fun of myself, naively supposing the contrary :-) ;-)

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

[fpc-pascal] Problem using ipc with OSX and fpc 3.0.0

[Tony Whyman]

I have a problem with some existing code that compiled with fpc 2.6.4 
under OSX and does not compile with fpc 3.0.0.


The problem is that the code makes a direct call to the semctl function 
(defined in ipc.pp) and uses the SEM_GETVAL constant as the command 
value. "Identifier not found errors" are returned for SEM_GETVAL (and 
SEM_SETVAL as well).


Checking the ipc.pp source, both SEM_GETVAL and SEM_SETVAL are defined 
for Linux, but when it comes to alternative flavours of unix you now see:


{$if not defined(aix) and not defined(darwin)}
  SEM_GETNCNT = 3;   { Return the value of sempid (READ)  }
  SEM_GETPID  = 4;   { Return the value of semval (READ)  }
  SEM_GETVAL  = 5;   { Return semvals into arg.array (READ)  }
  SEM_GETALL  = 6;   { Return the value of semzcnt (READ)  }
  SEM_GETZCNT = 7;   { Set the value of semval to arg.val (ALTER)  }
  SEM_SETVAL  = 8;   { Set semvals from arg.array (ALTER)  }
  SEM_SETALL  = 9;
{$endif}

That is these identifiers appear to have been removed for OSX and with 
no alternative given. This was not the case with 2.6.4.


Does anyone know why this was done and, if so, how calls to semctl 
should have their command value given under OSX (preferably in a 
platform independent manner).


Tony Whyman
MWA
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Build in a C compiler

[Maciej Izak]

2016-04-20 9:32 GMT+02:00 leledumbo :

> But your example doesn't show its use, probabyl you don't understand which
> comma operator I mean. Comma is used both as operator and
> argument/parameter
> separator in C, what I mean is the former, what you show is the latter.
> Here's the wikipedia article to make you understand:
> https://en.wikipedia.org/wiki/Comma_operator


In that case you are right.

-- 
Best regards,
Maciej Izak
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Build in a C compiler

[leledumbo]

> C's comma (sequence) operator is possible to use in Pascal

But your example doesn't show its use, probabyl you don't understand which
comma operator I mean. Comma is used both as operator and argument/parameter
separator in C, what I mean is the former, what you show is the latter.
Here's the wikipedia article to make you understand:
https://en.wikipedia.org/wiki/Comma_operator



--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/Build-in-a-C-compiler-tp5725008p5725013.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Build in a C compiler

[Maciej Izak]

2016-04-20 8:58 GMT+02:00 leledumbo :

> At syntax level, there's no Pascal equivalent
> of C's comma (sequence) operator. Argument evaluation in C is strictly
> right
> to left, in Pascal it's up to the compiler. A silly but valid C statement:
>
> printf("%d%d%d\n",i++,++i,++i,i++);
>
> would be hard to convert to Pascal automatically without blowing out the
> compiler.
>

C's comma (sequence) operator is possible to use in Pascal:

function printf(fmt: PAnsiChar): Integer; cdecl; varargs; external
'msvcrt.dll' name 'printf';

begin
  printf('%d%d%d'#10,1,2,3,4);
end.

-- 
Best regards,
Maciej Izak
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Build in a C compiler

[Mark Morgan Lloyd]

Rainer Stratmann wrote:

That would be great.

It is not that difficult.

{ = begin
} = end

and the other stuff is quite similar.

Pascal and C are close related.


No. Pascal and ALGOL are closely related, C and ALGOL are closely 
related. Pascal and C are not so closely related.


If you're looking for commonality go and use ALGOL, rather than making 
suggestions that are bound to result in a lot of sound and fury :-(


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Build in a C compiler

[leledumbo]

> That would be great. 

Nope

> It is not that difficult. 
> { = begin 
> } = end 
> 
> and the other stuff is quite similar. 

Syntax is easy, well once you have fully working preprocessor too, but how
about libraries? How will you convert scanf/printf/puts/etc? What if it uses
3rd party libraries?

> Pascal and C are close related.

Only at the surface. There are many semantics differences that's not
convertible at all. e.g.: ALL C expressions are potentially a boolean
expression which in turn has boolean value, while in Pascal, only boolean
expression has boolean value. At syntax level, there's no Pascal equivalent
of C's comma (sequence) operator. Argument evaluation in C is strictly right
to left, in Pascal it's up to the compiler. A silly but valid C statement:

printf("%d%d%d\n",i++,++i,++i,i++);

would be hard to convert to Pascal automatically without blowing out the
compiler.



--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/Build-in-a-C-compiler-tp5725008p5725010.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal