Re: [fpc-pascal] Is this the correct way to configure fpc for multiple arm-embedded subarchs?

On Sun, 2017-12-03 at 19:05 +0100, Florian Klämpfl wrote: > Am 29.11.2017 um 06:36 schrieb Christo: > > > > On Sun, 2017-11-26 at 17:19 +0100, Michael Ring wrote: > > > > > > I am looking for an easy way to have all cortex-m compilers available > > > at the same time to be able to do automated

Re: [fpc-pascal] GetAppConfigDir(False) in a Citrix environment

On 07/02/18 13:49, Bart wrote: > @Graeme: did you manage to translate all that into pascal? > If so, do you care to share it? I haven't had time to look at that job at work yet, but it's on my todo list and should be done in the next week. I don't mind sharing the solution. Regards, Graeme --

Re: [fpc-pascal] fpdoc error with XML parsing

On Tue, Jul 3, 2018 at 6:52 PM, wrote: >> So I guess "--" is not allowed inside a >> xml comment block. Another reason to dislike XML. ;-) W3C XML validator says it's invalid XML: " invalid comment declaration: found name start character outside comment but inside comment declaration" and it

Re: [fpc-pascal] Loss of precision when using math.Max()

It's hard to make things fool proof, fool's are too ingenius. On Jul 2, 2018 6:14 PM, "Wolf" wrote: > Not so long ago, Florian was proudly bragging about "Pascal does not allow > you to shoot yourself in the foot > " > > What

Re: [fpc-pascal] Loss of precision when using math.Max()

Am 03.07.2018 um 22:11 schrieb g...@wolfgang-ehrhardt.de: Zitat von Florian Klämpfl :  But actually, I just found out that we have something like this already for years: {$minfpconstprec 64} OK, then two questions remain: Why does is occur/apply only for (newer?) 3.1.1 versions? I dug

Re: [fpc-pascal] Loss of precision when using math.Max()

On 7/3/2018 10:41 AM, Martok wrote: >>> If you compile with range checks on, you get a runtime error. >> why are so many folks NOT developing with all the checks (range, heap, >> stack, >> etc) turned ON and then turning them off for production builds??? > Actually, while we're at it - it seems

Re: [fpc-pascal] Loss of precision when using math.Max()

On 7/3/2018 10:33 AM, wkitt...@windstream.net wrote: > On 07/03/2018 12:41 PM, Ralf Quint wrote: >> And no "new language" can absolve the programmer from properly doing >> their >> work. Everything else is just a quick hack, not a properly designed >> program... > > > Welcome Back, Ralf!  we've

Re: [fpc-pascal] Loss of precision when using math.Max()

On 7/3/2018 10:09 AM, Marco van de Voort wrote: > In our previous episode, Santiago A. said: >> Pascal needs to break backward compatibility to advance, that is, in >> fact, a new language. But if pascal is struggling to survive, let alone >> a new language if you are not mozilla, google... > I

Re: [fpc-pascal] Loss of precision when using math.Max()

Zitat von Florian Klämpfl : But actually, I just found out that we have something like this already for years: {$minfpconstprec 64} OK, then two questions remain: Why does is occur/apply only for (newer?) 3.1.1 versions? And why is there no option to select the maximum precision for

Re: [fpc-pascal] Loss of precision when using math.Max()

Am 03.07.2018 um 21:43 schrieb g...@wolfgang-ehrhardt.de: Zitat von Florian Klämpfl : So you want float constants being evaluated always with full precision (which would be required for consistency) causing any floating point expression containing a constant being evaluated with full

Re: [fpc-pascal] Loss of precision when using math.Max()

Zitat von Florian Klämpfl : So you want float constants being evaluated always with full precision (which would be required for consistency) causing any floating point expression containing a constant being evaluated with full precision as well? Yes, at least as default or selectable

Re: [fpc-pascal] Loss of precision when using math.Max()

Am 03.07.2018 um 20:33 schrieb g...@wolfgang-ehrhardt.de: Zitat von Florian Klämpfl : In pascal, the rule applies that *the resulting type of an operation does not depend on the type a value is assigned too*. So: 1.0 fits perfectly into a single, 3.0 as well, they are single constants (you

Re: [fpc-pascal] TFPGObjectList error

Am 01.07.2018 um 04:14 schrieb Michalis Kamburelis: 2018-07-01 4:01 GMT+02:00 Vojtěch Čihák : this seems to be misleading error message. TFPGObjectList works well for objects (classes). When I tried to push record to it, I got the same error message. TVec3 is not class, right? Indeed, it's a

Re: [fpc-pascal] Loss of precision when using math.Max()

Zitat von Florian Klämpfl : In pascal, the rule applies that *the resulting type of an operation does not depend on the type a value is assigned too*. So: 1.0 fits perfectly into a single, 3.0 as well, they are single constants (you didn't tell the compiler otherwise). Nobody wants that

Re: [fpc-pascal] Loss of precision when using math.Max()

Am 03.07.2018 um 19:42 schrieb g...@wolfgang-ehrhardt.de: Zitat von Vojtěch Čihák : will not give any warning even if correct result is 2.5. It is simply absurd because it is not about shooting your own foot. Compiler is not a crystal ball, it does what you tell him. If you need floating

Re: [fpc-pascal] FPC_PCHAR_LENGTH dog slow

On 07/03/2018 01:44 PM, leledumbo via fpc-pascal wrote: i think i'm still waiting for the string "length byte" becoming a "length word" or possibly a "length long" so the speed of pascal strings can be reacquired -=B-) > Ansi and any other dynamic strings already have length longint that allows

Re: [fpc-pascal] Loss of precision when using math.Max()

Am 03.07.2018 um 14:33 schrieb Wolf: Maybe we do get some views from the key authors of Free Pascal. Not from me. These topics have been discussed zillion times. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org

Re: [fpc-pascal] FPC_PCHAR_LENGTH dog slow

> i think i'm still waiting for the string "length byte" becoming a "length word" or possibly a "length long" so the speed of pascal strings can be reacquired -=B-) Ansi and any other dynamic strings already have length longint that allows 2GB string length with O(1) length retrieval. --

Re: [fpc-pascal] Loss of precision when using math.Max()

Zitat von Vojtěch Čihák : will not give any warning even if correct result is 2.5. It is simply absurd because it is not about shooting your own foot. Compiler is not a crystal ball, it does what you tell him. If you need floating point, use floating point types and floating point division

Re: [fpc-pascal] Loss of precision when using math.Max()

>> If you compile with range checks on, you get a runtime error. > why are so many folks NOT developing with all the checks (range, heap, stack, > etc) turned ON and then turning them off for production builds??? Actually, while we're at it - it seems to me that for FPC, "all runtime checks

Re: [fpc-pascal] Loss of precision when using math.Max()

On 07/03/2018 12:41 PM, Ralf Quint wrote: And no "new language" can absolve the programmer from properly doing their work. Everything else is just a quick hack, not a properly designed program... Welcome Back, Ralf! we've missed you O:) O:) O:) -- NOTE: No off-list assistance is given

Re: [fpc-pascal] FPC_PCHAR_LENGTH dog slow

On 07/03/2018 12:01 PM, Tomas Hajny wrote: On Tue, July 3, 2018 17:15, Ryan Joseph wrote: Why is that so crazy slow? Does it need to iterate the entire length of the string to know it’s length? > Yes, that's indeed the difference between Pascal strings (Short/Ansi/Wide/UnicodeString) and

Re: [fpc-pascal] Split stream into words

On Tue, Jul 3, 2018 at 11:55 AM, Michael Van Canneyt wrote: > >> Thanks. >> But, is uregexp part of FPC? > > > Not yet, but I intend to make it so. All right! Thanks. Marcos Douglas PS. Please, don't forget the XPath Unicode implementation too. We have talked about it months ago... but I can

Re: [fpc-pascal] Loss of precision when using math.Max()

On 07/03/18 05:33, Wolf wrote: The major shortcoming of this thread, the way I see it, is that the answer provided explains what the compiler does, but not why the key authors of Free Pascal have made these choices. What their choices achieve is a substantial watering-down of what is

Re: [fpc-pascal] Daemon using TTimer on Windows

On Tue, Jul 3, 2018 at 11:36 AM, Giuliano Colla wrote: > Il 03/07/2018 15:14, Marcos Douglas B. Santos ha scritto: > >> Can we sleep a thread for minutes or even hours without any problems? >> The OS will not kill the thread? > > On Linux environment, sample situation on one of our servers: > >>

Re: [fpc-pascal] Loss of precision when using math.Max()

In our previous episode, Santiago A. said: > > Pascal needs to break backward compatibility to advance, that is, in > fact, a new language. But if pascal is struggling to survive, let alone > a new language if you are not mozilla, google... I think to advance Pascal needs less discussion about

Re: [fpc-pascal] Loss of precision when using math.Max()

On 07/03/2018 03:26 AM, C Western wrote: On 02/07/18 23:13, Wolf wrote: Who is shooting whom in the foot? Wolf If you compile with range checks on, you get a runtime error. why are so many folks NOT developing with all the checks (range, heap, stack, etc) turned ON and then turning them

Re: [fpc-pascal] fpdoc error with XML parsing

On 07/02/2018 07:07 PM, Graeme Geldenhuys wrote: From that error message it doesn't seem to like the "--macro" part inside the xml comment. It seems fpdoc wants to process that "--" as the end of the comment. this was where i was headed... if the multi-line comments work properly, perhaps it

Re: [fpc-pascal] Loss of precision when using math.Max()

Hi,   I agree with the original topic that overload function Math.Max(Double, Double) shoud be chosen instead of Math.Max(Single, Single) when one of parameters is Integer.   But your criticism make no sense to me. You can as well point that this code:   var a, b: Byte; begin   a:=5;   b:=a div

Re: [fpc-pascal] Loss of precision when using math.Max()

On 7/3/2018 5:01 AM, Santiago A. wrote: > El 03/07/2018 a las 01:26, Jim Lee escribió: >> >> Without the implicit conversion of signed/unsigned values, the >> utility of the language is greatly diminished. Bollocks! Just learn to program in Pascal, not trying to have Pascal act just like another

Re: [fpc-pascal] Loss of precision when using math.Max()

El 03/07/2018 a las 14:33, Wolf escribió: PS.: while composing this mail, Santiago wrote:  Pascal needs to break backward compatibility to advance, that is, in fact, a new language. But if pascal is struggling to survive, let alone a new language if you are not mozilla, google... In which

Re: [fpc-pascal] FPC_PCHAR_LENGTH dog slow

On Tue, 3 Jul 2018 09:15:16 -0600 Ryan Joseph wrote: > I was just parsing something and found that a call to length on a pchar was > taking 90+% of the time in FPC_PCHAR_LENGTH. > > Why is that so crazy slow? Does it need to iterate the entire length of the > string to know it’s length? Yes.

Re: [fpc-pascal] FPC_PCHAR_LENGTH dog slow

On Tue, July 3, 2018 17:15, Ryan Joseph wrote: > I was just parsing something and found that a call to > length on a pchar was taking 90+% of the time in > FPC_PCHAR_LENGTH. > > Why is that so crazy slow? Does it need to iterate the > entire length of the string to know it’s length? Yes, that's

[fpc-pascal] FPC_PCHAR_LENGTH dog slow

I was just parsing something and found that a call to length on a pchar was taking 90+% of the time in FPC_PCHAR_LENGTH. Why is that so crazy slow? Does it need to iterate the entire length of the string to know it’s length? Regards, Ryan Joseph

Re: [fpc-pascal] List of chars for case

> On Jul 2, 2018, at 10:55 PM, leledumbo via fpc-pascal > wrote: > > Only through macro ATM Yeah I cheated and used a macro. ...and that’s why we should allow for macros as a fail safe in times of distress... Regards, Ryan Joseph ___

Re: [fpc-pascal] Split stream into words

On Tue, 3 Jul 2018, Marcos Douglas B. Santos wrote: On Tue, Jul 3, 2018 at 10:26 AM, Michael Van Canneyt wrote: On Tue, 3 Jul 2018, Marcos Douglas B. Santos wrote: On Tue, Jul 3, 2018 at 7:50 AM, Michael Van Canneyt wrote: On Tue, 3 Jul 2018, Marco van de Voort wrote: Trivial

Re: [fpc-pascal] Daemon using TTimer on Windows

Il 03/07/2018 15:14, Marcos Douglas B. Santos ha scritto: Can we sleep a thread for minutes or even hours without any problems? The OS will not kill the thread? On Linux environment, sample situation on one of our servers: ├─hald───hald-runner─┬─hald-addon-acpi │ ├─hald-addon-keyb │

Re: [fpc-pascal] Daemon using TTimer on Windows

On Tue, 2018-07-03 at 10:14 -0300, Marcos Douglas B. Santos wrote: > > Can we sleep a thread for minutes or even hours without any problems? > The OS will not kill the thread? > Sorry, I simply don't know. Try it. -- Marc Santhoff ___ fpc-pascal

Re: [fpc-pascal] Split stream into words

On Tue, Jul 3, 2018 at 10:26 AM, Michael Van Canneyt wrote: > > > On Tue, 3 Jul 2018, Marcos Douglas B. Santos wrote: > >> On Tue, Jul 3, 2018 at 7:50 AM, Michael Van Canneyt >> wrote: >>> >>> >>> On Tue, 3 Jul 2018, Marco van de Voort wrote: >>> Trivial indeed, till you need more fine-grained

Re: [fpc-pascal] Split stream into words

On Tue, 3 Jul 2018, Marcos Douglas B. Santos wrote: On Tue, Jul 3, 2018 at 7:50 AM, Michael Van Canneyt wrote: On Tue, 3 Jul 2018, Marco van de Voort wrote: Trivial indeed, till you need more fine-grained control. e.g. C needs to be an array of chars that mark word boundaries etc. But I

Re: [fpc-pascal] Split stream into words

On Tue, Jul 3, 2018 at 7:50 AM, Michael Van Canneyt wrote: > > On Tue, 3 Jul 2018, Marco van de Voort wrote: > Trivial indeed, till you need more fine-grained control. > e.g. C needs to be an array of chars that mark word boundaries etc. > > But I managed to solve the problem with regexps...

Re: [fpc-pascal] Daemon using TTimer on Windows

On Mon, Jul 2, 2018 at 6:28 PM, Marc Santhoff wrote: > On Sat, 2018-06-30 at 17:57 -0300, Marcos Douglas B. Santos wrote: >> >> My question is: Nowadays, can I use TTimer with no restrictions in a >> daemon application on Windows? If not, which could be a possible >> solution? >> > > Some years

Re: [fpc-pascal] Loss of precision when using math.Max()

The major shortcoming of this thread, the way I see it, is that the answer provided explains what the compiler does, but not why the key authors of Free Pascal have made these choices. What their choices achieve is a substantial watering-down of what is supposedly Pascal's most significant

Re: [fpc-pascal] Loss of precision when using math.Max()

El 03/07/2018 a las 01:26, Jim Lee escribió: On 07/02/18 15:13, Wolf wrote: Not so long ago, Florian was proudly bragging about "Pascal does not allow you to shoot yourself in the foot " What about this little program:

Re: [fpc-pascal] Split stream into words

On Tue, 3 Jul 2018, Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: > In our previous episode, Michael Van Canneyt said: >> >> What's the easiest way to split a stream into words ? > > Doesn't strutils have some word extraction and count functions? It does:

Re: [fpc-pascal] Split stream into words

In our previous episode, Michael Van Canneyt said: > > > In our previous episode, Michael Van Canneyt said: > >> > >> What's the easiest way to split a stream into words ? > > > > Doesn't strutils have some word extraction and count functions? > > It does: WordCount,ExtractWord, but they are

Re: [fpc-pascal] Split stream into words

On Tue, 3 Jul 2018, Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: What's the easiest way to split a stream into words ? Doesn't strutils have some word extraction and count functions? It does: WordCount,ExtractWord, but they are very inefficent. Michael.

Re: [fpc-pascal] Split stream into words

In our previous episode, Michael Van Canneyt said: > > What's the easiest way to split a stream into words ? Doesn't strutils have some word extraction and count functions? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org

Re: [fpc-pascal] Split stream into words

On Tue, 3 Jul 2018, Michael Van Canneyt wrote: Hi, What's the easiest way to split a stream into words ? Words are just that: words, but - here is the caveat - they must support unicode. So Michael and Michaël are both words. Tried regexpr unit (the obvious choice), but that does not

[fpc-pascal] Split stream into words

Hi, What's the easiest way to split a stream into words ? Words are just that: words, but - here is the caveat - they must support unicode. So Michael and Michaël are both words. Tried regexpr unit (the obvious choice), but that does not seem to do the trick: {$mode objfpc} {$H+} uses

Re: [fpc-pascal] Loss of precision when using math.Max()

On 02/07/18 23:13, Wolf wrote: Not so long ago, Florian was proudly bragging about "Pascal does not allow you to shoot yourself in the foot " What about this little program: program Project1; var a,b: byte; begin   a:=1;  

Re: [fpc-pascal] Daemon using TTimer on Windows

On Sat, 2018-06-30 at 17:57 -0300, Marcos Douglas B. Santos wrote: > > My question is: Nowadays, can I use TTimer with no restrictions in a > daemon application on Windows? If not, which could be a possible > solution? > Some years ago Graeme G. posted a solution to that problem. It's attached