Re: [fpc-pascal] Re: build a compiler for GO32v2 under Windows 8 (or 7)
In our previous episode, Tomas Hajny said: > Have you checked it in fixes or trunk? In any case, I've tried it directly > with the 2.6.2 binary before posting - even if I pass -Xi explicitly, the > compiler still complains about go32v2-ld.exe not found if it is not > accessible (and linking fails). I believe that Sergei may have fixed / > enabled it for GO32v2 in trunk (but my memory may serve me wrong, of > course). I also started testing when I saw it, and I could cycle trunk with -Xi. I'm not sure how far along it is, and if it is default. (is the internal linker always default if available?) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: StrUtils.RomanToInt oddities
On 18/09/2013 16:19, Bart wrote:
> RomanToInt acceps rather ludicrous values:
>
> RomanToInt('MDCLXVIVXLDM') = 2209
> RomanToInt('M') = 1002 //calculated as 3 + (1000-1)
>
> Both examples represent invalid roman numbers by any standard.
> Also I do not think Roman numerals can be negative...
>
> Feature or bug?
>
1. I'll respond with the expected answer: "What does Delphi do" (if it
has this function?
2. I wouldn't be bothered by negative numbers... even the Romans used to
have negative posessions (= debts) and they didn't have double entry
bookkeeping yet ;) Also, the documentation [1] mentions it as a feature.
3. The rest... well, depending on 1. I'd agree it's a bug.
[1] mentions "Invalid characters are dropped from S"... which I think is
a bit strange (S is a const) but assuming it means "Invalid characters
in S are ignored" it means somebody thought checking the input for valid
Roman numbers was a good idea. The question however becomes "what is the
algorithm for deciding invalid characters" which IMO will become a mess
very quickly. Much better to just consider the entire input as invalid.
[1] http://lazarus-ccr.sourceforge.net/docs/rtl/strutils/romantoint.html
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: build a compiler for GO32v2 under Windows 8 (or 7)
Am 20.09.2013 09:20, schrieb Marco van de Voort:
In our previous episode, Tomas Hajny said:
Have you checked it in fixes or trunk? In any case, I've tried it directly
with the 2.6.2 binary before posting - even if I pass -Xi explicitly, the
compiler still complains about go32v2-ld.exe not found if it is not
accessible (and linking fails). I believe that Sergei may have fixed /
enabled it for GO32v2 in trunk (but my memory may serve me wrong, of
course).
I also started testing when I saw it, and I could cycle trunk with -Xi.
I'm not sure how far along it is, and if it is default. (is the internal
linker always default if available?)
Yes, the internal linker is used by default. See options.pas, line 3246:
=== code begin ===
{ Force use of external linker if there is no
internal linker or the linking is skipped }
if not(cs_link_extern in init_settings.globalswitches) and
((target_info.link=ld_none) or
(cs_link_nolink in init_settings.globalswitches)) then
include(init_settings.globalswitches,cs_link_extern);
=== code end ===
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: build a compiler for GO32v2 under Windows 8 (or 7)
Am 19.09.2013 22:46, schrieb Tomas Hajny: On Thu, September 19, 2013 21:55, Sven Barth wrote: On 19.09.2013 17:28, Tomas Hajny wrote: . . 2) You still need at least a linker for the GO32v2 target (FPC internal linker does not support this target) and that is the somewhat tricky part. Hmm? Looking at compiler/systems/t_go32v2.pas I would say GO32v2 does have an internal linker?! Have you checked it in fixes or trunk? In any case, I've tried it directly with the 2.6.2 binary before posting - even if I pass -Xi explicitly, the compiler still complains about go32v2-ld.exe not found if it is not accessible (and linking fails). I believe that Sergei may have fixed / enabled it for GO32v2 in trunk (but my memory may serve me wrong, of course). Ehm, yes, trunk only. Sergei implemented it in revision 21435 at 30th May 2012. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: build a compiler for GO32v2 under Windows 8 (or 7)
In our previous episode, Sven Barth said: > > > > I'm not sure how far along it is, and if it is default. (is the internal > > linker always default if available?) > Yes, the internal linker is used by default. See options.pas, line 3246: >From the code and looking at the i_ records, I'd say that the .link field determines if the internal linker is used. (so not just its registration). Anyway thanks, it is clearer now. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] FPCUP Windows now has Go32V2 cross compiling support
Hi list, Recent posts have lead me to look again at my FPC/Lazarus downloader/compiler fpcup [1] to see if I could get cross compiling going from win64 or win64 to Go32v2. This works for me: 1) Setup: Create directory c:\development Get crosscompile binutils from ftp://ftp.freepascal.org/pub/fpc/contrib/cross/mingw/binutils-2.20-win32-i386-go32v2.zip Place the binaries in c:\development\cross\bin\i386-go32v2 Binaries include i386-go32v2-ar.exe i386-go32v2-as.exe i386-go32v2-ld.exe i386-go32v2-objdump.exe i386-go32v2-strip.exe 2) Let fpcup compile a new FPC and Lazarus: fpcup 3) Then do a cross compile; note this does require the cross compilation binutils but fpcup will warn you if they're missing fpcup --cputarget=i386 --ostarget=go32v2 Fpcup will give a warning about missing support for LCL/Lazarus which is expected as there's no LCL for Go32V2. 4) Start the installed Lazarus, create a simple program/console program, in Project Options, set target OS to go32v2 and target CPU to i386. Compile. 5) Remember to distribute cwsdpmi.exe with your programs. http://homer.rice.edu/~sandmann/cwsdpmi/index.html download: http://homer.rice.edu/~sandmann/cwsdpmi/csdpmi7b.zip Starting dosbox, running cwsdpmi and then a hello world .exe worked fine. As usual: comments/suggestions welcome. Thanks, Reinier [1] https://bitbucket.org/reiniero/fpcup/downloads ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities
On 9/20/13, Bart wrote: > Any invalid char in S will result in Result being 0; > So doc is wrong about that. Reported that in bugtracker: http://bugs.freepascal.org/view.php?id=25061 Bart ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] represent data string in hex?
On 9/20/13, wkitt...@windstream.net wrote: > > a[n] := #255; // works > a[n] := $ff; // does not work > > ideally, there would be multiple bytes... > > a[n] := $C2AD or a[n] := $C2$AD > Not sure what you want: a[n] := #$FF; (which equals a[n] := #255) a[n] := '$FF' (note the single quotes), assuming a[n] is of type String. Bart ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities
On 9/20/13, Reinier Olislagers wrote: > 1. I'll respond with the expected answer: "What does Delphi do" (if it > has this function? D7 PE does not have it. > 2. I wouldn't be bothered by negative numbers... even the Romans used to > have negative posessions (= debts) and they didn't have double entry > bookkeeping yet ;) Also, the documentation [1] mentions it as a feature. If I mention in documentationn that result is unpredicted for any input e.g. for function StrToInt(S), because ATMI implemented it like Result := StringOfChar(Char(Random(256)),Random(256)), then this would also not considered to be a bug, just it because does what the docs say? > 3. The rest... well, depending on 1. I'd agree it's a bug. > [1] mentions "Invalid characters are dropped from S"... which I think is > a bit strange (S is a const) but assuming it means "Invalid characters > in S are ignored" it means somebody thought checking the input for valid > Roman numbers was a good idea. The question however becomes "what is the > algorithm for deciding invalid characters" which IMO will become a mess > very quickly. Much better to just consider the entire input as invalid. Any invalid char in S will result in Result being 0; So doc is wrong about that. Bart ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities
On 20/09/2013 18:33, Bart wrote: > On 9/20/13, Reinier Olislagers wrote: >> 2. I wouldn't be bothered by negative numbers... even the Romans used to >> have negative posessions (= debts) and they didn't have double entry >> bookkeeping yet ;) Also, the documentation [1] mentions it as a feature. > > If I mention in documentationn that result is unpredicted for any > input [snip irrelevant part] then this would > also not considered to be a bug, just it because does what the docs > say? Well, if you want a black and white answer: yes, because the implementation follows the documentation/specifcations. However, as I indicated in the rest of my post, I do think the implementation(+documentation) needs to be changed for other cases. I just don't see that many problems by allowing negative numbers. >> 3. The rest... well, depending on 1. I'd agree it's a bug. >> [1] mentions "Invalid characters are dropped from S"... which I think is >> a bit strange (S is a const) but assuming it means "Invalid characters >> in S are ignored" it means somebody thought checking the input for valid >> Roman numbers was a good idea. The question however becomes "what is the >> algorithm for deciding invalid characters" which IMO will become a mess >> very quickly. Much better to just consider the entire input as invalid. > > Any invalid char in S will result in Result being 0; > So doc is wrong about that. Seems we agree here: 1. Changing docs to mention any invalid character will lead to result being 0. No idea what the policy is about needing to raise exceptions in case of errors - in this particular case, returning 0 should actually be enough by itself as there is no Roman numeral that stands for the value 0... 2. The other cases you mentioned in your OP are bugs, not features. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPCUP Windows now has Go32V2 cross compiling support
On Fri, September 20, 2013 18:42, Reinier Olislagers wrote: Hi Reinier, > Recent posts have lead me to look again at my FPC/Lazarus > downloader/compiler fpcup [1] to see if I could get cross compiling > going from win64 or win64 to Go32v2. > > This works for me: > 1) Setup: > Create directory c:\development > Get crosscompile binutils from > ftp://ftp.freepascal.org/pub/fpc/contrib/cross/mingw/binutils-2.20-win32-i386-go32v2.zip > Place the binaries in c:\development\cross\bin\i386-go32v2 > > Binaries include > i386-go32v2-ar.exe > i386-go32v2-as.exe > i386-go32v2-ld.exe > i386-go32v2-objdump.exe > i386-go32v2-strip.exe > > 2) Let fpcup compile a new FPC and Lazarus: > fpcup > > 3) Then do a cross compile; note this does require the cross compilation > binutils but fpcup will warn you if they're missing > fpcup --cputarget=i386 --ostarget=go32v2 > Which FPC branch do you use, trunk or fixes? If it is trunk, it should be able to use not only the internal assembler but also internal linker and thus these binutils are not used at all (unless also using -Xe). If it is fixes, then I wonder what happens there because the linker included in the package above completely refuses object files created by FPC 2.6.2 (admittedly, I haven't tested a fixes snapshot, but I wouldn't expect major changes in this area merged to fixes) - the linker complains about unsupported section type and doesn't find the required symbols. Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] represent data string in hex?
i have a static array of strings that i need to fill as hex bytes... i can do this in decimal but it would be easier to convert other data if i can do it in hex since the data is represented in hex... a[n] := #255; // works a[n] := $ff; // does not work ideally, there would be multiple bytes... a[n] := $C2AD or a[n] := $C2$AD help? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities
And please, before anyone gets offended by my postings in this thread: - I just stubled on this whils doing a kind WTF implementation of something like this (and at that time I didn't even knew we had StrUtils.RomanToInt). - I don't think it is the end of the world just because the StrUtils version behaves different than I expected it to. - I do not want to pretend my interpretation of "valid Roman numeral" is the absolute truth. I was just curious as to the why? I have my own interpretation (in code), so if fpc's stays as is, no problem whatsoever. It (my version) is LGPL, so anyone can use and or contribute. Sometimes I just like having these kind of discussions... Bart ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities
On 9/20/13, Reinier Olislagers wrote: > 2. The other cases you mentioned in your OP are bugs, not features. Unless the Greek do the same, someone with recent Delphi should test. If that's the case we're doomed to follw that. Bart ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: StrUtils.RomanToInt oddities
On 9/20/13, Reinier Olislagers wrote:
> The question however becomes "what is the
> algorithm for deciding invalid characters" which IMO will become a mess
> very quickly. Much better to just consider the entire input as invalid.
>
Here's my implementation:
program test;
{$mode objfpc}
{$H+}
uses
SysUtils, StrUtils;
function TryRomanToInt(S: String; out N: Integer): Boolean;
var
i, Len: Integer;
Terminated: Boolean;
begin
Result := (False);
S := UpperCase(S); //don't use AnsiUpperCase please
Len := Length(S);
if (Len = 0) then Exit;
i := 1;
N := 0;
Terminated := False;
//leading M's
while (i <= Len) and (S[i] = 'M') do
begin
//writeln('TryRomanToInt: Found 1000');
Inc(i);
N := N + 1000;
end;
//then CM or or CD or D or (C, CC, CCC, )
if (i <= Len) and (S[i] = 'D') then
begin
//writeln('TryRomanToInt: Found 500');
Inc(i);
N := N + 500;
end
else if (i + 1 <= Len) and (S[i] = 'C') then
begin
if (S[i+1] = 'M') then
begin
//writeln('TryRomanToInt: Found 900');
Inc(i,2);
N := N + 900;
end
else if (S[i+1] = 'D') then
begin
//writeln('TryRomanToInt: Found 400');
Inc(i,2);
N := N + 400;
end;
end ;
//next max 4 C's
if (i <= Len) and (S[i] = 'C') then
begin
//find max 4 C's
//writeln('TryRomanToInt: Found 100');
Inc(i);
N := N + 100;
if (i <= Len) and (S[i] = 'C') then
begin
//writeln('TryRomanToInt: Found 100');
Inc(i);
N := N + 100;
end;
if (i <= Len) and (S[i] = 'C') then
begin
//writeln('TryRomanToInt: Found 100');
Inc(i);
N := N + 100;
end;
if (i <= Len) and (S[i] = 'C') then
begin
//writeln('TryRomanToInt: Found 100');
Inc(i);
N := N + 100;
end;
end;
//then XC or XL
if (i + 1 <= Len) and (S[i] = 'X') then
begin
if (S[i+1] = 'C') then
begin
//writeln('TryRomanToInt: Found 90');
Inc(i,2);
N := N + 90;
end
else if (S[i+1] = 'L') then
begin
//writeln('TryRomanToInt: Found 40');
Inc(i,2);
N := N + 40;
end;
end;
//then L
if (i <= Len) and (S[i] = 'L') then
begin
//writeln('TryRomanToInt: Found 50');
Inc(i);
N := N + 50;
end;
//then (X, xx, xxx, )
if (i <= Len) and (S[i] = 'X') then
begin
//find max 4 X's
//writeln('TryRomanToInt: Found 10');
Inc(i);
N := N + 10;
if (i <= Len) and (S[i] = 'X') then
begin
//writeln('TryRomanToInt: Found 10');
Inc(i);
N := N + 10;
end;
if (i <= Len) and (S[i] = 'X') then
begin
//writeln('TryRomanToInt: Found 10');
Inc(i);
N := N + 10;
end;
if (i <= Len) and (S[i] = 'X') then
begin
//writeln('TryRomanToInt: Found 10');
Inc(i);
N := N + 10;
end;
end;
//then IX or IV
if (i + 1 <= Len) and (S[i] = 'I') then
begin
if (S[i+1] = 'X') then
begin
Terminated := (True);
//writeln('TryRomanToInt: Found 9');
Inc(i,2);
N := N + 9;
end
else if (S[i+1] = 'V') then
begin
Terminated := (True);
//writeln('TryRomanToInt: Found 4');
Inc(i,2);
N := N + 4;
end;
end;
//then V
if (not Terminated) and (i <= Len) and (S[i] = 'V') then
begin
//writeln('TryRomanToInt: Found 5');
Inc(i);
N := N + 5;
end;
//then I
if (not Terminated) and (i <= Len) and (S[i] = 'I') then
begin
Terminated := (True);
//writeln('TryRomanToInt: Found 1');
Inc(i);
N := N + 1;
//Find max 3 closing I's
if (i <= Len) and (S[i] = 'I') then
begin
//writeln('TryRomanToInt: Found 1');
Inc(i);
N := N + 1;
end;
if (i <= Len) and (S[i] = 'I') then
begin
//writeln('TryRomanToInt: Found 1');
Inc(i);
N := N + 1;
end;
if (i <= Len) and (S[i] = 'I') then
begin
//writeln('TryRomanToInt: Found 1');
Inc(i);
N := N + 1;
end;
end;
//writeln('TryRomanToInt: Len = ',Len,' i = ',i);
Result := (i > Len);
//if Result then writeln('TryRomanToInt: N = ',N);
end;
var
S: String;
N1, N2: Integer;
B: Boolean;
begin
repeat
write('Enter Roman numeral: ');
readln(S);
B := TryRomanToInt(S, N1);
if B then
write('TryRomanToInt(''',S,''') -> ',N1)
else
write('TryRomanToInt(''',S,''') FAIL');
writeln;
N2 := StrUtils.RomanToInt(S);
writeln('StrUtils.RomanToInt(''',S,''') = ',N2);
if B and (N1 <> N2) then writeln('StrUtils.RomanToInt <> TryRomanToInt');
writeln;
until S = '';
end.
Bart
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPCUP Windows now has Go32V2 cross compiling support
On 20/09/2013 18:55, Tomas Hajny wrote: > On Fri, September 20, 2013 18:42, Reinier Olislagers wrote: > Which FPC branch do you use, trunk or fixes? If it is trunk, it should be > able to use not only the internal assembler but also internal linker and > thus these binutils are not used at all (unless also using -Xe). Hi Tomas, Thanks a lot! I've tested it with trunk. I've adapted fpcup to not error out if those binutils are not found. Instead it writes a warning about 2.6.x needing binutils. > If it is > fixes, then I wonder what happens there because the linker included in the > package above completely refuses object files created by FPC 2.6.2 > (admittedly, I haven't tested a fixes snapshot, but I wouldn't expect > major changes in this area merged to fixes) - the linker complains about > unsupported section type and doesn't find the required symbols. Haven't tested on fixes yet. Thanks again, Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPCUP Windows now has Go32V2 cross compiling support
In our previous episode, Reinier Olislagers said: > > able to use not only the internal assembler but also internal linker and > > thus these binutils are not used at all (unless also using -Xe). > > Hi Tomas, > Thanks a lot! > > I've tested it with trunk. I've adapted fpcup to not error out if > those binutils are not found. Instead it writes a warning about 2.6.x > needing binutils. Note that despite internal assembler, one might still need GAS because of the startup code (Linux being a special case, having startup code in pascal) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPCUP Windows now has Go32V2 cross compiling support
On Fri, September 20, 2013 21:30, Marco van de Voort wrote: > In our previous episode, Reinier Olislagers said: >> > able to use not only the internal assembler but also internal linker >> and >> > thus these binutils are not used at all (unless also using -Xe). >> >> Hi Tomas, >> Thanks a lot! >> >> I've tested it with trunk. I've adapted fpcup to not error out if >> those binutils are not found. Instead it writes a warning about 2.6.x >> needing binutils. > > Note that despite internal assembler, one might still need GAS because of > the startup code (Linux being a special case, having startup code in > pascal) True, that's a good point. Still, the linker from that package didn't work for me with the 2.6.2 compiler (I haven't tried it with trunk, but it might be broken there too). Also, the linker included in the 2.15 build in contrib isn't compatible with the command line syntax used by our compiler for the GO32v2 target (as already mentioned in my yesterday's post). One possible option might be to change the compiler in order not to generate link.res unless using a DOS compiler or using -st option (assuming that this was a DJGPP extension due to limited length of DOS command line). Another possibility might be trying to get this option supported in standard binutils, but that would be certainly a task for someone else than me. Or is there possibly an option (e.g. some binutils Makefile directive) to get that ld option enabled, so that just rebuilding binutils with that option would be sufficient? Any thoughts? Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
