Closed ahribellah closed 2 years ago
skaller
commented
4 years ago Ah. Could be the build system isn't setting the right standard, or, MSVC 2019 isn't defaulting to C++ version required. Sorry, this is because I got tired of Appveyor timing out, and don't test windows builds myself. Its VS version 14 you have. I'm normally building with C++17, but that file (uint256_t) should build with C++11.
skaller
commented
4 years ago Oh dear .. I only have VS2015. :-)
skaller
commented
4 years ago ARgghg. I have a problem, git is not pulling from my Windows box. I have no idea why, the repo is public.
ahribellah
commented
4 years ago MSVC 2019 defaults to C++17, apparently (I don't use it often, tbh, so I wasn't aware). I'm reading that it doesn't have a mode for the C++11 standard, but that setting it to use C++14 should work.
EDIT: Nevermind, I misread. It defaults to C++14, which is the oldest standard available.
See (VS2017 mentioned here, but same should apply for VS2019 because the C++14 standard is still available): https://stackoverflow.com/questions/47043869/is-c11-available-in-visual-studio-2017/47043985
ARgghg. I have a problem, git is not pulling from my Windows box. I have no idea why, the repo is public.
Odd. Maybe download the repo as a zip?
skaller
commented
4 years ago OK, my bad, should have used https for the git clone. Got the repo now. Found a bug, the script is making a directory $PWD instead of setting PWD to the current directory. Running buildscript\winsetup.bat is required. It's set up for my Windows box so may needed editing on other systems.
Its a slight pain, i have a mac and windows/linux dual boot machine on the table but they're not connected at all except via the internet. So I can't copy stuff from the windows box to here except by sneaker net. Anyhow my build is running now. I expect the same issue.
skaller
commented
4 years ago OK I just did a complete from scratch Felix build on Windows using VS20-15 x86_x84 cross compiler. Its running tests now. So I haven't been able to reproduce the problem.
skaller
commented
4 years ago So uint256_t is a third party library which is shipped with Felix. The error is that it cannot convert from uint128_t to uint256_t. I don't know exactly where in the build process the package is being built.
However this constructor:
template <
typename T,
typename = typename std::enable_if<std::is_integral<T>::value, T>::type >
uint256_t(const T & rhs)should work provided this invalid C++ works:
// Give uint128_t type traits
namespace std { // This is probably not a good idea
template <> struct is_arithmetic <uint128_t> : std::true_type {};
template <> struct is_integral <uint128_t> : std::true_type {};
template <> struct is_unsigned <uint128_t> : std::true_type {};
};So it's possible, maybe, that VS2019 is failing to accept the specialisations above when considering the enable_if in the constructor.
ahribellah
commented
4 years ago So it's definitely related to VS2019, then.
gbluma
commented
4 years ago Looks like I can replicate the issue. Is uint256_t custom or imported from something else?
On Sat, Mar 7, 2020 at 1:58 AM Ari notifications@github.com wrote:
So it's definitely related to VS2019, then.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/felix-lang/felix/issues/149?email_source=notifications&email_token=AABLVN7WL2UQQTA27G7E5P3RGGS5PA5CNFSM4LDF2XO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEODLVHQ#issuecomment-596032158, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABLVN5EPY7AOGTASBQBVHTRGGS5PANCNFSM4LDF2XOQ .
ahribellah
commented
4 years ago I tried grabbing the latest version from here: https://github.com/calccrypto/uint256_t
Unfortunately, it's still throwing the same error.
skaller
commented
4 years ago I checked Windows build log, it's building Ok on my setup.
ahribellah
commented
4 years ago But that's in VS2015, right? Should I just use VS2015?
skaller
commented
4 years ago Well, we should try to find out what's going on. I'm going to post the actual command line from my Windows box in a sec. You can search in build/release/fbuild.log for more info.
skaller
commented
4 years ago Thread-2 : starting "'C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\VC\\BIN\\x86_amd64\\cl.exe' /nologo /c /GR /MDd /EHs /Zi /wd4291 /wd4190 /Ox /Ibuild\\release\\share\\src\\uint256_t /DFLX_STATIC_LINK /Fobuild\\release\\obj\\host\\lib\\rtl\\flx_uint256_t_static\\build\\release\\share\\src\\uint256_t\\uint256_t_static.obj /showIncludes build\\release\\share\\src\\uint256_t\\uint256_t.cpp"
* cl.exe /GR /MDd /EHs /Zi /wd4291 /wd4190: build\release\share\src\uint256_t\uint256_t.cpp -> build\release\obj\host\lib\rtl\flx_uint256_t_static\build\release\share\src\uint256_t\uint256_t_static.obj
+ 'C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\x86_amd64\cl.exe' /nologo /c /GR /MDd /EHs /Zi /wd4291 /wd4190 /Ox /Ibuild\release\share\src\uint256_t /DFLX_STATIC_LINK /Fobuild\release\obj\host\lib\rtl\flx_uint256_t_static\build\release\share\src\uint256_t\uint256_t_static.obj /showIncludes build\release\share\src\uint256_t\uint256_t.cpp
uint256_t.cppLooks like marginally the same info as the original post.
The possible additional info is here:
Error running 'C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Community\\VC\\Tools\\MSVC\\14.24.28314\\bin\\HostX64\\x64\\cl.exe /nologo /c /GR /MDd /EHs /Zi /wd4291 /wd4190 /Ox /Ibuild\\release\\share\\src\\uint256_t /DFLX_STATIC_LINK /Fobuild\\release\\obj\\host\\lib\\rtl\\flx_uint256_t_static\\build\\release\\share\\src\\uint256_t\\uint256_t_static.obj /showIncludes build\\release\\share\\src\\uint256_t\\uint256_t.cpp' exited with 2
Thread-2 : starting "'C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Community\\VC\\Tools\\MSVC\\14.24.28314\\bin\\HostX64\\x64\\cl.exe' /nologo /c /GR /MDd /EHs /Zi /wd4291 /wd4190 /Ox /Ibuild\\release\\share\\src\\uint256_t /DFLX_STATIC_LINK /Fobuild\\release\\obj\\host\\lib\\rtl\\flx_uint256_t_static\\build\\release\\share\\src\\uint256_t\\uint128_t_static.obj /showIncludes build\\release\\share\\src\\uint256_t\\uint128_t.cpp"
* cl.exe /GR /MDd /EHs /Zi /wd4291 /wd4190: build\release\share\src\uint256_t\uint128_t.cpp -> build\release\obj\host\lib\rtl\flx_uint256_t_static\build\release\share\src\uint256_t\uint128_t_static.obj
+ 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.24.28314\bin\HostX64\x64\cl.exe' /nologo /c /GR /MDd /EHs /Zi /wd4291 /wd4190 /Ox /Ibuild\release\share\src\uint256_t /DFLX_STATIC_LINK /Fobuild\release\obj\host\lib\rtl\flx_uint256_t_static\build\release\share\src\uint256_t\uint128_t_static.obj /showIncludes build\release\share\src\uint256_t\uint128_t.cpp
uint128_t.cppI've attached the full log below.
skaller
commented
4 years ago Yeah, same error. But I didn't get it. So I think, scanning the source code, that there is only one constructor that could apply, the nasty crap with the enable_if in it. So there are two possibilities if think:
I'm betting on 1. My GUESS .. and its only a guess .. is that VS2019 has built in "pre-compiled headers" for some stuff or some other machinery that causes it to ignore the specialisation of is_integral in namespace std which I think is not allowed. It worked on old version, but VS2019 has additional optimisations that take advantage of the rule, or something similar.
Of course this is a design fault in the standard library. Of course the user has to be able to specialise that template, for precisely the reason indicated in this code: we have bigger ints than available and we want them to work as if they were standard.
Anyhow, some way to fix it is necessary. One obvious solution is to add an explicit constructor for uint256_t from uint128_t. This would overlap the existing constructor BUT it is not polymorphic, so it should override the template one.
I can try this on the Mac, to make sure it doesn't break anything, then commit. [I have to go do something for a while first tho .. be an hour or so]
gbluma
commented
4 years ago Yeah, looks like it's some sort of conflict in the type traits.
The library tries to extend the std type traits.
//////// uint256_t.include
// Give uint256_t type traits
namespace std { // This is probably not a good idea
template <> struct is_arithmetic
This is defined in MSVC.
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.24.28314\include\xtr1common(188): note: see declaration of 'std::is_integral'
Ideally it should play nice, but I think we're seeing an issue with it not lining up exactly as required.
On Sat, Mar 7, 2020 at 2:47 AM John Skaller notifications@github.com wrote:
Yeah, same error. But I didn't get it. So I think, scanning the source code, that there is only one constructor that could apply, the nasty crap with the enable_if in it. So there are two possibilities if think:
- compiler is making the enable_if fail so the constructor doesn't apply
- the enable_if passes, but there is another constructor that applies leading to ambiguity.
I'm betting on 1. My GUESS .. and its only a guess .. is that VS2019 has built in "pre-compiled headers" for some stuff or some other machinery that causes it to ignore the specialisation of is_integral in namespace std which I think is not allowed. It worked on old version, but VS2019 has additional optimisations that take advantage of the rule, or something similar.
Of course this is a design fault in the standard library. Of course the user has to be able to specialise that template, for precisely the reason indicated in this code: we have bigger ints than available and we want them to work as if they were standard.
Anyhow, some way to fix it is necessary. One obvious solution is to add an explicit constructor for uint256_t from uint128_t. This would overlap the existing constructor BUT it is not polymorphic, so it should override the template one.
I can try this on the Mac, to make sure it doesn't break anything, then commit. [I have to go do something for a while first tho .. be an hour or so]
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/felix-lang/felix/issues/149?email_source=notifications&email_token=AABLVN5L66AGHL7OBQKJAMDRGGYS3A5CNFSM4LDF2XO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEODNACI#issuecomment-596037641, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABLVNZA2FD2QICVXLH3CTLRGGYS3ANCNFSM4LDF2XOQ .
gbluma
commented
4 years ago Okay, updated the uint256_t package to newest version and included a hack to bypass type trait bug. Might (?) compile now.
On Sat, Mar 7, 2020 at 2:57 AM Garrett Bluma garrett.bluma@gmail.com wrote:
Yeah, looks like it's some sort of conflict in the type traits.
The library tries to extend the std type traits.
//////// uint256_t.include // Give uint256_t type traits namespace std { // This is probably not a good idea template <> struct is_arithmetic
: std::true_type {}; template <> struct is_integral : std::true_type {}; template <> struct is_unsigned : std::true_type {}; }; This is defined in MSVC.
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.24.28314\include\xtr1common(188): note: see declaration of 'std::is_integral'
Ideally it should play nice, but I think we're seeing an issue with it not lining up exactly as required.
On Sat, Mar 7, 2020 at 2:47 AM John Skaller notifications@github.com wrote:
Yeah, same error. But I didn't get it. So I think, scanning the source code, that there is only one constructor that could apply, the nasty crap with the enable_if in it. So there are two possibilities if think:
- compiler is making the enable_if fail so the constructor doesn't apply
- the enable_if passes, but there is another constructor that applies leading to ambiguity.
I'm betting on 1. My GUESS .. and its only a guess .. is that VS2019 has built in "pre-compiled headers" for some stuff or some other machinery that causes it to ignore the specialisation of is_integral in namespace std which I think is not allowed. It worked on old version, but VS2019 has additional optimisations that take advantage of the rule, or something similar.
Of course this is a design fault in the standard library. Of course the user has to be able to specialise that template, for precisely the reason indicated in this code: we have bigger ints than available and we want them to work as if they were standard.
Anyhow, some way to fix it is necessary. One obvious solution is to add an explicit constructor for uint256_t from uint128_t. This would overlap the existing constructor BUT it is not polymorphic, so it should override the template one.
I can try this on the Mac, to make sure it doesn't break anything, then commit. [I have to go do something for a while first tho .. be an hour or so]
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/felix-lang/felix/issues/149?email_source=notifications&email_token=AABLVN5L66AGHL7OBQKJAMDRGGYS3A5CNFSM4LDF2XO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEODNACI#issuecomment-596037641, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABLVNZA2FD2QICVXLH3CTLRGGYS3ANCNFSM4LDF2XOQ .
skaller
commented
4 years ago Ok someone can retry with my patch on VC2019?
#if 1
// workaround for MSVC2019
uint256_t(const uint128_t & rhs)
: UPPER(uint128_0), LOWER(rhs)
{}
#endifIf it fixes THAT error, there will be others for the other specialisations. But we'll have pinned it down.
gbluma
commented
4 years ago I'm struggling with git, but my hack was to force specialization by include the following in uint256_t.include, uint256_t class:
uint256_t(const uint128_t & upper_rhs, const uint128_t & lower_rhs)
: UPPER(upper_rhs), LOWER(lower_rhs)
{}
uint256_t(const uint128_t & lower_rhs)
: UPPER(uint128_0), LOWER(lower_rhs)
{}On Sat, Mar 7, 2020 at 3:46 AM John Skaller notifications@github.com wrote:
Ok someone can retry with my patch on VC2019?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/felix-lang/felix/issues/149?email_source=notifications&email_token=AABLVN32OVU24BWBYTOYRBLRGG7QBA5CNFSM4LDF2XO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEODOF7I#issuecomment-596042493, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABLVN6S6FCO3RYYTPTYWPTRGG7QBANCNFSM4LDF2XOQ .
skaller
commented
4 years ago Yep, we agree, we probably have a conflict now if you commit your patch too. I think its the same, right? It isn't enough, due to the other specialisations, but it should pin down for sure the issue.
ahribellah
commented
4 years ago Okay, finally got two separate build attempts done.
Neither fix appears to have worked. I'm seeing the same error as before for both. I recloned with a clean copy before I tried gbluma's fix, then pulled the new version, deleted the build folder, and rebuilt. I even verified that it was correctly updated by checking for the patch in build/release/share/src/uint256_t.
skaller
commented
4 years ago So hang on, we have an error saying you cannot convert from uint128_t to uint256_t, even though a constructor is provided that does exactly that? Does this mean that the error is actually due to TWO conversions being applicable? Like an operator() conversion interfering or something???
ahribellah
commented
4 years ago Correction. I'm exhausted and didn't read it properly. There are actually less errors and they're now from initializer list to uint256_t, rather than uint128_t. I didn't notice that until I looked back at the original post.
Sorry about that.
For reference:
[fbuild] [rtl] build uint256_t
copying 5 files
cp build\release\share\src\uint256_t\uint128_t.h -> build\release\share\lib\rtl\uint128_t.h
cp build\release\share\src\uint256_t\uint128_t.include -> build\release\share\lib\rtl\uint128_t.include
cp build\release\share\src\uint256_t\uint256_t.h -> build\release\share\lib\rtl\uint256_t.h
cp build\release\share\src\uint256_t\uint256_t.include -> build\release\share\lib\rtl\uint256_t.include
cp build\release\share\src\uint256_t\uint256_t_config.include -> build\release\share\lib\rtl\uint256_t_config.include
* cl.exe /GR /MDd /EHs /Zi /wd4291 /wd4190: build\release\share\src\uint256_t\uint256_t.cpp -> build\release\obj\host\lib\rtl\flx_uint256_t_static\build\release\share\src\uint256_t\uint256_t_static.obj
+ 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.24.28314\bin\HostX86\x64\cl.exe' /nologo /c /GR /MDd /EHs /Zi /wd4291 /wd4190 /Ox /Ibuild\release\share\src\uint256_t /DFLX_STATIC_LINK /Fobuild\release\obj\host\lib\rtl\flx_uint256_t_static\build\release\share\src\uint256_t\uint256_t_static.obj /showIncludes build\release\share\src\uint256_t\uint256_t.cpp
uint256_t.cpp
build\release\share\src\uint256_t\uint256_t.cpp(8): error C2661: 'uint256_t::uint256_t': no overloaded function takes 2 arguments
build\release\share\src\uint256_t\uint256_t.cpp(68): error C2440: '<function-style-cast>': cannot convert from 'initializer list' to 'uint256_t'
build\release\share\src\uint256_t\uint256_t.cpp(68): note: No constructor could take the source type, or constructor overload resolution was ambiguous
build\release\share\src\uint256_t\uint256_t.cpp(72): error C2440: '<function-style-cast>': cannot convert from 'initializer list' to 'uint256_t'
build\release\share\src\uint256_t\uint256_t.cpp(72): note: No constructor could take the source type, or constructor overload resolution was ambiguous
build\release\share\src\uint256_t\uint256_t.cpp(88): error C2440: '<function-style-cast>': cannot convert from 'initializer list' to 'uint256_t'
build\release\share\src\uint256_t\uint256_t.cpp(88): note: No constructor could take the source type, or constructor overload resolution was ambiguous
build\release\share\src\uint256_t\uint256_t.cpp(92): error C2440: '<function-style-cast>': cannot convert from 'initializer list' to 'uint256_t'
build\release\share\src\uint256_t\uint256_t.cpp(92): note: No constructor could take the source type, or constructor overload resolution was ambiguous
build\release\share\src\uint256_t\uint256_t.cpp(107): error C2440: '<function-style-cast>': cannot convert from 'initializer list' to 'uint256_t'
build\release\share\src\uint256_t\uint256_t.cpp(107): note: No constructor could take the source type, or constructor overload resolution was ambiguous
build\release\share\src\uint256_t\uint256_t.cpp(111): error C2440: '<function-style-cast>': cannot convert from 'initializer list' to 'uint256_t'
build\release\share\src\uint256_t\uint256_t.cpp(111): note: No constructor could take the source type, or constructor overload resolution was ambiguous
build\release\share\src\uint256_t\uint256_t.cpp(126): error C2440: '<function-style-cast>': cannot convert from 'initializer list' to 'uint256_t'
build\release\share\src\uint256_t\uint256_t.cpp(126): note: No constructor could take the source type, or constructor overload resolution was ambiguous
build\release\share\src\uint256_t\uint256_t.cpp(139): error C2440: '<function-style-cast>': cannot convert from 'initializer list' to 'uint256_t'
build\release\share\src\uint256_t\uint256_t.cpp(139): note: No constructor could take the source type, or constructor overload resolution was ambiguous
build\release\share\src\uint256_t\uint256_t.cpp(145): error C2440: '<function-style-cast>': cannot convert from 'initializer list' to 'uint256_t'
build\release\share\src\uint256_t\uint256_t.cpp(145): note: No constructor could take the source type, or constructor overload resolution was ambiguous
build\release\share\src\uint256_t\uint256_t.cpp(148): error C2440: '<function-style-cast>': cannot convert from 'initializer list' to 'uint256_t'
build\release\share\src\uint256_t\uint256_t.cpp(148): note: No constructor could take the source type, or constructor overload resolution was ambiguous
build\release\share\src\uint256_t\uint256_t.cpp(180): error C2440: '<function-style-cast>': cannot convert from 'initializer list' to 'uint256_t'
build\release\share\src\uint256_t\uint256_t.cpp(180): note: No constructor could take the source type, or constructor overload resolution was ambiguous
build\release\share\src\uint256_t\uint256_t.cpp(284): error C2440: '<function-style-cast>': cannot convert from 'initializer list' to 'uint256_t'
build\release\share\src\uint256_t\uint256_t.cpp(284): note: No constructor could take the source type, or constructor overload resolution was ambiguous
build\release\share\src\uint256_t\uint256_t.cpp(302): error C2440: '<function-style-cast>': cannot convert from 'initializer list' to 'uint256_t'
build\release\share\src\uint256_t\uint256_t.cpp(302): note: No constructor could take the source type, or constructor overload resolution was ambiguous
build\release\share\src\uint256_t\uint256_t.cpp(350): error C2440: '<function-style-cast>': cannot convert from 'initializer list' to 'uint256_t'
build\release\share\src\uint256_t\uint256_t.cpp(350): note: No constructor could take the source type, or constructor overload resolution was ambiguous
build\release\share\src\uint256_t\uint256_t.cpp(351): error C2440: '<function-style-cast>': cannot convert from 'initializer list' to 'uint256_t'
build\release\share\src\uint256_t\uint256_t.cpp(351): note: No constructor could take the source type, or constructor overload resolution was ambiguous
build\release\share\src\uint256_t\uint256_t.cpp(352): error C2440: '<function-style-cast>': cannot convert from 'initializer list' to 'uint256_t'
build\release\share\src\uint256_t\uint256_t.cpp(352): note: No constructor could take the source type, or constructor overload resolution was ambiguous
Error running 'C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Community\\VC\\Tools\\MSVC\\14.24.28314\\bin\\HostX86\\x64\\cl.exe /nologo /c /GR /MDd /EHs /Zi /wd4291 /wd4190 /Ox /Ibuild\\release\\share\\src\\uint256_t /DFLX_STATIC_LINK /Fobuild\\release\\obj\\host\\lib\\rtl\\flx_uint256_t_static\\build\\release\\share\\src\\uint256_t\\uint256_t_static.obj /showIncludes build\\release\\share\\src\\uint256_t\\uint256_t.cpp' exited with 2
* cl.exe /GR /MDd /EHs /Zi /wd4291 /wd4190: build\release\share\src\uint256_t\uint128_t.cpp -> build\release\obj\host\lib\rtl\flx_uint256_t_static\build\release\share\src\uint256_t\uint128_t_static.obj
NMAKE : fatal error U1077: 'D:\Applications\Anaconda3\python.EXE' : return code '0x1'Sorry. I had some garbage commits in there.Some build file junk got in and I had to revert it. (I'm a little rusty.)
But the fix could be in now if you want to try it.
On Sat, Mar 7, 2020 at 4:03 AM John Skaller notifications@github.com wrote:
So hang on, we have an error saying you cannot convert from uint128_t to uint256_t, even though a constructor is provided that does exactly that? Does this mean that the error is actually due to TWO conversions being applicable? Like an operator() conversion interfering or something???
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/felix-lang/felix/issues/149?email_source=notifications&email_token=AABLVN5U4UI72YAZ54VMQDTRGHBS5A5CNFSM4LDF2XO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEODOPUI#issuecomment-596043729, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABLVNYCKG7HXJCM6LYLGW3RGHBS5ANCNFSM4LDF2XOQ .
skaller
commented
4 years ago Perfect result! The original error is fixed. All the above errors are "convert from initialiser list"
skaller
commented
4 years ago Except this one:
build\release\share\src\uint256_t\uint256_t.cpp(8):
error C2661: 'uint256_t::uint256_t': no overloaded function takes 2 arguments
``Ah, that one @gbluma fixed but I didn't.
skaller
commented
4 years ago FYI I scrapped my mods in favour of @gbluma, so i hope @arabelladonna built from my patch before @gbluma got in. So the current code should have a two argument constructor.
gbluma
commented
4 years ago Tested the compile to completion with Windows MSVC 2019 and it worked.
On Sat, Mar 7, 2020 at 4:29 AM John Skaller notifications@github.com wrote:
FYI I scrapped my mods in favour of @gbluma https://github.com/gbluma, so i hope @arabelladonna https://github.com/arabelladonna built from my patch before @gbluma https://github.com/gbluma got in. So the current code should have a two argument constructor.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/felix-lang/felix/issues/149?email_source=notifications&email_token=AABLVNZ67YKDTTQB5YO7YLDRGHETNA5CNFSM4LDF2XO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEODO4OQ#issuecomment-596045370, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABLVNZOWA24WLDLSORCHM3RGHETNANCNFSM4LDF2XOQ .
ahribellah
commented
4 years ago Sorry for the delay, I was sleeping.
After pulling the latest version this morning, uint256_t is indeed compiling and the full Felix system has now compiled.
skaller
commented
4 years ago make test?
ahribellah
commented
4 years ago Short version:
Batch result (188 OK + 01 FAIL)/189
...
Batch result (83 OK + 00 FAIL)/83I've attached the full version below.
skaller
commented
4 years ago Seems there's one failure, can you look at the expected and actual output?
Processing [14/189]: circuits-01.flx
Opening syntax extensions D:\Code\GitHub\felix\build\release\test\regress\rt\circuits-01.flx: line 2, cols 1 to 19
Parsed open of syntax extensions chips
[flx] Output C:\Users\ari\.felix\cache\text\D\Code\GitHub\felix\build\release\test\regress\rt\circuits-01.stdout doesn't match expected D:\Code\GitHub\felix\build\release\test\regress\rt\circuits-01.expectI should emit them in the print out. The expect file is shown, the output is in the file *.output. If you install SDL2 and the config meta-data-data-base is set right the graphics should work too.
skaller
commented
4 years ago It could be windows CRLF issue.. the expected output is:
Lexeme #1='
'
Lexeme #2='// hello'
Lexeme #3='
'
Lexeme #4='var'
Lexeme #5=' '
Lexeme #6='x'
Lexeme #7=' '
Lexeme #8='='
Lexeme #9=' '
Lexeme #10='187'
Lexeme #11=';'
Lexeme #12=' '
Lexeme #13='/* some /* nested */ comments */'
Lexeme #14='
'
Lexeme #15='var'
Lexeme #16=' '
Lexeme #17='hello'
Lexeme #18=' '
Lexeme #19='='
Lexeme #20=' '
Lexeme #21='2'
Lexeme #22=';'circuits-01.expect:
Lexeme #1='
'
Lexeme #2='// hello'
Lexeme #3='
'
Lexeme #4='var'
Lexeme #5=' '
Lexeme #6='x'
Lexeme #7=' '
Lexeme #8='='
Lexeme #9=' '
Lexeme #10='187'
Lexeme #11=';'
Lexeme #12=' '
Lexeme #13='/* some /* nested */ comments */'
Lexeme #14='
'
Lexeme #15='var'
Lexeme #16=' '
Lexeme #17='hello'
Lexeme #18=' '
Lexeme #19='='
Lexeme #20=' '
Lexeme #21='2'
Lexeme #22=';'circuits-01.stdout:
Lexeme #1='
'
Lexeme #2='// hello
'
Lexeme #3='
'
Lexeme #4='var'
Lexeme #5=' '
Lexeme #6='x'
Lexeme #7=' '
Lexeme #8='='
Lexeme #9=' '
Lexeme #10='187'
Lexeme #11=';'
Lexeme #12=' '
Lexeme #13='/* some /* nested */ comments */'
Lexeme #14='
'
Lexeme #15='var'
Lexeme #16=' '
Lexeme #17='hello'
Lexeme #18=' '
Lexeme #19='='
Lexeme #20=' '
Lexeme #21='2'
Lexeme #22=';'It could be windows CRLF issue..
It does look like the only differences are a few extra newlines.
skaller
commented
4 years ago Ah, that's interesting. The test data is given in the program code:
var testdata= """
// hello
var x = 187; /* some /* nested */ comments */
var hello = 2;
"""so of course, it has a CRLF at the end of each line of the string. I guess I assumed string literals would be invariant across platforms, since the lexical encoding standard is UTF8, but Felix permits CRLF in program text, and hence literals.
The really super cool thing is that the fix in the program code is to add another coroutine that strips out a CR if followed by a LF.
ahribellah
commented
4 years ago If you install SDL2 and the config meta-data-data-base is set right the graphics should work too.
Before I forget, I was just following the instructions in the README, making adjustments to batch files as necessary. By "if you install SDL2," do you mean just the actual SDL2 library or are there additional steps that I need to take on the Felix side?
gbluma
commented
4 years ago If I recall correctly, you'll have to adjust some .fpc files to point to your install of sdl2.
I think it would be the sdl2.fpc file copied into your install folder (or build folder if that's where you run flx from.) Also do the same for sdl2_image.fpc and sdl2_ttf.fpc if you're using them.
I think it's just the hard-coded paths that are the problem.
Description: Simple Direct Media Layer 2.0 cflags: /I\Users\skaller\Desktop\SDL2-2.0.3\include includes: '"SDL.h"' provides_dlib: /DEFAULTLIB:\Users\skaller\Desktop\SDL2-2.0.3\lib\x64\SDL2
On Sun, Mar 8, 2020 at 12:44 AM Ari notifications@github.com wrote:
If you install SDL2 and the config meta-data-data-base is set right the graphics should work too.
Before I forget, I was just following the instructions in the README, making adjustments to batch files as necessary. By "if you install SDL2," do you mean just the actual SDL2 library or are there additional steps that I need to take on the Felix side?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/felix-lang/felix/issues/149?email_source=notifications&email_token=AABLVN6HWBNFO56FOVGKBLLRGLTADA5CNFSM4LDF2XO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOEJFAQ#issuecomment-596152962, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABLVN4TY4SH3ASX6SFW5ITRGLTADANCNFSM4LDF2XOQ .
ahribellah
commented
4 years ago What's the proper way to do this? Apologies, I don't work with C/C++ configuration often.
I had this and it's telling me it can't find SDL.h:
Generated_from: 3715 "D:\Code\GitHub\felix\src\packages\sdl.fdoc"
Name: SDL2
Description: Simple Direct Media Layer 2.0
cflags: /ID:\Code\"C Libraries"\SDL-2.0.10\include
includes: '"SDL.h"'
provides_dlib: /DEFAULTLIB:D:\Code\"C Libraries"\SDL-2.0.10\x64\SDL2I noticed that the original just uses "\Users". So I then moved the folder to C:\Code and had this:
Generated_from: 3715 "D:\Code\GitHub\felix\src\packages\sdl.fdoc"
Name: SDL2
Description: Simple Direct Media Layer 2.0
cflags: /I\Code\SDL-2.0.10\include
includes: '"SDL.h"'
provides_dlib: /DEFAULTLIB:\Code\SDL-2.0.10\x64\SDL2I also tried removing the D: part of the original because I have the build folder on D:. Still couldn't find it.
It still can't find it. This is the exact error:
(base) D:\Code\GitHub\felix>flx src/web/tutopt/sdlgui/gui_01_window_01.fdoc
Shell command=cl.exe /nologo /wd4190 /MDd /Zs /showIncludes /c /EHs /IC:\usr\local\lib\felix\felix-2019.01.06\share\lib\rtl /IC:\usr\local\lib\felix\felix-2019.01.06\host\lib\rtl /I\Code\SDL-2.0.10\include /ID:\Code\C C:\Users\ari\.felix\cache\text\D\Code\GitHub\felix\src/web/tutopt/sdlgui/gui_01_window_01.cpp FAILED
[flx_depchk] C++ Dependency generator FAILED on C:\Users\ari\.felix\cache\text\D\Code\GitHub\felix\src/web/tutopt/sdlgui/gui_01_window_01.cpp
Shell command=cl.exe /nologo /wd4190 /MDd /Zi /c /EHs /IC:\usr\local\lib\felix\felix-2019.01.06\share\lib\rtl /IC:\usr\local\lib\felix\felix-2019.01.06\host\lib\rtl /I\Code\SDL-2.0.10\include /ID:\Code\C C:\Users\ari\.felix\cache\text\D\Code\GitHub\felix\src/web/tutopt/sdlgui/gui_01_window_01.cpp /FoC:\Users\ari\.felix\cache\text\D\Code\GitHub\felix\src/web/tutopt/sdlgui/gui_01_window_01_dynamic.obj FAILED
gui_01_window_01.cpp
C:\Users\ari\.felix\cache\text\D\Code\GitHub\felix\src\web\tutopt\sdlgui\gui_01_window_01.includes(6): fatal error C1083: Cannot open include file: 'SDL.h': No such file or directory
Unknown error in shell 2Took me a bit to get this working on my machine.
Supposing you have your SDL development libraries in "D:\Code\C Libraries\SDL-2.0.10\x64\SDL2"
You will want to update the fpc files in c:\usr\local\lib\felix\felix-2019.01.06\host\config\ as follows.
Name: SDL2 Description: Simple Direct Media Layer 2.0 cflags: /I"D:\Code\C Libraries\SDL-2.0.10\include" includes: '"SDL.h"' provides_dlib: /DEFAULTLIB:"D:\Code\C Libraries\SDL2-2.0.10\lib\x64\SDL2"
Name: SDL2_image Description: Simple Direct Media Layer 2.0: image loader cflags: /I"D:\Code\C Libraries \SDL2_image-2.0.5\include" includes: '"SDL_image.h"' provides_dlib: /DEFAULTLIB:"D:\Code\C Libraries\SDL2_image-2.0.5\lib\x64\SDL2_image"
Name: SDL2_ttf Description: Simple Direct Media Layer 2.0: free type interface cflags: /I"D:\Code\C Libraries\SDL2_ttf-2.0.15\include" includes: '"SDL_ttf.h"' provides_dlib: /DEFAULTLIB:"D:\Code\C Libraries\SDL2_ttf-2.0.15\lib\x64\SDL2_ttf"
Also, you'll need to make sure the DLLs are in your PATH environment variable so the compiled binary can use them.
set PATH=%PATH%;"D:\Code\C Libraries\SDL2_dlls"One more thing, editing .fpc files doesn't force recompilation of felix programs, so you'll want to use the --force option to ensure the config settings are always in sync.
flx --force src\web\tutopt\sdlgui\gui_01_window_01.fdocOn Sun, Mar 8, 2020 at 4:12 PM Ari notifications@github.com wrote:
What's the proper way to do this? Apologies, I don't work with C/C++ configuration often.
I had this and it's telling me it can't find SDL.h:
Generated_from: 3715 "D:\Code\GitHub\felix\src\packages\sdl.fdoc" Name: SDL2 Description: Simple Direct Media Layer 2.0 cflags: /ID:\Code\"C Libraries"\SDL-2.0.10\include includes: '"SDL.h"' provides_dlib: /DEFAULTLIB:D:\Code\"C Libraries"\SDL-2.0.10\x64\SDL2
I noticed that the original just uses "\Users". So I then moved the folder to C:\Code and had this:
Generated_from: 3715 "D:\Code\GitHub\felix\src\packages\sdl.fdoc" Name: SDL2 Description: Simple Direct Media Layer 2.0 cflags: /I\Code\SDL-2.0.10\include includes: '"SDL.h"' provides_dlib: /DEFAULTLIB:\Code\SDL-2.0.10\x64\SDL2
I also tried removing the D: part of the original because I have the build folder on D:. Still couldn't find it.
It still can't find it. This is the exact error:
(base) D:\Code\GitHub\felix>flx src/web/tutopt/sdlgui/gui_01_window_01.fdoc Shell command=cl.exe /nologo /wd4190 /MDd /Zs /showIncludes /c /EHs /IC:\usr\local\lib\felix\felix-2019.01.06\share\lib\rtl /IC:\usr\local\lib\felix\felix-2019.01.06\host\lib\rtl /I\Code\SDL-2.0.10\include /ID:\Code\C C:\Users\ari.felix\cache\text\D\Code\GitHub\felix\src/web/tutopt/sdlgui/gui_01_window_01.cpp FAILED [flx_depchk] C++ Dependency generator FAILED on C:\Users\ari.felix\cache\text\D\Code\GitHub\felix\src/web/tutopt/sdlgui/gui_01_window_01.cpp Shell command=cl.exe /nologo /wd4190 /MDd /Zi /c /EHs /IC:\usr\local\lib\felix\felix-2019.01.06\share\lib\rtl /IC:\usr\local\lib\felix\felix-2019.01.06\host\lib\rtl /I\Code\SDL-2.0.10\include /ID:\Code\C C:\Users\ari.felix\cache\text\D\Code\GitHub\felix\src/web/tutopt/sdlgui/gui_01_window_01.cpp /FoC:\Users\ari.felix\cache\text\D\Code\GitHub\felix\src/web/tutopt/sdlgui/gui_01_window_01_dynamic.obj FAILED gui_01_window_01.cpp C:\Users\ari.felix\cache\text\D\Code\GitHub\felix\src\web\tutopt\sdlgui\gui_01_window_01.includes(6): fatal error C1083: Cannot open include file: 'SDL.h': No such file or directory Unknown error in shell 2
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/felix-lang/felix/issues/149?email_source=notifications&email_token=AABLVN3AHISCFZZYNFRS2C3RGPGWPA5CNFSM4LDF2XO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOE2BGY#issuecomment-596222107, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABLVN4MUZISCTKCZKYQVZLRGPGWPANCNFSM4LDF2XOQ .
ahribellah
commented
4 years ago One more thing, editing .fpc files doesn't force recompilation of felix programs, so you'll want to use the --force option to ensure the config settings are always in sync.
This seems to have been the primary issue. I didn't realize that that needed to be done.
Sorry to report another error, but I'm now getting this when compiling.
(base) D:\Code\GitHub\felix>flx --force src\web\tutopt\sdlgui\gui_01_window_01.fdoc
cl : Command line error D8003 : missing source filename
Shell command=cl.exe /nologo /wd4190 /MDd /Zs /showIncludes /c /EHs /IC:\usr\local\lib\felix\felix-2019.01.06\share\lib\rtl /IC:\usr\local\lib\felix\felix-2019.01.06\host\lib\rtl /I"D:\Code\C C:\Users\ari\.felix\cache\text\D\Code\GitHub\felix\src\web\tutopt\sdlgui\gui_01_window_01_static_link_thunk.cpp FAILED
[flx_depchk] C++ Dependency generator FAILED on C:\Users\ari\.felix\cache\text\D\Code\GitHub\felix\src\web\tutopt\sdlgui\gui_01_window_01_static_link_thunk.cpp
cl : Command line error D8003 : missing source filename
Shell command=cl.exe /nologo /wd4190 /MDd /Zi /c /EHs /IC:\usr\local\lib\felix\felix-2019.01.06\share\lib\rtl /IC:\usr\local\lib\felix\felix-2019.01.06\host\lib\rtl /I"D:\Code\C C:\Users\ari\.felix\cache\text\D\Code\GitHub\felix\src\web\tutopt\sdlgui\gui_01_window_01_static_link_thunk.cpp /FoC:\Users\ari\.felix\cache\text\D\Code\GitHub\felix\src\web\tutopt\sdlgui\gui_01_window_01_static_link_thunk_dynamic.obj FAILED
Unknown error in shell 2I noticed /I"D:\Code\C, which seems to imply that it doesn't like that there's a space in C Libraries, but it also isn't throwing the error that it can't find SDL.h now.
EDIT: It was, in fact, the space in in C Libraries. Removing that fixed it. Just a note for future reference.
skaller
commented
4 years ago There's more to know, take note! First, it should handle spaces in flx_pkgconfig files (fpc files) correctly if you quote arguments. I think otherwise space is a separator. So there might be a problem, because a "string" to flx_pkgconfig will have the lexical quotes removed but an embedded space, but the system has to put quotes back when emitting the string to preserve the space.
Second, and much more important: if you hand edit files in build/release/host/config the next time you rebuild Felix from scratch (using make), you will clobber your edits/additions. So you must COPY these files into the directory:
$HOME/.felix/config
or wherever your .felix directory is. When the bootstrap is setting up the environment it first puts files into the target config directory using a formula based on the machine/compiler. You can see the source files in src/config after package extraction, organised in a tree. The system does not search for things. It just follows the formula.
AFTER that, it copies the *.fpc files in .felix/config, reinstalling your edits.
In fact this is a design fault! The problem is that you can have multiple targets each needing distinct configuration meta-data. So really the .fpc should be saved in .felix/config/target/.fpc.
ahribellah
commented
4 years ago In fact this is a design fault! The problem is that you can have multiple targets each needing distinct configuration meta-data. So really the .fpc should be saved in .felix/config/target/.fpc.
Noted. I'll do that before I rebuild it next time.
After getting the SDL error sorted, this is the error I'm faced with:
(base) D:\Code\GitHub\felix>flx --force src\web\tutopt\sdlgui\gui_01_window_01.fdoc
Felix exception handler
Dynamic linkage error
filename: C:\Users\ari\.felix\cache\binary\D\Code\GitHub\felix\src\web\tutopt\sdlgui\gui_01_window_01.dll
operation: LoadLibrary/dlopen
what: Cannot find dll/shared library
Unknown error in shell 3The library exists. Here are the results of using file from MSYS2:
ari@DESKTOP-1ER5E33 MINGW64 ~
$ file /c/users/ari/.felix/cache/binary/D/Code/GitHub/felix/src/web/tutopt/sdlgui/gui_01_window_01.dll
/c/users/ari/.felix/cache/binary/D/Code/GitHub/felix/src/web/tutopt/sdlgui/gui_01_window_01.dll: PE32+ executable (DLL) (GUI) x86-64, for MS WindowsI suspect that it is not that DLL that it can't find. You can check by running
flx hello.flxIf that works, it is generating and loading hello.dll in the binary cache just fine.
I suspect it is one of the SDL dlls that is not found. If it is on $PATH it should find it BUT this is NOT how it is supposed to work. When running under control of flx, the driver itself should provide the required path. That is, when running the program, it should be setting PATH itself.
ahribellah
commented
4 years ago Okay, I manually added them to my path. It built, but there was an "unknown error" and the SDL window loaded up with a gray background and then immediately stopped responding.
Here's the output:
(base) D:\Code\GitHub\felix>set PATH=D:\Code\CLibraries\SDL-2.0.10\x64;%PATH%
(base) D:\Code\GitHub\felix>flx --force src\web\tutopt\sdlgui\gui_01_window_01.fdoc
Basic Window Test
SDL_init OK
TTF_init OK
IMG_init OK
We compiled against SDL version 2.0.10 ...
But we are linking against SDL version 2.0.10.
We compiled against TTF version 2.0.15 ...
But we are linking against TTF version 2.0.15.
We compiled against IMG version 2.0.5 ...
But we are linking against IMG version 2.0.5.
Unknown error in shell -805306369Try a later test case. I have an issue with that too, I don't even get a window. This only start happening recently, i haven't checked it out yet. Try this one:
sdlgui/gui_04_wm_01.flxI'm rebuilding my Windows Felix, I'll try to get SDL running, but at the moment hello.flx doesn't work ;-)
skaller
commented
4 years ago oops .. its a .fdoc not a .flx.
skaller
commented
4 years ago The early tests use this only:
Faio::sleep(clock,15.0);which is just a delay. But this uses the event polling system demux and the async I/O system. The async system is provided in a DLL which is loaded on demand, and it starts a pthread to monitor the events using OS specific stuff like epoll on Linux, kqueue on MacOS, and I/O completion ports on Windows. However your basic tests all worked and they include some async.
As there hasn't been a release in a year, I decided to build Felix from source. However, I've encountered an error during the build process.
I'm using Visual Studio 2019.
Here's the error: