Re: [fpc-pascal] Defining sonames?

2017-08-18 Thread Martin Schreiber
On Friday 18 August 2017 12:45:26 Graeme Geldenhuys wrote:
> On 2017-08-18 10:27, Martin Schreiber wrote:
> > If one manually changes in link.res
>
> hahaha... You read my mind, I was going to try that today in my lunch
> time. :-)
>
> So now all that FPC needs is a new compiler parameter to tell it how to
> generate the linker parameters, and when the alternative is specified,
> not to strip the version info from the library name. That sounds doable
> with no immediate harm to existing projects (after all, it will be a new
> command line parameter).
>
Or simply treat a leading colon as start of a filename as ld does.

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

Re: [fpc-pascal] Pascal support in the Kattis educational site

2017-08-18 Thread James Richters
>Maybe the results backend uses higher precision result values, and the web 
>interface simply rounds it to two decimal places? ;-)

It seems most likely that the results are evaluated at more than 2 decimal 
places.  I don't know why they would only display 2 decimal places, 1/100th of 
a second is a virtual eternity when it comes to processor time... thus proven 
by the huge number of 0.00s results in the list.. in order to display 0.00, the 
run time had to be less than 0.005s,  but that's not surprising with a 
processors running in the GHz.   You would think that after the site was 
running for 1 day they would have realized they needed to display more 
precision then 2 places.

When I was try to get timing information for efficiency comparison between 
procedures, I ended up having to run the test procedure in a loop at least 1000 
times, sometimes 10million times because if I did not do that, they system 
timer resolution was not high enough to get an accurate count.  

It would be very interesting to see the timings to more precision, because I 
would think that some of the timings would be exactly the same because when it 
comes down to optimizing procedures,  different people could end up arriving at 
the exact same solution as far as the structure of the program is concerned.
They should also rank other aspects such as compiled program size, amount of 
memory used, User Interface design (input and output clarity and formatting), 
effectiveness of documentationetc. the best program isn't necessarily the 
one that executes fastest...  Which is a 'better' program: program A that 
executes in 0.00018s that uses 1MB of RAM or Program B that executes in 
0.00016s that uses 100MB of RAM 

James

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

Re: [fpc-pascal] Serial communications: synaser vs FPC's serial unit

2017-08-18 Thread Christo Crause
On Fri, Aug 18, 2017 at 9:39 AM, Graeme Geldenhuys <
mailingli...@geldenhuys.co.uk> wrote:

> On 2017-08-18 07:51, Christo Crause wrote:
>
>> I've also just noted a typing error in GetSerialPortNames: '/dev/ttyAM*'
>> should rather be '/dev/ttyACM*''
>>
>
> My version also has the first instance (ttyAM*) with a comment "ARM
> boards". Your implementation in the bug report looks a lot better than what
> I have in my synaser copy - cleaner code with less code duplication. Thanks
> for the reply.


Right, not a typo then. Good to learn something new - apparently ttyAMA* is
the device name specified by the ARM AMBA style serial ports driver for
Linux: (
https://code.woboq.org/linux/linux/drivers/tty/serial/amba-pl011.c.html#2514
)

So I looked for a systematic naming convention, but according to the Linux
allocated devices list (
https://static.lwn.net/kerneldoc/admin-guide/devices.html) there is a large
number of tty* names in use for different serial drivers.  Perhaps a
different approach (https://stackoverflow.com/a/9914339) is called for...
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Proposed tidy-up of the FPC Manual section on Character Types and the FPC Wiki

2017-08-18 Thread Graeme Geldenhuys

On 2017-08-18 11:13, Mark Morgan Lloyd wrote:

please could we have the breaking version numbers
noted explicitly.


The 'fpdoc' tool already has support for that feature. The  tag 
in description files. I don't know if it has actually been used in FPC 
class documentation though. I know I use it often in fpGUI Toolkit's 
class documentation.


See FPDOC pdf documentation around Section 5.3.37.

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

Re: [fpc-pascal] Serial communications: synaser vs FPC's serial unit

2017-08-18 Thread Graeme Geldenhuys

On 2017-08-18 10:34, Mark Morgan Lloyd wrote:

I saw some of those in th serial.pp in FPC trunk. Thanks for the
information.

I've got this terrible habit of inserting comments...:-)



You and I must be a rare breed of programmer then. :-)


Regards,
  Graeme

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

Re: [fpc-pascal] Defining sonames?

2017-08-18 Thread Graeme Geldenhuys

On 2017-08-18 10:27, Martin Schreiber wrote:

the application links without errors despite there is no libX11.so ->
libX11.so.6 link.


I quickly tested under FreeBSD 10.3. Even thought FreeBSD doesn't have 
*-devel packages like Linux does. All ports packages (binary or build 
from source) include unversioned and versioned library names.


Anyway, the -l:libname.so.1 style linker parameter also works under 
FreeBSD. I could link a project without problems. To make doubly sure, I 
deleted the libX11.so symlink file and managed to link my project 
successfully. It also run without problems (didn't expect any issues 
here). So using the versioned library names definitely works.



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

Re: [fpc-pascal] Defining sonames?

2017-08-18 Thread Graeme Geldenhuys

On 2017-08-18 10:27, Martin Schreiber wrote:

If one manually changes in link.res



hahaha... You read my mind, I was going to try that today in my lunch 
time. :-)


So now all that FPC needs is a new compiler parameter to tell it how to 
generate the linker parameters, and when the alternative is specified, 
not to strip the version info from the library name. That sounds doable 
with no immediate harm to existing projects (after all, it will be a new 
command line parameter).



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

Re: [fpc-pascal] Proposed tidy-up of the FPC Manual section on Character Types and the FPC Wiki

2017-08-18 Thread Michael Van Canneyt


Tony,

Thank you for your proposals!

I will take them to heart and improve the docs accordingly. Some parts are
20 years old, so no surprise that they are not exactly correct any more...

Michael.

On Fri, 18 Aug 2017, Tony Whyman wrote:

There has been some heated discussion on the Lazarus lists on the 
subject to character encodings etc. This has exposed several issues with 
the FPC Manual that I wanted to record.


1. The char type

The manual says: "A Char is exactly 1 byte in size, and contains one 
ASCII character. "


This was probably true when Pascal was first defined, but char is often 
now used for any on-byte character set e.g. ISO 8859-1. Replace ASCII 
with ANSI.


2. WideChar

The Manual says: "A WideChar is exactly 2 bytes in size, and contains 
one UNICODE character in UTF-16 encoding. "


This seems to be wrong as UTF-16 is not limited to code points defined 
using a single 16-bit code unit, but also permits code points comprising 
two 16-bit code units. The definition should be updated to indicate that 
a WideChar was really created for the obsolescent UCS-2 and is limited 
to a UTF-16 subset (Unicode characters that can be expressed as a single 
16-bit code unit).


Proposed replacement text: "A WideChar is exactly 2 bytes in size, and 
contains one UNICODE character in UCS-2 encoding or UTF-16 encoding 
limited to the Basic Multilingual Plane. Note that Unicode Characters 
represented by a UTF-16 code points that require two 16-bit code units 
cannot be contained in a single WideChar variable."


3. UnicodeStrings

The Manual says: "For multi-byte string types, the basic character has a 
size of at least 2."


Proposed improvement:

"Multi-byte string types are used to represent Unicode characters 
encoded as code points requiring two or four bytes".


As with UTF8String, the following caveat should also be added:

"Since a unicode character may require two or four bytes to be 
represented in the UTF-16 encoding, there are 2 points to take care of 
when using UnicodeString/WideString:


1. The character index – which retrieves a WideChar at a certain 
position – must be used with care: the expression S[i] will not 
necessarily be a valid character for a string S of type 
UnicodeString/WideString.


2. The  length of the string is not necessarily equal to the number of 
elements in the array. The standard function length cannot be used to 
get the character length of the string, it will always return the array 
length.


--

Wiki Page on "Character and string Type"

1. This needs to start with a Health Warning on the use of the word 
Unicode. Proposed Text (borrowing from Wikipedia):


"Free Pascal supports several character and string types. They range 
from single ANSI characters to unicode strings and also include pointer 
types. Differences also apply to encodings and reference counting. ANSI 
is typically used to refer to single byte character encodings - although 
FPC also uses AnsiStrings to hold Unicode UTF-8 encoded strings.


Unicode is a computing industry standard for the consistent encoding, 
representation, and handling of text expressed in most of the world's 
writing systems. Developed in conjunction with the Universal Coded 
Character Set (UCS) standard and published as The Unicode Standard, the 
latest version of Unicode contains a repertoire of 136,755 characters 
covering 139 modern and historic scripts, as well as multiple symbol sets.


Unicode can be implemented by different character encodings. The Unicode 
standard defines UTF-8, UTF-16, and UTF-32, and several other encodings 
are in use. The most commonly used encodings are UTF-8, UTF-16 and 
UCS-2, a precursor of UTF-16.


The original idea behind Unicode was to replace the typical 
256-character encodings requiring 1 byte per character with an encoding 
using 2^16 = 65,536 values requiring 2 bytes per character.The early 
2-byte encoding was usually called "Unicode", but is now called "UCS-2". 
UCS-2 differs from UTF-16 by being a constant length encoding and only 
capable of encoding characters of Basic Multilingual Plane (BMP), it is 
supported by many programs. However, "UCS-2 should now be considered 
obsolete. It no longer refers to an encoding form in either 10646 or the 
Unicode Standard.


Unfortunately, the term Unicode, in common usage, is still often used to 
refer to the UCS-2 two byte encoding and this can give rise to much 
confusion e.g. when Unicode is used when referring to the UTF-8 encoding."


2. The text on WideChar is too terse and needs to be expanded. Proposed 
text:


"A variable of type WideChar, also referred to as UnicodeChar (which 
derives from the archaic use of Unicode to mean UCS-2), is exactly 2 
bytes in size, and usually contains either:


(a) a single UCS-2 code point, or

(b) a single UTF-16 code unit.

In case (b), this is sufficient for Unicode Characters that have a 
UTF-16 code point that comprises a single 

Re: [fpc-pascal] Proposed tidy-up of the FPC Manual section on Character Types and the FPC Wiki

2017-08-18 Thread Mark Morgan Lloyd

On 18/08/17 10:00, Tony Whyman wrote:
There has been some heated discussion on the Lazarus lists on the 
subject to character encodings etc. This has exposed several issues with 
the FPC Manual that I wanted to record.


Could I ask one thing on behalf of people who try to maintain code so 
that it still works properly with a range of compiler (and FCL/LCL) 
versions.


In cases where there's been a change in default behaviour as the 
compiler has matured, please could we have the breaking version numbers 
noted explicitly.


--
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] Proposed tidy-up of the FPC Manual section on Character Types and the FPC Wiki

2017-08-18 Thread Tony Whyman
There has been some heated discussion on the Lazarus lists on the 
subject to character encodings etc. This has exposed several issues with 
the FPC Manual that I wanted to record.


1. The char type

The manual says: "A Char is exactly 1 byte in size, and contains one 
ASCII character. "


This was probably true when Pascal was first defined, but char is often 
now used for any on-byte character set e.g. ISO 8859-1. Replace ASCII 
with ANSI.


2. WideChar

The Manual says: "A WideChar is exactly 2 bytes in size, and contains 
one UNICODE character in UTF-16 encoding. "


This seems to be wrong as UTF-16 is not limited to code points defined 
using a single 16-bit code unit, but also permits code points comprising 
two 16-bit code units. The definition should be updated to indicate that 
a WideChar was really created for the obsolescent UCS-2 and is limited 
to a UTF-16 subset (Unicode characters that can be expressed as a single 
16-bit code unit).


Proposed replacement text: "A WideChar is exactly 2 bytes in size, and 
contains one UNICODE character in UCS-2 encoding or UTF-16 encoding 
limited to the Basic Multilingual Plane. Note that Unicode Characters 
represented by a UTF-16 code points that require two 16-bit code units 
cannot be contained in a single WideChar variable."


3. UnicodeStrings

The Manual says: "For multi-byte string types, the basic character has a 
size of at least 2."


Proposed improvement:

"Multi-byte string types are used to represent Unicode characters 
encoded as code points requiring two or four bytes".


As with UTF8String, the following caveat should also be added:

"Since a unicode character may require two or four bytes to be 
represented in the UTF-16 encoding, there are 2 points to take care of 
when using UnicodeString/WideString:


1. The character index – which retrieves a WideChar at a certain 
position – must be used with care: the expression S[i] will not 
necessarily be a valid character for a string S of type 
UnicodeString/WideString.


2. The  length of the string is not necessarily equal to the number of 
elements in the array. The standard function length cannot be used to 
get the character length of the string, it will always return the array 
length.


--

Wiki Page on "Character and string Type"

1. This needs to start with a Health Warning on the use of the word 
Unicode. Proposed Text (borrowing from Wikipedia):


"Free Pascal supports several character and string types. They range 
from single ANSI characters to unicode strings and also include pointer 
types. Differences also apply to encodings and reference counting. ANSI 
is typically used to refer to single byte character encodings - although 
FPC also uses AnsiStrings to hold Unicode UTF-8 encoded strings.


Unicode is a computing industry standard for the consistent encoding, 
representation, and handling of text expressed in most of the world's 
writing systems. Developed in conjunction with the Universal Coded 
Character Set (UCS) standard and published as The Unicode Standard, the 
latest version of Unicode contains a repertoire of 136,755 characters 
covering 139 modern and historic scripts, as well as multiple symbol sets.


Unicode can be implemented by different character encodings. The Unicode 
standard defines UTF-8, UTF-16, and UTF-32, and several other encodings 
are in use. The most commonly used encodings are UTF-8, UTF-16 and 
UCS-2, a precursor of UTF-16.


The original idea behind Unicode was to replace the typical 
256-character encodings requiring 1 byte per character with an encoding 
using 2^16 = 65,536 values requiring 2 bytes per character.The early 
2-byte encoding was usually called "Unicode", but is now called "UCS-2". 
UCS-2 differs from UTF-16 by being a constant length encoding and only 
capable of encoding characters of Basic Multilingual Plane (BMP), it is 
supported by many programs. However, "UCS-2 should now be considered 
obsolete. It no longer refers to an encoding form in either 10646 or the 
Unicode Standard.


Unfortunately, the term Unicode, in common usage, is still often used to 
refer to the UCS-2 two byte encoding and this can give rise to much 
confusion e.g. when Unicode is used when referring to the UTF-8 encoding."


2. The text on WideChar is too terse and needs to be expanded. Proposed 
text:


"A variable of type WideChar, also referred to as UnicodeChar (which 
derives from the archaic use of Unicode to mean UCS-2), is exactly 2 
bytes in size, and usually contains either:


(a) a single UCS-2 code point, or

(b) a single UTF-16 code unit.

In case (b), this is sufficient for Unicode Characters that have a 
UTF-16 code point that comprises a single 16-bit code unit i.e. 
characters in the Basic Multilingual Plane. However, all other UTF-16 
characters have a UTF-16 code point that comprises a two 16-bit code 
units. FPC provides no specific support for such characters which 
require, e.g. a 

Re: [fpc-pascal] Serial communications: synaser vs FPC's serial unit

2017-08-18 Thread Mark Morgan Lloyd

On 18/08/17 07:45, Graeme Geldenhuys wrote:
On 2017-08-18 08:15, Mark Morgan Lloyd wrote:> There's a> specific 
gotcha related to differences in the way Linux and Solaris> handle 
select(),


I saw some of those in th serial.pp in FPC trunk. Thanks for the 
information.


I've got this terrible habit of inserting comments... :-)

I'm not aware of a reliable, cross-platform way of getting a complete> 
list of all serial-like devices.
To be honest, this is not much of an issue - more of a nice-to-have. It 
will only need to be set up once for the application anyway.


This is more of an issue than it used to be since, as a particular 
example, if something like an Arduino resets itself the kernel is likely 
to assign this a new named device. Having to restart an app to track 
this is irritating, but tracking udev (or whatever) events is probably 
overkill.


I'd suggest that a good policy would be to recognise various patterns at 
startup (/dev/ttyS*, /dev/ttyUSB* and so on) and to be prepared to 
accept incrementing numeric suffixes as they appear.


--
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] Defining sonames?

2017-08-18 Thread Martin Schreiber
On Friday 18 August 2017 10:56:47 Graeme Geldenhuys wrote:
> On 2017-08-18 08:16, Martin Schreiber wrote:
> > I checked with a simple library file, it seems that FPC strips the ".so*"
> > part from "external" names.
>
> Exactly what I discovered too. :-/
>
If one manually changes in link.res
"
INPUT(
-lX11
)
"
to
"
INPUT(
-l:libX11.so.6
)
"
the application links without errors despite there is no libX11.so -> 
libX11.so.6 link.

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

Re: [fpc-pascal] Pascal support in the Kattis educational site

2017-08-18 Thread Graeme Geldenhuys

On 2017-08-18 01:10, kapibara via fpc-pascal wrote:

Your program was as
fast as No1 but anyway not visible among top ten.


Maybe the results backend uses higher precision result values, and the 
web interface simply rounds it to two decimal places? ;-)



Regards,
  Graeme

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

Re: [fpc-pascal] Defining sonames?

2017-08-18 Thread Graeme Geldenhuys

On 2017-08-18 08:16, Martin Schreiber wrote:

I checked with a simple library file, it seems that FPC strips the ".so*" part
from "external" names.


Exactly what I discovered too. :-/


So the only way to make version-safe binding units in
Free Pascal seems to be to use dlopen()/dlsym().


That was my conclusion as well.

Regards,
  Graeme

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

Re: [fpc-pascal] Defining sonames?

2017-08-18 Thread Graeme Geldenhuys

On 2017-08-18 06:28, Martin Schreiber wrote:

Did you remove the various {$linklib} statements too?
Did you check all units which where included by "uses" statements?


Yes to both.

Regards,
  Graeme

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

Re: [fpc-pascal] Serial communications: synaser vs FPC's serial unit

2017-08-18 Thread Graeme Geldenhuys

On 2017-08-18 07:51, Christo Crause wrote:

I've also just noted a typing error in GetSerialPortNames: '/dev/ttyAM*'
should rather be '/dev/ttyACM*''


My version also has the first instance (ttyAM*) with a comment "ARM 
boards". Your implementation in the bug report looks a lot better than 
what I have in my synaser copy - cleaner code with less code 
duplication. Thanks for the reply.


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

Re: [fpc-pascal] Serial communications: synaser vs FPC's serial unit

2017-08-18 Thread Graeme Geldenhuys

On 2017-08-18 08:15, Mark Morgan Lloyd wrote:

There's a
specific gotcha related to differences in the way Linux and Solaris
handle select(),



I saw some of those in th serial.pp in FPC trunk. Thanks for the 
information.



I'm not aware of a reliable, cross-platform way of getting a complete
list of all serial-like devices.


To be honest, this is not much of an issue - more of a nice-to-have. It 
will only need to be set up once for the application anyway.



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

Re: [fpc-pascal] Defining sonames?

2017-08-18 Thread Martin Schreiber
On Friday 18 August 2017 07:28:01 Martin Schreiber wrote:
> On Thursday 17 August 2017 22:20:44 Graeme Geldenhuys wrote:
> > On 2017-08-17 16:52, Martin Schreiber wrote:
> > > Exactly. So why not use the SONAME in the Pascal binding unit instead
> > > to use the base name as Free Pascal currently does in xlib.pp for
> > > example?
> >
> > I forked the xlib, xutils and x units from FPC and tried just that. It
> > made no difference.
>
> Did you remove the various {$linklib} statements too?
> Did you check all units which where included by "uses" statements?
> BTW I tried to fork xlib.pp too but gave up because of the too many files
> which hat do be forked and it was too dangerous for existing projects.
>
I checked with a simple library file, it seems that FPC strips the ".so*" part 
from "external" names. So the only way to make version-safe binding units in 
Free Pascal seems to be to use dlopen()/dlsym().
Is this intended?

Martin


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

Re: [fpc-pascal] Serial communications: synaser vs FPC's serial unit

2017-08-18 Thread Mark Morgan Lloyd

On 17/08/17 14:00, Graeme Geldenhuys wrote:

Hi,
If somebody with more experience (than me) with the Synaser and FPC 
serial.pp units could comment, that would be much appreciated.
For a new cross-platform project where I need to talk to a device hooked 
up to a serial port, which unit would be the best to use? Normally I 
would go with units included with FPC simply because I know they are 
strict about keeping everything maintained.
When I say cross-platform, I'm currently talking about Windows and 
Linux, and possibly FreeBSD and Mac too.
Now for the Synaser unit - the one I have is from 2013, and I already 
noticed that there is no support for FreeBSD's /dev/* names to access 
serial ports. Granted I added FreeBSD support to the 
GetSerialPortNames() function in 5 minutes, but this doesn't bode to 
well then for the Synaser unit - what else could be missing that I don't 
know of?


I did the last maintenance on the serial.pp unit. I was focussing on 
very low-level stuff, i.e. capture in threads with accurate timestamps 
being appended, and notwithstanding my experience in this area would 
suggest looking first at Synaser etc. which is far more likely to have 
e.g. compatible terminal emulation.


I did specifically test serial.pp with both Linux (various processors) 
and Solaris (SPARC) and to a lesser extent Windows (W2K, x86). There's a 
specific gotcha related to differences in the way Linux and Solaris 
handle select(), and since AIUI Solaris and the Berkeley OSes are 
related this might turn out to be more of an issue that things like 
naming conventions.


I'm not aware of a reliable, cross-platform way of getting a complete 
list of all serial-like devices. I suppose that in principle it would be 
possible to try out the appropriate ioctls on all character devices, but 
things might break.


--
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] Serial communications: synaser vs FPC's serial unit

2017-08-18 Thread Christo Crause
I see the common Linux port names got added to Synaser (trunk) but the BDS
variants (https://sourceforge.net/p/synalist/bugs/21/) wasn't added.

I've also just noted a typing error in GetSerialPortNames: '/dev/ttyAM*'
should rather be '/dev/ttyACM*''

On Thu, Aug 17, 2017 at 3:45 PM, Graeme Geldenhuys <
mailingli...@geldenhuys.co.uk> wrote:

>
> Now for the Synaser unit - the one I have is from 2013, and I already
> noticed that there is no support for FreeBSD's /dev/* names to access
> serial ports. Granted I added FreeBSD support to the GetSerialPortNames()
> function in 5 minutes, but this doesn't bode to well then for the Synaser
> unit - what else could be missing that I don't know of?
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal