[fpc-pascal] Suppressing ^C signal from stdin
When reading characters from a program's stdin using fpRead(), what's the best way of suppressing ^C so that it doesn't raise SIGTERM or whatever? I want to be able to handle signals indicating e.g. a UPS power-failure message, but not to get trivial stuff from the keyboard. Platform is predominantly Linux, possibly also Solaris and one of the BSDs. Anybody porting the program to Windows will have to do their own dirty work :-) -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Very odd case parsing problem
Sven Barth wrote: On 29.12.2013 18:20, Martin Frb wrote: On 29/12/2013 17:08, Martin Frb wrote: On 29/12/2013 16:37, Sven Barth wrote: Does Lazarus recognize "otherwise" as an alternative for "else" inside a "case"-statement as well? Not yet Now 1.3 does Great! :) Ruefully agrees :-) -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Very odd case parsing problem
Martin Frb wrote:
Drat- a dangling else in a case! I should have spotted that, but
instead spent an hour or so picking at it.
1) If you use Lazarus then you can have case-labels highlighted (e.g add
underline/border, blend foreground by mixing in another color, bold,
...) It is in the color config.
That will (in this case) not highlight the else, so you will know the
else is part of the if.
Thanks, noted.
2) I tried your code and it compiles (2.6.2 win32)
{$mode objfpc}{$H+}
procedure TForm1.FormCreate(Sender: TObject);
var
a: (help, help_, quit_);
b: Integer;
begin
try
case a of
help:begin
end;
help_: begin
end;
quit_: if b = 1 then begin
end
else
end // line 323
finally
end;
end;
There were additional statements in between the else and the final
end. Since the else associated with a case accepts multiple
statements while the else associated with an if doesn't, the
compiler was getting confused by what it thought was a spurious end
statement. I'm sure I've been bitten by this one before, and recently
enough for it to be embarrassing.
I find myself habitually putting in an explicit else part in each
case statement, even if it's empty. That's a habit from Modula-2 days,
I can't remember what the spec said but some (if not all) compilers
insisted on it. In view of the potential for a dangling else, I'm not
sure whether that's a good or a bad habit.
--
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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Very odd case parsing problem
leledumbo wrote:
I can fix that either by putting a semicolon before the else- which I
believe is strictly incorrect
Nope, that's correct. Take a look at the syntax diagram for case statement
here:
http://www.freepascal.org/docs-html/ref/refsu50.html
As you can see, each "case" is terminated by ";". From the parser point of
view, your code is exactly parsed as:
No, that shows a semicolon separating successive cases, not terminating
each one. What's more statement can be a compound statement and
that's similarly defined as using ; as a separator.
Bit of an old chestnut, and my recollection is that an extra semicolon
would crash some versions of Turbo Pascal. I'm not sure where my copy of
J&W is, so I can't go back to the BNF... but it wouldn't help since
else was added to the case statement by Turbo Pascal which explicitly has
case expression of case-element { ; case-element } else
where a case-element ends with a statement which can be a
compound-statement which again defines ; as a separator.
(Oh Lord this is all we need: a syntax war to round off the year.)
--
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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Very odd case parsing problem
Saunders, Rich wrote: On 2013-12-28 15:47, Mark Morgan Lloyd wrote: I can fix that either by putting a semicolon before the else- which I believe is strictly incorrect- or by putting begin/end around that conditional, or by inserting a dummy statement before the else like quit_: if High(lexemeListArray) = 1 then begin end; nop: begin end else The problem is the compiler associates the else with the if..then and not with the case statement. All your fixes break the possible connection between the else and the if..then and that's why they work. Your first fix (to just add a semicolon) would be my preferred one. I have lots of code that is written that way. I'm not sure why you think this is "strictly incorrect". Drat- a dangling else in a case! I should have spotted that, but instead spent an hour or so picking at 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/mailman/listinfo/fpc-pascal
[fpc-pascal] Very odd case parsing problem
I've been wrestling with something for a chunk of the early evening, which is reproducible in situ but not in a cut-down test program. Using 2.6.2 on x86 Linux in objfpc mode, a case statement that looks like this fails to parse: try case parseCommand(selector) of help:begin end; help_: begin end; quit_: if High(lexemeListArray) = 1 then begin end else end // line 323 finally end; As it stands, compilation fails with centralcontrol/distributionanddisplay.pas(323,5) Error: Constant and CASE types do not match centralcontrol/distributionanddisplay.pas(323,5) Error: Constant Expression expected centralcontrol/distributionanddisplay.pas(323,5) Error: duplicate case label centralcontrol/distributionanddisplay.pas(323,5) Fatal: Syntax error, ":" expected but "END" found I can fix that either by putting a semicolon before the else- which I believe is strictly incorrect- or by putting begin/end around that conditional, or by inserting a dummy statement before the else like quit_: if High(lexemeListArray) = 1 then begin end; nop: begin end else I suspect I might have seen this happen before, but it's not an easy one to grep for. Does this make sense to anybody, is it a known (and preferably fixed) issue, or should I be putting time into trying to match the behaviour in a cut-down test program? -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: how to simplify try try except end finally end?
Dennis Poon wrote: For what it's worth, I'm ambivalent. Not because I feel that try stacks couldn't or shouldn't be simplified, but because I feel that whoever overloaded try for two different structures should be shot. I don't know enough about compiler. Could you kindly elaborate on the above please? There are two distinct programming structures, with- as I understand it- significantly different code generation requirements. Both are introduced by the reserved word "try". The first structure, which is broadly comparable with most modern languages, is try .. raise... .. except .. end; with "raise" transferring control to the exception handler. The second structure is try .. finally .. end; and I might be wrong but I don't think there's an analogue of "raise" in this case. In my own scripting stuff I've used start .. stop... .. finally .. end; This obviously doesn't reduce verbosity, but my own opinion is that it improves clarity since you won't in general encounter try try .. and then have to go to the end of the blocks to work out what's intended. In principle it would be possible to define "start" as a macro, but I don't know how badly that would confuse Lazarus/Synedit highlighting and code folding. In practice it's completely incompatible with Delphi (and, as far as I know, every other Pascal variant) so is probably not a habit to get into. -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: how to simplify try try except end finally end?
Reinier Olislagers wrote: On 27/12/2013 10:17, Lukasz Sokol wrote: On 26/12/13 12:13, Reinier Olislagers wrote: On 26/12/2013 13:09, Dennis Poon wrote: Search the archives for proposals for syntax like this that didn't lead to anything. It did lead exactly to Sven Ah yes, you're right that *is* progress :) PS: I like it, too - used to it in .Net, but not too bothered by having to work around it. For what it's worth, I'm ambivalent. Not because I feel that try stacks couldn't or shouldn't be simplified, but because I feel that whoever overloaded try for two different structures should be shot. -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: MD5 decryption?
Reinier Olislagers wrote: Please don't take this as an insult, but make sure you don't design/implement any password/encryption schemes if you don't know what you're doing... Most people who /do/ know what they're doing shouldn't try to design encryption or hashing schemes, although it must be said that most World-class fsckups have resulted from key distribution and storage failures. For the uninitiated, there's interesting info on crypto history and practice on John Savard's website http://www.quadibloc.com/ -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] when will Free Pascal have a stable release of 2.7.2?
Sven Barth wrote: Am 11.12.2013 10:05, schrieb Mark Morgan Lloyd: Bart wrote: 2.7 branch will never be a stable release. Eventually we'll get a 2.8 release. I think that needs to be made to sound more deliberate, for Dennis's benefit. Please could any of the core team jump on me if some detail's wrong, but: You are nearly correct excep: There are some things in trunk which will go into 2.8, others will remain in trunk when it becomes 2.9, others will be removed or left optional for experimentation. 2.7.1 will become 2.8 sooner or later (*) and what's in trunk at that time will also be in 2.8.0 (and normally we don't deliberately remove things... ^^ ). * To be more precise: 2.8 will be branched from 2.7.1 and 2.7.1 will then become 2.9.1. But you do reserve the right to spring surprises on people who use odd-numbered releases incautiously. I've certainly been confused at times. I forget the detail, but IIRC it was something like an ARM fpu variant which was more robust in 2.5.1 despite 2.6.0 having been released... that example might be inaccurate but I'm just trying to emphasise as part of the FAQ that there are pitfalls for somebody who tries to use odd-numbered releases "just because they're the most recent". -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] when will Free Pascal have a stable release of 2.7.2?
Bart wrote: 2.7 branch will never be a stable release. Eventually we'll get a 2.8 release. I think that needs to be made to sound more deliberate, for Dennis's benefit. Please could any of the core team jump on me if some detail's wrong, but: 1.x is obsolete, consideration of whether it's stable or unstable isn't relevant. 2.x.y includes both stable and non-stable releases. The non-stable releases in particular include trunk. Where x is an even number, it's a stable release. So 2.0, 2.2, 2.4 and 2.6 are stable, with 2.8 being the next stable release. Where x is an odd number, it's not a stable release and should not be used for production purposes: specifically, it should not be used for compiling FPC itself or for compiling Lazarus etc. except as directed by developers. The same pattern might or might not be followed by the y digit. I think that trunk is currently 2.7.1. There are some things in trunk which will go into 2.8, others will remain in trunk when it becomes 2.9, others will be removed or left optional for experimentation. There are cases where a developer will tell you to use a particular release (which might have a non-obvious numeric relationship to the current stable version) to get around a code-generation problem, but otherwise except for testing purposes you should stick to the even numbers. This echoes the development practice of the Linux kernel, and is increasingly common practice. -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] cannot read /sys/class/net/eth1/address even as root user on linux
Dennis Poon wrote:
I tried to read the mac address in the captioned file path.
In terminal, I can simply 'cat' and display the mac address.
In FPC, when I tried to use TFileStream to read it,
FS := TFileStream.Create('/sys/class/net/eth1/address',
fmOpenRead+fmShareDenyWrite);
it raised "stream read error"
If I tried to use TextFile and readln, it even halted the program.
My question is:
Why 'cat' command can easily display this special file 'address' but
TFileStream cannot.
I was told to use this method to get the MAC address of a network card,
what other methods are there?
Nothing portable. You can't even use /sys safely without first checking
it's there: the filesystem support might not be compiled into the
kernel, or the filesystem might not be mounted. One possibility would be
looking at /etc/udev/rules.d/z25_persistent-net.rules but again there
are serious portability issues here.
You do actually have an eth1 device on your system, don't you? Most if
not all of the ones around here start off with eth0.
--
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/mailman/listinfo/fpc-pascal
[fpc-pascal] Minimal telnet server
Does anybody have code for an absolutely-minimal telnet server, to sit directly on top of the sockets interface? It will be used for TTY operation rather than anything that requires a modern terminal emulator, the client will probably be from lnet. This is to go into something that's otherwise entirely custom, which is to be translated from source subject to the MIT license (and possibly others: there's 50-year-old commercial code involved). -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] subtract longwords with rollover
Klaus Hartnegg wrote: Hi, How can I subtract two longwords such that when the result becomes negative, it rolls over? A := A - B triggers runtime error 201 when the result is negative. dec (A,B) rolls over, but triggers runtime error 201 when A is higher than the highest possible value of longint. Is dec only declared for longint, but not for longword? dec(longint(A),B) fails when the result is larger than 2 billion. I cannot use longint instead of longword, this causes problems in other parts of the code. What happens if you explicitly disable checking using $Q- $R- Remember that converting $8000 to base10 might be dismal. -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CRITICAL Bug in Lnet DNSLookup failure problem
Dennis Poon wrote: when using lnet to connect to a remote server at DomainName : Port e.g. yahoo.com : 80 in file lCommon.pp line 492: function StrToNetAddr(const IP : String) : Sockets.in_addr;inline; begin result := Sockets.StrToNetAddr(IP); end; The above function did not raise exception when the IP parameter is a null string, which is the return value of a failed DNSlookup of a domain name. You shouldn't be looking up a /domain/ name, you should be looking up a /host/ name. If this fails then you should be looking more closely at the parameter, e.g. it might refer to a host which doesn't exist or it might refer to a local host which needs to be qualified by the local domain name. The consequence is grave! When the DNS lookup fails, it returns a null IP string which the StrToNetAddr converts to the 0.0.0.0 IPv4.sin_Addr structure without raising any exception. If the local computer happens to have a port listening at port 80, it just connects to the port 80 of the local machine whenever the DNS lookup of the target domain fails!!! From past experience, the lnet author non longer responds to the any bug report, I must say that that is not my experience. I've previously raised lnet issues and contributed patches via Mantis, and found the response both prompt and enthusiastic. I am only mentioning this bug here so that other lnet users won't have to find out this bug the hard way (3 days of looking for bug in the wrong places) like I did. The fix is simple, so I will modify the code myself but just hope every new users of lnet can apply this fix before they use lnet. If I understand things correctly, 0.0.0.0 is a reserved network (as distinct from host) address so there is no circumstance in which you should be attempting to connect to it. Your local system (localhost) is normally 127.0.0.1, depending on the subnet mask 0.0.0.0 could be interpreted as "the Class A network" or "the entire Internet". So to summarise, in my opinion at least the 0.0.0.0 is a valid return, and you should be looking more carefully at intermediate values and- in particular- validating parameters fed to the program by the user. -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: GetAffinity\SetAffinity
Brian wrote: "... The critical sections you are using only protect each thread against itself, meaning they basically do nothing. Being inside a critical section is not a guarantee that you won't get preempted, but just that no other threads can enter the same section. ..." The two threads do not share and variables and do not interact with one another. The question is ... as Mark has previously pointed out ... does Linux x86 allow setting hard affinity with threads where the program (process) runs on one CPU core and one or more threads run on another core? But they do share state in the context of the RTL :-/ I think what I'd try is skipping the RTL and going direct to a syscall for the output, since I think threading should be safe at that level. Possibly one of the compiler/RTL team would like to comment. It looks like all the threads must run on the same core as the block diagram at this link seems to imply. https://computing.llnl.gov/linux/slurm/mc_support.html Mark : I found that sometimes coret_fail would run several times correctly , and then when launched on launch N+1 would fail. It may just be luck of the draw that everything was running on one core when it ran correctly. I'm afraid that I'm planning to spend the next few hours, and possibly days, catching up with some long-overdue SPARC and PPC testing- there's some fixed bugs on Mantis that I should have checked and my conscience is catching up with me. -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: GetAffinity\SetAffinity
Brian wrote: Mark ... sorry for the mixup. The program and unit should now be stand alone. The unit links libc (rev6). Regards Brian coret.pas <http://free-pascal-general.1045716.n5.nabble.com/file/n5717549/coret.pas> test_threads.pas <http://free-pascal-general.1045716.n5.nabble.com/file/n5717549/test_threads.pas> Both appear to run OK here, for at least several minutes. Test system is x86, P3x2 with no ht etc., Debian "Squeeze" with standard kernel (2.6.32). -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: GetAffinity\SetAffinity
Brian wrote: Attached is a simple test program with two threads. When the threads run , one displays '+' and the other displays '2'. If both threads run on the same core , the threads work , but if the threads are set to different cores , it generates a GP fault. If anyone is interested , download the code . It was tested on Ubuntu 12.04lts , but should be portable . Would be interested hear any results to confirm it is not a hardware issue on this PC. coret.pas <http://free-pascal-general.1045716.n5.nabble.com/file/n5717544/coret.pas> test_threads.pas <http://free-pascal-general.1045716.n5.nabble.com/file/n5717544/test_threads.pas> The only x86 systems conveniently to hand are multi-CPU rather than multi-core, but I'll happily test that provided you can make it into a standalone program. As it stands coret.pas requires non-standard units, and test_threads.pas isn't standalone. -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: GetAffinity\SetAffinity
Brian wrote: Mark, All the documentation seems to indicate that processes and threads are treated alike in Linux , Remember that historically, there were two different threading models: LinuxThreads, where a thread was implemented as a process, and the newer NPTL. Somewhere I've got code that can test for this: the difference is detectable and different architectures made the transition with significant time separation. My understanding is that ownership of resources, in particular memory, is still a property of processes rather than threads. however , even having established that I can apparently select a core to run a thread , I haven't yet been able to make it work. I explain the findings from a dual core Intel CPU. Using the sched_setaffinity() I can run a program on either core1 or core2 as long as all threads are set to the same core. If the main process (program) is set to core2 and all the threads are set to core2 everything is fine and dandy. However if the main process (program) is set to Core1 and any thread is set to Core2 using pthread_setaffinity_np() , when the Core2 thread starts to run it generates an immediate GP fault. If the API permits, try setting the affinity of the process to both cores, and then adjusting the affinity of the individual threads within this. Never try to move the affinity of a thread outside that of the process that owns its resources. The intent is to be able to run a thread which polls a serial or Ethernet port , rather like one would do with an ISR , but using a separate core for the task , while the main program runs on a different core. Unless you are going directly to the hardware, bear in mind that the actual device access is going to be done by the kernel using interrupts and buffers. So while I can sympathise with wanting to dedicate a core for the "heavy lifting", do you /really/ have to poll the buffers with a tight loop, rather than letting the OS do the job for which it was designed? And are your timing requirements really so stringent that you /have/ to do this? At this point I am not certain if there is something I am missing. At this point I'd be digging into the kernel for my architecture of choice and finding out what the restrictions are. Bearing in mind that it's a long time since I've tinkered with this, but my understanding is that much of it originated inside SGI, where their model was to have a high-speed network between the "chipsets" of a large number of- in effect- separate boxes (I've got /one/ SGI system here with that type of port). With that sort of architecture, you'd want to try to stop processes from moving between boxes gratuitously, and you might, as a separate setting, want to pin individual threads to one processor in each box. I've also got systems comprising multiple boards, where each board has an identical collection of ports, and in that type of architecture you'd want to try to keep a process near to any ports it was servicing (i.e. with suitable interrupt affinity) even if traffic between boards was comparatively efficient. -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: GetAffinity\SetAffinity
Brian wrote: After a bit of research , the issue of setting the cpu affinity has been solved , which may be of use to other folks. A bit of info here concerning the data type cpu_set_t , which as far as I can determine (no help from the mess that is the c library source) is essentially an array of DWORD. For my purposes running on an x86 CPU , allowance for 32 cores is sufficient , using cpu_set_1 as one unsigned long word. http://www.cyberciti.biz/tips/setting-processor-affinity-certain-task-or-process.html Here are some code fragments which may be of help. The function do_SysCall(0) basically doesn't work for setting the CPU core. Although the Linux documentation claims sched_setaffinity() amd sched_getaffinity() work for threads , it only works for processes. pthread_getaffinity_np() and pthread_setaffinity_np() work properly for threads. Thanks for that, interesting. I'd have expected affinity to have been oriented towards processes rather than threads, since I think it largely originated when people started working on NUMA systems- possibly at SGI. There's also interrupt affinity, which becomes significant when (the bus associated with) an I/O device is "nearer" some CPUs than others. I've had hardware of this type in the past, but in those days kernel support for these calls was patchy. -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] optionally uses a unit
Tomas Hajny wrote:
On Mon, November 18, 2013 07:38, Xiangrong Fang wrote:
Hi,
Is it possible to optionally use a unit? e.g.
unit myunit;
uses {$ifexists persist.pas}persist,{$endif} Classes;
type
TMyClass = class
public
{$ifexists persist.pas}
procedure SaveToStream(s: TStream);
{$endif}
end;
Isn't {$IFDEF PERSIST}... combined with calling the compiler with/without
-dPERSIST depending on availability of the source sufficient (and more
general)? Obviously, you can test availability of the source file in a
makefile/shell script/batch file/... and have the -dPERSIST added to
compiler options accordingly.
BTW, your example (and partly the whole concept) might give
unexpected/unwanted results - what if a precompiled version (.ppu/.o) of
that unit is available but not the source file? Which directories should
be checked when searching the file (note that the compiler couldn't know
if the filename mentioned should belong to a unit source file, specific
include file, compiled object, library or even a completely independent
file, and that different search paths are used for searching files of
different types)?
There are definitely hazards, but I think that an exists() predicate of
some form would definitely be useful. For example, inside an {$ifdef
persist} it would give the developers the ability to have a tailored
error message advising the maintainer that if persists.pas didn't exist
he should also get such-and-such a project from local svn, and set up
appropriate symlinks.
The major issue would be directories and search paths.
--
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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] System.FileSize documentation
Tomas Hajny wrote: On Wed, November 6, 2013 10:35, Mark Morgan Lloyd wrote: "Filesize returns the total number of records in file F. It cannot be invoked with a file of type Text. (under linux and unix, this also means that it cannot be invoked on pipes). If F is empty, 0 is returned." It also returns zero if the file is untyped, i.e. hasn't been declared with "of byte" etc. True. Maybe better posted to the bug repository for category Documentation in order to avoid it being forgotten? http://bugs.freepascal.org/view.php?id=25288 Just wanted a second opinion :-) -- 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/mailman/listinfo/fpc-pascal
[fpc-pascal] System.FileSize documentation
"Filesize returns the total number of records in file F. It cannot be invoked with a file of type Text. (under linux and unix, this also means that it cannot be invoked on pipes). If F is empty, 0 is returned." It also returns zero if the file is untyped, i.e. hasn't been declared with "of byte" 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] same routine with different parameters?
waldo kitty wrote: Another useful variant is giving *the* *last* parameter an optional value, which will allow you to omit the parameter: procedure MyObject.MyRoutine(const VarA : string; VarB: integer= -1); very interesting... will this work with both parameters, too? i don't think i need it in this specific situation, though... i'm mainly wanting to provide the original unmodified routine and my modification of it so i can return something to that 3rd party library development... Yes, provided that you don't also try to have a procedure with no parameters. In general, the compiler will tell you if you're doing something silly. Assume that this is for value parameters only. In particular, I don't think there's a way of defaulting a var parameter to a nil pointer. -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] same routine with different parameters?
waldo kitty wrote: question: in simple language, how can i have a routine with differing parameters like some routines in FPC and Lazarus do? i've never attempted this before and it is completely alien to my experience but i do use the functionality quite a lot with existing routines... description: i have a class object with an internal routine that i want to be able to pass no or different parameters to. example: procedure MyObject.MyRoutine; procedure MyObject.MyRoutine(VarA : SomeType); procedure MyObject.MyRoutine(VarA : string; VarB: integer); at one point, the first instance would be used... at another point one of the other instances would be used with the only difference being the parameters that are passed or not... i know that i would have individual instances with the necessary header and code for each... i just don't know if there is anything else special that needs to be done or if it can be done with an internal class object routine.. Just give it a whirl as you've shown, I think you've got it right. Another useful variant is giving *the* *last* parameter an optional value, which will allow you to omit the parameter: procedure MyObject.MyRoutine(const VarA : string; VarB: integer= -1); -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to detect if my program is running with root/elevated privileges?
Bart wrote:
On 10/28/13, Mark Morgan Lloyd wrote:
For windows there is winutils.iswindowsadmin(), for unix likes there is
fpgeteuid (which should return zero for root).
Also remember unix-style capabilities.
Care to elaborate on that?
You can use the setcap utility to add or remove capabilities to a
binary. I can't remember how they're stored, or why this is considered
even adequately secure. The capabilities library (e.g. libcap.so, don't
confuse this with a file from Mozilla of the same name) can be used by a
program to add capabilities to itself, provided that it starts off as
uid root. Note that gtk2 does not allow a program to be setuid root.
Below cut-and-pasted from my notes from when I was last looking at this,
sorry about the poor format. I've translated the appropriate header file
and hacked together a shim for the .so, usual cautions about making sure
it actually exists.
(* This requires that the program be running with sufficient
capabilities to be *)
(* able to bind to ports < 1024, however immediately after this is done
it goes *)
(* to a lot of trouble to relinquish as many privileges as possible.
*)
(*
*)
(* * If linked with gtk2, it is not possible to run setuid root but
explicit *)
(* capabilities may be added during installation:
*)
(*
*)
(* # setcap CAP_NET_BIND_SERVICE=p+e *gtk2
*)
Final parameter is the name of the program just compiled, which in my
case has widget set etc. appended.
(*
*)
(* Note that capabilities are stored as extended attributes, which
DO NOT *)
(* normally accompany a file if it is subsequently copied.
*)
(*
*)
(* * If linked with Qt, the program may be run setuid root:
*)
(*
*)
(* # chown root:root *qt
*)
(* # chmod u+s *qt
*)
(* # chmod g+s *qt
*)
(*
*)
(* or have extra capabilities as above.
*)
(*
*)
(* * In any case, the program may be started by the superuser (i.e.
run as *)
(* root).
*)
..in which case it does the usual unix thing of grabbing whatever
resources it needs, then switching to a safer UID so that if somebody
finds a way of forcing it to shell out it doesn't give them unrestricted
access to the system.
(*
*)
(* After the ports have been bound, the CAP_NET_BIND_SERVICE effective
and *)
(* permitted capabilities are relinquished. If the program is running
setuid*)
(* root, then it reverts to the actual user; if it is running as root it
*)
(* assumes group and user IDs as given in the configuration file, or as
given *)
(* by the ownership of the executable, or ID 65534 as ultimate fallback
*)
(* ("nobody" in recent Debian releases). MarkMLl.
*)
--
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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to detect if my program is running with root/elevated privileges?
Bart wrote: On 10/27/13, Marco van de Voort wrote: For windows there is winutils.iswindowsadmin(), for unix likes there is fpgeteuid (which should return zero for root). Thanks a lot. Also remember unix-style capabilities. -- 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/mailman/listinfo/fpc-pascal
[fpc-pascal] Sparse files and and copy-on-write filesystems
Does FPC have any support these days for creating and accessing sparse files, in particular on Linux? I'm considering a file containing a 2Gb fixed-size filesystem, with one or more sparse files logging updates. Obviously I could use something like Qemu's qcow format, but initially at least I think I'd prefer to be able to use raw files. -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fcl-process, SimpleIPC and pipes
Juha Manninen wrote: I must implement communication between 2 processes. I believe SimpleIPC is good for that purpose and it is well tested in a cross-platform system (Lazarus <-> ChmHelp). Named pipes were suggested to me. I would like to know the benefits / handicaps of SimpleIPC compared to named pipes. I will have to answer such questions myself soon. fcl-process also has pipes unit and then "pipesipc" which apparently does not use pipes. (?) The semantics of names pipes varies across different OSes. I've used the unix equivalent on Linux for the specific reason that I wanted to explore issues of naming etc., but porting to Windows turned out to be problematic despite my having used the MS/IBM variant in the past. Use SimpleIPC unless you have an informed reason not 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] [OT] sealed?
Sven Barth wrote: On 07.10.2013 19:29, silvioprog wrote: Hello, I was surfing the internet and came across this structure Delphi: TJSONPair= class sealed(TJSONAncestor) So, what is this? Simple: You are not allowed to create child classes of sealed classes (the compiler enforces this). FPC supports this since 2.4.2. Does it prevent the creation of class helpers? -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Getting the state of a TRTLCriticalSection
Jonas Maebe wrote: On 07 Oct 2013, at 11:33, Marco van de Voort wrote: In our previous episode, Jonas Maebe said: [interlocked increment/decrement] They do not include any memory barrier. The only thing those routines guarantee on all platforms, is that the value is atomically incremented/decremented. (btw that depends on which functions you mean, our own assembler versions probably. The Windows functions of the same name are guaranteed to have memory barriers afaik, but do require alignment. (probably to avoid crosssing cache lines) ) That's why I wrote "on all platforms". They also always require a native alignment on all platforms, because those are cpu limitations for atomic instructions. On 07 Oct 2013, at 11:40, Mark Morgan Lloyd wrote: Thanks Jonas, noted. For completeness, is there a way to force one? See http://www.freepascal.org/docs-html/rtl/system/readwritebarrier.html and the pages linked from there. Thanks for that, I mistakenly thought that the code generator was inserting implicit membars but I see from my notes relating to bug 23390 that it's an RTL (>2.2.2) detail. -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Getting the state of a TRTLCriticalSection
Jonas Maebe wrote: On 07 Oct 2013, at 09:14, Mark Morgan Lloyd wrote: Benito van der Zander wrote: In the end I stuck in code to increment/decrement a counter, and looked for it to be explicitly 0 or 1. Do you need to put a memory barrier around that, or does the critical section take care of that? I used the interlocked increment/decrement, which- as I understand it- should handle membar itself on architectures that can benefit from it. They do not include any memory barrier. The only thing those routines guarantee on all platforms, is that the value is atomically incremented/decremented. Thanks Jonas, noted. For completeness, is there a way to force 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Getting the state of a TRTLCriticalSection
Benito van der Zander wrote: In the end I stuck in code to increment/decrement a counter, and looked for it to be explicitly 0 or 1. Do you need to put a memory barrier around that, or does the critical section take care of that? I used the interlocked increment/decrement, which- as I understand it- should handle membar itself on architectures that can benefit from 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Getting the state of a TRTLCriticalSection
Michael Van Canneyt wrote: On Sun, 6 Oct 2013, Mark Morgan Lloyd wrote: Is there a preferred way of reading back whether something (including the current thread) has already entered a TCriticalSection? To my knowlede this does not exist. The Microsoft implementation of a critical section has TryEnterCriticalSection, but I do not know how portable or useful that is. I think that one's generally available, but it looks as though it does the same as TCriticalSection.TryEnter. In the end I stuck in code to increment/decrement a counter, and looked for it to be explicitly 0 or 1. -- 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/mailman/listinfo/fpc-pascal
[fpc-pascal] Getting the state of a TRTLCriticalSection
Is there a preferred way of reading back whether something (including
the current thread) has already entered a TCriticalSection?
I'm trying to put assertions in code that, partly under non-GUI thread
control via Synchronize, adds and deletes pages to a TPageControl. If I
do this
property BloodyGreatLock: boolean read GetBGL write SetBGL;
..
fBGL: TCriticalSection;
..
function GetBGL: boolean;
var gotLock: boolean;
begin
try
gotLock := fBGL.TryEnter
finally
if gotLock then
fBGL.Leave
end;
result := not gotLock
end { GetBGL } ;
then this initialisation code and test sequence
initialization
fBGL := TCriticalSection.Create;
Assert(BloodyGreatLock = false); (* Check lock read works properly *)
Assert(BloodyGreatLock = false);
BloodyGreatLock := true;
Assert(BloodyGreatLock = true); <= FAILURE HERE
Assert(BloodyGreatLock = true);
fails where indicated since the lock is owned by the current thread so
TryEnter has succeeded.
--
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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Socket error messages
How does one convert from the numeric value returned by SocketError to the name of the error (specifically, to e.g. EsockEINVAL rather than EsysEINVAL, i.e. to be in line with the definition of functions like fpbind)? > use the errors unit. (specific for unix) > > It has a functiun strerror() But aren't those EsysEINVAL rather than EsockEINVAL etc.? I notice that the example for fpconnect at http://lazarus-ccr.sourceforge.net/docs/rtl/sockets/fpconnect.html actually describes a variant of Connect that's not documented for fpconnect. -- 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/mailman/listinfo/fpc-pascal
[fpc-pascal] Socket error messages
How does one convert from the numeric value returned by SocketError to the name of the error (specifically, to e.g. EsockEINVAL rather than EsysEINVAL, i.e. to be in line with the definition of functions like fpbind)? I notice that the example for fpconnect at http://lazarus-ccr.sourceforge.net/docs/rtl/sockets/fpconnect.html actually describes a variant of Connect that's not documented for fpconnect. -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
Michael Schnell wrote: On 09/12/2013 12:47 PM, Mark Morgan Lloyd wrote: I've concluded that using a thread is, in fact, preferable True. It's a pity that Synapse and friend (especially SynaSer) does does not implement internal threads that throw appropriate events in the Main Thread when something comes in (or an error appears). This is a very common request, and since the fpc-Team some time ago enabled TThread.Queue in the RTL, this is doable in a straight forward, "fpc-ish" way (portable but Delphi compatible). Although for certain types of usage being able to get directly to the hardware (or strictly, to the lowest level the OS supports for normal users) is absolutely essential, e.g. if timing information has to be appended to each character or if records of control signal changes have to be inserted. -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
Mark Morgan Lloyd wrote: Michael Schnell wrote: On 09/11/2013 07:22 PM, Mark Morgan Lloyd wrote: I'd normally use a thread for this, but I've already got lnet's telnet client running in the program so would rather stick to the same library if possible. AFAIK, Lnet does not do threading internally (as does AsyncPro or - partly - Indy), so if you need to wait for TCP input while doing other things in your program, you need to do your own thread, anyway. [Nod] Works adequately for a telnet-based terminal though. I switched from Lnet to Synapse lately, as same seems to a lot of provide usable protocols. Synapse does not provide internal threads, either. True. Synapse's protocol support is second to none, but in the current case there's really no protocol involved- grab/store data and that's it. If I understand from more Googling etc., lnet server support works by the program first setting up a server socket and applying Listen, then setting up a connection socket and calling Accept() with the server socket (possibly the server socket's handle, and I'm unsure how to get this) as parameter. Both of these would need CallAction calls on a regular basis. I've concluded that using a thread is, in fact, preferable since I don't know how much data will arrive from the far end, how it will be paced, and whether the far end might attempt multiple simultaneous connections. While a polling scheme is OK for the foreground terminal stuff there's too much change that its proliferation will mess up either foreground or background transfer. -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
Michael Schnell wrote: On 09/11/2013 07:22 PM, Mark Morgan Lloyd wrote: I'd normally use a thread for this, but I've already got lnet's telnet client running in the program so would rather stick to the same library if possible. AFAIK, Lnet does not do threading internally (as does AsyncPro or - partly - Indy), so if you need to wait for TCP input while doing other things in your program, you need to do your own thread, anyway. [Nod] Works adequately for a telnet-based terminal though. I switched from Lnet to Synapse lately, as same seems to a lot of provide usable protocols. Synapse does not provide internal threads, either. True. Synapse's protocol support is second to none, but in the current case there's really no protocol involved- grab/store data and that's 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/mailman/listinfo/fpc-pascal
[fpc-pascal] lnet for TCP daemon
Is it feasible to use lnet for a simple TCP daemon on Linux, i.e. wait for a connection on a predefined port, read as much data as is available, repeat? And if so, what does the SerSock parameter to Accept() represent? I'd normally use a thread for this, but I've already got lnet's telnet client running in the program so would rather stick to the same library 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Breaking Pascal source lines
Howard Page-Clark wrote: On 06/09/2013 14:10, Mark Morgan Lloyd wrote: I'm sure there isn't a single "right" answer to this question, but if transferring Pascal source to a system that enforces short lines (e.g. 78 chars + CRLF) what's the best automatic breaking rule? One possibility is obviously to break after the rightmost space, but is it valid to break after e.g. . (if not followed by a digit), ^ and possibly others? Syntax errors are acceptable. Truncation isn't. Is it valid...? Yes. The compiler largely ignores line endings and line breaks (since they're inserted mainly for formatting, not syntax purposes). One exception is string constants, so your parser will have to track the "'" character and ensure a corresponding later match within the short line, or else insert a forced concatenation. The code Also single-line comments are obviously broken by wrap, i.e. preceded by // I can cope without trying to parse for strings etc., since I think that in all cases compiling a broken string would result in a syntax error. -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Breaking Pascal source lines
Bernd Oppolzer wrote: Am 06.09.2013 18:16, schrieb Bernd Oppolzer: To keep the syntax correct, you can break after every symbol, that is: not inside identifiers, not inside numbers (including floating point constants) not inside quoted strings but anywhere else I am using a Pascal pretty print program, that knows about the syntax (a little) and outputs the source in lines of 72 chars at most - this limit can be modified via parameter, IIRC. But: at the moment it accepts only classical Pascal syntax (my extension of Stanford P4) - no FPC. So it makes not much sense to share it. But I compiled it with FPC recently, and it ran without problems on Windows. Kind regards Bernd it's not quite correct; if there are symbols like := that consist of more than one char, you must not break in the middle. In particular things like += which might not be expected by people used to other dialects. -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Breaking Pascal source lines
leledumbo wrote: Use JEDI Code Formatter with max line length 78 and let the magic works... Worth remembering, thanks :-) -- 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/mailman/listinfo/fpc-pascal
[fpc-pascal] Breaking Pascal source lines
I'm sure there isn't a single "right" answer to this question, but if transferring Pascal source to a system that enforces short lines (e.g. 78 chars + CRLF) what's the best automatic breaking rule? One possibility is obviously to break after the rightmost space, but is it valid to break after e.g. . (if not followed by a digit), ^ and possibly others? Syntax errors are acceptable. Truncation isn't. -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to clear the value of a field in a table using parameters?
Michael Van Canneyt wrote: Not everywhere. In Oracle empty strings are Null (which is why we have special code for this situation in our business application). That's a deviation from the standard. NULL means "we don't know", empty means "we know it is empty" Actually, it means "we don't know and won't be told" since null or true -> null and so on. A bit like some political movements, frankly :-) -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compilation Error At revision 25270.
Eric Kom wrote: svn up make clean export PP=/usr/local/lib/fpc/2.7.1/ppc386 make OVERRIDEVERSIONCHECK=1 NOGDB=1 OPT='-O- -gl -Xs-' all pp.pas(248) Warning: Implicit uses of Variants unit pp.pas(247,1) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted make[4]: *** [ppc386] Error 1 make[4]: Leaving directory `/home/erickom/fpcBuild/fpc/compiler' make[3]: *** [wpocycle] Error 2 make[3]: Leaving directory `/home/erickom/fpcBuild/fpc/compiler' make[2]: *** [cycle] Error 2 make[2]: Leaving directory `/home/erickom/fpcBuild/fpc/compiler' make[1]: *** [compiler_cycle] Error 2 make[1]: Leaving directory `/home/erickom/fpcBuild/fpc' make: *** [build-stamp.i386-linux] Error 2 erickom@cloudOne:~/fpcBuild/fpc$ svn up Updating '.': At revision 25270. Try again, I think it's fixed at 25271. As a general point, you'd make it far easier for everybody- including yourself- if you used the stable compiler (2.6.2) as your starting point. Also, if you want to know what revision you're at then use svn info rather than svn up. -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] User-defined operators and dummy parameters
Sven Barth wrote: On 10.08.2013 12:04, Mark Morgan Lloyd wrote: Is it possible to pass a dummy parameter to a user-defined operator, with no expectation that it be referenced? The following test program compiles OK but fails at runtime with an error 217 on all platforms if the record is empty. It works if it contains a variant, but not reliably with other types. It seems that the compiler does not detect here that the variants unit is needed and thus does not impolitely add it. Please open a bug report with your code as an example. As a workaround simply add the unit "variants" to the unit where your operator is defined. http://bugs.freepascal.org/view.php?id=24863 The reason I revisited this was after we were looking at apparent zero-size record problems elsewhere. Btw: You don't need the "s: Variant" for operators in mode Delphi or mode ObjFPC as there you can use "Result" as usual (just write ": Variant" as for normal functions). Noted, my "eye was off the ball" while I was struggling with various errors in a test program somewhat larger than I've submitted (working up to 3-D arrays 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: User-defined operators and dummy parameters
leledumbo wrote: works if I change the operator header to: operator + (const r: r_; const a: t1) s: integer; from gdb bt, the problem seems to be assignment from shortint to variant: #0 0x in ?? () #1 0x08057205 in SYSTEM_$$_assign$SHORTINT$$VARIANT () #2 0x0806bf94 in U_$SYSTEM_$$_OUTPUT () #3 0x0804816f in plus (R=..., A=0xb7ff7068) at x.pas:30 #4 0x080482ef in main () at x.pas:47 [Digs] Thanks, you're right :-) Also, if the array elements are variants then there's no error. So in other words, it might turn out to be safer to have separate operators returning integer, double and so on. I appreciate that I'm abusing the language here, but /should/ the original implicit conversion have worked? Doesn't work without tuple support a1 := t1.create(1,2,3,4,5); Noted. What happens in this case if a1 := t1.create(1,2,3,4,5); .. a1 := t1.create(6,7,8,9); Does there have to be an explicit destroy or similar? -- 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/mailman/listinfo/fpc-pascal
[fpc-pascal] User-defined operators and dummy parameters
Is it possible to pass a dummy parameter to a user-defined operator,
with no expectation that it be referenced?
The following test program compiles OK but fails at runtime with an
error 217 on all platforms if the record is empty. It works if it
contains a variant, but not reliably with other types.
program test;
{$mode objfpc}{$H+}
typet1= array of integer;
r_= record
// x: variant
end;
var a1: t1;
reduce: r_ = ();
procedure print(const a: t1);
var i: integer;
begin
for i := Low(a) to High(a) do
Write(a[i], ' ');
WriteLn
end { print } ;
operator + (const r: r_; const a: t1) s: variant;
var i: integer;
begin
s := 0;
for i := Low(a) to High(a) do
s += a[i]
end { + } ;
begin
// a1 := t1([1,2,3,4,5]); Doesn't work without tuple support
SetLength(a1, 5);
a1[0] := 1;
a1[1] := 2;
a1[2] := 3;
a1[3] := 4;
a1[4] := 5;
WriteLn('a1:');
print(a1);
WriteLn('+/ a1:');
WriteLn(reduce + a1);
WriteLn
end.
This is of no particular importance, I'm just exploring capabilities.
--
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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Automatically exporting C++ API using SWIG??
Sven Barth wrote: We have three windows platforms with MSVC and I don't know how many platforms where GCC or LLVM is the main compiler. I'm not going for popularity here, just for the majority of platforms. Looking at the options 1 use swig architecture to parse the C++ source code/headers and extract Pascal bindings - either by a rewrite or adapting the current effort 2 accommodate (and maintain) various compiler idiosyncracies from a distance... I'd say option 1 would be the easiest and best maintainable? - SWIG already provides infrastructure to parse the source files - People using Delphi would probably also be interested in fixing/patching bugs - On top of the previous point: changes in C/C++ standards/formats would not be our concern so much because those will be dealt with by the wider SWIG community - Of course, if swig is ever extended to support more languages, we get that for free Of course I understand it's very attractive to have everything in house and native in FPC, but I suspect the effort needed to develop/maintain it may outweigh that... Important point for variant 2: less overhead. Using swig you first flatten the API and then unflatten it again into Object Pascal classes. For callbacks you have also wrappers (which are hidden from you). In case of cppclass you don't have all this, because code will be called directly. However, I'm reminded of the flurry of activity when SCADA malware was found in the wild a couple of years ago: it was decided fairly early that it had probably been compiled with MS tools, but inspection of the calling convention suggested that it was non-standard and it took a lot of head scratching before people decided which compiler/linker and what pragmata had been used. -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] RE: FPIDE 1.0.6
Marco van de Voort wrote: In our previous episode, Sven Barth said: IDE shows 44 bug records. Not all of these are real bugs, because there are also feature requests, etc., and not all bugs might be selected this way due to incomplete or incorrect input provided by the original bug reporter, but it gives you some indication at least. Also some bugs might not have been reported because of a smaller user base and thus smaller test coverage... And, a release that was the "latest" release for a much longer period of course has a higher chance of bugs begin detected. And IIRC 1.0.10 was one of the longest running releases. I'm still bothered, particularly now that the subject line is "FPIDE 1.0.6". I think that it would be interesting to know *exactly* what the OP is doing to get that version number, and *exactly* how that version number is reported. In particular, is he looking at something comparable with this: FreePascal IDE for Linux for i386 Target CPU: i386 Version 1.0.12 2012/11/14 -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ++ and --
Tomas Hajny wrote: On Tue, July 30, 2013 17:03, Timothy Groves wrote: FPC offers the +=, -=, etc., statements swiped from C. Is there any reason why ++ and -- are not similarly supported? I know that we have inc() and dec(), but I'd say that ++ and -- are easier to type. General side note with no intention to start discussion about superiority of one language to another: A lot of C constructs is easier to type than their Pascal equivalents but not necessarily even equally easy to read. Seconded. Now specifically to your question - I believe that one of the reasons may be the fact that Pascal does not support unary arithmetic operators in postfix notation. The fact that C allows using them with both prefix and postfix notation makes them even more difficult from my point of view because potentially allowing them only in one of the notations known from other languages would immediately trigger users to ask why only one of possible notations (common elsewhere) is supported and the other not. I've got a vague recollection that some of the ++ and -- semantics are particularly unpleasant, and that one of the C inventors did his best to disown them. At least += etc. are fairly unambiguous: they're almost macro expansions and as such they don't mandate any extra overloadable operators 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] what is the FPC equivalent of Delphi's zlib unit?
Michael Van Canneyt wrote: There are 3 options: paszlib.pas pascal implementation of libz. zstream.pp stream interface, uses paszlib. zlib.pp native interface to C libz library. Is any one of those more "natural" than the rest, because e.g. it's already used for GIF handling? -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] RE: FPIDE 1.0.6
Pierre Free Pascal wrote: The version of the IDE is different from the compiler version. Could you please tell us the compiler version? It can be found in "Help|About" menu entry. Even compiler version 2.4.0 already has IDE version 1.0.12... Thus I suspect that 1.0.6 corresponds to a really old compiler. It will be difficult to get feedback on outdate releases... /If/ that's the case, then he's got FPC 2.0.2. -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Cross compiling Windows to arm-linux
John Hansen wrote: lcd_test.dpr: warning: 31: "crti.o" not found, this will probably cause a linking failure lcd_test.dpr: warning: 31: "crtbegin.o" not found, this will probably cause a linking failure lcd_test.dpr: warning: 31: "crtend.o" not found, this will probably cause a linking failure lcd_test.dpr: warning: 31: "crtn.o" not found, this will probably cause a linking failure D:\FPC\2.7.1\units\arm-linux\rtl\cprt0.o: In function `_haltproc_eabi': (.text+0x88): undefined reference to `_fini' D:\FPC\2.7.1\units\arm-linux\rtl\cprt0.o: In function `_haltproc_eabi': (.text+0x90): undefined reference to `_init' Does anyone have any idea what is going wrong and how to fix this problem? It sounds like it might be that I need to have the order that it tries to link the files and libraries modified so that it links the C runtime .o files after my own code or something like that. But how do I accomplish that feat? This is a placeholder pending somebody more experienced commenting. A number of people have reported similar problems over the last few months, e.g. http://comments.gmane.org/gmane.comp.compilers.free-pascal.general/32106 -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Automatically exporting C++ API using SWIG??
Reinier Olislagers wrote: On 19/06/2012 09:51, Reinier Olislagers wrote: The recent thread about using C headers made me think about using C++ projects. Found that the SWIG tool converts C/C++ .h files into glue code and bindings for e.g. Python, Modula 3... but not Delphi/Object Pascal. It seems you get an object-oriented binding. FYI, created wiki page http://wiki.lazarus.freepascal.org/SWIG to bundle information. Thanks for that. I was looking at an interesting article yesterday on developing for the Pebble smartwatch, and wondering whether the people who write the APIs for that sort of device will without thinking use techniques that FPC would have difficulty accommodating. http://www.theregister.co.uk/2013/07/18/how_to_write_apps_for_the_pebble_smartwatch/ -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Wiki licensing
Reinier Olislagers wrote: Hi FPC & Lazarus lists, The current wiki page has this in the footer: "Content is available under ." While on the subject of Wikis, perhaps somebody would update http://en.wikipedia.org/wiki/Free_Pascal#Targets to include MIPS and 68K, and remove PPC Mac OS Classic which no longer builds. -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: (OT) Re: How to use UART of ARM platforms (e.g. Raspberry Pi ) through free Pascal?
Luca Olivetti wrote: Al 04/07/13 17:24, En/na Mark Morgan Lloyd ha escrit: In any event, my experience is that USB->serial converters are very poor for anything that involves accurate timing, and I suspect that controlling a 485 transceiver in conjunction with one would be problematic. Not if the converter manages the rx/tx switching all by itself I think I asked FTDI about this a couple of years ago, and was told that their hardware had facilities that would help but exploiting them would take a non-standard driver. The ones I used worked with the standard driver: send something, it automatically enables the transmitter, after the last bit has been transmitted it goes in high impedance mode ready for listening/receiving. Yes, but I was considering the case of using an off-the-shelf USB->RS232 device, followed by an RS232->RS485 converter (OP's note of this morning). A couple of years ago I was reverse-engineering the protocol used by some HP protocol analysers (so that I could use them for reverse-engineering protocols...) and my initial hack used a couple of standard USB devices. Unless I slowed the data stream right down (300 Baud) the driver buffering messed things up to the extent that I couldn't determine where there were gaps, let alone measure them so I could work out what the timeouts 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: (OT) Re: How to use UART of ARM platforms (e.g. Raspberry Pi ) through free Pascal?
Lukasz Sokol wrote: On 04/07/2013 12:03, Michael Schnell wrote: On 07/04/2013 12:52 PM, Lukasz Sokol wrote: For RS485 adaptation, use a MAX232 like chip (to convert +-12 to ttl) and then a RS485 transceiver chip; If you want to create hardware anyway, better use a PIC24 (pr PIC32) chip with USB plus a RS485 tranceiver chip. So you get rid of the " ATEN usb-to-serial cable (UC-232A)" and you have both sides of USB under your control so that you can do the USB procedure you want. +1 if OP wants to create his own hw and sw for that purpose Another way is using a pre-programmed PIC chip available by Microchip with USB to-Serial software plus a RS485 tranceiver chip. +1 if OP wants to use standard hw... Discussion elsewhere suggests that the RPi has an internal 16550 port, and controlling the 485 signals using e.g. CTS might be viable. In any event, my experience is that USB->serial converters are very poor for anything that involves accurate timing, and I suspect that controlling a 485 transceiver in conjunction with one would be problematic. I think I asked FTDI about this a couple of years ago, and was told that their hardware had facilities that would help but exploiting them would take a non-standard driver. -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: It is possible to pass command line to pascal
Johan, READ THE ENTIRE MESSAGE THAT YOU ARE QUOTING. You might be used to top-posting, but the convention on this ML is bottom-quoting and those links aren't just bits of somebody's sig, they contain the answer to your question. Johan Tu Toit wrote: Hi all, thanks for your help, I am happy to know about fpuname function from the baseunix unit. the fpSystem function from unix unit also helpfull but only return an integer. I am still looking on how to get a result as a string not a integer only You may also use a TProcess object: http://www.freepascal.org/docs-html/fcl/process/tprocess.html Here you have a tutorial with some examples: http://wiki.lazarus.freepascal.org/Executing_External_Programs#TProcess Apologies to everybody else for top-quoting and "shouting", but I think there's a possibility that the OP's missed the message due to unfamiliarity with the medium. -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] It is possible to pass command line to pascal
Rainer Stratmann wrote: On Sunday 30 June 2013 12:32:30 you wrote: Rainer Stratmann wrote: On Sunday 30 June 2013 00:59:59 you wrote: I Tried, but only return an integer not a string value. Thats right. You have to put the result in a file and then afterwards read the file. ls uname -r > file.txt I'm sorry, but that's misleading on at least two accounts. The first is that redirection (> and so on) is a property of the shell, so it won't work unless you pass the entire command to a shell with (typically) the -c option. The second is that as linked by leledumbo earlier http://wiki.lazarus.freepascal.org/Executing_External_Programs there are specific facilities in the runtimes to do this sort of thing and they don't, as a rule, involve temporary files. If I had to go on, what's that -r supposed to be doing? It is not too difficult to find out. If you speed up your engine then you can find out that he wants to know the actual Linux kernel number. 'uname -r' In which case why is he putting ls in front of it? -r is a valid option to both uname and ls, so since we're already looking at a broken command it's entirely valid to ask which it's supposed to apply to. With 'uname -r > file.txt' you redirect the output in a file. Then cou can read the file. I am sorry, but you try to make a very simple thing complicated. You might call having to invoke a shell with the -c option to get the redirection working, working out where to put the temporary file, deleting it on completion and making sure that all error conditions are handled "simple". I certainly don't. But as Marco has already reminded us, the information is already available from a standard library call. Calling an external program is not something to be approached for a trivial reason, unless you're writing shell or in a scripting language such as Perl where it might be less trouble than searching CPAN for the appropriate extension module. -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] It is possible to pass command line to pascal
Rainer Stratmann wrote: On Sunday 30 June 2013 00:59:59 you wrote: I Tried, but only return an integer not a string value. Thats right. You have to put the result in a file and then afterwards read the file. ls uname -r > file.txt I'm sorry, but that's misleading on at least two accounts. The first is that redirection (> and so on) is a property of the shell, so it won't work unless you pass the entire command to a shell with (typically) the -c option. The second is that as linked by leledumbo earlier http://wiki.lazarus.freepascal.org/Executing_External_Programs there are specific facilities in the runtimes to do this sort of thing and they don't, as a rule, involve temporary files. If I had to go on, what's that -r supposed to be doing? Are you trying to execute uname -r and in that case where does the ls come into it? Perhaps what you're really trying to do is something like ls /boot/vmlinux-`uname -r` (note those backticks which are NOT standard quotes) in which case you'd be better first getting the uname output and then using standard file operations to get the properties you're interested in. Finally, Linux (but not necessarily other unix implementations) puts version information into /proc/version which is accessible as a standard file- no external program required. -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] is there a ready to use FPC Cross compiler x86-Linux -> MIPS-linux?
Sven Barth wrote: On 15.06.2013 19:19, Dennis Poon wrote: I eventually found this page which talked about downloading a special toolchain from openwrt web site http://www.dd-wrt.com/phpBB2/viewtopic.php?t=61112 I followed its instruction and successfully compiled a helloworld c program and successfully RUN the helloworld binary on Netgear 3700 running DD-Wrt ! I was overjoyed. Then I tried to modify the steps to compile fpc my toolchains is at /home/dennis/toolchains/staging_dir_mips/bin/ and in this folder, there are files: mips-linux-ar and mips-linux-as so I make clean all CPU_TARGET=mips OS_TARGET=linux BINUTILSPREFIX=/home/dennis/toolchains/staging_dir_mips/bin/mips-linux- It seems not to be your problem, but your arguments are not entirely correct (and it "works" just by accident). BINUTILSPREFIX is *only* the prefix of the binaries, in your case "mips-linux-". The path must be passed as CROSSBINDIR like so: CROSSBINDIR=/home/dennis/toolchains/staging_dir_mips/bin And did you choose the correct endianess? Aka CPU_TARGET=mipsel or CPU_TARGET=mipseb? Maybe you could try to fiddle around with the arguments passed to mips-linux-as by hand. This means take the command below and try to get the prt0.as file to assemble: /home/dennis/toolchains/staging_dir_mips/bin/mips-linux-as -32 -mips32 -EB -o /home/dennis/fpc/2.7.1/rtl/units/mips-linux/prt0.o mips/prt0.as (current directory should be /home/dennis/fpc/2.7.1/rtl/linux ) That's probably a uClibc toolchain, one of the known issues is that it has to load the right .so file on the target. The big question is whether it also implies that there has to be special support for the Atheros (Broadcom?) target in the RTL. -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] why is MIPS not equivalent to MIPSEB
Dennis wrote:
I was trying to build a cross compiler by following the MIPS_port doc
but since I needed MIPS bid endian version instead, I changed their
example of MIPSel into MIPS which seems the correct way in dowloading
binutils and specifying TARGET CPU.
However, after many days of struggling, it appears that the correct
spelling regarded by the crosscompiler for MIPS big endian is actually
MIPSEB instead of MIPS!!!
And that probably produced a lot of my earlier problems. I had to
rename all the names of ld and as files from mips to mipseb to have the
compiler stop complaining.
Can someone tell me why in some areas of fpc, it is MIPS and else MIPSEB?
The first thing I want to point out is that you have to be very careful
with the "triplet" that describes the binutils tools. There's a certain
amount of guesswork involved, but once you've got a candidate there's a
tool in the binutils sources to make sure that it's viable.
As far as mips vs mipseb in the FPC sources are concerned:
-8<-
>>> One thing that makes me wonder is how mips and mipsel defines are
>>> related and when to use the 'mips' and when to use 'mipsel'.
>> mips: mipsel and mipseb
>
> Perhaps I was not clear enough, when doing defines for embedded in the
> code should I use:
>
> {$if defined(arm) or defined(avr) or defined(mips)}
>
> or
>
> {$if defined(arm) or defined(avr) or defined(mipsel)}
It seems that Florian was not clear enough either:
- use mipsel if it applies to MIPS Little Endian only
- use mipseb if it applies to MIPS Big Endian only
- use mips if it applies to both MIPS Little and Big endian
->8-
Circa 14th May, see
http://lists.freepascal.org/lists/fpc-devel/2013-May/thread.html
I'd remind you that the binaries I sent you were built with triplets
etc. as given on http://wiki.lazarus.freepascal.org/Native_MIPS_Systems
and that they worked here.
--
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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] can someone please email me a zipped hello world binary program MIPS big endian for testing on my MIPS hardware?
Mark Morgan Lloyd wrote:
Mark Morgan Lloyd wrote:
Mark Morgan Lloyd wrote:
/But/ I've got a vague recollection that somebody else had problems
running on some router or other, which is one of the reasons why I
fired things up at the end of last year and did some careful builds.
I can't remember exactly where that one got to- I suggest that you
look back through the fpc-devel and fpc-pascal archive.
I've asked elsewhere and somebody who does various embedded system work
tells me that
"Yes, I had similar problems with a mips OpenWrt. I couldn't get any
websourced cross compilers to work properly. Progs did compile OK on
the board itself.
"Gave up after a while. Have no idea why, how or what was wrong. :-("
So it looks like it's not just an FPC problem.
| Also, I tried to /proc/cpuinfo and it even said Permission denied (I
| have already chmod 777).
Dennis, is /anything/ readable in /proc? I see that the RTL refers to
/proc/self/exe during startup.
Noted your comment that you're running DD-WRT rather than OpenWRT.
--
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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] can someone please email me a zipped hello world binary program MIPS big endian for testing on my MIPS hardware?
Mark Morgan Lloyd wrote:
Mark Morgan Lloyd wrote:
/But/ I've got a vague recollection that somebody else had problems
running on some router or other, which is one of the reasons why I
fired things up at the end of last year and did some careful builds.
I can't remember exactly where that one got to- I suggest that you
look back through the fpc-devel and fpc-pascal archive.
I've asked elsewhere and somebody who does various embedded system work
tells me that
"Yes, I had similar problems with a mips OpenWrt. I couldn't get any
websourced cross compilers to work properly. Progs did compile OK on
the board itself.
"Gave up after a while. Have no idea why, how or what was wrong. :-("
So it looks like it's not just an FPC 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] can someone please email me a zipped hello world binary program MIPS big endian for testing on my MIPS hardware?
Mark Morgan Lloyd wrote: /But/ I've got a vague recollection that somebody else had problems running on some router or other, which is one of the reasons why I fired things up at the end of last year and did some careful builds. I can't remember exactly where that one got to- I suggest that you look back through the fpc-devel and fpc-pascal archive. The compiler was 2.7.1 (trunk) as of about revision 23218. In practical terms I'd suggest starting off with the current trunk from svn and only trying an older revision if really necessary. If these don't work for you then I think we need to work out what's going wrong, in case it's a general OpenWRT thing. Note below for the big-endian system: $ file ./test-mips-msb ./test-mips-msb: ELF 32-bit MSB executable, MIPS, MIPS-II version 1 (SYSV), statically linked, stripped $ cksum ./test-mips-msb 3420485397 68988 ./test-mips-msb $ ./test-mips-msb Hello, World! $ cat /proc/cpuinfo system type : MIPS Malta processor : 0 cpu model : MIPS 24Kc V0.0 FPU V0.0 BogoMIPS: 78.08 wait instruction: yes microsecond timers : yes tlb_entries : 16 extra interrupt vector : yes hardware watchpoint : yes, count: 1, address/irw mask: [0x0ff8] ASEs implemented: shadow register sets: 1 core: 0 VCED exceptions : not available VCEI exceptions : not available Note below for the little-endian system: $ file ./test-mips-lsb ./test-mips-lsb: ELF 32-bit LSB executable, MIPS, MIPS-II version 1 (SYSV), statically linked, stripped $ cksum ./test-mips-lsb 2200884524 69468 ./test-mips-lsb $ ./test-mips-lsb Hello, World! $ cat /proc/cpuinfo system type : MIPS Malta processor : 0 cpu model : MIPS 24Kc V0.0 FPU V0.0 BogoMIPS: 65.53 wait instruction: yes microsecond timers : yes tlb_entries : 16 extra interrupt vector : yes hardware watchpoint : yes, count: 1, address/irw mask: [0x0ff8] ASEs implemented: shadow register sets: 1 core: 0 VCED exceptions : not available VCEI exceptions : not available On my email etc. system: $ cksum ./test-mips-* 2200884524 69468 ./test-mips-lsb 3420485397 68988 ./test-mips-msb I've sent these in a tarball. I trust that you will accept that if the files arrive with the correct checksums that they've run successfully for me here. Apologies for the lousy threading but our gateway drops some messages. | > I tested the mipseb helloworld provided by Mark (Thanks again) but | > the result is the same as my own helloworld, on running, the whole | > shell just froze. | | did you try to test a "heloworld" done in C, using the cross toolchain | you use ? Michael: Curious thing is that those binaries definitely ran here So there's either something very odd with Qemu/Debian, or with OpenWRT- and I know where I'd put my money. Dennis: Transfer the binary back off the OpenWRT system to a development system, being very careful to track the file to avoid any possible confusion, and apply cksum to it to make sure it's not been corrupted in transit. Then transfer any other binary (e.g. /bin/sh) off the OpenWRT system and apply file to it, to see how it's described. Also listen to Michael and others since they've done far more recent work on this than I have, and if necessary take the trouble of getting more of the toolchain onto the target system. -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] can someone please email me a zipped hello world binary program MIPS big endian for testing on my MIPS hardware?
Mark Morgan Lloyd wrote: Dennis Poon wrote: Since I have spent days but still cannot produce a helloworld binary for MIPS big endian, I need someone to to produce that for me so I can test it on my MIPS hardware. I need to know at this stage whether a FPC produced program compiled for MIPS (big endian) can actually run on my hardware. If that result is negative, I shall need a totally different approach. I've just checked and I have big- and little-endian "Hello, World!" programs natively-compiled that run on Debian Linux on Qemu. I can send either or both if it would help, but I'd caution that they date back to around Xmas last year and something /could/ have changed with the compiler since. Big endian (on appropriate system): $ file test test: ELF 32-bit MSB executable, MIPS, MIPS-II version 1 (SYSV), statically linked, stripped $ ./test Hello, World! Little endian (on appropriate system): $ file test test: ELF 32-bit LSB executable, MIPS, MIPS-II version 1 (SYSV), statically linked, stripped $ ./test Hello, World! /But/ I've got a vague recollection that somebody else had problems running on some router or other, which is one of the reasons why I fired things up at the end of last year and did some careful builds. I can't remember exactly where that one got to- I suggest that you look back through the fpc-devel and fpc-pascal archive. Our gateway is dropping some messages due to attachments or something. Dennis, note the archives at http://lists.freepascal.org/lists/fpc-pascal/ and http://lists.freepascal.org/lists/fpc-devel/ | Mark, | Yes, please kindly send both test executables to me. | Also, if you say the compiler has changed since last christmas, do you | know how I can download the fpc sources version of last christmas? OK, you should have them but I would say that this isn't easy for me at the moment: my host system is too slow to be realistic and booting the two targets took around an hour. The compiler was 2.7.1 (trunk) as of about revision 23218. In practical terms I'd suggest starting off with the current trunk from svn and only trying an older revision if really necessary. If these don't work for you then I think we need to work out what's going wrong, in case it's a general OpenWRT thing. Note below for the big-endian system: $ file ./test-mips-msb ./test-mips-msb: ELF 32-bit MSB executable, MIPS, MIPS-II version 1 (SYSV), statically linked, stripped $ cksum ./test-mips-msb 3420485397 68988 ./test-mips-msb $ ./test-mips-msb Hello, World! $ cat /proc/cpuinfo system type : MIPS Malta processor : 0 cpu model : MIPS 24Kc V0.0 FPU V0.0 BogoMIPS: 78.08 wait instruction: yes microsecond timers : yes tlb_entries : 16 extra interrupt vector : yes hardware watchpoint : yes, count: 1, address/irw mask: [0x0ff8] ASEs implemented: shadow register sets: 1 core: 0 VCED exceptions : not available VCEI exceptions : not available Note below for the little-endian system: $ file ./test-mips-lsb ./test-mips-lsb: ELF 32-bit LSB executable, MIPS, MIPS-II version 1 (SYSV), statically linked, stripped $ cksum ./test-mips-lsb 2200884524 69468 ./test-mips-lsb $ ./test-mips-lsb Hello, World! $ cat /proc/cpuinfo system type : MIPS Malta processor : 0 cpu model : MIPS 24Kc V0.0 FPU V0.0 BogoMIPS: 65.53 wait instruction: yes microsecond timers : yes tlb_entries : 16 extra interrupt vector : yes hardware watchpoint : yes, count: 1, address/irw mask: [0x0ff8] ASEs implemented: shadow register sets: 1 core: 0 VCED exceptions : not available VCEI exceptions : not available On my email etc. system: $ cksum ./test-mips-* 2200884524 69468 ./test-mips-lsb 3420485397 68988 ./test-mips-msb I've sent these in a tarball. I trust that you will accept that if the files arrive with the correct checksums that they've run successfully for me here. -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] can someone please email me a zipped hello world binary program MIPS big endian for testing on my MIPS hardware?
Mark Morgan Lloyd wrote: /But/ I've got a vague recollection that somebody else had problems running on some router or other, which is one of the reasons why I fired things up at the end of last year and did some careful builds. I can't remember exactly where that one got to- I suggest that you look back through the fpc-devel and fpc-pascal archive. Looking back through the archive (mainly fpc-devel), I see occasional discussion of trying to get FPC-compiled programs running on (MIPS) OpenWRT without anybody saying unequivocally that they've succeeded. Can anybody confirm that they've successfully got FPC+MIPS+OpenWRT running, i.e. rather than targeting generic Linux on a development board? -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] can someone please email me a zipped hello world binary program MIPS big endian for testing on my MIPS hardware?
Dennis Poon wrote: Since I have spent days but still cannot produce a helloworld binary for MIPS big endian, I need someone to to produce that for me so I can test it on my MIPS hardware. I need to know at this stage whether a FPC produced program compiled for MIPS (big endian) can actually run on my hardware. If that result is negative, I shall need a totally different approach. I've just checked and I have big- and little-endian "Hello, World!" programs natively-compiled that run on Debian Linux on Qemu. I can send either or both if it would help, but I'd caution that they date back to around Xmas last year and something /could/ have changed with the compiler since. Big endian (on appropriate system): $ file test test: ELF 32-bit MSB executable, MIPS, MIPS-II version 1 (SYSV), statically linked, stripped $ ./test Hello, World! Little endian (on appropriate system): $ file test test: ELF 32-bit LSB executable, MIPS, MIPS-II version 1 (SYSV), statically linked, stripped $ ./test Hello, World! /But/ I've got a vague recollection that somebody else had problems running on some router or other, which is one of the reasons why I fired things up at the end of last year and did some careful builds. I can't remember exactly where that one got to- I suggest that you look back through the fpc-devel and fpc-pascal archive. -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] is there a ready to use FPC Cross compiler x86-Linux -> MIPS-linux?
Dennis Poon wrote: Mark, If you are referring to http://wiki.freepascal.org/MIPS_port then I did use that one but somehow along the way, I still cannot produce a binary program for mips, so someone suggested the binutils I got from that link might be the cause. At the top of that page is a "health warning", which I put in when there was a flurry of activity merging David Zhang's work- for some reason he'd flattened directories etc. and I was working through comparing files to find what had changed. Immediately below that is a link to http://wiki.freepascal.org/Native_MIPS_Systems which includes blow-by-blow accounts of building cross-binutils from source: I put those in using cut-and-paste as I did them but somebody has since tweaked the format. Florian and others started putting a significant amount of effort into the compiler in the middle of last year, at which point I stepped back since (a) they're the experts and (b) I'm stuck using Qemu which isn't really fast enough (Fuxin at Lemote promised a netbook for development which didn't materialise). I'm not saying that link will answer all your questions about the innards of the compiler, but it should result in your having usable tools. If you are referring to a different link, please kindly send again as I did not see it on the fpc discussion list. http://lists.freepascal.org/lists/fpc-pascal/2013-June/038362.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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] is there a ready to use FPC Cross compiler x86-Linux -> MIPS-linux?
Dennis Poon wrote: Michael, I just typed "ld -v" and it replied: GNU ld (GNU Binutils for Debian) 2.22 I do agree they look different. I supposed they should look like "mipsel-linux-ld" but I only followed the wiki.freepascal.org/MIPS_port doc step 1 which stated http://www.emdebian.org/debian/pool/main/b/binutils/ and on that page, the only package looke correct is: "binutils-mips-linux-gnu_2.22-8_i386.deb" and "binutils-mipsel-linux-gnu_2.22-8_i386.deb" After installing those, I got those as and ld files inside their respective bin folder. Can anyone provide me with links of PROVED binutils for MIPS linux? I've already given you a link, on our wiki, describing how to build them from scratch on a Debian system. -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] OT: Re: http://www.freepascal.org/future.var
Howard Page-Clark wrote: On 06/06/2013 08:32, Mark Morgan Lloyd wrote: Reinier Olislagers wrote: On 6-6-2013 7:52, Florian Klämpfl wrote: Reinier Olislagers schrieb: On 5-6-2013 22:02, Florian Klämpfl wrote: I'am opposed to an LLVM backend but if Jonas implements one I can and will not influence this :) That's clear enough, thanks! Of course I meant I can not and will not ... Sure, I understood you: German and Dutch are much alike in this particular construction where you leave out one not/nicht/niet, I think ;) English is the same. Don't worry about it. I'm not a good enough linguist to know if English is "the same", but Florian's original statement in English is ambiguous. It could be taken to mean "I can influence an LLVM implementation, but I will not," or it could be taken to have an implied earlier "not" to mean "I cannot and will not influence..." However it is a very curious construction in English, which immediately makes the reader think "What does he mean exactly?" It's not curious at all. He explicitly said "can and will not", he did not say "can but will not". Anyway, this is veering OT even for an OT thread, all I was trying to say was that his English was entirely adequate- at least to somebody who dates back to the time that grammar was taught as distinct from being allowed to "develop naturally" :-) -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] OT: Re: http://www.freepascal.org/future.var
Reinier Olislagers wrote: On 6-6-2013 7:52, Florian Klämpfl wrote: Reinier Olislagers schrieb: On 5-6-2013 22:02, Florian Klämpfl wrote: I'am opposed to an LLVM backend but if Jonas implements one I can and will not influence this :) That's clear enough, thanks! Of course I meant I can not and will not ... Sure, I understood you: German and Dutch are much alike in this particular construction where you leave out one not/nicht/niet, I think ;) English is the same. Don't worry about 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] is there a ready to use FPC Cross compiler x86-Linux -> MIPS-linux?
Dennis Poon wrote: or x86-Windows -> MIPS-linux cross compiler or x86-MacOS->MIPS-linux cross compiler? any one of the above will be big help to me. I searched the net and the http://wiki.freepascal.org/MIPS_port document seems to be at least Feb 2012 old. I wonder if there exists a more updated document or cross compiler already ready for use? Also see the link it cites, which describes building a Linux-hosted cross-compiler as a necessary stage towards getting it running natively on MIPS. -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] how to generate Free Pascal program for Open source router OpenWrt?
Dennis wrote: I wrote a free pascal program in ubuntu Linux and wanted to deploy it to run in a netgear router through open router firmware OpenWrt. To test it, I copied the program into a OpenWrt virtualbox virtual machine but when I ran it, it said: [ 1891.890545] MyprogramName[1573] general protection ip:bf8e3f86 sp:bf8e2cd4 error:0 Segmentation fault I suspect it's because my compile target is wrong but I thought OpenWrt is already based on linux. Please, in the CPU family, I cannot find the one used by Netgear router which is Atheros AR7161 Just to keep things going since I'm in no way an expert: Google suggests that's MIPS24k, what's the output from cat /proc/cpuinfo on that box? What does the file command have to say about your binary? What version of FPC are you using? -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Program not running
Thomas Schatzl wrote: On Wed, 2013-05-29 at 18:48 +0200, Koenraad Lelong wrote: Op 29-05-13 18:16, Thomas Schatzl schreef: There's snapshot on the ftp. Downloaded ftp://ftp.freepascal.org/pub/fpc/snapshot/v27/arm-linux-armhf/ Should I do this "native" ? Copied the contents to /usr Tried fpc -i, shows fpc 2.6.2, for armel. Is there some mistake ? Yes, you need to fix some symlink so that fpc uses the new compiler. I think there is a symlink in /usr/bin/ppcppc that still points to the old compiler. This is probably wrong, don't remember the exact location of the symlink that is used by the fpc wrapper. I think in general it will be in the same directory as the fpc wrapper gets placed. So which fpc should give this, and then there'll be a symlink ppcarm 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC / Lazarus install on Fedora 18
Jonas Maebe wrote: I understand this is well-intended, but please don't overdo it. The person apologised and acknowledged what his mistake was. Adding a long extra message on this topic does not really add anything useful to the discussion and does not help with creating a friendly atmosphere either. In general comments about such issues, if posted to the list, should only be made by the moderator in any case. My apologies, but I was trying to confirm that there was, in fact a header and to show that it had been part of the email standards for a very long time. It's nothing new, it's not specific to mailing list managers, and it's definitely not specific to this mailing list. I was definitely not trying to "get at" the poster who had inadvertently triggered somebody else's outrage, particularly since he had realised and pointed out what he'd done wrong. However I find the number of complaints I see about this behaviour irritating- it's difficult enough to keep abreast of things as it is. -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC / Lazarus install on Fedora 18
m...@rpzdesign.com wrote: Oops, Looks like there is an internal list coded identifier that links the thread of emails together. Yes, that's been in email since the earliest days- 30 years or so. Look: -8<- References: <519cb0e8.1000...@rpzdesign.com> <519cb1cc.8020...@epidata.info> <519ce1e3.7000...@rpzdesign.com> <20130523163755.1f278aba@darkbreed> ->8- That is totally distinct from the subject line, which is really there only as a summary and which can be changed without breaking an existing thread. My understanding is that MS mail clients have not been very good at honouring this over the years, but "standards compliant" software always has. The fact that a lot of people make this mistake in ignorance is really no excuse. SO EVERYBODY, PLEASE: The moral of the story is to create a completely new email to start another discussion thread and stay away from "Reply" button for convenience. YES, YES, YES, YES, YES!!! Ask yourself: would you walk into a party with a friend, find two people in earnest conversation, stand next to them talking loudly and expect them to be happy about 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TProcess, Batch script and Windows
Michael Van Canneyt wrote: On Wed, 15 May 2013, Marcos Douglas wrote: Hi, I want to execute a batch file on Windows (FPC 2.6.2 and Laz trunk) using TProcess class. It ONLY works if I use the [poWaitOnExit] and DO NOT USE [poNoConsole] options. I do not want to see the console so, I need to use [poNoConsole] option. Is this a bug? As far as I know, batch files need CMD and that needs a console ? For completeness: I've certainly got a Delphi program that can "shell out" to cmd in its main window, but it was non-trivial to 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] systemh.inc(117, 16) Error: Duplicate identifier "FarPointer"h
Marco van de Voort wrote:
In our previous episode, waldo kitty said:
i did even have "2.6.0 or 2.6.2" but decided that was not good even
though it may be supported...
2.6.0 is currently only supported for now. It might be removed sooner or later.
earlier in the thread someone posted that 2.6.2 could be used... that's why i
thought to maybe include that and then rejected due to the phrasing used ("will
work")...
Since 2.6.2 is out, 2.6.2 is the only guaranteed way. But since there was no
immediate reason known to disallow 2.6.0 (and Lazarus still offered 2.6.0
releases at 2.6.2 release time), 2.6.0 was still allowed.
Since earlier this week I've changed the naming, so now the warning specifies
"2.6.2".
Would it be possible to query the makefile to get the required compiler
version etc.? Something like
$ make version
This is Free Pascal version 2.7.1, release 123456.
The only compiler version supported by the build procedure is 2.6.2.
This wouldn't solve historical questions for somebody trying to get
every major version on his system (e.g. "which version of FPC should I
use to build 2.4.2") but might help in the future.
--
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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] systemh.inc(117, 16) Error: Duplicate identifier "FarPointer"
waldo kitty wrote: You are trying to build with 2.7.1. If you are absolutely sure that the current compiler is built from the exact same version/revision, you can try to use OVERRIDEVERSIONCHECK=1 to override . Stop. perhaps the message is too long and too informative? maybe something like a bikini (short and to the point) would be better? eg : Makefile:2704: *** WRONG COMPILER VERSION (2.7.1)! You MUST use 2.6.0 to compile with. Other compiler versions are not supported! (You might try "OVERRIDEVERSIONCHECK=1" but NO SUPPORT is given for this if it fails!) I'd suggest that anything like that would be counterproductive, since it implies that prompt support will be given for things that are even dumber- like trying to compile FPC using Delphi :-) -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] systemh.inc(117, 16) Error: Duplicate identifier "FarPointer"
Eric Kom wrote: On 07/05/2013 10:12, Mark Morgan Lloyd wrote: Eric Kom wrote: Good day, Compile failed. Please see below the error/bug. svn up make clean make OVERRIDEVERSIONCHECK=1 NOGDB=1 OPT='-O- -gl -Xs-' all You've already posted that, this isn't a chatroom and you don't have to repeat yourself. I know that it is not a chatroom, I didn't the respond maybe my mailbox has a problem. There is a full archive of all messages at http://lists.freepascal.org/lists/fpc-pascal/ Your question shows up there, so there I think you need to start asking yourself whether there might be other reasons that it wasn't answered. Now *WHY* are you trying to compile with that override, despite being told by one of the core developers not 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] systemh.inc(117, 16) Error: Duplicate identifier "FarPointer"
Eric Kom wrote: Good day, Compile failed. Please see below the error/bug. svn up make clean make OVERRIDEVERSIONCHECK=1 NOGDB=1 OPT='-O- -gl -Xs-' all You've already posted that, this isn't a chatroom and you don't have to repeat yourself. Now *WHY* are you trying to compile with that override, despite being told by one of the core developers not 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] MS DOS 8086 compiler?
Marco van de Voort wrote: In our previous episode, Mark Morgan Lloyd said: Actually, I have a vintage IBM PC 5150, with a 4.77 MHz 8088 processor, so this isn't true, it's very testable actually :) However, the i8086 code generator still generates some 186/286+ instructions, so it doesn't work there yet, but I'm planning to fix this shortly. Here's a video of a few very simple Free Pascal compiled programs on a true 80186: OK, answering my own question then. A pure-8086 port could be valuable if it generated reliable code for something like vtprolog.pas, since this implements its own garbage collection relying on detailed knowledge of how Turbo Pascal manages its heap. Heap management is mostly a RTL feature. For high TP compatibility, things like calling conventions must also match. Yes, but in the specific case I gave the program extends the heap management. In practical terms it could be replaced with a mark/release arrangement, since when the program is trying to find a solution based on predefined rules it won't be extending them. But as it stands it's a good test of TP-compatibility. IOW 8086 codegeneration is not automatically full TP compatibility on the binary level. -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] MS DOS 8086 compiler?
Nikolay Nikolov wrote: So in practical terms, a strict 8086 port is probably untestable. But why would anybody want to when even embedded processors are based on a newer architecture? Actually, I have a vintage IBM PC 5150, with a 4.77 MHz 8088 processor, so this isn't true, it's very testable actually :) However, the i8086 code generator still generates some 186/286+ instructions, so it doesn't work there yet, but I'm planning to fix this shortly. Here's a video of a few very simple Free Pascal compiled programs on a true 80186: OK, answering my own question then. A pure-8086 port could be valuable if it generated reliable code for something like vtprolog.pas, since this implements its own garbage collection relying on detailed knowledge of how Turbo Pascal manages its heap. -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] MS DOS 8086 compiler?
Bart wrote: On 4/27/13, Reinier Olislagers wrote: Noticed that an 8086 branch was merged to fpc trunk. Is it time to get out some 5.25" diskettes[1]? [1] Shame I dumped all the accompanying hardware long ago ;) Perhaps break out DOSBOX ;) I still have a portable (ahum, > 5 kg) IBM XT with 5.25" floppy disk. HD is appr. 10 MB (decaying...) Problem of course wil be to get the compiler on the floppy disks, and then hope my HD is large enough. (It cost about 10,000 Dfl (appr 4,500 € / $ 5000) at the time of purgase.) I've definitely got at least one system around older than a '386, but if it really is supposed to be an 8086 target it would have to be tested on an 8086/8088 because of extra opcodes that were added to the 186/286. I think I've got a system with 8086 or possibly V20, but it's non-PC and I don't know where its copy of DOS is (it usually ran CCP/M). I don't know how reliable a test something like Dosbox or Bochs would be, some of them vitualise the underlying hardware while others are sloppy about what opcodes they actually implement. So in practical terms, a strict 8086 port is probably untestable. But why would anybody want to when even embedded processors are based on a newer architecture? -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] GetCurrentDir
Henry Vermaak wrote: On Mon, Apr 22, 2013 at 09:57:06AM +0200, Michael Van Canneyt wrote: On Mon, 22 Apr 2013, Marco van de Voort wrote: In our previous episode, Mattias Gaertner said: The FPC code tries to work its way up from '.' in such a case. I just tried, but it gives a correct result in my case. Maybe as fallback it can use the environment variable PWD? No. That would only be valid right after startup, and doesn't change when you chdir in the program. +1 I think that readlink on /proc/self/cwd should work? Could be problematic if the share is in a form that the kernel can't parse. -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Mipsel compilation: changing elf flags?!
Reinier Olislagers wrote: Forum user ocye got mipsel binaries, but the ELF flags apparently need to be changed due to a bug in older Linux kernels. How can this be done? In addition, is there perhaps a compiler switch to manage this? Interesting, there was somebody in (I think) fpc-devel a few months ago with similar problems but we all rather went in circles. Since Lemote appears to be using the compiler OK and since I think I've had it running on (a Qemu emulation of) mipsel, I think that the problem is that /some/ kernel builds are expecting a particular ELF header on /some/ machine types. Correct. The forum thread links to a thread re failing executables using gdd where it appears that (certain?) 2.4 and 2.6 kernels did *not* want the MIPS flag set. If OP could identify the correct parameter for ld it might be possible to use fpc's -k option. Ok, so we have to dig into ld. Thanks; will pass it on. There might be something in http://wiki.lazarus.freepascal.org/Native_MIPS_Systems that will help since it includes the command lines I used for the cross-compilers etc., finding out what variants of binutils could be built was the hardest part. I was hoping to be able to test the MIPS etc. targets on a fairly regular basis, but Qemu (running on the systems available here) quite simply turned out to not be fast enough, and I'm struggling to find time to revisit getting an SGI system running for big-endian work. -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Mipsel compilation: changing elf flags?!
Reinier Olislagers wrote: See this forum thread: http://lazarus.freepascal.org/index.php/topic,20664.msg119960.html#msg119960 Forum user ocye got mipsel binaries, but the ELF flags apparently need to be changed due to a bug in older Linux kernels. How can this be done? In addition, is there perhaps a compiler switch to manage this? Interesting, there was somebody in (I think) fpc-devel a few months ago with similar problems but we all rather went in circles. Since Lemote appears to be using the compiler OK and since I think I've had it running on (a Qemu emulation of) mipsel, I think that the problem is that /some/ kernel builds are expecting a particular ELF header on /some/ machine types. If OP could identify the correct parameter for ld it might be possible to use fpc's -k option. -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpGUI Toolkit v1.0 release for FPC 2.6.2
Graeme Geldenhuys wrote: fpGUI v1.0 is available I'm glad to announce the 1.0 release of fpGUI. This has been over a years worth of development, so a complete list of changes will be to big to list here. Congratulations and well done. I'll definitely take another look when I've got a chance, what I've seen so far has been impressive. -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] LLVM (again)
Sven Barth wrote: Am 19.04.2013 14:05, schrieb Sven Barth: Am 19.04.2013 14:02, schrieb Reimar Grabowski: Hi, I have read the discussions about FPC using LLVM and the reasons against it (which I fully understand and support). But a friend of mine called my attention to this: https://github.com/kripken/emscripten/wiki If you would have read the discussion about LLVM you would know that emscripten was the reason that it was brought up the last time... ;) Sorry, it should be "Since you have read ... you should know ..." Nah. "Should you have read ... you would know..." unless such conciseness is frowned upon as an attribute of brace-using languages :-) :-) -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] socket timeout
Michael Schnell wrote: On 04/16/2013 11:26 AM, Xiangrong Fang wrote: How can I set the connection and read/write timeout when using socket in free pascal? I seem to remember that synapse can do this. Otherwise for non-standard protocols use fpconnect(), fpselect() 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Array assignment, and not-a-number
Sven Barth wrote: That's a good point, although obviously ordering would be lost. After I'd tinkered with it for a while I concluded that it was probably related to the discussion of tuples a few weeks ago. Not really. Also the principial components are already available in the compiler so in theory (!) one could implement this. Array constructors (the "[...]" notation) is already used for open array parameters Although if I understand things correctly that's for the specific case of a parameter passed to a procedure of function, not for the operand of a redefined operator such as := even though the definition looks like a function. and array initialization is already possible for named dynamic arrays in the form of the delphi compatible "TMyDynamicArrayType.Create(1, 2, 3, 4, 5);" (yes, I think this is a bad choice of implementing it and comes probably from Delphi.NET :( ) So it might be able to do it with a type helper, at the cost of looking like a function rather than like an ordinary assignment. Of course one place where what I'm playing with gets hairy is in overlaid operator definition: I'm having to define e.g. + for a pair of 1-D dynamic arrays, a pair of 2-D dynamic arrays and so on. If I understand things correctly it's not possible to define a generalised dynamic array parameter where the dimension (number of axes/indexes) as well as the rank (range of each index) is undefined. -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Array assignment, and not-a-number
Marco van de Voort wrote: In our previous episode, Jonas Maebe said: with an appropriate definition of the + operator without risk that an error would try to evaluate it as an ordinary arithmetic expression? We don't have constant to identify a qNaN. From math: NaN = 0.0/0.0; Infinity = 1.0/0.0; NegInfinity = -1.0/0.0; but of course that is just notation/convention (that 0.0/0.0 as literal evaluates to NaN), it doesn't mean all archs do. Thanks for that. Initial experiment using a NaN real or nil pointer throws an exception as soon as it's passed as the parameter which I suppose is not entirely surprising. Using varnull as a placeholder seems safest, although it looks as though I can't initialise a variant at declaration... WTH, it's just a toy for the moment at least. -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Array assignment, and not-a-number
Jonas Maebe wrote: On 15 Apr 2013, at 16:48, Mark Morgan Lloyd wrote: I was having a bit of fun earlier while waiting for a call. Am I correct in believing that something like typet1= array of integer; var a1: t1; x: integer; a1 := [1,2,3,4,5]; can't be done at present, irrespective of any custom definition of the := operator? Maybe if you overload the assignment operator for "t2=set of byte" to "t1" assignments, but I'm not certain. It's definitely not something we explicitly support. That's a good point, although obviously ordering would be lost. After I'd tinkered with it for a while I concluded that it was probably related to the discussion of tuples a few weeks ago. Is there an accessible not-a-number constant, to allow me to do something like var reduce: double= NAN; x := reduce + a1; with an appropriate definition of the + operator without risk that an error would try to evaluate it as an ordinary arithmetic expression? We don't have constant to identify a qNaN. I don't even know whether all architectures support them. Currently, the only way to achieve the above is by masking exceptions for invalid floating point operations: math.SetExceptionMask(math.GetExceptionMask + [exInvalidOp]). Thanks, noted. In practical terms the value isn't important, and I could obviously use something like a null variant or for that matter a nil pointer as a marker. You cannot overload/override operators that have a built-in meaning in the language (such as double+double). Understood, but what I'm doing here is using "reduce +" as an experimental alternative to APL's +/ or Vector Pascal's \+ to reduce the dimension of the right operand by applying the operator: c1: 7 9 11 13 5 +/ c1: 45 I've not investigated SSE or spreading over multiple cores yet, and probably won't due to time issues. My only incentive was looking for some alternative to Vector Pascal's higher-level functions, since obviously something like \ couldn't be achieved without major compiler surgery. -- 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/mailman/listinfo/fpc-pascal
[fpc-pascal] Array assignment, and not-a-number
I was having a bit of fun earlier while waiting for a call. Am I correct in believing that something like typet1= array of integer; var a1: t1; x: integer; a1 := [1,2,3,4,5]; can't be done at present, irrespective of any custom definition of the := operator? Is there an accessible not-a-number constant, to allow me to do something like var reduce: double= NAN; x := reduce + a1; with an appropriate definition of the + operator without risk that an error would try to evaluate it as an ordinary arithmetic expression? -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Portable (or at least working) version of GetDomainName()?
waldo kitty wrote: i would attempt to go portable by performing a DNS lookup on the address and or the given host name... i don't think i would try to use external programs for this but would compare my results with theirs for the same lookups... Agreed. I rarely use external programs since there's too much risk they're misplaced or of an unexpected version FWIW: i also just stumbled over our very similar conversation of a year ago... 13 April 2012 - Resolving a local hostnames to an IP address http://free-pascal-general.1045716.n5.nabble.com/Resolving-a-local-hostnames-to-an-IP-address-td5637709.html So did I. As a quick hack I've parsed /etc/resolv.conf (which covers at least the Linux and Solaris cases), falling back to GetDomainName() if that fails. That will do for the moment, since it will normally be overridden by a .ini file or by something explicitly entered by the user. -- 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/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Portable (or at least working) version of GetDomainName()?
Ludo Brands wrote: On 04/09/2013 10:14 AM, Mark Morgan Lloyd wrote: It might be notable that Debian doesn't volunteer a domain name unless it's able to contact DNS. I'll get onto nslookup, or just use temporary text (it's only salt for a password hash, and is stored). One of the problems with uname is that the kernel doesn't have a clue on how you are connected to the network. Your computer could have 10 network names if it had 10 addresses (not even 10 NIC's required). Looking up the IP you want the domain name for in a DNS is the only reliable way. And it is portable. Thanks Ludo, I'd got there. I think there's still the possibility of ambiguity if there are multiple DNS servers listed in resolv.conf, but I agree that it's probably the best way available. -- 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/mailman/listinfo/fpc-pascal
