Re: [fpc-pascal] Cross compile linux->solaris?

2017-04-28 Thread Mark Morgan Lloyd

On 28/04/17 18:04, Bart wrote:

Hi,
Thought it would be fun to test a little cgi web programming.
The server tha hosts my website returns this (on unam -a):SunOS aklathep 5.10 
Generic_150401-49 i86pc i386 i86pc Solaris
I only have (32-bit) fpc on Windows and Linux.Does anyone have a working cross 
compile setup from linux32 -> solaris?


No, I've only built it for SPARC.

--
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

[fpc-pascal] Cross compile linux->solaris?

2017-04-28 Thread Bart
Hi,

Thought it would be fun to test a little cgi web programming.

The server tha hosts my website returns this (on unam -a):
SunOS aklathep 5.10 Generic_150401-49 i86pc i386 i86pc Solaris

I only have (32-bit) fpc on Windows and Linux.
Does anyone have a working cross compile setup from linux32 -> solaris?

The error messages upon "compiling" a perl script are a PITA compared
to the messages from the fpc compiler.

PERL: Syntax error line 3 near print  (line 3 being the last and empty
line of the file)
Freepascal: Fatal: Syntax error, ";" expected but "identifier WRITELN" found

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

Re: [fpc-pascal] Correct syntax for initialized constants/variables

2017-04-28 Thread Ralf Quint
On 4/27/2017 12:22 PM, Ewald wrote:
> On 27/04/17 20:49, Ralf Quint wrote:
>> I try to include some initialized constants/variables in an application
>> of mine, but somehow stumbled upon a stupid little problem that I can't
>> figure out myself after nights on the computer.
>>
>> I see in the reference docs (section 4.4) examples for arrays and
>> examples for records, but in my case, I would need to properly define an
>> array of records.
> Something like this?
>
> Type
>   TA = Record
>   a: Integer;
>   End;
>
> Var
>   SomeArray: Array[0..1] of TA = (
>   (a: 42;),
>   (a: 17;)
>   );
Never mind, I just found my problem. Quite embarrassing for someone
programming in Pascal for 41 years, who should know better as to where
to put a comma and where to put a semicolon... :-[
Just picture me slapping myself hard for the next hour or two... :-!

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] Record operator for assignment

2017-04-28 Thread Sven Barth via fpc-pascal
Am 28.04.2017 14:09 schrieb "Mark Morgan Lloyd" <
markmll.fpc-pas...@telemetry.co.uk>:
> Is there any way that the length of an array being used for that sort of
job can be defined by what's put into it, rather than having to be
predefined?

No, there is not. Though I already had the idea that such preinitialized
dynamic arrays (because that's what they'd need to be for consistency)
could be implemented. Alas that's another small point on my huge ToDo
list... :/

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

Re: [fpc-pascal] Record operator for assignment

2017-04-28 Thread Mark Morgan Lloyd

On 28/04/17 04:30, Ryan Joseph wrote:

Instead of making constructors and doing busy work It would be nice if Free 
Pascal could let you assign records outside of type blocks like:
rec := (x: 0; y: 0; z: 0);
Why isn’t this possible btw? I saw some C++ code do this and it seems like an 
obvious solution that should have existed 20 years ago. The feature exists for 
type blocks so why not just enable it for other parts of code?
I had another idea to make this a little simpler by using open arrays and 
operator overloading. The compiler doesn’t permit this however. Is it a bug, my 
code or just a limitation?


Curiously, I was up against exactly the same thing yesterday when 
setting up an array for GetLongOpts() and a table for tokenising some 
other text elements.


I ended up using a dynamic array and overloading + for the first of 
those since it allowed me to do


  with option do begin
name := 'block';
value := name[1]   <===
  end;
  theOpts += option;

which wouldn't be available at compilation time, and also since 
build-time directives could easily include/exclude options. For the 
other one I used an array of records.


The problem with arrays of records as I see it is that the number of 
elements has to be predefined:


const   TopMatchItem= 10;

typeTMatchItem= record
  name: string;
  field: TCSVField
end;
TAMatchItem= array[0..TopMatchItem] of TMatchItem;

const   matchItems: TAMatchItem= ((name: ''; field: CSVBad),
  (name: 'block'; field: CSVBlock),
..

Or from the FPC compiler itself:

  ttokenarray=array[ttoken] of tokenrec;
  ptokenarray=^ttokenarray;
..

const
  arraytokeninfo : ttokenarray =(
  (str:''  ;special:true ;keyword:[m_none];op:NOTOKEN),
..

Is there any way that the length of an array being used for that sort of 
job can be defined by what's put into it, rather than having to be 
predefined?


--
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] Record operator for assignment

2017-04-28 Thread Sven Barth via fpc-pascal
Am 28.04.2017 09:23 schrieb "Ryan Joseph" :
>
>
> > On Apr 28, 2017, at 1:06 PM, Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> >
> > No, I mean
> >
> > rec := (x + y) * 2;
> >
> > The compiler has to differentiate these two.
>
> I see. It’s the parenthesis that are problematic. I guess the solution
would be curly brackets:
>
> rec := {x: 1; y: 2; z: 1}

Curly brackets are comments!

> or some magic function like writeln:
>
> rec := TMyRec(x: 1; y: 2; z: 1)

That could be a possibility as the compiler could then correctly handle the
field names, however it would have an ambiguity with typecasts until the
colon.
Though that would be solvable...

> rec := @(x: 1; y: 2; z: 1)

@ would be nonsense as that would denote a pointer.

> etc…
>
> Anyway it could be achieved that would be nice to have a built in
constructor for records on the language level.
>

Well, feel free to develop a patch, maybe it'll be accepted. I have other
fish to fry in the meantime.

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

Re: [fpc-pascal] Record operator for assignment

2017-04-28 Thread LacaK



I see. It’s the parenthesis that are problematic. I guess the solution would be 
curly brackets:

rec := {x: 1; y: 2; z: 1}

or some magic function like writeln:

rec := TMyRec(x: 1; y: 2; z: 1)

rec := @(x: 1; y: 2; z: 1)

etc…

or use like dynamic array constructor:
(MyArr := TMyDynArrType.Create(value1, value2) );)

rec := TMyRec.Create(x: 1; y: 2; z: 1);

;-)
-Laco.

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

Re: [fpc-pascal] Record operator for assignment

2017-04-28 Thread Ryan Joseph

> On Apr 28, 2017, at 1:06 PM, Sven Barth via fpc-pascal 
>  wrote:
> 
> No, I mean
> 
> rec := (x + y) * 2;
> 
> The compiler has to differentiate these two.

I see. It’s the parenthesis that are problematic. I guess the solution would be 
curly brackets:

rec := {x: 1; y: 2; z: 1}

or some magic function like writeln:

rec := TMyRec(x: 1; y: 2; z: 1)

rec := @(x: 1; y: 2; z: 1)

etc…

Anyway it could be achieved that would be nice to have a built in constructor 
for records on the language level.



Regards,
Ryan Joseph

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

Re: [fpc-pascal] Record operator for assignment

2017-04-28 Thread Sven Barth via fpc-pascal
On 28.04.2017 08:01, Ryan Joseph wrote:
> 
>> On Apr 28, 2017, at 12:43 PM, Sven Barth via fpc-pascal 
>>  wrote:
>>
>> It would introduce an ambiguity as "(x" could also complete to other 
>> expressions (e.g. "(x + y) * 2" or even merely "(x)"). Especially older 
>> Pascal compilers were geared towards the simplicity of the language and thus 
>> they didn't add it. For FPC it simply never came up.
> 
> I never thought about it either until I saw some c++ code doing it. Despite 
> having overlooked it, it’s basically a built in record constructor that’s 
> been in the language since forever. First it was making functions that paired 
> with records and now it’s constructors and "advanced record syntax" when the 
> more obvious and simpler solution was there all along. Maybe I’m crazy 
> though. ;)
> 
> You mean like: 
> 
> rec := (x: (x + y) * 2; y: 0; z: 0);

No, I mean

rec := (x + y) * 2;

The compiler has to differentiate these two.

> Why can’t everything between : and ; just be treated like a normal 
> assignment? “x” is already defined but it’s just a label and not part of the 
> assignment.

And that's another point. The compiler does not know what "x", "y" and
"z" are, cause it doesn't care about the left hand side of the
assignment until *after* the right hand side is parsed (in a var/const
section it knows the type; that's a different situation).
So a different syntax would be needed that would allow the compiler to
know that it's parsing a specific record type.

>>
>> The compiler currently prefers to cast array constructors towards sets, 
>> especially if they contain values that could be expressed as a set. That 
>> will change once proper support for array constructors is added. Though I 
>> don't know whether this would work then ;)
> 
> Huh, that syntax works in constructors, just not in the operator overloading. 
> Anyways I guess I’ll just assume that’s not implemented behavior.

Because in that case it knows that it's a parameter and handles that
differently. A type conversion is a different case.

Regards,
Sven

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

Re: [fpc-pascal] Record operator for assignment

2017-04-28 Thread Ryan Joseph

> On Apr 28, 2017, at 12:43 PM, Sven Barth via fpc-pascal 
>  wrote:
> 
> It would introduce an ambiguity as "(x" could also complete to other 
> expressions (e.g. "(x + y) * 2" or even merely "(x)"). Especially older 
> Pascal compilers were geared towards the simplicity of the language and thus 
> they didn't add it. For FPC it simply never came up.

I never thought about it either until I saw some c++ code doing it. Despite 
having overlooked it, it’s basically a built in record constructor that’s been 
in the language since forever. First it was making functions that paired with 
records and now it’s constructors and "advanced record syntax" when the more 
obvious and simpler solution was there all along. Maybe I’m crazy though. ;)

You mean like: 

rec := (x: (x + y) * 2; y: 0; z: 0);

Why can’t everything between : and ; just be treated like a normal assignment? 
“x” is already defined but it’s just a label and not part of the assignment.

> 
> The compiler currently prefers to cast array constructors towards sets, 
> especially if they contain values that could be expressed as a set. That will 
> change once proper support for array constructors is added. Though I don't 
> know whether this would work then ;)

Huh, that syntax works in constructors, just not in the operator overloading. 
Anyways I guess I’ll just assume that’s not implemented behavior.

Thanks.

Regards,
Ryan Joseph

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