Re: [fpc-pascal] Defining sonames?
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
>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
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
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
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?
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?
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
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
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
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
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?
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
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?
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?
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
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
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?
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
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
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
