Re: [fpc-pascal] "Unexpected end of file" when having an open comment after the final "end."

[Ralf Quint via fpc-pascal]

On 2/8/2024 11:01 AM, Martin Wynne via fpc-pascal wrote:

Hi Thomas,

The error is not the file content after "end.".

The error is not having the expected "end;" after "begin".

This works ok:

_

program test;

begin
end;

end.

abc 123

_

Martin. 


This is not a valid Pascal source code to begin with (pun intended)...

The "begin" is the start of the actual Pascal program and by definition, 
that program is terminated by matching that with an "end." That's what 
the code completion in Lazarus for example is adding into a new "simple 
program" project source code.


Just adding a random "end;" should also just yield an error message...

Well, I actually did just tested this and it gives as expected an 
"Error: Syntax error,  "." expected but ";" found. It Doesn't even 
process past the "end." in that case.


What is however interesting is that an open comment, as mention by the 
OP,  immediately after the "end." results in the "Error: unexpected end 
of file" message, however any other addition text past that "end." will 
result in no error message and completing to compile the program 
successfully...


I just tried a couple more things, and it seems it is just the "{" or 
"(*" opening of a comment that is causing the error message, having a 
"//" comment until end of  line after the "end."  will also compile just 
fine



Ralf


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

Re: [fpc-pascal] Floating point question

[Ralf Quint via fpc-pascal]

On 2/4/2024 12:32 PM, James Richters via fpc-pascal wrote:


>> Not specifying in a program, specially in a strict programming 
language like Pascal, will always result in implementation depending


>> variations/assumptions.

The problem is, I feel that I DID specify what should be by declaring 
my variable as Extended. And Apparently FPC agrees with me, because it 
DOES work the way I expect, except if I put a .0 in my constant 
terms.This is all just a bug if you put .0 after any integers in an 
expression.I just put a better example that shows how it works 
correctly except if you put a .0


Strangely, upon discovering this, the solution is opposite what I 
thought it should be.If all the terms of an expression were reduced to 
the lowest precision possible without loosing data, then my 1440.0 
would be reduced from a float to a word, and then the entire problem 
would have went away, because when I put in 1440 without the .0, there 
is no problem.The .0 is apparently defining it to be a floating point 
and the smallest floating point is a single… but that’s not the 
smallest data structure, the smallest data structure that can be used 
is a word and that would have solved it.


Sorry, but that doesn't make any sense. If you just add the .0, you 
specify a floating point value, ANY floating point value. This is kind 
of obvious in a programming language that has only one type of floating 
point value (yes, they are less common these days as they used to be in 
the "days of old"). But you did not specify WHICH type of the possibly 
floating point values you are expecting, and there are three different 
ones (single, double, extended). What happens when you assume an 
integer/word/longint by omitting the decimal fraction, that's a 
different discussion.


But I would expect that you you explicitly use a typecast as in 
"extended (1440.0)" that the compiler is using an extended floating 
point calculation at that point. Specifying the resulting variable to be 
a specific type is IMHO not implying that ALL calculations of a whole 
expression are performed in that variable's type. If the compiler would 
ignore an explicit type cast of a constant, THEN I would call this a bug.



Ralf

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

Re: [fpc-pascal] Floating point question

[Ralf Quint via fpc-pascal]

On 2/4/2024 11:15 AM, James Richters via fpc-pascal wrote:

I understand that the result depends on the variables and expressions,
The problem with constants used in an expression is that some determination
needs to be made because it's not specified.
Since it's not specified, then I think it should be implied to be the same
as the variable it would be stored in, if that determination cannot be made,
then maximum precision should be used.
I don't think that this "implied" applies in my experience to pretty 
much all programming languages that I have used in the last 47 years 
that do offer various forms of floating point formats.
Not specifying in a program, specially in a strict programming language 
like Pascal, will always result in implementation depending 
variations/assumptions.


And if those variations are not to your liking, then simply specify 
(type cast) those constants to more precisely get the result you expect. 
This is Pascal after all, not Python or other over-ooped programming 
language that is making assumptions about your code all the time...



Ralf

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

Re: [fpc-pascal] Function to create a record ?

[Ralf Quint via fpc-pascal]

On 6/1/2023 5:36 PM, Steve Litt via fpc-pascal wrote:

Hi all,

I'm trying to create a function (called newperson()) that creates a new
instance of a record. The following compiles with no errors or warnings
in FPC, but multiple calls to newperson() produce exactly the same
variable, so in the preceding changing person changes person2, and vice
versa:

===
program test2;

const
junkvar_size = 2000;

type
personrecord = record
name: string;
end;
var
person: personrecord;
person2: personrecord;
junkvar: array[1..junkvar_size] of char;

function newperson(): personrecord;
var newp: personrecord;
begin
newp.name := '';
newperson := newp;
end;

function modperson(person: personrecord; name: string): personrecord;
begin
person.name := name;
modperson := person;
end;

procedure writeperson(person: personrecord);
begin
writeln(person.name);
end;

begin
person := newperson();
fillchar(junkvar, junkvar_size, 'a');
person2 := newperson();
fillchar(junkvar, junkvar_size, 'b');
person := modperson(person, 'Martin');
person := modperson(person2, 'Maria');
{writeln(junkvar);}
writeperson(person);
writeperson(person2);
end.
===

What is the best way for me to construct newperson() so that every time
called it would return a new variable?

W.T.F.?

Sorry, but for how long are you programming, in general, and for how 
long in Pascal?


Seriously, you should take some very basic Pascal tutorials, work 
through them, and in particular, pay close attention to the "scope" of 
variables as well as parameter passing. You seem to be completely 
oblivious to those very basics here... :(


Ralf


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

Re: [fpc-pascal] Oberon-0

[Ralf Quint via fpc-pascal]

On 4/19/2023 7:46 PM, Adriaan van Os via fpc-pascal wrote:

Ralf Quint via fpc-pascal wrote:


What does Oberon and Forth have to do with the FreePascal compiler? 😕


1. Niklaus Wirth
2. Strong resemblance between Oberon and Pascal
3. An early version of his book Compiler Construction used Pascal 
rather than Oberon


Well, still, neither one of those IMHO is a valid reason as to why this 
is discussed on a Free Pascal mailing list, beside possibly on 
fpc-other, as suggested.



Ralf


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

Re: [fpc-pascal] Oberon-0

[Ralf Quint via fpc-pascal]

On 4/19/2023 1:06 AM, Markus Greim via fpc-pascal wrote:
You are right there are in between many compilers for the Propeller 2 
around.

My idea would be a to have an Oberon system on the Propeller itself.
Developing on the target itself is unbeatable clever.
Is started 35 Years ago with the 8051-AH Basic processor and later on 
similar systems.


The Propeller 2 has already a built in Forth which is already a fine 
thing, but I am sure the Processor is powerful enough to run also a 
full Oberon

in the latest flavor of the RISC5 system.
The Oberon0 compiler would be necessary as bootstrap for a full Oberon 
system.
A native Oberon0 to Propeller ASM compiler would be fine, but maybe it 
would be easier to write first an Oberon0 to PropForth compiler.


What does Oberon and Forth have to do with the FreePascal compiler? 😕


Ralf

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

Re: [fpc-pascal] Cache-line alignment for records

[Ralf Quint via fpc-pascal]

On 3/29/2023 2:38 PM, Ched via fpc-pascal wrote:

Hello,

Ok for the records for internal calculations. But sometimes, records 
are used for reading/writing structured files. Does "packed" in 
"packed array" and "packed record" always forbid the compiler to play 
with alignments ? 


If that record/array is specifically defined as "packed", then yes, of 
course. However, arrays/records that are no so defined should be aligned...



Ralf


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

Re: [fpc-pascal] Converting old pascal written for Pascal/MT+ compiler

[Ralf Quint via fpc-pascal]

On 3/28/2023 3:12 AM, Marco van de Voort via fpc-pascal wrote:


On 28-3-2023 11:33, Karoly Balogh via fpc-pascal wrote:


Probably yes, but there might be an alternative, see below. But as 
far as

I understand, Unit is a Turbo Pascal concept, so any Pascal programming
dialect that predates it, probably don't understand it.


True, and before units in Turbo Pascal(*) and Modules in Extended 
Pascal, nothing was standardized about breaking up the source into 
multiple parts.


Most dialects either adopted some form of C "extern" like handling, 
and the more advanced ones some form of Modula2 derived modules, 
either directly, or via the lengthy Extended Pascal standardization 
process.


(*) Turbo Pascal was strictly not a standard, but influential enough 
to set one.


Units was actually something that was taken over from UCSD Pascal, which 
had them for more than a decade before Anders Hejlsberg introduced them 
with Turbo Pascal 4.0. They were omitted from the earlier versions due 
to space constraints on CP/M, then the CP/M versions were translated 
more or less 1:1 from Z80 to 8086 code and they were added when Turbo 
Pascal 4.0 was pretty much rewritten from scratch...



Ralf


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

Re: [fpc-pascal] Converting old pascal written for Pascal/MT+ compiler

[Ralf Quint via fpc-pascal]

On 3/27/2023 2:45 AM, Jacob Kroon via fpc-pascal wrote:

Hi,

I have some old Pascal code that was compiled in a CPM environment 
using the Pascal/MT+ compiler from Digital Research. I'm trying to get 
this project to build in a modern environment, for a start using 
FreePascal.


First, is anyone aware of a tool for converting this dialect of Pascal 
to something that FreePascal will accept ?


Well, it is a very long time since I used Pascal MT+ the last time, and 
that was already on the x86 version (+30 years now), but the same things 
should still apply.


First of all, Pascal MT+ is more or less ISO7185 compatible, so you 
would have to use that mode in FPC if you don't want to change all those 
file reference (that's what's mostly different to a "real" Pascal :P )


As for the "external" vars (and possibly procedures/functions), it is 
not quite the same as the units in UCSD/Turbo/Delphi/FreePascal, but it 
had the possibility (due to source code size restrictions, you had only 
64KB for OS, compiler and source code together) to compile different 
source files into separate object files, which then could be linked 
together with the linker. It is more of an "forward" declaration. In 
most cases, I would assume that you could actually copy all those source 
files that are being referenced into a single source file. Using units 
could work in a lot of cases, but which way to go might depend on your 
actual use case...



Ralf



Second, the old code contains a lot of:

var
foobar : external integer;

in sources that reference 'foobar', then there is a declaration in one 
of them:


var
foobar : integer;

As I understand it, in order to translate this to something that 
FreePascal understands, the variable needs to go in a "unit" and be 
part of its interface. Then, pascal sources that needs to reference 
the variable should use this unit. Is this the easiest way forward ?


I thought maybe I instead could adapt the syntax like:

var
foobar : integer; external;

but with this I still get undefined references when linking. Using 
units seems ok.


Bets regards
Jacob
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal



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

Re: [fpc-pascal] Working on a new way to educate people about pascal

[Ralf Quint via fpc-pascal]

On 12/31/2022 12:37 AM, Steve Litt via fpc-pascal wrote:

Anthony Walter via fpc-pascal said on Thu, 29 Dec 2022 07:31:57 -0500


@youngman

"I'm a database guy with maybe 30 years experience, I'm new to SQL and
oh my god is it an over-complicated monster ..."

I'll say this: It certainly doesn't help that there are different
variations of SQL.

SteveT
Well, that  pretty much en par with any other programming language. 
Beside maybe C (for the most part), there are different variations of 
pretty much every mainstream programming language. Just see how many 
variations you can set in FreePascal to try and match other Pascal 
variations (Delphi, Turbo, ISO)... ;-)


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

Re: [fpc-pascal] Program efficiency

[Ralf Quint via fpc-pascal]

On 11/9/2022 6:52 AM, James Richters via fpc-pascal wrote:


Sounds to me that if the compiler will probably insert temp variables 
anyway, then I might as well make my own and make it easier to 
understand later.



+1

Trying to write this without intermediate variables would definitely 
make is less readable and the only case (maybe) where this could 
possibly, and even then likely in limited cases be more efficient, would 
be if you have a CPU architecture with MANY 64bit registers. But even 
64bit ARM gets limited rather quickly and it certainly won't help on 
x86, which is still the vastly dominant CPU architecture out there...



Ralf

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

Re: [fpc-pascal] BoolToStr

[Ralf Quint via fpc-pascal]

On 8/28/2022 8:23 AM, James Richters via fpc-pascal wrote:

Running "i:\booltostr.exe "

-1

0

Why true is -1 instead of 1 is beyond me, but anyway, I would consider 
this BoolToInt, not BoolToStr,I want the Strings ‘TRUE’ or ‘FALSE’ as 
indicated in the documentation


Very logical in fact. 0 is NO bit set in any given size of boolean data 
type, -1 means ALL bits set on that same size boolean data type. And a 
check on TRUE or FALSE, can easily be done with checking the sign flag 
of a processor rather than doing actually any bit fiddling (at least on 
those CPUs that I am familiar with).


Ralf

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

Re: [fpc-pascal] string vs char

[Ralf Quint via fpc-pascal]

On 10/15/2021 3:16 PM, Ched via fpc-pascal wrote:

Well, well, understand.


OTOH, declaring a string of length 1 is sort of futile -- it uses
two bytes where a plain char declaration takes just one byte.


Not so futile as a string can be empty, not a char ! 


Well, if you don't like it being called "futile, just call it "nonsense" 
instead (in 99.99% of all possible use cases)


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
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FreePascal and MySQL 8.0

[Ralf Quint via fpc-pascal]

On 9/20/2021 12:39 AM, antlists via fpc-pascal wrote:

On 20/09/2021 00:12, Ralf Quint via fpc-pascal wrote:

On 9/18/2021 7:33 AM, Terry A. Haimann via fpc-pascal wrote:

I just upgraded to a new laptop and see that MariaDB is using MySQL 8.0
. I also see there is no connector in my Free Pascal install for MySQL
8.0.  I do see that there is an open ticket to create a connector.  Is
there an Alpha or Beta version of the connector available that I can
try?

Thank you for your attention,


To me, this question doesn't make any sense...

Either you have MariaDB or you have MySQL. "MariaDB is using MySQL 
8.0" seems utter nonsense.


What he probably meant is "MariaDB is using the MySQL 8.0 connector" 
which DOES make sense. 


Well, then it helps if he would write exactly that.

In general, in programming you need to write exactly what you intend to 
do, neither readers nor compilers/libraries can make wild guesses as to 
what your intentions might be otherwise...


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
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FreePascal and MySQL 8.0

[Ralf Quint via fpc-pascal]

On 9/18/2021 7:33 AM, Terry A. Haimann via fpc-pascal wrote:

I just upgraded to a new laptop and see that MariaDB is using MySQL 8.0
. I also see there is no connector in my Free Pascal install for MySQL
8.0.  I do see that there is an open ticket to create a connector.  Is
there an Alpha or Beta version of the connector available that I can
try?

Thank you for your attention,


To me, this question doesn't make any sense...

Either you have MariaDB or you have MySQL. "MariaDB is using MySQL 8.0" 
seems utter nonsense.


Beside that MySQL 8 is around for 3 1/2 years now (April 2018)...

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
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Hello, new Pascal programmer. had a question!

[Ralf Quint via fpc-pascal]

On 8/31/2021 10:40 AM, joseph turco via fpc-pascal wrote:

I guess I should just use lazarus and learn the GUI Tools.


Using Lazarus doesn't mean you HAVE TO write GUI programs. Just use it 
as an IDE. And by and large, any book/resource about Object 
Pascal/Delphi will do just fine to learn the basics of FreePascal...


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
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] How does FPC perform in the FASTEST Computer Language Race

[Ralf Quint via fpc-pascal]

On 7/10/2021 10:20 AM, Ryan Joseph via fpc-pascal wrote:


I guess that video is totally false or I'm missing something


There is no easier way to cheat than using benchmarks... ;-)

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
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] 50 years of Pascal, by the the author himself

[Ralf Quint via fpc-pascal]

Thought this was kind of interesting, though it leaves short of 
mentioning the later Object Pascal evolution and thus Delphi and 
FreePascal...


https://cacm.acm.org/magazines/2021/3/250705-50-years-of-pascal/fulltext


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
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Traits Proposal

[Ralf Quint via fpc-pascal]

On 2/16/2021 10:48 AM, Sven Barth via fpc-pascal wrote:
Ryan Joseph via fpc-pascal > schrieb am Di., 16. Feb. 
2021, 19:21:


>
> There we have:
>
> * slower creation of the class, because each implemented
interface adds another VMT reference to the class which needs to
be initialized.

How bad is this? We need to make a test case we can profile. For
example if you have a game that creates 1000 classes 60 frames per
second. If adding interfaces to the classes hurts this process we
may have a deal breaker.


If you need to create 1000 class instances each frame then you have a 
flaw in your logic in my opinion.


Yup, that would be a deal breaker right from the get go...

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
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Value:x:y syntax

[Ralf Quint via fpc-pascal]

On 2/9/2021 7:26 AM, Luis Henrique via fpc-pascal wrote:



I guess one can call it optional formatting specifiers.  See documentation: 
https://www.freepascal.org/docs-html/rtl/system/str.html

I think I was lazy and didn't look in the right place, thanks Michael and 
Christo.


This is standard Pascal real number formatting since at least the mid 
'70s...


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
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Selecting Records with a variable

[Ralf Quint via fpc-pascal]

On 12/20/2020 7:11 AM, Luca Olivetti via fpc-pascal wrote:


Then change your data model.

Instead of

Axis_record = record
  X,Y,Z,A,B,C    : Double;
End;

use

AxisName = (X,Y,Z,A,B,C);
Axis_record = array[AxisName] of double;

then it's easy to do what you want.

procedure DoSomething(var Axis:Axis_record; const which:AxisName);
begin
  Axis[which]:=Axis[which]/2;
end;

Bye


+1

I think this is a typical example where properly thinking about a 
solution for a programming issue BEFORE going with what seems as the 
logical choice at first glance leads to a much simpler solution without 
coming up with all kinds of fancy workarounds...


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
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] basic question on begin, end;

[Ralf Quint via fpc-pascal]

On 9/22/2020 5:46 AM, dano none via fpc-pascal wrote:

I have a basic shuffle routine. I put being, end statements in the outer loop 
for clarification.
It ended up producing random results.
Commenting out the begin, end combination allows the code to run as expected.
My code is below, can someone tell me if the begin, end combination should 
actually make a difference, or should they be more ornamental in function?


Well, in that code snippet, you have commented out one begin statement 
and two end statements in a nested comment. As Bart already mentioned, 
having the first for loop's statements enclosed with a begin/end does 
not make any functional difference, unless you have somehow unbalanced 
pairs of begin/end (outside of that code snippet).


Most of the time, this will result in the code not even compiling or 
throwing some warnings but there can be cases where it accidentally 
changes the flow of the code. Similar like moving code blocks around in 
Python with a one-off indentation and all the sudden the flow of that 
code changes, without complaining...


What editor do you use to write your code? If you are using the Lazarus 
IDE for example, it show show you/highlight the matching pairs of 
begin/end and could help to find some stray begins or ends in your code...


Ralf


Thanks!

{Let's Shuffle Col1  - routine from: 
https://www.theproblemsite.com/reference/science/technology/programming/randomizing-an-array
 }
my_base := 0;
for i:= 0 to 4 do  { Column we are currently working on }
 {  begin }
  for j:= 0 to 90 do { 20 swaps on the working column }
 begin
index1 := RandomRange(my_base,my_base+14);   { a random # = 
length of the array }
index2 := RandomRange(my_base,my_base+14);
writeln('index1 ', index1,' ', 'index2 ', index2);
while (index1 = index2) do
begin
   index2 := RandomRange(my_base,my_base+14); { avoid swaping 
on the same square }
   writeln('index2 trap ',index2);
end;
my_temp := shuffle_array[i,index1]; { store position to get 
a random value }
shuffle_array[i,index1] := shuffle_array[i,index2];
shuffle_array[i,index2] := my_temp;
writeln(shuffle_array[i,index1],'  ',shuffle_array[i,index2]);

{ ok... Index isn't a valid row.. }
 end;
 my_base := my_base + 15;
 writeln('current base ',my_base:2);
 ch := ReadKey;
 {  end;  { end i = column indexer }}



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

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

Re: [fpc-pascal] Killing the mail list

[Ralf Quint via fpc-pascal]

On 3/15/2020 6:55 AM, Ryan Joseph via fpc-pascal wrote:

It's 2020 and the mail list is starting to really show its age. I don't get 
first messages from gmail and my personal web host is whitelisted, messages 
bounce when I use the wrong account by accident, hard to search the archives, 
can't post images and code easily (big problem!), messages gets lost or 
un-threaded when subjects are incorrect, and the list goes on (pun not 
intended).

Has there ever been any discussion into replacing it with a modern web based 
forum? I don't know how to manage this migration but it should be a goal for 
the future in my opinion.

Personally I really like the format used in forum.sublimetext.com which is from 
www.discourse.org.

Completely irrelevant what year it is, I much rather prefer the mailing 
list over a forum. The main reason is simply that the mailing list is 
"non interactive", meaning my email client gets the new posts 
automatically and puts them in a suitable subfolder, where I can read 
and react to them at my leisure, I am not required to actively check if 
there is something new or a reply to an existing thread I am interested in.


A lot of issues that you mention can happen on a forum as well, so that 
is no argument. There are a lot of forums that in fact restrict the 
posting of images and other forms of attachments, simply to ward off the 
never ending endeavors of spam/malware spewing miscreants...


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
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Add API to official documentation search

[Ralf Quint via fpc-pascal]

On 11/17/2019 2:41 PM, Graeme Geldenhuys wrote:

On 17/11/2019 10:31 pm, Michael Van Canneyt wrote:

Stated purpose was special handling in the Bing search engine.

Either way, that's a pie in the face for Embarcadero. :-)

They might rather get a chuckle out of it, after all, it is Bing. And as 
you should know, friends don't let friends use Bing! :P


Ralf ;-)

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