Re: [fpc-pascal] Hint converting to int64
On 11/09/18 16:15, Santiago A. wrote: El 11/09/18 a las 12:30, Mark Morgan Lloyd escribió:> On 11/09/18 10:15, Santiago A. wrote:>> Hello:FPC: 3.0.4 (Realease from Lazarus 1.8.4 SVN: 57972)OS: Windows7 >> 32bits / Linux 64Bits>> I have this code and I get a hint>> -- var Entity:Longword;FullParagraph:string; pIni:Integer; >> begin Entity:=Entity*10+ord(FullParagraph[pIni])-48; // <=== >> Hint end; --->> Hint: Converting the operands to "Int64" before doing the add could >> prevent overflow errors.I can't see why it mentions int64, there are >> integer and longword variables, but no Int64 one.>> There is you know.>> https://www.freepascal.org/docs-html/current/ref/refsu4.html#x26-250003.1.1 > --var Entity:Longword; FullParagraph:string; pIni:Integer;begin Entity:=Entity*10+ord(FullParagraph[pIni])-48; // <=== Hint end; ---Do you mean that Entity is promoted to int64 in a 32bits system? The operands Entity*10 and 10+ord(FullParagraph[pIni])-48 are both 32 bits, but the addition could overflow. The compiler writer's trying to be nice to you, quit kvetching :-) -- 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] Hint converting to int64
On 11/09/18 10:15, Santiago A. wrote: Hello:FPC: 3.0.4 (Realease from Lazarus 1.8.4 SVN: 57972)OS: Windows7 32bits / Linux 64Bits I have this code and I get a hint -- var Entity:Longword;FullParagraph:string; pIni:Integer; begin Entity:=Entity*10+ord(FullParagraph[pIni])-48; // <=== Hint end; --- Hint: Converting the operands to "Int64" before doing the add could prevent overflow errors.I can't see why it mentions int64, there are integer and longword variables, but no Int64 one. There is you know. https://www.freepascal.org/docs-html/current/ref/refsu4.html#x26-250003.1.1 I have replaced it by Entity:=Entity*10+LongWord(ord(FullParagraph[pIni]))-48; That is, I have casted the result of "ord()" to longword. But I get the same hint.What should I do to remove the hint? -- 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] Unbuffering I/O
On 30/08/18 12:00, Henry Vermaak wrote:
On Thu, Aug 30, 2018 at 10:57:21AM +, Mark Morgan Lloyd wrote:> Ah yes, that's it, thanks very
much.> > WriteLn(StdErr, Format('# Socket %s, clock resolution %8.6f uSec',>
[socketName, ts.tv_nsec / 1000]));> ttextrec(StdErr).flushfunc:= ttextrec(StdErr).inoutfunc;>
while true do begin> ttextrec(Output).flushfunc:= ttextrec(Output).inoutfunc;> i
:= fprecv(client, @buff, 1024, 0);
You only need to set flushfunc once at startup (for standard handles) orjust
after opening a file. The whole output vs stdout thing hasconfused me in the
past, too.
Thanks, noted and good point. That's a result of where the flushes
originally were.
--
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] Unbuffering I/O
On 30/08/18 10:15, Henry Vermaak wrote:
On Thu, Aug 30, 2018 at 09:45:00AM +, Mark Morgan Lloyd wrote:> On 30/08/18 09:00, Henry Vermaak wrote:> >On Thu, Aug 30, 2018 at
07:52:54AM +0200, Martin Schreiber wrote:> > >In order to flush textfiles automatically I use> ">
ttextrec().flushfunc:= ttextrec().inoutfunc;> "> after it is opened.> > >Reading text.inc this morning
lead me to believe this is the correctway. This is what the RTL does when opening serial devices inFileOpenFunc(), for example. There's a comment
inside Flush() that saysthat InOutFunc() should be used to flush, since the FlushFunc() may notbe assigned.> > I've just checked this and
unfortunately it doesn't do very much for the> standard device (?) used by WriteLn() etc., i.e. as would be used for a> quick-and-dirty program.
It definitely works for me. I made a program flush.pas that looks like this:
begin ttextrec(output).flushfunc := ttextrec(output).inoutfunc;
writeln('hi there');sleep(1000);end.
Running `./flush > out.txt` and `tail -F out.txt` shows the outputimmediately,
while removing the flushfunc assignment causes a delay of asecond before the
output appeared in the file.
Ah yes, that's it, thanks very much.
WriteLn(StdErr, Format('# Socket %s, clock resolution %8.6f
uSec', [socketName, ts.tv_nsec / 1000]));
ttextrec(StdErr).flushfunc:= ttextrec(StdErr).inoutfunc;
while true do begin
ttextrec(Output).flushfunc:= ttextrec(Output).inoutfunc;
i := fprecv(client, @buff, 1024, 0);
Basically, I was getting confused by the lack of "Error" etc., hence the
different names.
I note this works the same for both tail -f and tail -F which have
slightly different ways of looking to see if the input file has changed.
--
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] Unbuffering I/O
On 30/08/18 09:00, Henry Vermaak wrote: On Thu, Aug 30, 2018 at 07:52:54AM +0200, Martin Schreiber wrote: In order to flush textfiles automatically I use> "> ttextrec().flushfunc:= ttextrec().inoutfunc;> "> after it is opened. Reading text.inc this morning lead me to believe this is the correctway. This is what the RTL does when opening serial devices inFileOpenFunc(), for example. There's a comment inside Flush() that saysthat InOutFunc() should be used to flush, since the FlushFunc() may notbe assigned. I've just checked this and unfortunately it doesn't do very much for the standard device (?) used by WriteLn() etc., i.e. as would be used for a quick-and-dirty program. I've tried ttextrec(StdErr).flushfunc:= ttextrec(StdErr).inoutfunc; //Flush(StdErr); while true do begin // Flush(StdOut); // Has limited effect ttextrec(StdErr).flushfunc:= ttextrec(StdErr).inoutfunc; and program(input, output, error) .. //error.flushfunc:= error.inoutfunc; //Flush(StdErr); while true do begin // Flush(StdOut); // Has limited effect output.flushfunc:= output.inoutfunc; (Is that latter form even valid any more?) Please don't anybody put any effort into it- it's a very minor niggle from my POV. -- 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] Unbuffering I/O
On 29/08/18 16:00, Henry Vermaak wrote: On Wed, Aug 29, 2018 at 03:01:54PM +, Mark Morgan Lloyd wrote:> I think I've seen this question asked before, my apologies if this was> recently.> > I've got two programs intended to be functionally identical, one in Perl and> the other in FPC. They read a unix-domain datagram, decode the message, and> emit output; if this goes to a file then it's reasonable to monitor it using> tail -f> > Perl has a variable that you can set to force output to be unbuffered, with> the result that as soon as a message is output it's in the file in its> entirety.> > Is there an equivalent for Pascal, or should I be using something like> fpSync(stdout) at opportune times? Does SetTextBuf() with a buffer of size 1 work? I don't think there isanything equivalent to setvbuf(). Otherwise you'll have to Flush() themmanually, which is a pain. I'm a bit wary of SetTextBuf() with a preopened handle. Flush() is actually no big deal since the program has a well-defined processing loop... but unfortunately is less than effective. It's something I can live with, since this is really only a test program I knocked together to look at how clock_gettime() behaves on different platforms (the answer being "badly" :-) -- 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] Unbuffering I/O
I think I've seen this question asked before, my apologies if this was recently. I've got two programs intended to be functionally identical, one in Perl and the other in FPC. They read a unix-domain datagram, decode the message, and emit output; if this goes to a file then it's reasonable to monitor it using tail -f Perl has a variable that you can set to force output to be unbuffered, with the result that as soon as a message is output it's in the file in its entirety. Is there an equivalent for Pascal, or should I be using something like fpSync(stdout) at opportune times? -- 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] Reading AM2302 temp/humid sensor on RaspberryPi?
On 24/08/18 09:15, R0b0t1 wrote: On Thu, Aug 23, 2018 at 6:28 AM, Mark Morgan Lloyd wrote:> On 23/08/18 10:00, Martin Schreiber wrote:>>>> On Thursday 23 August 2018 11:11:34 Bo Berglund wrote:> On Thu, 23 Aug>> 2018 09:00:07 +0200, Bo Berglund>> wrote:> >I will>> need a higher resolution GetTickCount for this...>> Is there in fact a way>> (on Linux - Raspbian) to get a tickcount with> higher resolution than 1 ms?>>> On a mid-00s server I'm using clock_gettime(CLOCK_REALTIME which is> apparently better than 1uSec, but from previously looking at older PCs and> (I think) RPi3 your mileage may vary enormously. AIUI there's been a lot of> issues over the years with different cores not having their counters in> step, with counter frequency following dynamic clocks rather than being> fixed and so on.> There is clock_getres(2) to test this. That shows the nominal resolution, not the actual rate that the counter is updated. -- 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] Reading AM2302 temp/humid sensor on RaspberryPi?
On 23/08/18 10:00, Martin Schreiber wrote: On Thursday 23 August 2018 11:11:34 Bo Berglund wrote:> On Thu, 23 Aug 2018 09:00:07 +0200, Bo Berglund>> wrote:> >I will need a higher resolution GetTickCount for this...>> Is there in fact a way (on Linux - Raspbian) to get a tickcount with> higher resolution than 1 ms? On a mid-00s server I'm using clock_gettime(CLOCK_REALTIME which is apparently better than 1uSec, but from previously looking at older PCs and (I think) RPi3 your mileage may vary enormously. AIUI there's been a lot of issues over the years with different cores not having their counters in step, with counter frequency following dynamic clocks rather than being fixed and so on. The AM2302 datasheet suggests that it's a device to be avoided assiduously. -- 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] Syntax changes suggestions
On 18/07/18 20:45, Ryan Joseph wrote: On Jul 18, 2018, at 1:46 PM, R0b0t1 wrote:> > You can make the function yourself. That you may have problems with> typing are indicative that the language could use a more expressive> type system, not that it was a good idea to create an intrinsic that> could (potentially) ignore types. I don’t remember what it did exactly. Like this maybe? n = (x != 0) ? 10 : 20; if x <> 0 then n := 10else n := 20; n := IfThen(x <> 0, 10, 20); People are probably sick of doing that and wanted a more concise statement. I’ve even seen people do stuff like this because they’re fighting the language. if x <> 0 then n := 10 else n := 20; They probably wanted something like this: n := if x <> 0 then 10 else 20; Not too crazy in my opinion. Without wanting to reopen the debate or appear to be criticising the developers, ALGOL-60 did this: FOR I := 1 STEP 6 UNTIL M DO BEGIN PCHTX(SYTB[I], WRITEBUFFER[0], IF M-I > 6 THEN 6 ELSE M-I+1); WRITE (PCH,10,WRITEBUFFER[*]); CLEAR(WRITEBUFFER[0],9) END; I make no apology for the layout, since that's a fragment of Wirth's own code. -- 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] Syntax changes suggestions
don't like looking at such C code, so why would I want that in Pascal This is not my fight because TBH I'm inclined to avoid novel language features until I know that using them won't impact on some of the older kit I try to keep stuff compiled for. However, I do wish that people wouldn't resort to that same old chestnut. There ought to be a Pascal discussion equivalent of Godwin's Law: "sooner or later in any debate about a language feature somebody will complain that it's too much like C". Frankly, who cares? are we really all so insecure that we can't accommodate even the suggestion that "our opponents" occasionally have a good idea? Besides which, in-block declarations predate C: it's the way that ALGOL-60 did it. And ALGOL-60 put the type before the variable in a declaration, had in-expression conditionals and so on: all things I've seen rejected offhand as "too much like C". So come on chaps, at least get your history right and say that you prefer the Pascal way and won't have any ALGOL crap messing it up. Pax vobiscum. -- 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] Syntax changes suggestions
On 17/07/18 09:15, Henry Vermaak wrote: On Mon, Jul 16, 2018 at 03:02:42PM +0200, Sven Barth via fpc-pascal wrote:> Santiago A. schrieb am Mo., 16. Juli 2018, 13:41:> > > I have some suggestions of change to freepascal syntax, just to debate> >> > (All are backward compatible)> >> > - Declaring variables inside blocks, and loop variables> >> -> reduces readability -> no interest How can it reduce readability? You move variables closer to where theyare used, therefore reducing clutter in the main "var" section.Limiting variable scope is definitely a good thing, I sure hope you'renot arguing against that. That's why almost all languages encourage it. Agreed, and that's /particularly/ the case with something like a loop control variable which should not be assumed to have a predictable value out-of-scope. Wirth moved variables outside blocks to make Pascal incompatible with ALGOL, since after the disastrous ALGOL-68 fiasco he wanted to plough his own furrow. That doesn't necessarily make the decision a wise one. -- 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] Feature announcement: Dynamic array extensions
On 20/06/18 20:00, Sven Barth via fpc-pascal wrote:
Addendum: the support for the "+" operator is now coupled to a new
modeswitch "ArrayOperators".
If the modeswitch is enabled, then the operator can not be overloaded
and it also won't be used even if an overload from a unit without the
modeswitch is in scope (the compiler however issues a warning if this is
the case, so you can either remove the overload or disable the
modeswitch). If the modeswitch is not enabled then everything behaves as
before.
The modeswitch is enabled by default in Delphi modes as this feature was
added for Delphi compatibility. If you want to disable it in those modes
then you need to do this:
=== code begin ===
{$mode delphi}{$modeswitch arrayoperators-} // Note the "-"
=== code end ===
Sven, please could we have a further update when you decide what version
of the compiler will get the new facility, so that those of us with code
that might clash can make sure we have version-specific conditionals in
place.
--
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] Proper preprocessor?
On 20/06/18 17:30, Marco van de Voort wrote: That would be C incompatible, which I thought was the main reason to haveit? I don't believe Ryan said that (and I certainly didn't). It's the functionality that counts, not slavish adherence to any particular syntax. -- 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] Proper preprocessor?
On 20/06/18 16:00, Marc Santhoff wrote:
On Wed, 2018-06-20 at 22:45 +0700, Ryan Joseph wrote:> > On Jun 20, 2018, at 10:20 PM, Marc Santhoff
wrote:> > > > The spots where resolving single parameter macros is done are pretty easy> > to> > find. Parsing
the macro text and replacement will be the hardest part, as> > Michael wrote. A bit of housekeeping for parameter-type lists,
etc...> > Easy? I’ve wanted to contribute to the compiler for years but it’s so> daunting finding anything I give up. I’m
curious how the parser works so> please show me where the parser does the $defines. Maybe I can figure it out> this time.
When I looked around it was in
scanner.passymsym.pas
Just grep for "macro".
If there is more or I'm wrong hopefully one of the "compiler guys" will helpout
here, please. ;)
Word of caution: IIRC macros only work properly in comments delimited by
braces {}
--
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] Proper preprocessor?
On 20/06/18 14:45, Marc Santhoff wrote: But I speak up for another reason: Long ago, at the time of fpc 1.9.x or 2.0.x I did some digging in compilersource code, the lexer and parser part. IIRC there were some hooks for callinga proprocessor in the code at that time. If they are still there, wouldn't itbe a solution for both sides? The compiler programmers only have to activate (or complete) a way to call apreprocessor, solving the problem of mangled error messages. The preprocessor user could implement whatever is needed on his or her side? My 2 cent,Marc Is that what the PREPROCWRITE define is for? My 1½d :-) -- 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] Proper preprocessor?
On 20/06/18 13:45, Ryan Joseph wrote: On Jun 20, 2018, at 8:09 PM, Michael Van Canneyt wrote:> > Nothing stops people from preprocessing their code if they need really> advanced preprocessing: The toolchain can handle it already.> > But there is no need to integrate it in the compiler and thus needlessly> complicating it even more. The consequences of such a step are far-reaching.> > And till now, no-one has presented the really pressing use cases that would warrant such a step. How can you integrate a preprocessor without misaligning error messages and debugging information? I forget the detail but some language implementations have pragmata which tell subsequent processing steps that at this point the source should be considered to have come from such-and-such a line number in such-and-such a file. -- 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] Proper preprocessor?
On 20/06/18 10:00, Ryan Joseph wrote:
On Jun 20, 2018, at 3:50 PM, Michael Van Canneyt wrote:>
> Because it is simply a bad idea ?
Yeah that’s what the programming gurus in ivory towers and professors keep
saying but what about the person actually trying to finish some work? It really
sucks trying to fight the compiler sometimes because of engrained dogma.
How does an external preprocessor work if the compiler doesn’t about it?
Doesn’t it totally mess up the line numbers for debugging? I’d happily write my
own even if it was compatible with the compiler.
Pascal has some trivial macro support. {$define m:=xyz}> > If you need more than
that, you can use m4 or so. Lazarus has support for> pre-compile commands, so you can
always configure it to preprocess your> files if you are so inclined.
We've been here before, and not long ago.
I've done my fair share of language advocacy in the past and in general
am no friend of C, but I suggest that a number of people- on both the
"pure" and the "pragmatic" sides of the argument- could very much do
with "cooling it".
I'm pretty sure that the preprocessor issue was discussed a few months
ago with somebody pointing out that the Pascal compiler's macro handling
was deficient in that it had no concept of parameters. I believe that
the consensus was that it might possibly be desirable for the compiler
to be able to invoke an external preprocessor for the main unit and then
for each one that it imported, but that we didn't get as far as
considering its implications for include files etc.
The other alternative would be break the compiler in such a way that it
was usable from a standard makefile, but since there isn't separate
compilation of definition and implementation parts this would probably
impact on type safety. I believe that this too has been debated in the
past, and has attracted even less enthusiasm than a hook for an extrnal
preprocessor preprocessor.
--
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] Feature announcement: Dynamic array extensions
On 07/06/18 10:45, Martok wrote: What actually happens is that the memory is released back to the heap > (but *not* to the OS, at least on Linux), with the result that > concatenating elements will introduce a substantial hit particularly if > space for a new element allocated from the heap isn't contiguous.Writing a preallocating wrapper *where needed* for heavily grown arrays isfairly simple. The thing is: it's rarely worth it ;-)I recently did that for a wavefront mesh loader that appends vertices one-by-oneto an array, and for a scene with some 400k vertices, the difference was justsome milliseconds out of several seconds overall.Turns out the allocator usually finds a spot where the array doesn't need toactually be copied around for a while, and the pure bookkeeping of realloc isvery cheap. The bit of code I was looking at was a mainframe emulator reading a tape to find the block positions, I was appending elements individually using a user-defined + and it wasn't exactly fast (resulting in a tape load time probably slower than the hardware would have had 60 years ago)... although obviously not as bad as Nitorami's suggestion that every concatenation would result in a syscall. I'd been expecting that SetLength() would do the same as it does with a string, i.e. prune the valid range without releasing memory. What I've done so far is only interim code and I've got lots of ways round it, but the reality check was useful :-) -- 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] Feature announcement: Dynamic array extensions
On 04/06/18 12:00, Nitorami wrote: It would be reasonable to assume that the predefined + might be>> substantially more efficient than a programmer-defined one could be. Yes, that's one of the reasons I vote for keeping the new feature>and allow to overload the operator. I don't think that argument holds water. Concatenation of dynamic structuresis a slow function in the first place. I am not a core developer, but Iconsider that regardless how you do it, it will require a call to setlength,which in turn will call the operating system to allocate memory for the nowlarger structure. That takes much more time than a few assembly instructionsfor a normal pascal procedure call. The obvious workaround is to preallocate a dynamic array to a nominal size and then to trim it using SetLength(0), I'd assumed that it would retain ownership of the memory but I've just checked. What actually happens is that the memory is released back to the heap (but *not* to the OS, at least on Linux), with the result that concatenating elements will introduce a substantial hit particularly if space for a new element allocated from the heap isn't contiguous. -- 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] Feature announcement: Dynamic array extensions
On 03/06/18 16:30, denisgolovan wrote: Having worked with APL for almost 6 years and continuing with Q/KDB, I would say APL syntax is much more readable than Perl 6. Horses for courses. I think the impressive thing about APL is that the necessary operations were worked out (and used for Blackboard demonstrations) /before/ it was converted into a computer language, and by and large weren't added to. However the functional nature of the language was vastly overrused, and students who thought they were being smart would on occasion find themselves with mainframe runtimes of /months/ because they'd created an enormous array instead of using a simple control structure. Nod here to Vector Pascal as well. And as a bit of history, the first computer implementation of Iverson's notation was done at Stanford under the watchful eye of Niklaus Wirth. Though being able to modify language like that is really impressive. I agree, which is the main reason I posted the link. -- 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] Feature announcement: Dynamic array extensions
On 03/06/18 14:30, Ryan Joseph wrote: On Jun 3, 2018, at 9:07 PM, Marco van de Voort wrote:> > But nobody + an item to their item list. The operator is "+" not "add". What other operators could be used then? There’s only so many characters on the keyboard after all. My only interest is because it’s fast to type and looks nice. Swift allows you to overload any operator in the unicode set so we could make up our own crazy stuff. :) list • 1; // list.Add(1); All of the predefined ones have the problem of clashing with arithmetic use in numeric vectors. I'd note that Perl uses . but my preference would be _ (followed by whitespace, or at least not by something that would make it look like a variable name). People with deeply masochistic tendencies might appreciate the link below, if unavailable Google might have a cache. http://www.dlugosz.com/Perl6/web/APL.html -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] http://webcache.googleusercontent.com/search?q=cache:ag72S4uAW30J:http://www.dlugosz.com/Perl6/web/APL.html%2B%22provide+SIMD+processing+without+writing+explicit+loops,+and+APL+also+has+the+feature%22=firefox-b=en=clnk ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Feature announcement: Dynamic array extensions
On 02/06/18 13:00, Mattias Gaertner wrote: Sven Barth via fpc-pascal hat am 2. Juni 2018 um 09:42 geschrieben: > > denisgolovan < denisgolo...@yandex.ru> schrieb am Sa., 2. Juni 2018, 09:18: > > @Sven > > Please reconsider "+" operator for arrays if your changes really forbid to overload operators for arrays now.> > > It wasn't me who implemented that part. I personally had planned to do it with a warning for existing overloads, but Florian beat me to it and implemented it this way. Though when asked by me he did say that we'll wait and see if people complain... So *maybe* we'll change this. +1 for the possibility to overload this operator. It would be reasonable to assume that the predefined + might be substantially more efficient than a programmer-defined one could be. -- 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] Feature announcement: Dynamic array extensions
On 02/06/18 08:00, Ryan Joseph wrote: On Jun 2, 2018, at 2:42 PM, Sven Barth via fpc-pascal wrote:> > It wasn't me who implemented that part. I personally had planned to do it with a warning for existing overloads, but Florian beat me to it and implemented it this way. Though when asked by me he did say that we'll wait and see if people complain... So *maybe* we'll change this.> btw why can’t there be both? You can have multiple + operators for any given dynamic array type can’t you? typeTArrayOfInteger = array of integer; operator + (left: TArrayOfInteger; right: integer): TArrayOfInteger;var i: integer;beginfor i := 0 to high(left) do left[i] += 1;end; operator + (left: TArrayOfInteger; right: TArrayOfInteger): TArrayOfInteger;begin result := Concat(left, right);end; Agreed, both are extremely useful and have an intuitively unambiguous meaning (unlike - which can be useful but doesn't have an unambiguous meaning). However as Dennis points out + is also essential for vector operations. Perhaps either leaving it to the programmer to define what's needed would be the best approach, or alternatively splitting dynamic arrays into mathematical vectors and non-mathematical collections. Or relaxing the requirement that only predefined operators can be redefined, so that something like _ could be used for concatenation. -- 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] Realtime and freepascal???
On 31/05/18 10:45, Dennis wrote: Darius Blaszyk wrote:> Hi,>> For a hard real-time project I am considering using freepascal. As > this is my first endeavour in real-time I would like to ask the > community on their experiences. Is FPC suitable for this kind of > applications? If so what commercially available boards are out there? > I believe a beagle bone for instance is capable of doing realtime > applications because of the PRU. Which are certainly good for data capture, anything more complicated than that and I hope you're good at assembler. other credit card size boards > worthwhile investigating? What RTOS do people have good experience > with in combination with freepascal?>I am not sure Beagle Bone is a good choice because it seemed to have supply problem for many years. It is hard to purchase large quantity of it.In the past, I have use raspberry Pi connected to many simple devices via a serial bus. The PI acts as a server to accept commands from the internet and forward them to the devices on the serial bus and pass back the responses to the internet. The software was written in FPC. It's notable that the Boeing "Dreamliner" uses Ethernet heavily for both control and passenger entertainment, allegedly with the various subsystems both firewalled and airgapped (which raises the question: would one really need both if one were confident in what he was doing?). Also, check out this https://ultibo.org/Which is an embedded OS written in FPC, so you just modify the source code to include your application and recompile a new embedded OS for use with raspberry Pi.That way, it has lower latency and lower RAM requirement than running your FPC program on top of the Linux OS. Which is certainly a valiant attempt, although my tastes run towards systems with robust protection between segments/addressspaces. -- 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] Feature announcement: Dynamic array extensions
On 20/05/18 12:30, Sven Barth via fpc-pascal wrote: ## "+" operator The compiler now implements a "+" operator for arrays which is the same as if Concat() would be called on the arrays. Note regarding backwards compatibility: existing "+" operator overloads for dynamic arrays no longer compile. Does that only apply when both operands are compatible dynamic arrays, or does it also break definition of + to append an element to an array? -- 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] FPC on Android tablets: ARM, x86_64
On 11/05/18 15:15, Alexander Grotewohl wrote: FPC for ARM works correctly with termux, but the program to generate fpc.cfg does not, requiring some manual configuration to get it to find the included units, etc. Apparently requires libpthread, which in our case we have not got. Is this really needed, and since this program should be usable as a system's "sanity check" is there any way to improve the error reporting? -- 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] FPC on Android tablets: ARM, x86_64
On 11/05/18 15:15, Alexander Grotewohl wrote: FPC for ARM works correctly with termux, but the program to generate fpc.cfg does not, requiring some manual configuration to get it to find the included units, etc. I've copied over a preinstalled x86_64 compiler etc. from my desktop system to a tablet and individual programs appear to be executable, which is quite an achievement in itself: eat your heart out, Dynabook :-) I agree that fpcmkcfg looks to be a bit of a problem. On one occasion it deigned to tell me that there was an fpcmake (?) problem, I'll see if I can get a better grip on it. Basic operation of the the text IDE appeared OK, as did a program written using a text-mode dialogue editor (Dialedit3b); however I suspect that an abrupt switch from landscape to portrait mode is likely to be a problem. -- 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] FPC on Android tablets: ARM, x86_64
Thanks both for that. I've got an Intel-based tablet here and might have a play. On 11/05/18 15:15, Alexander Grotewohl wrote: FPC for ARM works correctly with termux, but the program to generate fpc.cfg does not, requiring some manual configuration to get it to find the included units, etc. On 05/10/2018 07:19 AM, Mark Morgan Lloyd wrote:> Has anybody come across https://wiki.termux.com/wiki/Main_Page which > I've seen mentioned elsewhere?>> It's supposedly a Linux environment into which one can install > standard development tools etc.> -- 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] FPC on Android tablets: ARM, x86_64
Has anybody come across https://wiki.termux.com/wiki/Main_Page which I've seen mentioned elsewhere? It's supposedly a Linux environment into which one can install standard development tools etc. -- 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] detecting recursive loops
On 05/05/18 21:15, James Richters wrote: I'm having an issue with one of my programs that I suspect is being caused by a recursive loop... in simplified form... something like this: Procedure Proc1;Begin Proc2;End;Procedure Proc2;Begin Proc1;End; I ended up getting a runtime error and the report showed something like above, where I had a loop of the same 3 procedures calling each other over and over in sequence in a loop before the actual error. Unfortunately I didn't take down all the information because I thought I could make it happen again.. but I haven't had the runtime error again... however under certain conditions sequences that normally happen very fast become very slow and I suspect it somehow is getting into this recursive loop again. It's a very large very complicated program and trying figure out where this is happening is becoming quite a challenge. I was wondering if there is some method of detecting these recursive loops, either during compilation, or is there some option that would force a runtime error if a loop of procedures happened. Any ideas how to identify potential unintentional loops? I occasionally put entry/exit counters on functions that I suspect are going to be a problem, InterlockedIncrement() etc. You can obviously have your code check that as a verification of sanity, or pick up a haig value using a conditional breakpoint. -- 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] Using constants instead of comments
On 18/04/18 12:15, wkitt...@windstream.net wrote:
On 04/17/2018 11:06 PM, James Richters wrote:> I have a whole section of
diagnostic writeln's in a program, and it's tedious to comment them all
out/in as needed. I'm curious if doing something like
what's wrong with traditional IFDEF?? use something like this...
{$IFDEF DEBUG}writeln ('blahblahblah');writeln
(LOGFILE,'blahblahblah');flush (LOGFILE);{$ENDIF}
then you simply create the DEBUG define...
-DDEBUG
if you don't want it, leave it out and none of the bracketd code is even
included...
I agree. Another possibility is something like
{$if declared(customDebugWrite) }
customDebugWrite(...);
{$endif declared() }
so if customDebugWrite() isn't present in the program during compilation
(commented out, or the entire unit containing it omitted) no attempt
will be made to call it.
--
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] Seek with text file
On 03/04/18 12:45, Rik van Kekem wrote: From the code-snippet from Anthony you can see it's really easy to use. 1000 lines of about average 70 characters per lines would be72*1000=70MB. 72 kB, not MB. Big enough to give some very old systems problems if they used a Windows component as an editor, but these days trivial. Historically, things like "text" and "file of string[80]" have been fraught because of OS-specific interpretations of what a line of text was. These days there are still ambiguities because of UTF-8 etc. -- 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] Proposal for new Free Pascal logo
On 02/04/18 09:45, Michael Van Canneyt wrote: remove the whiskers. As an exercise I have done the job for you. See here: http://www.freepascal.org/~michael/pascal_logo2.png It's of course better to improve the original, I am not an artist.(I even would get rid of more elements, but let's start with this) If we're talking branding anyway (a subject I loathe), then a logo should represent the company/product group, whatever. So, the FPC logo should exhale maturity, strength, prowess, self-confidence. Hardly things one associates with a kitten. FPC is an open-source project dating back to the days the word "open source" did not exist. So maturity is important. Using marketing/branding talk:Given that I think your version looks like a kitten, you will understand that for the reasons explained above, I would not want to be "associated" with the logo as you proposed it now. More to the point, why is a Cheetah logo being discussed in the context of Free Pascal? If FPC is to have a logo it should be distinct from Lazarus since it's a separate project, although ideally they'd be complementary: an expanse of bushveldt with a couple of trees or similar (but please, no prey animals). There's also the important question of whether an image selected as a logo can be scaled down to be used as an icon. -- 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] Linux getifaddrs
On 01/03/18 15:15, Brian wrote: Do you know of any kernel functions that would return the current IP address? I think you're looking for something like SIOCGIFADDR in netdevice(7), but it's not necessarily what you want. You need to take into account that a single host might have multiple interfaces, and that each interface might have multiple assigned IP addresses (aliases in IP4 terms). In practical terms you almost always either want to tell a program which of the available IP addresses to use or let it use 0.0.0.0, and don't for one moment dream of embedding an IP address inside your comms protocol since you'll end up with a proxying nightmare like VOIP. The only time I've really needed to play with this was when trying to work out a machine's local neighbours so I could see whether they responded to a non-standard UDP protocol. -- 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] Connecting to a database from a commandline pascal program
On 16/02/18 16:00, Terry A. Haimann wrote:
Hello,
I am trying to write a command Line Pascal program to connect to a
MySQLdatabase using the ZeosDBO Library. I am sure I have done somethingstupid.
I have it now so that it will compile, but it crashes as soon as I tryto modify
my TZConnection variable.
I have it defined as:
MyConnection: TZconnection;
And code is defined as:
WriteLn('2'); MyConnection.Create(Nil); // MyQuery.Create(Nil);
WriteLn('2.0); MyConnection := '127.0.0.1';WriteLn('2.1');
MyConnection.Protocol := 'mysql'; WriteLn('2.2'); MyConnection.Database
:= 'MyDatabase';WriteLn('2.3'); MyConnection.User := 'MyUser';
WriteLn('2.4'); MyConnection.Password := 'MyPass';WriteLn('2.5');
MyConnection.Connected := True; WriteLn('2.6');
It never hits 2.0, so I believe it is dying on the create. Am I doingthe create
wrong? I can't find any examples as too doing this, I havetried googling it.
Most of the examples I see are doing this fromLazarus. Not from a command line
Free Pascal program.
Shouldn't that be MyConnection := TZconnection.Create(nil);
--
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] Linux udev messages
Has anybody used NETLINK_KOBJECT_UEVENT on linux to get messages relating to device hotplugging and removal? It seems like the sort of thing that could be monitored by a TIdleTimer event handler for at least cosmetic purposes. Area of application is a configuration utility for a Logitech G600 mouse. -- 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] Sleep(30) is not reliable?
On 24/01/18 16:15, AlexeyT wrote: In Lazarus component EControl I call Sleep(30) to wait when timer tick work is done. while FBusy do Sleep(30); and app loops forever now in sleep(). procedure Sleep(milliseconds: Cardinal);Var timeout,timeoutresult : TTimespec; res: cint;begin timeout.tv_sec:=milliseconds div 1000; timeout.tv_nsec:=1000*1000*(milliseconds mod 1000); repeat res:=fpnanosleep(@timeout,@timeoutresult); timeout:=timeoutresult; until (res<>-1) or (fpgeterrno<>ESysEINTR);end; It is fpc 3.0.2. IDE Lazarus shows long loop inside this 'repeat'. i waited 10-20seconds. What happens if you put an Application.ProcessMessages in there? -- 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] FPC on zSeries Mainframes
On 01/01/18 13:00, Graeme Geldenhuys wrote: Hi, I remember back in 2012 (I think) there was a large discussion about implementing support for the zSeries IBM mainframes. The wiki had many pages on the topic too. http://wiki.freepascal.org/ZSeries Anybody know what actually happened with those efforts? Was there something usable in the end? There was a lot of discussion that boiled down to five things: * Should the compiler (as distinct from the generated code) use EBCDIC and what effect did this have on collation order assumptions? * Older members of the range used a proprietary floating-point format. * Older members of the range didn't have dedicated stack operations and were restricted to a 12-bit relative addressing offset. * Allowing for the unrestricted availability of 1980s operating systems that were restricted to the above, what should the target of an FPC implementation be? * What assembler would be supported, allowing that IBM system software long described interfaces in terms of assembler macros? One developer- who put a lot in the wiki- appeared to grind to a halt when he realised that it wasn't possible to generate a static cross-reference listing for the FPC compiler, due to the number of runtime decisions made based on the class of elements in the parse tree etc. If I may express two personal opinions: * My preferred target hardware would be the oldest that got stack and large-offset support, which was also where GCC started taking it fairly seriously. I believe there is at least one GCC port that targets older hardware (Paul Edwards?). * My preferred target operating system would be VM/380, which is VM/370 with what is effectively a DOS extender to allow it to compile programs that require >16 MegaOctets. My basis for this preference is that its lineage (Multics etc.) makes it pleasingly familiar to people used to PC-DOS and unix, I've been criticised by somebody who would prefer MVS on the basis that the interface macros are different but I consider this to be a detail since the code generation would probably be common. Bernd Oppolzer is actively maintaining a derivative of the original "P" compiler on VM/370 http://bernd-oppolzer.de/job9.htm and I expect this to be bundled with the next release of the VM/370 "Sixpack" http://www.smrcc.org.uk/members/g4ugm/vm-370/VM370sixpack-1_3-Beta.zip which will run on top of the Hercules emulator. I can't remember whether he was able to compile it using FPC, there were some string-expansion issues (relating to mainframes using fixed-length records) giving him problems. Gotta go, venison's done :-) -- 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] Why win64 program are considerably bigger in exe size than win 32?
On 31/12/17 00:15, Martok wrote: Oh, and I finally know why even simple LCL applications are so large: graphicsdrags in fcl-image, which includes full support for JPEG, TIFF, PNG and requirespasjpeg, paszlib and others. The widgetset indirection is surprisingly small. Interesting. -- 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] Why win64 program are considerably bigger in exe size than win 32?
On 22/12/17 12:45, leledumbo via fpc-pascal wrote: Why? At least pointer size takes double space, multiply it with every instances1.5x bigger is not impossible. Particularly if the binary contains debugging information. -- 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] Is there some example of an FPC program for use in svn hook calls (email)?
On 14/12/17 10:00, Adriaan van Os wrote: Bo Berglund wrote: Now I am looking at the same problem for svn and this time I need it> to be cross-platform, hence using FPC.> Before I start on it myself I wonder if someone here has already> written such a program for svn and if so, if it is available as open> source? I use sendmail <https://en.wikipedia.org/wiki/Sendmail> from FPC, using AssignStream, fpgeterrno and PClose. Haven't tried that on Windows though. With the caveat that while Sendmail is a well-respected MTA, many unix systems also provide a sendmail command as a generic mailer. On Windows Blat is an alternative. -- 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] FORTRAN from FreePascal
On 20/11/17 12:00, Schindler Karl-Michael wrote: Am 20.11.2017 um 12:00 schrieb fpc-pascal-requ...@lists.freepascal.org:> > Date: Sun, 19 Nov 2017 11:14:50 +> From: Mark Morgan Lloyd <markmll.fpc-pas...@telemetry.co.uk>> To: fpc-pascal@lists.freepascal.org> Subject: Re: [fpc-pascal] FORTRAN from FreePascal> Message-ID: <ourp3a$fub$1...@pye-srv-01.telemetry.co.uk>> Content-Type: text/plain; charset=utf-8; format=flowed> > Oh really? Well I'll let you travel back in time and argue with numerous > former colleagues who've routinely found differences between their > "fortran" (-IV, -77 or whatever) and "fast fortran" compilers which in > those days tended to be separate programs even if supplied together. Wasn't the problem somewhat different? There have always been "fast-math" version of some costly function. So, the point was, whether the faster routines could be used at the price of their larger numerical errors. Similarly, the choice of the optimization level of a compiler needed to be checked. Furthermore, the wide spread use of fortran for numerical intense simulation up to this date stands in contrast to your statement, in particular in the field called high performance computing. Possibly. It might be that the "fast" variant of the compiler was actually pulling in different libraries. However, the situation as described to me has always been in terms of "if you have problems don't use the 'fast' compiler" or, with more recent development tools "the first thing to try is turning optimisation off". And this advice seems to /particularly/ apply to FORTRAN. And leaving aside for the moment a small number of specialists who I only know from subscription online services etc. (such things do still exist), I've had this in most detail from well-respected senior academic colleagues one of whom had been involved with the design of the Manchester computers back when 2K words was "more than a man can keep track of". Oh, and the story about Turing suggesting using gin in the delay lines is inaccurate. He merely observed that gin, as an aqueous alcohol mixture with trace oil content, was excellent for cleaning the transducers before the line was filled with mercury. But this is getting way off topic and we'll get a "moderatorial cough" any moment :-) -- 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] FORTRAN from FreePascal
On 19/11/17 12:15, Bo Berglund wrote: On Sun, 19 Nov 2017 11:14:50 +, Mark Morgan Lloyd<markmll.fpc-pas...@telemetry.co.uk> wrote: I think we're in broad agreement though: don't try converting backend >code unless you know exactly what you're doing, and Pascal (including >Lazarus/LCL etc.) can be valuable when implementing a C21st frontend :-) We do have the original Fortran code and only really want to be ableto handle changes in operating system needs (like changing Windowsrequirements) or even porting to Linux.But currently we are not able to compile new DLL:s even since we don'thave a Fortran compiler. Can GNU Fortran be used for testing? For example is GNU Fortran (https://gcc.gnu.org/fortran/) possible tobuild on Windows? I have very limited experience in compiler buildingexcept for FreePascal, which I have built many times... AFICT the *sources* are available via SVN:https://gcc.gnu.org/svn.html https://gcc.gnu.org/wiki/GFortranBinaries -- 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] FORTRAN from FreePascal
On 19/11/17 10:15, Adriaan van Os wrote: Mark Morgan Lloyd wrote: That obviously applies to all languages, I've never come across > something which can represent 1/3 or pi exactly. If you do read what is written in the link - that is not the issue. The issue is how to interpret floating-point constants and how to convert single-precision floating-point to decimal. In BCD, that conversion is exact. I read the link before posting. You aren't going to represent 1/3 or Pi exactly in BCD either. But FORTRAN- or rather > the way that people use it- has always seemed peculiarly sensitive, the > classic problem being that recompiling with the optimising variant of > the compiler produces significantly different results. This is nonsense too. The issue is whether to use IEEE-754 math or not. And there are (or should be) compiler switches for that purpose. Not just in Fortran. Oh really? Well I'll let you travel back in time and argue with numerous former colleagues who've routinely found differences between their "fortran" (-IV, -77 or whatever) and "fast fortran" compilers which in those days tended to be separate programs even if supplied together. I stick to my position: a "tidy" language (I'm not going to fall into the trap of using a word like "regular" here) generally results in a tidy compiler design, and that should go a long way towards avoiding implementation errors. I think we're in broad agreement though: don't try converting backend code unless you know exactly what you're doing, and Pascal (including Lazarus/LCL etc.) can be valuable when implementing a C21st frontend :-) -- 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] FORTRAN from FreePascal
On 19/11/17 04:00, Adriaan van Os wrote: Mark Morgan Lloyd wrote:> I think that conventional wisdom is that if somebody's written numerical > analysis code you don't change it gratuitously, since any alterations > will change rounding errors etc. For some reason, that seems to apply > particularly to FORTRAN programs :-) The reason being explained here <https://gcc.gnu.org/onlinedocs/gcc-3.4.6/g77/Floating_002dpoint-Errors.html> That obviously applies to all languages, I've never come across something which can represent 1/3 or pi exactly. But FORTRAN- or rather the way that people use it- has always seemed peculiarly sensitive, the classic problem being that recompiling with the optimising variant of the compiler produces significantly different results. Elsewhere I came across discussion of (I think it was) a DEC FORTRAN compiler which produced the wrong results in a block of code only if it followed a comment. There's always been something grubby about FORTRAN compilers, and by now I find myself wondering whether people should even be attempting to design languages which don't compile easily (i.e. using recursive descent or whatever). -- 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] Seek to EOF of file of byte
On 18/11/17 21:15, pasc...@piments.com wrote: On 18/11/17 20:27, Mark Morgan Lloyd wrote:> because the program is being viewed critically by the ALGOL programmer > whose code Algol, one my all time favourite languages. while wendif fi why is this not universally adopted? I still comment my C code with fi's and wend's to keep track of what a bunch of curly braces actually refer to. /Don't/ get me going, particularly here. Basically, because Wirth threw his toys out of the pram when ALGOL-W was rejected, and rushed out Pascal as an alternative without looking at the few bits of ALGOL-68 which were useful for something. He didn't come to his senses until Modula-2 or his involvement with Ada (I'm not sure which came first) but by then the damage was done. -- 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] Seek to EOF of file of byte
On 18/11/17 19:30, Graeme Geldenhuys wrote: On 2017-11-18 15:44, Mark Morgan Lloyd wrote:> How should one do this?> https://www.freepascal.org/docs-html/current/rtl/system/seekeof.html> implies that it's only for text files, Seek(f, FileSize(f)) seems excessive. Just curious, why would you consider the "old technology" instead of using TFileStream (or any of the other TStream descendants). I'm actually busy converting some old apps that used "t: Text" style coding, and replacing it with more modern Stream-style code, and it works really well. Streams are so much more flexible. With your propensity for "I wouldn't start from here" answers I'm surprised you're not on CIX :-) Basically, because the program is being viewed critically by the ALGOL programmer whose code I'm converting, and a number of other people of a comparable generation and background. So while I'm using OO fairly heavily and threads where the architecture makes them appropriate ** I'm trying not to change stuff gratuitously. ** The original code tried to simulate up to 2x CPUs and up to 4x IOPs using a single thread. I'm trying to do it properly. -- 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] FORTRAN from FreePascal
On 18/11/17 19:45, Bo Berglund wrote: On Sat, 18 Nov 2017 17:06:25 +, Mark Morgan Lloyd<markmll.fpc-pas...@telemetry.co.uk> wrote: I find myself wondering, in part due to conversations elsewhere: can the >Lazarus IDE do anything at all sane with a FORTRAN routine called from >Pascal? In the D7 application written in ObjectPascal calls were made into theFORTRAN created DLL:s referencing multi-dimensional arrays of data.Fortran processes the inversion and returns modified/new array output.So as long as the interface is like this and the calling conventionsare OK it should work also from Lazarus/FPC. Except that when you're calling into a DLL (.so on Linux etc.) I don't think you have much chance of seeing the inside of the library code. With a statically-linked program it should be possible. A friend-of-a-friend has a certain amount of legacy FORTRAN, so this is something that I really must find the time to try at some point. I think that conventional wisdom is that if somebody's written numerical analysis code you don't change it gratuitously, since any alterations will change rounding errors etc. For some reason, that seems to apply particularly to FORTRAN programs :-) -- 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] FORTRAN from FreePascal
On 18/11/17 16:45, Adriaan van Os wrote: Bo Berglund wrote: I would very much want to convert them into DLL:s programmed in Pascal> instead so they can be maintained for new Windows versions (and use 64> bit for example). Well, you would have to do that by hand. And you need sufficient understanding of Fortran to know what you are doing. I am not aware of a Fortran to Pascal converter. But why do that if Fortran compilers are available ? And even if a Fortran compiler wouldn't exist, there is a Fortran to C converter, named f2c. See for example <http://www.netlib.org/clapack/readme.maintain> I find myself wondering, in part due to conversations elsewhere: can the Lazarus IDE do anything at all sane with a FORTRAN routine called from Pascal? -- 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] Seek to EOF of file of byte
How should one do this? https://www.freepascal.org/docs-html/current/rtl/system/seekeof.html implies that it's only for text files, Seek(f, FileSize(f)) seems excessive. -- 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] FORTRAN from FreePascal
On 13/11/17 13:30, brian wrote: I need to try to put a user-friendly GUI and some graphical outputonto an old command-line FORTRAN number cruncher, and have beenprovided with around 130 KB of FORTRAN source code. A quick scan ofdocumentation seems to suggest that this is possible using gfortranand the C calling conventions (if someone knows differently, pleasesay so right now!) :) My knowledge of FORTRAN-77 is sound, if rather rusty, but I knowalmost nothing about C programming, having been brought up as achemist before I was dragged across to programming (I learned toprogram on Algol-60, BASIC and FORTRAN-IV, yes, that long ago ): ). Anyone with any past experience here? It seems I have two choices, totry to call the FORTRAN subroutines from FreePascal or to port theFORTRAN code to Pascal, I'm looking for advice... If the FORTRAN can be called from C as distinct from being able to call C subroutines, then I'd have thought that you'd be able to replace the main part of the program (that reads the data cards or whatever) with something written in Pascal. That would potentially allow you to put together a UI using Lazarus etc. Granted that various companies have long had translators from FORTRAN to ALGOL (particularly in the case of B who I don't think had a native compiler) or other languages, but I'd have thought that a full translation would be best avoided if possible. -- 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] Database apps on Debian etc.
On 12/11/17 09:30, Graeme Geldenhuys wrote: On 2017-11-11 18:41, Mark Morgan Lloyd wrote:> the FPC/Lazarus controls do a good job of presenting a common API> irrespective of what backend server is being used, would it be feasible> to have a "reconnect monitor" or similar to help recover from this sort> of thing? You should always program your software with the assumption that a network connection could fail at any point. The ability to try and re-establish the connection should be a standard feature in your applications. Programming database apps with tiOPF makes that pretty easy. Saying that, using Delphi/Lazarus RAD style development with DB-controls should also be able to allow that - I think. It's certainly possible to do it, I've done it. Is TSQLConnection.KeepConnection intended to automate this? -- 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] Database apps on Debian etc.
Graeme started a short thread on databases in "The Other Place" a few days ago, but I thought this might be of sufficient general relevance to raise here. I had a system outage this morning, with all apps suddenly losing their connectivity to the PostgreSQL server. It turned out that the cause of that was that Debian had done an unattended upgrade of the Postgres server, and by restarting it had killed all persistent connections. There is no "Can we kill your database when we feel like it?" question during Debian installation. I anticipate that the same problem will affect other databases or software to which a client program maintains a persistent session, unless explicit steps are taken to recognise and recover from a server-side restart. Noting that the traditional way of using the data-aware controls introduced by Delphi etc., is particularly vulnerable, and noting that the FPC/Lazarus controls do a good job of presenting a common API irrespective of what backend server is being used, would it be feasible to have a "reconnect monitor" or similar to help recover from this sort of thing? -- 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] MINIX 3 support
On 09/11/17 23:15, Graeme Geldenhuys wrote: Does FPC support the MINIX 3 target platform? Or has somebody attempted to port FPC to that platform? Interesting question, particularly now that it's being factory-installed :-) -- 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] FCL-WEB and PostgreSQL Support: Current Status
On 27/09/17 18:30, Marco van de Voort wrote: In our previous episode, Mark Morgan Lloyd said:> > Can you ellaborate a bit more on this Michael? Like how and where it isused? (Not mentioning company names, if it's a problem.) I was thinkingabout using it in various places, but as I don't know how widely they'retested and used and under what conditions, I didn't had the balls to offerthis as viable alternative against competing technology X.> > We definitely need more use case studies...> > The only problems I've experienced with FPC's support for PostgreSQL > were related to handling SQL queries (e.g. spurious parameter > substitution) rather than to dataflow. As such they were predictable and > could be worked round. Zeljan once explained an interesting practical problem he had. He said the connection per transaction model could be dangerous, speciallyin a mobile era where connections are often broken, and thus must wait ontimeout. This means during rush times, a server can run out of a fairlylimited ephemeral port inventory before abandoned connections start to timeout. That is a postgres problem though, not the FPC components Which I suppose really starts getting to be an issue when somebody tries to "put something in the cloud" without careful consideration of that type of scenario. -- 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] FCL-WEB and PostgreSQL Support: Current Status
On 27/09/17 15:45, Karoly Balogh (Charlie/SGR) wrote: Hi, On Wed, 27 Sep 2017, Michael Van Canneyt wrote: 2 - Are they recommended for use in production environments?>> Absolutely.> I use them in very high-load (and we're talking VERY high load)> environments, with 24/7 availability. Can you ellaborate a bit more on this Michael? Like how and where it isused? (Not mentioning company names, if it's a problem.) I was thinkingabout using it in various places, but as I don't know how widely they'retested and used and under what conditions, I didn't had the balls to offerthis as viable alternative against competing technology X. We definitely need more use case studies... The only problems I've experienced with FPC's support for PostgreSQL were related to handling SQL queries (e.g. spurious parameter substitution) rather than to dataflow. As such they were predictable and could be worked round. -- 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] Inclocked/declocked
On 11/09/17 19:45, Sven Barth via fpc-pascal wrote: I've rechecked and the thing is as follows:- the IncLocked call happens each time you assign a dynamic array toanother dynamic array variable or a by-value parameter (this alsoincludes being part of a record, but not a class instance or TP-styleobject)- the DecLocked call happens each time the array is cleared (as long asthe reference count is > 0 this only means a decrement of the count)which happens if you assign Nil, assign a different array (thedestination array is "cleared") or if the array variable goes out of scope The two routines are also used in context of Ansi- and UnicodeStringvariables as well as reference counted interfaces (aka COM-styleinterfaces). In contrast to what I wrote earlier the compiler does however not ensurea unique array if you only change an element, so given the followingexample: In the general case, will these force a membar or a cache flush? -- 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] Using Serial in a TCP/RS232 gateway, how to set buffer sizes?
On 06/09/17 19:30, Bo Berglund wrote: Where could I be losing incoming serial data? FTcpComm.IOHandler.ReadBytes(Buf, -1, false); .. SerWrite(FComH, Buf[0], Length(Buf)); SerWrite() returns the actual number of bytes it's written, which could be anywhere from the number passed as the parameter down to zero (if hardware handshaking's being used at a lower level). An intermediate value would indicate that a buffer's full somewhere, and that you should adjust your source address and length and have another shot. TCP is a stream protocol and you can't make any assumptions about the amount of data you get in one call. It's not reasonable to assume that buffers for serial comms are limitless, 2K is entirely reasonable to support most serial comms protocols or an 80x25 screen. -- 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] Using Serial in a TCP/RS232 gateway, how to set buffer sizes?
On 06/09/17 21:15, Bo Berglund wrote: I could also create another test program, a serial sniffer that couldbe set up to just log whatever appears on the serial lines. I need a3-way cable for that of course. I'd also suggest that that sort of thing works better with on-board or at least PCI-connected serial ports rather than relying on USB-connected ports. -- 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] Using Serial in a TCP/RS232 gateway, how to set buffer sizes?
On 06/09/17 18:45, Bo Berglund wrote: I have created a simple application which relays data from anapplication I am debugging in Windows7 to/from a remotely locatedembedded data system.I use the built-in fpc Serial unit to handle the serial data and anIndy10 TIdTcpClient for the network part.Data coming in on the serial port are mirrored out to the remote TCPserver and data returned from that server are mirrored to the serialport.The Windows application only uses RS232 for this type ofcommunication.At the remote location I have a Raspberry Pi uint where I haveinstalled and configured ser2net to do the same job in the remotelocation. My relaying application displays the number of bytes received andtransmitted on the interfaces so I can see what is going on. This scheme has worked fine for most commands and data transfers Ihave checked, but now I have run against a brick wall... There is a pair of commands designed to read and write a large sectionof the system CMOS RAM memory (where the data file system resides).When I try to write a 1 Mbytes big buffer the byte count in my relayerdoes not reach the correct number. The Windows application I amdebugging sends all of the bytes out the serial port (I have loggedthis), but the relayer seems to lose some data and therefore thetransfer fails. The binary protocol specifies at the start how manybytes are to be transferred (0x0FF000 or 1044486 decimal), then itsends the data followed by a two-byte checksum. The data system shallrespond with NAK or ACK depending on the outcome of the checksumverification.The problem is that when the Windows app is done sending the datasystem is still missing many kilobytesSo no ACK is returned, it is still in receive mode. Now I am looking at the Serial unit in order to figure out how buffersizes influence the performance. Apparently both Tx and Rx buffers areset (hardcoded) to 2048, which feels like a bit low to me. Is there some hidden property that makes it possible to increase thisvalue?What is the maximum size one can set it too? Not that I was responsible for. Refer to the Windows API for any limits. -- 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] Freepascal Floating Point Issue
On 21/08/17 22:15, Ralf Quint wrote: On 8/21/2017 3:02 PM, James Richters wrote:> I am having an issue with a simple floating point application. I am setting a variable to a specific value and immediately after I set it, it is not exactly what I set it to. Here's an example>>Draw_GX_Min:=999.999;> Writeln(Draw_GX_Min:3:30);>> The writeln results in 999.999002 >> Why is it not 999.999000 where did 0.02 come from?>Out of thin air... Well, kind of. Double floating point means 16 digitsof precision, so when you force a 30 digit precision output, anythingpast 16 digits is random garbage, at best... And in any event, that's probably much more precision than the GPU is using to generate the final image :-) -- 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] 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
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] 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] why the 0.5 in the Unix Epoch (for UnixToDateTime function)
On 01/08/17 12:15, Dennis Poon wrote: Vojtěch Čihák wrote:>> Hi,>> wiki https://en.wikipedia.org/wiki/Julian_day says that "... Julian > day number 0 assigned to the day starting at noon on January 1, 4713 > BC, ...">> The noon means 0,5.>Thanks,that is a weird definition though IMHO. Astronomer's convention. -- 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] Food for thought - language string improvement
On 06/07/17 20:00, Sven Barth via fpc-pascal wrote: On 06.07.2017 16:13, Graeme Geldenhuys wrote:> Imagine if FPC had type inference and multi-line strings, neither very> exotic features. The code then becomes:> > => var query := '''SELECT Customers.CustomerName, Orders.OrderID> FROM Customers> FULL OUTER JOIN Orders> ON Customers.CustomerID = Orders.CustomerID> ORDER BY Customers.CustomerName;'''> > FDQuery1.SQL.Add(query);> => > > Easier to read, easier to edit, no need for a IDE wizard or external tools. Completely ignoring the type inference which I'm definitely not a fan of- at least not in Pascal: In my opinion it would be better to improveand finalize the $IncludeStringFile patch from issue #25536 (https://bugs.freepascal.org/view.php?id=25536 ).It has the advantage that it doesn't change the language and that theinclude file can be viewed independently with an appropriate syntaxhighlighter (especially with more complex SQL statements - to stick withyour example - that is something that I'd really welcome).Of course it has the disadvantage that one can't easily add variables,but for things like this one can always pass the included string toFormat() and friends which in my opinion would be more cleaned up anyway. Some sort of heredoc approach would seem reasonable and I think it might be worth noting the PostgreSQL way: $$Dianne's horse$$ $SomeTag$Dianne's horse$SomeTag$ $function$ BEGIN RETURN ($1 ~ $q$[\t\r\n\v\\]$q$); END; $function$ -- 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 to TCP gateway in FPC?
On 03/07/17 21:00, Bo Berglund wrote: On Sun, 2 Jul 2017 12:27:45 +, Mark Morgan Lloyd<markmll.fpc-pas...@telemetry.co.uk> wrote: You were asking a few days ago about Application.ProcessMessages but >didn't respond to my attempt to tease out your understanding of what was >happening. Have you sorted that out to your satisfaction? I made a Lazarus GUI program to convert a serial stream to TCP to aremote server where it was again converted to serial.The question was raised because I have used APM inside the main loopof the application in order for it to process stuff like mouse clicksetc while running the main task.Then I figured that I should make a console program with the samefunctions, but APM is part of the Forms unit and this is not used by aconsole. So I was thinking that maybe the data handling wouyld notwork if it was missing... Now I decided to keep the GUI app and use it interactively when I needto run against the remote system. What's happening there is that an LCL-based program is single threaded, and if you're in any sort of tight loop you need to call APM to get any of the usual GUI stuff to work. When I coded those two extra reads the Linux/Solaris implementation had a comparatively tight loop, so I added the callback so that if they were being used in the main thread the GUI would carry on working. The Windows implementation isn't so careful with that. If they were instead being called from a background thread you'd obviously /not/ call APM, since in general that can only be safely called from the main (foreground) thread. However they can still be called usefully to put a Sleep(0) in the loop, i.e. a hint to the kernel that it can reschedule if it wants to. -- 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 to TCP gateway in FPC?
On 02/07/17 11:45, Bo Berglund wrote: The Lazarus relaying program using FPC serial and Indy TIdTcpclientcomponents works just fine! Now also with millisecond logging. Assuming you mean the standard serial.pp: yes, it was because of accurate logging etc. that I worked on it a few years ago. However be warned that as part of that effort I was looking at it on various hardware, and I found that USB serial introduces a lot of inaccuracy presumably because it's trying to bundle stuff up into packets. You were asking a few days ago about Application.ProcessMessages but didn't respond to my attempt to tease out your understanding of what was happening. Have you sorted that out to your satisfaction? -- 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 to TCP gateway in FPC?
On 26/06/17 22:30, Bo Berglund wrote: My problem here is the fact that the RPi is headless so the GUIprogram I have written with Lazarus will not work. Instead I have tomake a console version that can run on RPi for the test and here Ihave the concern that I am using Application.Processmessages, which Ibelieve cannot be used in a console program.How can I replace it? You're obviously correct that APM doesn't exist in a text-only program because it's part of the LCL. But I think you need to ask yourself why you need to /replace/ it, rather than just removing it. -- 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 to TCP gateway in FPC?
On 21/06/17 22:45, Bo Berglund wrote:
Two issues here:1) How do I enter a loop in a GUI application? In a command
lineapplication it is just going to be part of he main program code.
I'm not saying it's the right or the best way, but in the interest of
giving you something to work with I do this:
procedure TListForm.FormCreate(Sender: TObject);
CONST startParam= 0;
begin
..
Application.QueueAsyncCall(@OnAfterShow, startParam) (* Keep at end *)
end { TListForm.FormCreate } ;
PROCEDURE TListForm.OnAfterShow(afterShowParam: PtrInt);
(* guaranteed to be after all form creation etc. has completed. *)
BEGIN
..
END { TListForm.OnAfterShow } ;
That can loop, but make sure you put Application.ProcessMessages in it.
--
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 to TCP gateway in FPC?
On 21/06/17 05:30, Bo Berglund wrote: On Wed, 21 Jun 2017 01:57:36 +0200, José Mejuto<joshy...@gmail.com> wrote: The problem I have is that it seems only to work for COM1 or COM3, as>> soon as I use a higher numbered port like COM33 then it fails.>> What have I missed here?>> Is serial only able to work with the low numbered ports (single>> digit)?>>COM ports in windows can only be 1-9, to open high numbered COM ports >you must use the extended name syntax (without quotes) "\\.\COM99" you >can also use "\\.\COM1" for COM1-9. It turns out that I also must not use the trailing colon in the namewhich is present in the wiki example...But then I get a non-zero handle. I have yet to verify that data canflow. Is there a way to enumerate the available com ports so that they canbe listed in a combobox for selection? This would have the advantagethat it would work on both Windows and Linux and it limits thepossible errors by the user. Of course the enumerator must know aboutthe differences in syntax between Windows and Linux! Not reliably in unix. You have to know the various potential name patterns, i.e. /dev/ttyS*, /dev/ttyAMA* and so on, and then enumerate what's currently visible in the filesystem. It might be possible to get "hints" as to the device type from the /sys filesystem, but I'm not sure it's safe to rely on this. What about Linux (Raspberry Pi)? Is the com port name simply ttyUSB1or do I have to use the full /dev/ttyUSB1? You *definitely* have to use the name as given. You're opening a file in the filesystem tree, not an internally-reserved name. -- 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 to TCP gateway in FPC?
On 20/06/17 06:45, Michael Schnell wrote: On 18.06.2017 18:16, Bo Berglund wrote:> No RS232 work with FPC/Lazarus> earlier and in Delphi I used AsyncPro components, but these are so> complex that one is lost amongst all properties to set...AsyncPro is free and easy to use but not perfectly bug-free. Unfortunately no fpc/Lazarus port yet. I tend to use the lower-level serial.pp unit. The patches I contributed a couple of years ago specifically added a couple of read-with-timeout functions. -- 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] FPC for AVR
On 15/06/17 17:45, Bernd Mueller wrote: On 06/15/2017 10:34 AM, Mark Morgan Lloyd wrote: Yes, but I was asking about the FPC situation. I'm desperately resisting local pressure to write code that might end up non-trivial in C/C++. I realized a project with an ATTiny1634. Nothing special: I used both UARTs (interrupt driven), had to handle a small shaft encoder and had to do a little bit banging on the GPIOs. All together, I used 6 Interrupts. For debugging, I implemented a third "soft-UART", which could send only. At any time, I could switch back to the pascal compiler, which I used over the last 17 years for AVR. But I am not going back, too much advantages on the fpc side to me :-) Thanks for that, encouraging. -- 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] FPC for AVR
On 15/06/17 16:45, Karoly Balogh (Charlie/SGR) wrote: Hi, On Thu, 15 Jun 2017, Mark Morgan Lloyd wrote: At the risk of making myself unpopular: because right now I /don't/ have> time. Sorry, I didn't mean this personal to you. I was just a bit triggered onthe fact that people offer competing products on FPC status requests,because I've seen it more than once that people just ask for the Status ofX, regarding FPC, and when it's not there right now, they just move on tosomething else. And we have to "compete" with a whole range of commercialproducts, where this attitude doesn't help. I agree for what it's worth, and I also find it very frustrating when- in a mailing list specifically for FPC or Lazarus- somebody asks a question about the standard development environment or a standard component and gets the answer that the best way to do it is to use somebody else's pet project. Especially with a project as young and specialized as FPC's AVR backend.>> "Young and specialised"... exactly. Which is why I was interested in any> light that people currently working on AVR could throw on it, since> what's in the Wiki is roughly 9 months old (apart from recently-added> links etc.) and that's a long time for something which people are> actively working on. You are right, of course. I'm only using Arduinos at the moment (potentially including e.g. Teensy), and until I'm far more knowledgeable about remote debugging etc. am inclined to keep it that way :-) -- 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] FPC for AVR
On 15/06/17 11:30, Karoly Balogh (Charlie/SGR) wrote: Hi, On Thu, 15 Jun 2017, Mark Morgan Lloyd wrote: mikroPascal (not free) supports AVR and many other chips.> > https://shop.mikroe.com/compilers/mikropascal/avr-electronic-license> > Brian>> Yes, but I was asking about the FPC situation. I'm desperately resisting> local pressure to write code that might end up non-trivial in C/C++. Well, FPC is an open source project, which means without communityfeedback and contribution, it won't improve, or would, but much slower. :) So if you have time, how about you try if it works for yourusecase/platform/etc, and at least give feedback on it? Even if it didn'twork, if you run into issues you're unable to solve, and share them, itmight be helpful for the developers. And I'm sure some of the issues you'dencounter could be fixed overnight, if the devs would know it's a blockerfor someone's actual usecase. At the risk of making myself unpopular: because right now I /don't/ have time. And part of the reason that my colleagues and I are seriously short of time is that we've put far too much of it over the years into trying to work around problems in various open source projects on various architectures, starting off with Debian on SPARC and heading off in even more arcane directions. And that /does/ include FPC. Especially with a project as young and specialized as FPC's AVR backend. "Young and specialised"... exactly. Which is why I was interested in any light that people currently working on AVR could throw on it, since what's in the Wiki is roughly 9 months old (apart from recently-added links etc.) and that's a long time for something which people are actively working on. -- 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] FPC for AVR
On 15/06/17 11:15, Rainer Stratmann wrote: Am Donnerstag, 15. Juni 2017, 08:34:49 schrieb Mark Morgan Lloyd:> On 14/06/17 20:15, Brian wrote:> > mikroPascal (not free) supports AVR and many other chips.> > https://shop.mikroe.com/compilers/mikropascal/avr-electronic-license> > Brian> > Yes, but I was asking about the FPC situation. I'm desperately resisting> local pressure to write code that might end up non-trivial in C/C++. As far as I know there is not ab FPC solution by now. http://wiki.lazarus.freepascal.org/AVR http://wiki.lazarus.freepascal.org/AVR_Programming -- 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] FPC for AVR
On 14/06/17 20:15, Brian wrote: mikroPascal (not free) supports AVR and many other chips. https://shop.mikroe.com/compilers/mikropascal/avr-electronic-license Brian Yes, but I was asking about the FPC situation. I'm desperately resisting local pressure to write code that might end up non-trivial in C/C++. -- 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] FPC for AVR
What sort of targets are people looking at, what sort of debugging is available, and has anybody experimented with the "AVR Dragon"? -- 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] Large file support
On 02/06/17 11:00, Marco van de Voort wrote:
In our previous episode, Mark Morgan Lloyd said:> > 8 apparently, but off_t is
documented as a cint32.> >
https://www.freepascal.org/docs-html/current/rtl/unixtype/off_t.html
The declaration is
{$if not defined(fs32bit)}off_t= cint64; { used for file sizes
}{$else}off_t= cint;{$endif}
The 64bit is active, IIRC the 32-bit is for use with FPC_USE_LIBC for whenthe
debian oldstable still defined 32-bit as seek (even though even
somewhatrelevant distros already defined 64-bit).
FPC_USE_LIBC for linux and *bsd still is still hardly used afaik.
Maybe we could clean it out. Why the documentation tool picks the $ELSEbranch I
don't know. I grepped, and it didn't seem to find anything in fpdocor (doc/rtl)
makefiles defining it.
Thanks, I'll code defensively.
--
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] Large file support
On 02/06/17 10:00, Marco van de Voort wrote: In our previous episode, Mark Morgan Lloyd said:> Could I have a reality check please: is there no fpLSeek64() for files > larger than 2Gb? Afaik, there is no such posix calls. In the past, most linux temporarily hadsome -64 calls while it left the main calls 32-bit to make transitionsmoother, but nowadays it is all 64-bit? What does writeln(sizeof(off_t)); print ? 8 apparently, but off_t is documented as a cint32. https://www.freepascal.org/docs-html/current/rtl/unixtype/off_t.html -- 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] Large file support
Could I have a reality check please: is there no fpLSeek64() for files larger than 2Gb? -- 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] named parameter
On 29/05/17 05:15, Ryan Joseph wrote: On May 28, 2017, at 5:22 PM, Mark Morgan Lloyd <markmll.fpc-pas...@telemetry.co.uk> wrote:> >> IMO though it does improve readability in long functions with lots of>> parameters, like windows api style procedures that have 5 or more>> parameters and you can't figure out which param is>> which> You mean like this? function Foo (theString: string; options: set of TFoo): boolean;beginend; Foo(theString: 'foo', options: []); Objective-C has this mandatory and it made for stupidly long method names that just looked terrible but it was optional Pascal makes it look nicer. The declaration syntax is already the same as the label for the calling syntax so that seems like a nice fit. Except that there's no provision for setting a parameter passed as a set element to true if it's not given explicitly. Sometimes you want that, and simply inverting the meaning of a parameter results in values which appear contrived in the context of the "real world" problem being solved. The example I gave was from a terminal emulator, where "echo", "loopback" and so on are well-accepted concepts in the industry. And having a parameter "any_character_set_as_long_as_its_not_apl" is downright silly :-) -- 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] named parameter
On 27/05/17 20:30, nore...@z505.com wrote:
IMO though it does improve readability in long functions with lots of
parameters, like windows api style procedures that have 5 or more
parameters and you can't figure out which param is
which
I had an interesting case a couple of years ago where a procedure called
itself recursively, but with a couple of the parameters shifted in
relative position. Messing that up when I added an extra parameter
caused a difficult-to find bug, so I think that some sort of
identify-by-name arrangment (I'm not saying pass-by-name because of its
historical meaning) would be useful.
procedure SendMechCodeToLineASCII(mc: word; bcd, apl: boolean; crlf:
boolean= false;
lf: boolean= false; echo: boolean= false;
loopback: boolean= false);
..
(* CR expansion, local echo etc. Note recursive echo of LF if CR is
expanded, *)
(* this is to keep the VM/CMS "Sixpack" happy since otherwise the first
line of *)
(* output always tries to overwrite the command that instigated it (but
with*)
(* bits of the command showing through non-destructive spaces).
*)
(*
*)
(* Note intentional shift of parameter positions in the recursive call
below. *)
if (mc = Op_CarrierReturn) and crlf then
SendMechCodeToLineASCII(Op_Index, bcd, apl, {crlf :=} loopback,
{lf :=} false,
{echo := } true, {loopback :=}
false);
if echo then
PseudoEventQueue.Enqueue($8000 + canonical(mc))
end
end { SendMechCodeToLineASCII } ;
--
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] named parameter
On 27/05/17 10:20, Ryan Joseph wrote: On May 27, 2017, at 5:13 PM, Mark Morgan Lloyd <markmll.fpc-pas...@telemetry.co.uk> wrote:> > someFunction(TPoint(X:0.0; Y:0.0));> > Pascal purists would probably object to that style, since what it's effectively doing is passing the parameters as an explicit list. I mentioned this form of “default constructor" as a sorely missing feature in FPC a couple weeks ago. Making redundant constructors for records constantly is pretty silly. If I could figure out the compiler code I would add this myself since it’s probably one of the easier things to implement. End of last month actually, I checked :-) I was on the periphery of that discussion, since I thought I needed something similar (but turned out not to). But you might have noticed some of the APLisms that I horrify Sven with on occasion... -- 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] GLM library alternative?
On 27/05/17 09:40, leledumbo via fpc-pascal wrote: Has anyone converted these to Pascal before or having some similar I couldlook at? I don't usually do the matrix calculation myself, I delegate that by callingOpenGL functions in proper order. But working from a hazy recollection of such things, it's possible to merge the translation/rotation matrices so that the final transformation can be reduced to a single operation. -- 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] named parameter
On 27/05/17 09:40, Ryan Joseph wrote: On May 27, 2017, at 4:27 PM, Graeme Geldenhuys <mailingli...@geldenhuys.co.uk> wrote:> > Yeah, that was going to be my suggestion too. I've done this many times when many parameters are optional. Use a record as parameter type. The other benefit of this is that it is future and backwards compatible. You can add or change parameters without breaking the method signature. can you show an example of this? Just curious. IIRC the problem is that while it's possible to initialise a record constant by named fields processed in arbitrary order, the compiler at present doesn't allow it to be done inline: someFunction(TPoint(X:0.0; Y:0.0)); Pascal purists would probably object to that style, since what it's effectively doing is passing the parameters as an explicit list. Somebody please correct me it I'm wrong. -- 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] named parameter
On 27/05/17 08:00, Michael Van Canneyt wrote:
On Sat, 27 May 2017, Mr Bee via fpc-pascal wrote:
Hi,>> As Pascal mostly well known as a safe, easy to read, and elegant
language,> don't you think Pascal needs named parameter? I mean for
ALL kind of> parameters, not just for Variants. When you have a
function with many> parameters having default values, you know that
named parameter is> desirable. For example:>> function f(p1: string =
''; p2: integer = 0; p3: boolean = false);>> But you only need to
supply the third parameter, you still must supply the> first and
second ones with appropriate default values, like this:>> f('', 0,
true);>> while with named parameter, you can do this:>> f(p3 :=
true);>> I believe it would raise Pascal's code readability. I know it
has been> discussed before. I know somehow the parser had been able to
read such> syntax. So, why don't we have the option to enable it for
people who want> it? Kinda a syntax switch mode.>> What do you think? :)
Opinions on what constitutes readable code clearly differ :)
But as far as I know, the parser is not able to read this syntax ?
It would probably be possible to do it by using a record with nullable
fields as the parameter.
Otherwise if you want that sort of thing use Smalltalk :-)
--
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] Ignoring function results
On 20/05/17 12:30, Bart wrote:
On 5/20/17, Mark Morgan Lloyd <markmll.fpc-pas...@telemetry.co.uk> wrote:
According to the Programmer's Guide 1.3.41, {$EXTENDEDSYNTAX OFF} has> the
effect of permitting the result of a function to be ignored.
Isn't that just the other way around?
"Extended syntax allows you to drop the result of a function. Thismeans that you can
use a function call as if it were a procedure.By default this feature is on. You can
switch it off using the {$X-}or {$EXTENDEDSYNTAX OFF}directive."
Just a mo, let me have another shot at that in case I was doing
something stupid...
it's definitely got to be on for optional parameters to be accepted, and
that appears to be the default state if {$mode objfpc}{$H+} is at the
top of the unit.
The curious thing is that in the cold light of day I can't get
$EXTENDEDSYNTAX to have any effect on the function result. I'll admit
what I'm doing:
operator <= (var a: TDateTimeArray; const s: TDateTime): boolean;
begin
result := Length(a) > 0;
SetLength(a, Length(a) + 1);
a[High(a)] := s
end { <= } ;
operator + (const a: TDateTimeArray; const s: TDateTime): TDateTimeArray;
var b: boolean;
begin
result := a;
if Length(result) = 0 then
{ b := } result <= s
else
result[High(result)] += s
end { + } ;
If I uncomment the boolean assignment it works. Where I appeared to be
last night was that setting $EXTENDEDSYNTAX OFF had the above working,
but I'm now having trouble duplicating it. And I hadn't touched a drop :-)
--
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] Ignoring function results
According to the Programmer's Guide 1.3.41, {$EXTENDEDSYNTAX OFF} has
the effect of permitting the result of a function to be ignored.
However it also appears to (at least) prohibit functions/procedures with
optional parameters: can these be controlled separately?
--
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] Vehicle management
On 05/11/2017 09:37 AM, Sven Barth via fpc-pascal wrote:>> Am 11.05.2017 18:14 schrieb "Jon Foster" <jon-li...@jfpossibilities.com > <mailto:jon-li...@jfpossibilities.com>>:> > Anyhow tips on the FPC->C++ front would be appreciated. I will probably > search the list archives as I know this topic comes up repeatedly. I > don't understand how ginormous an undertaking this might be but maybe I > can contribute something on this front.>> I can't speak for other approaches to interface with C++ code, but > patches to the compiler's cppclass support are definitely welcome :D It > will never support everything there is in C++, but if we'd manage to > interface with most library code that would be something... Apologies for bad threading here. Sven, can I just go off on a slight tangent before that part of the discussion adjourns to fpc-devel, since this is a user rather than a developer question. What's the current situation with FPC interface to the Subversion support libraries which I think is something you were looking at at one point? In extremis, I suppose that it should be possible for a program written in FPC to use Lua as a shim when calling C++. -- 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] Vehicle management
On 11/05/17 08:30, Felipe Monteiro de Carvalho wrote: On Thu, May 11, 2017 at 1:19 AM, Jon Foster<jon-li...@jfpossibilities.com> wrote:> Yeah. The wiki is cluttered with inaccurate and abandoned information for> Android development. It needs a serious scrubbing. And access to needed> sources is somewhat hidden. I've combed it for a few years, now, to try and> deduce what's real and what's not. I'm not even sure where I got the bits of> source I'm using now. I've just been clinging to it like a shipwreck> survivor clinging to flotsam. I don't think the wiki page I posted is inaccurate, all the stuffthere is valid AFAIK, but it is simply very incomplete. A lot moreshould be written, and also note that there are 2 different ways: 1> Via NDK combining native Pascal + Java2> Via JVM compiler The wiki I posted is only for approach 1, even a link to a fullcompilable example is posted there (thought it is for OpenGL). I neverused approach 2 and dont plan on using it. Thanks for that, I admit that I found what was on the wiki confusing: it's never clear what's obsolete and what's merely incomplete. So I think that what you're saying is that both approaches are still viable, but you favour the first. For anybody else following this saga, I've now talked to the vehicle and the utility I'm using appears to run at 600 bps, not 800 so I'm probably not going to have to modify serial.pp. But some of the results are a bit odd and the author's had to use a lot of carefully tweaked timings which suggests that something's not quite right... 750 Baud, anybody? :-) -- 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] Vehicle management
On 08/05/17 18:30, Felipe Monteiro de Carvalho wrote: On Sun, May 7, 2017 at 8:33 PM, Mark Morgan Lloyd<markmll.fpc-pas...@telemetry.co.uk> wrote:> Can anybody give me a quick summary of the position of FPC on Android etc.? Works fine like via JNI, you can do most stuff in Pascal using JNI butpart still needs to be in Java. some info here: http://wiki.lazarus.freepascal.org/Android_Programming Thanks Felipe, noted. I rather lost track when therewere (at least) two competing approaches. -- 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] Vehicle management
On 08/05/17 16:00, wkitt...@windstream.net wrote: as it is GPL, source code availability is required... that author has no choice but to supply it... Yes, but it looks as though he's been asked in the past and has claimed that "it needed tidying up": that was a couple of years ago. However we're not at all inclined to let him off the hook, since we take very little pleasure in having to dig out a Windows system to run one poxy program... even if it does save us £1000 at a main dealer. And being able to demonstrate that his VB code could could be made portable without a great deal of work would, I think, be in everybody's interest. -- 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] Vehicle management
On 08/05/17 14:30, Paul Breneman wrote: On 05/08/2017 09:11 AM, Mark Morgan Lloyd wrote:...> It's on the manufacturer-specific pins. The specs are NOT freely> available, and if the description I've seen so far is to be believed the> comms run at 800 bps.> Thanks for the *education* Mark on "manufacturer-specific pins". I just did a little searching and reading. This could turn into a full-time job! See *Bus Systems* here: :) https://teslatap.com/undocumented/ If it were simple we'd have had our suspension fixed two days ago :-) -- 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] Call for testing: array constructors
On 04/05/17 22:30, Sven Barth via fpc-pascal wrote: Hello together! Since revision 36105 FPC now supports the use of array constructorsusing the "[...]" syntax inside ordinary code blocks like Delphi doessince - I think - XE8. And yes, even nested ones are supported (take alook at $fpcdir/tests/test/tarrconstr5.pp for a bit of inspiration). Considering that this changed how "[...]" is handled I'd like you all totest whether your existing code still works (especially if it's dealingwith sets!) and to try this new feature to see if there are any problemsthat our testsuite doesn't cover yet. If you report bugs, then please attach the tag "array constructors". > Operators however would need you to stuff them into a record as only > then you could define generic operators that would work on that > record type. Alse the code of your addition operators differs with > the types so that would not help, at least not as is. Thanks Sven. Am I correct in believing that operators are basically not handled by generics? Apart from that, the operations of getting stuff into arrays etc. appear to work well. -- 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] Vehicle management
On 08/05/17 13:00, Paul Breneman wrote: On 05/08/2017 04:48 AM, Mark Morgan Lloyd wrote:...>> Thanks Graeme (and others, please keep commenting).>> This is something niche, for a specific vehicle (Range Rover P38 EAS> unlock etc.), but could still be a nice little showcase program.>> One odd thing is that the physical interface is apparently via> manufacturer-specific pins on the connector carrying RS232 running at a> non-standard speed. I've not hung a 'scope on the signals yet to verify> that, but if it's correct I'll probably have to modify the Linux> serial.pp unit again.> If it's an OBD connector then the specs should be available. Here is more info: https://en.wikipedia.org/wiki/SAE_J1939 It's on the manufacturer-specific pins. The specs are NOT freely available, and if the description I've seen so far is to be believed the comms run at 800 bps. -- 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] machine readable grammar of object pascal?
On 08/05/17 08:30, Graeme Geldenhuys wrote: On 2017-05-08 04:26, nore...@z505.com wrote:> which is like a variable, but called a const ;-) I'm slowly but surely loosing all hope for Object Pascal. The languageis becoming more and more mangled with every new release ofDelphi and FPC. I'm not sure that it's worse than the alternatives, which either get bogged down in an attempt to be all things to all men (Perl 6 as a particular example) or are showcases for some community's idea of the one true way of programming. Please excuse a quote, edited for conciseness: "Back around September 2007, I was doing some minor but central work on an enormous Google C++ program, one you've all interacted with, and my compilations were taking about 45 minutes on our huge distributed compile cluster. An announcement came around that there was going to be a talk "In the span of an hour at that talk we heard about something like 35 new features that were being planned. "At this point I asked myself a question: Did the C++ committee really believe that was wrong with C++ was that it didn't have enough features?" -- Ken Thompson https://commandcenter.blogspot.co.uk/2012/06/less-is-exponentially-more.html The problem is that those 35+ new features were things that somebody actually wanted or needed, either because it improved functionality or because it improved the rigour with which behaviour could be documented. -- 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] Vehicle management
On 08/05/17 08:30, Graeme Geldenhuys wrote: On 2017-05-07 19:33, Mark Morgan Lloyd wrote:> Can anybody give me a quick summary of the position of FPC on Android > etc.? (Graeme, that includes FPCgui if it's relevant). Referring to small devices... Android support for fpGUI is in the works for some 2-3 weeks now byanother developer. You are welcome to discuss progress with him inthe fpgui.support newsgroup. WinCE support for fpGUI has been working for years. RPi support for fpGUI has been working for years too. Thanks Graeme (and others, please keep commenting). This is something niche, for a specific vehicle (Range Rover P38 EAS unlock etc.), but could still be a nice little showcase program. One odd thing is that the physical interface is apparently via manufacturer-specific pins on the connector carrying RS232 running at a non-standard speed. I've not hung a 'scope on the signals yet to verify that, but if it's correct I'll probably have to modify the Linux serial.pp unit again. -- 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] Vehicle management
Has anybody used FPC to talk to a vehicle via the OBD connector? Can anybody give me a quick summary of the position of FPC on Android etc.? (Graeme, that includes FPCgui if it's relevant). We've been caught short by a vehicle problem that appears to be only fixable by a VB.NET program. However it's GPLed and we're trying to lean on the (reluctant) author for the source, it would be a natural to transcribe to e.g. a tablet or possibly a bratphone. -- 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
